Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id DB2962009C6 for ; Tue, 31 May 2016 11:16:12 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id D9B19160A43; Tue, 31 May 2016 09:16:12 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 2B8D3160A01 for ; Tue, 31 May 2016 11:16:12 +0200 (CEST) Received: (qmail 77535 invoked by uid 500); 31 May 2016 09:16:06 -0000 Mailing-List: contact dev-help@santuario.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@santuario.apache.org Delivered-To: mailing list dev@santuario.apache.org Received: (qmail 77525 invoked by uid 99); 31 May 2016 09:16:06 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 May 2016 09:16:06 +0000 Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 1359C1A0182 for ; Tue, 31 May 2016 09:16:04 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id p34so18345688qgp.1 for ; Tue, 31 May 2016 02:16:04 -0700 (PDT) X-Gm-Message-State: ALyK8tLXzPFufAPK7ZTCqy35PghoM9toNaNCXL37nfMGsF/dqxG/qBQqyEDHvUZhIREftUFjqz/IucDWEuYAPQ== MIME-Version: 1.0 X-Received: by 10.140.20.162 with SMTP id 31mr18527140qgj.106.1464686163668; Tue, 31 May 2016 02:16:03 -0700 (PDT) Reply-To: coheigea@apache.org Received: by 10.237.55.231 with HTTP; Tue, 31 May 2016 02:16:03 -0700 (PDT) In-Reply-To: <9846A6064BD102419D06814DD0D78DE112929E13@CIO-TNC-D2MBX02.osuad.osu.edu> References: <9846A6064BD102419D06814DD0D78DE112929D38@CIO-TNC-D2MBX02.osuad.osu.edu> <9892EC6224DBC54598164D1F77721D75A8333B086E@IBIUSMBSB.ibi.com> <9846A6064BD102419D06814DD0D78DE112929E13@CIO-TNC-D2MBX02.osuad.osu.edu> Date: Tue, 31 May 2016 10:16:03 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Base64 error? From: Colm O hEigeartaigh To: "dev@santuario.apache.org" Content-Type: multipart/alternative; boundary=001a11c1248a7e3bf105341fd26d archived-at: Tue, 31 May 2016 09:16:13 -0000 --001a11c1248a7e3bf105341fd26d Content-Type: text/plain; charset=UTF-8 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 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 --001a11c1248a7e3bf105341fd26d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks all for the feedback. I came across = this bug in Apache Ranger, which uses the Santuario BASE-64 encoder to enco= de 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:

= =C2=A0=C2=A0=C2=A0 =C2=A0 String masterKey1 =3D org.apache.xml.security.uti= ls.Base64.encode(key.getBytes());
=C2=A0=C2=A0=C2=A0 =C2=A0 org.apache.c= ommons.codec.binary.Base64 base64 =3D new org.apache.commons.codec.binary.B= ase64(76, new byte[]{'\n'});
=C2=A0=C2=A0=C2=A0 =C2=A0 String ma= sterKey2 =3D new String(base64.encode(key.getBytes())).trim();
=C2=A0=C2= =A0=C2=A0 =C2=A0 org.junit.Assert.assertEquals(masterKey1, masterKey2);
=
There is actually two problems here, using '\n' instead o= f '\r\n' and also not adding an additional line separator at the en= d (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&= #39;m inclined to make the change as it won't have huge backwards compa= tibility implications. Anyone object to this?

Colm.
<= div class=3D"gmail_extra">
On Mon, May 30, 20= 16 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 hEige= artaigh

Talend Community Coder
http://coders.talend.com
--001a11c1248a7e3bf105341fd26d--