CRLF change in Java 8 patch

["Cantor, Scott" <ca...@osu.edu>]

Sean, mostly:

Were folks expecting to see Java 8 mid-stream pick up that Base64 change in Santuario that adds the CR character to the wrapped base64 blobs?

It showed up in the latest Oracle patch, but has *not* appeared in the other OpenJDK 8 patch releases we have under test.

That is not an ideal situation, needless to say. Our opinion is that change was a huge mistake, but be that as it may, to start seeing things fork in such a potentially sensitive area is a pretty big red flag. We suspected it might happen, but being right doesn't make it any more fun.

-- Scott

Re: CRLF change in Java 8 patch

["Cantor, Scott" <ca...@osu.edu>]

On 10/17/19, 10:22 AM, "Colm O hEigeartaigh" <co...@apache.org> wrote:

> Are you referring to the fix that was made for 2.1.2? 
> As in, the latest Oracle patch, does not have this fix above?

I was referring to the original CR change from back before the property was even added. I don't know if Java's copy honors the property or not, but the change is that the old util.Base64 class (that I know 2.1.x has moved off of) in Java 8 did not have the CR added prior to the 231/232 patch that just came out.

The latest OpenJDK(s) 8 did not appear to pick up that change. So Oracle Java 8 != OpenJDK 8 in a fairly sensitive area.

I'm curious if Oracle intended that change, or if it was an accident.

-- Scott

Re: CRLF change in Java 8 patch

["Cantor, Scott" <ca...@osu.edu>]

On 10/17/19, 2:46 PM, "Sean Mullan" <se...@oracle.com> wrote:

[snip]

That answers my question, thank you.

-- Scott

Re: CRLF change in Java 8 patch

[Sean Mullan <se...@oracle.com>]

On 10/17/19 11:49 AM, Cantor, Scott wrote:
> To be honest, it *is* possible that the Java 8 change we observed could have been that they suddenly moved it from shadowing xmlsec 2.0.x to 2.1.x, but I think it's more plausible that just the Base64 class changed (or they revved a 2.0.x release) than that they would have moved a whole minor xmlsec version in the JDK patch.

That came in as part of the upgrade to 2.1.3: 
https://bugs.openjdk.java.net/browse/JDK-8230710

It has also been pushed to OpenJDK 11.0.5: 
https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/caa57e349340

Not yet to OpenJDK 8 it seems. You could ask about any plans to do that 
on the OpenJDK 8 dev list: jdk8u-dev@openjdk.java.net

--Sean

> 
> -- Scott
> 
> On 10/17/19, 10:22 AM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
> 
> Hi Scott,
> 
> Are you referring to the fix that was made for 2.1.2?
> https://issues.apache.org/jira/browse/SANTUARIO-482
> 
> 

Re: CRLF change in Java 8 patch

["Cantor, Scott" <ca...@osu.edu>]

To be honest, it *is* possible that the Java 8 change we observed could have been that they suddenly moved it from shadowing xmlsec 2.0.x to 2.1.x, but I think it's more plausible that just the Base64 class changed (or they revved a 2.0.x release) than that they would have moved a whole minor xmlsec version in the JDK patch.

-- Scott

On 10/17/19, 10:22 AM, "Colm O hEigeartaigh" <co...@apache.org> wrote:

Hi Scott,

Are you referring to the fix that was made for 2.1.2? 
https://issues.apache.org/jira/browse/SANTUARIO-482 

Re: CRLF change in Java 8 patch

[Colm O hEigeartaigh <co...@apache.org>]

Hi Scott,

Are you referring to the fix that was made for 2.1.2?
https://issues.apache.org/jira/browse/SANTUARIO-482

As in, the latest Oracle patch, does not have this fix above?

Colm.

On Thu, Oct 17, 2019 at 3:16 PM Cantor, Scott <ca...@osu.edu> wrote:

> Sean, mostly:
>
> Were folks expecting to see Java 8 mid-stream pick up that Base64 change
> in Santuario that adds the CR character to the wrapped base64 blobs?
>
> It showed up in the latest Oracle patch, but has *not* appeared in the
> other OpenJDK 8 patch releases we have under test.
>
> That is not an ideal situation, needless to say. Our opinion is that
> change was a huge mistake, but be that as it may, to start seeing things
> fork in such a potentially sensitive area is a pretty big red flag. We
> suspected it might happen, but being right doesn't make it any more fun.
>
> -- Scott
>
>
>