[jdk8u-dev] RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec [v2]

[Andrew John Hughes]

On Thu, 13 Apr 2023 15:11:24 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> The 8u JDK-8244154 backport https://hg.openjdk.org/jdk8u/jdk8u/hotspot/rev/803cbdf0f152 includes just the readme comment update, while the 11u backport https://hg.openjdk.org/jdk-updates/jdk11u/rev/87e85e5123dd includes much else. 8u and 11u both define the SHA3 mechanisms in share/native/sun/security/pkcs11/wrapper/pkcs11t.h, but the 11u JDK-8263404 backport doesn't include them in p11-nss-sensitive.txt.
> 
> In light of the above, shall we stay with 11u backport compatibility or add the SHA3 mechanisms back to p11-nss-sensitive.txt?

There are eight 8u changesets for this change, in light of the forest of repository used at the time and the need to update `THIRD_PARTY_README` across all of them.

The meat of the change is https://github.com/openjdk/jdk8u-dev/commit/c52caa91409cfef72f375590b6a606700a279d9c#diff-a616f7793085d46b7c847c0b4a5b81f3f7c7b7d66fd3d7212c1dd3aa49385b00R665 which includes the SHA3 definitions.

I tend towards keeping the trunk version of `p11-nss-sensitive.txt` because it avoids any surprises in the (unlikely) case that a provider is used with that test that has one of the SHA3 mechanisms enabled. I'm with Martin in that it isn't clear to me why non-RSA mechanisms are being disabled at all to begin with, but I'd prefer to keep the original configuration if it doesn't break the test on 8u.

Incidentally, the `@modules jdk.crypto.cryptoki` line in `TestP11KeyFactoryGetRSAKeySpec.java` could go. No-one is ever going to backport the entire module system to 8u. The lack of it is one of the main reasons people stick with 8u.

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

PR Comment: https://git.openjdk.org/jdk8u-dev/pull/302#issuecomment-1507160755