kuzjka opened a new pull request, #504:
URL: https://github.com/apache/santuario-xml-security-java/pull/504

   ### New feature
   
   This PR continues [the mailing list 
thread](https://lists.apache.org/thread/d285pdhjz5mfhcmbrglzkn6qthsyyxjr) and 
suggests system properties to control base64Binary values formatting:
   
   * `org.apache.xml.security.base64.lineSeparator`, 
`org.apache.xml.security.base64.lineLength` - allows to override default MIME 
encoding settings
   * `org.apache.xml.security.base64.ignoreLineBreaks` - disables line wrapping 
for base64 value, but allows to keep the whole XML pretty-printed. Takes 
precedence over line wrapping settings above.
   * existing `org.apache.xml.security.ignoreLineBreaks` takes precedence over 
all new options.
   
   Default values result to CRLF line breaks with 76 chars in the line, making 
the whole thing fully compatible with previous implementation.
   
   ### Other changes
   
   Some of the logic is included to XMLUtils to provide better encapsulation:
   * adding line breaks in the beginning and in the end of wrapped base64 
values in the element is implemented as `XMLUtils.encodeElementValue`
   * `Base64OutputStream` from Commons, used in XML encryption, is replaced 
with a `java.util` implementation and provided by `XMLUtils`, making it 
consistent with configured Base64 encoder.
   
   `Base64.Encoder/Decoder` instances are thread-safe, so sharing a single 
instance should give us a little performance gain.
   
   ### Test coverage
   
   As the base64 configuration takes place during class load, unit-tests 
leverage from custom `ClassLoader` and Reflection API to reinitialize the class 
in each test.
   
   ### Motivation
   
   https://www.w3.org/TR/xmlschema-2/#base64Binary - `base64Binary` definition 
has note, that original MIME line-length limitation must not be enforced. In 
current implementation it is only possible to remove all line breaks in the 
document using `org.apache.xml.security.ignoreLineBreaks`, sacrificing human 
readability.
   
   Also, using LF instead of CRLF may be desired in systems where verifying 
side does not expect escape sequences in base64Binary values.
   
   ---
   
   I would be thankful for your comments and suggestions.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@santuario.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to