Bug ID: JDK-8236645 JDK 8u231 introduces a regression with incompatible handling of XML messages

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 7	JDK 8	Other
7u321Fixed	8u241Fixed	openjdk8u272Fixed

JDK 8u231 introduces a regression with incompatible handling of XML message signing

Starting with JDK 8u231, there was a change in the way that Oracle Java handles the XML message and signing (possibly related to JDK-8177334 or others).

The problem breaks existing client systems.  

When a server platform is updated to JDK 8u231, the form of the signed XML messages is changed slightly making them incompatible with older clients already in the field which expect the message to be processed and signed as it was in the past.

Replacing the clients is a long-term process for end users of customers and is not a workable solution.  We need the server and the JDK on the server to provide the same format signed XML messages as they did in the past.

Possibly the same issue as the regression: JDK-8235603 

This problem is observed while using WebLogic Server 12.1.3.

Fix Request [8u] Requesting jdk8u approval of this fix to provide a workaround to users who require the legacy Base64 format. This change has been implemented to conform to the details outlined in the CSR. The webrev below passes jdk_tier1 and the jdk_security tests. 8u webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8236645/webrev.02/ 8u RFR: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012477.html
20-08-2020
A new Oracle JDK 8 Updates only system property - `com.sun.org.apache.xml.internal.security.lineFeedOnly` is made available to fall back to legacy Base64 encoded format. Users can set this flag in one of two ways: 1. -Dcom.sun.org.apache.xml.internal.security.lineFeedOnly=true 2. System.setProperty("com.sun.org.apache.xml.internal.security.lineFeedOnly", "true") Later JDK family versions will only support the recommended property: `com.sun.org.apache.xml.internal.security.ignoreLineBreaks`
11-02-2020
Initial analysis: workaround supplied in JDK-8235603 uses Base64 (Basic) encoder so it eliminates the carriage return value appended at the end. Looking at the Base64 Basic description - https://docs.oracle.com/javase/8/docs/api/index.html?java/util/Base64.html The encoder does not add any line feed and the value returned is a long encoded output. Output is the same for jdk8u231 and jdk8u221 when setting the system property to ignoreLineBreaks Since the clients validate the format of the returned output, they see the issue. I will investigate further on the behaviour seen. Thanks, Kiran
10-02-2020
The Santuario community seem to have resisted similar calls to roll back or provide assistance on this interoperability issue. A new property was proposed at one stage (to change encoder away from the more compliant JDK Base64 encoder) but they appear to have then changed their mind and didn't offer the option in the end. Perhaps the right decision. Some info here: http://apache-xml-project.6118.n7.nabble.com/Feedback-requested-on-SANTUARIO-482-td44506.html https://issues.apache.org/jira/browse/SANTUARIO-482
07-01-2020

CSR :	JDK-8237765 - JDK 8u231 introduces a regression with incompatible handling of XML messages
Duplicate :	JDK-8235603 - 8u231 Transform of DOM to byte array adds ASCII carriage return to signed XML
Relates :	JDK-8177334 - Update xmldsig implementation to Apache Santuario 2.1.1
Relates :	JDK-8235603 - 8u231 Transform of DOM to byte array adds ASCII carriage return to signed XML