[jdk21u-dev] RFR: 8302111: Serialization considerations

[Andrew John Hughes]

On Mon, 10 Feb 2025 15:38:07 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> I think this is a valuable fix we need in 21.  It secures deserialized data.
> 
> The code needed some resolves, but overall the change of
> head fits well on the code in 21.  In detail:
> 
> I resolved
>   src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java and
>   src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java.
> It does not apply as these changes are missing in 21:
>   8311170: Simplify and modernize equals and hashCode in security area
>   8315974: Make fields final in 'com.sun.crypto.provider' package
> Both files have similar differences between head and 21:
> In both files I resolved one larger chunk. Some of the removed code is different:
>   * Initialization of this.l removed in original.  This initialization is not in 21.
>   * head has some coding initializing this.x/y.  This is handled by a call to
>     parseKeyBits() in 21, which executes similar code.
> The new code is the same as in head.
> 
> In src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java, changes
>   8327818: Implement Kerberos debug with sun.security.util.Debug and again
>   8311170: Simplify and modernize equals and hashCode in security area
> are missing in 21.
> This only requires trivial resolves due to context differences.
> 
> I based this backport on the commit to head.
> The commit to 22.0.2 is identical to that, except that it skips
> two unnecessary empty lines in KRBError.java. I rather go
> with the head version as this will make further backports
> fit better.
> 
> This passed our nightly testing which includes the tests for the security implementations. 
> We run headless tier 1-4 on 8 platform with fastdebug, jck and further internal tests.

Backport mostly looks good. The initialisation differences for `l`, `x` and `y` are also from JDK-8315974: "Make fields final in 'com.sun.crypto.provider' package". I presume, because the fields were now final, there could not be code paths that didn't initialise `l` and the initialisation of `x` and `y` could no longer be delegated to `parseKeyBits`.

On the subject of `parseKeyBits`, I think this method can now be removed, as it is in JDK-8315974. It is a private method that I don't see being called from anywhere else in those files.

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

Changes requested by andrew (Reviewer).

PR Review: https://git.openjdk.org/jdk21u-dev/pull/1391#pullrequestreview-2607161182