santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Base64 error?
Date Tue, 31 May 2016 09:16:03 GMT
Thanks all for the feedback. I came across this bug in Apache Ranger, which
uses the Santuario BASE-64 encoder to encode keys as part of a Hadoop Key
Management Service. I swapped the Santuario BASE-64 encoder out and
replaced it with Commons Codec, and the output is different. To produce the
same output, I need to do something like:

      String masterKey1 =
org.apache.xml.security.utils.Base64.encode(key.getBytes());
      org.apache.commons.codec.binary.Base64 base64 = new
org.apache.commons.codec.binary.Base64(76, new byte[]{'\n'});
      String masterKey2 = new String(base64.encode(key.getBytes())).trim();
      org.junit.Assert.assertEquals(masterKey1, masterKey2);

There is actually two problems here, using '\n' instead of '\r\n' and also
not adding an additional line separator at the end (hence the trim() above
on the commons codec output).

Given, as Clemont points out, that the XML processor maps \r\n to \n on
input, I'm inclined to make the change as it won't have huge backwards
compatibility implications. Anyone object to this?

Colm.

On Mon, May 30, 2016 at 9:09 PM, Cantor, Scott <cantor.2@osu.edu> wrote:

> > The XML spec requires the XML processor to map \r\n to \n on input,
> > thereby hiding this discrepancy.
>
> Good point.
>
> > Is the Base64 value ever used without this mapping taking place?
>
> Possibly in very obscure cases involving enveloping signatures?
>
> -- Scott
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
View raw message