Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8237765

JDK 8u231 introduces a regression with incompatible handling of XML messages

    XMLWordPrintable

    Details

    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      low
    • Compatibility Risk Description:
      No effect on current JDK behaviour. The new system property will be disabled by default.
    • Interface Kind:
      System or security property
    • Scope:
      JDK

      Description

      Summary

      Oracle JDK 8u231 upgraded the Apache Santuario libraries to v2.1.3. As part of that upgrade, the Santuario stack has become more strict on how it encodes data and is now using the JDK encoder rather than its own legacy encoder. This change introduced an issue where XML signature using the Base64 encoding resulted in appending &#xd or &#13 to the encoded output. This issue is seen in the Apache Santuario code base and not a JDK issue. The Santuario team has adopted a position of keeping their libraries compliant with the RFC 2045 -

      https://issues.apache.org/jira/browse/SANTUARIO-494

      https://issues.apache.org/jira/browse/SANTUARIO-482

      and recommended using com.sun.org.apache.xml.internal.security.ignoreLineBreaks System property to workaround the issue. But this property usage results in a long encoded output. A few Oracle JDK customers use client software to verify the format returned by the encoder. The software expects the data obtained to match legacy Base64 encoding result. Customers expect JDK Updates to work seamlessly in their enterprise, a need for fixing the issue specific to Oracle JDK 8 Updates is proposed. When upgrading to later JDK versions, it is the Customer's responsibility to upgrade their client's software as well.

      Problem

      With the upgraded Apache Santuario libraries, nearly all encoding requests are now managed by the JDK java.util.Base64 implementation, which is more compliant with the RFC standards as opposed to the legacy encoder that ships with the Santuario libraries.

      As per the RFC complaint Encoder specification adopted by Apache Santuario:

      The encoded output must be represented in lines of no more than 76 characters each and uses a carriage return {@code '\r'} followed immediately by a linefeed {@code '\n'} as the line separator.

      &#xd or &#13 are the ASCII values of '\r' who somehow escape encoding and appends to the encoded output.

      Following examples can be used for better understanding:

      JDK 8u231 Encoding output :

      Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1t
      appOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvX
      sf4F9Q==

      JDK 8u231 with ignoreLineBreaks property:

      Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1tappOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvXsf4F9Q==

      Expected output (Legacy Encoding output):

      Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1t
      appOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvX
      sf4F9Q==

      Solution

      Introduce a new system property com.sun.org.apache.xml.internal.security.lineFeedOnly which when set uses the API getMimeEncoder(int linelength, byte[] lineSeparator) with linelength as 76 and lineSeparator as '\n'. This way no carriage return is passed to Encoding logic.

      With the new property the expected result is obtained:

      Result before setting System property:

      Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1t
      appOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvX
      sf4F9Q==

      Result after setting System property:

      Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1t
      appOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvX
      sf4F9Q==

      This new com.sun.org.apache.xml.internal.security.lineFeedOnly System Property will be available only in Oracle JDK 8 Updates. Later JDK versions will still need to use System Property com.sun.org.apache.xml.internal.security.ignoreLineBreaks and client software's should be updated to work with the logic.

      Specification

      No specification change, only behavioral change with the new property is observed. This new property has no effect on default behavior nor when com.sun.org.apache.xml.internal.security.ignoreLineBreaks property is set.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              kravikumar Kiran Sidhartha Ravikumar
              Reporter:
              shadowbug Shadow Bug
              Reviewed By:
              Sean Mullan
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: