[jdk17u-dev] RFR: 8305972: Update XML Security for Java to 3.0.2 [v6]

[Severin Gehwolf]

On Wed, 10 Jan 2024 15:27:17 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> I backport this for parity with 17.0.11-oracle.
>> 
>> The backport was almost clean, except for two trivial resolves due to differences in whitespace in the context.
>> 
>> The change comes with a CSR, which is already approved for 17.
>> But the CSR requires changes wrt. to the original change. 
>> In 17, no EDDSA support is added.
>> 
>> The PR comes with two commits:
>> 1. the almost clean backport. I already skipped two comments added in head but not needed in 17 (SignatureMethod, DigestMethod).
>> 2. removing the eddsa support.
>> 
>> Tests pass, SAP nightly testing passed.
>
> Goetz Lindenmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup Test as proposed by Martin B.

>From the 17, 11 and 8u CSR:


The port is largely the same in terms of implementation as that done for JDK 21.

The javax.xml.crypto.dsig.SignatureMethod and javax.xml.crypto.dsig.DigestMethod interfaces will not be updated. Instead, end users would define the newly added EdDSA Signature methods locally in application code. Unlike JDK 17 and later, JDK 11 and 8 doesn't have EdDSA support by default. A 3rd party security provider which supports ed25519 and ed448 would be required.


This suggests that EdDSA support was kept as this bug is about updating a bundled in-tree library from a third party (Apache Santuario). So changes to that third party code should be kept to a minimum, IMO. For JDK 11 and JDK 8 even a third party provider would be needed in order to be able to use EdDSA there.

TLDR; Since this is a third-party library code upgrade, I'd suggest to go with https://github.com/openjdk/jdk17u-dev/pull/2116

HTH.

-------------

PR Comment: https://git.openjdk.org/jdk17u-dev/pull/2006#issuecomment-1895461204