From duke at openjdk.org Tue Apr 1 01:19:30 2025 From: duke at openjdk.org (duke) Date: Tue, 1 Apr 2025 01:19:30 GMT Subject: Withdrawn: 8347938: Switch to latest ML-KEM private key encoding In-Reply-To: References: Message-ID: <1LNJ1Ay7MZtQIjuhfI0-xrAdfJ1pwARUGML0uE78h08=.0a9c7d8a-a510-4b62-9d97-d04c699b8396@github.com> On Thu, 30 Jan 2025 22:00:07 GMT, Weijun Wang wrote: > The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IERTF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-06 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-07. Most importantly, the seed used to generate a key pair is now stored in the private key. > > Both the seed and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key that contains the seed, both fields will be filled. If the PKCS #8 encoding only contains the expanded key (which does not conform to the current drafts but might have been created earlier), the expanded key will be read and used in KEM and signature operations. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23376 From djelinski at openjdk.org Tue Apr 1 07:16:22 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 1 Apr 2025 07:16:22 GMT Subject: RFR: 8350705: [JMH] test security.SSLHandshake failed for 2 threads configuration In-Reply-To: <1RpDvTY_v21orweF8PU6KJ7ce9IaqQ4pr6fM2vrbsow=.ef1b7d76-5a0d-4e64-98c1-3372bd5bf275@github.com> References: <1RpDvTY_v21orweF8PU6KJ7ce9IaqQ4pr6fM2vrbsow=.ef1b7d76-5a0d-4e64-98c1-3372bd5bf275@github.com> Message-ID: On Tue, 25 Mar 2025 15:38:02 GMT, Hai-May Chao wrote: >> Update the SSLHandshake benchmark to enable running in multiple threads. >> >> This PR changes the scope of the state from per-benchmark to per-thread. The server SSLContext is still shared across all threads to simulate the scenario where multiple clients try to connect to the same server at the same time. >> >> Before the change, running this benchmark with `make test TEST=micro:SSLHandshake MICRO=OPTIONS="-t 3"` failed with an exception. After this change the benchmark completes successfully. > > Changes look good. Thanks @haimaychao for the review! Can I get a second review please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24195#issuecomment-2768403907 From lkorinth at openjdk.org Tue Apr 1 10:53:54 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 1 Apr 2025 10:53:54 GMT Subject: Integrated: 8352719: Add an equals sign to the modules statement In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 12:30:57 GMT, Leo Korinth wrote: > krb5/auto/TEST.properties: add an equals sign to the modules statement (this is the only `TEST.properties` file that uses this undocumented feature) . > > compare: > > find -name "TEST.properties" | xargs grep 'modules.*java' > find -name "TEST.properties" | xargs grep 'modules.*java' | grep -v = This pull request has now been integrated. Changeset: 85a0baf0 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/85a0baf0cb3366d6c16f9aadee123862117f5338 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod 8352719: Add an equals sign to the modules statement Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/24194 From lkorinth at openjdk.org Tue Apr 1 10:53:54 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 1 Apr 2025 10:53:54 GMT Subject: RFR: 8352719: Add an equals sign to the modules statement In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 12:30:57 GMT, Leo Korinth wrote: > krb5/auto/TEST.properties: add an equals sign to the modules statement (this is the only `TEST.properties` file that uses this undocumented feature) . > > compare: > > find -name "TEST.properties" | xargs grep 'modules.*java' > find -name "TEST.properties" | xargs grep 'modules.*java' | grep -v = Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24194#issuecomment-2768961419 From mullan at openjdk.org Tue Apr 1 15:28:35 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 1 Apr 2025 15:28:35 GMT Subject: RFR: 8347067: Load certificates without explicit trust settings in KeyChainStore [v5] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:43:32 GMT, Tim Jacomb wrote: >> ## The change >> >> Without this change intermediate certificates that don't have explicit trust settings are ignored not added to the truststore. >> >> >> >> ## Reproducer >> >> See https://github.com/timja/openjdk-intermediate-ca-reproducer >> >> Without this change the reproducer fails, and with this change it succeeds. >> >> ## Example failing architecture >> >> Root CA -> Intermediate 1 -> Intermediate 2 -> Leaf >> >> Where: >> * All certs are in admin domain kSecTrustSettingsDomainAdmin >> * Root CA is marked as always trust >> * Intermediate 1 and 2 are Unspecified >> >> Previously Root CA would be found but intermediate 1 and 2 would be skipped when verifying trust settings. >> >> ## Background reading >> >> ### Rust >> see also Rust Lib that is used throughout Rust ecosystem for this: >> https://github.com/rustls/rustls-native-certs/blob/efe7b1d77bf6080851486535664d1dc7ef0dea68/src/macos.rs#L39-L58 >> >> e.g. in Deno `https://github.com/denoland/deno/pull/11491` where I've verified it is correctly implemented and works in my setup >> >> ## Python >> >> I also looked at the Python implementation for inspiration as well (which also works on my system): https://github.com/sethmlarson/truststore/blob/main/src/truststore/_macos.py > > Tim Jacomb has updated the pull request incrementally with one additional commit since the last revision: > > Make test output easier to read I am dubious that this is the right thing to do. There is a distinct difference between a certificate that is trusted and one that requires additional validation to determine if it is trusted. Blindly trusting self-signed certificates is very dangeorous, and unless I am mistaken, this seems to be what this code may do. I do not think lumping both of these certificates into "trusted" certificates is the right thing to do. It may mean that we need to enhance the `KeyStore` API to be able to store arbitrary certificates. Or you could consider storing these additional certificates in a `CertStore`. I am also not sure the use case is common. Typically a web server will send its entire chain, and not just the server certificate. Certainly open to hearing alternate opinions if I have overlooked something. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2769754872 From duke at openjdk.org Tue Apr 1 16:16:27 2025 From: duke at openjdk.org (Tim Jacomb) Date: Tue, 1 Apr 2025 16:16:27 GMT Subject: RFR: 8347067: Load certificates without explicit trust settings in KeyChainStore [v5] In-Reply-To: References: Message-ID: <2lESj2GQZ789FVYUcpWKs8NS54e2T9EGafkTfjRIDK8=.ccff1b5c-0ab3-4079-b035-6c5f4bf9209b@github.com> On Tue, 1 Apr 2025 15:25:45 GMT, Sean Mullan wrote: > I am dubious that this is the right thing to do. There is a distinct difference between a certificate that is trusted and one that requires additional validation to determine if it is trusted. Blindly trusting self-signed certificates is very dangeorous, and unless I am mistaken, this seems to be what this code may do. I do not think lumping both of these certificates into "trusted" certificates is the right thing to do. There is no 'blind' trust in this pull request. Any 'non trusted' certificate is validated via the OS APIs, once it has been validated by the OS then it is a trusted certificate it just needed its chain verified to the root. https://github.com/openjdk/jdk/pull/22911/files#diff-b0b2f959f0fa18e568c0688bd233882283bca94f4ff6dce886a21510ff82d64dR475 https://github.com/timja/jdk/blob/59ceebc4acf2c39c86c45b1aa6746bf619417cea/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m#L475 > It may mean that we need to enhance the `KeyStore` API to be able to store arbitrary certificates. Or you could consider storing these additional certificates in a `CertStore`. The `KeyStore` can store them arbitrarily right now can't it but is it that currently anything in there is 'trusted'? > > I am also not sure the use case is common. Typically a web server will send its entire chain, and not just the server certificate. I don't think its very common either but I think its becoming more common with ZTNA providers (Zero Trust Network Access) being deployed in a lot of organisations for compliance and security reasons. When these are third party providers they often won't have your root cert and they may or may not provide the complete chain (I don't know if its configurable to do that) my organisation's one certainly doesn't provide the whole chain and there are other bug reports out there from other organisations too. > Certainly open to hearing alternate opinions if I have overlooked something. An alternative option would be a truststore or some other mechanism that just does [SecTrustEvaluateWithError](https://developer.apple.com/documentation/security/sectrustevaluatewitherror(_:_:)?language=objc) without any of the complexity of providing the actual certificates but just checks the trust for the presented chain. Not sure how complex that would be. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2769893831 From duke at openjdk.org Tue Apr 1 16:47:13 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 1 Apr 2025 16:47:13 GMT Subject: RFR: 8349890 : option -Djava.security.debug=x509,ava breaks special chars Message-ID: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> **A DESCRIPTION OF THE PROBLEM :** Enabling -Djava.security.debug=x509,ava affects how special characters in certificates are processed. The expected behavior is that debugging should not interfere with the normal encoding of certificate fields. **Fix:** The Debugging will no longer interfere with these fields, unless you call toString(). ------------- Commit messages: - 8349890:option -Djava.security.debug=x509,ava breaks special chars - 8349890: option -Djava.security.debug=x509,ava breaks special chars Changes: https://git.openjdk.org/jdk/pull/24360/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24360&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349890 Stats: 76 lines in 2 files changed: 58 ins; 14 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24360/head:pull/24360 PR: https://git.openjdk.org/jdk/pull/24360 From duke at openjdk.org Tue Apr 1 16:54:25 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 1 Apr 2025 16:54:25 GMT Subject: RFR: 8349890 : Option -Djava.security.debug=x509,ava breaks special chars [v2] In-Reply-To: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> References: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> Message-ID: <56u4NzI3lkDW6FJde_kVwNxM4622Sp_dSRxr8bj5uKM=.afa58513-6dc8-4254-8db5-d1122d3a8fc3@github.com> > **A DESCRIPTION OF THE PROBLEM :** > Enabling -Djava.security.debug=x509,ava affects how special characters in certificates are processed. The expected behavior is that debugging should not interfere with the normal encoding of certificate fields. > > **Fix:** > The Debugging will no longer interfere with these fields, unless you call toString(). Koushik Muthukrishnan Thirupattur has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8349890: option -Djava.security.debug=x509,ava breaks special chars ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24360/files - new: https://git.openjdk.org/jdk/pull/24360/files/0fdfaca6..1096d02b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24360&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24360&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24360/head:pull/24360 PR: https://git.openjdk.org/jdk/pull/24360 From mullan at openjdk.org Tue Apr 1 17:32:21 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 1 Apr 2025 17:32:21 GMT Subject: RFR: 8347067: Load certificates without explicit trust settings in KeyChainStore [v5] In-Reply-To: <2lESj2GQZ789FVYUcpWKs8NS54e2T9EGafkTfjRIDK8=.ccff1b5c-0ab3-4079-b035-6c5f4bf9209b@github.com> References: <2lESj2GQZ789FVYUcpWKs8NS54e2T9EGafkTfjRIDK8=.ccff1b5c-0ab3-4079-b035-6c5f4bf9209b@github.com> Message-ID: On Tue, 1 Apr 2025 16:13:55 GMT, Tim Jacomb wrote: > > I am dubious that this is the right thing to do. There is a distinct difference between a certificate that is trusted and one that requires additional validation to determine if it is trusted. Blindly trusting self-signed certificates is very dangeorous, and unless I am mistaken, this seems to be what this code may do. I do not think lumping both of these certificates into "trusted" certificates is the right thing to do. > > There is no 'blind' trust in this pull request. Any 'non trusted' certificate is validated via the OS APIs, once it has been validated by the OS then it is a trusted certificate it just needed its chain verified to the root. That helps, but just because it successfully validated once does not mean it should be treated as a trusted certificate (essentially as a trust anchor). It may later be revoked/expired, its key or signature algorithm may weaken or it may fail validation for some other reason, or CA certificates further up the chain may change and affect the trustworthiness of this certificate. > > It may mean that we need to enhance the `KeyStore` API to be able to store arbitrary certificates. Or you could consider storing these additional certificates in a `CertStore`. > > The `KeyStore` can store them arbitrarily right now can't it but is it that currently anything in there is 'trusted'? > > > I am also not sure the use case is common. Typically a web server will send its entire chain, and not just the server certificate. > > I don't think its very common either but I think its becoming more common with ZTNA providers (Zero Trust Network Access) being deployed in a lot of organisations for compliance and security reasons. > > When these are third party providers they often won't have your root cert and they may or may not provide the complete chain (I don't know if its configurable to do that) my organisation's one certainly doesn't provide the whole chain and there are other bug reports out there from other organisations too. > > > Certainly open to hearing alternate opinions if I have overlooked something. > > An alternative option would be a truststore or some other mechanism that just does [SecTrustEvaluateWithError](https://developer.apple.com/documentation/security/sectrustevaluatewitherror(_:_:)?language=objc) without any of the complexity of providing the actual certificates but just checks the trust for the presented chain. Not sure how complex that would be. I think at this point if this is important enough we would need to explore other options. I haven't had time to really think about the different use cases you mention above, but providing more rationale and pointers to issues where users are having issues with Java because of this issue would help. Thanks, Sean ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2770193958 From abakhtin at openjdk.org Tue Apr 1 18:35:25 2025 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Tue, 1 Apr 2025 18:35:25 GMT Subject: RFR: 8347067: Load certificates without explicit trust settings in KeyChainStore [v5] In-Reply-To: References: <2lESj2GQZ789FVYUcpWKs8NS54e2T9EGafkTfjRIDK8=.ccff1b5c-0ab3-4079-b035-6c5f4bf9209b@github.com> Message-ID: On Tue, 1 Apr 2025 17:29:57 GMT, Sean Mullan wrote: > > > I am dubious that this is the right thing to do. There is a distinct difference between a certificate that is trusted and one that requires additional validation to determine if it is trusted. Blindly trusting self-signed certificates is very dangeorous, and unless I am mistaken, this seems to be what this code may do. I do not think lumping both of these certificates into "trusted" certificates is the right thing to do. > > > > > > There is no 'blind' trust in this pull request. Any 'non trusted' certificate is validated via the OS APIs, once it has been validated by the OS then it is a trusted certificate it just needed its chain verified to the root. > > > > That helps, but just because it successfully validated once does not mean it should be treated as a trusted certificate (essentially as a trust anchor). It may later be revoked/expired, its key or signature algorithm may weaken or it may fail validation for some other reason, or CA certificates further up the chain may change and affect the trustworthiness of this certificate. Exactly the same happens with other certificates with trust settings. They are loaded on start and not verified for trust settings later. They are still trusted, If the Trust Settings are updated manually in the native KeyChainStore. Also, it affects KeychainStore only and does not affect KeychainStore-ROOT certificates, as it is static. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2770352993 From duke at openjdk.org Tue Apr 1 18:41:28 2025 From: duke at openjdk.org (Bernd) Date: Tue, 1 Apr 2025 18:41:28 GMT Subject: RFR: 8347067: Load certificates without explicit trust settings in KeyChainStore [v5] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:43:32 GMT, Tim Jacomb wrote: >> ## The change >> >> Without this change intermediate certificates that don't have explicit trust settings are ignored not added to the truststore. >> >> >> >> ## Reproducer >> >> See https://github.com/timja/openjdk-intermediate-ca-reproducer >> >> Without this change the reproducer fails, and with this change it succeeds. >> >> ## Example failing architecture >> >> Root CA -> Intermediate 1 -> Intermediate 2 -> Leaf >> >> Where: >> * All certs are in admin domain kSecTrustSettingsDomainAdmin >> * Root CA is marked as always trust >> * Intermediate 1 and 2 are Unspecified >> >> Previously Root CA would be found but intermediate 1 and 2 would be skipped when verifying trust settings. >> >> ## Background reading >> >> ### Rust >> see also Rust Lib that is used throughout Rust ecosystem for this: >> https://github.com/rustls/rustls-native-certs/blob/efe7b1d77bf6080851486535664d1dc7ef0dea68/src/macos.rs#L39-L58 >> >> e.g. in Deno `https://github.com/denoland/deno/pull/11491` where I've verified it is correctly implemented and works in my setup >> >> ## Python >> >> I also looked at the Python implementation for inspiration as well (which also works on my system): https://github.com/sethmlarson/truststore/blob/main/src/truststore/_macos.py > > Tim Jacomb has updated the pull request incrementally with one additional commit since the last revision: > > Make test output easier to read Isnt that the Same for Windows? Not all Stores are explicitely trusted, some contain intermediate certificates. It would certainly be helpful to reflect trust in Keystore API (if only to not Trust the ones which are not marked as such). For example CurrentUser\Root or LocalMachine\CA are such Locations which could ne marking as trusted/not trusted respektively. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2770364398 From vpaprotski at openjdk.org Tue Apr 1 18:47:39 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Tue, 1 Apr 2025 18:47:39 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v12] In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 14:40:56 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reacting to comments by Volodymyr. No further comments from me. (I did leave two questions, but nothing that requires code changes) Thanks for addressing all my many (lengthy) comments and questions. And the refactor! ------------- Marked as reviewed by vpaprotski (Author). PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2723440925 From vpaprotski at openjdk.org Tue Apr 1 18:47:39 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Tue, 1 Apr 2025 18:47:39 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11] In-Reply-To: References: Message-ID: On Sat, 22 Mar 2025 20:02:31 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Further readability improvements. > - Added asserts for array sizes src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 342: > 340: // Performs two keccak() computations in parallel. The steps of the > 341: // two computations are executed interleaved. > 342: static address generate_double_keccak(StubGenerator *stubgen, MacroAssembler *_masm) { This function seems ok. I didnt do as line-by-line 'exact' review as for the NTT intrinsics, but just put the new version into a diff next to the original function. Seems like a reasonable clean 'refactor' (hardcode the blocksize, add new input registers 10-14. Makes it really easy to spot vs 0-4 original registers..) I didnt realize before that the 'top 3 limbs' are wasted. I guess it doesnt matter, there are registers to spare aplenty and it makes the entire algorithm cleaner and easier to follow. I did also stare at the algorithm with the 'What about AVX2' question.. This function would pretty much need to be rewritten it looks like :/ Last two questions.. - how much performance is gained from doubling this function up? - If thats worth it.. what if instead it was quadrupled the input? (I scanned the java code, it looked like NR was parametrized already to 2..). It looks like there are almost enough registers here to go to 4 (I think 3 would need to be freed up somehow.. alternatively, the upper 3 limbs are empty in all operations, perhaps it could be used instead.. at the expense of readability) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2017636762 From mullan at openjdk.org Tue Apr 1 19:26:27 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 1 Apr 2025 19:26:27 GMT Subject: RFR: 8347067: Load certificates without explicit trust settings in KeyChainStore [v5] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:43:32 GMT, Tim Jacomb wrote: >> ## The change >> >> Without this change intermediate certificates that don't have explicit trust settings are ignored not added to the truststore. >> >> >> >> ## Reproducer >> >> See https://github.com/timja/openjdk-intermediate-ca-reproducer >> >> Without this change the reproducer fails, and with this change it succeeds. >> >> ## Example failing architecture >> >> Root CA -> Intermediate 1 -> Intermediate 2 -> Leaf >> >> Where: >> * All certs are in admin domain kSecTrustSettingsDomainAdmin >> * Root CA is marked as always trust >> * Intermediate 1 and 2 are Unspecified >> >> Previously Root CA would be found but intermediate 1 and 2 would be skipped when verifying trust settings. >> >> ## Background reading >> >> ### Rust >> see also Rust Lib that is used throughout Rust ecosystem for this: >> https://github.com/rustls/rustls-native-certs/blob/efe7b1d77bf6080851486535664d1dc7ef0dea68/src/macos.rs#L39-L58 >> >> e.g. in Deno `https://github.com/denoland/deno/pull/11491` where I've verified it is correctly implemented and works in my setup >> >> ## Python >> >> I also looked at the Python implementation for inspiration as well (which also works on my system): https://github.com/sethmlarson/truststore/blob/main/src/truststore/_macos.py > > Tim Jacomb has updated the pull request incrementally with one additional commit since the last revision: > > Make test output easier to read We need to be really careful here. With this fix we are deciding at runtime that these intermediate certificates should be treated as `KeyStore.TrustedCertificateEntry` objects just because they validated ok, and without any interaction with the user or application. Also, the JDK does not rely on certificate chain validation from the OS. The JDK has its own PKIX `CertPathValidator` implementation and has its own restrictions on weak algorithms, etc which is a key part of establishing trust in certificates used in TLS, signed JARs, etc. You are now delegating this to MacOS as a mostly invisible change which brings in a new set of security concerns which may make it less secure or at a minimum requires resources to ensure this code is properly reviewed, audited, etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2770471055 From abarashev at openjdk.org Tue Apr 1 20:59:06 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 1 Apr 2025 20:59:06 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 signatures Message-ID: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). https://www.rfc-editor.org/rfc/rfc9155.html ------------- Commit messages: - Unit tests - Merge branch 'master' into JDK-8340321_disable - 8340321: Disable SHA-1 in TLS/DTLS 1.2 signatures Changes: https://git.openjdk.org/jdk/pull/24367/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24367&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340321 Stats: 176 lines in 3 files changed: 175 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24367.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24367/head:pull/24367 PR: https://git.openjdk.org/jdk/pull/24367 From skuksenko at openjdk.org Tue Apr 1 21:50:47 2025 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Tue, 1 Apr 2025 21:50:47 GMT Subject: RFR: 8353478: Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms Message-ID: Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms. ------------- Commit messages: - Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms Changes: https://git.openjdk.org/jdk/pull/24369/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24369&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353478 Stats: 1938 lines in 10 files changed: 210 ins; 1696 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/24369.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24369/head:pull/24369 PR: https://git.openjdk.org/jdk/pull/24369 From sviswanathan at openjdk.org Tue Apr 1 23:11:45 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 1 Apr 2025 23:11:45 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v12] In-Reply-To: References: Message-ID: On Mon, 31 Mar 2025 14:40:56 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reacting to comments by Volodymyr. src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 359: > 357: __ kmovbl(k4, rax); > 358: __ addl(rax, 16); > 359: __ kmovbl(k5, rax); We could use the sequence from generate_sha3_implCompress to setup the K registers, that has less dependency: __ movl(rax, 0x1F); __ kmovbl(k5, rax); __ kshiftrbl(k4, k5, 1); __ kshiftrbl(k3, k5, 2); __ kshiftrbl(k2, k5, 3); __ kshiftrbl(k1, k5, 4); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2023769620 From duke at openjdk.org Wed Apr 2 07:38:34 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 2 Apr 2025 07:38:34 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13] In-Reply-To: References: Message-ID: > By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Reacting to comment by Sandhya. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23860/files - new: https://git.openjdk.org/jdk/pull/23860/files/7a9f6645..e4ab10bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=11-12 Stats: 10 lines in 1 file changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23860.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860 PR: https://git.openjdk.org/jdk/pull/23860 From duke at openjdk.org Wed Apr 2 07:45:14 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 2 Apr 2025 07:45:14 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v12] In-Reply-To: References: Message-ID: <_3aVrAsKu82hHiEvG-gkLScqZrm-7M6nDo6vcA7EHds=.19728142-3151-462d-95ea-bdbc36c236a7@github.com> On Tue, 1 Apr 2025 22:43:36 GMT, Sandhya Viswanathan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Reacting to comments by Volodymyr. > > src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 359: > >> 357: __ kmovbl(k4, rax); >> 358: __ addl(rax, 16); >> 359: __ kmovbl(k5, rax); > > We could use the sequence from generate_sha3_implCompress to setup the K registers, that has less dependency: > > __ movl(rax, 0x1F); > __ kmovbl(k5, rax); > __ kshiftrbl(k4, k5, 1); > __ kshiftrbl(k3, k5, 2); > __ kshiftrbl(k2, k5, 3); > __ kshiftrbl(k1, k5, 4); Thanks! (I had copied/doubled this function from the single state version before you made me do this change on that one and I forgot to update the copy :-) ) Changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2024255339 From duke at openjdk.org Wed Apr 2 08:22:22 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 2 Apr 2025 08:22:22 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11] In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 21:42:08 GMT, Volodymyr Paprotski wrote: >> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: >> >> - Further readability improvements. >> - Added asserts for array sizes > > src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 342: > >> 340: // Performs two keccak() computations in parallel. The steps of the >> 341: // two computations are executed interleaved. >> 342: static address generate_double_keccak(StubGenerator *stubgen, MacroAssembler *_masm) { > > This function seems ok. I didnt do as line-by-line 'exact' review as for the NTT intrinsics, but just put the new version into a diff next to the original function. Seems like a reasonable clean 'refactor' (hardcode the blocksize, add new input registers 10-14. Makes it really easy to spot vs 0-4 original registers..) > > I didnt realize before that the 'top 3 limbs' are wasted. I guess it doesnt matter, there are registers to spare aplenty and it makes the entire algorithm cleaner and easier to follow. > > I did also stare at the algorithm with the 'What about AVX2' question.. This function would pretty much need to be rewritten it looks like :/ > > Last two questions.. > - how much performance is gained from doubling this function up? > - If thats worth it.. what if instead it was quadrupled the input? (I scanned the java code, it looked like NR was parametrized already to 2..). It looks like there are almost enough registers here to go to 4 (I think 3 would need to be freed up somehow.. alternatively, the upper 3 limbs are empty in all operations, perhaps it could be used instead.. at the expense of readability) Well, the algorithm (keccak()) is doing the same things on 5 array elements (It works on essentially a 5x5 matrix doing row and column operations, so putting 5 array entries in a vector register was the "natural" thing to do). This function can only be used under very special circumstances, which occur during the generation of tha "A matrix" in ML-KEM and ML-DSA, the speed of that matrix generation has almost doubled (I don't have exact numbers). We are using 7 registers per state and 15 for the constants, so we have only 3 to spare. We could perhaps juggle with the constants keeping just the ones that will be needed next in registers and reloading them "just in time", but that might slow things down a bit - more load instructions executed + maybe some load delay. On the other hand, more parallelism. I might try it out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2024317665 From mdonovan at openjdk.org Wed Apr 2 13:02:54 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 2 Apr 2025 13:02:54 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 signatures In-Reply-To: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> Message-ID: On Tue, 1 Apr 2025 20:53:01 GMT, Artur Barashev wrote: > Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). > https://www.rfc-editor.org/rfc/rfc9155.html test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureDTLS12.java line 34: > 32: */ > 33: > 34: import java.lang.Override; You shouldn't have to import java.lang.Override test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS12.java line 37: > 35: import static jdk.test.lib.Asserts.assertTrue; > 36: > 37: import java.lang.Override; unnecessary import ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24367#discussion_r2024764557 PR Review Comment: https://git.openjdk.org/jdk/pull/24367#discussion_r2024766076 From forax at univ-mlv.fr Wed Apr 2 14:33:57 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Apr 2025 16:33:57 +0200 (CEST) Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) In-Reply-To: References: Message-ID: <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr> Hi Per, last week, at JChateau, we had a one hour session about stable values, I've build the JDK with this PR so we can discuss about it. To present the API, i start from the double check locking, rewriting it to use the StableValue API. The main remark was that methods like orElseSet() or isSet() are hard to used correctly. In my opinion, the current API is a mix of a high level API and a low-level API but it's too easy to misuse the low-level API. high level: - methods supplier(), list() and map() Those are easy to use low level: - methods: of, of(value), orElseSet, setOrThrow(), etc Those are hard to use properly. I think, not necessary in this PR, that the current API should be separated into two different classes, one in java.lang with the high level API (the static methods other than Of() and one in java.util.concurrent with the low level API where you have to know what you are doing (like with any classes of java.util.concurrent). regards, R?mi ----- Original Message ----- > From: "Per Minborg" > To: "compiler-dev" , "core-libs-dev" , "hotspot-dev" > , "security-dev" > Sent: Thursday, March 13, 2025 12:20:10 PM > Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) > Implement JEP 502. > > The PR passes tier1-tier3 tests. > > ------------- > > Commit messages: > - Use acquire semantics for reading rather than volatile semantics > - Add missing null check > - Simplify handling of sentinel, wrap, and unwrap > - Fix JavaDoc issues > - Fix members in StableEnumFunction > - Address some comments in the PR > - Merge branch 'master' into implement-jep502 > - Revert change > - Fix copyright issues > - Update JEP number > - ... and 231 more: https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6 > > Changes: https://git.openjdk.org/jdk/pull/23972/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8351565 > Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod > Patch: https://git.openjdk.org/jdk/pull/23972.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 > > PR: https://git.openjdk.org/jdk/pull/23972 From duke at openjdk.org Wed Apr 2 15:02:57 2025 From: duke at openjdk.org (Tim Jacomb) Date: Wed, 2 Apr 2025 15:02:57 GMT Subject: RFR: 8347067: Load certificates without explicit trust settings in KeyChainStore [v5] In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 19:23:27 GMT, Sean Mullan wrote: > We need to be really careful here. With this fix we are deciding at runtime that these intermediate certificates should be treated as `KeyStore.TrustedCertificateEntry` objects just because they validated ok, and without any interaction with the user or application. > Also, the JDK does not rely on certificate chain validation from the OS. The JDK has its own PKIX `CertPathValidator` implementation and has its own restrictions on weak algorithms, etc which is a key part of establishing trust in certificates used in TLS, signed JARs, etc. You are now delegating this to MacOS as a mostly invisible change which brings in a new set of security concerns which may make it less secure or at a minimum requires resources to ensure this code is properly reviewed, audited, etc. This isn't being delegated to macOS anymore so than it already was, trust settings are still checked as the OS does not validate non trusted certificates, this is just in `KeychainStore` which is opt-in only. `CertPathValidator` is still used in finding the path and I assume could still veto weak algorithms etc. It would be good if it did check the path and not assume all certificates are Trusted Roots. Yes, exactly the same on Windows, I implemented it in node.js here: https://github.com/nodejs/node/pull/57164 (node's certificate validation does check the path) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2772856681 From abarashev at openjdk.org Wed Apr 2 16:00:58 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 2 Apr 2025 16:00:58 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures In-Reply-To: References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> Message-ID: On Wed, 2 Apr 2025 12:51:42 GMT, Matthew Donovan wrote: >> Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). >> https://www.rfc-editor.org/rfc/rfc9155.html > > test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureDTLS12.java line 34: > >> 32: */ >> 33: >> 34: import java.lang.Override; > > You shouldn't have to import java.lang.Override Indeed, thanks! For some reason my IntelliJ inserts this import on "Optimize Imports" command, I need to find out why. > test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS12.java line 37: > >> 35: import static jdk.test.lib.Asserts.assertTrue; >> 36: >> 37: import java.lang.Override; > > unnecessary import Replied above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24367#discussion_r2025147866 PR Review Comment: https://git.openjdk.org/jdk/pull/24367#discussion_r2025148344 From mbalao at openjdk.org Wed Apr 2 16:47:51 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 16:47:51 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Tue, 25 Feb 2025 19:40:24 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 2158: > >> 2156: hasKeyAttributes = null; >> 2157: supportedFormats = null; >> 2158: supportedClasses = null; > > Are these necessary? The other constructor didn't set them. We made these fields initialization explicit in the copy-constructor to document that cached fields need to be regenerated, and it's not that we forgot (or were added later). That's why we added the comment in the lines before. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025222786 From mbalao at openjdk.org Wed Apr 2 17:03:50 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 17:03:50 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Tue, 25 Feb 2025 19:45:47 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 2149: > >> 2147: attributes = new HashMap<>(svc.attributes); >> 2148: } >> 2149: registered = false; > > I didn't see it's set to `true` in any of the constructors; also the default value is already `false`, why only explicitly set it to `false` here? The value in this case could have been `true` as this constructor is only used when doing a copy-on-write from a service that is registered already in the map (the new/updated service will be in the map as well). We preferred to do this at the caller level. We can remove this explicit assignment from here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025247755 From fferrari at openjdk.org Wed Apr 2 17:32:55 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Wed, 2 Apr 2025 17:32:55 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Tue, 25 Feb 2025 23:49:41 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 2202: > >> 2200: "Attribute value expected to exist with the same identity."; >> 2201: attributes.remove(attrKey, attrValue); >> 2202: } > > Is the new impl assuming `attrValue` should never be `null`? Based on javadoc of `Map.remove(Object key, Object value)`, the new impl removes the entry when the associated value is `null` vs the original impl removes the entry regardless of the associated value. Yes, the new implementation assumes `attrValue` isn't `null`. For cases in which the old implementation was receiving `null`, the new implementation receives `oldValue`, from `Provider::implRemove`: https://github.com/openjdk/jdk/blob/3d0df51b634e02e95ee66c4121460e8fe6b9d9be/src/java.base/share/classes/java/security/Provider.java#L1535-L1539 This is also asserted as `attrValue != null` in `Provider.ServicesMap::removeAttributeLegacy`, the caller of `Service::removeAttribute`: https://github.com/openjdk/jdk/blob/3d0df51b634e02e95ee66c4121460e8fe6b9d9be/src/java.base/share/classes/java/security/Provider.java#L1319-L1329 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025285785 From jbhateja at openjdk.org Wed Apr 2 18:24:55 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 2 Apr 2025 18:24:55 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 07:38:34 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reacting to comment by Sandhya. @ferakocz , I verified new version of patch on Linux and windows and it works fine. Thanks for addressing my comments. ------------- Marked as reviewed by jbhateja (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2737186292 From mbalao at openjdk.org Wed Apr 2 18:58:55 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 18:58:55 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Wed, 26 Feb 2025 00:21:48 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 2078: > >> 2076: // entries derive from the aliases field, keys are not repeated >> 2077: // (case-insensitive comparison) and not equal to the algorithm. For >> 2078: // services (still) not added to a ServicesMap, value is an empty map. > > Could we re-write it to summarize the conditions for empty map? It could be easier to read/understand. > For example: empty map if no aliases or if this service is not yet added to a `ServiceMap`. > The part of case-insensitive comparision, it's due to the impl of `ServiceKey`, right? Maybe we can simply refer to that no need to describe it here. We will re-write this comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025412796 From weijun.wang at oracle.com Wed Apr 2 19:00:22 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Wed, 2 Apr 2025 19:00:22 +0000 Subject: New JEP Draft: Key Derivation Function API Message-ID: Hi all, JEP 478: Key Derivation Function API (Preview) [1] was included in JDK 24. We propose to finalize it in JDK 25 without modification. The new JEP is available at https://openjdk.org/jeps/8353275. Since JDK 24, a PKCS #11 implementation of HKDF [2] has been integrated into an early build of JDK 25, and several in-progress efforts are using the preview API as-is: 1. A refactoring of the DH-Based Key Encapsulation Mechanism (DHKEM) [3] in its ExtractAndExpand step. 2. An implementation of Hybrid Public Key Encryption (HPKE) [4] in its key schedule setup and secret export. 3. A TLS 1.3 refactoring [5] in its key derivation process. There has been no feedback suggesting changes to the API. The current set of integrations and refactorings demonstrates that the API is capable and flexible enough to support a variety of use cases as designed. We welcome your feedback on the proposal. Thanks, Weijun [1] https://openjdk.org/jeps/478 [2] https://bugs.openjdk.org/browse/JDK-8328119 [3] https://github.com/openjdk/jdk/pull/18411/files#diff-f92a5f15c7a2657b5b7e07d3b129ac7e483a25e35982a803fb137e31b4f9211f [4] https://github.com/openjdk/jdk/pull/18411 [5] https://github.com/openjdk/jdk/pull/23974 From mbalao at openjdk.org Wed Apr 2 20:04:55 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 20:04:55 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Wed, 26 Feb 2025 00:26:43 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 2071: > >> 2069: // For services added to a ServicesMap, their algorithm service key. >> 2070: // This value derives from the algorithm field. For services (still) >> 2071: // not added to a ServicesMap, value is null. > > The current comment is a bit hard to read. > How about "The mapping key of this service when added to a `ServiceMap`; null if not yet added to a `ServiceMap`"? > The value is derived from the type and algorithm and this is straightforward enough that probably need not be commented. Comment re-written. > src/java.base/share/classes/java/security/Provider.java line 2110: > >> 2108: >> 2109: /* >> 2110: * Constructor used from the ServicesMap Legacy API. > > nit: "used **by**"? Same goes for other places. Good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025502125 PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025503163 From mbalao at openjdk.org Wed Apr 2 20:08:56 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 20:08:56 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: <95KZA0F3g6tnJBJsJreuVcsQIClnqggOSDmsk2ZTNjI=.652d4a8f-ed2e-45b2-9cc8-1e2eb1422cf7@github.com> On Wed, 26 Feb 2025 00:45:13 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 2268: > >> 2266: } >> 2267: } >> 2268: aliasKeys = Collections.unmodifiableMap(aliasKeys); > > if `aliases` are empty, then we can skip line 2261-2268 and no need to update `aliasKeys`? Good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025508086 From mbalao at openjdk.org Wed Apr 2 20:12:56 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 20:12:56 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Wed, 26 Feb 2025 00:50:39 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 2256: > >> 2254: * keys with Service::addAliasKey. >> 2255: */ >> 2256: private void generateServiceKeys() { > > nit: move this private method to be with other private methods? Ok, but public and private methods in the class look interleaved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025512604 From mbalao at openjdk.org Wed Apr 2 20:17:00 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 20:17:00 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Wed, 26 Feb 2025 01:09:55 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 1654: > >> 1652: } >> 1653: >> 1654: // used as key in the serviceMap and legacyMap HashMaps > > This comment is obsolete with the new impl and should be updated. True. I'll remove the comment as it's used in many places. The comment was not adding much anyways and it is not worth it keeping it in sync. It's easier to just look uses of the class in the same file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025520475 From mbalao at openjdk.org Wed Apr 2 20:22:55 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 20:22:55 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Wed, 26 Feb 2025 01:44:26 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 735: > >> 733: // with the Legacy API. The absence of a service key on this set is an >> 734: // indication that the service was either not added or added with the >> 735: // Current API. Only algorithm service keys are added to this set. > > nit: I find the sentence "The absence of a service key on this set ... added with Current API" is somewhat redundant. I suppose you mean "not added with the Legacy API or added with the Current API". The first sentence is clear enough and the second sentence doesn't add much value. It could be that the service was not registered in the ServicesMap (any API) or was registered with the Current API. I made a minor change to the comment to stress the difference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025528391 From mbalao at openjdk.org Wed Apr 2 20:25:54 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 20:25:54 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Wed, 26 Feb 2025 01:56:58 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 750: > >> 748: private final Map> serviceAttrProps; >> 749: >> 750: ServicesMap() { > > nit: add comment for this constructor? Ok, I'll add a note. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025536940 From weijun at openjdk.org Wed Apr 2 20:35:29 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 2 Apr 2025 20:35:29 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v14] In-Reply-To: References: Message-ID: > Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. > ![HPKEParameterSpec](https://github.com/user-attachments/assets/8cc7101b-92d1-43be-b7b4-24a7ba449231) Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: - put encapsulation in params from getParameters - receiver must specify all algorithm identifiers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18411/files - new: https://git.openjdk.org/jdk/pull/18411/files/c578ef5d..0796a423 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=12-13 Stats: 235 lines in 6 files changed: 54 ins; 110 del; 71 mod Patch: https://git.openjdk.org/jdk/pull/18411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 PR: https://git.openjdk.org/jdk/pull/18411 From mbalao at openjdk.org Wed Apr 2 20:53:53 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 20:53:53 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Mon, 3 Mar 2025 23:24:29 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 713: > >> 711: */ >> 712: private record MappingInfo(Service svc, ServiceKey algKey, >> 713: Boolean isLegacy) {} > > There is comment states that `isLegacy` may be null, but then I also see a few if-cond using `isLegacy` directly like its a boolean, wouldn't it lead to NPE if `isLegacy` is `null`? `isLegacy` is null when the service was never added to the ServicesMap and the Current vs. Legacy API question does not apply. In these cases, the `MappingInfo` record returned by `find` has a null service too, indicating that the query did not find the service. For a caller, this case reads as the `isLegacy` value of a not found service, and will be ignored. You can check how all uses of `.isLegacy` are in a conditional block where `.svc` is not null or in a method where we have that pre-condition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025577715 From weijun at openjdk.org Wed Apr 2 20:59:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 2 Apr 2025 20:59:51 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v14] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 20:35:29 GMT, Weijun Wang wrote: >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >> ![HPKEParameterSpec](https://github.com/user-attachments/assets/8cc7101b-92d1-43be-b7b4-24a7ba449231) > > Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: > > - put encapsulation in params from getParameters > - receiver must specify all algorithm identifiers Now receiver must provide all algorithm identifiers at cipher initialization. Calling `getParameters` on sender side returns an `AlgorithmParameters` object which contains the actual `HPKEParameterSpec` object used even the key encapsulation message (this message is still retrievable from `getIV`). In a real world application, the sender would typically retrieve the `kem_id`, `kdf_id`, `aead_id`, key encapsulation message, (optionally) `psk_id`, and whether an auth-key is used from it, and send these to the receiver. There is no byte array encoding of these information defined yet. Maybe there will be one when HPKE is used in CMS. That said, even if there is one, it probably cannot be used to recover a whole `HPKEParameterSpec` object directly, as sensitive data like psk and auth-key are not likely to be included. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18411#issuecomment-2773722258 From mbalao at openjdk.org Wed Apr 2 21:14:50 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 21:14:50 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Tue, 4 Mar 2025 01:55:06 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 988: > >> 986: // The service was added with the Current API. Overwrite >> 987: // the alias entry on the services map without modifying >> 988: // the service that is currently using it. > > Is the "service" in the above line really means the provider `service` entry? If so, may be "associated with" is better than "using". Also there is no code under this comment block, where is the action of "overwrite the alias entry on the services map"? Yes, "associated with" is better. The overwrite happens later in `putService`. I'll clarify that in the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025612169 From mbalao at openjdk.org Wed Apr 2 21:20:55 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 2 Apr 2025 21:20:55 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> Message-ID: On Wed, 5 Mar 2025 01:02:15 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 1125: > >> 1123: if (oldMi.svc != null) { >> 1124: // The service exists. Get its Properties map entry. Note: >> 1125: // Services added through an alias or an attribute may don't > > "may don't"? Maybe you mean "may not" or simply "don't" Good catch. I'd go with "may not" because they have have been added without and later obtained one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025618797 From valeriep at openjdk.org Wed Apr 2 21:52:03 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 2 Apr 2025 21:52:03 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API Message-ID: This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. Thanks in advance for the review~ ------------- Commit messages: - 8353578: Refactor existing usage of internal HKDF impl to use the KDF API Changes: https://git.openjdk.org/jdk/pull/24393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353578 Stats: 599 lines in 14 files changed: 53 ins; 480 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/24393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24393/head:pull/24393 PR: https://git.openjdk.org/jdk/pull/24393 From weijun at openjdk.org Wed Apr 2 23:24:49 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 2 Apr 2025 23:24:49 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 21:43:19 GMT, Valerie Peng wrote: > This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. > > This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. > > Thanks in advance for the review~ src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 120: > 118: SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret", > 119: HKDFParameterSpec.ofExtract().addSalt(zeros) > 120: .addIKM(ikm).extractOnly()); Maybe no need for `addSalt(zeros)`. I remember salt is by default zeros for HKDF. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2025733194 From mbalao at openjdk.org Thu Apr 3 00:30:50 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 3 Apr 2025 00:30:50 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Tue, 4 Mar 2025 01:59:58 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 1037: > >> 1035: } >> 1036: >> 1037: if (mi.isLegacy) { > > For legacy entry, there is no check on the `legacyApiCall` value, is this due to the call path from `resolveKeyConflict` method? However, should a legacy entry be removed by the `removeService` method? If not, then additional check may be needed? There is no check because entries added with the Legacy API can be removed (i.e. overwritten) with entries added with the Current API. Current API operations take precedence. Looks like someone can invoke `removeService` with a Service instance whose algorithm was added with the Legacy API and the code is not stopping this removal. May be a good idea to stop this. @franferrax , what do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025816338 From mbalao at openjdk.org Thu Apr 3 00:33:52 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 3 Apr 2025 00:33:52 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> Message-ID: On Wed, 5 Mar 2025 01:40:55 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 1370: > >> 1368: * Algorithm and alias based entries pointing to the old version of the >> 1369: * service are overwritten. >> 1370: */ > > Comment for this method should note that this method is only for the Legacy registration... Sounds good. I added a note. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025818389 From mbalao at openjdk.org Thu Apr 3 00:38:50 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 3 Apr 2025 00:38:50 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> Message-ID: On Wed, 5 Mar 2025 07:06:45 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 1374: > >> 1372: ServiceUpdateCallback updateCb) { >> 1373: Service newSvc; >> 1374: MappingInfo oldMi = find(key); > > `oldMi` could just simply be `mi`? There is no `newMi` in the same method anywhere. We used `old` to stress the difference with the new service that is added to replace the old one. For example, in the statement `newSvc = new Service(oldMi.svc)` we see more clearly the contrast. There isn't a `newMi` because we don't look up in the map again. Unless you have a strong preference, I'd stick with `old`. Let us know. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025820881 From mbalao at openjdk.org Thu Apr 3 00:46:51 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 3 Apr 2025 00:46:51 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> Message-ID: <4isuseNc1rL2y-n9L7JD75771Zf5geuPqogaEWsY9F4=.5cb3d025-a893-4464-be6b-905a0f2bd3f2@github.com> On Thu, 6 Mar 2025 06:13:22 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 1502: > >> 1500: return parseLegacy(servicesMap, ks, vs, opType); >> 1501: } else if (value != null && oldValue instanceof String oldValueS && >> 1502: opType == OPType.ADD) { > > Which method is this else-block for? `value` is not null and not instanceof `String` and `oldValue` is instanceof `String` and `opType` is ADD? In this case we are adding an entry to the Provider (seen as a Properties map more than a Provider). The value of this new entry is not a string and is replacing an entry with the same key, whose value is mapped to a service in the internal (services) map. From the point of view of the internal map, this acts as a removal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025825223 From mbalao at openjdk.org Thu Apr 3 00:51:04 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 3 Apr 2025 00:51:04 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> Message-ID: On Thu, 6 Mar 2025 06:15:17 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 1508: > >> 1506: // to a removal. In any case, let the caller proceed with the >> 1507: // Properties map update. >> 1508: parseLegacy(servicesMap, ks, oldValueS, OPType.REMOVE); > > no return here and falls through to the line 1512? Is this really intended? Yes, it's intended because we need the caller to handle the property change. While a service is removed in the internal (services) map (and the corresponding property in the outer map automatically removed), nothing is added to the outer map for the new property. We need the caller to handle that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025827860 From valeriep at openjdk.org Thu Apr 3 00:54:54 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 3 Apr 2025 00:54:54 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API In-Reply-To: References: Message-ID: <8UNuDQR_eQ2zm91c6_AUgT7pZEqbOx6kLmtyjZXgnxk=.e0280c9e-f2a1-49f6-9d1d-e5235638b522@github.com> On Wed, 2 Apr 2025 23:22:40 GMT, Weijun Wang wrote: >> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. >> >> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. >> >> Thanks in advance for the review~ > > src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 120: > >> 118: SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret", >> 119: HKDFParameterSpec.ofExtract().addSalt(zeros) >> 120: .addIKM(ikm).extractOnly()); > > Maybe no need for `addSalt(zeros)`. I remember salt is by default zeros for HKDF. Yes, I am on the fence about this. Given the specified value is the same as the default, it can be removed. I kept it there so the new code matches the original code completely. Not much difference either way I think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2025829592 From mbalao at openjdk.org Thu Apr 3 00:56:52 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 3 Apr 2025 00:56:52 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> Message-ID: On Thu, 6 Mar 2025 07:06:08 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 1536: > >> 1534: >> 1535: private Object implRemove(Object key) { >> 1536: Object oldValue = super.get(key); > > `oldValue` isn't really old value, is it? Naming it `oldValue` and pass it to `doLegacyOp()` as `value` is very confusing. Yes, I see why it could be confusing. We named it `old` thinking from the returned value's point of view (when there is a removal, we have to return the old/previous value). Perhaps we should rename it to just `value`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025831036 From mbalao at openjdk.org Thu Apr 3 01:07:58 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 3 Apr 2025 01:07:58 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> Message-ID: On Thu, 6 Mar 2025 06:10:09 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 1486: > >> 1484: * case, Properties map entries are synchronized. In the latter, Properties >> 1485: * map entries are not modified. >> 1486: */ > > I am not too sure I get this comment block. Judging from the impl, this enum seems to be used to indicate whether the Properties map is updated. The part about ServiceMap is especially confusing. Is this enum for Properties map or ServicesMap? In addition, instead of stating "an entry that is not a service, alias or attribute.", can we just state the remaining types? Is "In the former case" refer to the UPDATE? In that paragraph. there is only one case. Lastly, there is only 2 values to this enum, can't this be replaced with a boolean? Yes, we can replace a 2-values enum with a boolean if you have a strong preference. We have done this before. I still think that an enum and a comment may help the reader, especially because uses are in multiple private and undocumented methods. This enum allows us to have the documentation in a single place. As for the comment itself, UPDATE indicates that the change in the outer (properties) map has to be done. SKIP indicates that the outer map change should be skipped: it was either done automatically when the ServicesMap was updated or should not be done because there was an error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2025839530 From fferrari at openjdk.org Thu Apr 3 01:21:28 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Thu, 3 Apr 2025 01:21:28 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v6] In-Reply-To: References: Message-ID: > Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map"). > > #### New services map design > > Here is the high-level hierarchy of the new services map design: > > * `servicesMap` (`ServicesMap`) > * Instances (fields) > * `services` (`Map`): unifies the previous `serviceMap` and `legacyMap` > * `legacySvcKeys` (`Set`): set indicating which keys in `services` correspond to the Legacy API > * `serviceProps` (`Map`): keeps track of the _provider Hashtable entries_ that originated services entries (1) > * `serviceAttrProps` (`Map>`): keeps track of the _provider Hashtable entries_ that originated service attributes (1) > * `serviceSet` (`AtomicReference>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method > * Writers' methods (for providers registering services through the Current or the Legacy API) > * `boolean putService(Service svc)` > * `boolean removeService(Service svc)` > * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)` > * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)` > * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)` > * `boolean removeLegacy(ServiceKey key, String className)` > * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)` > * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)` > * Readers' methods (for services users and `GetInstance` APIs) > * `Set getServices()` > * `Service getService(ServiceKey key)` > * Other methods: default and copy constructors, `void clear()` > > (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms. > > #### Testing > > As part of our testing, we observed all the tests pass in the following categories: > > * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398)) > * `jdk/com/sun/crypto` > * `jdk/java/security` > * Including the new `jdk/java/security/Provider/Ser... Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: Assorted minor changes. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22613/files - new: https://git.openjdk.org/jdk/pull/22613/files/3d0df51b..413cd7f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=04-05 Stats: 80 lines in 1 file changed: 36 ins; 26 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/22613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22613/head:pull/22613 PR: https://git.openjdk.org/jdk/pull/22613 From djelinski at openjdk.org Thu Apr 3 08:11:50 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 3 Apr 2025 08:11:50 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 21:43:19 GMT, Valerie Peng wrote: > This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. > > This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. > > Thanks in advance for the review~ LGTM. Thanks! ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24393#pullrequestreview-2738901455 From mullan at openjdk.org Thu Apr 3 14:52:01 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 3 Apr 2025 14:52:01 GMT Subject: RFR: 8219408: Tests should handle ${} in the view of jtreg "smart action" In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 12:53:16 GMT, Matthew Donovan wrote: > In this PR I removed TEST.properties files that disabled smart action tags. It is safe to remove the entire file: the smart action tags was the only directive in them. I verified the affected tests pass successfully. Marked as reviewed by mullan (Reviewer). Looks ok, but I am wondering ... how did these tests pass in the first place if the `allowSmartActionArgs` property was false? ------------- PR Review: https://git.openjdk.org/jdk/pull/23896#pullrequestreview-2740188003 PR Comment: https://git.openjdk.org/jdk/pull/23896#issuecomment-2776046269 From sean.mullan at oracle.com Thu Apr 3 15:20:03 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 3 Apr 2025 11:20:03 -0400 Subject: SSLContext instances In-Reply-To: <751077d2-8a11-42d7-951f-41ca5c366dc9@gmail.com> References: <43b0a23e-28ce-4f6c-ad3d-139b53f6197c@gmail.com> <052f82aa-84d7-479a-95bd-9ab4186f633d@oracle.com> <751077d2-8a11-42d7-951f-41ca5c366dc9@gmail.com> Message-ID: On 3/13/25 3:44 PM, Scott Lewis wrote: > But from the point of view of the OSGi framework implementation (for > example), has there been any discussion to alternatives to leaving > SSLContext.setDefault open to all code at all times?? e.g. deprecation > of public static setDefault, or changing the semantics of setDefault so > that it could only be called successfully once (on startup).? I > understand that may not be feasible due to api conventions, but was > wondering if this or other approaches (enhancing JCP) have been > considered/discussed. I am not familiar with OSGi so I don't understand the scenario you are describing. Can you provide more details? --Sean From jnimeh at openjdk.org Thu Apr 3 16:45:25 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 3 Apr 2025 16:45:25 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 Message-ID: This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. ------------- Commit messages: - 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 Changes: https://git.openjdk.org/jdk/pull/24420/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24420&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350126 Stats: 488 lines in 3 files changed: 238 ins; 214 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/24420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24420/head:pull/24420 PR: https://git.openjdk.org/jdk/pull/24420 From jnimeh at openjdk.org Thu Apr 3 16:45:25 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 3 Apr 2025 16:45:25 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 16:31:39 GMT, Jamil Nimeh wrote: > This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. > > There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. Benchmarks for Apple M1: MacOS Sonoma 14.5, 8x Apple M1 Quarter Round Parallel, No Interleaving --------------------------------------- Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 3837175.980 ? 14108.076 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 1150065.857 ? 2238.499 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 299444.203 ? 1914.377 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 76149.432 ? 81.343 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 3457825.749 ? 95284.525 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 1100458.180 ? 9856.390 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 296393.225 ? 1176.583 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 75271.693 ? 848.788 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 995936.643 ? 8252.270 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 518474.192 ? 2541.371 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 178582.085 ? 337.094 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 50037.769 ? 60.497 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 1189366.955 ? 3437.169 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 568044.693 ? 6057.314 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 181517.405 ? 248.283 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 49339.073 ? 298.549 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 50024.452 ? 53.838 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 49459.758 ? 63.090 ops/s Quarter Round Parallel, With Interleaving ----------------------------------------- Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 3880433.294 ? 9904.562 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 1157285.625 ? 2415.082 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 301986.767 ? 339.147 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 75990.670 ? 194.671 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 3486874.086 ? 93507.311 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 1111966.942 ? 9602.005 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 297633.816 ? 1455.184 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 74817.230 ? 1737.888 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 998384.311 ? 7491.076 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 517031.021 ? 1756.181 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 179139.212 ? 401.008 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 49796.519 ? 609.335 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 1207581.459 ? 13757.759 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 576596.806 ? 4205.682 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 184108.182 ? 229.014 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 50120.498 ? 300.391 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 50053.528 ? 181.415 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 50232.767 ? 62.234 ops/s Block Parallel, No Interleaving ------------------------------- Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 4107524.407 ? 9337.726 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 1210532.736 ? 1111.846 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 315178.899 ? 375.858 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 78782.555 ? 856.939 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 3601509.841 ? 103375.315 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 1156918.875 ? 9666.447 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 312270.458 ? 1726.717 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 79394.369 ? 513.291 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 1029546.842 ? 2317.072 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 532504.493 ? 2836.934 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 183874.028 ? 332.438 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 51739.678 ? 122.138 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 1263370.572 ? 15424.473 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 588853.049 ? 3419.509 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 188899.111 ? 160.103 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 51516.978 ? 147.720 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 51758.247 ? 39.852 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 51441.519 ? 278.059 ops/s Block Parallel, With Interleaving --------------------------------- Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 4154482.236 ? 8208.082 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 1221710.558 ? 5967.515 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 319918.165 ? 327.235 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 80602.283 ? 193.687 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 3710733.896 ? 88631.462 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 1168824.003 ? 10465.340 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 315040.718 ? 1389.500 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 80365.126 ? 586.286 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 1007279.441 ? 8794.990 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 536758.995 ? 3346.320 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 184600.058 ? 362.456 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 52079.247 ? 38.558 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 1233639.918 ? 7503.063 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 593298.939 ? 3886.323 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 190535.858 ? 215.443 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 51953.765 ? 226.078 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 52073.085 ? 46.961 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 51815.757 ? 331.563 ops/s Benchmarks for Neoverse-N1: System: 2x Neoverse-N1, 2 cores, 1 socket, 1 thread/core (var 0x3, part, 0xD0C) Quarter-Round Parallel Intrinsics Implementation ------------------------------------------------ Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 2219198.137 ? 13314.344 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 684200.661 ? 3601.031 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 181048.566 ? 942.201 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 46150.219 ? 118.031 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 2049320.671 ? 9549.691 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 663456.090 ? 2722.964 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 179921.834 ? 573.613 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 45885.159 ? 102.974 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 476694.433 ? 4118.055 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 251749.129 ? 1535.415 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 87052.901 ? 436.111 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 24099.749 ? 136.009 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 601333.942 ? 5414.186 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 280884.583 ? 2332.119 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 90250.320 ? 604.948 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 24346.217 ? 101.557 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 23950.145 ? 119.081 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 24405.675 ? 93.554 ops/s Quarter-Round Parallel Intrinsics with Interleaving Implementation: ------------------------------------------------------------------- Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 2344673.121 ? 14885.986 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 724626.059 ? 3078.617 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 192723.841 ? 744.860 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 49050.992 ? 118.087 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 2136919.832 ? 7229.740 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 703672.009 ? 2520.798 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 191748.973 ? 421.704 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 48939.791 ? 194.749 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 497137.864 ? 2915.527 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 262127.552 ? 1302.946 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 90018.698 ? 425.574 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 24987.421 ? 119.936 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 634980.497 ? 4191.567 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 293529.897 ? 1496.703 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 93230.690 ? 480.282 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 24936.479 ? 112.139 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 24897.542 ? 76.891 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 25128.075 ? 120.033 ops/s Block-Parallel Intrinsics Implementation ---------------------------------------- Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 2164945.312 ? 8845.473 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 659831.098 ? 1968.217 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 175252.222 ? 512.910 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 44329.489 ? 126.564 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 1975016.045 ? 11695.931 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 640856.881 ? 1830.533 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 173305.072 ? 366.240 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 44208.373 ? 107.018 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 466351.469 ? 3278.807 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 247662.489 ? 1165.507 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 85367.721 ? 404.796 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 23492.360 ? 92.043 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 589645.973 ? 4262.663 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 278130.465 ? 1394.179 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 88081.739 ? 443.476 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 23853.430 ? 104.346 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 23620.475 ? 75.932 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 23750.134 ? 118.572 ops/s Block-Parallel with Interleaving Intrinsics Implementation ---------------------------------------------------------- Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 2358246.820 ? 14256.312 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 734318.183 ? 2447.434 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 196243.937 ? 517.431 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 50008.245 ? 85.350 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 2156054.908 ? 5432.249 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 713847.200 ? 1962.784 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 194383.466 ? 464.389 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 49652.092 ? 166.716 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 497410.798 ? 3632.927 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 261587.126 ? 1336.591 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 90453.673 ? 429.630 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 24963.118 ? 103.795 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 623876.407 ? 4655.637 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 292279.929 ? 1345.033 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 93352.350 ? 429.286 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 25190.232 ? 121.961 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 25128.018 ? 84.863 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 25371.698 ? 129.837 ops/s Benchmarks for Cortex-A72: 4 processor Cortex-A72, 1 cluster, 4 cores/cluster, 1 thread/core (var 0x0, part 0xD08) Quarter Round Parallel Implementation, No Interleaving ------------------------------------------------------ Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 602983.483 ? 6556.879 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 186189.843 ? 628.835 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 49499.230 ? 139.811 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 12487.617 ? 69.484 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 592209.356 ? 3927.984 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 185091.856 ? 366.779 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 49491.296 ? 117.179 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 12512.907 ? 71.587 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 96212.313 ? 2482.928 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 65131.604 ? 1504.555 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 27746.783 ? 229.856 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 8381.946 ? 32.122 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 129453.321 ? 3224.106 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 77091.625 ? 1470.684 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 29334.590 ? 303.107 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 8460.356 ? 8.524 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 8386.624 ? 34.163 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 8471.573 ? 8.635 ops/s Quarter Round Parallel Implementaion, With Interleaving ------------------------------------------------------- Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 767143.826 ? 9195.715 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 254386.139 ? 1378.080 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 69152.606 ? 176.940 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 17609.457 ? 71.086 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 746643.194 ? 9077.375 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 251953.223 ? 959.588 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 69064.757 ? 197.231 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 17563.052 ? 97.678 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 105520.550 ? 2805.637 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 72902.046 ? 1738.503 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 33446.843 ? 377.742 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 10437.913 ? 31.702 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 141153.205 ? 3693.280 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 89657.996 ? 1635.631 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 35926.981 ? 244.574 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 10555.879 ? 18.698 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 10440.037 ? 33.023 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 10542.745 ? 45.282 ops/s Block Parallel Implementation, No Interleaving ---------------------------------------------- Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 587100.753 ? 5754.708 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 178737.840 ? 730.445 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 47340.182 ? 121.627 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 11947.269 ? 66.887 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 574123.343 ? 3838.477 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 177870.311 ? 420.125 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 47409.796 ? 109.224 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 11967.672 ? 65.803 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 95867.086 ? 2228.000 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 63376.433 ? 1301.826 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 26988.391 ? 231.289 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 8139.090 ? 20.871 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 127770.261 ? 3262.540 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 76019.408 ? 1226.583 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 28652.283 ? 214.896 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 8208.186 ? 11.455 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 8131.508 ? 27.548 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 8207.550 ? 13.086 ops/s Block Parallel Implementation, With Interleaving ------------------------------------------------ Benchmark (dataSize) (keyLength) (mode) (padding) (permutation) (provider) Mode Cnt Score Error Units o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 256 256 None NoPadding ChaCha20 thrpt 40 826086.130 ? 9933.137 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 1024 256 None NoPadding ChaCha20 thrpt 40 276583.128 ? 1434.611 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 4096 256 None NoPadding ChaCha20 thrpt 40 75688.367 ? 228.277 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.decrypt 16384 256 None NoPadding ChaCha20 thrpt 40 19348.013 ? 77.810 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 256 256 None NoPadding ChaCha20 thrpt 40 800978.386 ? 10445.822 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 1024 256 None NoPadding ChaCha20 thrpt 40 274107.264 ? 1606.978 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 4096 256 None NoPadding ChaCha20 thrpt 40 75446.852 ? 209.379 ops/s o.o.b.j.c.full.CipherBench.ChaCha20.encrypt 16384 256 None NoPadding ChaCha20 thrpt 40 19270.292 ? 105.573 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 105988.778 ? 3001.220 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 76162.169 ? 1692.042 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 34978.996 ? 468.786 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 11040.040 ? 31.844 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 256 256 None NoPadding ChaCha20-Poly1305 thrpt 40 146046.188 ? 3471.952 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 1024 256 None NoPadding ChaCha20-Poly1305 thrpt 40 94041.417 ? 1834.558 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 4096 256 None NoPadding ChaCha20-Poly1305 thrpt 40 37770.658 ? 311.519 ops/s o.o.b.j.c.full.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 11183.053 ? 11.204 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.decrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 11037.956 ? 39.522 ops/s o.o.b.j.c.small.CipherBench.ChaCha20Poly1305.encrypt 16384 256 None NoPadding ChaCha20-Poly1305 thrpt 40 11196.095 ? 33.796 ops/s ------------- PR Comment: https://git.openjdk.org/jdk/pull/24420#issuecomment-2776357177 PR Comment: https://git.openjdk.org/jdk/pull/24420#issuecomment-2776369079 PR Comment: https://git.openjdk.org/jdk/pull/24420#issuecomment-2776371619 From mdonovan at openjdk.org Thu Apr 3 17:38:53 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 3 Apr 2025 17:38:53 GMT Subject: RFR: 8219408: Tests should handle ${} in the view of jtreg "smart action" In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 14:48:20 GMT, Sean Mullan wrote: > Looks ok, but I am wondering ... how did these tests pass in the first place if the `allowSmartActionArgs` property was false? The underlying code uses `PropertyExpander.expand()` which looks for and expands `${}` values. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23896#issuecomment-2776498190 From scottslewis at gmail.com Thu Apr 3 17:45:36 2025 From: scottslewis at gmail.com (Scott Lewis) Date: Thu, 3 Apr 2025 10:45:36 -0700 Subject: SSLContext instances In-Reply-To: References: <43b0a23e-28ce-4f6c-ad3d-139b53f6197c@gmail.com> <052f82aa-84d7-479a-95bd-9ab4186f633d@oracle.com> <751077d2-8a11-42d7-951f-41ca5c366dc9@gmail.com> Message-ID: On 4/3/2025 8:20 AM, Sean Mullan wrote: > > > On 3/13/25 3:44 PM, Scott Lewis wrote: >> But from the point of view of the OSGi framework implementation (for >> example), has there been any discussion to alternatives to leaving >> SSLContext.setDefault open to all code at all times?? e.g. >> deprecation of public static setDefault, or changing the semantics of >> setDefault so that it could only be called successfully once (on >> startup).? I understand that may not be feasible due to api >> conventions, but was wondering if this or other approaches (enhancing >> JCP) have been considered/discussed. > > I am not familiar with OSGi so I don't understand the scenario you are > describing. Can you provide more details? Although I'm referring to OSGi because that's my implementation context of interest, the thoughts apply to any application where new code/components are added/updated incrementally...e.g. many modern web servers, many client-side apps. The OSGI framework has been using the java mechanisms (built on sm and permissions) to restrict these install/update dynamics as appropriate for the application...e.g. only installing signed and user-approved/trusted code. SSLContext.setDefault seems to me to be a notably risky case for any dynamic system, and particularly for java-based servers.?? I say risky not only because of potential for explicit attacks or sslcontext provider bug exploits or configuration confusion, but also for the potential for errors during installation and/or upgrade, or even just a vague level of trust in the component being installed. Unlike many of the jvm APIs, SSLContext.setDefault cannot be overridden/replaced by the surrounding application and/or a runtime framework like OSGi.?? Thus the ideas for deprecating it, replacing it through some new non-static api, or changing the semantics to allow it to be used only (e.g. on startup), or disabled at runtime. I've proposed using OSGi service registry to support framework customization and securing of access to creating SSLContext instances in the OSGi framework [1].?? This does not, however, address the issue of the vulnerability resulting from uncontrollable access to SSLContext.setDefault...so that's why I asking about it here. Thanks. [1] https://github.com/osgi/osgi/issues/810 > > --Sean > From myankelevich at openjdk.org Thu Apr 3 18:41:57 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 3 Apr 2025 18:41:57 GMT Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java [v3] In-Reply-To: References: Message-ID: On Thu, 6 Mar 2025 11:49:12 GMT, Mikhail Yankelevich wrote: >> Refactor the following to run fully in java: >> test/java/security//Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh >> test/java/security//Security/ClassLoaderDeadlock/Deadlock.sh > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > Jaikiran's comments Still requires a security-libs review ------------- PR Comment: https://git.openjdk.org/jdk/pull/23440#issuecomment-2776629290 From vpaprotski at openjdk.org Thu Apr 3 18:49:24 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 3 Apr 2025 18:49:24 GMT Subject: RFR: 8353671: Remove dead code missed in JDK-8350459 Message-ID: 8353671: Remove dead code missed in JDK-8350459 ------------- Commit messages: - remove dead code Changes: https://git.openjdk.org/jdk/pull/24423/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24423&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353671 Stats: 23 lines in 1 file changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24423/head:pull/24423 PR: https://git.openjdk.org/jdk/pull/24423 From vpaprotski at openjdk.org Thu Apr 3 18:52:12 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 3 Apr 2025 18:52:12 GMT Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64 [v8] In-Reply-To: <5WNrv1s7Bp7hLwSVGqoPw9ycCSHK0Zyka65DpAjnB2s=.31243a29-4fbb-4c21-b671-45470d043335@github.com> References: <5WNrv1s7Bp7hLwSVGqoPw9ycCSHK0Zyka65DpAjnB2s=.31243a29-4fbb-4c21-b671-45470d043335@github.com> Message-ID: On Mon, 31 Mar 2025 19:57:59 GMT, Sean Mullan wrote: > > > I think it would also be useful to write a release note describing the approximate performance improvement gains for the crypto algorithms as displayed in your chart. Thanks. > > > > > > @seanjmullan I think I only done that once, cant find the 'instructions'.. I think Jamil had helped me, but.. (https://bugs.openjdk.org/browse/JDK-8297970) "Create subtask with 'release-note' label?" > > See the [Release Notes section](https://openjdk.org/guide/#release-notes) of the OpenJDK Developer's Guide for the process. > > For this release note, something similar to https://jdk.java.net/24/release-notes#JDK-8333867 would be nice, a couple of sentences explaining the approximate improvement, on what architectures, and for what APIs and algorithms one would see the improvement. Done I think: https://bugs.openjdk.org/browse/JDK-8297970 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2776649392 From vpaprotski at openjdk.org Thu Apr 3 18:52:12 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 3 Apr 2025 18:52:12 GMT Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64 [v8] In-Reply-To: <9TJyGXccPFnDI60b2Wg3ZIuQH2nd6LC-pFgEs6p8x1c=.6308a314-dd48-4cb3-9986-8e6eb754d4c2@github.com> References: <9TJyGXccPFnDI60b2Wg3ZIuQH2nd6LC-pFgEs6p8x1c=.6308a314-dd48-4cb3-9986-8e6eb754d4c2@github.com> Message-ID: On Fri, 28 Mar 2025 20:10:42 GMT, Volodymyr Paprotski wrote: >> src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java line 164: >> >>> 162: protected void mult(long[] a, long[] b, long[] r) { >>> 163: multImpl(a, b, r); >>> 164: reducePositive(r); >> >> `reducePositive` is now seems unused > > oh.. hmm.. I had a second PR that I decided wasnt worth it that was going to reuse this code.. > > Will create a second JBS and remove https://github.com/openjdk/jdk/pull/24423 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2027562079 From mbalao at openjdk.org Thu Apr 3 19:11:59 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 3 Apr 2025 19:11:59 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: On Mon, 3 Mar 2025 18:31:19 GMT, Valerie Peng wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Clear ServicesMap fields in the declared order >> >> Constructors assign the fields in the same order. > > src/java.base/share/classes/java/security/Provider.java line 637: > >> 635: // let javadoc show doc from superclass >> 636: @Override >> 637: public synchronized Object get(Object key) { > > How about the getProperty(String) method on line 675? Add `@Override` tag and `synchronized` keyword there also? And the `keySet()` and `values()` methods on line 432 and 444 respectively? What is the criteria for synchronizing the method of the `Provider` class? The reason why we need to synchronize `get` is because the handling of the properties map from ServicesMap may expose temporary holes. For example, if a property backed up by a service is overwritten with a value that is not (e.g. a non-string value), we need to delete the service first. When deleting the service, the properties map will have a temporary hole that is then filled up with the new property value. It's possible that we missed some other methods such as `getProperty`. We will review them again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2027591882 From abarashev at openjdk.org Thu Apr 3 20:33:55 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 3 Apr 2025 20:33:55 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3] In-Reply-To: References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: On Tue, 18 Mar 2025 14:58:51 GMT, Matthew Donovan wrote: >> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates. >> >> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1) >> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa) >> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0) > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - reversed order of DN strings when making certificates. > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - changed boolean array initialization > - 8325766: Review seclibs tests for cert expiry test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 243: > 241: .addBasicConstraintsExt(false, false, -1) > 242: .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1")) > 243: .build(trustedCert, caKeys.getPrivate(), "MD5WithRSA"); MD5 algorithm is not allowed in TLSv1.3 test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 255: > 253: .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1")) > 254: .addBasicConstraintsExt(false, false, -1) > 255: .build(trustedCert, caKeys.getPrivate(), "MD5WithRSA"); Same as above: MD5 algorithm is not allowed in TLSv1.3 certificates ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2027699283 PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2027699952 From mullan at openjdk.org Thu Apr 3 21:27:52 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 3 Apr 2025 21:27:52 GMT Subject: RFR: 8349890 : Option -Djava.security.debug=x509,ava breaks special chars [v2] In-Reply-To: <56u4NzI3lkDW6FJde_kVwNxM4622Sp_dSRxr8bj5uKM=.afa58513-6dc8-4254-8db5-d1122d3a8fc3@github.com> References: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> <56u4NzI3lkDW6FJde_kVwNxM4622Sp_dSRxr8bj5uKM=.afa58513-6dc8-4254-8db5-d1122d3a8fc3@github.com> Message-ID: On Tue, 1 Apr 2025 16:54:25 GMT, Koushik Muthukrishnan Thirupattur wrote: >> **A DESCRIPTION OF THE PROBLEM :** >> Enabling -Djava.security.debug=x509,ava affects how special characters in certificates are processed. The expected behavior is that debugging should not interfere with the normal encoding of certificate fields. >> >> **Fix:** >> The Debugging will no longer interfere with these fields, unless you call toString(). > > Koushik Muthukrishnan Thirupattur has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8349890: option -Djava.security.debug=x509,ava breaks special chars src/java.base/share/classes/sun/security/x509/AVA.java line 643: > 641: public String toString() { > 642: return toKeywordValueString > 643: (toKeyword(DEFAULT, Collections.emptyMap()), Boolean.TRUE); I don't think you need to use `Boolean` here, you can just use the primitive boolean data type as the last parameter, and pass `true`. src/java.base/share/classes/sun/security/x509/AVA.java line 662: > 660: */ > 661: public String toRFC1779String(Map oidMap) { > 662: return toKeywordValueString(toKeyword(RFC1779, oidMap), Boolean.FALSE); Same comment, but pass `false`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24360#discussion_r2027760447 PR Review Comment: https://git.openjdk.org/jdk/pull/24360#discussion_r2027750490 From mbalao at openjdk.org Thu Apr 3 21:56:52 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 3 Apr 2025 21:56:52 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: References: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com> Message-ID: <1WBudTkBc735KIMiUay3VbC0xKPEwTR2HJhNGcMKd4I=.29b82117-a165-4b6e-a18c-93e5bdd328c6@github.com> On Thu, 3 Apr 2025 00:27:50 GMT, Martin Balao wrote: >> src/java.base/share/classes/java/security/Provider.java line 1037: >> >>> 1035: } >>> 1036: >>> 1037: if (mi.isLegacy) { >> >> For legacy entry, there is no check on the `legacyApiCall` value, is this due to the call path from `resolveKeyConflict` method? However, should a legacy entry be removed by the `removeService` method? If not, then additional check may be needed? > > There is no check because entries added with the Legacy API can be removed (i.e. overwritten) with entries added with the Current API. Current API operations take precedence. > > Looks like someone can invoke `removeService` with a Service instance whose algorithm was added with the Legacy API and the code is not stopping this removal. May be a good idea to stop this. @franferrax , what do you think? We discussed this further with @franferrax and don't necessarily see the proposed behavior as a problem. To put this into some context first, it's very unlikely that someone builds a Service instance with the same algorithm of a Legacy API entry and invokes `removeService`. Even if that's the case, the service will be removed and the principle of "the Current API takes precedence" applies. This principle is also used when overriding a Legacy API value with `putService` ?behavior that comes from before of our change. Our motivation for enforcing no modification of services added with the Current API from the Legacy API was to preserve service immutability, which would not be at stake here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r2027792005 From fferrari at openjdk.org Thu Apr 3 22:05:07 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Thu, 3 Apr 2025 22:05:07 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v7] In-Reply-To: References: Message-ID: > Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map"). > > #### New services map design > > Here is the high-level hierarchy of the new services map design: > > * `servicesMap` (`ServicesMap`) > * Instances (fields) > * `services` (`Map`): unifies the previous `serviceMap` and `legacyMap` > * `legacySvcKeys` (`Set`): set indicating which keys in `services` correspond to the Legacy API > * `serviceProps` (`Map`): keeps track of the _provider Hashtable entries_ that originated services entries (1) > * `serviceAttrProps` (`Map>`): keeps track of the _provider Hashtable entries_ that originated service attributes (1) > * `serviceSet` (`AtomicReference>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method > * Writers' methods (for providers registering services through the Current or the Legacy API) > * `boolean putService(Service svc)` > * `boolean removeService(Service svc)` > * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)` > * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)` > * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)` > * `boolean removeLegacy(ServiceKey key, String className)` > * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)` > * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)` > * Readers' methods (for services users and `GetInstance` APIs) > * `Set getServices()` > * `Service getService(ServiceKey key)` > * Other methods: default and copy constructors, `void clear()` > > (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms. > > #### Testing > > As part of our testing, we observed all the tests pass in the following categories: > > * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398)) > * `jdk/com/sun/crypto` > * `jdk/java/security` > * Including the new `jdk/java/security/Provider/Ser... Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: Minor doc change missing. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22613/files - new: https://git.openjdk.org/jdk/pull/22613/files/413cd7f5..384f2a7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22613/head:pull/22613 PR: https://git.openjdk.org/jdk/pull/22613 From sviswanathan at openjdk.org Thu Apr 3 22:55:51 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 3 Apr 2025 22:55:51 GMT Subject: RFR: 8353671: Remove dead code missed in JDK-8350459 In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 18:42:35 GMT, Volodymyr Paprotski wrote: > 8353671: Remove dead code missed in JDK-8350459 Marked as reviewed by sviswanathan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24423#pullrequestreview-2741373475 From ecki at zusammenkunft.net Thu Apr 3 23:46:34 2025 From: ecki at zusammenkunft.net (ecki) Date: Fri, 4 Apr 2025 01:46:34 +0200 Subject: SSLContext instances In-Reply-To: References: <43b0a23e-28ce-4f6c-ad3d-139b53f6197c@gmail.com> <052f82aa-84d7-479a-95bd-9ab4186f633d@oracle.com> <751077d2-8a11-42d7-951f-41ca5c366dc9@gmail.com> , Message-ID: <49189215-261F-664C-9B93-4E6308791FC0@hxcore.ol> An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Fri Apr 4 02:50:31 2025 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 4 Apr 2025 12:50:31 +1000 Subject: SSLContext instances In-Reply-To: References: <43b0a23e-28ce-4f6c-ad3d-139b53f6197c@gmail.com> <052f82aa-84d7-479a-95bd-9ab4186f633d@oracle.com> <751077d2-8a11-42d7-951f-41ca5c366dc9@gmail.com> Message-ID: I think it would be useful to configure the JVM to prevent loading of untrusted (unsigned) code.?? This might be useful in preventing injection attacks, where the attacker is attempting to have the JVM load remote untrusted code. -- Regards, Peter On 4/04/2025 3:45 am, Scott Lewis wrote: > On 4/3/2025 8:20 AM, Sean Mullan wrote: >> >> >> On 3/13/25 3:44 PM, Scott Lewis wrote: >>> But from the point of view of the OSGi framework implementation (for >>> example), has there been any discussion to alternatives to leaving >>> SSLContext.setDefault open to all code at all times?? e.g. >>> deprecation of public static setDefault, or changing the semantics >>> of setDefault so that it could only be called successfully once (on >>> startup). I understand that may not be feasible due to api >>> conventions, but was wondering if this or other approaches >>> (enhancing JCP) have been considered/discussed. >> >> I am not familiar with OSGi so I don't understand the scenario you >> are describing. Can you provide more details? > > Although I'm referring to OSGi because that's my implementation > context of interest, the thoughts apply to any application where new > code/components are added/updated incrementally...e.g. many modern web > servers, many client-side apps. > > The OSGI framework has been using the java mechanisms (built on sm and > permissions) to restrict these install/update dynamics as appropriate > for the application...e.g. only installing signed and > user-approved/trusted code. > > SSLContext.setDefault seems to me to be a notably risky case for any > dynamic system, and particularly for java-based servers.?? I say risky > not only because of potential for explicit attacks or sslcontext > provider bug exploits or configuration confusion, but also for the > potential for errors during installation and/or upgrade, or even just > a vague level of trust in the component being installed. > > Unlike many of the jvm APIs, SSLContext.setDefault cannot be > overridden/replaced by the surrounding application and/or a runtime > framework like OSGi.?? Thus the ideas for deprecating it, replacing it > through some new non-static api, or changing the semantics to allow it > to be used only (e.g. on startup), or disabled at runtime. > > I've proposed using OSGi service registry to support framework > customization and securing of access to creating SSLContext instances > in the OSGi framework [1].?? This does not, however, address the issue > of the vulnerability resulting from uncontrollable access to > SSLContext.setDefault...so that's why I asking about it here. > > Thanks. > > [1] https://github.com/osgi/osgi/issues/810 > > >> >> --Sean >> From duke at openjdk.org Fri Apr 4 03:18:31 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 4 Apr 2025 03:18:31 GMT Subject: RFR: 8349890 : Option -Djava.security.debug=x509,ava breaks special chars [v3] In-Reply-To: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> References: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> Message-ID: > **A DESCRIPTION OF THE PROBLEM :** > Enabling -Djava.security.debug=x509,ava affects how special characters in certificates are processed. The expected behavior is that debugging should not interfere with the normal encoding of certificate fields. > > **Fix:** > The Debugging will no longer interfere with these fields, unless you call toString(). Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: 8349890:Option -Djava.security.debug=x509,ava breaks special chars ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24360/files - new: https://git.openjdk.org/jdk/pull/24360/files/1096d02b..06bbe7d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24360&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24360&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24360/head:pull/24360 PR: https://git.openjdk.org/jdk/pull/24360 From maurizio.cimadamore at oracle.com Fri Apr 4 10:32:34 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 4 Apr 2025 11:32:34 +0100 Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) In-Reply-To: References: <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr> Message-ID: In general I don't disagree. There is, however, at least _some_ cases where the imperative API is less difficult to use. In some cases you know that a class has a complex lifecycle -- perhaps it starts off in a simple "larval" state, where the instance only exist in a single thread. In this state, it's possible for the class to receive state updates. If parts of the class state are stable, using `trySet` might work very well. Perhaps only "friends" of this class can call such mutator methods on the larval instance. At some point later in the class lifetime, it becomes "frozen", and it is published to multiple threads. Of course, this is a corner case -- but if our goal is to model what `@Stable` can do, while surely a stable supplier, or using `orElseSet` are better no-worry alternatives to get there, there remain a number of use cases that would not be expressible if all we had was the high-level API. In a way, a big part of what this new API does is that it finds the right set of primitives, upon which we can build all the other interesting high-level stuff. I think your complaint is not that the primitive is wrong, but that in calling the primitive StableValue we're giving the "good name" to the stuff that is less likely to be widely used. (Note: a very minimalistic API approach -- which we considered -- would have been to just provide extra stable factories in Supplier/Function/IntFunction/List/Map and call it a day) Maurizio On 03/04/2025 12:20, Per-Ake Minborg wrote: > Hi Remi and thank you for the feedback from JChateau?(what a wonderful > name!). > > This is one of the issues we already have on the list for the next > round of preview. Now we know more folks are on the same page. > > Best, Per > ------------------------------------------------------------------------ > *From:* Remi Forax > *Sent:* Wednesday, April 2, 2025 4:33 PM > *To:* Per Minborg > *Cc:* compiler-dev ; core-libs-dev > ; hotspot-dev ; > security-dev > *Subject:* Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) > Hi Per, > last week, at JChateau, we had a one hour session about stable values, > I've build the JDK with this PR so we can discuss about it. > > To present the API, i start from the double check locking, rewriting > it to use the StableValue API. > > The main remark was that methods like orElseSet() or isSet() are hard > to used correctly. > > In my opinion, the current API is a mix of a high level API and a > low-level API but it's too easy to misuse the low-level API. > > > high level: > - methods supplier(), list() and map() > ? Those are easy to use > > low level: > - methods: of, of(value), orElseSet, setOrThrow(), etc > ? Those are hard to use properly. > > I think, not necessary in this PR, that the current API should be > separated into two different classes, one in java.lang with the high > level API (the static methods other than Of() and one in > java.util.concurrent with the low level API where you have to know > what you are doing (like with any classes of java.util.concurrent). > > regards, > R?mi > > ----- Original Message ----- > > From: "Per Minborg" > > To: "compiler-dev" , "core-libs-dev" > , "hotspot-dev" > > , "security-dev" > > Sent: Thursday, March 13, 2025 12:20:10 PM > > Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) > > > Implement JEP 502. > > > > The PR passes tier1-tier3 tests. > > > > ------------- > > > > Commit messages: > > - Use acquire semantics for reading rather than volatile semantics > > - Add missing null check > > - Simplify handling of sentinel, wrap, and unwrap > > - Fix JavaDoc issues > > - Fix members in StableEnumFunction > > - Address some comments in the PR > > - Merge branch 'master' into implement-jep502 > > - Revert change > > - Fix copyright issues > > - Update JEP number > > - ... and 231 more: > https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6 > > > > Changes: https://git.openjdk.org/jdk/pull/23972/files > >? Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00 > > >? Issue: https://bugs.openjdk.org/browse/JDK-8351565 > >? Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod > >? Patch: https://git.openjdk.org/jdk/pull/23972.diff > >? Fetch: git fetch https://git.openjdk.org/jdk.git > pull/23972/head:pull/23972 > > > > PR: https://git.openjdk.org/jdk/pull/23972 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Fri Apr 4 12:44:03 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 4 Apr 2025 12:44:03 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal Message-ID: Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission @Deprecated(forRemoval = true, since="25") Is added to each class and the existing @apiNote is converted to @deprected ------------- Commit messages: - 8353641: Deprecate core library permission classes for removal Changes: https://git.openjdk.org/jdk/pull/24444/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353641 Stats: 47 lines in 15 files changed: 28 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444 PR: https://git.openjdk.org/jdk/pull/24444 From dfuchs at openjdk.org Fri Apr 4 12:56:03 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 4 Apr 2025 12:56:03 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs wrote: > Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected Looks reasonable to me. Changes to LoggingPermission look good. Out of curiosity I also looked at all usages of RuntimePermission in the JDK - I believe you caught them all - including the unexpected use in XSLT. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24444#issuecomment-2778654645 From mullan at openjdk.org Fri Apr 4 13:12:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 13:12:50 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal Message-ID: Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. The current API note in these classes was reused as the deprecation text. Release Note: https://bugs.openjdk.org/browse/JDK-8353680 ------------- Commit messages: - Remove trailing whitespace. - Initial revision. Changes: https://git.openjdk.org/jdk/pull/24445/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348967 Stats: 53 lines in 15 files changed: 34 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24445/head:pull/24445 PR: https://git.openjdk.org/jdk/pull/24445 From duke at openjdk.org Fri Apr 4 13:53:57 2025 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 4 Apr 2025 13:53:57 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote: > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. I agree with most of these, however the permissions infrastructure *itself* is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778791218 From mullan at openjdk.org Fri Apr 4 14:08:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 14:08:57 GMT Subject: RFR: 8349890 : Option -Djava.security.debug=x509,ava breaks special chars [v3] In-Reply-To: References: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> Message-ID: On Fri, 4 Apr 2025 03:18:31 GMT, Koushik Muthukrishnan Thirupattur wrote: >> **A DESCRIPTION OF THE PROBLEM :** >> Enabling -Djava.security.debug=x509,ava affects how special characters in certificates are processed. The expected behavior is that debugging should not interfere with the normal encoding of certificate fields. >> >> **Fix:** >> The Debugging will no longer interfere with these fields, unless you call toString(). > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8349890:Option -Djava.security.debug=x509,ava breaks special chars test/jdk/sun/security/x509/X500Name/PrintX500NameInDebugModeWithAvaOption.java line 39: > 37: public static void main(String[] args) throws Exception { > 38: > 39: X500Name name = new X500Name("cn=john doe + l=ca\\+lifornia + l =sf, O=?"); Use `X500Principal` objects for testing instead of `X500Name`. `X500Principal` is a public/standard API, so it is better to ensure that the issue is fixed via standard APIs. Then you also don't need the `@modules` line. Also change name of test to `PrintX500PrincipalInDebugModeWithAvaOption`. test/jdk/sun/security/x509/X500Name/PrintX500NameInDebugModeWithAvaOption.java line 47: > 45: //Test the name in RFC2253 format. This should skip the hex conversion to return > 46: //"\u00d1" for special character "?" > 47: Asserts.assertTrue(name.getRFC2253Name().contains("\u00d1"), "String does not contain expected value"); Here you can call `X500Principal.getName()` instead which emits an RFC 2253 name. test/jdk/sun/security/x509/X500Name/PrintX500NameInDebugModeWithAvaOption.java line 51: > 49: //Test the name in canonical name in RFC2253 format. This should skip the hex conversion to return > 50: //"n\u0303" for special character "?" > 51: Asserts.assertTrue(name.getRFC2253CanonicalName().contains("n\u0303"),"String does not contain expected value"); Here you can call `X500Principal.getName(X500Principal.CANONICAL)` instead which emits a canonical RFC 2253 name. test/jdk/sun/security/x509/X500Name/PrintX500NameInDebugModeWithAvaOption.java line 51: > 49: //Test the name in canonical name in RFC2253 format. This should skip the hex conversion to return > 50: //"n\u0303" for special character "?" > 51: Asserts.assertTrue(name.getRFC2253CanonicalName().contains("n\u0303"),"String does not contain expected value"); Nit, add space after the comma, same comment on line 43 and 56. Or break up into 2 lines as some of the lines are a bit long. test/jdk/sun/security/x509/X500Name/PrintX500NameInDebugModeWithAvaOption.java line 56: > 54: //Test to print name in RFC1779 format. This should skip the hex conversion to print > 55: //"\u00d1" for special character "?" > 56: Asserts.assertTrue(name.getRFC1779Name().contains("\u00d1"),"String does not contain expected value"); Here you can call `X500Principal.getName(X500Principal.RFC1779)` instead which emits a RFC 1779 name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24360#discussion_r2028855420 PR Review Comment: https://git.openjdk.org/jdk/pull/24360#discussion_r2028869879 PR Review Comment: https://git.openjdk.org/jdk/pull/24360#discussion_r2028872261 PR Review Comment: https://git.openjdk.org/jdk/pull/24360#discussion_r2028875687 PR Review Comment: https://git.openjdk.org/jdk/pull/24360#discussion_r2028874116 From mullan at openjdk.org Fri Apr 4 14:15:48 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 14:15:48 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal In-Reply-To: References: Message-ID: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com> On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote: > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. > > The current API note in these classes was reused as the deprecation text. > > Release Note: https://bugs.openjdk.org/browse/JDK-8353680 > > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. > > I agree with most of these, however the permissions infrastructure _itself_ is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself. Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778846121 From mullan at openjdk.org Fri Apr 4 14:26:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 14:26:53 GMT Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java [v3] In-Reply-To: References: Message-ID: <1_Z3ReKHnwdaUR5GEWOjjDdbJ5QdSXcMPciSQAJKNHw=.dc1bbefe-5152-42d8-a62c-ccc4a093d1af@github.com> On Thu, 6 Mar 2025 11:49:12 GMT, Mikhail Yankelevich wrote: >> Refactor the following to run fully in java: >> test/java/security//Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh >> test/java/security//Security/ClassLoaderDeadlock/Deadlock.sh > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > Jaikiran's comments The JBS issue should have a `noreg-self` label. Otherwise fix looks ok. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23440#pullrequestreview-2743181022 From mullan at openjdk.org Fri Apr 4 14:29:05 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 14:29:05 GMT Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64 [v8] In-Reply-To: References: <5WNrv1s7Bp7hLwSVGqoPw9ycCSHK0Zyka65DpAjnB2s=.31243a29-4fbb-4c21-b671-45470d043335@github.com> Message-ID: <5m9xiUkcb41c47vcLKS3kvsK9Jhh1y7PsNRHcffa8ug=.5785cdda-e50e-410a-a139-5554d70bfdff@github.com> On Thu, 3 Apr 2025 18:49:24 GMT, Volodymyr Paprotski wrote: > Done I think: https://bugs.openjdk.org/browse/JDK-8297970 Is this link correct? This issue was fixed in JDK 20. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2778889529 From hannesw at openjdk.org Fri Apr 4 14:32:45 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 4 Apr 2025 14:32:45 GMT Subject: RFR: 8254622: Hide superclasses from conditionally exported packages Message-ID: Please review an enhancement to treat classes and interfaces that are not included and not unconditionally exported as hidden. This means they do not show up in the generated documentation even if they are implemented or extended by a documented type. This change makes the `@hidden` JavaDoc tag unnecessary in two internal base classes that previously used it, `jdk.internal.vm.vector.VectorSupport` and `jdk.internal.event.Event`. The generated documentation is unchanged. The change also adds support for the `@hidden` JavaDoc tag in interfaces, which was previously missing, and adds coverage to `TestHiddenTag.java`. ------------- Commit messages: - Remove whitespace - Update copyright headers - Add test, support hidden interfaces - Merge branch 'master' into JDK-8254622 - Tweak comments - 8254622: Hide superclasses from conditionally exported packages Changes: https://git.openjdk.org/jdk/pull/24446/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24446&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8254622 Stats: 382 lines in 19 files changed: 326 ins; 15 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/24446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24446/head:pull/24446 PR: https://git.openjdk.org/jdk/pull/24446 From fferrari at openjdk.org Fri Apr 4 14:37:03 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Fri, 4 Apr 2025 14:37:03 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v3] In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 21:04:39 GMT, Valerie Peng wrote: >>> Hi @valeriepeng, I found code assuming `com.sun.crypto.provider.PBEKey` contains only ASCII, please find my suggestions in the review comments. I also added a suggestion for the tests, in order to increase the coverage in that regard. >>> >>> All the patches are verified to cleanly apply on top of this PR branch, when copied through the GitHub's copy button and applied with `xclip -sel clip | git apply`. >> >> Great, thanks for catching this! > >> Hi @valeriepeng, >> >> I have left a couple more comments, and taken advantage to do a more complete review. >> >> Please note that I haven't finished reviewing `TestPBKD.java` (for example, we can still do some of the deleted checks). However I wanted to left a partial review in-advance, as I will be on PTO until next Tuesday. > > Sure, I will wait for you to complete the review, no hurry. Hi @valeriepeng, I finished with `TestPBKD.java`. I had to try and test every suggestion to make sure I'm not proposing anything that breaks the test. For that reason, instad of making comments to the changes, I'm posting an updated version for your review.
Summary of the changes * Update the copyright year * Remove unused imports * Remove the `kdfAlgo` argument of `TestPBKD::pbkd2AssertionData()` (with the `PBEWithAnd` secret key factories removal, we only use `PBKDF2With`, so `kdfAlgo` is always equal to `algo`) * Reintroduce deleted `PBEWithAnd` assertion data, we can still use it with their `PBKDF2With` equivalent * Reintroduce some deleted checks in `TestPBKD::testInvalidTranslateKey()` * Non-PBEKey key to PBE SecretKeyFactory * PBEKey key to PBE SecretKeyFactory of a different algorithm * Non-AES PBEKey key to AES SecretKeyFactory * Inconsistent key length between key and its algorithm * Reintroduce a deleted check in `TestPBKD::testInvalidGenerateSecret()` * Missing salt and iteration count * Rename `p11PbeKey` ? `p11PbkdfKey` for alignment with the `P11PBEKey` ? `P11PBKDFKey` rename * Rename `skf1`, `skf2`, `skf3`, ? to avoid skipping numbers
Proposed test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java /* * Copyright (c) 2023, 2025, Red Hat, Inc. * * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ import java.math.BigInteger; import java.nio.charset.StandardCharsets; import java.security.InvalidKeyException; import java.security.NoSuchAlgorithmException; import java.security.Provider; import java.security.Security; import java.security.spec.InvalidKeySpecException; import java.security.spec.KeySpec; import java.util.Arrays; import javax.crypto.SecretKey; import javax.crypto.SecretKeyFactory; import javax.crypto.interfaces.PBEKey; import javax.crypto.spec.PBEKeySpec; import javax.crypto.spec.SecretKeySpec; /* * @test * @bug 8301553 8348732 * @summary test key derivation on a SunPKCS11 SecretKeyFactory service * @library /test/lib .. * @modules java.base/com.sun.crypto.provider:open * @run main/othervm/timeout=30 TestPBKD */ public final class TestPBKD extends PKCS11Test { private static final String sep = "======================================" + "==================================="; private enum Configuration { // Pass password, salt and iterations to a // SecretKeyFactory through a PBEKeySpec. PBEKeySpec, // Pass password, salt and iterations and iterations to a // SecretKeyFactory through an anonymous class implementing // the javax.crypto.interfaces.PBEKey interface. AnonymousPBEKey, } private static Provider sunJCE = Security.getProvider("SunJCE"); private static BigInteger i(byte[] data) { return new BigInteger(1, data); } private record AssertionData(String algo, PBEKeySpec keySpec, BigInteger expectedKey) {} private static AssertionData pbkd2AssertionData(String algo, char[] password, int keyLen, String staticExpectedKeyString) { PBEKeySpec keySpec = new PBEKeySpec(password, salt, iterations, keyLen); BigInteger staticExpectedKey = new BigInteger(staticExpectedKeyString, 16); BigInteger expectedKey = null; if (sunJCE != null) { try { expectedKey = i(SecretKeyFactory.getInstance(algo, sunJCE) .generateSecret(keySpec).getEncoded()); checkAssertionValues(expectedKey, staticExpectedKey); } catch (NoSuchAlgorithmException | InvalidKeySpecException e) { // Move to staticExpectedKey as it's unlikely // that any of the algorithms are available. sunJCE = null; } } if (expectedKey == null) { expectedKey = staticExpectedKey; } return new AssertionData(algo, keySpec, expectedKey); } private static void checkAssertionValues(BigInteger expectedValue, BigInteger staticExpectedValue) { if (!expectedValue.equals(staticExpectedValue)) { printHex("SunJCE value", expectedValue); printHex("Static value", staticExpectedValue); throw new Error("Static and SunJCE values do not match."); } } private static final char[] pwd = "123456\uA4F7".toCharArray(); private static final char[] emptyPwd = new char[0]; private static final byte[] salt = "abcdefgh".getBytes( StandardCharsets.UTF_8); private static final int iterations = 1000; // Generated with SunJCE. Keep a reference to some // entries for tests executing invalid conditions. private static final AssertionData pbkdf2WithHmacSHA512Data = pbkd2AssertionData("PBKDF2WithHmacSHA512", pwd, 256, "845560159e2f3f51dad8d6e0feccc8987e3077595f90b60ab96d4f29" + "203927b0"); private static final AssertionData pbkdf2WithHmacSHA256Data = pbkd2AssertionData("PBKDF2WithHmacSHA256", pwd, 384, "6851e387278dd5a3a0d05e4d742f59d844984e3e9b619488a42b93dd" + "6453f630ae3e2ad7ed809fa9e98a792187d62e84"); private static final AssertionData[] assertionData = new AssertionData[]{ pbkd2AssertionData("PBKDF2WithHmacSHA1", pwd, 128, "29958f3f1c942e50903189eb7f1ba09d"), pbkd2AssertionData("PBKDF2WithHmacSHA224", pwd, 128, "e328140e31f4ffb15af806986c23ee4e"), pbkd2AssertionData("PBKDF2WithHmacSHA256", pwd, 128, "6851e387278dd5a3a0d05e4d742f59d8"), pbkd2AssertionData("PBKDF2WithHmacSHA384", pwd, 128, "5570e2fb1a664910f055b71643b52351"), pbkd2AssertionData("PBKDF2WithHmacSHA512", pwd, 128, "845560159e2f3f51dad8d6e0feccc898"), pbkd2AssertionData("PBKDF2WithHmacSHA1", pwd, 256, "29958f3f1c942e50903189eb7f1ba09d40" + "b5552da5e645dad4b5911ce0f2f06b"), pbkd2AssertionData("PBKDF2WithHmacSHA224", pwd, 256, "e328140e31f4ffb15af806986c23ee4e" + "7daa2119fee8c64aef7c1f4c1871724e"), pbkd2AssertionData("PBKDF2WithHmacSHA256", pwd, 256, "6851e387278dd5a3a0d05e4d742f59d8" + "44984e3e9b619488a42b93dd6453f630"), pbkd2AssertionData("PBKDF2WithHmacSHA384", pwd, 256, "5570e2fb1a664910f055b71643b52351" + "d7d0ad3a18912086f80d974f2acc2efb"), pbkdf2WithHmacSHA512Data, pbkd2AssertionData("PBKDF2WithHmacSHA1", pwd, 240, "29958f3f1c942e50903189eb7f1ba09d40b5552da5e645dad4b5911c" + "e0f2"), pbkd2AssertionData("PBKDF2WithHmacSHA224", pwd, 336, "e328140e31f4ffb15af806986c23ee4e7daa2119fee8c64aef7c1f4c" + "1871724e0ea628577e0ab54fa7c6"), pbkdf2WithHmacSHA256Data, pbkd2AssertionData("PBKDF2WithHmacSHA384", pwd, 576, "5570e2fb1a664910f055b71643b52351d7d0ad3a18912086f80d974f" + "2acc2efba52650d4bf872455820f24c846742161da84a1b4c3f197f4" + "347308e8841a8971cf686aef29107396"), pbkd2AssertionData("PBKDF2WithHmacSHA512", pwd, 768, "845560159e2f3f51dad8d6e0feccc8987e3077595f90b60ab96d4f29" + "203927b00aa1a11e4d19d4f275a7f45314be500dacc3c1de9f704827" + "b396463ccaa8957344d41bd64d9d09ff474e776469d326b1ee6ee5a5" + "d854b86d3d7a25084afd6d6f"), pbkd2AssertionData("PBKDF2WithHmacSHA512", emptyPwd, 256, "3a5c5fd11e4d381b32e11baa93d7b12809e016e48e0542c5d3453fc2" + "40a0fa76"), }; public void main(Provider sunPKCS11) throws Exception { System.out.println("SunPKCS11: " + sunPKCS11.getName()); // Test valid cases. for (Configuration conf : Configuration.values()) { for (AssertionData data : assertionData) { testValidWith(sunPKCS11, data, conf); } } // Test invalid cases. testInvalidTranslateKey(sunPKCS11); testInvalidGenerateSecret(sunPKCS11); testInvalidGetKeySpec(sunPKCS11); System.out.println("TEST PASS - OK"); } private static void testValidWith(Provider sunPKCS11, AssertionData data, Configuration conf) throws Exception { System.out.println(sep + System.lineSeparator() + data.algo + " (with " + conf.name() + ")"); SecretKeyFactory skf = SecretKeyFactory.getInstance(data.algo, sunPKCS11); SecretKey derivedKey = switch (conf) { case PBEKeySpec -> skf.generateSecret(data.keySpec); case AnonymousPBEKey -> skf.translateKey(getAnonymousPBEKey( data.algo, data.keySpec)); }; BigInteger derivedKeyValue = i(derivedKey.getEncoded()); printHex("Derived Key", derivedKeyValue); if (!derivedKeyValue.equals(data.expectedKey)) { printHex("Expected Derived Key", data.expectedKey); throw new Exception("Expected Derived Key did not match"); } if (skf.translateKey(derivedKey) != derivedKey) { throw new Exception("SecretKeyFactory::translateKey must return " + "the same key when a P11PBEKey from the same token is " + "passed"); } testGetKeySpec(data, skf, derivedKey); if (sunJCE != null && data.algo.startsWith("PBKDF2")) { testTranslateP11PBEKeyToSunJCE(data.algo, (PBEKey) derivedKey); } } private static SecretKey getAnonymousPBEKey(String algorithm, PBEKeySpec keySpec) { return new PBEKey() { public byte[] getSalt() { return keySpec.getSalt(); } public int getIterationCount() { return keySpec.getIterationCount(); } public String getAlgorithm() { return algorithm; } public String getFormat() { return "RAW"; } public char[] getPassword() { return keySpec.getPassword(); } public byte[] getEncoded() { return new byte[keySpec.getKeyLength() / 8]; } }; } private static void printHex(String title, BigInteger b) { String repr = (b == null) ? "buffer is null" : b.toString(16); System.out.println(title + ": " + repr + System.lineSeparator()); } private static void testGetKeySpec(AssertionData data, SecretKeyFactory skf, SecretKey derivedKey) throws Exception { System.out.println(sep + System.lineSeparator() + "SecretKeyFactory::getKeySpec() (for " + data.algo + ")"); KeySpec skfKeySpec = skf.getKeySpec(derivedKey, PBEKeySpec.class); if (skfKeySpec instanceof PBEKeySpec skfPBEKeySpec) { char[] specPassword = skfPBEKeySpec.getPassword(); byte[] specSalt = skfPBEKeySpec.getSalt(); int specIterations = skfPBEKeySpec.getIterationCount(); int specKeyLength = skfPBEKeySpec.getKeyLength(); System.out.println(" spec key length (bits): " + specKeyLength); System.out.println(" spec password: " + String.valueOf(specPassword)); System.out.println(" spec iteration count: " + specIterations); printHex(" spec salt", i(specSalt)); if (!Arrays.equals(specPassword, data.keySpec.getPassword())) { throw new Exception("Password differs"); } if (!Arrays.equals(specSalt, data.keySpec.getSalt())) { throw new Exception("Salt differs"); } if (specIterations != data.keySpec.getIterationCount()) { throw new Exception("Iteration count differs"); } if (specKeyLength != data.keySpec.getKeyLength()) { throw new Exception("Key length differs"); } } else { throw new Exception("Invalid key spec type: " + skfKeySpec); } // Test extracting key bytes with a SecretKeySpec. SecretKeySpec secretKeySpec = (SecretKeySpec) skf.getKeySpec(derivedKey, SecretKeySpec.class); if (!Arrays.equals(secretKeySpec.getEncoded(), derivedKey.getEncoded())) { throw new Exception("Unable to extract key bytes with a " + "SecretKeySpec"); } } private static void testTranslateP11PBEKeyToSunJCE(String algorithm, PBEKey p11PbeK) throws Exception { System.out.println(sep + System.lineSeparator() + "Translate P11PBEKey to SunJCE (for " + algorithm + ")"); SecretKey jceK = SecretKeyFactory.getInstance(algorithm, sunJCE) .translateKey(p11PbeK); BigInteger jceEncoded = i(jceK.getEncoded()); printHex(" translated to SunJCE", jceEncoded); if (jceK instanceof PBEKey jcePbeK) { if (!Arrays.equals(jcePbeK.getPassword(), p11PbeK.getPassword())) { throw new Exception("Password differs"); } if (!Arrays.equals(jcePbeK.getSalt(), p11PbeK.getSalt())) { throw new Exception("Salt differs"); } if (jcePbeK.getIterationCount() != p11PbeK.getIterationCount()) { throw new Exception("Iteration count differs"); } if (!jceEncoded.equals(i(p11PbeK.getEncoded()))) { throw new Exception("Encoded key differs"); } } else { throw new Exception("Unexpected key type for SunJCE key: " + jceK.getClass().getName()); } } @FunctionalInterface private interface Action { void run() throws Exception; } private static void assertThrows(Class expectedExc, String expectedMsg, Action action) throws Exception { String shtExpected = "Should have thrown '" + expectedExc.getSimpleName() + ": " + expectedMsg + "'"; try { action.run(); } catch (Exception e) { if (expectedExc.isAssignableFrom(e.getClass()) && e.getMessage().equals(expectedMsg)) { return; } e.printStackTrace(); throw new Exception(shtExpected + ", but threw '" + e.getClass().getSimpleName() + ": " + e.getMessage() + "'"); } throw new Exception(shtExpected + ", but it didn't throw"); } private static void testInvalidTranslateKey(Provider sunPKCS11) throws Exception { System.out.println(sep + System.lineSeparator() + "Invalid SecretKeyFactory::translateKey tests"); SecretKeyFactory skf1 = SecretKeyFactory.getInstance( pbkdf2WithHmacSHA512Data.algo, sunPKCS11); SecretKeyFactory skf2 = SecretKeyFactory.getInstance("AES", sunPKCS11); SecretKeyFactory skf3 = SecretKeyFactory.getInstance( pbkdf2WithHmacSHA256Data.algo, sunPKCS11); PBEKey p11PbkdfKey = (PBEKey) skf3.translateKey(getAnonymousPBEKey( skf3.getAlgorithm(), pbkdf2WithHmacSHA256Data.keySpec)); Class e = InvalidKeyException.class; System.out.println(" * Non-PBEKey key to PBE SecretKeyFactory"); assertThrows(e, "PBE service requires a PBE key", () -> skf3.translateKey(new SecretKeySpec( new byte[10], skf3.getAlgorithm()))); System.out.println(" * PBEKey key to PBE SecretKeyFactory of a " + "different algorithm"); assertThrows(e, "Cannot use a " + pbkdf2WithHmacSHA256Data.algo + " key for a " + pbkdf2WithHmacSHA512Data.algo + " service", () -> skf1.translateKey(p11PbkdfKey)); System.out.println(" * Non-AES PBEKey key to AES SecretKeyFactory"); String keyAlg1 = "HmacPBESHA1"; PBEKeySpec kSpec1 = new PBEKeySpec(pwd, salt, 1, 16); assertThrows(e, "Cannot use a " + keyAlg1 + " key for a " + skf2.getAlgorithm() + " service", () -> skf2.translateKey(getAnonymousPBEKey(keyAlg1, kSpec1))); System.out.println(" * Inconsistent key length between key and its " + "algorithm"); String keyAlg2 = "PBEWithHmacSHA1AndAES_128"; assertThrows(e, InvalidKeySpecException.class.getName() + ": Key " + "length is invalid for " + keyAlg2 + " (expecting 128 but " + "was " + kSpec1.getKeyLength() + ")", () -> skf2.translateKey(getAnonymousPBEKey(keyAlg2, kSpec1))); System.out.println(" * Invalid key length in bits"); PBEKeySpec kSpec2 = new PBEKeySpec(pwd, salt, 1); assertThrows(e, InvalidKeySpecException.class.getName() + ": Key " + "length must be multiple of 8 and greater than zero", () -> skf3.translateKey(getAnonymousPBEKey( skf3.getAlgorithm(), kSpec2))); System.out.println(); } private static void testInvalidGenerateSecret(Provider sunPKCS11) throws Exception { System.out.println(sep + System.lineSeparator() + "Invalid SecretKeyFactory::generateSecret tests"); SecretKeyFactory skf1 = SecretKeyFactory.getInstance( pbkdf2WithHmacSHA512Data.algo, sunPKCS11); SecretKeyFactory skf2 = SecretKeyFactory.getInstance("AES", sunPKCS11); Class e = InvalidKeySpecException.class; System.out.println(" * Missing salt and iteration count"); assertThrows(e, "Salt not found", () -> skf1.generateSecret(new PBEKeySpec(pwd))); System.out.println(" * Invalid key length in bits"); String msg = "Key length must be multiple of 8 and greater than zero"; assertThrows(e, msg, () -> skf1.generateSecret(new PBEKeySpec(pwd, salt, 1))); assertThrows(e, msg, () -> skf1.generateSecret(new PBEKeySpec(pwd, salt, 1, 3))); System.out.println(" * PBEKeySpec to non-PBE SecretKeyFactory"); PBEKeySpec kSpec = new PBEKeySpec(pwd, salt, 1, 16); assertThrows(e, "Unsupported spec: javax.crypto.spec.PBEKeySpec", () -> skf2.generateSecret(kSpec)); System.out.println(); } private static void testInvalidGetKeySpec(Provider sunPKCS11) throws Exception { System.out.println(sep + System.lineSeparator() + "Invalid SecretKeyFactory::getKeySpec tests"); SecretKeyFactory skf1 = SecretKeyFactory.getInstance( pbkdf2WithHmacSHA256Data.algo, sunPKCS11); SecretKeyFactory skf2 = SecretKeyFactory.getInstance( "AES", sunPKCS11); PBEKey p11PbkdfKey = (PBEKey) skf1.translateKey(getAnonymousPBEKey( skf1.getAlgorithm(), pbkdf2WithHmacSHA256Data.keySpec)); Class e = InvalidKeySpecException.class; System.out.println(" * null KeySpec class"); assertThrows(e, "key and keySpec must not be null", () -> skf1.getKeySpec(p11PbkdfKey, null)); System.out.println(" * Invalid key type for PBEKeySpec"); assertThrows(e, "Unsupported spec: " + PBEKeySpec.class.getName(), () -> skf1.getKeySpec(new SecretKeySpec(new byte[16], skf1.getAlgorithm()), PBEKeySpec.class)); System.out.println(" * Invalid PBE key and PBEKeySpec for " + skf2.getAlgorithm() + " SecretKeyFactory"); assertThrows(e, "Unsupported spec: " + PBEKeySpec.class.getName(), () -> skf2.getKeySpec(p11PbkdfKey, PBEKeySpec.class)); System.out.println(); } public static void main(String[] args) throws Exception { main(new TestPBKD()); } }
------------- PR Comment: https://git.openjdk.org/jdk/pull/24068#issuecomment-2778910705 From aph at openjdk.org Fri Apr 4 14:39:04 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 4 Apr 2025 14:39:04 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 16:31:39 GMT, Jamil Nimeh wrote: > This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. > > There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4517: > 4515: bSet[0] = v16; bSet[1] = v17; bSet[2] = v18; bSet[3] = v19; > 4516: cSet[0] = v20; cSet[1] = v21; cSet[2] = v22; cSet[3] = v23; > 4517: dSet[0] = v24; dSet[1] = v25; dSet[2] = v26; dSet[3] = v27; Suggestion: bSet[0] = workSt[4]; bSet[1] = workSt[5]; bSet[2] = workSt[6]; bSet[3] = workSt[7]; cSet[0] = workSt[8]; cSet[1] = workSt[9]; cSet[2] = workSt[10]; cSet[3] = workSt[11]; dSet[0] = workSt[12]; dSet[1] = workSt[13]; dSet[2] = workSt[14]; dSet[3] = workSt[15]; How about something like this? The mapping from index to register, and from specification to implementation, is easier for this reviewer to understand. or maybe (better?) define a function, such that: regs_for_quarter_round(bSet, workSt, 4, 5, 6, 7); regs_for_quarter_round(cSet, workSt, 8, 9, 10, 11); regs_for_quarter_round(dSet, workSt, 12, 13, 14, 15); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24420#discussion_r2028932064 From duke at openjdk.org Fri Apr 4 14:51:58 2025 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 4 Apr 2025 14:51:58 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal In-Reply-To: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com> References: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com> Message-ID: On Fri, 4 Apr 2025 14:12:55 GMT, Sean Mullan wrote: > > > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. > > > > > > I agree with most of these, however the permissions infrastructure _itself_ is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself. > > Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)? The [`wildfly-elytron`](https://github.com/wildfly-security/wildfly-elytron) project uses `Permission` and `PermissionCollection` as a standalone basic API to represent user authorization permissions. Some examples include `LoginPermission` and `RunAsPrincipalPermission`, and a special `NoPermission` class which is useful in certain situations. The user authorization mechanism does not use policy files, security manager APIs, `AccessController` or any other JAAS-adjacent API for this purpose. Security contexts are managed completely separately from the JDK using thread local scoping (planned to move to `ScopedValue` someday if/when it becomes available). Permissions are checked against the user security context (`org.wildfly.security.auth.server.SecurityIdentity`) by authorization-sensitive operations in both server and user code. The `AllPermission` class is used for "superuser" authorization situations, and cases where the deployer opts out of authorization checks for whatever reason (for example, testing). We use it for role-based access control of the application server itself when access control checks pass, as well for superuser authorization cases, and probably other cases I'm forgetting about (it's one of those things that we always assumed would stick around forever, so we used it without a second thought). `AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492 From duke at openjdk.org Fri Apr 4 15:02:23 2025 From: duke at openjdk.org (robert engels) Date: Fri, 4 Apr 2025 15:02:23 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote: > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. > > The current API note in these classes was reused as the deprecation text. > > Release Note: https://bugs.openjdk.org/browse/JDK-8353680 Sad day when the Java backwards compatibility promise is thrown out the window because a bunch of developers need work to do. Removing these classes does nothing towards the reduced api surface the goal of removing the SM had. I suspect these classes haven?t changed in 20 years. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778984443 From daniel.fuchs at oracle.com Fri Apr 4 15:04:19 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 4 Apr 2025 16:04:19 +0100 Subject: RFR: 8348967: Deprecate security permission classes for removal In-Reply-To: References: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com> Message-ID: Hi David, Are there other subclasses of Permission that this framework uses? More specifically - would it be fine to deprecate NetPermission, URLPermission and SocketPermission classes? best regards, -- daniel On 04/04/2025 15:51, David M. Lloyd wrote: >> Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)? > > The [`wildfly-elytron`](https://github.com/wildfly-security/wildfly-elytron) project uses `Permission` and `PermissionCollection` as a standalone basic API to represent user authorization permissions. Some examples include `LoginPermission` and `RunAsPrincipalPermission`, and a special `NoPermission` class which is useful in certain situations. > > The user authorization mechanism does not use policy files, security manager APIs, `AccessController` or any other JAAS-adjacent API for this purpose. > > Security contexts are managed completely separately from the JDK using thread local scoping (planned to move to `ScopedValue` someday if/when it becomes available). Permissions are checked against the user security context (`org.wildfly.security.auth.server.SecurityIdentity`) by authorization-sensitive operations in both server and user code. > > The `AllPermission` class is used for "superuser" authorization situations, and cases where the deployer opts out of authorization checks for whatever reason (for example, testing). We use it for role-based access control of the application server itself when access control checks pass, as well for superuser authorization cases, and probably other cases I'm forgetting about (it's one of those things that we always assumed would stick around forever, so we used it without a second thought). > > `AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492 From vpaprotski at openjdk.org Fri Apr 4 15:17:03 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Fri, 4 Apr 2025 15:17:03 GMT Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64 [v8] In-Reply-To: <5m9xiUkcb41c47vcLKS3kvsK9Jhh1y7PsNRHcffa8ug=.5785cdda-e50e-410a-a139-5554d70bfdff@github.com> References: <5WNrv1s7Bp7hLwSVGqoPw9ycCSHK0Zyka65DpAjnB2s=.31243a29-4fbb-4c21-b671-45470d043335@github.com> <5m9xiUkcb41c47vcLKS3kvsK9Jhh1y7PsNRHcffa8ug=.5785cdda-e50e-410a-a139-5554d70bfdff@github.com> Message-ID: On Fri, 4 Apr 2025 14:26:30 GMT, Sean Mullan wrote: > > Done I think: https://bugs.openjdk.org/browse/JDK-8297970 > > Is this link correct? This issue was fixed in JDK 20. Sorry.. copy/paste didnt notice.. https://bugs.openjdk.org/browse/JDK-8353670 (also ends in *70!) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2779021494 From david.lloyd at redhat.com Fri Apr 4 15:22:48 2025 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 4 Apr 2025 10:22:48 -0500 Subject: RFR: 8348967: Deprecate security permission classes for removal In-Reply-To: References: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com> Message-ID: Greetings Daniel, For the sake of discussion, I will look at these classes as classifiable into two groups: classes that we use (or are useful) only in the context of a security manager, and classes that we use (or are useful) independently of any other JDK API. I would put all three of these classes (`NetPermission`, `URLPermission`, and `SocketPermission`) in the former category, as well as the other non-`AllPermission` classes listed in Sean's PR: we (and our users) would use them only in the context of a security manager, so when that is gone, our need to support these classes goes with it, as far as I can tell. The classes that we would continue to require on an ongoing basis (to my knowledge) would include `Permission` itself (obviously), `AllPermission`, and the `BasicPermission` base class (which also seems to be subclassed by many third-party projects). On Fri, Apr 4, 2025 at 10:05?AM Daniel Fuchs wrote: > Hi David, > > Are there other subclasses of Permission that this framework uses? > More specifically - would it be fine to deprecate NetPermission, > URLPermission and SocketPermission classes? > > best regards, > > -- daniel > > On 04/04/2025 15:51, David M. Lloyd wrote: > >> Can you elaborate or give an example/pointer to code on how it uses > `AllPermission` w/o the corresponding SM APIs and infrastructure (policy > files, `AccessController`, etc)? > > > > The [`wildfly-elytron`]( > https://github.com/wildfly-security/wildfly-elytron) project uses > `Permission` and `PermissionCollection` as a standalone basic API to > represent user authorization permissions. Some examples include > `LoginPermission` and `RunAsPrincipalPermission`, and a special > `NoPermission` class which is useful in certain situations. > > > > The user authorization mechanism does not use policy files, security > manager APIs, `AccessController` or any other JAAS-adjacent API for this > purpose. > > > > Security contexts are managed completely separately from the JDK using > thread local scoping (planned to move to `ScopedValue` someday if/when it > becomes available). Permissions are checked against the user security > context (`org.wildfly.security.auth.server.SecurityIdentity`) by > authorization-sensitive operations in both server and user code. > > > > The `AllPermission` class is used for "superuser" authorization > situations, and cases where the deployer opts out of authorization checks > for whatever reason (for example, testing). We use it for role-based access > control of the application server itself when access control checks pass, > as well for superuser authorization cases, and probably other cases I'm > forgetting about (it's one of those things that we always assumed would > stick around forever, so we used it without a second thought). > > > > `AllPermission` is an integral concept of permission sets, and thus we > would be obliged to create our own if the JDK one disappeared, causing > compatibility problems due to the class moving to a new package from the > point of view of consumers. Its destiny should be tied to that of > `Permission` itself in my opinion, because it is pretty fundamental. > > > > ------------- > > > > PR Comment: > https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492 > > -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.org Fri Apr 4 15:38:50 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 4 Apr 2025 15:38:50 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal In-Reply-To: References: Message-ID: <-lk13iK-xcpj57om_W2geIwkx_35JQSE9sKcMzEaMec=.7b41608b-e63d-47ab-aee6-ecdafc2f635f@github.com> On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote: > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. > > The current API note in these classes was reused as the deprecation text. > > Release Note: https://bugs.openjdk.org/browse/JDK-8353680 Thanks David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2779110623 From jnimeh at openjdk.org Fri Apr 4 16:13:49 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 4 Apr 2025 16:13:49 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 14:35:59 GMT, Andrew Haley wrote: >> This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. >> >> There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4517: > >> 4515: bSet[0] = v16; bSet[1] = v17; bSet[2] = v18; bSet[3] = v19; >> 4516: cSet[0] = v20; cSet[1] = v21; cSet[2] = v22; cSet[3] = v23; >> 4517: dSet[0] = v24; dSet[1] = v25; dSet[2] = v26; dSet[3] = v27; > > Suggestion: > > bSet[0] = workSt[4]; bSet[1] = workSt[5]; bSet[2] = workSt[6]; bSet[3] = workSt[7]; > cSet[0] = workSt[8]; cSet[1] = workSt[9]; cSet[2] = workSt[10]; cSet[3] = workSt[11]; > dSet[0] = workSt[12]; dSet[1] = workSt[13]; dSet[2] = workSt[14]; dSet[3] = workSt[15]; > > How about something like this? The mapping from index to register, and from specification to implementation, is easier for this reviewer to understand. > > or maybe (better?) define a function, such that: > > > regs_for_quarter_round(bSet, workSt, 4, 5, 6, 7); > regs_for_quarter_round(cSet, workSt, 8, 9, 10, 11); > regs_for_quarter_round(dSet, workSt, 12, 13, 14, 15); I like either approach, I'll try the function route. Either way it definitely helps make things more clear. Putting this in terms of the workSt indicies maps more closely to how things are described in the RFC. Good call! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24420#discussion_r2029095293 From mullan at openjdk.org Fri Apr 4 16:22:47 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 16:22:47 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal In-Reply-To: References: <9F3RrRIQCRygi1beKlVOjCKbHaF-rDFh63UG1leNDq8=.24f6dca0-e6f6-4fed-ac9a-1355bb73c8be@github.com> Message-ID: On Fri, 4 Apr 2025 14:49:36 GMT, David M. Lloyd wrote: > `AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental. Yes, I can see now that this permission is different than the other JDK specific permissions that are being deprecated for removal. I will leave it as-is for now, undeprecated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2779219067 From duke at openjdk.org Fri Apr 4 16:25:53 2025 From: duke at openjdk.org (David M. Lloyd) Date: Fri, 4 Apr 2025 16:25:53 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote: > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. > > The current API note in these classes was reused as the deprecation text. > > Release Note: https://bugs.openjdk.org/browse/JDK-8353680 Great, thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2779226283 From rriggs at openjdk.org Fri Apr 4 16:39:27 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 4 Apr 2025 16:39:27 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v2] In-Reply-To: References: Message-ID: <-VbTKqOznNLKI7R7AHZEECmO_Gfu5aYoFpE7T2FriqY=.79b97a1a-1787-465c-b6a8-f590a01c8f9b@github.com> > Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add SuppressWarnings to a Windows source missed earlier. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24444/files - new: https://git.openjdk.org/jdk/pull/24444/files/3ae4467e..1fa560a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444 PR: https://git.openjdk.org/jdk/pull/24444 From mullan at openjdk.org Fri Apr 4 17:21:58 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 17:21:58 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures In-Reply-To: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> Message-ID: On Tue, 1 Apr 2025 20:53:01 GMT, Artur Barashev wrote: > Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). > https://www.rfc-editor.org/rfc/rfc9155.html test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS12.java line 28: > 26: * @bug 8340321 > 27: * @summary Disable SHA-1 in TLS/DTLS 1.2 signatures. > 28: * This test only covers TLS 1.2. What about TLS 1.3? Do we never include sha1 signature mechanisms? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24367#discussion_r2029178689 From duke at openjdk.org Fri Apr 4 17:46:39 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 4 Apr 2025 17:46:39 GMT Subject: RFR: 8349890 : Option -Djava.security.debug=x509,ava breaks special chars [v4] In-Reply-To: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> References: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> Message-ID: <8GonKLdOC9kgRjuCcoNBFPR7gX--3DgGsJMzT7bUlik=.a252d3c0-29fc-4598-95c5-a933562046b5@github.com> > **A DESCRIPTION OF THE PROBLEM :** > Enabling -Djava.security.debug=x509,ava affects how special characters in certificates are processed. The expected behavior is that debugging should not interfere with the normal encoding of certificate fields. > > **Fix:** > The Debugging will no longer interfere with these fields, unless you call toString(). Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: 8349890:Option -Djava.security.debug=x509,ava breaks special chars ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24360/files - new: https://git.openjdk.org/jdk/pull/24360/files/06bbe7d4..7cfa6ec7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24360&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24360&range=02-03 Stats: 119 lines in 2 files changed: 61 ins; 58 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24360/head:pull/24360 PR: https://git.openjdk.org/jdk/pull/24360 From duke at openjdk.org Fri Apr 4 17:46:39 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 4 Apr 2025 17:46:39 GMT Subject: RFR: 8349890 : Option -Djava.security.debug=x509,ava breaks special chars [v3] In-Reply-To: References: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> Message-ID: On Fri, 4 Apr 2025 13:51:33 GMT, Sean Mullan wrote: >> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: >> >> 8349890:Option -Djava.security.debug=x509,ava breaks special chars > > test/jdk/sun/security/x509/X500Name/PrintX500NameInDebugModeWithAvaOption.java line 39: > >> 37: public static void main(String[] args) throws Exception { >> 38: >> 39: X500Name name = new X500Name("cn=john doe + l=ca\\+lifornia + l =sf, O=?"); > > Use `X500Principal` objects for testing instead of `X500Name`. `X500Principal` is a public/standard API, so it is better to ensure that the issue is fixed via standard APIs. Then you also don't need the `@modules` line. > > Also change name of test to `PrintX500PrincipalInDebugModeWithAvaOption`. Changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24360#discussion_r2029214843 From abarashev at openjdk.org Fri Apr 4 17:53:49 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 4 Apr 2025 17:53:49 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures In-Reply-To: References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> Message-ID: <6F37pDaE4IkV0uLjHP-yJ7h_ZbDnwIHRTL_KM5rltX4=.16b93318-a119-4d6b-bcc4-146654e76db0@github.com> On Fri, 4 Apr 2025 17:18:44 GMT, Sean Mullan wrote: >> Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). >> https://www.rfc-editor.org/rfc/rfc9155.html > > test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS12.java line 28: > >> 26: * @bug 8340321 >> 27: * @summary Disable SHA-1 in TLS/DTLS 1.2 signatures. >> 28: * This test only covers TLS 1.2. > > What about TLS 1.3? Do we never include sha1 signature mechanisms? `ECDSA_SHA1` is actually supported in TLSv1.3. I'll add the v1.3 test then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24367#discussion_r2029223401 From vpaprotski at openjdk.org Fri Apr 4 17:55:48 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Fri, 4 Apr 2025 17:55:48 GMT Subject: RFR: 8353671: Remove dead code missed in JDK-8350459 In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 18:42:35 GMT, Volodymyr Paprotski wrote: > 8353671: Remove dead code missed in JDK-8350459 @ascarpino If you wouldn't mind, should be a quick one :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24423#issuecomment-2779414600 From mullan at openjdk.org Fri Apr 4 18:04:39 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 18:04:39 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal [v2] In-Reply-To: References: Message-ID: > Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. > > The current API note in these classes was reused as the deprecation text. > > Release Note: https://bugs.openjdk.org/browse/JDK-8353680 Sean Mullan has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'JDK-8348967' of gh:seanjmullan/jdk into JDK-8348967 - Revert "Initial revision." Undeprecate AllPermission. This reverts commit 38938d9d56672ecc374c3d86a891c95e6b164d02. - Remove trailing whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24445/files - new: https://git.openjdk.org/jdk/pull/24445/files/de5f360e..8dae2f8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=00-01 Stats: 19 lines in 8 files changed: 0 ins; 15 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24445/head:pull/24445 PR: https://git.openjdk.org/jdk/pull/24445 From rriggs at openjdk.org Fri Apr 4 18:21:29 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 4 Apr 2025 18:21:29 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v3] In-Reply-To: References: Message-ID: > Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Updated style of @Deprecated to match most existing @Deprecated annotations `since` comes before `forRemoval` No spaces around `=` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24444/files - new: https://git.openjdk.org/jdk/pull/24444/files/1fa560a4..bb18c1e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=01-02 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444 PR: https://git.openjdk.org/jdk/pull/24444 From rriggs at openjdk.org Fri Apr 4 18:26:50 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 4 Apr 2025 18:26:50 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal [v2] In-Reply-To: References: Message-ID: <4U4fHTMkZq09NuiU-svQOicKoYLqEMUmIyUcNZnTNgw=.09aa34d1-23a7-4c76-8050-727875c54ffe@github.com> On Fri, 4 Apr 2025 18:04:39 GMT, Sean Mullan wrote: >> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. >> >> The current API note in these classes was reused as the deprecation text. >> >> Release Note: https://bugs.openjdk.org/browse/JDK-8353680 > > Sean Mullan has updated the pull request incrementally with three additional commits since the last revision: > > - Merge branch 'JDK-8348967' of gh:seanjmullan/jdk into JDK-8348967 > - Revert "Initial revision." > Undeprecate AllPermission. > > This reverts commit 38938d9d56672ecc374c3d86a891c95e6b164d02. > - Remove trailing whitespace. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2743809469 From iris at openjdk.org Fri Apr 4 18:33:58 2025 From: iris at openjdk.org (Iris Clark) Date: Fri, 4 Apr 2025 18:33:58 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal [v2] In-Reply-To: References: Message-ID: <5KYDV4UYQqtRvB8n6oeHBpCV5MhrsKSQWsAjC_Rotg8=.28c75b48-6362-4970-96f8-b9f104e25d2a@github.com> On Fri, 4 Apr 2025 18:04:39 GMT, Sean Mullan wrote: >> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. >> >> The current API note in these classes was reused as the deprecation text. >> >> Release Note: https://bugs.openjdk.org/browse/JDK-8353680 > > Sean Mullan has updated the pull request incrementally with three additional commits since the last revision: > > - Merge branch 'JDK-8348967' of gh:seanjmullan/jdk into JDK-8348967 > - Revert "Initial revision." > Undeprecate AllPermission. > > This reverts commit 38938d9d56672ecc374c3d86a891c95e6b164d02. > - Remove trailing whitespace. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2743822700 From weijun at openjdk.org Fri Apr 4 18:40:39 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 4 Apr 2025 18:40:39 GMT Subject: RFR: 8350134: Support DHKEM with PKCS11 [v2] In-Reply-To: References: Message-ID: > This code change adds support for getting public key from an EC private key in PKCS #11. This is is necessary to support DHKEM for keys in SunPKCS11. The support is still not complete and there is no way to get the public key if the private key is unwrapped from an encrypted form. PKCS #11 3.0 defined CKA_PUBLIC_KEY_INFO but I haven't yet found a library supporting it. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8350134 - add key slicing support - the code change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23651/files - new: https://git.openjdk.org/jdk/pull/23651/files/60f76169..7fd44849 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23651&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23651&range=00-01 Stats: 170874 lines in 3876 files changed: 72340 ins; 75725 del; 22809 mod Patch: https://git.openjdk.org/jdk/pull/23651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23651/head:pull/23651 PR: https://git.openjdk.org/jdk/pull/23651 From iris at openjdk.org Fri Apr 4 18:40:50 2025 From: iris at openjdk.org (Iris Clark) Date: Fri, 4 Apr 2025 18:40:50 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v3] In-Reply-To: References: Message-ID: <9XnN5LLqYWAbbv3Smz9WTvMTZcbGwpGnQJtozSQm0Co=.ba9516ba-7fdc-4694-88e4-93a78a788099@github.com> On Fri, 4 Apr 2025 18:21:29 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission >> >> @Deprecated(forRemoval = true, since="25") >> Is added to each class and the existing @apiNote is converted to @deprected > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Updated style of @Deprecated to match most existing @Deprecated annotations > `since` comes before `forRemoval` > No spaces around `=` Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24444#pullrequestreview-2743835110 From abarashev at openjdk.org Fri Apr 4 18:41:07 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 4 Apr 2025 18:41:07 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures [v2] In-Reply-To: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> Message-ID: > Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). > https://www.rfc-editor.org/rfc/rfc9155.html Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Add TLSv1.3 unit test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24367/files - new: https://git.openjdk.org/jdk/pull/24367/files/b45f6651..efe2b96b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24367&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24367&range=00-01 Stats: 86 lines in 3 files changed: 74 ins; 9 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24367.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24367/head:pull/24367 PR: https://git.openjdk.org/jdk/pull/24367 From abarashev at openjdk.org Fri Apr 4 18:41:08 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 4 Apr 2025 18:41:08 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures [v2] In-Reply-To: References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> Message-ID: On Wed, 2 Apr 2025 15:58:00 GMT, Artur Barashev wrote: >> test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureDTLS12.java line 34: >> >>> 32: */ >>> 33: >>> 34: import java.lang.Override; >> >> You shouldn't have to import java.lang.Override > > Indeed, thanks! For some reason my IntelliJ inserts this import on "Optimize Imports" command, I need to find out why. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24367#discussion_r2029276041 From abarashev at openjdk.org Fri Apr 4 18:41:08 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 4 Apr 2025 18:41:08 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures [v2] In-Reply-To: <6F37pDaE4IkV0uLjHP-yJ7h_ZbDnwIHRTL_KM5rltX4=.16b93318-a119-4d6b-bcc4-146654e76db0@github.com> References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> <6F37pDaE4IkV0uLjHP-yJ7h_ZbDnwIHRTL_KM5rltX4=.16b93318-a119-4d6b-bcc4-146654e76db0@github.com> Message-ID: On Fri, 4 Apr 2025 17:50:58 GMT, Artur Barashev wrote: >> test/jdk/sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS12.java line 28: >> >>> 26: * @bug 8340321 >>> 27: * @summary Disable SHA-1 in TLS/DTLS 1.2 signatures. >>> 28: * This test only covers TLS 1.2. >> >> What about TLS 1.3? Do we never include sha1 signature mechanisms? > > `ECDSA_SHA1` is actually supported in TLSv1.3. I'll add the v1.3 test then. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24367#discussion_r2029275775 From rriggs at openjdk.org Fri Apr 4 19:00:02 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 4 Apr 2025 19:00:02 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v4] In-Reply-To: References: Message-ID: > Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Remove unused import of LinkPermission ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24444/files - new: https://git.openjdk.org/jdk/pull/24444/files/bb18c1e6..25aa6099 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444 PR: https://git.openjdk.org/jdk/pull/24444 From mullan at openjdk.org Fri Apr 4 19:07:59 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 19:07:59 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v4] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission >> >> @Deprecated(forRemoval = true, since="25") >> Is added to each class and the existing @apiNote is converted to @deprected > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import of LinkPermission Some copyright dates have not been updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24444#issuecomment-2779539268 From rriggs at openjdk.org Fri Apr 4 19:15:29 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 4 Apr 2025 19:15:29 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v5] In-Reply-To: References: Message-ID: > Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Update copyright in WindowsFileCopy ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24444/files - new: https://git.openjdk.org/jdk/pull/24444/files/25aa6099..c1457493 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444 PR: https://git.openjdk.org/jdk/pull/24444 From mullan at openjdk.org Fri Apr 4 19:15:29 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 4 Apr 2025 19:15:29 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v4] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission >> >> @Deprecated(forRemoval = true, since="25") >> Is added to each class and the existing @apiNote is converted to @deprected > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import of LinkPermission src/java.base/share/classes/java/io/FilePermission.java line 87: > 85: > 86: @Deprecated(since="25", forRemoval=true) > 87: @SuppressWarnings("removal") Is this leftover? You already add it to the methods that need it. src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 202: > 200: } > 201: > 202: @SuppressWarnings("removal") This should not be necessary. src/java.logging/share/classes/java/util/logging/LoggingPermission.java line 48: > 46: */ > 47: > 48: @Deprecated(forRemoval = true, since="25") This order is different than other classes, maybe make it consistent? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029312409 PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029308725 PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029311303 From rriggs at openjdk.org Fri Apr 4 19:22:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 4 Apr 2025 19:22:46 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v6] In-Reply-To: References: Message-ID: > Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary SuppressWarnings and correct Deprecated annotation style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24444/files - new: https://git.openjdk.org/jdk/pull/24444/files/c1457493..9a9417a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=04-05 Stats: 3 lines in 3 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444 PR: https://git.openjdk.org/jdk/pull/24444 From weijun at openjdk.org Fri Apr 4 19:56:04 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 4 Apr 2025 19:56:04 GMT Subject: RFR: 8350134: Support DHKEM with PKCS11 [v3] In-Reply-To: References: Message-ID: > This code change adds supports for getting public key from an EC private key and slicing a secret key in PKCS #11. These are necessary to support DHKEM for keys in SunPKCS11. The first support is still not complete and there is no way to get the public key if the private key is unwrapped from an encrypted form. PKCS #11 3.0 defined CKA_PUBLIC_KEY_INFO but I haven't yet found a library supporting it. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: revert auth support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23651/files - new: https://git.openjdk.org/jdk/pull/23651/files/7fd44849..e8c2f8a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23651&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23651&range=01-02 Stats: 61 lines in 1 file changed: 2 ins; 46 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/23651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23651/head:pull/23651 PR: https://git.openjdk.org/jdk/pull/23651 From abarashev at openjdk.org Fri Apr 4 20:44:28 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 4 Apr 2025 20:44:28 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures [v3] In-Reply-To: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> Message-ID: <6xhofgGpQXmRoQNfiqTmn8sJwgxFaeJwqCrbD9NjeJg=.6be6ffee-603f-4b70-90ee-ef615d4fa9f7@github.com> > Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). > https://www.rfc-editor.org/rfc/rfc9155.html Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Disable ECDSA_SHA1 to be used for TLSv1.3 handshake signatures ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24367/files - new: https://git.openjdk.org/jdk/pull/24367/files/efe2b96b..4335dfc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24367&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24367&range=01-02 Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24367.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24367/head:pull/24367 PR: https://git.openjdk.org/jdk/pull/24367 From duke at openjdk.org Fri Apr 4 21:40:55 2025 From: duke at openjdk.org (duke) Date: Fri, 4 Apr 2025 21:40:55 GMT Subject: Withdrawn: 8225739: sun/security/pkcs11/tls/tls12/FipsModeTLS12.java is not reliable In-Reply-To: <3Y-OWPpeWf2LfdUUllVANzvs9LnldUWFMKL0IaMowB0=.a25b90df-fbc1-42f3-b132-9f3c4818e480@github.com> References: <3Y-OWPpeWf2LfdUUllVANzvs9LnldUWFMKL0IaMowB0=.a25b90df-fbc1-42f3-b132-9f3c4818e480@github.com> Message-ID: On Fri, 17 Jan 2025 17:24:57 GMT, Martin Balao wrote: > Hello, > > I would like to propose a solution for this test that makes it more clear when it's skipped. > > Regards, > Martin.- This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23177 From wetmore at openjdk.org Fri Apr 4 23:07:49 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 4 Apr 2025 23:07:49 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 21:43:19 GMT, Valerie Peng wrote: > This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. > > This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. > > Thanks in advance for the review~ The rest looks good. Nice to get this done finally! src/java.base/share/classes/sun/security/ssl/Utilities.java line 150: > 148: String sanitizedAlg = digestAlg.replace("-", ""); > 149: return switch (sanitizedAlg) { > 150: case "SHA256", "SHA384", "SHA512" -> "HKDF-" + sanitizedAlg; This is a nit, but currently we don't have SHA512 in `CipherSuite.HashAlg`. You can leave it for any future enhancements. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24393#pullrequestreview-2744199375 PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2029495768 From wetmore at openjdk.org Fri Apr 4 23:07:51 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 4 Apr 2025 23:07:51 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API In-Reply-To: <8UNuDQR_eQ2zm91c6_AUgT7pZEqbOx6kLmtyjZXgnxk=.e0280c9e-f2a1-49f6-9d1d-e5235638b522@github.com> References: <8UNuDQR_eQ2zm91c6_AUgT7pZEqbOx6kLmtyjZXgnxk=.e0280c9e-f2a1-49f6-9d1d-e5235638b522@github.com> Message-ID: On Thu, 3 Apr 2025 00:51:44 GMT, Valerie Peng wrote: >> src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 120: >> >>> 118: SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret", >>> 119: HKDFParameterSpec.ofExtract().addSalt(zeros) >>> 120: .addIKM(ikm).extractOnly()); >> >> Maybe no need for `addSalt(zeros)`. I remember salt is by default zeros for HKDF. > > Yes, I am on the fence about this. Given the specified value is the same as the default, it can be removed. I kept it there so the new code matches the original code completely. Not much difference either way I think. I like having it there to communicate that is really the intent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2029534765 From liach at openjdk.org Sat Apr 5 00:37:48 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 5 Apr 2025 00:37:48 GMT Subject: RFR: 8254622: Hide superclasses from conditionally exported packages In-Reply-To: References: Message-ID: <3TeN5yxeLsHqA9fv2BBz4ErEn0y8zXfHuct9uvc6cak=.19223c83-732e-4ead-82fb-b5f0bb422e02@github.com> On Fri, 4 Apr 2025 13:36:19 GMT, Hannes Walln?fer wrote: > Please review an enhancement to treat classes and interfaces that are not included and not unconditionally exported as hidden. This means they do not show up in the generated documentation even if they are implemented or extended by a documented type. > > This change makes the `@hidden` JavaDoc tag unnecessary in two internal base classes that previously used it, `jdk.internal.vm.vector.VectorSupport` and `jdk.internal.event.Event`. The generated documentation is unchanged. > > The change also adds support for the `@hidden` JavaDoc tag in interfaces, which was previously missing, and adds coverage to `TestHiddenTag.java`. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java line 165: > 163: for (TypeMirror type : interfaces) { > 164: TypeElement tDoc = utils.asTypeElement(type); > 165: if (!(utils.isPublic(tDoc) || utils.isLinkable(tDoc)) || utils.isHidden(tDoc)) { This `(!isPublicOrProtected && !isLinkable) || isHidden` trio appears a few times. The conditions are negated and wrapped in parentheses so it is easily confusing on the web; can we extract this check into a new utils method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24446#discussion_r2029581822 From sviswanathan at openjdk.org Sat Apr 5 00:44:56 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Sat, 5 Apr 2025 00:44:56 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 07:38:34 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reacting to comment by Sandhya. src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 339: > 337: > 338: // levels 2 to 7 are done in 2 batches, by first saving half of the coefficients > 339: // from level 1 into memory, doing all the level 2 to level 7 computations In line number 344 - 347, we seem to be storing all the coefficients from level 1 into memory. src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 345: > 343: > 344: store4Xmms(coeffs, 0, xmm0_3, _masm); > 345: store4Xmms(coeffs, 4 * XMMBYTES, xmm4_7, _masm); This seems to be unnecessary store. src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 370: > 368: loadPerm(xmm16_19, perms, nttL4PermsIdx, _masm); > 369: loadPerm(xmm12_15, perms, nttL4PermsIdx + 64, _masm); > 370: load4Xmms(xmm24_27, zetas, 4 * 512, _masm); // for level 3 The comment // for level3 is not relevant here and could be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2029437396 PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2029578599 PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2029583308 From swen at openjdk.org Sat Apr 5 01:30:49 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 5 Apr 2025 01:30:49 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes [v2] In-Reply-To: References: Message-ID: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> > During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10 anonymous classes, which slows down the startup. This PR is to improve KnownOIDs and eliminate unnecessary embedded classes. > > > Here's how to reproduce this: > > > public class Startup { > public static void main(String[] args) {} > } > > > > java -verbose:class Startup > > > > [0.665s][info][class,load] sun.security.util.KnownOIDs > [0.666s][info][class,load] sun.security.util.KnownOIDs$1 > [0.667s][info][class,load] sun.security.util.KnownOIDs$2 > [0.667s][info][class,load] sun.security.util.KnownOIDs$3 > [0.668s][info][class,load] sun.security.util.KnownOIDs$4 > [0.668s][info][class,load] sun.security.util.KnownOIDs$5 > [0.668s][info][class,load] sun.security.util.KnownOIDs$6 > [0.668s][info][class,load] sun.security.util.KnownOIDs$7 > [0.669s][info][class,load] sun.security.util.KnownOIDs$8 > [0.669s][info][class,load] sun.security.util.KnownOIDs$9 > [0.669s][info][class,load] sun.security.util.KnownOIDs$10 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @valeriepeng ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23411/files - new: https://git.openjdk.org/jdk/pull/23411/files/b14f35c6..98886a0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23411&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23411&range=00-01 Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23411/head:pull/23411 PR: https://git.openjdk.org/jdk/pull/23411 From duke at openjdk.org Sat Apr 5 03:51:00 2025 From: duke at openjdk.org (duke) Date: Sat, 5 Apr 2025 03:51:00 GMT Subject: Withdrawn: 8348432: Use block size as the default Hmac key length for JDK providers In-Reply-To: <69YqQmCsaap5PDO88Iju4_MEu3Tj5kOo_2uBVFdhCII=.3ea510be-9397-4adb-bb24-e6bf5e7a51d7@github.com> References: <69YqQmCsaap5PDO88Iju4_MEu3Tj5kOo_2uBVFdhCII=.3ea510be-9397-4adb-bb24-e6bf5e7a51d7@github.com> Message-ID: <0tBouJhs5vwS_mX-zFo3ei5YClPnpq_e15_8G8PgJqI=.35aeb1f2-a949-4a58-a060-54cf6e569b49@github.com> On Fri, 7 Feb 2025 22:19:41 GMT, Valerie Peng wrote: > Could someone help review this straight forward change? > > Changing to use block size instead of the hash output length as the default Hmac key sizes. The relevant regression tests have been adjusted accordingly as well. > > Thanks, > Valerie This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23526 From aturbanov at openjdk.org Sat Apr 5 16:49:58 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 5 Apr 2025 16:49:58 GMT Subject: RFR: 8353478: Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 21:41:57 GMT, Sergey Kuksenko wrote: > Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms. test/micro/org/openjdk/bench/javax/crypto/full/KEMBench.java line 69: > 67: @OperationsPerInvocation(SET_SIZE) > 68: public void encapsulate(Blackhole bh) throws InvalidKeyException { > 69: for(KeyPair kp : keys) { Suggestion: for (KeyPair kp : keys) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24369#discussion_r2029915714 From valeriep at openjdk.org Sat Apr 5 19:12:23 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Sat, 5 Apr 2025 19:12:23 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v2] In-Reply-To: References: Message-ID: > This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. > > This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. > > Thanks in advance for the review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: added default deriveData method to SSLKeyDerivation interface and refactored code to remove unused AlgorithmParameterSpec argument. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24393/files - new: https://git.openjdk.org/jdk/pull/24393/files/cfa422e4..320c49aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=00-01 Stats: 222 lines in 15 files changed: 38 ins; 75 del; 109 mod Patch: https://git.openjdk.org/jdk/pull/24393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24393/head:pull/24393 PR: https://git.openjdk.org/jdk/pull/24393 From skuksenko at openjdk.org Sun Apr 6 00:32:17 2025 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Sun, 6 Apr 2025 00:32:17 GMT Subject: RFR: 8353478: Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms [v2] In-Reply-To: References: Message-ID: <3uAVtfSLbHVgOMVltddUOxFHHjIH27A3CjPcfTsnmfY=.3a040e06-29fc-4405-9be2-b6af125318a7@github.com> > Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms. Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: Update test/micro/org/openjdk/bench/javax/crypto/full/KEMBench.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24369/files - new: https://git.openjdk.org/jdk/pull/24369/files/b7e439aa..a9296af8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24369&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24369&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24369.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24369/head:pull/24369 PR: https://git.openjdk.org/jdk/pull/24369 From jpai at openjdk.org Mon Apr 7 06:38:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Apr 2025 06:38:14 GMT Subject: RFR: 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes instances leading to higher memory footprint Message-ID: Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787. As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application. The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache. Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm (details in a comment of this PR). ------------- Commit messages: - 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes instances leading to higher memory footprint Changes: https://git.openjdk.org/jdk/pull/24475/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24475&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353787 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24475/head:pull/24475 PR: https://git.openjdk.org/jdk/pull/24475 From jpai at openjdk.org Mon Apr 7 06:42:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Apr 2025 06:42:53 GMT Subject: RFR: 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787. > > As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application. > > The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache. > > Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm (details in a comment of this PR). Here's a trivial application which creates and uses signed JARs for use in a `URLClassLoader`. Running this application will show that after the change proposed in this PR, the number of `java.util.jar.Attributes$Name` instances reduce drastically. Specifically, before this change, the `jmap -histo:live` of this application will show: num #instances #bytes class name (module) ------------------------------------------------------- ... 7: 100127 2403048 java.util.jar.Attributes$Name (java.base at 24) ... (more than 2MB of `Attributes$Name` instances) and after this change, the `jmap -histo:live` will show: num #instances #bytes class name (module) ------------------------------------------------------- ... 164: 28 672 java.util.jar.Attributes$Name (java.base at 25-internal) ... (just 672 bytes) import java.util.*; import java.nio.file.*; import java.nio.charset.*; import java.util.jar.*; import java.net.*; public class AttributesNameFootprint { private static final Path KEYSTORE = // Path.of(); private static final String ALIAS = // alias in the keystore private static final String PASSPHRASE = // passphrase of the keystore public static void main(final String[] args) throws Exception { // the number of JARs that we want to be used by the application // in its classpath final int numJARs = 100; final List classpath = new ArrayList<>(); // create some signed JARs for (int i = 1; i <= numJARs; i++) { final String jarNamePrefix = "jar" + i; final Path jar = createJAR(jarNamePrefix, jarNamePrefix + "-entry"); final Path signed = signJAR(jar); classpath.add(signed.toUri().toURL()); } // use those signed JARs in the classpath of a URLClassLoader // and load some resources, to trigger the instantiation of the // Manifest instances of these JAR files try (final URLClassLoader cl = new URLClassLoader(classpath.toArray(URL[]::new))) { for (int i = 1; i <= numJARs; i++) { final String jarNamePrefix = "jar" + i; final String resName = jarNamePrefix + "-entry"; final URL resource = cl.getResource(resName); if (resource == null) { throw new RuntimeException("Failed to find " + resName); } //System.out.println("found " + resName + " - " + resource); } // check the memory footprint of the application, especially // the number of java.util.jar.Attributes$Name instances final long pid = ProcessHandle.current().pid(); System.out.println("You can now run "jmap -histo:live " + pid + "". Once done, press any key to exit"); System.in.read(); } System.out.println("done"); } private static Path createJAR(final String jarNamePrefix, final String entryName) throws Exception { final Path jarDir = Files.createDirectories(Path.of(".").resolve("jars")); final Path jarFile = Files.createTempFile(jarDir, jarNamePrefix, ".jar"); // create a manifest file which will trigger Manifest instance // creation when parsed by the URLClassLoader final Manifest manifest = new Manifest(); final Attributes mainAttrs = manifest.getMainAttributes(); mainAttrs.putValue("Manifest-Version", "1.0"); mainAttrs.putValue("Class-Path", "non-existent.jar"); // create the JAR file with this manifest try (final JarOutputStream jaros = new JarOutputStream(Files.newOutputStream(jarFile), manifest)) { final JarEntry jarEntry = new JarEntry(entryName); jaros.putNextEntry(jarEntry); jaros.write(("hello " + entryName).getBytes(StandardCharsets.US_ASCII)); jaros.closeEntry(); // create 1000 more entries in the JAR for (int i = 0; i < 1000; i++) { final String otherEntry = entryName + i; final JarEntry other = new JarEntry(otherEntry); jaros.putNextEntry(other); jaros.write(("hello " + otherEntry).getBytes(StandardCharsets.US_ASCII)); jaros.closeEntry(); } } return jarFile; } private static Path signJAR(final Path unsignedJAR) throws Exception { final Path signedJARDir = Files.createDirectories(Path.of(".").resolve("signed-jars")); final Path signedJAR = signedJARDir.resolve("signed-" + unsignedJAR.getFileName()); final String[] cmd = new String[] { "jarsigner", "-keystore", KEYSTORE.toString(), "-storepass", PASSPHRASE, "-signedjar", signedJAR.toString(), unsignedJAR.toString(), ALIAS }; final ProcessBuilder pb = new ProcessBuilder(); pb.command(cmd); pb.inheritIO(); final Process p = pb.start(); final int exitCode = p.waitFor(); if (exitCode != 0) { System.err.println(Arrays.toString(cmd) + " exit code: " + exitCode); throw new RuntimeException("failed to sign jar " + unsignedJAR + ", exit code: " + exitCode); } return signedJAR; } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/24475#issuecomment-2782178725 From alanb at openjdk.org Mon Apr 7 06:48:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 7 Apr 2025 06:48:55 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v6] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 19:22:46 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission >> >> @Deprecated(forRemoval = true, since="25") >> Is added to each class and the existing @apiNote is converted to @deprected > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary SuppressWarnings and correct Deprecated annotation style src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1639: > 1637: */ > 1638: @SuppressWarnings("removal") > 1639: static volatile RuntimePermission modifyThreadPermission; This can be removed, it's not used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2030554666 From myankelevich at openjdk.org Mon Apr 7 08:52:55 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 7 Apr 2025 08:52:55 GMT Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java [v3] In-Reply-To: <1_Z3ReKHnwdaUR5GEWOjjDdbJ5QdSXcMPciSQAJKNHw=.dc1bbefe-5152-42d8-a62c-ccc4a093d1af@github.com> References: <1_Z3ReKHnwdaUR5GEWOjjDdbJ5QdSXcMPciSQAJKNHw=.dc1bbefe-5152-42d8-a62c-ccc4a093d1af@github.com> Message-ID: On Fri, 4 Apr 2025 14:24:09 GMT, Sean Mullan wrote: > The JBS issue should have a `noreg-self` label. Otherwise fix looks ok. @seanjmullan thank you! I have updated the JBS issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23440#issuecomment-2782500576 From duke at openjdk.org Mon Apr 7 08:52:56 2025 From: duke at openjdk.org (duke) Date: Mon, 7 Apr 2025 08:52:56 GMT Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java [v3] In-Reply-To: References: Message-ID: On Thu, 6 Mar 2025 11:49:12 GMT, Mikhail Yankelevich wrote: >> Refactor the following to run fully in java: >> test/java/security//Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh >> test/java/security//Security/ClassLoaderDeadlock/Deadlock.sh > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > Jaikiran's comments @myankelev Your change (at version e1056f95ba98978c324dba5dfcadee6a2c330adc) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23440#issuecomment-2782502960 From myankelevich at openjdk.org Mon Apr 7 09:59:56 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 7 Apr 2025 09:59:56 GMT Subject: Integrated: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java In-Reply-To: References: Message-ID: <_8VDnIyKHhyyyykrQq1Pk4svqzopL7DC24T1Iubtlp0=.052b474c-1182-437e-a37c-32177bf829a3@github.com> On Tue, 4 Feb 2025 14:08:05 GMT, Mikhail Yankelevich wrote: > Refactor the following to run fully in java: > test/java/security//Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh > test/java/security//Security/ClassLoaderDeadlock/Deadlock.sh This pull request has now been integrated. Changeset: 32d6d031 Author: Mikhail Yankelevich Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/32d6d031514be9cfee5b0fd778cb738b7ff9d770 Stats: 189 lines in 4 files changed: 12 ins; 172 del; 5 mod 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java Reviewed-by: jpai, mullan ------------- PR: https://git.openjdk.org/jdk/pull/23440 From adinn at openjdk.org Mon Apr 7 12:41:57 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 7 Apr 2025 12:41:57 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v6] In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 17:00:43 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merged master. > - Fixed bad assertion. > - Fixed mismerge. > - Merged master. > - A little cleanup > - Merged master > - removing trailing spaces > - kyber aarch64 intrinsics @ferakocz Thanks for another very good piece of work which appears to me to be functioning correctly and performantly. The PR suffers from the same problems as the original ML_DSA one i.e. The mapping of data to registers and the overall structure of the generated code and its relation to the related Java code/the original algorithms will be hard for a maintainer to identify. I have reworked your patch to use vector sequences in this [draft PR](https://github.com/openjdk/jdk/pull/24419) in very much the same way as was done for the ML_DSA PR. This has significantly abstracted and clarified the register mappings that are in use in each kyber generator and has also made the higher level structure of the generated code much easier to follow. Note that my rework of the generation routines was applied to your original PR after rebasing it on master. Before updating the kyber routines I also generalized a few of the VSeq methods that benefit from being shared by both kyber and dilithium, most notably the montmul routines, and I added a few extra helpers. The reworked version passes the ML_KEM functional test and gives similar performance improvements for the ML_KEM micro benchmark. The generated code does differ in a few places from what your original patch generates but only superficially - most notable is that a few loads/stores that rely on continued post-increments in the original instead use a constant offset or an add/load pair in the reworked code. This makes a very minor difference to code size and does not seem to affect performance. I would like you to rework your PR to incorporate these changes because I believe it will make a big difference to maintainability. n.b. it may be easier to integrate my changes by diffing your branch and mine and applying the resulting change set rather than trying to merge the changes. Please let me know if you have problems with the integration and need help. I still have some further review comments and would also like to see more commenting to explain what the code is doing. However, I think it will be easier to do that after this rework has been integrated into your PR. ------------- PR Review: https://git.openjdk.org/jdk/pull/23663#pullrequestreview-2746672860 From mullan at openjdk.org Mon Apr 7 12:52:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 7 Apr 2025 12:52:50 GMT Subject: RFR: 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint In-Reply-To: References: Message-ID: <98OAnQYTAmLgk3M-BpSwXxng7pXvzAnMppER1FYcwUk=.76fee1fe-6f9d-4625-8f16-8cf6e398cdfa@github.com> On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787. > > As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application. > > The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache. > > Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm (details in a comment of this PR). I suggest making this a P3 since it sounds like it would be useful to backport to 21. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24475#pullrequestreview-2746704222 From jpai at openjdk.org Mon Apr 7 12:58:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Apr 2025 12:58:50 GMT Subject: RFR: 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint In-Reply-To: <98OAnQYTAmLgk3M-BpSwXxng7pXvzAnMppER1FYcwUk=.76fee1fe-6f9d-4625-8f16-8cf6e398cdfa@github.com> References: <98OAnQYTAmLgk3M-BpSwXxng7pXvzAnMppER1FYcwUk=.76fee1fe-6f9d-4625-8f16-8cf6e398cdfa@github.com> Message-ID: On Mon, 7 Apr 2025 12:49:45 GMT, Sean Mullan wrote: > I suggest making this a P3 since it sounds like it would be useful to backport to 21. Done - I've marked it as a P3, and I agree that this is worth backporting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24475#issuecomment-2783248254 From mullan at openjdk.org Mon Apr 7 14:07:02 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 7 Apr 2025 14:07:02 GMT Subject: RFR: 8349890 : Option -Djava.security.debug=x509,ava breaks special chars [v4] In-Reply-To: <8GonKLdOC9kgRjuCcoNBFPR7gX--3DgGsJMzT7bUlik=.a252d3c0-29fc-4598-95c5-a933562046b5@github.com> References: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> <8GonKLdOC9kgRjuCcoNBFPR7gX--3DgGsJMzT7bUlik=.a252d3c0-29fc-4598-95c5-a933562046b5@github.com> Message-ID: On Fri, 4 Apr 2025 17:46:39 GMT, Koushik Muthukrishnan Thirupattur wrote: >> **A DESCRIPTION OF THE PROBLEM :** >> Enabling -Djava.security.debug=x509,ava affects how special characters in certificates are processed. The expected behavior is that debugging should not interfere with the normal encoding of certificate fields. >> >> **Fix:** >> The Debugging will no longer interfere with these fields, unless you call toString(). > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8349890:Option -Djava.security.debug=x509,ava breaks special chars Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24360#pullrequestreview-2746963330 From mullan at openjdk.org Mon Apr 7 14:29:51 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 7 Apr 2025 14:29:51 GMT Subject: RFR: 8353671: Remove dead code missed in JDK-8350459 In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 18:42:35 GMT, Volodymyr Paprotski wrote: > 8353671: Remove dead code missed in JDK-8350459 Can you add a link to JDK-8350459 in the JBS issue? Also, Tony is not available right now to review, so I reviewed and approved it. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24423#pullrequestreview-2747038716 From mullan at openjdk.org Mon Apr 7 14:35:10 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 7 Apr 2025 14:35:10 GMT Subject: RFR: 8353671: Remove dead code missed in JDK-8350459 In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 18:42:35 GMT, Volodymyr Paprotski wrote: > 8353671: Remove dead code missed in JDK-8350459 Also, the JBS issue needs an appropriate `noreg` label. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24423#issuecomment-2783550263 From jnimeh at openjdk.org Mon Apr 7 15:11:36 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 7 Apr 2025 15:11:36 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 [v2] In-Reply-To: References: Message-ID: > This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. > > There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Place columnar/diagonal alignment code into separate method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24420/files - new: https://git.openjdk.org/jdk/pull/24420/files/b530e166..fe865308 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24420&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24420&range=00-01 Stats: 39 lines in 3 files changed: 33 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24420/head:pull/24420 PR: https://git.openjdk.org/jdk/pull/24420 From myankelevich at openjdk.org Mon Apr 7 16:05:58 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 7 Apr 2025 16:05:58 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 15:54:47 GMT, Mikhail Yankelevich wrote: >> * fully automated the test >> * removed the race condition >> * client on a thread and server on a thread options are now run together automatically > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor comment changes Still needs a security libraries approval ------------- PR Comment: https://git.openjdk.org/jdk/pull/23469#issuecomment-2783869367 From lancea at openjdk.org Mon Apr 7 16:41:48 2025 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 7 Apr 2025 16:41:48 GMT Subject: RFR: 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787. > > As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application. > > The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache. > > Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm (details in a comment of this PR). Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24475#pullrequestreview-2747458624 From mullan at openjdk.org Mon Apr 7 16:44:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 7 Apr 2025 16:44:50 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v2] In-Reply-To: References: Message-ID: On Sat, 5 Apr 2025 19:12:23 GMT, Valerie Peng wrote: >> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. >> >> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. >> >> Thanks in advance for the review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > added default deriveData method to SSLKeyDerivation interface and > refactored code to remove unused AlgorithmParameterSpec argument. src/java.base/share/classes/sun/security/ssl/RSAKeyExchange.java line 295: > 293: > 294: @Override > 295: public SecretKey deriveKey(String type) throws IOException { How about changing the variable name to `typeNotUsed` like `SSLKeyDerivation.LegacyMasterKeyDerivation`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2031626688 From mullan at openjdk.org Mon Apr 7 16:47:54 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 7 Apr 2025 16:47:54 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v2] In-Reply-To: References: Message-ID: On Sat, 5 Apr 2025 19:12:23 GMT, Valerie Peng wrote: >> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. >> >> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. >> >> Thanks in advance for the review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > added default deriveData method to SSLKeyDerivation interface and > refactored code to remove unused AlgorithmParameterSpec argument. src/java.base/share/classes/sun/security/ssl/SSLKeyDerivation.java line 35: > 33: SecretKey deriveKey(String purpose) throws IOException; > 34: > 35: default byte[] deriveData(String purpose) throws IOException { This is an internal interface, so I don't think you need to make this a `default` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2031630692 From duke at openjdk.org Mon Apr 7 16:55:54 2025 From: duke at openjdk.org (duke) Date: Mon, 7 Apr 2025 16:55:54 GMT Subject: RFR: 8349890 : Option -Djava.security.debug=x509,ava breaks special chars [v4] In-Reply-To: <8GonKLdOC9kgRjuCcoNBFPR7gX--3DgGsJMzT7bUlik=.a252d3c0-29fc-4598-95c5-a933562046b5@github.com> References: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> <8GonKLdOC9kgRjuCcoNBFPR7gX--3DgGsJMzT7bUlik=.a252d3c0-29fc-4598-95c5-a933562046b5@github.com> Message-ID: <0N5sCwulHth6zS178BavIq1f5LPqWRAeDdnNjObbELs=.a0449ff6-c8c2-4353-bc33-2911e2ff7222@github.com> On Fri, 4 Apr 2025 17:46:39 GMT, Koushik Muthukrishnan Thirupattur wrote: >> **A DESCRIPTION OF THE PROBLEM :** >> Enabling -Djava.security.debug=x509,ava affects how special characters in certificates are processed. The expected behavior is that debugging should not interfere with the normal encoding of certificate fields. >> >> **Fix:** >> The Debugging will no longer interfere with these fields, unless you call toString(). > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8349890:Option -Djava.security.debug=x509,ava breaks special chars @koushikthirupattur Your change (at version 7cfa6ec70aedfded461844d3142621364ee66f99) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24360#issuecomment-2783997046 From rriggs at openjdk.org Mon Apr 7 17:18:40 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 7 Apr 2025 17:18:40 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v7] In-Reply-To: References: Message-ID: > Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions. Remove dead code from ForkJoinPool. Add @SuppressWarnings("remove") ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24444/files - new: https://git.openjdk.org/jdk/pull/24444/files/9a9417a7..322c5938 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=05-06 Stats: 20 lines in 4 files changed: 11 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444 PR: https://git.openjdk.org/jdk/pull/24444 From duke at openjdk.org Mon Apr 7 17:32:00 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Mon, 7 Apr 2025 17:32:00 GMT Subject: Integrated: 8349890 : Option -Djava.security.debug=x509,ava breaks special chars In-Reply-To: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> References: <_ji2MElIg5WS6-YdzlxxR5BK6YwM5zuFfskAuDBR7Tw=.35d2e0f8-22fa-4e9d-b670-f80d0da238ba@github.com> Message-ID: On Tue, 1 Apr 2025 16:40:57 GMT, Koushik Muthukrishnan Thirupattur wrote: > **A DESCRIPTION OF THE PROBLEM :** > Enabling -Djava.security.debug=x509,ava affects how special characters in certificates are processed. The expected behavior is that debugging should not interfere with the normal encoding of certificate fields. > > **Fix:** > The Debugging will no longer interfere with these fields, unless you call toString(). This pull request has now been integrated. Changeset: 0d4d1558 Author: Koushik Thirupattur Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/0d4d1558164bb352aa4f7be1fffb7eb2da506944 Stats: 79 lines in 2 files changed: 61 ins; 14 del; 4 mod 8349890: Option -Djava.security.debug=x509,ava breaks special chars Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/24360 From vpaprotski at openjdk.org Mon Apr 7 18:38:24 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Mon, 7 Apr 2025 18:38:24 GMT Subject: RFR: 8353671: Remove dead code missed in JDK-8350459 In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 14:32:26 GMT, Sean Mullan wrote: > Also, the JBS issue needs an appropriate `noreg` label. Added `noreg-cleanup`, I think thats the best match (?) > Can you add a link to JDK-8350459 in the JBS issue? Its already a subtask of JDK-8350459, so its 'linked' in a way (though the UI really should display the parent task in the child task, just like it does in the parent task). I went ahead and added a 'relates-to' link anyway.. Thanks @seanjmullan for the approval! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24423#issuecomment-2784185861 From duke at openjdk.org Mon Apr 7 18:38:31 2025 From: duke at openjdk.org (duke) Date: Mon, 7 Apr 2025 18:38:31 GMT Subject: RFR: 8353671: Remove dead code missed in JDK-8350459 In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 18:42:35 GMT, Volodymyr Paprotski wrote: > 8353671: Remove dead code missed in JDK-8350459 @vpaprotsk Your change (at version 6cc25c3373e6dbb18c9d1d37e8cfcb5e08e16ff7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24423#issuecomment-2784187392 From rriggs at openjdk.org Mon Apr 7 18:40:35 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 7 Apr 2025 18:40:35 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v8] In-Reply-To: References: Message-ID: > Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions." SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated. - Merge branch 'master' into 8353641-deprecate-premission-classes - Missing suppresswarnings - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions. Remove dead code from ForkJoinPool. Add @SuppressWarnings("remove") - Remove unnecessary SuppressWarnings and correct Deprecated annotation style - Update copyright in WindowsFileCopy - Remove unused import of LinkPermission - Updated style of @Deprecated to match most existing @Deprecated annotations `since` comes before `forRemoval` No spaces around `=` - Add SuppressWarnings to a Windows source missed earlier. - 8353641: Deprecate core library permission classes for removal Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission @Deprecated(forRemoval = true, since="25") Is added to each class and the existing @apiNote is converted to @deprected ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24444/files - new: https://git.openjdk.org/jdk/pull/24444/files/322c5938..6d3f003d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=06-07 Stats: 10986 lines in 240 files changed: 8087 ins; 2384 del; 515 mod Patch: https://git.openjdk.org/jdk/pull/24444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444 PR: https://git.openjdk.org/jdk/pull/24444 From vpaprotski at openjdk.org Mon Apr 7 18:47:53 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Mon, 7 Apr 2025 18:47:53 GMT Subject: Integrated: 8353671: Remove dead code missed in JDK-8350459 In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 18:42:35 GMT, Volodymyr Paprotski wrote: > 8353671: Remove dead code missed in JDK-8350459 This pull request has now been integrated. Changeset: 885cf0ff Author: Volodymyr Paprotski Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/885cf0ff8d1e7816bf409136234d63373d576f9e Stats: 23 lines in 1 file changed: 0 ins; 23 del; 0 mod 8353671: Remove dead code missed in JDK-8350459 Reviewed-by: sviswanathan, mullan ------------- PR: https://git.openjdk.org/jdk/pull/24423 From mullan at openjdk.org Mon Apr 7 18:51:13 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 7 Apr 2025 18:51:13 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v2] In-Reply-To: References: Message-ID: <-1PpZbXygm5SvzP34-MPe60Uz9K6aCNAF3cMkycYGIM=.d900c690-2c81-4110-8998-eab276730ec4@github.com> On Fri, 4 Apr 2025 22:18:31 GMT, Bradford Wetmore wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> added default deriveData method to SSLKeyDerivation interface and >> refactored code to remove unused AlgorithmParameterSpec argument. > > src/java.base/share/classes/sun/security/ssl/Utilities.java line 150: > >> 148: String sanitizedAlg = digestAlg.replace("-", ""); >> 149: return switch (sanitizedAlg) { >> 150: case "SHA256", "SHA384", "SHA512" -> "HKDF-" + sanitizedAlg; > > This is a nit, but currently we don't have SHA512 in `CipherSuite.HashAlg`. You can leave it for any future enhancements. You could also consider storing the HKDF algorithm names in the `HashAlg` enum. Not sure if it would make much difference, performance wise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2031813844 From mullan at openjdk.org Mon Apr 7 19:35:11 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 7 Apr 2025 19:35:11 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures [v3] In-Reply-To: <6xhofgGpQXmRoQNfiqTmn8sJwgxFaeJwqCrbD9NjeJg=.6be6ffee-603f-4b70-90ee-ef615d4fa9f7@github.com> References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> <6xhofgGpQXmRoQNfiqTmn8sJwgxFaeJwqCrbD9NjeJg=.6be6ffee-603f-4b70-90ee-ef615d4fa9f7@github.com> Message-ID: On Fri, 4 Apr 2025 20:44:28 GMT, Artur Barashev wrote: >> Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). >> https://www.rfc-editor.org/rfc/rfc9155.html >> >> Also fixing a little TLSv1.3 spec violation bug: ECDSA_SHA1 should not be allowed for handshake signatures in TLSv1.3. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Disable ECDSA_SHA1 to be used for TLSv1.3 handshake signatures Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24367#pullrequestreview-2747915902 From duke at openjdk.org Mon Apr 7 20:07:12 2025 From: duke at openjdk.org (duke) Date: Mon, 7 Apr 2025 20:07:12 GMT Subject: RFR: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures [v3] In-Reply-To: <6xhofgGpQXmRoQNfiqTmn8sJwgxFaeJwqCrbD9NjeJg=.6be6ffee-603f-4b70-90ee-ef615d4fa9f7@github.com> References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> <6xhofgGpQXmRoQNfiqTmn8sJwgxFaeJwqCrbD9NjeJg=.6be6ffee-603f-4b70-90ee-ef615d4fa9f7@github.com> Message-ID: On Fri, 4 Apr 2025 20:44:28 GMT, Artur Barashev wrote: >> Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). >> https://www.rfc-editor.org/rfc/rfc9155.html >> >> Also fixing a little TLSv1.3 spec violation bug: ECDSA_SHA1 should not be allowed for handshake signatures in TLSv1.3. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Disable ECDSA_SHA1 to be used for TLSv1.3 handshake signatures @artur-oracle Your change (at version 4335dfc96f51fd707442716d090be70c62825eaa) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24367#issuecomment-2784499541 From kustos at gmx.net Mon Apr 7 20:13:42 2025 From: kustos at gmx.net (Philippe Marschall) Date: Mon, 7 Apr 2025 22:13:42 +0200 Subject: SSLServerCertStore not registered Message-ID: <0a7d1d07-7b48-45ee-b688-4d9d1c1fa763@gmx.net> Hello The topic of getting the certificate chain of a server comes up repeatably, see for example [1]. While not difficult it's still quite a bit of code to implement. The JDK also has need for this in keystool and the code is implemented as a CertStoreSpi in sun.security.provider.certpath.ssl.SSLServerCertStore. Unfortunately the class is not registered by a security provider like JdkLDAP. Keytool calls the class directly, even creates as sublclass of CertStore. Is there any reason SSLServerCertStore is not registered? I would be willing to work on a patch with some guidance. [1] https://stackoverflow.com/questions/19297446/extract-server-certificates Regards Philippe From djelinski at openjdk.org Mon Apr 7 20:54:12 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 7 Apr 2025 20:54:12 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v2] In-Reply-To: References: Message-ID: On Sat, 5 Apr 2025 19:12:23 GMT, Valerie Peng wrote: >> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. >> >> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. >> >> Thanks in advance for the review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > added default deriveData method to SSLKeyDerivation interface and > refactored code to remove unused AlgorithmParameterSpec argument. Still looks good. The changes here are not enough to get the NSS-FIPS library to complete TLS1.3 handshake, but it's a big step in the right direction. I think we can fix the remaining issues separately. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24393#pullrequestreview-2748084288 From duke at openjdk.org Mon Apr 7 23:18:23 2025 From: duke at openjdk.org (duke) Date: Mon, 7 Apr 2025 23:18:23 GMT Subject: Withdrawn: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: Message-ID: <6eFMhUUPtfwSpGfImONuHNnxjrFPByg7Rfc4U0ow05o=.effb6bf8-7b0f-4e9e-904c-1710b7d61fb7@github.com> On Sun, 2 Feb 2025 19:35:03 GMT, Shaojin Wen wrote: > During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10 anonymous classes, which slows down the startup. This PR is to improve KnownOIDs and eliminate unnecessary embedded classes. > > > Here's how to reproduce this: > > > public class Startup { > public static void main(String[] args) {} > } > > > > java -verbose:class Startup > > > > [0.665s][info][class,load] sun.security.util.KnownOIDs > [0.666s][info][class,load] sun.security.util.KnownOIDs$1 > [0.667s][info][class,load] sun.security.util.KnownOIDs$2 > [0.667s][info][class,load] sun.security.util.KnownOIDs$3 > [0.668s][info][class,load] sun.security.util.KnownOIDs$4 > [0.668s][info][class,load] sun.security.util.KnownOIDs$5 > [0.668s][info][class,load] sun.security.util.KnownOIDs$6 > [0.668s][info][class,load] sun.security.util.KnownOIDs$7 > [0.669s][info][class,load] sun.security.util.KnownOIDs$8 > [0.669s][info][class,load] sun.security.util.KnownOIDs$9 > [0.669s][info][class,load] sun.security.util.KnownOIDs$10 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23411 From sviswanathan at openjdk.org Tue Apr 8 00:12:15 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 8 Apr 2025 00:12:15 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 07:38:34 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reacting to comment by Sandhya. src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 802: > 800: __ evpbroadcastd(zero, scratch, Assembler::AVX_512bit); // 0 > 801: __ addl(scratch, 1); > 802: __ evpbroadcastd(one, scratch, Assembler::AVX_512bit); // 1 A better way to initialize (0, 1, -1) vectors is: // load 0 into int vector vpxor(zero, zero, zero, Assembler::AVX_512bit); // load -1 into int vector vpternlogd(minusOne, 0xff, minusOne, minusOne, Assembler::AVX_512bit); // load 1 into int vector vpsubd(one, zero, minusOne, Assembler::AVX_512bit); Where minusOne could be xmm31. A broadcast from r register to xmm register is more expensive. src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 982: > 980: __ evporq(xmm19, k0, xmm19, xmm23, false, Assembler::AVX_512bit); > 981: > 982: __ evpsubd(xmm12, k0, zero, one, false, Assembler::AVX_512bit); // -1 The -1 initialization could be done outside the loop. src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1015: > 1013: __ addptr(lowPart, 4 * XMMBYTES); > 1014: __ cmpl(len, 0); > 1015: __ jcc(Assembler::notEqual, L_loop); It looks to me that subl and cmpl could be merged: __ addptr(highPart, 4 * XMMBYTES); __ addptr(lowPart, 4 * XMMBYTES); __ subl(len, 4 * XMMBYTES); __ jcc(Assembler::notEqual, L_loop); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2032172061 PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2032171059 PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2031979828 From jpai at openjdk.org Tue Apr 8 00:38:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Apr 2025 00:38:18 GMT Subject: RFR: 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint In-Reply-To: References: Message-ID: <887z3437qFFcUQj0euLTGyu1jcOMu9CYA5B_Jm9sEp4=.711799ca-2294-4143-9330-a1fabc80fbd2@github.com> On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787. > > As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application. > > The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache. > > Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm (details in a comment of this PR). Thank you Sean and Lance for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24475#issuecomment-2784935034 From jpai at openjdk.org Tue Apr 8 00:38:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Apr 2025 00:38:18 GMT Subject: Integrated: 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 06:34:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the increase in memory footprint of an application that uses signed JAR files, signed with `SHA-384` digest algorithm? This addresses https://bugs.openjdk.org/browse/JDK-8353787. > > As noted in that issue and the linked mailing list discussion, it has been noticed that when JARs signed with `SHA-384` digest algorithm (which is the default since Java 19) are loaded, the number of `java.util.Attributes$Name` instances held in memory increase, leading to an increase in the memory footprint of the application. > > The `Attributes` class has an internal cache which is meant to store `Name` instances of some well-known manifest attributes. It already has the `Name` instances for `SHA1-Digest` and `SHA-256-Digest` manifest attributes cached, but is missing an entry for `SHA-384-Digest`. The commit in this PR adds `SHA-384-Digest` to that cache. > > Given the nature of this change, no new jtreg test has been introduced and existing tests in tier1, tier2 and tier3 continue to pass with this change. I've manually verified that this change does reduce the memory footprint of an application which has signed JARs with `SHA-384` digest algorithm (details in a comment of this PR). This pull request has now been integrated. Changeset: b64cdc28 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/b64cdc28132c889ca8e21dc9534590ba2a778bcd Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint Reviewed-by: mullan, lancea ------------- PR: https://git.openjdk.org/jdk/pull/24475 From duke at openjdk.org Tue Apr 8 03:16:05 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 8 Apr 2025 03:16:05 GMT Subject: RFR: 8353945: Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 Message-ID: Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890. The expected results of the failing tests will now change according to the fix in JDK-8349890. ------------- Commit messages: - 8353945:Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 Changes: https://git.openjdk.org/jdk/pull/24498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24498&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353945 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24498/head:pull/24498 PR: https://git.openjdk.org/jdk/pull/24498 From duke at openjdk.org Tue Apr 8 03:20:31 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 8 Apr 2025 03:20:31 GMT Subject: RFR: 8353945: Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 [v2] In-Reply-To: References: Message-ID: <1dpAzvt3UKgbhswqxitaD9CWEdrnx4CtKfTWhCYhEp4=.9f8b8d6c-c17c-451f-b9c4-3fc57874e729@github.com> > Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890. The expected results of the failing tests will now change according to the fix in JDK-8349890. Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: 8353945:Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24498/files - new: https://git.openjdk.org/jdk/pull/24498/files/653f8ac2..5dc03320 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24498&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24498&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24498/head:pull/24498 PR: https://git.openjdk.org/jdk/pull/24498 From alanb at openjdk.org Tue Apr 8 06:44:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Apr 2025 06:44:15 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v8] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission >> >> @Deprecated(forRemoval = true, since="25") >> Is added to each class and the existing @apiNote is converted to @deprected > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions." > SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated. > - Merge branch 'master' into 8353641-deprecate-premission-classes > - Missing suppresswarnings > - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions. > Remove dead code from ForkJoinPool. > Add @SuppressWarnings("remove") > - Remove unnecessary SuppressWarnings and correct Deprecated annotation style > - Update copyright in WindowsFileCopy > - Remove unused import of LinkPermission > - Updated style of @Deprecated to match most existing @Deprecated annotations > `since` comes before `forRemoval` > No spaces around `=` > - Add SuppressWarnings to a Windows source missed earlier. > - 8353641: Deprecate core library permission classes for removal > > Now that the Security Manager is permanently disabled, the following permission classes > in the core libraries area can be deprecated for removal as they are no longer useful: > FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, > RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected src/java.base/share/classes/jdk/internal/access/JavaIOFilePermissionAccess.java line 49: > 47: */ > 48: @SuppressWarnings("removal") > 49: FilePermission newPermUsingAltPath(FilePermission input); I assume JavaIOFilePermissionAccess can be removed, nothing should be using this now. src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java line 443: > 441: @SuppressWarnings("removal") > 442: private void defineTransletClasses() > 443: throws TransformerConfigurationException { In passing, the PermissionCollection used to construct the PD here is no longer needed. If this is cleaned up then the SW wouldn't be needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2032494012 PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2032493150 From mullan at openjdk.org Tue Apr 8 11:51:10 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 8 Apr 2025 11:51:10 GMT Subject: RFR: 8353945: Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 [v2] In-Reply-To: <1dpAzvt3UKgbhswqxitaD9CWEdrnx4CtKfTWhCYhEp4=.9f8b8d6c-c17c-451f-b9c4-3fc57874e729@github.com> References: <1dpAzvt3UKgbhswqxitaD9CWEdrnx4CtKfTWhCYhEp4=.9f8b8d6c-c17c-451f-b9c4-3fc57874e729@github.com> Message-ID: On Tue, 8 Apr 2025 03:20:31 GMT, Koushik Muthukrishnan Thirupattur wrote: >> Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890. The expected results of the failing tests will now change according to the fix in JDK-8349890. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8353945:Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24498#pullrequestreview-2749687520 From duke at openjdk.org Tue Apr 8 11:51:11 2025 From: duke at openjdk.org (duke) Date: Tue, 8 Apr 2025 11:51:11 GMT Subject: RFR: 8353945: Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 [v2] In-Reply-To: <1dpAzvt3UKgbhswqxitaD9CWEdrnx4CtKfTWhCYhEp4=.9f8b8d6c-c17c-451f-b9c4-3fc57874e729@github.com> References: <1dpAzvt3UKgbhswqxitaD9CWEdrnx4CtKfTWhCYhEp4=.9f8b8d6c-c17c-451f-b9c4-3fc57874e729@github.com> Message-ID: <8Zu1NhiwZNwzzY1WcJzjiSkAcDljRJGtFP17oQ9f0e4=.0d0a7fd7-39bb-428c-a37d-54f22c416291@github.com> On Tue, 8 Apr 2025 03:20:31 GMT, Koushik Muthukrishnan Thirupattur wrote: >> Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890. The expected results of the failing tests will now change according to the fix in JDK-8349890. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8353945:Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 @seanjmullan Your change (at version 5dc03320ba60d95b4eeac061c441875948bb944e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24498#issuecomment-2786174811 From duke at openjdk.org Tue Apr 8 11:54:32 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 8 Apr 2025 11:54:32 GMT Subject: Integrated: 8353945: Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 03:10:23 GMT, Koushik Muthukrishnan Thirupattur wrote: > Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890. The expected results of the failing tests will now change according to the fix in JDK-8349890. This pull request has now been integrated. Changeset: d8bed130 Author: Koushik Thirupattur Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/d8bed1304713b17286d4ed614f95d0ef6e59a95b Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod 8353945: Test javax/security/auth/x500/X500Principal/NameFormat.java fails after JDK-8349890 Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/24498 From abarashev at openjdk.org Tue Apr 8 13:05:35 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 8 Apr 2025 13:05:35 GMT Subject: Integrated: 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures In-Reply-To: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> References: <5oQfOLKIhaad8AqoJ6cFrgelyqFMZ9A3xb_TbmXZDxQ=.9d753e5c-a28d-496b-a49b-cc1e92ee5147@github.com> Message-ID: On Tue, 1 Apr 2025 20:53:01 GMT, Artur Barashev wrote: > Disable SHA-1 in TLS/DTLS 1.2 handshake signatures (but not in certificate signatures). > https://www.rfc-editor.org/rfc/rfc9155.html > > Also fixing a little TLSv1.3 spec violation bug: ECDSA_SHA1 should not be allowed for handshake signatures in TLSv1.3. This pull request has now been integrated. Changeset: dfa79c37 Author: Artur Barashev Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/dfa79c373097d17a347b7c17103c57e12f59dc67 Stats: 249 lines in 5 files changed: 246 ins; 0 del; 3 mod 8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/24367 From mullan at openjdk.org Tue Apr 8 14:23:06 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 8 Apr 2025 14:23:06 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal [v3] In-Reply-To: References: Message-ID: > Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. > > The current API note in these classes was reused as the deprecation text. > > Release Note: https://bugs.openjdk.org/browse/JDK-8353680 Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: Fix build error; add removal annotation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24445/files - new: https://git.openjdk.org/jdk/pull/24445/files/8dae2f8d..cecd9287 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24445&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24445/head:pull/24445 PR: https://git.openjdk.org/jdk/pull/24445 From mullan at openjdk.org Tue Apr 8 14:41:13 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 8 Apr 2025 14:41:13 GMT Subject: RFR: 8350705: [JMH] test security.SSLHandshake failed for 2 threads configuration In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 12:54:01 GMT, Daniel Jeli?ski wrote: > Update the SSLHandshake benchmark to enable running in multiple threads. > > This PR changes the scope of the state from per-benchmark to per-thread. The server SSLContext is still shared across all threads to simulate the scenario where multiple clients try to connect to the same server at the same time. > > Before the change, running this benchmark with `make test TEST=micro:SSLHandshake MICRO=OPTIONS="-t 3"` failed with an exception. After this change the benchmark completes successfully. Looks good. The bug needs a `noreg` label. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24195#pullrequestreview-2750250404 From rriggs at openjdk.org Tue Apr 8 15:05:35 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 8 Apr 2025 15:05:35 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal [v3] In-Reply-To: References: Message-ID: <3DjiAo-0RHErmFMxtXjOQkl9N14GEqyDMEpzFk-YyEk=.c4d9615b-d33d-4ee8-b189-b0a86fb6f006@github.com> On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan wrote: >> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. >> >> The current API note in these classes was reused as the deprecation text. >> >> Release Note: https://bugs.openjdk.org/browse/JDK-8353680 > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Fix build error; add removal annotation. Looks good, still. ------------- PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2750338429 From fferrari at openjdk.org Tue Apr 8 15:12:20 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Tue, 8 Apr 2025 15:12:20 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v8] In-Reply-To: References: Message-ID: > Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map"). > > #### New services map design > > Here is the high-level hierarchy of the new services map design: > > * `servicesMap` (`ServicesMap`) > * Instances (fields) > * `services` (`Map`): unifies the previous `serviceMap` and `legacyMap` > * `legacySvcKeys` (`Set`): set indicating which keys in `services` correspond to the Legacy API > * `serviceProps` (`Map`): keeps track of the _provider Hashtable entries_ that originated services entries (1) > * `serviceAttrProps` (`Map>`): keeps track of the _provider Hashtable entries_ that originated service attributes (1) > * `serviceSet` (`AtomicReference>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method > * Writers' methods (for providers registering services through the Current or the Legacy API) > * `boolean putService(Service svc)` > * `boolean removeService(Service svc)` > * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)` > * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)` > * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)` > * `boolean removeLegacy(ServiceKey key, String className)` > * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)` > * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)` > * Readers' methods (for services users and `GetInstance` APIs) > * `Set getServices()` > * `Service getService(ServiceKey key)` > * Other methods: default and copy constructors, `void clear()` > > (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms. > > #### Testing > > As part of our testing, we observed all the tests pass in the following categories: > > * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398)) > * `jdk/com/sun/crypto` > * `jdk/java/security` > * Including the new `jdk/java/security/Provider/Ser... Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: Sync of methods reading the properties map. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22613/files - new: https://git.openjdk.org/jdk/pull/22613/files/384f2a7b..da693b12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=06-07 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22613/head:pull/22613 PR: https://git.openjdk.org/jdk/pull/22613 From duke at openjdk.org Tue Apr 8 15:13:20 2025 From: duke at openjdk.org (David M. Lloyd) Date: Tue, 8 Apr 2025 15:13:20 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal [v3] In-Reply-To: References: Message-ID: <24wR6AVIfTd9KtlS4sK_-TAx_A5eEe1-edWjf6CurZk=.84e12340-06c5-4a27-9fb6-c35610e3e4c8@github.com> On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan wrote: >> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. >> >> The current API note in these classes was reused as the deprecation text. >> >> Release Note: https://bugs.openjdk.org/browse/JDK-8353680 > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Fix build error; add removal annotation. Marked as reviewed by dmlloyd at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2750361672 From djelinski at openjdk.org Tue Apr 8 15:22:31 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 8 Apr 2025 15:22:31 GMT Subject: Integrated: 8350705: [JMH] test security.SSLHandshake failed for 2 threads configuration In-Reply-To: References: Message-ID: On Mon, 24 Mar 2025 12:54:01 GMT, Daniel Jeli?ski wrote: > Update the SSLHandshake benchmark to enable running in multiple threads. > > This PR changes the scope of the state from per-benchmark to per-thread. The server SSLContext is still shared across all threads to simulate the scenario where multiple clients try to connect to the same server at the same time. > > Before the change, running this benchmark with `make test TEST=micro:SSLHandshake MICRO=OPTIONS="-t 3"` failed with an exception. After this change the benchmark completes successfully. This pull request has now been integrated. Changeset: 58ff36f3 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/58ff36f3bdefe2e883dc871a4e7fcaa81e8eef5b Stats: 33 lines in 1 file changed: 20 ins; 6 del; 7 mod 8350705: [JMH] test security.SSLHandshake failed for 2 threads configuration Reviewed-by: hchao, mullan ------------- PR: https://git.openjdk.org/jdk/pull/24195 From djelinski at openjdk.org Tue Apr 8 15:22:30 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 8 Apr 2025 15:22:30 GMT Subject: RFR: 8350705: [JMH] test security.SSLHandshake failed for 2 threads configuration In-Reply-To: References: Message-ID: <7VpRC7TwIVQc699Cd_Wkls4NPbFO5i2JTCEGc8bQCOU=.e3b7fa36-d24f-4d9b-8487-6a8f58cbff54@github.com> On Mon, 24 Mar 2025 12:54:01 GMT, Daniel Jeli?ski wrote: > Update the SSLHandshake benchmark to enable running in multiple threads. > > This PR changes the scope of the state from per-benchmark to per-thread. The server SSLContext is still shared across all threads to simulate the scenario where multiple clients try to connect to the same server at the same time. > > Before the change, running this benchmark with `make test TEST=micro:SSLHandshake MICRO=OPTIONS="-t 3"` failed with an exception. After this change the benchmark completes successfully. Thanks for the reviews! Label added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24195#issuecomment-2786806100 From mpowers at openjdk.org Tue Apr 8 15:31:18 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 8 Apr 2025 15:31:18 GMT Subject: RFR: 8353478: Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms [v2] In-Reply-To: <3uAVtfSLbHVgOMVltddUOxFHHjIH27A3CjPcfTsnmfY=.3a040e06-29fc-4405-9be2-b6af125318a7@github.com> References: <3uAVtfSLbHVgOMVltddUOxFHHjIH27A3CjPcfTsnmfY=.3a040e06-29fc-4405-9be2-b6af125318a7@github.com> Message-ID: On Sun, 6 Apr 2025 00:32:17 GMT, Sergey Kuksenko wrote: >> Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms. > > Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: > > Update test/micro/org/openjdk/bench/javax/crypto/full/KEMBench.java > > Co-authored-by: Andrey Turbanov test/micro/org/openjdk/bench/javax/crypto/small/SignatureBench.java line 2: > 1: /* > 2: * Copyright (c) 2015, 2055, Oracle and/or its affiliates. All rights reserved. A few years to far ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24369#discussion_r2033459657 From rriggs at openjdk.org Tue Apr 8 16:09:27 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 8 Apr 2025 16:09:27 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v8] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 06:41:41 GMT, Alan Bateman wrote: >> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions." >> SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated. >> - Merge branch 'master' into 8353641-deprecate-premission-classes >> - Missing suppresswarnings >> - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions. >> Remove dead code from ForkJoinPool. >> Add @SuppressWarnings("remove") >> - Remove unnecessary SuppressWarnings and correct Deprecated annotation style >> - Update copyright in WindowsFileCopy >> - Remove unused import of LinkPermission >> - Updated style of @Deprecated to match most existing @Deprecated annotations >> `since` comes before `forRemoval` >> No spaces around `=` >> - Add SuppressWarnings to a Windows source missed earlier. >> - 8353641: Deprecate core library permission classes for removal >> >> Now that the Security Manager is permanently disabled, the following permission classes >> in the core libraries area can be deprecated for removal as they are no longer useful: >> FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, >> RuntimePermission, and SerializablePermission >> >> @Deprecated(forRemoval = true, since="25") >> Is added to each class and the existing @apiNote is converted to @deprected > > src/java.base/share/classes/jdk/internal/access/JavaIOFilePermissionAccess.java line 49: > >> 47: */ >> 48: @SuppressWarnings("removal") >> 49: FilePermission newPermUsingAltPath(FilePermission input); > > I assume JavaIOFilePermissionAccess can be removed, nothing should be using this now. Filed JDK-8354053 to remove as a separate issue. > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java line 443: > >> 441: @SuppressWarnings("removal") >> 442: private void defineTransletClasses() >> 443: throws TransformerConfigurationException { > > In passing, the PermissionCollection used to construct the PD here is no longer needed. If this is cleaned up then the SW wouldn't be needed. Filed JDK-8354054 to cleanup in a separate issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2033542174 PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2033538959 From rriggs at openjdk.org Tue Apr 8 16:16:23 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 8 Apr 2025 16:16:23 GMT Subject: RFR: 8348967: Deprecate security permission classes for removal [v3] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 14:23:06 GMT, Sean Mullan wrote: >> Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. >> >> The current API note in these classes was reused as the deprecation text. >> >> Release Note: https://bugs.openjdk.org/browse/JDK-8353680 > > Sean Mullan has updated the pull request incrementally with one additional commit since the last revision: > > Fix build error; add removal annotation. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24445#pullrequestreview-2750589286 From mullan at openjdk.org Tue Apr 8 16:16:24 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 8 Apr 2025 16:16:24 GMT Subject: Integrated: 8348967: Deprecate security permission classes for removal In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote: > Please review this change to terminally deprecate the following security related permission classes: `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported. > > The current API note in these classes was reused as the deprecation text. > > Release Note: https://bugs.openjdk.org/browse/JDK-8353680 This pull request has now been integrated. Changeset: 3cbe686d Author: Sean Mullan URL: https://git.openjdk.org/jdk/commit/3cbe686d6203043e95604b3d6c96d6ed9d5364c3 Stats: 36 lines in 11 files changed: 20 ins; 0 del; 16 mod 8348967: Deprecate security permission classes for removal Reviewed-by: rriggs, iris ------------- PR: https://git.openjdk.org/jdk/pull/24445 From weijun at openjdk.org Tue Apr 8 18:19:46 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 8 Apr 2025 18:19:46 GMT Subject: RFR: 8353888: Implement Key Derivation Function API Message-ID: Finalize the KDF API. ------------- Commit messages: - the change Changes: https://git.openjdk.org/jdk/pull/24520/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353888 Stats: 42 lines in 16 files changed: 0 ins; 30 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24520.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520 PR: https://git.openjdk.org/jdk/pull/24520 From duke at openjdk.org Tue Apr 8 18:21:34 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 8 Apr 2025 18:21:34 GMT Subject: RFR: 8354061: Update copyright in NameFormat.java fix after JDK-8349890 Message-ID: Update copyright in NameFormat.java fix after JDK-8353945. Missed to update when the fix was integrated with JDK-8353945. ------------- Commit messages: - 8354061: Update copyright in NameFormat.java fix after JDK-8349890 Changes: https://git.openjdk.org/jdk/pull/24518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24518&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354061 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24518/head:pull/24518 PR: https://git.openjdk.org/jdk/pull/24518 From liach at openjdk.org Tue Apr 8 18:21:34 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Apr 2025 18:21:34 GMT Subject: RFR: 8354061: Update copyright in NameFormat.java fix after JDK-8349890 In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 17:26:47 GMT, Koushik Muthukrishnan Thirupattur wrote: > Update copyright in NameFormat.java fix after JDK-8353945. Missed to update when the fix was integrated with JDK-8353945. Marked as reviewed by liach (Reviewer). On second look this is not necessary - this file was not touched. ------------- PR Review: https://git.openjdk.org/jdk/pull/24518#pullrequestreview-2750980327 PR Comment: https://git.openjdk.org/jdk/pull/24518#issuecomment-2787288331 From mullan at openjdk.org Tue Apr 8 19:15:24 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 8 Apr 2025 19:15:24 GMT Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64 [v8] In-Reply-To: References: <5WNrv1s7Bp7hLwSVGqoPw9ycCSHK0Zyka65DpAjnB2s=.31243a29-4fbb-4c21-b671-45470d043335@github.com> <5m9xiUkcb41c47vcLKS3kvsK9Jhh1y7PsNRHcffa8ug=.5785cdda-e50e-410a-a139-5554d70bfdff@github.com> Message-ID: On Fri, 4 Apr 2025 15:13:50 GMT, Volodymyr Paprotski wrote: > > > Done I think: https://bugs.openjdk.org/browse/JDK-8297970 > > > > > > Is this link correct? This issue was fixed in JDK 20. > > Sorry.. copy/paste didnt notice.. https://bugs.openjdk.org/browse/JDK-8353670 (also ends in *70!) Looks good, but can you also say something about the approximate performance gain? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2787432878 From liach at openjdk.org Tue Apr 8 19:39:16 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Apr 2025 19:39:16 GMT Subject: RFR: 8353888: Implement Key Derivation Function API In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 18:14:53 GMT, Weijun Wang wrote: > Finalize the KDF API. Changes requested by liach (Reviewer). src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82: > 80: MODULE_IMPORTS, > 81: @JEP(number=478, title="Key Derivation Function API", status="Preview") > 82: KEY_DERIVATION, Please keep this constant - we cannot remove this until our minimum boot JDK is 25. ------------- PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2751196660 PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2033904746 From duke at openjdk.org Tue Apr 8 19:48:20 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 8 Apr 2025 19:48:20 GMT Subject: Withdrawn: 8354061: Update copyright in NameFormat.java fix after JDK-8349890 In-Reply-To: References: Message-ID: <7f_-whXRoX9c0DDohREb_NZA5AS880nqXFGnIs3YohA=.fde8c83d-24d5-4729-a940-a3b9c1aacd46@github.com> On Tue, 8 Apr 2025 17:26:47 GMT, Koushik Muthukrishnan Thirupattur wrote: > Update copyright in NameFormat.java fix after JDK-8353945. Missed to update when the fix was integrated with JDK-8353945. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24518 From duke at openjdk.org Tue Apr 8 19:49:47 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 8 Apr 2025 19:49:47 GMT Subject: RFR: 8354061: Update copyright in NameFormat.java fix after JDK-8349890 Message-ID: <57J4ns2PhxzYB_v6EeHjZCZXvT6rOSD6p9AWfdFNFsw=.3295e139-a24a-4789-8654-81e8191cacce@github.com> 8354061: Update copyright in NameFormat.java fix after JDK-8349890 ------------- Commit messages: - 8354061: Update copyright in NameFormat.java fix after JDK-8349890 Changes: https://git.openjdk.org/jdk/pull/24523/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24523&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354061 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24523.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24523/head:pull/24523 PR: https://git.openjdk.org/jdk/pull/24523 From mullan at openjdk.org Tue Apr 8 19:55:17 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 8 Apr 2025 19:55:17 GMT Subject: RFR: 8354061: Update copyright in NameFormat.java fix after JDK-8349890 In-Reply-To: <57J4ns2PhxzYB_v6EeHjZCZXvT6rOSD6p9AWfdFNFsw=.3295e139-a24a-4789-8654-81e8191cacce@github.com> References: <57J4ns2PhxzYB_v6EeHjZCZXvT6rOSD6p9AWfdFNFsw=.3295e139-a24a-4789-8654-81e8191cacce@github.com> Message-ID: On Tue, 8 Apr 2025 19:44:30 GMT, Koushik Muthukrishnan Thirupattur wrote: > 8354061: Update copyright in NameFormat.java fix after JDK-8349890 Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24523#pullrequestreview-2751231196 From duke at openjdk.org Tue Apr 8 19:58:10 2025 From: duke at openjdk.org (duke) Date: Tue, 8 Apr 2025 19:58:10 GMT Subject: RFR: 8354061: Update copyright in NameFormat.java fix after JDK-8349890 In-Reply-To: <57J4ns2PhxzYB_v6EeHjZCZXvT6rOSD6p9AWfdFNFsw=.3295e139-a24a-4789-8654-81e8191cacce@github.com> References: <57J4ns2PhxzYB_v6EeHjZCZXvT6rOSD6p9AWfdFNFsw=.3295e139-a24a-4789-8654-81e8191cacce@github.com> Message-ID: On Tue, 8 Apr 2025 19:44:30 GMT, Koushik Muthukrishnan Thirupattur wrote: > 8354061: Update copyright in NameFormat.java fix after JDK-8349890 @koushikthirupattur Your change (at version 1d3078efb8dce8346336d298832b204875b8e71f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24523#issuecomment-2787518097 From mbalao at openjdk.org Tue Apr 8 20:08:33 2025 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 8 Apr 2025 20:08:33 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: <9BCMcXORKkDGTOCgfl6jKoHVICwKl0dwJqozdwkowZo=.32bea330-0528-428f-87c6-7355b922a8aa@github.com> On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- @franferrax @valeriepeng @wangweij may I ask you to have a look at this proposal? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2787537060 From mbalao at openjdk.org Tue Apr 8 20:08:32 2025 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 8 Apr 2025 20:08:32 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key Message-ID: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Hi, I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. Thanks, Martin.- ------------- Commit messages: - 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key Changes: https://git.openjdk.org/jdk/pull/24526/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350661 Stats: 21 lines in 2 files changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24526/head:pull/24526 PR: https://git.openjdk.org/jdk/pull/24526 From weijun at openjdk.org Tue Apr 8 21:03:17 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 8 Apr 2025 21:03:17 GMT Subject: RFR: 8353888: Implement Key Derivation Function API In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 19:35:33 GMT, Chen Liang wrote: >> Finalize the KDF API. > > src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82: > >> 80: MODULE_IMPORTS, >> 81: @JEP(number=478, title="Key Derivation Function API", status="Preview") >> 82: KEY_DERIVATION, > > Please keep this constant - we cannot remove this until our minimum boot JDK is 25. Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see no problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2034027369 From liach at openjdk.org Tue Apr 8 21:06:23 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Apr 2025 21:06:23 GMT Subject: RFR: 8353888: Implement Key Derivation Function API In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 21:00:41 GMT, Weijun Wang wrote: >> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82: >> >>> 80: MODULE_IMPORTS, >>> 81: @JEP(number=478, title="Key Derivation Function API", status="Preview") >>> 82: KEY_DERIVATION, >> >> Please keep this constant - we cannot remove this until our minimum boot JDK is 25. > > Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see no problem. I think the dependency is in the CreateSymbols tool or something ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2034030628 From myankelevich at openjdk.org Tue Apr 8 21:25:23 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 8 Apr 2025 21:25:23 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v6] In-Reply-To: References: Message-ID: On Wed, 19 Mar 2025 18:08:40 GMT, Mikhail Yankelevich wrote: >> Moved the sh file logic to jtreg java test. > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor: space at the end Still needs a review ------------- PR Comment: https://git.openjdk.org/jdk/pull/23590#issuecomment-2787691992 From weijun at openjdk.org Tue Apr 8 21:26:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 8 Apr 2025 21:26:11 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: <6HOFp_futq09HNcBAI52Oay2wQiB-tZviOisloCPSl8=.420e4985-9d05-4c72-8779-49e6bf151c29@github.com> On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- Looks good to me, but again I am not a PKCS #11 expert. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2787692665 From duke at openjdk.org Tue Apr 8 21:27:08 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 8 Apr 2025 21:27:08 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14] In-Reply-To: References: Message-ID: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com> > By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Reacting to mor comments from Sandhya. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23860/files - new: https://git.openjdk.org/jdk/pull/23860/files/e4ab10bb..0b0d0969 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=12-13 Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23860.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860 PR: https://git.openjdk.org/jdk/pull/23860 From duke at openjdk.org Tue Apr 8 21:29:26 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 8 Apr 2025 21:29:26 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v13] In-Reply-To: References: Message-ID: On Sat, 5 Apr 2025 00:27:05 GMT, Sandhya Viswanathan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Reacting to comment by Sandhya. > > src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 345: > >> 343: >> 344: store4Xmms(coeffs, 0, xmm0_3, _masm); >> 345: store4Xmms(coeffs, 4 * XMMBYTES, xmm4_7, _masm); > > This seems to be unnecessary store. Thanks for catching that. Changed. > src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 370: > >> 368: loadPerm(xmm16_19, perms, nttL4PermsIdx, _masm); >> 369: loadPerm(xmm12_15, perms, nttL4PermsIdx + 64, _masm); >> 370: load4Xmms(xmm24_27, zetas, 4 * 512, _masm); // for level 3 > > The comment // for level3 is not relevant here and could be removed. Ooops. Deleted the comment. > src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 802: > >> 800: __ evpbroadcastd(zero, scratch, Assembler::AVX_512bit); // 0 >> 801: __ addl(scratch, 1); >> 802: __ evpbroadcastd(one, scratch, Assembler::AVX_512bit); // 1 > > A better way to initialize (0, 1, -1) vectors is: > // load 0 into int vector > vpxor(zero, zero, zero, Assembler::AVX_512bit); > // load -1 into int vector > vpternlogd(minusOne, 0xff, minusOne, minusOne, Assembler::AVX_512bit); > // load 1 into int vector > vpsubd(one, zero, minusOne, Assembler::AVX_512bit); > > Where minusOne could be xmm31. > > A broadcast from r register to xmm register is more expensive. Changed. > src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 982: > >> 980: __ evporq(xmm19, k0, xmm19, xmm23, false, Assembler::AVX_512bit); >> 981: >> 982: __ evpsubd(xmm12, k0, zero, one, false, Assembler::AVX_512bit); // -1 > > The -1 initialization could be done outside the loop. Not really. All registers are used. > src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1015: > >> 1013: __ addptr(lowPart, 4 * XMMBYTES); >> 1014: __ cmpl(len, 0); >> 1015: __ jcc(Assembler::notEqual, L_loop); > > It looks to me that subl and cmpl could be merged: > __ addptr(highPart, 4 * XMMBYTES); > __ addptr(lowPart, 4 * XMMBYTES); > __ subl(len, 4 * XMMBYTES); > __ jcc(Assembler::notEqual, L_loop); Changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057184 PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057342 PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057700 PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057565 PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2034057463 From myankelevich at openjdk.org Tue Apr 8 21:39:25 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 8 Apr 2025 21:39:25 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v4] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 18:46:29 GMT, Mikhail Yankelevich wrote: >> Refactored the runNameEquals.sh to java test > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor Still needs a review ------------- PR Comment: https://git.openjdk.org/jdk/pull/23542#issuecomment-2787705216 From liach at openjdk.org Tue Apr 8 21:54:26 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Apr 2025 21:54:26 GMT Subject: RFR: 8354061: Update copyright in NameFormat.java fix after JDK-8349890 In-Reply-To: <57J4ns2PhxzYB_v6EeHjZCZXvT6rOSD6p9AWfdFNFsw=.3295e139-a24a-4789-8654-81e8191cacce@github.com> References: <57J4ns2PhxzYB_v6EeHjZCZXvT6rOSD6p9AWfdFNFsw=.3295e139-a24a-4789-8654-81e8191cacce@github.com> Message-ID: On Tue, 8 Apr 2025 19:44:30 GMT, Koushik Muthukrishnan Thirupattur wrote: > 8354061: Update copyright in NameFormat.java fix after JDK-8349890 This trivial bump looks right. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24523#issuecomment-2787718753 From sviswanathan at openjdk.org Tue Apr 8 22:01:42 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 8 Apr 2025 22:01:42 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14] In-Reply-To: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com> References: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com> Message-ID: <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com> On Tue, 8 Apr 2025 21:27:08 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reacting to mor comments from Sandhya. Overall very clean and nicely done PR. Thanks a lot for considering my inputs. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2751503300 From duke at openjdk.org Tue Apr 8 22:02:11 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 8 Apr 2025 22:02:11 GMT Subject: Integrated: 8354061: Update copyright in NameFormat.java fix after JDK-8349890 In-Reply-To: <57J4ns2PhxzYB_v6EeHjZCZXvT6rOSD6p9AWfdFNFsw=.3295e139-a24a-4789-8654-81e8191cacce@github.com> References: <57J4ns2PhxzYB_v6EeHjZCZXvT6rOSD6p9AWfdFNFsw=.3295e139-a24a-4789-8654-81e8191cacce@github.com> Message-ID: On Tue, 8 Apr 2025 19:44:30 GMT, Koushik Muthukrishnan Thirupattur wrote: > 8354061: Update copyright in NameFormat.java fix after JDK-8349890 This pull request has now been integrated. Changeset: 63fa255c Author: Koushik Thirupattur Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/63fa255c06a273b00f99d4e8649dab618cbf5773 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8354061: Update copyright in NameFormat.java fix after JDK-8349890 Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/24523 From duke at openjdk.org Tue Apr 8 23:19:57 2025 From: duke at openjdk.org (TomyLobo) Date: Tue, 8 Apr 2025 23:19:57 GMT Subject: RFR: 8330217: Spurious warning from jarsigner -verify when keystore with intermediate CA is used [v4] In-Reply-To: References: <4Pk_xJTP8JhRGmnshoiD1Jjbn2gXT6Xo-ES0RfYLQnw=.29c3724d-e5fd-4ef2-8a3e-850d1e0d698c@github.com> Message-ID: On Tue, 30 Jul 2024 22:24:04 GMT, Weijun Wang wrote: >> There is an error in `jarsigner` on the "This JAR contains signed entries that aren't signed by alias in this keystore" warning. The exit code is determined by [`notSignedByAlias`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L344) but the warning message is controlled by [`allAliasesFound`](https://github.com/openjdk/jdk/blob/0a60b0f99efb38d2cc97f3862ef95a0d26ba49a7/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L1183). >> >> Also, inside the `inKeyStoreForOneSigner()` method, all certificates in a cert chain are used to determine whether the signer is in a keystore and if any is inside the JAR file is treated as being signed by an alias in this keystore. In fact, only the end-entity certificate (the first one in the chain) should be checked. >> >> After the fix, the `allAliasesFound` field and the `SOME_ALIASES_NOT_FOUND` constant are useless and can be removed. >> >> *Update*: this warning is reclassified as an informational warning in the latest commits. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > enhance test to check for severe and informational warnings ? Please don't merge without changes ? > New commit pushed. > `aliasNotInStore` is no longer considered as a severe warning. > This is reasonable because in a real world we should not expect the JAR file verifier having the signer's key or certificate in their local keystore. Please do not remove this feature. It is essential for people wanting a strict validation vs. a given certificate. Correct me if I'm wrong, but afaik, without that severe warning, all jarsigner does is validate that *anyone* signed this and there's no way to tell if it was signed by the correct signer. One can, with some investigative skills, figure out the signer and textually compare them (or extract the cert manually), but that is cumbersome and few people will realistically do that. If I read the docs correctly, specifying a keystore should cause jarsigner to emit that strict warning, if the signer's certificate is not in the keystore. I can't test that, though, because [JDK-8330217](https://bugs.openjdk.org/browse/JDK-8330217) blocks my testing. > As long the root CA for the signer is in either `cacerts` or the local keystore the verification should succeed with no severe warning. I'm not sure how to interpret that "or". Is `cacerts` still used if -keystore is specified? > The jarsigner man page will need to be updated. > > A new `OutputAnalyzer::shouldContainOrderedSequence` method is added to ensure that a series of strings are contained inside the output in their order. There has an existing similar method `shouldContainMultiLinePattern` but it requires the containing lines are consecutive. Therefore a new method is introduced. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19701#issuecomment-2787840785 From weijun at openjdk.org Tue Apr 8 23:39:42 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 8 Apr 2025 23:39:42 GMT Subject: RFR: 8353888: Implement Key Derivation Function API [v2] In-Reply-To: References: Message-ID: > Finalize the KDF API. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: add enum back ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24520/files - new: https://git.openjdk.org/jdk/pull/24520/files/4ff3b95b..66706a50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24520.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520 PR: https://git.openjdk.org/jdk/pull/24520 From duke at openjdk.org Wed Apr 9 03:36:00 2025 From: duke at openjdk.org (Nibedita Jena) Date: Wed, 9 Apr 2025 03:36:00 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets Message-ID: Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. According to RFC 3546, the host_name limit allowed is 255. With a sample testcase when the host_name length is > 127, exception is thrown: javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( "throwable" : { java.lang.NegativeArraySizeException: -1 at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) e.g. int l = buf.get(); b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 For TLSv1.3, its not an issue until length > 255. According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. ------------- Commit messages: - 8350830: Values converted incorrectly when reading TLS session tickets Changes: https://git.openjdk.org/jdk/pull/24535/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24535&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350830 Stats: 398 lines in 3 files changed: 395 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24535.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24535/head:pull/24535 PR: https://git.openjdk.org/jdk/pull/24535 From duke at openjdk.org Wed Apr 9 05:02:29 2025 From: duke at openjdk.org (Hendrik Schick) Date: Wed, 9 Apr 2025 05:02:29 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 03:28:40 GMT, Nibedita Jena wrote: > Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). > While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. > > Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. > According to RFC 3546, the host_name limit allowed is 255. > With a sample testcase when the host_name length is > 127, exception is thrown: > javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 > javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( > "throwable" : { > java.lang.NegativeArraySizeException: -1 > at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) > at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) > > e.g. > int l = buf.get(); > b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 > > For TLSv1.3, its not an issue until length > 255. > > According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. > Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 389: > 387: final byte[] sessionId = engine.getSession().getId(); > 388: // compare and verify if they are same > 389: if (java.util.Arrays.equals(expected, sessionId)) { import java.util.Arrays ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2034442819 From duke at openjdk.org Wed Apr 9 06:02:30 2025 From: duke at openjdk.org (Hendrik Schick) Date: Wed, 9 Apr 2025 06:02:30 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 03:28:40 GMT, Nibedita Jena wrote: > Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). > While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. > > Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. > According to RFC 3546, the host_name limit allowed is 255. > With a sample testcase when the host_name length is > 127, exception is thrown: > javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 > javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( > "throwable" : { > java.lang.NegativeArraySizeException: -1 > at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) > at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) > > e.g. > int l = buf.get(); > b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 > > For TLSv1.3, its not an issue until length > 255. > > According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. > Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 79: > 77: * The following is to set up the keystores. > 78: */ > 79: private static final String pathToStores = System.getProperty("test.src", ".");; Suggestion: private static final String pathToStores = System.getProperty("test.src", "."); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2034504780 From alanb at openjdk.org Wed Apr 9 06:16:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 9 Apr 2025 06:16:45 GMT Subject: RFR: 8353888: Implement Key Derivation Function API [v2] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 21:03:18 GMT, Chen Liang wrote: >> Oh, I didn't know that. I've built this with JDK 24 as the boot JDK and see no problem. > > I think the dependency is in the CreateSymbols tool or something Yes, we've had issues with boot cycle builds at least, Jan has the details and I think the guidance the last time was to leave it in place to the next release. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2034519284 From djelinski at openjdk.org Wed Apr 9 06:47:30 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 9 Apr 2025 06:47:30 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- I think the usual way to handle this is by calling `P11KeyGenerator.checkKeySize` ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2788490696 From djelinski at openjdk.org Wed Apr 9 07:24:32 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 9 Apr 2025 07:24:32 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 03:28:40 GMT, Nibedita Jena wrote: > Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). > While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. > > Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. > According to RFC 3546, the host_name limit allowed is 255. > With a sample testcase when the host_name length is > 127, exception is thrown: > javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 > javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( > "throwable" : { > java.lang.NegativeArraySizeException: -1 > at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) > at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) > > e.g. > int l = buf.get(); > b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 > > For TLSv1.3, its not an issue until length > 255. > > According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. > Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. Changes requested by djelinski (Reviewer). src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 359: > 357: > 358: // PSK identity > 359: i = Byte.toUnsignedInt(buf.get()); Could you rewrite this constructor to use the helper methods from `sun.security.ssl.Record` instead of reading data from the buffer directly? test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 115: > 113: passphrase); > 114: > 115: SSLContext sslCtx = SSLContext.getInstance(sslProtocol); Use SSLContextTemplate methods to generate the context, if possible test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 268: > 266: clientEngine.setUseClientMode(true); > 267: SSLParameters cliSSLParams = clientEngine.getSSLParameters(); > 268: cliSSLParams.setServerNames(List.of(SNI_NAME)); you could also use `SNI_NAME` as the host parameter of the `createSSLEngine` method above; this way you wouldn't need to set it here. test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 392: > 390: System.out.println(this.sslc.getProvider().getName() + " " + this.sslc.getProtocol() + " - Session resumption SUCCEEDED"); > 391: } else { > 392: System.out.println(this.sslc.getProvider().getName() + " " + this.sslc.getProtocol() + " - Session resumption FAILED"); should the test fail if this happens? Either change this to throw an exception, or remove this method. test/jdk/sun/security/ssl/SSLSessionImpl/keystore_san.p12 line 1: > 1: 0??0?? *?H?? Can you use the SSLContextTemplate class instead? If not, please add a readme describing how this file can be regenerated. ------------- PR Review: https://git.openjdk.org/jdk/pull/24535#pullrequestreview-2752317840 PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2034632391 PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2034639617 PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2034645788 PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2034654626 PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2034624226 From michaelm at openjdk.org Wed Apr 9 10:04:47 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 9 Apr 2025 10:04:47 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v4] In-Reply-To: References: Message-ID: <7QqAa8kPfdRpCCwiAleAk7v53UshuArCnUvMpRR0On8=.4646bb5b-5382-437c-9e7e-9e8513698d4a@github.com> > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Apply suggestions from code review from turbanoff review Co-authored-by: Andrey Turbanov - doc + copyright update - remove file added by mistake - whitespace - moved test - Merge branch 'master' into 8348986-exceptions - update - update - ... and 7 more: https://git.openjdk.org/jdk/compare/f7fa05f5...f5501d18 ------------- Changes: https://git.openjdk.org/jdk/pull/23929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=03 Stats: 1000 lines in 42 files changed: 767 ins; 104 del; 129 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From myankelevich at openjdk.org Wed Apr 9 11:22:31 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 9 Apr 2025 11:22:31 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: <5IpSog9-rq8LBc7eYeSBjpzelGd2rinHZCITuPSM_M4=.d82a80ae-5f7e-4912-abf4-90ca4eac08b3@github.com> On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 41: > 39: import sun.security.pkcs11.wrapper.*; > 40: import static sun.security.pkcs11.wrapper.PKCS11Constants.*; > 41: import static sun.security.pkcs11.wrapper.PKCS11Exception.RV.*; Nitpick: Does this import need to be a `*`? Wouldn't it be better to just have a `import static sun.security.pkcs11.wrapper.PKCS11Exception.RV.CKR_KEY_SIZE_RANGE; `? test/jdk/sun/security/pkcs11/KDF/TestHKDF.java line 619: > 617: k.deriveKey("AES", HKDFParameterSpec.ofExtract() > 618: .thenExpand(null, 31)); > 619: throw new Exception("No exception thrown."); I think this throw is unnecessary, you can just call this code straight on line 619 and remove the catch block below reportTestFailure(new Exception("Derivation of an AES key of " + "invalid size (31 bytes) expected to throw " + "InvalidAlgorithmParameterException.", e)); What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2035131173 PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2035122389 From duke at openjdk.org Wed Apr 9 12:57:06 2025 From: duke at openjdk.org (Nibedita Jena) Date: Wed, 9 Apr 2025 12:57:06 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v2] In-Reply-To: References: Message-ID: <-NEwoCypbb1q4sb-Va4C_BfKSfegYOOOz3TMIjx-94k=.b7bc0dcc-30bb-40e2-8e7e-9284de0023c7@github.com> > Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). > While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. > > Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. > According to RFC 3546, the host_name limit allowed is 255. > With a sample testcase when the host_name length is > 127, exception is thrown: > javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 > javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( > "throwable" : { > java.lang.NegativeArraySizeException: -1 > at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) > at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) > > e.g. > int l = buf.get(); > b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 > > For TLSv1.3, its not an issue until length > 255. > > According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. > Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: Minor change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24535/files - new: https://git.openjdk.org/jdk/pull/24535/files/81ea059c..46d4a6e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24535&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24535&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24535.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24535/head:pull/24535 PR: https://git.openjdk.org/jdk/pull/24535 From duke at openjdk.org Wed Apr 9 13:04:44 2025 From: duke at openjdk.org (Nibedita Jena) Date: Wed, 9 Apr 2025 13:04:44 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v2] In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 07:05:14 GMT, Daniel Jeli?ski wrote: >> Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor change > > test/jdk/sun/security/ssl/SSLSessionImpl/keystore_san.p12 line 1: > >> 1: 0??0?? *?H?? > > Can you use the SSLContextTemplate class instead? > If not, please add a readme describing how this file can be regenerated. Since this new testcase is mainly targeting for SNI hence the keystore being added with given extension. Hence made it different from common SSLContextTemplate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2035323557 From mbalao at openjdk.org Wed Apr 9 13:22:36 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 9 Apr 2025 13:22:36 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Wed, 9 Apr 2025 06:45:14 GMT, Daniel Jeli?ski wrote: > I think the usual way to handle this is by calling `P11KeyGenerator.checkKeySize` We discussed calling `P11KeyGenerator::checkKeySize` with @franferrax but were not sure of taking this approach. We found that for DES(3) cases some fixed values are considered valid but wondered if, in theory, the PKCS 11 library can be configured to be more restrictive and reject some of them. Given that this is an error-path and should be exceptional, we thought that the cost of passing the operation to the token and handling the error was affordable. Perhaps we can do both: check beforehand and handle the error afterwards. I'll give it some more thinking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2789680355 From mbalao at openjdk.org Wed Apr 9 13:34:36 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 9 Apr 2025 13:34:36 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <5IpSog9-rq8LBc7eYeSBjpzelGd2rinHZCITuPSM_M4=.d82a80ae-5f7e-4912-abf4-90ca4eac08b3@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <5IpSog9-rq8LBc7eYeSBjpzelGd2rinHZCITuPSM_M4=.d82a80ae-5f7e-4912-abf4-90ca4eac08b3@github.com> Message-ID: <34h5WHbDb13rSttly1hg0G75MwvujDrSzEquHl31mEw=.a8ceef28-79de-4af6-94cb-5573421ee149@github.com> On Wed, 9 Apr 2025 10:57:45 GMT, Mikhail Yankelevich wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > test/jdk/sun/security/pkcs11/KDF/TestHKDF.java line 619: > >> 617: k.deriveKey("AES", HKDFParameterSpec.ofExtract() >> 618: .thenExpand(null, 31)); >> 619: throw new Exception("No exception thrown."); > > I think this throw is unnecessary, you can just call this code straight on line 619 and remove the catch block below > > reportTestFailure(new Exception("Derivation of an AES key of " + > "invalid size (31 bytes) expected to throw " + > "InvalidAlgorithmParameterException.", e)); > > > What do you think? The catch block would still be needed because another exception (such as `ProviderException`, as is the case now) might be thrown and we want to make sure that it does not occur. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2035384667 From mbalao at openjdk.org Wed Apr 9 13:40:35 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 9 Apr 2025 13:40:35 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <5IpSog9-rq8LBc7eYeSBjpzelGd2rinHZCITuPSM_M4=.d82a80ae-5f7e-4912-abf4-90ca4eac08b3@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <5IpSog9-rq8LBc7eYeSBjpzelGd2rinHZCITuPSM_M4=.d82a80ae-5f7e-4912-abf4-90ca4eac08b3@github.com> Message-ID: On Wed, 9 Apr 2025 11:03:52 GMT, Mikhail Yankelevich wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 41: > >> 39: import sun.security.pkcs11.wrapper.*; >> 40: import static sun.security.pkcs11.wrapper.PKCS11Constants.*; >> 41: import static sun.security.pkcs11.wrapper.PKCS11Exception.RV.*; > > Nitpick: Does this import need to be a `*`? Wouldn't it be better to just have a `import static sun.security.pkcs11.wrapper.PKCS11Exception.RV.CKR_KEY_SIZE_RANGE; > `? Ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2035397303 From weijun at openjdk.org Wed Apr 9 14:01:39 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 9 Apr 2025 14:01:39 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v6] In-Reply-To: References: Message-ID: On Wed, 19 Mar 2025 18:08:40 GMT, Mikhail Yankelevich wrote: >> Moved the sh file logic to jtreg java test. > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor: space at the end test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 52: > 50: import jtreg.SkippedException; > 51: > 52: public class MultipleLogins extends PKCS11Test { Is there any special reason to not keep the class standalone and make it a subclass of `PKCS11Test`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23590#discussion_r2035441446 From weijun at openjdk.org Wed Apr 9 14:27:34 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 9 Apr 2025 14:27:34 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v6] In-Reply-To: References: Message-ID: On Wed, 19 Mar 2025 18:08:40 GMT, Mikhail Yankelevich wrote: >> Moved the sh file logic to jtreg java test. > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor: space at the end test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 75: > 73: for (int i = 0; i < NUM_PROVIDERS; i++) { > 74: // loop to set up test without security manger > 75: providers[i] = (SunPKCS11)newPKCS11Provider(); Not sure if it's worth updating, but since `configure` always returns a new provider, there is no need to call `newPKCS11Provider` here and we can just call `configure` on the same `Security.getProvider("SunPKCS11")`. Also, you can use the public `AuthProvider` instead of internal class `SunPKCS11` everywhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23590#discussion_r2035495685 From myankelevich at openjdk.org Wed Apr 9 14:30:45 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 9 Apr 2025 14:30:45 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v2] In-Reply-To: <-NEwoCypbb1q4sb-Va4C_BfKSfegYOOOz3TMIjx-94k=.b7bc0dcc-30bb-40e2-8e7e-9284de0023c7@github.com> References: <-NEwoCypbb1q4sb-Va4C_BfKSfegYOOOz3TMIjx-94k=.b7bc0dcc-30bb-40e2-8e7e-9284de0023c7@github.com> Message-ID: On Wed, 9 Apr 2025 12:57:06 GMT, Nibedita Jena wrote: >> Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). >> While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. >> >> Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. >> According to RFC 3546, the host_name limit allowed is 255. >> With a sample testcase when the host_name length is > 127, exception is thrown: >> javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 >> javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( >> "throwable" : { >> java.lang.NegativeArraySizeException: -1 >> at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) >> at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) >> >> e.g. >> int l = buf.get(); >> b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 >> >> For TLSv1.3, its not an issue until length > 255. >> >> According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. >> Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. > > Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: > > Minor change test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 33: > 31: import javax.net.ssl.*; > 32: import javax.net.ssl.SSLEngineResult.HandshakeStatus; > 33: import java.io.*; Nitpick: wildcard import test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 44: > 42: * Enables logging of the SSLEngine operations. > 43: */ > 44: private static final boolean logging = false; I strongly believe logging should be on at all times, no logging will make debugging challenging especially if the issue is intermittent. test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 55: > 53: * after gaining some familiarity with this application. > 54: */ > 55: private static final boolean debug = true; Could you please get the debug from the `private static final boolean debug = Boolean.parseBoolean(System.getProperty("test.debug", "true"));` or `private static final boolean debug = Boolean.getBoolean("test.debug");` ? Also, why is the `debug` is set to true by default? It makes more sense to remove it all together imo and just log everything, with this off it will be very hard to see what's wrong. test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 98: > 96: */ > 97: public static void main(String args[]) throws Exception { > 98: if (debug) { If you remove the debug, this can be removed and the property could be set at `@run` on line 26. I think this will also remove the need for othervm. test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 361: > 359: if (resultOnce) { > 360: resultOnce = false; > 361: System.out.println("The format of the SSLEngineResult is: \n" + Why is this needed? Wouldn't it be more appropriate to have it outside the logging and just print it out as a description? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2035405118 PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2035398129 PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2035180058 PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2035469081 PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2035473407 From djelinski at openjdk.org Wed Apr 9 14:34:32 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 9 Apr 2025 14:34:32 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Wed, 9 Apr 2025 13:19:45 GMT, Martin Balao wrote: > Perhaps we can do both: check beforehand and handle the error afterwards. That sounds reasonable. Whatever you decide, I think it would be good to make sure P11HKDF, P11SecretKeyFactory and P11KeyGenerator perform the same checks during key generation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2789946445 From ihse at openjdk.org Wed Apr 9 15:09:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 9 Apr 2025 15:09:58 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com> On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Convert the merged master changes to UTF-8 > - Merge master and fix conflicts > - Close streams when finished loading into props > - Adjust CF test to read in with UTF-8 to fix failing test > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties > - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22: > 20: # Peter Smolik > 21: Cp1250 WINDOWS-1250 0x00FF > 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil) This does not seem to have been a correct conversion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2035582242 From mpowers at openjdk.org Wed Apr 9 15:29:39 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 9 Apr 2025 15:29:39 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v4] In-Reply-To: References: Message-ID: <5lUCJwLj9quu-YSGr1v33aKi_zv_cD4Id-ljCdQIZ5E=.dcc03592-6aad-4a9e-88aa-38466377e757@github.com> On Tue, 11 Feb 2025 18:46:29 GMT, Mikhail Yankelevich wrote: >> Refactored the runNameEquals.sh to java test > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor Looks good to me. IntelliJ couldn't find problems either. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23542#issuecomment-2790111917 From mdonovan at openjdk.org Wed Apr 9 16:41:37 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 9 Apr 2025 16:41:37 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v6] In-Reply-To: References: Message-ID: On Wed, 19 Mar 2025 18:08:40 GMT, Mikhail Yankelevich wrote: >> Moved the sh file logic to jtreg java test. > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor: space at the end test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 132: > 130: > 131: throw new RuntimeException("Token was present", e); > 132: } // else expected does this comment mean that the received exception `e` is expected or that you're expecting an `else` clause that isn't here yet? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23590#discussion_r2035748171 From duke at openjdk.org Wed Apr 9 17:12:47 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 9 Apr 2025 17:12:47 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14] In-Reply-To: <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com> References: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com> <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com> Message-ID: On Tue, 8 Apr 2025 21:58:57 GMT, Sandhya Viswanathan wrote: > Overall very clean and nicely done PR. Thanks a lot for considering my inputs. That is in no small part thanks to the reviewers, especially to Volodymyr! @lmesnik, @jatin-bhateja, @sviswa7 would one of you /sponsor me with the integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2790417248 From weijun at openjdk.org Wed Apr 9 18:15:03 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 9 Apr 2025 18:15:03 GMT Subject: RFR: 8353888: Implement Key Derivation Function API [v3] In-Reply-To: References: Message-ID: > Finalize the KDF API. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update @since tags as required by JEP 12 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24520/files - new: https://git.openjdk.org/jdk/pull/24520/files/66706a50..a55c5069 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=01-02 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24520.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520 PR: https://git.openjdk.org/jdk/pull/24520 From sviswanathan at openjdk.org Wed Apr 9 18:42:45 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 9 Apr 2025 18:42:45 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14] In-Reply-To: References: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com> <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com> Message-ID: On Wed, 9 Apr 2025 17:09:09 GMT, Ferenc Rakoczi wrote: >> Overall very clean and nicely done PR. Thanks a lot for considering my inputs. > >> Overall very clean and nicely done PR. Thanks a lot for considering my inputs. > > That is in no small part thanks to the reviewers, especially to Volodymyr! > @lmesnik, @jatin-bhateja, @sviswa7 would one of you /sponsor me with the integration? @ferakocz Once you do /integrate, I will be honored to sponsor your PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2790618572 From duke at openjdk.org Wed Apr 9 19:33:37 2025 From: duke at openjdk.org (duke) Date: Wed, 9 Apr 2025 19:33:37 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14] In-Reply-To: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com> References: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com> Message-ID: On Tue, 8 Apr 2025 21:27:08 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Reacting to mor comments from Sandhya. @ferakocz Your change (at version 0b0d0969d6ac629bf2ca997d2286c4d28f91c1b9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2790791121 From duke at openjdk.org Wed Apr 9 19:33:35 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 9 Apr 2025 19:33:35 GMT Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v14] In-Reply-To: References: <394Wf5RpbwUgE7zBaZBnwa2YAxQFwWDhF1VuaMPHdhE=.98ff29f7-b6a7-49eb-bdd6-8489568b24b7@github.com> <-W1vBCTLtPyOZNm6XhHQXT9spBbkAd4Z4rTn_LHH1Aw=.5beae719-ac8b-404a-a34c-deecfc97dd7e@github.com> Message-ID: On Wed, 9 Apr 2025 17:09:09 GMT, Ferenc Rakoczi wrote: >> Overall very clean and nicely done PR. Thanks a lot for considering my inputs. > >> Overall very clean and nicely done PR. Thanks a lot for considering my inputs. > > That is in no small part thanks to the reviewers, especially to Volodymyr! > @lmesnik, @jatin-bhateja, @sviswa7 would one of you /sponsor me with the integration? > @ferakocz Once you do /integrate, I will be honored to sponsor your PR. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2790788483 From skuksenko at openjdk.org Wed Apr 9 19:34:24 2025 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Wed, 9 Apr 2025 19:34:24 GMT Subject: RFR: 8353478: Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms [v3] In-Reply-To: References: Message-ID: <3hFUKagMkYaowhCw9wP6jPdwBj4O4DLUwv0-E6S2TG8=.8861fb5c-5cec-4eee-97e0-7e6558c2d6f8@github.com> > Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms. Sergey Kuksenko has updated the pull request incrementally with three additional commits since the last revision: - Update SignatureBench.java Specify explicit algorithm and fix copyright typo - Update KeyPairGeneratorBench.java Specify explicit algorithms - Update KEMBench.java Specify explicit algorithm ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24369/files - new: https://git.openjdk.org/jdk/pull/24369/files/a9296af8..f5027c53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24369&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24369&range=01-02 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24369.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24369/head:pull/24369 PR: https://git.openjdk.org/jdk/pull/24369 From duke at openjdk.org Wed Apr 9 21:18:35 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 9 Apr 2025 21:18:35 GMT Subject: Integrated: 8351034: Add AVX-512 intrinsics for ML-DSA In-Reply-To: References: Message-ID: On Mon, 3 Mar 2025 11:12:58 GMT, Ferenc Rakoczi wrote: > By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled. This pull request has now been integrated. Changeset: e87ff328 Author: Ferenc Rakoczi Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/e87ff328d5cc66454213dee44cf2faeb0e76262f Stats: 1307 lines in 10 files changed: 1265 ins; 27 del; 15 mod 8351034: Add AVX-512 intrinsics for ML-DSA Reviewed-by: sviswanathan, lmesnik, vpaprotski, jbhateja ------------- PR: https://git.openjdk.org/jdk/pull/23860 From jlu at openjdk.org Wed Apr 9 21:28:41 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 9 Apr 2025 21:28:41 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com> Message-ID: On Wed, 9 Apr 2025 15:06:32 GMT, Magnus Ihse Bursie wrote: >> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Convert the merged master changes to UTF-8 >> - Merge master and fix conflicts >> - Close streams when finished loading into props >> - Adjust CF test to read in with UTF-8 to fix failing test >> - Reconvert CS.properties to UTF-8 >> - Revert all changes to CurrencySymbols.properties >> - Bug6204853 should not be converted >> - Copyright year for CompileProperties >> - Redo translation for CS.properties >> - Spot convert CurrencySymbols.properties >> - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22: > >> 20: # Peter Smolik >> 21: Cp1250 WINDOWS-1250 0x00FF >> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil) > > This does not seem to have been a correct conversion. Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.) Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036165417 From fferrari at openjdk.org Thu Apr 10 00:25:51 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Thu, 10 Apr 2025 00:25:51 GMT Subject: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions Message-ID: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> Hi, this is a proposal to fix 8352728. The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following: 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`. 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`. #### Windows Case @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf: * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`: * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473") * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288") * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop) * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/java.base/windows/native/libjava/canonicalize_md.c:246-250"). This may leave a partially normalized path, but it doesn't stop the processing, allowing [later symlinks resolution](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L476 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:476"). * [`Path::toRealPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/nio/file/Path.java#L804 "src/java.base/share/classes/java/nio/file/Path.java:804") goes through the following stack into `FindFirstFileW`: * [`WindowsPath::toRealPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/sun/nio/fs/WindowsPath.java#L907 "src/java.base/windows/classes/sun/nio/fs/WindowsPath.java:907") * [`WindowsLinkSupport::getRealPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java#L255 "src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java:255") (here is the loop) * [`WindowsNativeDispatcher::FindFirstFile`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java#L182 "src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java:182") * [`WindowsNativeDispatcher::FindFirstFile0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c#L330 "src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c:330") * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, a `WindowsException` is [immediately thrown](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c#L341 "src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c:341"), then caught and [rethrown as an `IOException`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java#L280 "src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java:280") (in particular `AccessDeniedException`). This not only stops the iteration but also makes the `Path::toRealPath` call fail. NOTE: In cases in which `File::getCanonicalPath` gives a partially normalized path due to lack of permissions, the impact on cycle detection should be negligible: any include that leads to infinite recursion will revisit the exact same path at some point (even if not normalized). #### Testing The proposed `ConfigFileTestDirPermissions` test is passing, and no regressions have been found in `test/jdk/java/security/Security/ConfigFileTest.java` (_Windows_ and _Linux_). Also, the [GitHub Actions testing run (`tier1` on various platforms)](https://github.com/franferrax/jdk/actions/runs/14363107070) has passed. #### Testing Appendix I could not make a fully automated symlinks resolution test in _Windows_, so I'm posting here a _PowerShell_ extended version of `ConfigFileTestDirPermissions`. This test requires user interaction, to accept _UAC_ elevation when creating the symlink. To run it, just paste the whole snippet in a non-elevated _PowerShell_ terminal at the root of a built `jdk` repository.
ConfigFileTestDirPermissionsEx PowerShell test function ConfigFileTestDirPermissionsEx { # Ensures java.security is loaded and symlinks are resolved in Windows, # even when the user does not have permissions on a parent directory. # Make sure we run non-elevated $user = [Security.Principal.WindowsIdentity]::GetCurrent() $adminRole = [Security.Principal.WindowsBuiltInRole]::Administrator $principal = New-Object Security.Principal.WindowsPrincipal($user) if ($principal.IsInRole($adminRole)) { throw "Must run non-elevated!" } $originalJdk = Get-Item -ErrorAction SilentlyContinue "build/*/images/jdk" # Make sure a built JDK image is found if (![System.IO.Directory]::Exists($originalJdk.FullName)) { throw "Could not find a built image, must run from the jdk repo root" } # Create temporary directory $tempDirName = "JDK-8352728-tmp-" + (New-Guid).ToString("N") $tempDir = Join-Path ([System.IO.Path]::GetTempPath()) $tempDirName New-Item $tempDir -ItemType Directory | Out-Null try { # Copy the jdk to a different directory $jdk = Join-Path $tempDir "jdk-parent-dir/jdk" Copy-Item -Recurse $originalJdk $jdk # Create an extra.properties file with a relative include in it $include = Join-Path $tempDir "relatively.included.properties" $testProperty = "test.property.name=test_property_value" Out-File -Encoding ascii $include -InputObject $testProperty $extra = Join-Path $tempDir "extra.properties" $content = "include " + (Split-Path -Leaf $include) Out-File -Encoding ascii $extra -InputObject $content # Create a symlink to extra.properties, from the jdk directory $mainPropsDir = Join-Path $jdk "conf/security" $mainProps = Join-Path $mainPropsDir "java.security" $link = Join-Path $mainPropsDir "link.to.extra.properties" Start-Process -Wait -Verb RunAs -WindowStyle Hidden "cmd.exe" @( "/c", "mklink", $link, $extra ) # Include link.to.extra.properties from java.security $content = "`ninclude " + (Split-Path -Leaf $link) Out-File -Encoding ascii -Append $mainProps -InputObject $content # Remove current user permissions from jdk-parent-dir $parent = Split-Path -Parent $jdk $newAcl = New-Object System.Security.AccessControl.DirectorySecurity $newAcl.SetAccessRule((New-Object ` System.Security.AccessControl.FileSystemAccessRule( $user.Name, "FullControl", "Deny" ) )) $originalAcl = Get-Acl $parent Set-Acl $parent $newAcl try { # Make sure the permissions are affecting the current user $java = Join-Path $jdk "bin/java.exe" $stderrFile = Join-Path $tempDir "StandardError.txt" $realPath = Join-Path $tempDir "RealPath.java" Out-File -Encoding ascii $realPath -InputObject @" public final class RealPath { public static void main(String[] args) throws Exception { java.nio.file.Path.of(args[0]).toRealPath(); } } "@ $proc = Start-Process -Wait -WindowStyle Hidden -PassThru ` -RedirectStandardError $stderrFile $java @( $realPath, $mainProps ) $stderrContent = Get-Content $stderrFile if ($proc.ExitCode -eq 0) { throw "Directory should affect the user, expected to fail" } if (($stderrContent -match "AccessDeniedException").Length -eq 0) { throw "Failure was not an AccessDeniedException" } # Execute the copied jdk, ensuring java.security.Security is # loaded (i.e. use -XshowSettings:security:properties) $proc = Start-Process -Wait -WindowStyle Hidden -PassThru ` -RedirectStandardError $stderrFile $java @( "-Djava.security.debug=properties", "-XshowSettings:security:properties", "-version" ) $stderrContent = Get-Content $stderrFile Write-Output $stderrContent if ($proc.ExitCode -ne 0) { throw "Execution failed" } if (($stderrContent -match $testProperty).Length -eq 0) { throw "Expected '$testProperty' property not found" } Write-Output "TEST PASS - OK" } finally { Set-Acl $parent $originalAcl } } finally { Remove-Item -Recurse -Force $tempDir } } ConfigFileTestDirPermissionsEx
------------- Commit messages: - 8352728: InternalError loading java.security due to Windows parent folder permissions Changes: https://git.openjdk.org/jdk/pull/24465/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24465&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352728 Stats: 102 lines in 2 files changed: 97 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24465.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24465/head:pull/24465 PR: https://git.openjdk.org/jdk/pull/24465 From valeriep at openjdk.org Thu Apr 10 03:14:33 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Apr 2025 03:14:33 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- test/jdk/sun/security/pkcs11/KDF/TestHKDF.java line 619: > 617: k.deriveKey("AES", HKDFParameterSpec.ofExtract() > 618: .thenExpand(null, 31)); > 619: throw new Exception("No exception thrown."); nit: "Expected InvalidAlgorithmParameterException not thrown" is clearer? test/jdk/sun/security/pkcs11/KDF/TestHKDF.java line 625: > 623: reportTestFailure(new Exception("Derivation of an AES key of " + > 624: "invalid size (31 bytes) expected to throw " + > 625: "InvalidAlgorithmParameterException.", e)); Why not just use `reportTestFailure(e)`? I don't find the extra layer of exception too useful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2036420476 PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2036421991 From wetmore at openjdk.org Thu Apr 10 03:14:36 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 10 Apr 2025 03:14:36 GMT Subject: RFR: 8350582: Correct the parsing of the ssl value in javax.net.debug [v3] In-Reply-To: References: Message-ID: On Thu, 6 Mar 2025 20:10:58 GMT, Sean Coffey wrote: >> Breaking the parent JDK-8044609 JBS issue into sub tasks. >> >> This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced. This patch should be easier for backporting also. >> >> Wider corrections can be followed up via parent bug. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate latest review feedback Depending on the followup discussion of what `ssl` alone means. However, several suggestions below, one might help with test coverage. If you take some/all, then I'll review again. Should be quick. test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 1: > 1: /* A suggestion that could ease/increase test coverage: HashMap masterMap = new HashMap<>(); // add one for each output category. masterMap.put("handshake", "Produced ClientHello handshake message"); // ... // for each testcase { // missing = clone masterMap; // start with the full map // required = new HashMap(); // create an empty map // for each key in the test case { // missing.remove(value); // required.add(value); // } // runTest(); // check each value String in required is present // check each value String in missing is not // } You can then easily add test cases with: test("ssl","handshake"); // use "..." params if you don't want to do String parsing, and have multiple params test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 27: > 25: * @test > 26: * @bug 8350582 > 27: * @library /test/lib /javax/net/ssl/templates ../../ Is `../..` actually needed? It ran fine in another test directory several levels below this one. test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 28: > 26: * @bug 8350582 > 27: * @library /test/lib /javax/net/ssl/templates ../../ > 28: * @summary Verify debug output for different javax.net.debug scenarios Isn't the summary supposed to match the bugid's description? test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 59: > 57: > 58: private static Stream patternMatches() { > 59: // "Plaintext before ENCRYPTION" comes from "ssl:record:plaintext" option Minor nits. >= 80 chars in some lines. You could leave as is, or shorten the searched-for message. I'm ok if you really want to leave, as I don't expect lots of changes in this file. (horizontal scrolling during reviews is my pet peeve) Or you could do: `Produced ClientHello handshake message` -> `Produced ClientHello handshake` test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 168: > 166: } > 167: > 168: public static void main(String[] args) throws Exception { Is this here because for running outside of jtreg, say via the command line? ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23781#pullrequestreview-2755088852 PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r2036411141 PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r2036335133 PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r2036416941 PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r2036338994 PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r2036419493 From valeriep at openjdk.org Thu Apr 10 03:30:25 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Apr 2025 03:30:25 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- On a related note, I am working on https://github.com/openjdk/jdk/pull/24393 and noticed that JSSE calls HKDF.deriveKey(...) with various names such as "TlsFinishedSecret", "TlsResumptionMasterSecret" as the key algorithm. This causes errors when using PKCS11 HKDF since the `P11SecretKeyFactory.getKeyInfo()` look up returns `null` and leads to `InvalidAlgorithmParameterException`. I am debating whether to do the special handling as below: P11SecretKeyFactory.KeyInfo ki = P11SecretKeyFactory.getKeyInfo(alg); if (ki == null) { - throw new InvalidAlgorithmParameterException("A PKCS #11 key " + - "type (CKK_*) was not found for a key of the algorithm '" + - alg + "'."); + // special handling for TLS + if (alg.startsWith("Tls")) { + ki = P11SecretKeyFactory.getKeyInfo("Generic"); + } else { + throw new InvalidAlgorithmParameterException("A PKCS #11 key " + + "type (CKK_*) was not found for a key of the algorithm '" + + alg + "'."); + } Comments or suggestions? @martinuy ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2791454433 From mbalao at openjdk.org Thu Apr 10 03:38:24 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 10 Apr 2025 03:38:24 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 10 Apr 2025 03:08:32 GMT, Valerie Peng wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > test/jdk/sun/security/pkcs11/KDF/TestHKDF.java line 619: > >> 617: k.deriveKey("AES", HKDFParameterSpec.ofExtract() >> 618: .thenExpand(null, 31)); >> 619: throw new Exception("No exception thrown."); > > nit: "Expected InvalidAlgorithmParameterException not thrown" is clearer? This exception will be the cause, the wrapper exception will inform that `InvalidAlgorithmParameterException` was expected to be thrown. > test/jdk/sun/security/pkcs11/KDF/TestHKDF.java line 625: > >> 623: reportTestFailure(new Exception("Derivation of an AES key of " + >> 624: "invalid size (31 bytes) expected to throw " + >> 625: "InvalidAlgorithmParameterException.", e)); > > Why not just use `reportTestFailure(e)`? I don't find the extra layer of exception too useful. To be more informative, because the original exception ?not the one that we would throw if no exception is thrown? does not state which exception was expected to be thrown, is just a `ProviderException` which may even look good/appropriate for an invalid key size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2036438251 PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2036436647 From mbalao at openjdk.org Thu Apr 10 03:57:29 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 10 Apr 2025 03:57:29 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- > On a related note, I am working on #24393 and noticed that JSSE calls HKDF.deriveKey(...) with various names such as "TlsFinishedSecret", "TlsResumptionMasterSecret" as the key algorithm. This causes errors when using PKCS11 HKDF since the `P11SecretKeyFactory.getKeyInfo()` look up returns `null` and leads to `InvalidAlgorithmParameterException`. I am debating whether to do the special handling as below: > > ``` > P11SecretKeyFactory.KeyInfo ki = P11SecretKeyFactory.getKeyInfo(alg); > if (ki == null) { > - throw new InvalidAlgorithmParameterException("A PKCS #11 key " + > - "type (CKK_*) was not found for a key of the algorithm '" + > - alg + "'."); > + // special handling for TLS > + if (alg.startsWith("Tls")) { > + ki = P11SecretKeyFactory.getKeyInfo("Generic"); > + } else { > + throw new InvalidAlgorithmParameterException("A PKCS #11 key " + > + "type (CKK_*) was not found for a key of the algorithm '" + > + alg + "'."); > + } > ``` > > Comments or suggestions? @martinuy Thanks for the heads up. I was just looking at the possibility of passing key algorithms for derived keys that were not considered before but are part of the map (e.g. hmac, pbe, etc.), and wondered how that should be handled. Tls could be the opposite case: not part of the map but needs to be handled. Will give it some thinking. I was also thinking of extending the `P11SecretKeyFactory::keyInfo` map to include key generation mechanisms that would facilitate querying `CK_MECHANISM_INFO` and obtaining valid key size ranges for each key type. This would simplify the call to `P11KeyGenerator::checkKeySize` from `P11SecretKeyFactory::createKey` and allow a call from `P11HKDF`. While the idea suggested by @djelinski sounds reasonable, I want to notice an implicit assumption that may not hold true for all PKCS 11 libraries: `CK_MECHANISM_INFO` data for mechanisms such as `CKM_AES_KEY_GEN` will be used for mechanisms such as `CKM_HKDF_DATA`/`CKM_HKDF_DERIVE`. `P11SecretKeyFactory::createKey` has a similar type of assumption. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2791482999 From duke at openjdk.org Thu Apr 10 05:09:52 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Thu, 10 Apr 2025 05:09:52 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v16] In-Reply-To: References: Message-ID: > java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc. > > image > > > > NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page. Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: 8328914: Document the java.security.debug property in javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23569/files - new: https://git.openjdk.org/jdk/pull/23569/files/ba6caeb6..00efddca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=14-15 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23569/head:pull/23569 PR: https://git.openjdk.org/jdk/pull/23569 From alanb at openjdk.org Thu Apr 10 05:54:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 10 Apr 2025 05:54:36 GMT Subject: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> Message-ID: <4zW7XEoxy4YlShEw_Jf6ZPMn1llJ09c6sye_tyvhswU=.f5d74ea1-5026-4812-b9ac-9d21c54a90b2@github.com> On Sat, 5 Apr 2025 02:36:43 GMT, Francisco Ferrari Bihurriet wrote: > Hi, this is a proposal to fix 8352728. > > The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following: > > 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`. > 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`. > > #### Windows Case > > @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf: > > * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`: > * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473") > * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288") > * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop) > * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/java.base/windows/native/libjava/c... I don't think this change should be integrated. Instead, I think start by finding out why this code is using toRealPath. For the two cases, it looks like toRealPath is correctly failing for the first, but for /dev/stdin then please bring it to nio-dev to discuss how special devices should be handled by that method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-2791631369 From ihse at openjdk.org Thu Apr 10 07:34:37 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 10 Apr 2025 07:34:37 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com> Message-ID: On Wed, 9 Apr 2025 21:26:15 GMT, Justin Lu wrote: >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22: >> >>> 20: # Peter Smolik >>> 21: Cp1250 WINDOWS-1250 0x00FF >>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil) >> >> This does not seem to have been a correct conversion. > > Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.) > > Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that. You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036695622 From ihse at openjdk.org Thu Apr 10 07:34:37 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 10 Apr 2025 07:34:37 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com> Message-ID: On Thu, 10 Apr 2025 07:31:37 GMT, Magnus Ihse Bursie wrote: >> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.) >> >> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that. > > You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well. If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036696723 From eirbjo at openjdk.org Thu Apr 10 08:10:42 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 10 Apr 2025 08:10:42 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com> Message-ID: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com> On Thu, 10 Apr 2025 07:32:18 GMT, Magnus Ihse Bursie wrote: >> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well. > > If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed. Some observations: 1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ? 2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change. 3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd` 4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8: byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1); String decoded = new String(origBytes, StandardCharsets.UTF_8); byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8); String hex = HexFormat.of().formatHex(encoded); assertEquals("efbfbd", hex); ``` Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036767319 From ihse at openjdk.org Thu Apr 10 08:38:38 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 10 Apr 2025 08:38:38 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com> <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com> Message-ID: On Thu, 10 Apr 2025 08:08:02 GMT, Eirik Bj?rsn?s wrote: >> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed. > > Some observations: > > 1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ? > > 2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change. > > 3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd` > > 4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8: > > > byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1); > String decoded = new String(origBytes, StandardCharsets.UTF_8); > byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8); > String hex = HexFormat.of().formatHex(encoded); > assertEquals("efbfbd", hex); > ``` > > Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files. > This PR seems to have been abondoned, so perhaps this discussion belongs in https://github.com/openjdk/jdk/pull/15694 ? Oh, I didn't notice this was supplanted by another PR. It might be better to continue there, yes. Even if closed PRs seldom are the best places to conduct discussions, I think it might be a good idea to scrutinize all files modified by this script. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036820765 From ihse at openjdk.org Thu Apr 10 08:41:45 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 10 Apr 2025 08:41:45 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote: >> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. >> >> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. >> >> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) >> >> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. >> >> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Replace InputStreamReader with BufferedReader Continuing the discussion that was started at a predecessor to this PR, https://github.com/openjdk/jdk/pull/12726#discussion_r2035582242. At least one incorrect conversion has been found in this PR. It might be worthwhile to double- and triple-check all the other conversions as well. As part of https://bugs.openjdk.org/browse/JDK-8301971 I am trying various ways of detecting files without UTF-8 encoding, but it is still a bit of hit and miss, since there are no surefire way of telling which encoding a file has, only heuristics. So finding and following up potential sources of error is important. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791991649 PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791997157 From eirbjo at openjdk.org Thu Apr 10 08:48:37 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 10 Apr 2025 08:48:37 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: Message-ID: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com> On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote: >> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. >> >> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. >> >> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) >> >> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. >> >> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Replace InputStreamReader with BufferedReader FWIW, I checked out the revision of the commit previous to this change and found the following: % git checkout b55e418a077791b39992042411cde97f68dc39fe^ % find src -name "*.properties" | xargs file | grep -v ASCII src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: ISO-8859 text src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties: Unicode text, UTF-8 text, with very long lines (322) Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792014164 From ihse at openjdk.org Thu Apr 10 09:45:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 10 Apr 2025 09:45:56 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote: >> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files. >> >> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files. >> >> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`) >> >> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`. >> >> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Replace InputStreamReader with BufferedReader Thanks for checking! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792170460 From fferrari at openjdk.org Thu Apr 10 13:09:32 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Thu, 10 Apr 2025 13:09:32 GMT Subject: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions In-Reply-To: <4zW7XEoxy4YlShEw_Jf6ZPMn1llJ09c6sye_tyvhswU=.f5d74ea1-5026-4812-b9ac-9d21c54a90b2@github.com> References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> <4zW7XEoxy4YlShEw_Jf6ZPMn1llJ09c6sye_tyvhswU=.f5d74ea1-5026-4812-b9ac-9d21c54a90b2@github.com> Message-ID: On Thu, 10 Apr 2025 05:52:17 GMT, Alan Bateman wrote: >> Hi, this is a proposal to fix 8352728. >> >> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following: >> >> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`. >> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`. >> >> #### Windows Case >> >> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf: >> >> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`: >> * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473") >> * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288") >> * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop) >> * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja... > > I don't think this change should be integrated before more investigation. I think start by finding out why this code is using toRealPath. For the two cases listed, it looks like toRealPath is correctly failing for the first, but for /dev/stdin then please bring it to nio-dev to discuss how special devices should be handled by that method. Hi @AlanBateman. > I don't think this change should be integrated before more investigation. Ok, makes sense. > I think start by finding out why this code is using toRealPath. The usage of `Path::toRealPath` was introduced by the [8319332: Security properties files inclusion](https://bugs.openjdk.org/browse/JDK-8319332) proposal for the following reasons: 1. Weak reason: detect cyclic re-inclusion through an alias of the same file (e.g. symlink, or alternative case in case-insensitive filesystems). This would only make cycle detection trigger earlier, but is not strictly necessary (infinite recursion will lead to path repetition even if not normalized). 2. Weak reason: resolve a relative path passed through `-Djava.security.properties=relative.props` against the current working directory (stack: `loadAll`, `loadExtra`, `loadExtraHelper`, `loadExtraFromPath`, `loadFromPath`). This resolution could be done with `Path::toAbsolutePath`, but this case is also subject to the 3?? reason. 3. Strong reason: resolve symlinks, so that properties files use their original path to resolve relative includes. The rationale behind this is that the writer of the original properties file is the one who reasoned where relative includes should resolve to. On the other hand, the writer of the symlink just wants to use the original file with all its includes, without having to replicate anything else. This case is exercised by the _PowerShell_ test on this PR's description. > For the two cases listed, it looks like toRealPath is correctly failing for the first [?] Yes, that was our impression, and that's why we are not proposing any fix to `Path::toRealPath`: there's nothing wrong with failing if normalization is not complete. But `File::getCanonicalPath` takes a best-effort approach that is more suitable to our needs. > [?] but for /dev/stdin then please bring it to nio-dev to discuss how special devices should be handled by that method. I will investigate the _Linux_ case, I had skipped it because `File::getCanonicalPath` looked like the only alternative on _Windows_, while it is also working on _Linux_. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-2792757981 From duke at openjdk.org Thu Apr 10 13:19:05 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 10 Apr 2025 13:19:05 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: > By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: - Code rearrange, some renaming, fixing comments - Changes suggested by Andrew Dinn. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23663/files - new: https://git.openjdk.org/jdk/pull/23663/files/8d5a9e12..74ff3d9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=05-06 Stats: 2139 lines in 4 files changed: 630 ins; 826 del; 683 mod Patch: https://git.openjdk.org/jdk/pull/23663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663 PR: https://git.openjdk.org/jdk/pull/23663 From mullan at openjdk.org Thu Apr 10 13:48:42 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 10 Apr 2025 13:48:42 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v4] In-Reply-To: References: Message-ID: <08IYQWVBN1lmUTRnj-xb_O5m7AFJfz3TlB3rHv1nBX0=.93f962b7-d00d-4620-9995-330a3abc1611@github.com> On Tue, 11 Feb 2025 18:46:29 GMT, Mikhail Yankelevich wrote: >> Refactored the runNameEquals.sh to java test > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor test/jdk/sun/security/krb5/Krb5NameEquals.java line 57: > 55: final GSSManager mgr = GSSManager.getInstance(); > 56: > 57: // Checking if native GSS is installed, throwing skip exception if it's not. Should you be only doing this check if `sun.security.jgss.native` is `true`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r2037421800 From abarashev at openjdk.org Thu Apr 10 13:57:08 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 10 Apr 2025 13:57:08 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled Message-ID: MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: Any endpoint receiving any certificate which it would need to validate using any signature algorithm using an MD5 hash MUST abort the handshake with a "bad_certificate" alert. The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. ------------- Commit messages: - Cosmetic test changes - Optimize imports - A couple of typo fixes - Abort the handshake with a bad_certificate alert on MD5 and SHA1 - Update test run directive. Remove unnecessary comments - Update unit test - Unit test - 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled Changes: https://git.openjdk.org/jdk/pull/24425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350807 Stats: 501 lines in 11 files changed: 426 ins; 42 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From adinn at openjdk.org Thu Apr 10 14:19:46 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 10 Apr 2025 14:19:46 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/register_aarch64.hpp line 510: > 508: > 509: // convenience methods for splitting 8-way of 4-way vector register > 510: // sequences in half -- needed because vector operations can normally typo: 8-way of 4-way -> 8-way or 4-way src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5012: > 5010: assert(!va.is_constant(), "output vector must identify 2 different registers"); > 5011: > 5012: // schedule 2 streams of i instructions src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5167: > 5165: // On each level, we fill up the vector registers in such a way that the > 5166: // array elements that need to be multiplied by the zetas be in one > 5167: // set of vector registers while the corresponding ones that don't need to grammar: by the zetas be in one ... -> by the zetas are in one ... src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5168: > 5166: // array elements that need to be multiplied by the zetas be in one > 5167: // set of vector registers while the corresponding ones that don't need to > 5168: // be multiplied, in another set. We can do 32 Montgomery multiplications grammar: be multiplied, in another set. --> be multiplied are in another set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037529145 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037526649 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037535909 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037537834 From adinn at openjdk.org Thu Apr 10 14:30:39 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 10 Apr 2025 14:30:39 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5278: > 5276: // level 4 > 5277: vs_ldpq(vq, kyberConsts); > 5278: int offsets3[8] = { 0, 32, 64, 96, 128, 160, 192, 224 }; I'd like to add comment here to explain the coefficient grouping and likewise at level 5 and 6. So here we have: // Up to level 3 the coefficients multiplied by or added/subtracted // to the zetas occur in discrete blocks whose size is some multiple // of 32. At level 4 coefficients occur in 8 discrete blocks of size 16 // so they are loaded using employing an ldr at 8 distinct offsets. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037560706 From myankelevich at openjdk.org Thu Apr 10 14:42:23 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 10 Apr 2025 14:42:23 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v4] In-Reply-To: <08IYQWVBN1lmUTRnj-xb_O5m7AFJfz3TlB3rHv1nBX0=.93f962b7-d00d-4620-9995-330a3abc1611@github.com> References: <08IYQWVBN1lmUTRnj-xb_O5m7AFJfz3TlB3rHv1nBX0=.93f962b7-d00d-4620-9995-330a3abc1611@github.com> Message-ID: On Thu, 10 Apr 2025 13:36:01 GMT, Sean Mullan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> minor > > test/jdk/sun/security/krb5/Krb5NameEquals.java line 57: > >> 55: final GSSManager mgr = GSSManager.getInstance(); >> 56: >> 57: // Checking if native GSS is installed, throwing skip exception if it's not. > > Should you be only doing this check if `sun.security.jgss.native` is `true`? Done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r2037582380 From myankelevich at openjdk.org Thu Apr 10 14:42:22 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 10 Apr 2025 14:42:22 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v5] In-Reply-To: References: Message-ID: > Refactored the runNameEquals.sh to java test Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - checking if native GSS now only haoppens with sun.security.jgss.native = true. Improt fix - Merge branch 'master' into JDK-8349534 - minor - reworked - minor cleanup - 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23542/files - new: https://git.openjdk.org/jdk/pull/23542/files/70bb9737..f3e3c55e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23542&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23542&range=03-04 Stats: 221556 lines in 5040 files changed: 100241 ins; 92133 del; 29182 mod Patch: https://git.openjdk.org/jdk/pull/23542.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23542/head:pull/23542 PR: https://git.openjdk.org/jdk/pull/23542 From adinn at openjdk.org Thu Apr 10 14:42:35 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 10 Apr 2025 14:42:35 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: <1-Ncd4d8AXSun31DFTq_Q-GI0zbOW76QB0LXX2iyF38=.46a32e70-f613-43f0-a485-c5113200ed40@github.com> On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5300: > 5298: // level 5 > 5299: vs_ldpq(vq, kyberConsts); > 5300: int offsets4[4] = { 0, 32, 64, 96 }; Again a comment // At level 5 related coefficients occur in discrete blocks of size 8 so // need to be loaded interleaved using an ld2 operation with arrangement 2D src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5319: > 5317: vs_st2_indexed(vs1, __ T2D, coeffs, tmpAddr, 384, offsets4); > 5318: > 5319: // level 6 And again // At level 6 related coefficients occur in discrete blocks of size 4 so // need to be loaded interleaved using an ld2 operation with arrangement 4S src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5377: > 5375: // level 0 > 5376: vs_ldpq(vq, kyberConsts); > 5377: int offsets4[4] = { 0, 32, 64, 96 }; Again a comment // At level 0 related coefficients occur in discrete blocks of size 4 so // need to be loaded interleaved using an ld2 operation with arrangement 4S src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5399: > 5397: vs_st2_indexed(vs1, __ T4S, coeffs, tmpAddr, 384, offsets4); > 5398: > 5399: // level 1 Again a comment // At level 1 related coefficients occur in discrete blocks of size 8 so // need to be loaded interleaved using an ld2 operation with arrangement 2D src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5423: > 5421: > 5422: // level 2 > 5423: int offsets3[8] = { 0, 32, 64, 96, 128, 160, 192, 224 }; Again // At level 2 coefficients occur in 8 discrete blocks of size 16 // so they are loaded using employing an ldr at 8 distinct offsets. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5464: > 5462: vs_str_indexed(vs1, __ Q, coeffs, 256, offsets3); > 5463: > 5464: // level 3 / From level 3 upwards coefficients occur in discrete blocks whose size is // some multiple of 32 so can be loaded using ldpq and suitable indexes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037571231 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037573218 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037577265 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037578385 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037581149 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037585101 From adinn at openjdk.org Thu Apr 10 14:52:33 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 10 Apr 2025 14:52:33 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5590: > 5588: __ add(tmpAddr, coeffs, 0); > 5589: store64shorts(vs2, tmpAddr); > 5590: I'd like to make explicit the fact that we have avoided doing an add here (and in the next two cases) by adding a commented out generation step i.e. at this line insert // __ add(tmpAddr, coeffs, 128); // unneeded as implied by preceding load src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5595: > 5593: __ add(tmpAddr, coeffs, 128); > 5594: store64shorts(vs2, tmpAddr); > 5595: Likewise insert: // __ add(tmpAddr, coeffs, 256); // unneeded as implied by preceding load src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5601: > 5599: store64shorts(vs2, tmpAddr); > 5600: > 5601: load64shorts(vs1, tmpAddr); Likewise insert: // __ add(tmpAddr, coeffs, 384); // unneeded as implied by preceding load ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037607688 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037609104 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037611049 From mullan at openjdk.org Thu Apr 10 15:00:44 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 10 Apr 2025 15:00:44 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v5] In-Reply-To: References: Message-ID: <5cRAKyQXM5S1zXURl7Xdxf7J1M_a9ge4SpcESbtIPww=.59c8a1bc-e268-4cd0-82a9-db43dadd4da1@github.com> On Thu, 10 Apr 2025 14:42:22 GMT, Mikhail Yankelevich wrote: >> Refactored the runNameEquals.sh to java test > > Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - checking if native GSS now only haoppens with sun.security.jgss.native = true. Improt fix > - Merge branch 'master' into JDK-8349534 > - minor > - reworked > - minor cleanup > - 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test Bug needs a `noreg-self` label; otherwise looks good. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23542#pullrequestreview-2757187734 From mullan at openjdk.org Thu Apr 10 15:12:45 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 10 Apr 2025 15:12:45 GMT Subject: RFR: 8353641: Deprecate core library permission classes for removal [v8] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs wrote: >> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission >> >> @Deprecated(forRemoval = true, since="25") >> Is added to each class and the existing @apiNote is converted to @deprected > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions." > SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated. > - Merge branch 'master' into 8353641-deprecate-premission-classes > - Missing suppresswarnings > - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions. > Remove dead code from ForkJoinPool. > Add @SuppressWarnings("remove") > - Remove unnecessary SuppressWarnings and correct Deprecated annotation style > - Update copyright in WindowsFileCopy > - Remove unused import of LinkPermission > - Updated style of @Deprecated to match most existing @Deprecated annotations > `since` comes before `forRemoval` > No spaces around `=` > - Add SuppressWarnings to a Windows source missed earlier. > - 8353641: Deprecate core library permission classes for removal > > Now that the Security Manager is permanently disabled, the following permission classes > in the core libraries area can be deprecated for removal as they are no longer useful: > FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, > RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24444#pullrequestreview-2757226356 From jwaters at openjdk.org Thu Apr 10 15:17:42 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Apr 2025 15:17:42 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v7] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'openjdk:master' into unused > - Neater warning silencer in proc_md.h > - Revert _WIN32 workaround in log_messages.c > - Copyright in VersionInfo.cpp > - Remove neutralLangId in VersionInfo.cpp > - Remove global memHandle, would've liked to keep it as a comment :( > - Merge branch 'master' into unused > - 8342682 Keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2794181603 From duke at openjdk.org Thu Apr 10 15:23:33 2025 From: duke at openjdk.org (duke) Date: Thu, 10 Apr 2025 15:23:33 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v5] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 14:42:22 GMT, Mikhail Yankelevich wrote: >> Refactored the runNameEquals.sh to java test > > Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - checking if native GSS now only haoppens with sun.security.jgss.native = true. Improt fix > - Merge branch 'master' into JDK-8349534 > - minor > - reworked > - minor cleanup > - 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test @myankelev Your change (at version f3e3c55eef1475764c6343ad031f0788dd7cd0d3) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23542#issuecomment-2794211562 From myankelevich at openjdk.org Thu Apr 10 15:33:35 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 10 Apr 2025 15:33:35 GMT Subject: Integrated: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 17:50:21 GMT, Mikhail Yankelevich wrote: > Refactored the runNameEquals.sh to java test This pull request has now been integrated. Changeset: 0e223f14 Author: Mikhail Yankelevich Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/0e223f1456c14efdb423595bee3444d5e26db7c6 Stats: 173 lines in 2 files changed: 18 ins; 137 del; 18 mod 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test Co-authored-by: Weijun Wang Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/23542 From weijun at openjdk.org Thu Apr 10 15:36:55 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 10 Apr 2025 15:36:55 GMT Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms Message-ID: Add 2 `MessageDigest` algorithms. ------------- Commit messages: - the change Changes: https://git.openjdk.org/jdk/pull/24576/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24576&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354305 Stats: 96 lines in 4 files changed: 93 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24576.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24576/head:pull/24576 PR: https://git.openjdk.org/jdk/pull/24576 From adinn at openjdk.org Thu Apr 10 16:17:38 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 10 Apr 2025 16:17:38 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: <8wo-YxVVmMSocSfA7Te4-txUqtv6JQyxktwIGZ_U3z4=.fadb528c-6d39-4733-be37-7c85387cf3da@github.com> On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5933: > 5931: vs_ld3_post(vin, __ T16B, condensed); > 5932: > 5933: // expand groups of input bytes in vin to shorts in va and vb I's like to expand on the data layouts here so that maintenance engineers don't have to work it out every time they look at it. So, I would like to replace this comment as follows // The front half of sequence vin (vin[0], vin[1] and vin[2]) // holds 48 (16x3) contiguous bytes from memory striped // horizontally across each of the 16 byte lanes. Equivalently, // that is 16 pairs of 12-bit integers. Likewise the back half // holds the next 48 bytes in the same arrangement. // Each vector in the front half can also be viewed as a vertical // strip across the 16 pairs of 12 bit integers. Each byte in // vin[0] stores the low 8 bits of the first int in a pair. Each // byte in vin[1] stores the high 4 bits of the first int and the // low 4 bits of the second int. Each byte in vin[2] stores the // high 8 bits of the second int. Likewise the vectors in second // half. // Converting the data to 16-bit shorts requires first of all // expanding each of the 6 x 16B vectors into 6 corresponding // pairs of 8H vectors. Mask, shift and add operations on the // resulting vector pairs can be used to combine 4 and 8 bit // parts of related 8H vector elements. // // The middle vectors (vin[2] and vin[5]) are actually expanded // twice, one copy manipulated to provide the lower 4 bits // belonging to the first short in a pair and another copy // manipulated to provide the higher 4 bits belonging to the // second short in a pair. This is why the the vector sequences va // and vb used to hold the expanded 8H elements are of length 8. // Expand vin[0] into va[0:1], and vin[1] into va[2:3] and va[4:5] src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5941: > 5939: __ ushll(va[4], __ T8H, vin[1], __ T8B, 0); > 5940: __ ushll2(va[5], __ T8H, vin[1], __ T16B, 0); > 5941: Insert here // Likewise expand vin[3] into vb[0:1], and vin[4] into vb[2:3] // and vb[4:5] src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5949: > 5947: __ ushll2(vb[5], __ T8H, vin[4], __ T16B, 0); > 5948: > 5949: // offset duplicated elements in va and vb by 8 To make this clearer it should say // shift lo byte of copy 1 of the middle stripe into the high byte src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5955: > 5953: __ shl(vb[3], __ T8H, vb[3], 8); > 5954: > 5955: // expand remaining input bytes in vin to shorts in va and vb To make this clearer it should say // Expand vin[2] into va[6:7] and vin[5] into vb[6:7] but this // time pre-shifted by 4 to ensure top bits of input 12-bit int // are in bit positions [4..11]. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5962: > 5960: __ ushll2(vb[7], __ T8H, vin[5], __ T16B, 4); > 5961: > 5962: // split the duplicated 8 bit values into two distinct 4 bit To make this clearer it should say // mask hi 4 bits of the 1st 12-bit int in a pair from copy1 and // shift lo 4 bits of the 2nd 12-bit int in a pair to the bottom of // copy2 src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5973: > 5971: __ ushr(vb[5], __ T8H, vb[5], 4); > 5972: > 5973: // sum resulting short values into the front halves of va and This should be replaced to clarify details of the ordering for summing and grouping // sum hi 4 bits and lo 8 bits of the 1st 12-bit int in each pair and // hi 8 bits plus lo 4 bits of the 2nd 12-bit int in each pair // n.b. the ordering ensures: i) inputs are consumed before they // are overwritten ii) the order of 16-bit results across successive // pairs of vectors in va and then vb reflects the order of the // corresponding 12-bit inputs src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5984: > 5982: __ addv(vb[3], __ T8H, vb[5], vb[7]); > 5983: > 5984: // store results interleaved as shorts Change to // store 64 results interleaved as shorts src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5993: > 5991: __ cbz(parsedLength, L_end); > 5992: > 5993: // if anything is left it should be a final 72 bytes. so we Clarify as follows // if anything is left it should be a final 72 bytes of input // i.e. a final 48 12-bit values. so we handle this by loading // load 48 bytes into all 16B lanes of front(vin) and only 24 // bytes into the lower 8B lane of back(vin) src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5999: > 5997: vs_ld3(vs_back(vin), __ T8B, condensed); > 5998: > 5999: // expand groups of input bytes in vin to shorts in va and vb Modify as above // Expand vin[0] into va[0:1], and vin[1] into va[2:3] and va[4:5] src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6009: > 6007: __ ushll2(va[5], __ T8H, vin[1], __ T16B, 0); > 6008: > 6009: __ ushll(vb[0], __ T8H, vin[3], __ T8B, 0); Add a comment // This time expand just the lower 8 lanes src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6013: > 6011: __ ushll(vb[4], __ T8H, vin[4], __ T8B, 0); > 6012: > 6013: // offset duplicated elements in va and vb by 8 As before clarify as follows // shift lo byte of copy 1 of the middle stripe into the high byte src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6018: > 6016: __ shl(vb[2], __ T8H, vb[2], 8); > 6017: > 6018: // expand remaining input bytes in vin to shorts in va and vb Again improve this comment // expand vin[2] into va[6:7] and lower 8 lanes of vin[5] into // vb[6] pre-shifted by 4 to ensure top bits of the input 12-bit // int are in bit positions [4..11]. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6024: > 6022: __ ushll(vb[6], __ T8H, vin[5], __ T8B, 4); > 6023: > 6024: // split the duplicated 8 bit values into two distinct 4 bit Once again update // mask hi 4 bits of each 1st 12-bit int in pair from copy1 and // shift lo 4 bits of each 2nd 12-bit int in pair to bottom of // copy2 src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6033: > 6031: __ ushr(vb[4], __ T8H, vb[4], 4); > 6032: > 6033: // sum resulting short values into the front halves of va and Again update to provide more detail // sum hi 4 bits and lo 8 bits of each 1st 12-bit int in pair and // hi 8 bits plus lo 4 bits of each 2nd 12-bit int in pair // n.b. ordering ensures: i) inputs are consumed before they are // overwritten ii) order of 16-bit results across succsessive // pairs of vectors in va and then lower half of vb reflects order // of corresponding 12-bit inputs src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6042: > 6040: __ addv(vb[1], __ T8H, vb[4], vb[6]); > 6041: > 6042: // store results interleaved as shorts Change to // store 48 results interleaved as shorts ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037755555 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037758589 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037760493 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037762375 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037764723 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037767700 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037783970 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037771521 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037769694 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037774404 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037776668 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037779831 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037780704 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037781617 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2037782757 From adinn at openjdk.org Thu Apr 10 16:53:32 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 10 Apr 2025 16:53:32 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com> On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. @ferakocz Hi Ferenc. Thank you for adjusting the code as requested and even more so for the extra clean-ups you added which I very much appreciate. I have added suggestions for some extra/modified commenting to clarify certain details of what is being generated that were not 100% clear to me when I first read/restructured the code. They may seem a bit obvious but I want to ensure that any maintainer who needs to review the code can assimilate it quickly (including me if/when I revisit it in 12 months time). Mostly my recommendations for upgrading of comments is complete and I believe little more will be needed to sign off this PR. However, I still want to check through a few parts of the code that I have not fully cross-checked against the Java routines (e.g. the Barrett reductions). I'll try to do that asap but it will probably be a few days from now. Thanks again for your help in improving this code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2794514677 From jlu at openjdk.org Thu Apr 10 18:47:53 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 10 Apr 2025 18:47:53 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v2] In-Reply-To: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com> References: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com> Message-ID: <9aQcWun5KNgHgELVwkc3478_RtqfhRL1Cxvyn2Yl0Nw=.07ee596f-e738-4796-8d27-14621ed8860c@github.com> On Thu, 10 Apr 2025 08:44:28 GMT, Eirik Bj?rsn?s wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace InputStreamReader with BufferedReader > > FWIW, I checked out the revision of the commit previous to this change and found the following: > > > % git checkout b55e418a077791b39992042411cde97f68dc39fe^ > % find src -name "*.properties" | xargs file | grep -v ASCII > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: > ISO-8859 text > src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties: > Unicode text, UTF-8 text, with very long lines (322) > > > Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky. This conversion was performed under the assumption of ASCII set and Unicode escape sequences, which is the format we expect for the translation process for .properties files. That file should have been omitted from this change. Thank you @eirbjo and @magicus for the analysis and checking! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2794828598 From rriggs at openjdk.org Thu Apr 10 19:22:40 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 10 Apr 2025 19:22:40 GMT Subject: Integrated: 8353641: Deprecate core library permission classes for removal In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs wrote: > Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission > > @Deprecated(forRemoval = true, since="25") > Is added to each class and the existing @apiNote is converted to @deprected This pull request has now been integrated. Changeset: af5db513 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/af5db513060db5f89c071f531e6111c69fcd7370 Stats: 54 lines in 17 files changed: 26 ins; 8 del; 20 mod 8353641: Deprecate core library permission classes for removal Reviewed-by: mullan, iris ------------- PR: https://git.openjdk.org/jdk/pull/24444 From valeriep at openjdk.org Thu Apr 10 21:04:43 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Apr 2025 21:04:43 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v2] In-Reply-To: References: <8UNuDQR_eQ2zm91c6_AUgT7pZEqbOx6kLmtyjZXgnxk=.e0280c9e-f2a1-49f6-9d1d-e5235638b522@github.com> Message-ID: <-xV7BmRtbbkvn1RfphLKSPQUIrastr7hOam1YzdY5hg=.4af3949a-84b0-485c-add8-9f9245cadeb6@github.com> On Fri, 4 Apr 2025 23:05:01 GMT, Bradford Wetmore wrote: >> Yes, I am on the fence about this. Given the specified value is the same as the default, it can be removed. I kept it there so the new code matches the original code completely. Not much difference either way I think. > > I like having it there to communicate that is really the intent. Ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2038333871 From valeriep at openjdk.org Thu Apr 10 21:19:37 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Apr 2025 21:19:37 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v2] In-Reply-To: <-1PpZbXygm5SvzP34-MPe60Uz9K6aCNAF3cMkycYGIM=.d900c690-2c81-4110-8998-eab276730ec4@github.com> References: <-1PpZbXygm5SvzP34-MPe60Uz9K6aCNAF3cMkycYGIM=.d900c690-2c81-4110-8998-eab276730ec4@github.com> Message-ID: On Mon, 7 Apr 2025 18:48:15 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/ssl/Utilities.java line 150: >> >>> 148: String sanitizedAlg = digestAlg.replace("-", ""); >>> 149: return switch (sanitizedAlg) { >>> 150: case "SHA256", "SHA384", "SHA512" -> "HKDF-" + sanitizedAlg; >> >> This is a nit, but currently we don't have SHA512 in `CipherSuite.HashAlg`. You can leave it for any future enhancements. > > You could also consider storing the HKDF algorithm names in the `HashAlg` enum. Not sure if it would make much difference, performance wise. Yes, this sounds better for overall consistency. Will adopt the `HashAlg` enum suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2038350409 From michaelm at openjdk.org Thu Apr 10 21:26:21 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 10 Apr 2025 21:26:21 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: update to minimise code changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23929/files - new: https://git.openjdk.org/jdk/pull/23929/files/f5501d18..c41146b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=03-04 Stats: 208 lines in 26 files changed: 16 ins; 61 del; 131 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From michaelm at openjdk.org Thu Apr 10 21:31:31 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 10 Apr 2025 21:31:31 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > update to minimise code changes I've just updated the PR with a change that replaces the new methods of the form `throwException()` with the previous pattern of the form `throw new XException`. This reduces the code changes a bit further and is more readable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2795207656 From valeriep at openjdk.org Thu Apr 10 21:50:28 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Apr 2025 21:50:28 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v2] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 16:42:14 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> added default deriveData method to SSLKeyDerivation interface and >> refactored code to remove unused AlgorithmParameterSpec argument. > > src/java.base/share/classes/sun/security/ssl/RSAKeyExchange.java line 295: > >> 293: >> 294: @Override >> 295: public SecretKey deriveKey(String type) throws IOException { > > How about changing the variable name to `typeNotUsed` like `SSLKeyDerivation.LegacyMasterKeyDerivation`? Yes, missed this one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2038386660 From valeriep at openjdk.org Thu Apr 10 22:15:27 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 10 Apr 2025 22:15:27 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v2] In-Reply-To: References: Message-ID: <6J1Tv8x9-HQeZv23mOF3q5U7NnqeTsKz4rRGJtoXE60=.a7c8470a-9f77-44cb-bcc3-4beccfe0db22@github.com> On Mon, 7 Apr 2025 16:44:58 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> added default deriveData method to SSLKeyDerivation interface and >> refactored code to remove unused AlgorithmParameterSpec argument. > > src/java.base/share/classes/sun/security/ssl/SSLKeyDerivation.java line 35: > >> 33: SecretKey deriveKey(String purpose) throws IOException; >> 34: >> 35: default byte[] deriveData(String purpose) throws IOException { > > This is an internal interface, so I don't think you need to make this a `default` method. I didn't add `deriveData(String)` impl to all the existing impls of `SSLKeyDerivation`. Only impls used for deriving IVs are updated to add impl for `deriveData(String)`, so the `default` method is necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2038421803 From mbalao at openjdk.org Thu Apr 10 23:54:03 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 10 Apr 2025 23:54:03 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- Martin Balao has updated the pull request incrementally with two additional commits since the last revision: - Algorithm and key size checking before derivation. Mechanism normalization for TLS. - Minor import adjustment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24526/files - new: https://git.openjdk.org/jdk/pull/24526/files/848dd1e1..8feb31ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=00-01 Stats: 145 lines in 4 files changed: 80 ins; 24 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/24526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24526/head:pull/24526 PR: https://git.openjdk.org/jdk/pull/24526 From mbalao at openjdk.org Thu Apr 10 23:56:26 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 10 Apr 2025 23:56:26 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: <5f9zq1-OIOaRqnOkzVBrf3ti7LqV-GeONSgm_GQcDu0=.5002fab1-e740-49c5-8670-3517e400d25d@github.com> On Thu, 10 Apr 2025 03:27:19 GMT, Valerie Peng wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > On a related note, I am working on https://github.com/openjdk/jdk/pull/24393 and noticed that JSSE calls HKDF.deriveKey(...) with various names such as "TlsFinishedSecret", "TlsResumptionMasterSecret" as the key algorithm. This causes errors when using PKCS11 HKDF since the `P11SecretKeyFactory.getKeyInfo()` look up returns `null` and leads to `InvalidAlgorithmParameterException`. I am debating whether to do the special handling as below: > > > P11SecretKeyFactory.KeyInfo ki = P11SecretKeyFactory.getKeyInfo(alg); > if (ki == null) { > - throw new InvalidAlgorithmParameterException("A PKCS #11 key " + > - "type (CKK_*) was not found for a key of the algorithm '" + > - alg + "'."); > + // special handling for TLS > + if (alg.startsWith("Tls")) { > + ki = P11SecretKeyFactory.getKeyInfo("Generic"); > + } else { > + throw new InvalidAlgorithmParameterException("A PKCS #11 key " + > + "type (CKK_*) was not found for a key of the algorithm '" + > + alg + "'."); > + } > > > Comments or suggestions? @martinuy @valeriepeng @djelinski @franferrax can you please take a look at this new proposal? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2795432401 From mbalao at openjdk.org Fri Apr 11 00:03:25 2025 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 11 Apr 2025 00:03:25 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 10 Apr 2025 23:54:03 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - Algorithm and key size checking before derivation. Mechanism normalization for TLS. > - Minor import adjustment. What I have found with Tls* keys is that they are in the map but we need to translate their pseudo-mechanism to a valid one (`CKK_GENERIC_SECRET`). Is that enough for #24393? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2795454937 From valeriep at openjdk.org Fri Apr 11 01:45:11 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 11 Apr 2025 01:45:11 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v3] In-Reply-To: References: Message-ID: > This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. > > This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. > > Thanks in advance for the review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: address review feedbacks cleanup interim security values changed PKCS11 HKDF impl to allow key algorithms starting with "Tls" as generic keys ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24393/files - new: https://git.openjdk.org/jdk/pull/24393/files/320c49aa..eaa0737e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=01-02 Stats: 216 lines in 14 files changed: 115 ins; 27 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/24393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24393/head:pull/24393 PR: https://git.openjdk.org/jdk/pull/24393 From djelinski at openjdk.org Fri Apr 11 08:16:43 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Apr 2025 08:16:43 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 10 Apr 2025 23:54:03 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - Algorithm and key size checking before derivation. Mechanism normalization for TLS. > - Minor import adjustment. LGTM. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24526#pullrequestreview-2759517717 From dfuchs at openjdk.org Fri Apr 11 09:06:28 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 09:06:28 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal Message-ID: Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. ------------- Commit messages: - 8353642: Deprecate networking permission classes for removal Changes: https://git.openjdk.org/jdk/pull/24592/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353642 Stats: 58 lines in 12 files changed: 36 ins; 4 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/24592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592 PR: https://git.openjdk.org/jdk/pull/24592 From dfuchs at openjdk.org Fri Apr 11 10:01:26 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 10:01:26 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 09:00:05 GMT, Daniel Fuchs wrote: > Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. The CSR is also ready to be reviewed at [https://bugs.openjdk.org/browse/JDK-8354406](https://bugs.openjdk.org/browse/JDK-8354406) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796425675 From dfuchs at openjdk.org Fri Apr 11 10:01:26 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 10:01:26 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: > Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Missing white spaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24592/files - new: https://git.openjdk.org/jdk/pull/24592/files/e9dc4146..9b371b3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592 PR: https://git.openjdk.org/jdk/pull/24592 From djelinski at openjdk.org Fri Apr 11 11:00:26 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Apr 2025 11:00:26 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 10:01:26 GMT, Daniel Fuchs wrote: >> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Missing white spaces src/java.base/share/classes/java/net/HttpURLConnection.java line 617: > 615: * {@link java.security.AllPermission}. > 616: */ > 617: @Deprecated(since = "25") can this (and all other getPermission methods) be "forRemoval=true"? src/java.base/share/classes/java/security/CodeSource.java line 468: > 466: } > 467: @SuppressWarnings("removal") > 468: var result = this.sp.implies(that.sp); Will we need to rewrite this code without SocketPermissions? Can we remove it, maybe? It is only used by CodeSource.implies, which is not used by the JDK (but may be used elsewhere). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039291810 PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039304662 From djelinski at openjdk.org Fri Apr 11 11:12:40 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Apr 2025 11:12:40 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 10:55:10 GMT, Daniel Jeli?ski wrote: >> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing white spaces > > src/java.base/share/classes/java/security/CodeSource.java line 468: > >> 466: } >> 467: @SuppressWarnings("removal") >> 468: var result = this.sp.implies(that.sp); > > Will we need to rewrite this code without SocketPermissions? Can we remove it, maybe? It is only used by CodeSource.implies, which is not used by the JDK (but may be used elsewhere). also the JavaDoc of the implies method references the SocketPermission. That will also need to be cleaned up at some point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039324745 From djelinski at openjdk.org Fri Apr 11 11:19:27 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Apr 2025 11:19:27 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 10:01:26 GMT, Daniel Fuchs wrote: >> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Missing white spaces src/java.base/share/classes/java/net/SocketPermission.java line 1311: > 1309: > 1310: @SuppressWarnings("removal") > 1311: @Deprecated(since = "25", forRemoval = true) this class is internal, no need to deprecate ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039335050 From dfuchs at openjdk.org Fri Apr 11 11:34:32 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 11:34:32 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 10:45:20 GMT, Daniel Jeli?ski wrote: >> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing white spaces > > src/java.base/share/classes/java/net/HttpURLConnection.java line 617: > >> 615: * {@link java.security.AllPermission}. >> 616: */ >> 617: @Deprecated(since = "25") > > can this (and all other getPermission methods) be "forRemoval=true"? Possibly. @AlanBateman may have some thoughts on this. > src/java.base/share/classes/java/net/SocketPermission.java line 1311: > >> 1309: >> 1310: @SuppressWarnings("removal") >> 1311: @Deprecated(since = "25", forRemoval = true) > > this class is internal, no need to deprecate It helps getting warnings at the place where the class is used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039358351 PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039360730 From dfuchs at openjdk.org Fri Apr 11 11:34:33 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 11:34:33 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: <_lrzJTVqcfATXdXToFeL69PLIu9LRQ37BFmmlFYvTWQ=.8e3a7e15-e5a5-45dc-b0d1-362950b51939@github.com> On Fri, 11 Apr 2025 11:10:10 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/java/security/CodeSource.java line 468: >> >>> 466: } >>> 467: @SuppressWarnings("removal") >>> 468: var result = this.sp.implies(that.sp); >> >> Will we need to rewrite this code without SocketPermissions? Can we remove it, maybe? It is only used by CodeSource.implies, which is not used by the JDK (but may be used elsewhere). > > also the JavaDoc of the implies method references the SocketPermission. That will also need to be cleaned up at some point. That will be left over for someone in security-libs to cleanup this code at their convenience before we remove SocketException. Hmmm... If the public API references SocketException we might have to deprecate in this PR too. Not sure what the implications are. Maybe @seanjmullan can advise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039353439 From alanb at openjdk.org Fri Apr 11 11:37:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 11 Apr 2025 11:37:36 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 11:30:54 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/net/HttpURLConnection.java line 617: >> >>> 615: * {@link java.security.AllPermission}. >>> 616: */ >>> 617: @Deprecated(since = "25") >> >> can this (and all other getPermission methods) be "forRemoval=true"? > > Possibly. @AlanBateman may have some thoughts on this. I think we should at least consider deprecating URLConnection.getPermission and HttpURLConnection.getPermission for removal, only because I don't immediately see the advantage of doing it in two steps for these two APIs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039366899 From dfuchs at openjdk.org Fri Apr 11 11:50:24 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 11:50:24 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 11:34:36 GMT, Alan Bateman wrote: >> Possibly. @AlanBateman may have some thoughts on this. > > I think we should at least consider deprecating URLConnection.getPermission and HttpURLConnection.getPermission for removal, only because I don't immediately see the advantage of doing it in two steps for these two APIs. Thanks - I will do that then ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039391997 From djelinski at openjdk.org Fri Apr 11 12:04:24 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Apr 2025 12:04:24 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 10:01:26 GMT, Daniel Fuchs wrote: >> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Missing white spaces The GHA failure (Windows) appears to be related. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796715234 From dfuchs at openjdk.org Fri Apr 11 12:33:25 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 12:33:25 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 12:01:52 GMT, Daniel Jeli?ski wrote: > The GHA failure (Windows) appears to be related. Yes - I missed one windows specific file in my original patch. I have a test running in the CI and I am waiting for it to pass before updating the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796783392 From michaelm at openjdk.org Fri Apr 11 13:49:27 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 11 Apr 2025 13:49:27 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 10:01:26 GMT, Daniel Fuchs wrote: >> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Missing white spaces src/java.base/share/classes/java/security/CodeSource.java line 461: > 459: if (this.sp == null) { > 460: @SuppressWarnings("removal") > 461: var _ = this.sp = new SocketPermission(thisHost, "resolve"); What's the reason for the `var _ =` bit ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039598335 From dfuchs at openjdk.org Fri Apr 11 13:56:18 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 13:56:18 GMT Subject: RFR: 8353642: Deprecate networking permission classes for removal [v3] In-Reply-To: References: Message-ID: > Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Review feedback. Deprecate getPermission for removal. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24592/files - new: https://git.openjdk.org/jdk/pull/24592/files/9b371b3a..d47a31d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=01-02 Stats: 22 lines in 7 files changed: 5 ins; 7 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/24592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592 PR: https://git.openjdk.org/jdk/pull/24592 From dfuchs at openjdk.org Fri Apr 11 14:00:33 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 14:00:33 GMT Subject: RFR: 8353642: Deprecate URL::getPermission method and networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 11:47:21 GMT, Daniel Fuchs wrote: >> I think we should at least consider deprecating URLConnection.getPermission and HttpURLConnection.getPermission for removal, only because I don't immediately see the advantage of doing it in two steps for these two APIs. > > Thanks - I will do that then Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039614980 From dfuchs at openjdk.org Fri Apr 11 14:00:32 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 14:00:32 GMT Subject: RFR: 8353642: Deprecate URL::getPermission method and networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 12:31:04 GMT, Daniel Fuchs wrote: > The GHA failure (Windows) appears to be related. Should be fixed now ------------- PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796995066 From dfuchs at openjdk.org Fri Apr 11 14:00:34 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Apr 2025 14:00:34 GMT Subject: RFR: 8353642: Deprecate URL::getPermission method and networking permission classes for removal [v2] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 13:47:10 GMT, Michael McMahon wrote: >> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing white spaces > > src/java.base/share/classes/java/security/CodeSource.java line 461: > >> 459: if (this.sp == null) { >> 460: @SuppressWarnings("removal") >> 461: var _ = this.sp = new SocketPermission(thisHost, "resolve"); > > What's the reason for the `var _ =` bit ? `@SuppressWarnings` can not be applied to a an expression - it needs a (variable/method/class) declaration ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039613130 From michaelm at openjdk.org Fri Apr 11 14:58:29 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 11 Apr 2025 14:58:29 GMT Subject: RFR: 8353642: Deprecate URL::getPermission method and networking permission classes for removal [v3] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 13:56:18 GMT, Daniel Fuchs wrote: >> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback. Deprecate getPermission for removal. Looks fine to me. ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2760620879 From djelinski at openjdk.org Fri Apr 11 15:50:43 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Apr 2025 15:50:43 GMT Subject: RFR: 8353642: Deprecate URL::getPermission method and networking permission classes for removal [v3] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 13:56:18 GMT, Daniel Fuchs wrote: >> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback. Deprecate getPermission for removal. LGTM. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2760802017 From abarashev at openjdk.org Fri Apr 11 16:09:08 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 11 Apr 2025 16:09:08 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v2] In-Reply-To: References: Message-ID: > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Merge branch 'master' into JDK-8350807 - Cosmetic test changes - Optimize imports - A couple of typo fixes - Abort the handshake with a bad_certificate alert on MD5 and SHA1 - Update test run directive. Remove unnecessary comments - Update unit test - Unit test - 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/28f12786..134a3264 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=00-01 Stats: 58077 lines in 1239 files changed: 32407 ins; 21258 del; 4412 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From mullan at openjdk.org Fri Apr 11 16:52:30 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 11 Apr 2025 16:52:30 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v14] In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 20:35:29 GMT, Weijun Wang wrote: >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >> ![hpke](https://github.com/user-attachments/assets/4edc5d08-ef52-44c5-b5d5-e8890c2d2fce) > > Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: > > - put encapsulation in params from getParameters > - receiver must specify all algorithm identifiers src/java.base/share/classes/com/sun/crypto/provider/HPKEParameters.java line 88: > 86: @Override > 87: protected String engineToString() { > 88: return "HPKE"; Should you also return what is in the `HPKEParameterSpec`? I think that would be more compliant with the method description. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2039923948 From valeriep at openjdk.org Fri Apr 11 19:50:26 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 11 Apr 2025 19:50:26 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: <0ueeteWqxlhiEC6JBY238zM2-63_O56xay9MlF1QFJg=.27ec81a6-e06a-44fb-b628-c372387e8ba2@github.com> On Fri, 11 Apr 2025 00:00:39 GMT, Martin Balao wrote: > What I have found with Tls* keys is that they are in the map but we need to translate their pseudo-mechanism to a valid one (`CKK_GENERIC_SECRET`). Is that enough for #24393? What I found is that there are more "TlsXXX" than those defined in P11SecretKeyFactory class which are mapped to PCKK_xxx. So, we will need to decide if those self-defined "TlsXXX" algorithms are allowed (e.g. PKCS11 will treat them as Generic secret keys or changing the TLS code to use a key algorithm recognized by PKCS11). Beside this, we need to make sure the current pseudo key type works, e.g. translating to a valid key type when necessary, as you stated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2797888313 From mullan at openjdk.org Fri Apr 11 20:38:41 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 11 Apr 2025 20:38:41 GMT Subject: RFR: 8354449: Remove com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties Message-ID: Workaround for `sed` issue on MacOS 15.4. See https://bugs.openjdk.org/browse/JDK-8353948 for more details. This is a leftover resource file from long ago which serves no purpose, and has been removed in the next Apache release: https://issues.apache.org/jira/browse/SANTUARIO-624 Running through mach 5 tiers 1 and 2 to be safe, so probably won't integrate until Monday. ------------- Commit messages: - Remove com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties Changes: https://git.openjdk.org/jdk/pull/24601/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24601&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354449 Stats: 199 lines in 1 file changed: 0 ins; 199 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24601.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24601/head:pull/24601 PR: https://git.openjdk.org/jdk/pull/24601 From weijun at openjdk.org Fri Apr 11 20:41:13 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 11 Apr 2025 20:41:13 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v15] In-Reply-To: References: Message-ID: > Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. > ![hpke](https://github.com/user-attachments/assets/4edc5d08-ef52-44c5-b5d5-e8890c2d2fce) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: toString, exportData, spec in HPKEParameters must have algorithm identifiers specified ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18411/files - new: https://git.openjdk.org/jdk/pull/18411/files/0796a423..17dceaa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=13-14 Stats: 78 lines in 4 files changed: 68 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/18411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 PR: https://git.openjdk.org/jdk/pull/18411 From weijun at openjdk.org Fri Apr 11 20:53:26 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 11 Apr 2025 20:53:26 GMT Subject: RFR: 8354449: Remove com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 20:34:39 GMT, Sean Mullan wrote: > Workaround for `sed` issue on MacOS 15.4. See https://bugs.openjdk.org/browse/JDK-8353948 for more details. > > This is a leftover resource file from long ago which serves no purpose, and has been removed in the next Apache release: https://issues.apache.org/jira/browse/SANTUARIO-624 > > Running through mach 5 tiers 1 and 2 to be safe, so probably won't integrate until Monday. Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24601#pullrequestreview-2761545922 From rriggs at openjdk.org Fri Apr 11 21:30:36 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 11 Apr 2025 21:30:36 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess Message-ID: The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. The remaining support will be removed when FilePermission is removed. ------------- Commit messages: - 8354053: Remove unused JavaIOFilePermissionAccess Changes: https://git.openjdk.org/jdk/pull/24603/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24603&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354053 Stats: 262 lines in 5 files changed: 59 ins; 176 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/24603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24603/head:pull/24603 PR: https://git.openjdk.org/jdk/pull/24603 From valeriep at openjdk.org Fri Apr 11 21:31:31 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 11 Apr 2025 21:31:31 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 10 Apr 2025 23:54:03 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - Algorithm and key size checking before derivation. Mechanism normalization for TLS. > - Minor import adjustment. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 246: > 244: alg.equalsIgnoreCase("Generic")) { > 245: return ki.keyType; > 246: } What is this check for? It's not immediately clear to me why do we look up the keyInfo using `alg` but then again to check to error out when the found keyType is CKK_GENERIC_SECRET && alg not equals "Generic". This seems to directly contradicts the special workaround for "TlsXXX" in my other PR? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2040315149 From valeriep at openjdk.org Fri Apr 11 21:35:29 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 11 Apr 2025 21:35:29 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 10 Apr 2025 23:54:03 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - Algorithm and key size checking before derivation. Mechanism normalization for TLS. > - Minor import adjustment. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 251: > 249: (int) PCKK_TLSMASTER -> { > 250: return CKK_GENERIC_SECRET; > 251: } It's easier to troubleshoot to add a default case and not let it fall through to the exception on line 253? It's possible that P11SecretKeyFactory is enhanced with more KeyInfo, but the newly added keyType is not added here. Lumping different causes into the same exception may be harder to debug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2040321172 From valeriep at openjdk.org Fri Apr 11 23:16:38 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 11 Apr 2025 23:16:38 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes [v2] In-Reply-To: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> References: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> Message-ID: On Sat, 5 Apr 2025 01:30:49 GMT, Shaojin Wen wrote: >> During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10 anonymous classes, which slows down the startup. This PR is to improve KnownOIDs and eliminate unnecessary embedded classes. >> >> >> Here's how to reproduce this: >> >> >> public class Startup { >> public static void main(String[] args) {} >> } >> >> >> >> java -verbose:class Startup >> >> >> >> [0.665s][info][class,load] sun.security.util.KnownOIDs >> [0.666s][info][class,load] sun.security.util.KnownOIDs$1 >> [0.667s][info][class,load] sun.security.util.KnownOIDs$2 >> [0.667s][info][class,load] sun.security.util.KnownOIDs$3 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$4 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$5 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$6 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$7 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$8 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$9 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$10 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @valeriepeng Looks fine. ------------- PR Review: https://git.openjdk.org/jdk/pull/23411#pullrequestreview-2761762064 From mbalao at openjdk.org Fri Apr 11 23:38:26 2025 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 11 Apr 2025 23:38:26 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Fri, 11 Apr 2025 21:28:30 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Algorithm and key size checking before derivation. Mechanism normalization for TLS. >> - Minor import adjustment. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 246: > >> 244: alg.equalsIgnoreCase("Generic")) { >> 245: return ki.keyType; >> 246: } > > What is this check for? It's not immediately clear to me why do we look up the keyInfo using `alg` but then again to check to error out when the found keyType is CKK_GENERIC_SECRET && alg not equals "Generic". This seems to directly contradicts the special workaround for "TlsXXX" in my other PR? For the TlsXXX issue I check the pseudo-mechanism. That works if all algorithms are known to the map. I'll check how many we have and see what are the pros/cons of having them in the map. I prefer symmetric key algorithms to be in the map. The reason for the check you referred is to block deriving keys such as HmacSHA256, PBEWithHmacSHA224AndAES_256, etc. which are not the result of HKDF derivations, but of Mac and PBE derivation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2040428987 From mbalao at openjdk.org Fri Apr 11 23:49:31 2025 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 11 Apr 2025 23:49:31 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: <0ueeteWqxlhiEC6JBY238zM2-63_O56xay9MlF1QFJg=.27ec81a6-e06a-44fb-b628-c372387e8ba2@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <0ueeteWqxlhiEC6JBY238zM2-63_O56xay9MlF1QFJg=.27ec81a6-e06a-44fb-b628-c372387e8ba2@github.com> Message-ID: On Fri, 11 Apr 2025 19:47:38 GMT, Valerie Peng wrote: > > What I have found with Tls* keys is that they are in the map but we need to translate their pseudo-mechanism to a valid one (`CKK_GENERIC_SECRET`). Is that enough for #24393? > > What I found is that there are more "TlsXXX" than those defined in P11SecretKeyFactory class which are mapped to PCKK_xxx. So, we will need to decide if those self-defined "TlsXXX" algorithms are allowed (e.g. PKCS11 will treat them as Generic secret keys or changing the TLS code to use a key algorithm recognized by PKCS11). Beside this, we need to make sure the current pseudo key type works, e.g. translating to a valid key type when necessary, as you stated. Good, let me check this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2798225287 From mbalao at openjdk.org Fri Apr 11 23:49:32 2025 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 11 Apr 2025 23:49:32 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Fri, 11 Apr 2025 21:32:47 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Algorithm and key size checking before derivation. Mechanism normalization for TLS. >> - Minor import adjustment. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 251: > >> 249: (int) PCKK_TLSMASTER -> { >> 250: return CKK_GENERIC_SECRET; >> 251: } > > It's easier to troubleshoot to add a default case and not let it fall through to the exception on line 253? It's possible that P11SecretKeyFactory is enhanced with more KeyInfo, but the newly added keyType is not added here. Lumping different causes into the same exception may be harder to debug. The exception informs the algorithm, and we know that the algorithm was found in the map because, otherwise, we would have not been able to get the `KeyInfo ki` received by parameter. I can add two separate exceptions if you want, but should not make much of a difference because the reason for the exception is the same: the algorithm is not valid for derivation, regardless if its underlying mechanism is CKK_GENERIC_SECRET or something else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2040431816 From duke at openjdk.org Sat Apr 12 00:42:40 2025 From: duke at openjdk.org (duke) Date: Sat, 12 Apr 2025 00:42:40 GMT Subject: Withdrawn: 8350134: Support DHKEM with PKCS11 In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 21:24:37 GMT, Weijun Wang wrote: > This code change adds supports for getting public key from an EC private key and slicing a secret key in PKCS #11. These are necessary to support DHKEM for keys in SunPKCS11. The first support is still not complete and there is no way to get the public key if the private key is unwrapped from an encrypted form. PKCS #11 3.0 defined CKA_PUBLIC_KEY_INFO but I haven't yet found a library supporting it. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23651 From liach at openjdk.org Sun Apr 13 10:10:32 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 13 Apr 2025 10:10:32 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs wrote: > The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. > The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. > Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. > The remaining support will be removed when FilePermission is removed. src/java.base/share/classes/java/io/FilePermission.java line 254: > 252: > 253: // Construct a new Permission with altPath > 254: // Package private for use by test FilePermissionCollectionMerge That test is already calling with reflection and +open, we can just make this private and non-static. The last use of the original methods were removed when AccessControlContext was functionally removed. If security developers can check, maybe we can just remove these methods completely? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24603#discussion_r2041089794 From alanb at openjdk.org Sun Apr 13 17:53:31 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 13 Apr 2025 17:53:31 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess In-Reply-To: References: Message-ID: <8FEWzCYGGAof4_zU-rvI8YQViNAHnjS6ZEC9_o_r0jU=.104f0aa0-10c5-42b4-81c5-16ca577d55f6@github.com> On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs wrote: > The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. > The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. > Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. > The remaining support will be removed when FilePermission is removed. @wangweij Is there any reason to keep the system property jdk.io.permissionsUseCanonicalPath ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2800051496 From weijun at openjdk.org Sun Apr 13 20:04:31 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sun, 13 Apr 2025 20:04:31 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs wrote: > The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. > The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. > Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. > The remaining support will be removed when FilePermission is removed. I remember the implies method of the file permission class depends on whether this system property is set. Although file permission is no longer used in access control check the class and the method is still there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2800101409 From alanb at openjdk.org Mon Apr 14 12:50:43 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 14 Apr 2025 12:50:43 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess In-Reply-To: References: Message-ID: On Sun, 13 Apr 2025 20:01:28 GMT, Weijun Wang wrote: > I remember the implies method of the file permission class depends on whether this system property is set. Although file permission is no longer used in access control check the class and the method are still there. Right, and I wasn't suggesting we remove implies(FilePermission), instead I'm wondering if the compatibility knob and the implNote can be removed. As you know, it dates from the change to FilePermission in JDK 9 to do simple path matching rather than canonicalization. In any case, I don't want to complicate Roger's cleanup, I'm just noting that it's doing cleanup on a compatibility property that we should have removed a few releases/years ago. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2800552748 From duke at openjdk.org Mon Apr 14 12:54:31 2025 From: duke at openjdk.org (Nibedita Jena) Date: Mon, 14 Apr 2025 12:54:31 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v3] In-Reply-To: References: Message-ID: > Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). > While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. > > Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. > According to RFC 3546, the host_name limit allowed is 255. > With a sample testcase when the host_name length is > 127, exception is thrown: > javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 > javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( > "throwable" : { > java.lang.NegativeArraySizeException: -1 > at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) > at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) > > e.g. > int l = buf.get(); > b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 > > For TLSv1.3, its not an issue until length > 255. > > According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. > Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: Updated SSLSessionImpl constructor with Record interface methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24535/files - new: https://git.openjdk.org/jdk/pull/24535/files/46d4a6e0..9e0e0bc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24535&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24535&range=01-02 Stats: 127 lines in 3 files changed: 14 ins; 72 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/24535.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24535/head:pull/24535 PR: https://git.openjdk.org/jdk/pull/24535 From djelinski at openjdk.org Mon Apr 14 12:54:35 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 14 Apr 2025 12:54:35 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v3] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 12:11:22 GMT, Nibedita Jena wrote: >> Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). >> While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. >> >> Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. >> According to RFC 3546, the host_name limit allowed is 255. >> With a sample testcase when the host_name length is > 127, exception is thrown: >> javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 >> javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( >> "throwable" : { >> java.lang.NegativeArraySizeException: -1 >> at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) >> at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) >> >> e.g. >> int l = buf.get(); >> b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 >> >> For TLSv1.3, its not an issue until length > 255. >> >> According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. >> Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. > > Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: > > Updated SSLSessionImpl constructor with Record interface methods Nice. Here's a +1 from me, but please wait for the usual reviewers. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24535#pullrequestreview-2764127508 From duke at openjdk.org Mon Apr 14 12:57:18 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 14 Apr 2025 12:57:18 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v8] In-Reply-To: References: Message-ID: > By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Clarified comments as suggested by Andrew Dinn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23663/files - new: https://git.openjdk.org/jdk/pull/23663/files/74ff3d9f..d7f7fc8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=06-07 Stats: 134 lines in 3 files changed: 96 ins; 4 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/23663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663 PR: https://git.openjdk.org/jdk/pull/23663 From duke at openjdk.org Mon Apr 14 12:57:35 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 14 Apr 2025 12:57:35 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com> References: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com> Message-ID: <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com> On Thu, 10 Apr 2025 16:50:29 GMT, Andrew Dinn wrote: >> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: >> >> - Code rearrange, some renaming, fixing comments >> - Changes suggested by Andrew Dinn. > > @ferakocz Hi Ferenc. Thank you for adjusting the code as requested and even more so for the extra clean-ups you added which I very much appreciate. > > I have added suggestions for some extra/modified commenting to clarify certain details of what is being generated that were not 100% clear to me when I first read/restructured the code. They may seem a bit obvious but I want to ensure that any maintainer who needs to review the code can assimilate it quickly (including me if/when I revisit it in 12 months time). > > Mostly my recommendations for upgrading of comments is complete and I believe little more will be needed to sign off this PR. However, I still want to check through a few parts of the code that I have not fully cross-checked against the Java routines (e.g. the Barrett reductions). I'll try to do that asap but it will probably be a few days from now. > > Thanks again for your help in improving this code. @adinn Hi, Andrew, I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2801545565 From adinn at openjdk.org Mon Apr 14 13:00:45 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 14 Apr 2025 13:00:45 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/register_aarch64.hpp line 509: > 507: } > 508: > 509: // convenience methods for splitting 8-way of 4-way vector register Suggestion: // convenience methods for splitting 8-way or 4-way vector register src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5012: > 5010: assert(!va.is_constant(), "output vector must identify 2 different registers"); > 5011: > 5012: // schedule 2 streams of i 5164: // > 5165: // On each level, we fill up the vector registers in such a way that the > 5166: // array elements that need to be multiplied by the zetas be in one Suggestion: // array elements that need to be multiplied by the zetas are in one src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5168: > 5166: // array elements that need to be multiplied by the zetas be in one > 5167: // set of vector registers while the corresponding ones that don't need to > 5168: // be multiplied, in another set. We can do 32 Montgomery multiplications Suggestion: // be multiplied are in another set. We can do 32 Montgomery multiplications src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5278: > 5276: // level 4 > 5277: vs_ldpq(vq, kyberConsts); > 5278: int offsets3[8] = { 0, 32, 64, 96, 128, 160, 192, 224 }; I'd like to add comment here to explain the coefficient grouping and likewise at level 5 and 6. So here we have: Suggestion: // Up to level 3 the coefficients multiplied by or added/subtracted // to the zetas occur in discrete blocks whose size is some multiple // of 32. At level 4 coefficients occur in 8 discrete blocks of size 16 // so they are loaded using an ldr at 8 distinct offsets. int offsets3[8] = { 0, 32, 64, 96, 128, 160, 192, 224 }; src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5299: > 5297: > 5298: // level 5 > 5299: vs_ldpq(vq, kyberConsts); Suggestion: vs_ldpq(vq, kyberConsts); // At level 5 related coefficients occur in discrete blocks of size 8 so // need to be loaded interleaved using an ld2 operation with arrangement 2D src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5319: > 5317: vs_st2_indexed(vs1, __ T2D, coeffs, tmpAddr, 384, offsets4); > 5318: > 5319: // level 6 Suggestion: // level 6 // At level 6 related coefficients occur in discrete blocks of size 4 so // need to be loaded interleaved using an ld2 operation with arrangement 4S src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5377: > 5375: // level 0 > 5376: vs_ldpq(vq, kyberConsts); > 5377: int offsets4[4] = { 0, 32, 64, 96 }; Again a comment Suggestion: // At level 6 related coefficients occur in discrete blocks of size 4 so // need to be loaded interleaved using an ld2 operation with arrangement 4S int offsets4[4] = { 0, 32, 64, 96 }; src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5399: > 5397: vs_st2_indexed(vs1, __ T4S, coeffs, tmpAddr, 384, offsets4); > 5398: > 5399: // level 1 Again a comment Suggestion: // level 1 // At level 1 related coefficients occur in discrete blocks of size 8 so // need to be loaded interleaved using an ld2 operation with arrangement 2D src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5422: > 5420: vs_st2_indexed(vs1, __ T2D, coeffs, tmpAddr, 384, offsets4); > 5421: > 5422: // level 2 Again Suggestion: // level 2 // At level 2 coefficients occur in 8 discrete blocks of size 16 // so they are loaded using employing an ldr at 8 distinct offsets. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5464: > 5462: vs_str_indexed(vs1, __ Q, coeffs, 256, offsets3); > 5463: > 5464: // level 3 Suggestion: // level 3 // From level 3 upwards coefficients occur in discrete blocks whose size is // some multiple of 32 so can be loaded using ldpq and suitable indexes. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5591: > 5589: store64shorts(vs2, tmpAddr); > 5590: > 5591: load64shorts(vs1, tmpAddr); I'd like to make explicit the fact that we have avoided doing an add here (and in the next two cases) by adding a commented out generation step i.e. at this line insert Suggestion: // __ add(tmpAddr, coeffs, 128); // unneeded as implied by preceding store load64shorts(vs1, tmpAddr); src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5596: > 5594: store64shorts(vs2, tmpAddr); > 5595: > 5596: load64shorts(vs1, tmpAddr); Likewise insert: Suggestion: // __ add(tmpAddr, coeffs, 256); // unneeded as implied by preceding store load64shorts(vs1, tmpAddr); src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5601: > 5599: store64shorts(vs2, tmpAddr); > 5600: > 5601: load64shorts(vs1, tmpAddr); Likewise insert: Suggestion: // __ add(tmpAddr, coeffs, 384); // unneeded as implied by preceding store load64shorts(vs1, tmpAddr); src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5640: > 5638: VSeq<4> vs1(0), vs2(4); // 4 sets of 8x8H inputs/outputs/tmps > 5639: VSeq<4> vs3(16), vs4(20); > 5640: VSeq<2> vq(30); // pair of constants for montmul Suggestion: VSeq<2> vq(30); // pair of constants for montmul: qinv, q src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5642: > 5640: VSeq<2> vq(30); // pair of constants for montmul > 5641: VSeq<2> vz(28); // pair of zetas > 5642: VSeq<4> vc(27, 0); // constant sequence for montmul Suggestion: VSeq<4> vc(27, 0); // constant for montmul: montRSquareModQ src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6094: > 6092: VSeq<8> vc2_1(31, 0); > 6093: VSeq<2> vc2_2(31, 0); > 6094: FloatRegister vc2_3 = v31; Suggestion: // we also need a pair of corresponding constant sequences VSeq<8> vc1_1(30, 0); // kyber_q VSeq<2> vc1_2(30, 0); FloatRegister vc1_3 = v30; VSeq<8> vc2_1(31, 0); // kyberBarrettMultiplier VSeq<2> vc2_2(31, 0); FloatRegister vc2_3 = v31; src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6102: > 6100: // load q and the multiplier for the Barrett reduction > 6101: __ add(kyberConsts, kyberConsts, 16); > 6102: __ ldpq(vc1_3, vc2_3, kyberConsts); Suggestion: __ ldpq(vc1_3, vc2_3, kyberConsts); // kyber_q, kyberBarrettMultiplier src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6111: > 6109: __ ldr(vs1_3, __ Q, __ post(coeffs, 16)); > 6110: } > 6111: vs_sqdmulh(vs2_1, __ T8H, vs1_1, vc2_1); Suggestion: vs_sqdmulh(vs2_1, __ T8H, vs1_1, vc2_1); // vs2 <- (2 * vs1 * kyberBarrettMultiplier) >> 16 src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6116: > 6114: __ sqdmulh(vs2_3, __ T8H, vs1_3, vc2_3); > 6115: } > 6116: vs_sshr(vs2_1, __ T8H, vs2_1, 11); Suggestion: vs_sshr(vs2_1, __ T8H, vs2_1, 11); // vs2 <- (vs1 * kyberBarrettMultiplier) >> 26 src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6121: > 6119: __ sshr(vs2_3, __ T8H, vs2_3, 11); > 6120: } > 6121: vs_mlsv(vs1_1, __ T8H, vs2_1, vc1_1); Suggestion: vs_mlsv(vs1_1, __ T8H, vs2_1, vc1_1); // vs1 <- vs1 - vs2 * kyber_q ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041886663 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041888092 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041889242 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041889966 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041892243 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041892994 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041893924 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041895469 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041896626 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041898215 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041899623 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041902206 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041902833 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041906126 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041909711 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041929011 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041867539 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041868670 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041881429 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041883012 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2041883686 From adinn at openjdk.org Mon Apr 14 13:14:19 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 14 Apr 2025 13:14:19 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5661: > 5659: // load 16 zetas > 5660: vs_ldpq_post(vz, zetas); > 5661: // load 2 sets of 32 coefficients from the two input arrays Suggestion: // load 2 sets of 32 coefficients from the two input arrays // interleaved as shorts. i.e. pairs of shorts adjacent in memory // are striped across pairs of vector registers ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2042093533 From ihse at openjdk.org Mon Apr 14 13:14:54 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 14 Apr 2025 13:14:54 GMT Subject: RFR: 8354449: Remove com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 20:34:39 GMT, Sean Mullan wrote: > Workaround for `sed` issue on MacOS 15.4. See https://bugs.openjdk.org/browse/JDK-8353948 for more details. > > This is a leftover resource file from long ago which serves no purpose, and has been removed in the next Apache release: https://issues.apache.org/jira/browse/SANTUARIO-624 > > Running through mach 5 tiers 1 and 2 to be safe, so probably won't integrate until Monday. Seems like a good solution! It effectively solved the immediate problem, and it gets rid of old unused stuff. Two birds in one stone. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24601#pullrequestreview-2763765228 From rriggs at openjdk.org Mon Apr 14 14:24:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 14 Apr 2025 14:24:44 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs wrote: > The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. > The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. > Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. > The remaining support will be removed when FilePermission is removed. I considered dropping the property support, but it seemed harmless to leave it until FilePermission is removed and avoids thrash in an unused implementation and documentation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2801882511 From dfuchs at openjdk.org Mon Apr 14 14:24:51 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 14 Apr 2025 14:24:51 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > update to minimise code changes src/java.base/share/classes/java/net/NetworkInterface.java line 329: > 327: } else { > 328: throw new IllegalArgumentException( > 329: formatMsg("invalid address type%s", filterNetInfo(addr.toString()).prefixWith(": "))); OK - I see that `addr` cannot be null if we reach here. src/java.base/share/classes/java/net/Proxy.java line 101: > 99: throw new IllegalArgumentException( > 100: formatMsg("type " + type + " is not compatible with address %s", > 101: filterNetInfo(sa.toString()) You will get NullPointerException instead of IllegalArgumentException if `sa` is `null`. I suggest using `String.valueOf(sa)` rather than `sa.toString()` to preserve the pre-existing behaviour. src/java.base/share/classes/java/net/Proxy.java line 102: > 100: formatMsg("type " + type + " is not compatible with address %s", > 101: filterNetInfo(sa.toString()) > 102: .replaceWith("type " + sa.getClass().toString()))); You will have to guard against sa == null here src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253: > 251: > 252: int i = 0; > 253: boolean enhanced = true; `enhanced` doesn't seem to be used here. Is this some leftover? src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java line 203: > 201: throw new NullPointerException( > 202: formatMsg("malformed context url%s : no !/", > 203: filterJarName(url.toString()).prefixWith(": "))); It's not clear whether `url` could be `null` here, so to sidestep the question maybe use `String::valueOf` rather than `Object::toString`. src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java line 212: > 210: throw new NullPointerException( > 211: formatMsg("malformed context url%s", > 212: filterJarName(url.toString()).prefixWith(": "))); Same remark here test/jdk/java/net/URI/Test.java line 29: > 27: * 7171415 6339649 6933879 8037396 8272072 8051627 8297687 > 28: * @author Mark Reinhold > 29: * @run main/othervm -Djdk.includeInExceptions=hostInfo Test This change does not look like it's needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042182598 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042187411 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042190019 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042199577 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042214144 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042215273 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042244694 From rriggs at openjdk.org Mon Apr 14 14:43:00 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 14 Apr 2025 14:43:00 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes [v2] In-Reply-To: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> References: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> Message-ID: On Sat, 5 Apr 2025 01:30:49 GMT, Shaojin Wen wrote: >> During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10 anonymous classes, which slows down the startup. This PR is to improve KnownOIDs and eliminate unnecessary embedded classes. >> >> >> Here's how to reproduce this: >> >> >> public class Startup { >> public static void main(String[] args) {} >> } >> >> >> >> java -verbose:class Startup >> >> >> >> [0.665s][info][class,load] sun.security.util.KnownOIDs >> [0.666s][info][class,load] sun.security.util.KnownOIDs$1 >> [0.667s][info][class,load] sun.security.util.KnownOIDs$2 >> [0.667s][info][class,load] sun.security.util.KnownOIDs$3 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$4 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$5 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$6 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$7 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$8 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$9 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$10 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @valeriepeng Looks ok; but will need to be re-opened. It would seem odd to approve a closed PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23411#issuecomment-2801947830 From mullan at openjdk.org Mon Apr 14 14:46:45 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Apr 2025 14:46:45 GMT Subject: Integrated: 8354449: Remove com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 20:34:39 GMT, Sean Mullan wrote: > Workaround for `sed` issue on MacOS 15.4. See https://bugs.openjdk.org/browse/JDK-8353948 for more details. > > This is a leftover resource file from long ago which serves no purpose, and has been removed in the next Apache release: https://issues.apache.org/jira/browse/SANTUARIO-624 > > Running through mach 5 tiers 1 and 2 to be safe, so probably won't integrate until Monday. This pull request has now been integrated. Changeset: 16657dba Author: Sean Mullan URL: https://git.openjdk.org/jdk/commit/16657dba998207ef238ac387336907cd186e31d5 Stats: 199 lines in 1 file changed: 0 ins; 199 del; 0 mod 8354449: Remove com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties Reviewed-by: weijun, ihse ------------- PR: https://git.openjdk.org/jdk/pull/24601 From abarashev at openjdk.org Mon Apr 14 15:19:18 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 14 Apr 2025 15:19:18 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v3] In-Reply-To: References: Message-ID: > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Update Copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/134a3264..9d2a7743 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=01-02 Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From duke at openjdk.org Mon Apr 14 15:34:21 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 14 Apr 2025 15:34:21 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v9] In-Reply-To: References: Message-ID: > By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Uncommented an accidentakky commented line in ML_KEM.java + changed 1 more comment as suggested by Andrew Dinn. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23663/files - new: https://git.openjdk.org/jdk/pull/23663/files/d7f7fc8e..5901547f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=07-08 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663 PR: https://git.openjdk.org/jdk/pull/23663 From mullan at openjdk.org Mon Apr 14 15:49:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Apr 2025 15:49:57 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v16] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 05:09:52 GMT, Koushik Muthukrishnan Thirupattur wrote: >> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc. >> >> ![image](https://github.com/user-attachments/assets/b8a589d1-691e-4fb6-bb18-5890c73cb37d) >> >> >> >> >> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8328914: Document the java.security.debug property in javadoc src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 53: > 51:

The java.security.debug system property

> 52: > 53:

Debug

I would remove these 2 headings ("The java.security.debug system property" and "Debug"), as they are not needed since right now this document is only about one property and the title says the name of the property. If we add more system properties in the future, we can add more subsections. src/java.base/share/classes/java/security/package-info.java line 1: > 1: /* Update copyright date. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r2042424084 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r2042416653 From mullan at openjdk.org Mon Apr 14 15:52:45 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Apr 2025 15:52:45 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v16] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 05:09:52 GMT, Koushik Muthukrishnan Thirupattur wrote: >> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc. >> >> ![image](https://github.com/user-attachments/assets/b8a589d1-691e-4fb6-bb18-5890c73cb37d) >> >> >> >> >> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8328914: Document the java.security.debug property in javadoc src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 1: > 1: For now, let's change the name of this file to "debug-system-property.html". We can always change the name later if we add more system properties to it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r2042437371 From rriggs at openjdk.org Mon Apr 14 16:14:03 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 14 Apr 2025 16:14:03 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess [v2] In-Reply-To: References: Message-ID: > The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. > The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. > Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. > The remaining support will be removed when FilePermission is removed. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Simplify as suggested in review comments Convert static methods to instance methods and invoke on the existing FilePermission. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24603/files - new: https://git.openjdk.org/jdk/pull/24603/files/721fba81..56680c47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24603&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24603&range=00-01 Stats: 27 lines in 2 files changed: 1 ins; 2 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/24603.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24603/head:pull/24603 PR: https://git.openjdk.org/jdk/pull/24603 From rriggs at openjdk.org Mon Apr 14 16:17:48 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 14 Apr 2025 16:17:48 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess [v2] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 16:14:03 GMT, Roger Riggs wrote: >> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. >> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. >> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. >> The remaining support will be removed when FilePermission is removed. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Simplify as suggested in review comments > Convert static methods to instance methods and invoke on the existing FilePermission. Note: FilePermissionCollectionMerge has never worked when `jdk.io.permissionsUseCanonicalPath=true`. The creation of the alternate FilePermission gets an NPE because the internal npath is null. And still does not; it is not worth fixing since FilePermission is to be removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24603#issuecomment-2802221485 From mullan at openjdk.org Mon Apr 14 17:56:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Apr 2025 17:56:50 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v14] In-Reply-To: References: Message-ID: <1JYX6gMahUjwiOKFNofynWUIEDlCCZSRQB4xYGgFdhg=.e32d7a25-25cd-44d2-8bb4-fcd0c65e4a47@github.com> On Wed, 2 Apr 2025 20:35:29 GMT, Weijun Wang wrote: >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >> ![hpke](https://github.com/user-attachments/assets/4edc5d08-ef52-44c5-b5d5-e8890c2d2fce) > > Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: > > - put encapsulation in params from getParameters > - receiver must specify all algorithm identifiers src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 53: > 51: *
  • {@link #of()} creates an instance with unspecified KEM, KDF, and AEAD > 52: * algorithms, which will be determined by the implementation based on the key > 53: * provided to {@code init()}. This instance can only be used by the sender. Does `Cipher.init` throw an exception if the parameters created by `HPKEParameterSpec.of()` are initialized with a cipher in decrypt mode? src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 82: > 80: * public key. > 81: *
  • > 82: * If HPKE modes {@code mode_psk} or {@code mode_auth_psk} are used, If you want to use `mode_auth_psk`, do you have to call both `authKey` and `psk` methods? If so, I think it would be more readable if you have a separate paragraph for this mode, indicating calling both methods are required. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2040102243 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2040109790 From mullan at openjdk.org Mon Apr 14 17:56:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Apr 2025 17:56:53 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v15] In-Reply-To: References: Message-ID: <0Ppa9h_Gyc9W1MoYIWffLA9wRiWxrMYy93zqpEwZGIg=.74790f84-fc3e-4d6c-84fd-8613f39328fc@github.com> On Fri, 11 Apr 2025 20:41:13 GMT, Weijun Wang wrote: >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >> ![hpke](https://github.com/user-attachments/assets/4edc5d08-ef52-44c5-b5d5-e8890c2d2fce) > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > toString, exportData, spec in HPKEParameters must have algorithm identifiers specified src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 78: > 76: * {@link #info(byte[])} method by both sides. > 77: *
  • > 78: * If HPKE modes {@code mode_auth} or {@code mode_auth_psk} are used, This could be reworded as: "To use the HPKE modes {@code mode_auth} ..." src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 35: > 33: public static void main(String[] args) throws Exception { > 34: // @start region="hpke-spec-example" > 35: // Key pair generation Comment should note this is the recipient's key pair. src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 46: > 44: sender.init(Cipher.ENCRYPT_MODE, kp.getPublic(), ps); > 45: > 46: // Retrieve the actual parameters used from the sender. I think it would be more clear if you didn't name the cipher objects `sender` and `recipient` because there can be confusion as to whether you mean the cipher objects or the sender/receiver entities. src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 64: > 62: recipient.init(Cipher.DECRYPT_MODE, kp.getPrivate(), pr); > 63: > 64: // Secure communication between the 2 sides There is no secure communication in the code below. I would remove/change this comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2042597344 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2042605774 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2042611506 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2042620693 From liach at openjdk.org Mon Apr 14 18:17:52 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 14 Apr 2025 18:17:52 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess [v2] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 16:14:03 GMT, Roger Riggs wrote: >> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. >> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. >> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. >> The remaining support will be removed when FilePermission is removed. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Simplify as suggested in review comments > Convert static methods to instance methods and invoke on the existing FilePermission. Looks good to me but need other engineers to review security related aspects. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24603#pullrequestreview-2765200561 From chap at anastigmatix.net Mon Apr 14 18:31:48 2025 From: chap at anastigmatix.net (Chapman Flack) Date: Mon, 14 Apr 2025 14:31:48 -0400 Subject: Integrated: 8295803: Console should be usable in jshell and other environments In-Reply-To: References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com> Message-ID: <67FD5494.3070507@anastigmatix.net> Hello, This existing email thread seems to hold the most historical context regarding usability of Console in jshell. On 12/07/22 15:52, Naoto Sato wrote: > On Tue, 29 Nov 2022 19:38:02 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached > to the platform provided terminal, such as the case when the > standard input is redirected. `System.console()` now returns > a Console implementation based on `jdk.internal.le` terminal by default, > or jshell implementation if available. A corresponding CSR has been > drafted. > This pull request has now been integrated. > Changeset: 8a9911ef > Author: Naoto Sato > URL: https://git.openjdk.org/jdk/commit/8a9911ef1762ae837e427ec9d91b1399ba33b6e4 > Stats: 684 lines in 17 files changed: 661 ins; 11 del; 12 mod > 8295803: Console should be usable in jshell and other environments > Reviewed-by: jlaskey, alanb > PR: https://git.openjdk.org/jdk/pull/11421 Since integration of 8295803, it is possible to use Console in jshell *when using jshell interactively*. When jshell is reading from a script file, it remains impossible to use readLine or readPassword of Console. This is the case whether the script file being read from is supplied as jshell's standard input, or is named on the command line, or is named with /open in an interactive session. It is perhaps least astonishing to have the Console not work when standard input is redirected (though I'm not aware of a modern OS where the console can't be identified even when stdin happens to be redirected). On the other hand, it is quite astonishing when the opening of a script file by name interferes with use of the console. The upshot is that a common expectation of a scripting language--that it be able to solicit some user input or a password while executing a script--remains unmet in jshell even with the integration of 8295803. At first glance, it appears to me there is no very fundamental problem, except that Console operations are vectored through an IOContext, and the ScannerIOContext put in place while reading from a script does not accommodate them. There may have been a bit of conceptual conflation around whether a NonInteractiveIOContext (perhaps only meaning the commands being executed are sourced from a file) must be the same thing as a context with no access to a console for soliciting input. Prior to JDK 24, an attempt to use readLine or readPassword results in an uncaught exception that terminates the state engine: Exception in thread "output reader" jdk.internal.org.jline.reader.UserInterruptException at jdk.jshell/jdk.internal.jshell.tool.IOContext.readPassword(IOContext.java:75) at jdk.jshell/jdk.internal.jshell.tool.JShellTool$IOContextConsole.readPassword(JShellTool.java:4114) at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:410) at java.base/java.io.OutputStream.write(OutputStream.java:167) at java.base/java.io.OutputStream.write(OutputStream.java:124) at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74) State engine terminated. As of JDK 24, there is no uncaught exception, but readLine / readPassword simply return null, after displaying the supplied prompt. The behavior change for JDK 24 appears to have been included without explanation in an unrelated commit for JDK-8341631: https://github.com/openjdk/jdk24u/commit/cf158bc6cdadfdfa944b8ec1d3dc7069c8f055a9#diff-0ec20a2b27010e8ce642a3f62fdb25fee623b0e4c564f4f49bedeabf7b0a7107R4110-R4137 It may be that the changes (catching the exception and returning null) were a preliminary stage of an effort to make readLine / readPassword actually work; the intention just isn't clear from that commit message. Regards, Chapman Flack From coffeys at openjdk.org Mon Apr 14 18:42:40 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 14 Apr 2025 18:42:40 GMT Subject: RFR: 8350582: Correct the parsing of the ssl value in javax.net.debug [v4] In-Reply-To: References: Message-ID: > Breaking the parent JDK-8044609 JBS issue into sub tasks. > > This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced. This patch should be easier for backporting also. > > Wider corrections can be followed up via parent bug. Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Review comments from Brad - Merge branch 'master' into 8350582-javax-debug - Incorporate latest review feedback - Feedback from Mikhail - correct bug id - 8210430 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23781/files - new: https://git.openjdk.org/jdk/pull/23781/files/0cf24eda..cb444611 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23781&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23781&range=02-03 Stats: 199524 lines in 4350 files changed: 87343 ins; 88046 del; 24135 mod Patch: https://git.openjdk.org/jdk/pull/23781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23781/head:pull/23781 PR: https://git.openjdk.org/jdk/pull/23781 From coffeys at openjdk.org Mon Apr 14 18:46:41 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 14 Apr 2025 18:46:41 GMT Subject: RFR: 8350582: Correct the parsing of the ssl value in javax.net.debug [v3] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 03:11:42 GMT, Bradford Wetmore wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporate latest review feedback > > Depending on the followup discussion of what `ssl` alone means. > > However, several suggestions below, one might help with test coverage. If you take some/all, then I'll review again. Should be quick. Thanks for your review @bradfordwetmore - I've fixed up the test case as per your review comments. Breaking the test output logic into two maps sounds attractive but the logic isn't mutually exclusive for some of our debug options. In fact, the debug logic for sub-components is still broken and should be fixed up in the follow on 8044609 bug fix. The logger implementation is at odds with our help and docs menu. I have used a map to test for good/bad patterns but I've left the keys for those maps as user defined. this fixes up special handling of the "ssl" option and restores it to the older TLSv1.2 stack approach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23781#issuecomment-2802627538 From valeriep at openjdk.org Mon Apr 14 19:07:06 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 14 Apr 2025 19:07:06 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v4] In-Reply-To: References: Message-ID: > As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings. > > Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: the suggested test changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24068/files - new: https://git.openjdk.org/jdk/pull/24068/files/b7b19438..e42e4402 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=02-03 Stats: 97 lines in 1 file changed: 44 ins; 18 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/24068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24068/head:pull/24068 PR: https://git.openjdk.org/jdk/pull/24068 From fferrari at openjdk.org Mon Apr 14 19:15:57 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Mon, 14 Apr 2025 19:15:57 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Fri, 11 Apr 2025 23:36:17 GMT, Martin Balao wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 246: >> >>> 244: alg.equalsIgnoreCase("Generic")) { >>> 245: return ki.keyType; >>> 246: } >> >> What is this check for? It's not immediately clear to me why do we look up the keyInfo using `alg` but then again to check to error out when the found keyType is CKK_GENERIC_SECRET && alg not equals "Generic". This seems to directly contradicts the special workaround for "TlsXXX" in my other PR? > > For the TlsXXX issue I check the pseudo-mechanism. That works if all algorithms are known to the map. I'll check how many we have and see what are the pros/cons of having them in the map. I prefer symmetric key algorithms to be in the map. > > The reason for the check you referred is to block deriving keys such as HmacSHA256, PBEWithHmacSHA224AndAES_256, etc. which are not the result of HKDF derivations, but of Mac and PBE derivation. As far as I understand it, `HmacSHA256` is blocked, but not `PBEWithHmacSHA224AndAES_256`. ### `HmacSHA256` * Has an `HMACKeyInfo` entry with the following non-static fields: * `KeyInfo.algo` = `"HmacSHA256"` * `KeyInfo.keyType` = `CKK_GENERIC_SECRET` * `KeyInfo.keyGenMech` = `CK_UNAVAILABLE_INFORMATION` * `HMACKeyInfo.mech` = `CKM_SHA256_HMAC` * `HMACKeyInfo.keyLen` = `256` Given `ki.keyType` is `CKK_GENERIC_SECRET` and `alg` is `HmacSHA256`, in `P11HKDF::getDerivedKeyType` it will enter the first `case` but not the `if`. So it will finally throw the expected exception: InvalidAlgorithmParameterException("A key of algorithm 'HmacSHA256' is not valid for derivation.") ### `PBEWithHmacSHA224AndAES_256` * Has an `AESPBEKeyInfo` entry with the following non-static fields: * `KeyInfo.algo` = `"PBEWithHmacSHA224AndAES_256"` * `KeyInfo.keyType` = `CKK_AES` * `KeyInfo.keyGenMech` = `CK_UNAVAILABLE_INFORMATION` * `PBEKeyInfo.kdfMech` = `CKM_PKCS5_PBKD2` * `PBEKeyInfo.prfMech` = `CKP_PKCS5_PBKD2_HMAC_SHA224` * `PBEKeyInfo.keyLen` = `256` * `PBEKeyInfo.extraAttrs` = `new CK_ATTRIBUTE[] { CK_ATTRIBUTE.ENCRYPT_TRUE }` Given `ki.keyType` is `CKK_AES`, in `P11HKDF::getDerivedKeyType` it will enter the first `case` and also the `if`, returning `CKK_AES`. Later, in `P11KeyGenerator::checkKeySize(..., Token token)`, `P11KeyGenerator::getSupportedRange` will return `null`, because `ki.keyGenMech` is `CK_UNAVAILABLE_INFORMATION`. This will make `P11KeyGenerator::checkKeySize(..., CK_MECHANISM_INFO range)` enter the `default` case, and finally return the unmodified `keySize`. No exception is thrown, unless I'm missing something. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2042766732 From fferrari at openjdk.org Mon Apr 14 19:15:56 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Mon, 14 Apr 2025 19:15:56 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 10 Apr 2025 23:54:03 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - Algorithm and key size checking before derivation. Mechanism normalization for TLS. > - Minor import adjustment. Hi @martinuy, Thanks for your proposal, I left four comments. Two of them are suggestions/ideas, but unless my static analysis is bogus, I also found a minor bug (one comment explains the reasoning, the other suggests a low-hanging fruit test case to confirm). src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 240: > 238: putKeyInfo(new KeyInfo("TlsPremasterSecret", PCKK_TLSPREMASTER)); > 239: putKeyInfo(new KeyInfo("TlsRsaPremasterSecret", PCKK_TLSRSAPREMASTER)); > 240: putKeyInfo(new KeyInfo("TlsMasterSecret", PCKK_TLSMASTER)); Have you considered removing `PCKK_TLSPREMASTER`, `PCKK_TLSRSAPREMASTER` and `PCKK_TLSMASTER` from everywhere? We could just use `CKK_GENERIC_SECRET` for the `TlsPremasterSecret`, `TlsRsaPremasterSecret` and `TlsMasterSecret` key info entries. Unlike `PCKK_ANY`, which is used for the `TemplateManager` to map `*` entries in _SunPKCS11_ configuration files [1], these other 3 pseudo key types are only used here in `P11SecretKeyFactory`. Additionally, any time these 3 pseudo key types are used, it is to map to `CKK_GENERIC_SECRET`. [1] _SunPKCS11_ configuration files can't contain `PCKK_TLS*MASTER` attributes entries, only `*` is parsable, and corresponds with `PCKK_ANY`: https://github.com/openjdk/jdk/blob/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Functions.java#L1258 test/jdk/sun/security/pkcs11/KDF/TestHKDF.java line 643: > 641: 32, > 642: "Derivation of an invalid key algorithm"); > 643: } I suggest adding a case with an invalid key algorithm whose key info map entry doesn't have `KeyInfo.keyType=CKK_GENERIC_SECRET`. For example, `PBEWithHmacSHA224AndAES_256`, where `KeyInfo.keyType=CKK_AES`. ------------- Changes requested by fferrari (Committer). PR Review: https://git.openjdk.org/jdk/pull/24526#pullrequestreview-2765121407 PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2042623420 PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2042751519 From fferrari at openjdk.org Mon Apr 14 19:15:57 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Mon, 14 Apr 2025 19:15:57 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Mon, 14 Apr 2025 19:01:00 GMT, Francisco Ferrari Bihurriet wrote: >> For the TlsXXX issue I check the pseudo-mechanism. That works if all algorithms are known to the map. I'll check how many we have and see what are the pros/cons of having them in the map. I prefer symmetric key algorithms to be in the map. >> >> The reason for the check you referred is to block deriving keys such as HmacSHA256, PBEWithHmacSHA224AndAES_256, etc. which are not the result of HKDF derivations, but of Mac and PBE derivation. > > As far as I understand it, `HmacSHA256` is blocked, but not `PBEWithHmacSHA224AndAES_256`. > > ### `HmacSHA256` > > * Has an `HMACKeyInfo` entry with the following non-static fields: > * `KeyInfo.algo` = `"HmacSHA256"` > * `KeyInfo.keyType` = `CKK_GENERIC_SECRET` > * `KeyInfo.keyGenMech` = `CK_UNAVAILABLE_INFORMATION` > * `HMACKeyInfo.mech` = `CKM_SHA256_HMAC` > * `HMACKeyInfo.keyLen` = `256` > > Given `ki.keyType` is `CKK_GENERIC_SECRET` and `alg` is `HmacSHA256`, in `P11HKDF::getDerivedKeyType` it will enter the first `case` but not the `if`. So it will finally throw the expected exception: > > > InvalidAlgorithmParameterException("A key of algorithm 'HmacSHA256' is not valid for derivation.") > > > ### `PBEWithHmacSHA224AndAES_256` > > * Has an `AESPBEKeyInfo` entry with the following non-static fields: > * `KeyInfo.algo` = `"PBEWithHmacSHA224AndAES_256"` > * `KeyInfo.keyType` = `CKK_AES` > * `KeyInfo.keyGenMech` = `CK_UNAVAILABLE_INFORMATION` > * `PBEKeyInfo.kdfMech` = `CKM_PKCS5_PBKD2` > * `PBEKeyInfo.prfMech` = `CKP_PKCS5_PBKD2_HMAC_SHA224` > * `PBEKeyInfo.keyLen` = `256` > * `PBEKeyInfo.extraAttrs` = `new CK_ATTRIBUTE[] { CK_ATTRIBUTE.ENCRYPT_TRUE }` > > Given `ki.keyType` is `CKK_AES`, in `P11HKDF::getDerivedKeyType` it will enter the first `case` and also the `if`, returning `CKK_AES`. Later, in `P11KeyGenerator::checkKeySize(..., Token token)`, `P11KeyGenerator::getSupportedRange` will return `null`, because `ki.keyGenMech` is `CK_UNAVAILABLE_INFORMATION`. This will make `P11KeyGenerator::checkKeySize(..., CK_MECHANISM_INFO range)` enter the `default` case, and finally return the unmodified `keySize`. No exception is thrown, unless I'm missing something. Also, we could save one of the `if` conditions by creating a separate `case` for `CKK_GENERIC_SECRET`: switch ((int) ki.keyType) { case (int) CKK_DES, (int) CKK_DES3, (int) CKK_AES, (int) CKK_RC4, (int) CKK_BLOWFISH, (int) CKK_CHACHA20 -> { return ki.keyType; } case (int) CKK_GENERIC_SECRET -> { if (alg.equalsIgnoreCase("Generic")) { return ki.keyType; } } // [...] } In my view, this is quicker to understand, what do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2042767712 From mullan at openjdk.org Mon Apr 14 19:40:45 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 14 Apr 2025 19:40:45 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v15] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 20:41:13 GMT, Weijun Wang wrote: >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >> ![hpke](https://github.com/user-attachments/assets/4edc5d08-ef52-44c5-b5d5-e8890c2d2fce) > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > toString, exportData, spec in HPKEParameters must have algorithm identifiers specified src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 136: > 134: * {@snippet lang=java class="PackageSnippets" region="hpke-spec-example"} > 135: * > 136: * @implNote Making this implementation specific means that other providers could in theory choose different defaults, which reduces compatibility but an application could never be sure, or even know if this is for algorithms in RFC 9180. These are probably the most reasonable defaults for RFC 9180 compliant implementations. Did you consider making these defaults a requirement of HPKE implementations? I also wonder if "HPKE" is too general. If there is ever a new HPKE spec with say a new KEM or KDF algorithm for EC/XDH keys, would it be called "HPKE2"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2042820511 From wetmore at openjdk.org Tue Apr 15 00:04:51 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 15 Apr 2025 00:04:51 GMT Subject: RFR: 8350582: Correct the parsing of the ssl value in javax.net.debug [v4] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 18:42:40 GMT, Sean Coffey wrote: >> Breaking the parent JDK-8044609 JBS issue into sub tasks. >> >> This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced. This patch should be easier for backporting also. >> >> Wider corrections can be followed up via parent bug. > > Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Review comments from Brad > - Merge branch 'master' into 8350582-javax-debug > - Incorporate latest review feedback > - Feedback from Mikhail > - correct bug id > - 8210430 Thanks for addressing the other issues in the test e.g. `main`, `../..`, and bug description. In looking at the proposed test for this issue, what I was thinking of is actually a mix of 8350582 and future bug [JDK-8044609](https://bugs.openjdk.org/browse/JDK-8044609) which cleans up the cat/subcats assignments. This bug only handles the `ssl` change, so I'm thinking we should change the regtest for this bug to be a simple test looking for the effects of `ssl` with no `data/verbose/plaintext/packet` output, and move (or update) this more general test to be done for 8044609. Thoughts? test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 79: > 77: debugMessages.put("logger", > 78: List.of("FINE: adding as trusted certificates", > 79: "FINE: WRITE: TLSv1.3 application_data")); Missing a few more test cases for the more general test case. `session` -> `Session initialized:` `packet` -> `Raw write` `defaultctx` -> (may not be able to add if you're using non-default contexts) `verbose` -> `Ignore unsupported cipher suite:` ------------- PR Review: https://git.openjdk.org/jdk/pull/23781#pullrequestreview-2765771586 PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r2042989284 From fferrari at openjdk.org Tue Apr 15 02:46:45 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Tue, 15 Apr 2025 02:46:45 GMT Subject: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions In-Reply-To: <4zW7XEoxy4YlShEw_Jf6ZPMn1llJ09c6sye_tyvhswU=.f5d74ea1-5026-4812-b9ac-9d21c54a90b2@github.com> References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> <4zW7XEoxy4YlShEw_Jf6ZPMn1llJ09c6sye_tyvhswU=.f5d74ea1-5026-4812-b9ac-9d21c54a90b2@github.com> Message-ID: On Thu, 10 Apr 2025 05:52:17 GMT, Alan Bateman wrote: >> Hi, this is a proposal to fix 8352728. >> >> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following: >> >> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`. >> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`. >> >> #### Windows Case >> >> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf: >> >> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`: >> * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473") >> * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288") >> * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop) >> * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja... > > I don't think this change should be integrated before more investigation. I think start by finding out why this code is using toRealPath. For the two cases listed, it looks like toRealPath is correctly failing for the first, but for /dev/stdin then please bring it to nio-dev to discuss how special devices should be handled by that method. Hi again @AlanBateman, I've been doing some research on _Linux_, debugging the following sample: ### `GetContentAndRealPath.java` import java.nio.file.Files; import java.nio.file.Path; import static java.nio.charset.StandardCharsets.UTF_8; public final class GetContentAndRealPath { public static void main(String[] args) throws Exception { if (args.length != 1) { throw new Exception("Please specify a file path"); } Path path = Path.of(args[0]); System.out.println("%(java) Content:"); System.out.println("%(java) => " + new String(Files.readAllBytes(path), UTF_8).trim()); System.out.println("%(java)"); System.out.println("%(java) File::getCanonicalPath:"); System.out.println("%(java) => " + path.toFile().getCanonicalFile().toPath()); System.out.println("%(java)"); System.out.println("%(java) Path::toRealPath:"); System.out.println("%(java) => " + path.toRealPath()); } } The first thing to note is that `/dev/stdin` is not a problem per se, the actual problem is when it is provided by an anonymous pipe. So the following works fine: $ java GetContentAndRealPath.java /dev/stdin %(java) %(java) File::getCanonicalPath: %(java) => /dev/null %(java) %(java) Path::toRealPath: %(java) => /dev/null In Bash, there are various ways to provide `stdin` through an anonymous pipe: # https://www.gnu.org/software/bash/manual/bash.html#Pipelines echo Pipelines | java GetContentAndRealPath.java /dev/stdin # https://www.gnu.org/software/bash/manual/bash.html#Here-Strings java GetContentAndRealPath.java /dev/./stdin << Here-Documents %(java) %(java) File::getCanonicalPath: %(java) => /dev/stdin %(java) %(java) Path::toRealPath: Exception in thread "main" java.nio.file.NoSuchFileException: /etc/../dev/stdin at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:834) at GetContentAndRealPath.main(GetContentAndRealPath.java:24) Please note how `File::getCanonicalPath` resolves `/etc/../dev/stdin` ? `/dev/stdin` while `Path::toRealPath` fails with `NoSuchFileException`. ### _glibc_'s `realpath()` I traced this behaviour inside _glibc_'s `realpath()`, with the following GDB script: gdb -q --nx java <<'EOF' 2>&1 | grep --color=never '^%(\w*)|^Exception|^ at' # Settings set debuginfod enabled on set breakpoint pending on handle SIGSEGV nostop noprint pass # Break once at JDK_Canonicalize(), if the path starts with /dev/fd/ tbreak JDK_Canonicalize if ((int) strncmp(orig, "/dev/fd/", 8)) == 0 # Start java with a Process-Substitution anonymous pipe run GetContentAndRealPath.java <(echo Process-Substitution) # Stopped at JDK_Canonicalize() add a trace for each glibc's realpath() call # https://github.com/bminor/glibc/blob/glibc-2.39/stdlib/canonicalize.c#L431 break canonicalize.c:431 commands python begin_realpath() continue end # Inside glibc's realpath() implementation, also trace each readlink() result # https://github.com/bminor/glibc/blob/glibc-2.39/stdlib/canonicalize.c#L311 break canonicalize.c:311 commands python after_readlink() continue end ############################################################ python from errno import errorcode def begin_realpath(): name = gdb.parse_and_eval('name').string('utf-8') print(f'%(glibc) realpath("{name}")') def after_readlink(): rname = gdb.parse_and_eval('rname').string('utf-8') print(f'%(glibc) readlink("{rname}") -> ', end='') n = int(gdb.parse_and_eval('n')) if n >= 0: buf = gdb.parse_and_eval('buf').string('utf-8')[:n] print(f'"{buf}"') else: errno = int(gdb.parse_and_eval('errno')) print(f'{errorcode[errno]} ({errno})') end ############################################################ # Resume execution from JDK_Canonicalize() continue EOF It produces the following output: %(java) Content: %(java) => Process-Substitution %(java) %(java) File::getCanonicalPath: %(glibc) realpath("/dev/fd/63") %(glibc) readlink("/dev") -> EINVAL (22) %(glibc) readlink("/dev/fd") -> "/proc/self/fd" %(glibc) readlink("/proc") -> EINVAL (22) %(glibc) readlink("/proc/self") -> "1390261" %(glibc) readlink("/proc/1390261") -> EINVAL (22) %(glibc) readlink("/proc/1390261/fd") -> EINVAL (22) %(glibc) readlink("/proc/1390261/fd/63") -> "pipe:[18671624]" %(glibc) readlink("/proc/1390261/fd/pipe:[18671624]") -> ENOENT (2) %(glibc) realpath("/dev/fd") %(glibc) readlink("/dev") -> EINVAL (22) %(glibc) readlink("/dev/fd") -> "/proc/self/fd" %(glibc) readlink("/proc") -> EINVAL (22) %(glibc) readlink("/proc/self") -> "1390261" %(glibc) readlink("/proc/1390261") -> EINVAL (22) %(glibc) readlink("/proc/1390261/fd") -> EINVAL (22) %(java) => /proc/1390261/fd/63 %(java) %(java) Path::toRealPath: %(glibc) realpath("/dev/fd/63") %(glibc) readlink("/dev") -> EINVAL (22) %(glibc) readlink("/dev/fd") -> "/proc/self/fd" %(glibc) readlink("/proc") -> EINVAL (22) %(glibc) readlink("/proc/self") -> "1390261" %(glibc) readlink("/proc/1390261") -> EINVAL (22) %(glibc) readlink("/proc/1390261/fd") -> EINVAL (22) %(glibc) readlink("/proc/1390261/fd/63") -> "pipe:[18671624]" %(glibc) readlink("/proc/1390261/fd/pipe:[18671624]") -> ENOENT (2) Exception in thread "main" java.nio.file.NoSuchFileException: /dev/fd/63 at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:834) at GetContentAndRealPath.main(GetContentAndRealPath.java:24) We can see that `realpath()` invokes `readlink()` several times for the partially normalized path. Anonymous pipes live in the [**PipeFS** virtual filesystem](https://okc1.github.io/blog/2015/07/23/how-is-pipe-implemented-unix), which isn't mounted in userspace. However, anonymous pipes do have a `dentry` which gives them a `dname` with the `pipe:[]` format (Code: [`readlink` syscall](https://github.com/torvalds/linux/blob/v6.12/fs/stat.c#L574) ? [`do_readlinkat`](https://github.com/torvalds/linux/blob/v6.12/fs/stat.c#L551) ? [`vfs_readlink`](https://github.com/torvalds/linux/blob/v6.12/fs/namei.c#L5255) ? [`proc_pid_readlink`](https://github.com/torvalds/linux/blob/v6.12/fs/proc/base.c#L1856) ? [`do_proc_readlink`](https://github.com/torvalds/linux/blob/v6.12/fs/proc/base.c#L1827) ? [`d_path`](https://github.com/torvalds/linux/blob/v6.12/fs/d_path.c#L270-L283) ? [`pipefs_dname`](https://github.com/torvalds/linux/blob/v6.12/fs/pipe.c#L867-L874). Also, there are som e higher level explanations [here](https://unix.stackexchange.com/a/124977) and [here](https://narkive.com/QM2vnkZu.5)). When `readlink()` resolves `/proc//fd/63`, it returns the `pipe:[18543635]` link target, which makes the symlink look "broken" (from the userspace perspective) and this ultimately makes `realpath()` fail with `ENOENT (2)`. However, the unresolved `/proc//fd/0` link works, as the _Linux Kernel_ can access the anonymous pipe behind it: fferrari at vmhost:~$ echo TEST | sleep 20 &>/dev/null &disown [1] 1386980 fferrari at vmhost:~$ cat $(realpath /proc/$(pgrep sleep)/fd/0) cat: '/proc/1386980/fd/pipe:[18629664]': No such file or directory fferrari at vmhost:~$ cat /proc/$(pgrep sleep)/fd/0 TEST ### _OpenJDK_ APIs difference We can see in [`UnixNativeDispatcher::realpath0`](https://github.com/openjdk/jdk/blob/jdk-25+17/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c#L1105 "src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1105") that `Path::toRealPath` translates the _glibc_'s `realpath()` failure immediately. On the other hand `File::getCanonicalPath` goes through [`UnixFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-25+17/src/java.base/unix/native/libjava/UnixFileSystem_md.c#L86-L87 "src/java.base/unix/native/libjava/UnixFileSystem_md.c:86") and `JDK_Canonicalize`, [which retries `realpath()` until some subpath works](https://github.com/openjdk/jdk/blob/jdk-25+17/src/java.base/unix/native/libjava/canonicalize_md.c#L67-L86 "src/java.base/unix/native/libjava/canonicalize_md.c:86"). This aligns with the previous GDB experiment, which showed `File::getCanonicalPath` is doing an additional `realpath("/dev/fd")` call when `realpath("/dev/fd/63")` fails. Given it just follows the _glibc_'s behaviour, I don't think a `Path::toRealPath` change is justifiable for an `nio-dev` request. For example, [an equivalent discussion has been raised for Rust](https://github.com/rust-lang/rust/issues/95239), and the developers aren't considering making any change. `File::getCanonicalPath` seems to take the best-effort approach (both in _Linux_ and _Windows_), whereas `Path::toRealPath` is stricter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-2803609222 From duke at openjdk.org Tue Apr 15 07:07:48 2025 From: duke at openjdk.org (Nibedita Jena) Date: Tue, 15 Apr 2025 07:07:48 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v2] In-Reply-To: References: <-NEwoCypbb1q4sb-Va4C_BfKSfegYOOOz3TMIjx-94k=.b7bc0dcc-30bb-40e2-8e7e-9284de0023c7@github.com> Message-ID: <3op9pxBHOQuyTdZeBqO1jEUm_9rpWGruItPYXzCk6ug=.aa412b76-d3e6-4abf-a312-1e634aa693c9@github.com> On Wed, 9 Apr 2025 14:13:41 GMT, Mikhail Yankelevich wrote: >> Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor change > > test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 361: > >> 359: if (resultOnce) { >> 360: resultOnce = false; >> 361: System.out.println("The format of the SSLEngineResult is: \n" + > > Why is this needed? Wouldn't it be more appropriate to have it outside the logging and just print it out as a description? This is existing format has been used here. It should print only when logging is on (at moment its true always but if changes to false then its no use to print this description) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2043805229 From alanb at openjdk.org Tue Apr 15 07:49:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Apr 2025 07:49:45 GMT Subject: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> Message-ID: On Sat, 5 Apr 2025 02:36:43 GMT, Francisco Ferrari Bihurriet wrote: > Hi, this is a proposal to fix 8352728. > > The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following: > > 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`. > 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`. > > #### Windows Case > > @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf: > > * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`: > * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473") > * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288") > * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop) > * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/java.base/windows/native/libjava/c... > File::getCanonicalPath seems to take the best-effort approach (both in Linux and Windows), whereas Path::toRealPath is stricter. Path::toRealPath is doing the right thing, and consistent with realpath(2). The issue with File::getCanonicalXXX is that it is specified to return a canonical file even if it doesn't exist, so this is why you see a lot more code to compute a result. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-2804137751 From duke at openjdk.org Tue Apr 15 07:50:00 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 15 Apr 2025 07:50:00 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v17] In-Reply-To: References: Message-ID: > java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc. > > image > > > > > NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page. Koushik Muthukrishnan Thirupattur has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: - 8328914: Document the java.security.debug property in javadoc - Merge branch 'master' into 8328914 - 8328914: Document the java.security.debug property in javadoc - 8328914: Document the java.security.debug property in javadoc - 8328914: Document the java.security.debug property in javadoc - 8328914: Document the java.security.debug property in javadoc - 8328914: Document the java.security.debug property in javadoc - 8328914: Document the java.security.debug property in javadoc - 8328914: Document the java.security.debug property in javadoc - 8328914: Document the java.security.debug property in javadoc - ... and 12 more: https://git.openjdk.org/jdk/compare/5dc7bb52...dc7f34fa ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23569/files - new: https://git.openjdk.org/jdk/pull/23569/files/00efddca..dc7f34fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=15-16 Stats: 246879 lines in 5312 files changed: 117081 ins; 101046 del; 28752 mod Patch: https://git.openjdk.org/jdk/pull/23569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23569/head:pull/23569 PR: https://git.openjdk.org/jdk/pull/23569 From michaelm at openjdk.org Tue Apr 15 11:10:49 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 15 Apr 2025 11:10:49 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5] In-Reply-To: References: Message-ID: <4T-aEuL5RC4ragkopv7afbUBA3NT9efLxcG6EZGCJ8o=.65b066df-bc22-4df5-a7b8-c09b8e7515f7@github.com> On Mon, 14 Apr 2025 13:51:30 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> update to minimise code changes > > src/java.base/share/classes/java/net/Proxy.java line 102: > >> 100: formatMsg("type " + type + " is not compatible with address %s", >> 101: filterNetInfo(sa.toString()) >> 102: .replaceWith("type " + sa.getClass().toString()))); > > You will have to guard against sa == null here The `replaceWith()` call is actually not needed at all. I will remove it ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2044273655 From michaelm at openjdk.org Tue Apr 15 11:24:47 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 15 Apr 2025 11:24:47 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5] In-Reply-To: References: Message-ID: <5ovW0BNN592wq1AFeHxH0QsrKk-hDXqCtGHgwRJ6StU=.ab9fa83f-27a7-485f-b586-4b1572329694@github.com> On Mon, 14 Apr 2025 14:20:39 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> update to minimise code changes > > test/jdk/java/net/URI/Test.java line 29: > >> 27: * 7171415 6339649 6933879 8037396 8272072 8051627 8297687 >> 28: * @author Mark Reinhold >> 29: * @run main/othervm -Djdk.includeInExceptions=hostInfo Test > > This change does not look like it's needed. Thanks for the review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2044297016 From mullan at openjdk.org Tue Apr 15 12:48:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 15 Apr 2025 12:48:50 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v17] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 07:50:00 GMT, Koushik Muthukrishnan Thirupattur wrote: >> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc. >> >> image >> >> >> >> >> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page. > > Koushik Muthukrishnan Thirupattur has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - 8328914: Document the java.security.debug property in javadoc > - Merge branch 'master' into 8328914 > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc > - ... and 12 more: https://git.openjdk.org/jdk/compare/42e78a27...dc7f34fa src/java.base/share/classes/java/security/doc-files/debug-system-property.html line 58: > 56:

    > 57: > 58:

    Printing Thread and Timestamp Information

    I would keep this heading as H3, it looks too large as H1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r2044445413 From mbalao at openjdk.org Tue Apr 15 13:22:52 2025 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 15 Apr 2025 13:22:52 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: <2jdzgr96PyMNn1jLpRcxgMZQlfMZpyXm1FxisjdQzBo=.58ec60c8-fb17-47fd-85f1-d30eb12f98dd@github.com> On Mon, 14 Apr 2025 17:44:53 GMT, Francisco Ferrari Bihurriet wrote: >> Martin Balao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Algorithm and key size checking before derivation. Mechanism normalization for TLS. >> - Minor import adjustment. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 240: > >> 238: putKeyInfo(new KeyInfo("TlsPremasterSecret", PCKK_TLSPREMASTER)); >> 239: putKeyInfo(new KeyInfo("TlsRsaPremasterSecret", PCKK_TLSRSAPREMASTER)); >> 240: putKeyInfo(new KeyInfo("TlsMasterSecret", PCKK_TLSMASTER)); > > Have you considered removing `PCKK_TLSPREMASTER`, `PCKK_TLSRSAPREMASTER` and `PCKK_TLSMASTER` from everywhere? We could just use `CKK_GENERIC_SECRET` for the `TlsPremasterSecret`, `TlsRsaPremasterSecret` and `TlsMasterSecret` key info entries. > > Unlike `PCKK_ANY`, which is used for the `TemplateManager` to map `*` entries in _SunPKCS11_ configuration files [1], these other 3 pseudo key types are only used here in `P11SecretKeyFactory`. Additionally, any time these 3 pseudo key types are used, it is to map to `CKK_GENERIC_SECRET`. > > [1] _SunPKCS11_ configuration files can't contain `PCKK_TLS*MASTER` attributes entries, only `*` is parsable, and corresponds with `PCKK_ANY`: > https://github.com/openjdk/jdk/blob/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Functions.java#L1258 I like this idea but the downside I see is that we would need string comparison in `P11KDF::getDerivedKeyType` to allow TLS keys. What if we merge all `PCKK_TLSPREMASTER`, `PCKK_TLSRSAPREMASTER` and `PCKK_TLSMASTER` into `PCKK_TLSKEY` and then do the translation to `CKK_GENERIC_SECRET` as needed? This will also help with the new Tls* keys that I am planning to add to the map. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2044527101 From mbalao at openjdk.org Tue Apr 15 13:26:42 2025 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 15 Apr 2025 13:26:42 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: <2jdzgr96PyMNn1jLpRcxgMZQlfMZpyXm1FxisjdQzBo=.58ec60c8-fb17-47fd-85f1-d30eb12f98dd@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <2jdzgr96PyMNn1jLpRcxgMZQlfMZpyXm1FxisjdQzBo=.58ec60c8-fb17-47fd-85f1-d30eb12f98dd@github.com> Message-ID: On Tue, 15 Apr 2025 13:20:34 GMT, Martin Balao wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 240: >> >>> 238: putKeyInfo(new KeyInfo("TlsPremasterSecret", PCKK_TLSPREMASTER)); >>> 239: putKeyInfo(new KeyInfo("TlsRsaPremasterSecret", PCKK_TLSRSAPREMASTER)); >>> 240: putKeyInfo(new KeyInfo("TlsMasterSecret", PCKK_TLSMASTER)); >> >> Have you considered removing `PCKK_TLSPREMASTER`, `PCKK_TLSRSAPREMASTER` and `PCKK_TLSMASTER` from everywhere? We could just use `CKK_GENERIC_SECRET` for the `TlsPremasterSecret`, `TlsRsaPremasterSecret` and `TlsMasterSecret` key info entries. >> >> Unlike `PCKK_ANY`, which is used for the `TemplateManager` to map `*` entries in _SunPKCS11_ configuration files [1], these other 3 pseudo key types are only used here in `P11SecretKeyFactory`. Additionally, any time these 3 pseudo key types are used, it is to map to `CKK_GENERIC_SECRET`. >> >> [1] _SunPKCS11_ configuration files can't contain `PCKK_TLS*MASTER` attributes entries, only `*` is parsable, and corresponds with `PCKK_ANY`: >> https://github.com/openjdk/jdk/blob/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Functions.java#L1258 > > I like this idea but the downside I see is that we would need string comparison in `P11KDF::getDerivedKeyType` to allow TLS keys. What if we merge all `PCKK_TLSPREMASTER`, `PCKK_TLSRSAPREMASTER` and `PCKK_TLSMASTER` into `PCKK_TLSKEY` and then do the translation to `CKK_GENERIC_SECRET` as needed? This will also help with the new Tls* keys that I am planning to add to the map. BTW, I don't like the partial "Tls" string comparison much because it's making an assumption about the algorithm name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2044533071 From mbalao at openjdk.org Tue Apr 15 13:26:43 2025 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 15 Apr 2025 13:26:43 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Mon, 14 Apr 2025 18:53:12 GMT, Francisco Ferrari Bihurriet wrote: >> Martin Balao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Algorithm and key size checking before derivation. Mechanism normalization for TLS. >> - Minor import adjustment. > > test/jdk/sun/security/pkcs11/KDF/TestHKDF.java line 643: > >> 641: 32, >> 642: "Derivation of an invalid key algorithm"); >> 643: } > > I suggest adding a case with an invalid key algorithm whose key info map entry doesn't have `KeyInfo.keyType=CKK_GENERIC_SECRET`. For example, `PBEWithHmacSHA224AndAES_256`, where `KeyInfo.keyType=CKK_AES`. Sounds good! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2044534670 From mbalao at openjdk.org Tue Apr 15 13:49:44 2025 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 15 Apr 2025 13:49:44 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <0ueeteWqxlhiEC6JBY238zM2-63_O56xay9MlF1QFJg=.27ec81a6-e06a-44fb-b628-c372387e8ba2@github.com> Message-ID: On Fri, 11 Apr 2025 23:46:49 GMT, Martin Balao wrote: >>> What I have found with Tls* keys is that they are in the map but we need to translate their pseudo-mechanism to a valid one (`CKK_GENERIC_SECRET`). Is that enough for #24393? >> >> What I found is that there are more "TlsXXX" than those defined in P11SecretKeyFactory class which are mapped to PCKK_xxx. So, we will need to decide if those self-defined "TlsXXX" algorithms are allowed (e.g. PKCS11 will treat them as Generic secret keys or changing the TLS code to use a key algorithm recognized by PKCS11). Beside this, we need to make sure the current pseudo key type works, e.g. translating to a valid key type when necessary, as you stated. > >> > What I have found with Tls* keys is that they are in the map but we need to translate their pseudo-mechanism to a valid one (`CKK_GENERIC_SECRET`). Is that enough for #24393? >> >> What I found is that there are more "TlsXXX" than those defined in P11SecretKeyFactory class which are mapped to PCKK_xxx. So, we will need to decide if those self-defined "TlsXXX" algorithms are allowed (e.g. PKCS11 will treat them as Generic secret keys or changing the TLS code to use a key algorithm recognized by PKCS11). Beside this, we need to make sure the current pseudo key type works, e.g. translating to a valid key type when necessary, as you stated. > > Good, let me check this. > Hi @martinuy, > > Thanks for your proposal, I left four comments. Two of them are suggestions/ideas, but unless my static analysis is bogus, I also found a minor bug (one comment explains the reasoning, the other suggests a low-hanging fruit test case to confirm). Thanks for your review. Yes, there is a hole that allows derivation for algorithms such as `PBEWithHmacSHA224AndAES_256`. Well spotted! I'm planning to restrict PBE algorithms based on the `PBEKeyInfo` subclass. Perhaps checking `HMACKeyInfo` doesn't hurt, even when these should not pass the mechanism check. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2805117767 From adinn at openjdk.org Tue Apr 15 14:18:54 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 15 Apr 2025 14:18:54 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5665: > 5663: vs_ld2_post(vs_back(vs1), __ T8H, nttb); > 5664: vs_ld2_post(vs_front(vs4), __ T8H, ntta); > 5665: vs_ld2_post(vs_back(vs4), __ T8H, nttb); Suggestion: vs_ld2_post(vs_front(vs1), __ T8H, ntta); // x 8H vs_ld2_post(vs_back(vs1), __ T8H, nttb); // x 8H vs_ld2_post(vs_front(vs4), __ T8H, ntta); // x 8H vs_ld2_post(vs_back(vs4), __ T8H, nttb); // x 8H src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5668: > 5666: // montmul the first and second pair of values loaded into vs1 > 5667: // in order and then with one pair reversed storing the two > 5668: // results in vs3 Suggestion: // compute 4 montmul cross-products for pairs (a0,a1) and (b0,b1) // i.e. montmul the first and second halves of vs1 in order and // then with one sequence reversed storing the two results in vs3 // // vs3[0] <- montmul(a0, b0) // vs3[1] <- montmul(a1, b1) // vs3[2] <- montmul(a0, b1) // vs3[3] <- montmul(a1, b0) src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5674: > 5672: // montmul the first and second pair of values loaded into vs4 > 5673: // in order and then with one pair reversed storing the two > 5674: // results in vs1 Suggestion: // compute 4 montmul cross-products for pairs (a2,a3) and (b2,b3) // i.e. montmul the first and second halves of vs4 in order and // then with one sequence reversed storing the two results in vs1 // // vs1[0] <- montmul(a2, b2) // vs1[1] <- montmul(a3, b3) // vs1[2] <- montmul(a2, b3) // vs1[3] <- montmul(a3, b2) src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5680: > 5678: // for each pair of results pick the second value in the first > 5679: // pair to create a sequence that we montmul by the zetas > 5680: // i.e. we want sequence Suggestion: // montmul result 2 of each cross-product i.e. (a1*b1, a3*b3) by a zeta. // We can schedule two montmuls at a time if we use a suitable vector // sequence . src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5683: > 5681: int delta = vs1[1]->encoding() - vs3[1]->encoding(); > 5682: VSeq<2> vs5(vs3[1], delta); > 5683: kyber_montmul16(vs5, vz, vs5, vs_front(vs2), vq); Suggestion: // vs3[1] <- montmul(montmul(a1, b1), z0) // vs1[1] <- montmul(montmul(a3, b3), z1) kyber_montmul16(vs5, vz, vs5, vs_front(vs2), vq); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044679089 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044682671 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044684696 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044689607 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044691632 From adinn at openjdk.org Tue Apr 15 14:28:11 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 15 Apr 2025 14:28:11 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5684: > 5682: VSeq<2> vs5(vs3[1], delta); > 5683: kyber_montmul16(vs5, vz, vs5, vs_front(vs2), vq); > 5684: // add results in pairs storing in vs3 Suggestion: // add results in pairs storing in vs3 // vs3[0] <- montmul(a0, b0) + montmul(montmul(a1, b1), z0); // vs3[1] <- montmul(a0, b1) + montmul(a1, b0); src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5686: > 5684: // add results in pairs storing in vs3 > 5685: vs_addv(vs_front(vs3), __ T8H, vs_even(vs3), vs_odd(vs3)); > 5686: vs_addv(vs_back(vs3), __ T8H, vs_even(vs1), vs_odd(vs1)); Suggestion: // vs3[2] <- montmul(a2, b2) + montmul(montmul(a3, b3), z1); // vs3[3] <- montmul(a2, b3) + montmul(a3, b2); vs_addv(vs_back(vs3), __ T8H, vs_even(vs1), vs_odd(vs1)); src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5687: > 5685: vs_addv(vs_front(vs3), __ T8H, vs_even(vs3), vs_odd(vs3)); > 5686: vs_addv(vs_back(vs3), __ T8H, vs_even(vs1), vs_odd(vs1)); > 5687: // montmul result by constant vc and store result in vs1 Suggestion: // vs1 <- montmul(vs3, montRSquareModQ) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044712516 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044714830 PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044726778 From adinn at openjdk.org Tue Apr 15 14:31:53 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 15 Apr 2025 14:31:53 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 13:19:05 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision: > > - Code rearrange, some renaming, fixing comments > - Changes suggested by Andrew Dinn. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5690: > 5688: kyber_montmul32(vs1, vs3, vc, vs2, vq); > 5689: // store the four results as two interleaved pairs of > 5690: // quadwords Suggestion: // store back the two pairs of result vectors de-interleaved as 8H elements // i.e. storing each pairs of shorts striped across a register pair adjacent // in memory ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2044745249 From michaelm at openjdk.org Tue Apr 15 14:35:28 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 15 Apr 2025 14:35:28 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v6] In-Reply-To: References: Message-ID: <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com> > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - review update - Merge branch 'master' into 8348986-exceptions - update to minimise code changes - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Apply suggestions from code review from turbanoff review Co-authored-by: Andrey Turbanov - doc + copyright update - remove file added by mistake - whitespace - moved test - ... and 10 more: https://git.openjdk.org/jdk/compare/b7837843...da33863c ------------- Changes: https://git.openjdk.org/jdk/pull/23929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=05 Stats: 948 lines in 42 files changed: 715 ins; 101 del; 132 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From adinn at openjdk.org Tue Apr 15 14:35:51 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 15 Apr 2025 14:35:51 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com> References: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com> <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com> Message-ID: <6HyHF-GcjuyiiFmcu5uJcbwsg7nxqBrErYc25coOqFk=.d5976962-156e-499c-8b5e-9ef775077016@github.com> On Mon, 14 Apr 2025 12:26:09 GMT, Ferenc Rakoczi wrote: >> @ferakocz Hi Ferenc. Thank you for adjusting the code as requested and even more so for the extra clean-ups you added which I very much appreciate. >> >> I have added suggestions for some extra/modified commenting to clarify certain details of what is being generated that were not 100% clear to me when I first read/restructured the code. They may seem a bit obvious but I want to ensure that any maintainer who needs to review the code can assimilate it quickly (including me if/when I revisit it in 12 months time). >> >> Mostly my recommendations for upgrading of comments is complete and I believe little more will be needed to sign off this PR. However, I still want to check through a few parts of the code that I have not fully cross-checked against the Java routines (e.g. the Barrett reductions). I'll try to do that asap but it will probably be a few days from now. >> >> Thanks again for your help in improving this code. > > @adinn Hi, Andrew, > I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review! @ferakocz Hi Ferenc, Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2805488504 From mullan at openjdk.org Tue Apr 15 14:50:01 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 15 Apr 2025 14:50:01 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v3] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 15:19:18 GMT, Artur Barashev wrote: >> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: >> >> >> Any endpoint receiving any certificate which it would need to >> validate using any signature algorithm using an MD5 hash MUST abort >> the handshake with a "bad_certificate" alert. >> >> >> >> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. >> >> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. >> >> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Update Copyright test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 57: > 55: // Certificates and keys used in the test. > 56: // Certificates are signed with signature using MD5WithRSA algorithm. > 57: static String trusedCertStr = We try to avoid hard-coding certificates in tests - can you create these certs as part of a test setup using keytool instead? test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 270: > 268: // MD5 is disabled by default in java.security config file. > 269: Security.setProperty("jdk.certpath.disabledAlgorithms", ""); > 270: Security.setProperty("jdk.tls.disabledAlgorithms", ""); Use `SecurityUtils.removeFromDisabledAlgs` and only remove MD5 from these properties. test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 304: > 302: } > 303: > 304: private static SSLContext getSSLContext(String trusedCertStr, Typo: s/trusedCertStr/trustedCertStr/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044749198 PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044759691 PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044772389 From dfuchs at openjdk.org Tue Apr 15 15:08:57 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 15 Apr 2025 15:08:57 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v6] In-Reply-To: <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com> References: <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com> Message-ID: On Tue, 15 Apr 2025 14:35:28 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - review update > - Merge branch 'master' into 8348986-exceptions > - update to minimise code changes > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Apply suggestions from code review > > from turbanoff review > > Co-authored-by: Andrey Turbanov > - doc + copyright update > - remove file added by mistake > - whitespace > - moved test > - ... and 10 more: https://git.openjdk.org/jdk/compare/b7837843...da33863c Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2768796475 From duke at openjdk.org Tue Apr 15 15:12:47 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 15 Apr 2025 15:12:47 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com> References: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com> <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com> Message-ID: On Mon, 14 Apr 2025 12:26:09 GMT, Ferenc Rakoczi wrote: >> @ferakocz Hi Ferenc. Thank you for adjusting the code as requested and even more so for the extra clean-ups you added which I very much appreciate. >> >> I have added suggestions for some extra/modified commenting to clarify certain details of what is being generated that were not 100% clear to me when I first read/restructured the code. They may seem a bit obvious but I want to ensure that any maintainer who needs to review the code can assimilate it quickly (including me if/when I revisit it in 12 months time). >> >> Mostly my recommendations for upgrading of comments is complete and I believe little more will be needed to sign off this PR. However, I still want to check through a few parts of the code that I have not fully cross-checked against the Java routines (e.g. the Barrett reductions). I'll try to do that asap but it will probably be a few days from now. >> >> Thanks again for your help in improving this code. > > @adinn Hi, Andrew, > I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review! > @ferakocz > > Hi Ferenc, > > Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR. No problem , it was easy to make the changes. Thanks again! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2805981351 From duke at openjdk.org Tue Apr 15 15:12:47 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 15 Apr 2025 15:12:47 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v10] In-Reply-To: References: Message-ID: > By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Accepted more comment changes from Andrew Dinn. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23663/files - new: https://git.openjdk.org/jdk/pull/23663/files/5901547f..b6b3155e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=08-09 Stats: 43 lines in 1 file changed: 27 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/23663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663 PR: https://git.openjdk.org/jdk/pull/23663 From abarashev at openjdk.org Tue Apr 15 15:34:51 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 15 Apr 2025 15:34:51 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v3] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 14:35:38 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Copyright > > test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 304: > >> 302: } >> 303: >> 304: private static SSLContext getSSLContext(String trusedCertStr, > > Typo: s/trusedCertStr/trustedCertStr/ Done, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044918762 From fferrari at openjdk.org Tue Apr 15 15:34:53 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Tue, 15 Apr 2025 15:34:53 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v4] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 19:07:06 GMT, Valerie Peng wrote: >> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings. >> >> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > the suggested test changes Looks good to me, but please note I'm not a Reviewer. ------------- Marked as reviewed by fferrari (Committer). PR Review: https://git.openjdk.org/jdk/pull/24068#pullrequestreview-2768887358 From abarashev at openjdk.org Tue Apr 15 16:04:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 15 Apr 2025 16:04:54 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v3] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 14:32:47 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Copyright > > test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 270: > >> 268: // MD5 is disabled by default in java.security config file. >> 269: Security.setProperty("jdk.certpath.disabledAlgorithms", ""); >> 270: Security.setProperty("jdk.tls.disabledAlgorithms", ""); > > Use `SecurityUtils.removeFromDisabledAlgs` and only remove MD5 from these properties. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2044980058 From adinn at openjdk.org Tue Apr 15 16:06:47 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 15 Apr 2025 16:06:47 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com> <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com> Message-ID: On Tue, 15 Apr 2025 15:09:16 GMT, Ferenc Rakoczi wrote: >> @adinn Hi, Andrew, >> I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review! > >> @ferakocz >> >> Hi Ferenc, >> >> Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR. > > No problem , it was easy to make the changes. Thanks again! @ferakocz I reran test jtreg:test/jdk/sun/security/provider/acvp/Launcher.java and hit a Java assertion: >> ML-KEM-512 encapsulation 1 STDERR: java.lang.AssertionError at java.base/com.sun.crypto.provider.ML_KEM.twelve2Sixteen(ML_KEM.java:1371) at java.base/com.sun.crypto.provider.ML_KEM.decodePoly(ML_KEM.java:1408) at java.base/com.sun.crypto.provider.ML_KEM.decodeVector(ML_KEM.java:1337) at java.base/com.sun.crypto.provider.ML_KEM.kPkeEncrypt(ML_KEM.java:712) at java.base/com.sun.crypto.provider.ML_KEM.encapsulate(ML_KEM.java:555) at java.base/com.sun.crypto.provider.ML_KEM_Impls$K.implEncapsulate(ML_KEM_Impls.java:134) at java.base/sun.security.provider.NamedKEM$KeyConsumerImpl.engineEncapsulate(NamedKEM.java:124) at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:265) at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:225) at ML_KEM_Test.encapDecapTest(ML_KEM_Test.java:98) at ML_KEM_Test.run(ML_KEM_Test.java:41) at Launcher.run(Launcher.java:160) at Launcher.main(Launcher.java:122) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1447) JavaTest Message: Test threw exception: java.lang.AssertionError JavaTest Message: shutting down test The offending code is this: private void twelve2Sixteen(byte[] condensed, int index, short[] parsed, int parsedLength) { int i = parsedLength / 64; int remainder = parsedLength - i * 64; if (remainder != 0) { i++; } assert (((remainder != 0) && (remainder != 48)) || <== assert here index + i * 96 > condensed.length); I believe the logic is reversed here i.e. it should be: assert ((remainder == 0) || (remainder == 48)) && index + i * 96 <= condensed.length); Does that sound right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2806628550 From fferrari at openjdk.org Tue Apr 15 16:06:54 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Tue, 15 Apr 2025 16:06:54 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <2jdzgr96PyMNn1jLpRcxgMZQlfMZpyXm1FxisjdQzBo=.58ec60c8-fb17-47fd-85f1-d30eb12f98dd@github.com> Message-ID: On Tue, 15 Apr 2025 13:23:06 GMT, Martin Balao wrote: >> I like this idea but the downside I see is that we would need string comparison in `P11KDF::getDerivedKeyType` to allow TLS keys. What if we merge all `PCKK_TLSPREMASTER`, `PCKK_TLSRSAPREMASTER` and `PCKK_TLSMASTER` into `PCKK_TLSKEY` and then do the translation to `CKK_GENERIC_SECRET` as needed? This will also help with the new Tls* keys that I am planning to add to the map. > > BTW, I don't like the partial "Tls" string comparison much because it's making an assumption about the algorithm name. A new `PCKK_TLSKEY` pseudo key type looks good to me. Alternatively, and just thinking out loud, how about introducing a new `TlsKeyInfo` and using `ki instanceof TlsKeyInfo` in `P11KDF::getDerivedKeyType`? Perhaps we could also add a new `KeyInfo.supportsHKDF` boolean field and store that information in the map, replacing the whole `P11KDF::getDerivedKeyType` call by a `ki.supportsHKDF` check. This would also solve the `PBEWithHmacSHA224AndAES_256` case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2044984104 From abarashev at openjdk.org Tue Apr 15 16:10:46 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 15 Apr 2025 16:10:46 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v4] In-Reply-To: References: Message-ID: <11-V1fB3JOWQMiMuT6ahw_CNwz3XOVMp2zrm9kdNHuc=.9ba19223-4fed-432e-8892-bf18f08339a7@github.com> > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Only remove MD5 from config properties. Fix a typo. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/9d2a7743..7a7bb00f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=02-03 Stats: 16 lines in 1 file changed: 4 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From mbalao at openjdk.org Tue Apr 15 17:48:48 2025 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 15 Apr 2025 17:48:48 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <2jdzgr96PyMNn1jLpRcxgMZQlfMZpyXm1FxisjdQzBo=.58ec60c8-fb17-47fd-85f1-d30eb12f98dd@github.com> Message-ID: <7qu2m_URjjlWaOpuY0m2ykS_7aMcgzl7X_HN3vhfSZE=.dcf050da-69ff-413e-a071-2cb425a4ca3d@github.com> On Tue, 15 Apr 2025 16:04:26 GMT, Francisco Ferrari Bihurriet wrote: >> BTW, I don't like the partial "Tls" string comparison much because it's making an assumption about the algorithm name. > > A new `PCKK_TLSKEY` pseudo key type looks good to me. Alternatively, and just thinking out loud, how about introducing a new `TlsKeyInfo` and using `ki instanceof TlsKeyInfo` in `P11KDF::getDerivedKeyType`? > > Perhaps we could also add a new `KeyInfo.supportsHKDF` boolean field and store that information in the map, replacing the whole `P11KDF::getDerivedKeyType` call by a `ki.supportsHKDF` check. This would also solve the `PBEWithHmacSHA224AndAES_256` case. `KeyInfo.supportsHKDF` could be a valid approach. My only concern would be overloading the map/map-objects with information that is specific to each use of a key type. For example, the same criteria could be applied to store whether a key is suitable for `C_CreateObject` in `P11SecretKeyFactory::createKey`. What I liked about storing the key gen mech is that we have different users benefiting from the same information. If there is interest in exploring this idea, I can propose something. I liked the `TlsKeyInfo` idea to remove `PCKK_TLS*` completely. We can create these keys and assign GENERIC, same as HMACKeyInfo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2045160880 From abarashev at openjdk.org Tue Apr 15 17:51:34 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 15 Apr 2025 17:51:34 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v5] In-Reply-To: References: Message-ID: > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Replace hard-coded certs with dynamically generated ones ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/7a7bb00f..86874f33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=03-04 Stats: 335 lines in 1 file changed: 92 ins; 225 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From abarashev at openjdk.org Tue Apr 15 17:51:36 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 15 Apr 2025 17:51:36 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v3] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 14:30:22 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Copyright > > test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 57: > >> 55: // Certificates and keys used in the test. >> 56: // Certificates are signed with signature using MD5WithRSA algorithm. >> 57: static String trusedCertStr = > > We try to avoid hard-coding certificates in tests - can you create these certs as part of a test setup using keytool instead? Done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2045163151 From duke at openjdk.org Tue Apr 15 18:02:43 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 15 Apr 2025 18:02:43 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v18] In-Reply-To: References: Message-ID: > java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc. > > image > > > > NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page. Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: 8328914: Document the java.security.debug property in javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23569/files - new: https://git.openjdk.org/jdk/pull/23569/files/dc7f34fa..f53973f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=16-17 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23569/head:pull/23569 PR: https://git.openjdk.org/jdk/pull/23569 From duke at openjdk.org Tue Apr 15 18:18:36 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 15 Apr 2025 18:18:36 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11] In-Reply-To: References: Message-ID: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com> > By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Fixed asserts. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23663/files - new: https://git.openjdk.org/jdk/pull/23663/files/b6b3155e..3c3bca61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=09-10 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663 PR: https://git.openjdk.org/jdk/pull/23663 From duke at openjdk.org Tue Apr 15 18:23:51 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 15 Apr 2025 18:23:51 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com> <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com> Message-ID: On Tue, 15 Apr 2025 15:09:16 GMT, Ferenc Rakoczi wrote: >> @adinn Hi, Andrew, >> I think I addressed all of your comment improvement comments, in most cases I just changed them as you suggested. Thanks a lot for the thorough review! > >> @ferakocz >> >> Hi Ferenc, >> >> Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR. > > No problem , it was easy to make the changes. Thanks again! > @ferakocz I reran test jtreg:test/jdk/sun/security/provider/acvp/Launcher.java and hit a Java assertion: > > ``` > >> ML-KEM-512 encapsulation > 1 STDERR: > java.lang.AssertionError > at java.base/com.sun.crypto.provider.ML_KEM.twelve2Sixteen(ML_KEM.java:1371) > at java.base/com.sun.crypto.provider.ML_KEM.decodePoly(ML_KEM.java:1408) > at java.base/com.sun.crypto.provider.ML_KEM.decodeVector(ML_KEM.java:1337) > at java.base/com.sun.crypto.provider.ML_KEM.kPkeEncrypt(ML_KEM.java:712) > at java.base/com.sun.crypto.provider.ML_KEM.encapsulate(ML_KEM.java:555) > at java.base/com.sun.crypto.provider.ML_KEM_Impls$K.implEncapsulate(ML_KEM_Impls.java:134) > at java.base/sun.security.provider.NamedKEM$KeyConsumerImpl.engineEncapsulate(NamedKEM.java:124) > at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:265) > at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:225) > at ML_KEM_Test.encapDecapTest(ML_KEM_Test.java:98) > at ML_KEM_Test.run(ML_KEM_Test.java:41) > at Launcher.run(Launcher.java:160) > at Launcher.main(Launcher.java:122) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1447) > > JavaTest Message: Test threw exception: java.lang.AssertionError > JavaTest Message: shutting down test > ``` > > The offending code is this: > > ``` > private void twelve2Sixteen(byte[] condensed, int index, > short[] parsed, int parsedLength) { > int i = parsedLength / 64; > int remainder = parsedLength - i * 64; > if (remainder != 0) { > i++; > } > assert (((remainder != 0) && (remainder != 48)) || <== assert here > index + i * 96 > condensed.length); > ``` > > I believe the logic is reversed here i.e. it should be: > > ``` > assert ((remainder == 0) || (remainder == 48)) && > index + i * 96 <= condensed.length); > ``` > > Does that sound right? Aarrrrgh, yes. I forgot to negate that condition when I went from throwing an exception to assert, and I also thought, incorrectly, that -ea would enable my assertions when I tested :-( . Thanks a lot for catching it! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2807096779 From valeriep at openjdk.org Tue Apr 15 18:23:44 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 15 Apr 2025 18:23:44 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v4] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 15:31:38 GMT, Francisco Ferrari Bihurriet wrote: > Looks good to me, but please note I'm not a Reviewer. Thanks much for the detailed review and suggestions~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/24068#issuecomment-2807097351 From mullan at openjdk.org Tue Apr 15 18:24:49 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 15 Apr 2025 18:24:49 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v18] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 18:02:43 GMT, Koushik Muthukrishnan Thirupattur wrote: >> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc. >> >> image >> >> >> >> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8328914: Document the java.security.debug property in javadoc Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23569#pullrequestreview-2769372776 From fferrari at openjdk.org Tue Apr 15 18:38:20 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Tue, 15 Apr 2025 18:38:20 GMT Subject: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions [v2] In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> Message-ID: <4Wwny0n2QnVHXCN_eK35cxWvcoD1NgaIw64U_GPtO_E=.c67c1cc9-5617-4b02-93ea-075c29914317@github.com> > Hi, this is a proposal to fix 8352728. > > The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following: > > 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`. > 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`. > > #### Windows Case > > @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf: > > * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`: > * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473") > * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288") > * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop) > * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/java.base/windows/native/libjava/c... Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Do minor adjustments Update copyright year, improve comments and use File::toPath to convert back to Path. - Merge openjdk/master into JDK-8352728 - 8352728: InternalError loading java.security due to Windows parent folder permissions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24465/files - new: https://git.openjdk.org/jdk/pull/24465/files/308479dd..a8c5ca74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24465&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24465&range=00-01 Stats: 206256 lines in 690 files changed: 21802 ins; 181929 del; 2525 mod Patch: https://git.openjdk.org/jdk/pull/24465.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24465/head:pull/24465 PR: https://git.openjdk.org/jdk/pull/24465 From mullan at openjdk.org Tue Apr 15 18:40:59 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 15 Apr 2025 18:40:59 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v15] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 19:37:44 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> toString, exportData, spec in HPKEParameters must have algorithm identifiers specified > > src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 136: > >> 134: * {@snippet lang=java class="PackageSnippets" region="hpke-spec-example"} >> 135: * >> 136: * @implNote > > Making this implementation specific means that other providers could in theory choose different defaults, which reduces compatibility but an application could never be sure, or even know if this is for algorithms in RFC 9180. These are probably the most reasonable defaults for RFC 9180 compliant implementations. Did you consider making these defaults a requirement of HPKE implementations? I also wonder if "HPKE" is too general. If there is ever a new HPKE spec with say a new KEM or KDF algorithm for EC/XDH keys, would it be called "HPKE2"? Consider adding a String or Enum argument to `of()` with the name of the profile, ex "RFC9180". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2045238642 From mullan at openjdk.org Tue Apr 15 18:40:59 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 15 Apr 2025 18:40:59 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v15] In-Reply-To: References: Message-ID: On Fri, 11 Apr 2025 20:41:13 GMT, Weijun Wang wrote: >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >> ![hpke](https://github.com/user-attachments/assets/4edc5d08-ef52-44c5-b5d5-e8890c2d2fce) > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > toString, exportData, spec in HPKEParameters must have algorithm identifiers specified src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 103: > 101: return impl.aead.cipher.getBlockSize(); > 102: } else { > 103: throw new IllegalStateException("No AEAD cipher"); Should this return 0 instead per spec? The spec is not defined to throw `IllegalStateException`. src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 112: > 110: return impl.aead.cipher.getOutputSize(inputLen); > 111: } else { > 112: throw new IllegalStateException("No AEAD cipher"); The spec is not defined to throw `IllegalStateException`. src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 156: > 154: impl = new Impl(opmode); > 155: if (!(key instanceof AsymmetricKey ak)) { > 156: throw new InvalidKeyException("Not asymmetric key"); Nit: "Not an asymmetric key" src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 178: > 176: AlgorithmParameters params, SecureRandom random) > 177: throws InvalidAlgorithmParameterException { > 178: throw new InvalidAlgorithmParameterException( Could you support this method by extracting the `HKDFParameterSpec` from the `AlgorithmParameters`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2044491111 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2044497136 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2044506212 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2044514837 From abarashev at openjdk.org Tue Apr 15 20:43:23 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 15 Apr 2025 20:43:23 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v6] In-Reply-To: References: Message-ID: > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: To improve performance we only update when necessary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/86874f33..e04bda10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=04-05 Stats: 23 lines in 3 files changed: 11 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From mark.reinhold at oracle.com Tue Apr 15 20:54:24 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 15 Apr 2025 20:54:24 +0000 Subject: New candidate JEP: 510: Key Derivation Function API Message-ID: <20250415205424.3AC39811ADB@eggemoggin.niobe.net> https://openjdk.org/jeps/510 Summary: Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. - Mark From abarashev at openjdk.org Tue Apr 15 21:59:56 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 15 Apr 2025 21:59:56 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v7] In-Reply-To: References: Message-ID: > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Refactor existing LocalSupportedAlgs code. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/e04bda10..de86b443 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=05-06 Stats: 158 lines in 7 files changed: 32 ins; 114 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From abarashev at openjdk.org Tue Apr 15 22:05:12 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 15 Apr 2025 22:05:12 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v8] In-Reply-To: References: Message-ID: <0zSavgHYD9d9ytF16hLEMz8U7B3iA8jtLJbKiU5wK_4=.120c80a9-cdf4-46ec-b5f3-c3b8ff35e668@github.com> > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Remove redundant brackets ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/de86b443..8e56207a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From valeriep at openjdk.org Tue Apr 15 23:01:56 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 15 Apr 2025 23:01:56 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v5] In-Reply-To: References: Message-ID: > As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings. > > Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: minor comment and copyright year update. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24068/files - new: https://git.openjdk.org/jdk/pull/24068/files/e42e4402..34e5d4e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=03-04 Stats: 6 lines in 3 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24068/head:pull/24068 PR: https://git.openjdk.org/jdk/pull/24068 From abarashev at openjdk.org Wed Apr 16 04:23:22 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 16 Apr 2025 04:23:22 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v9] In-Reply-To: References: Message-ID: > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Remove redundant updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/8e56207a..dd089425 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=07-08 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From abarashev at openjdk.org Wed Apr 16 04:28:19 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 16 Apr 2025 04:28:19 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v10] In-Reply-To: References: Message-ID: > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with two additional commits since the last revision: - Remove one more newline - Remove extra newline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/dd089425..ce9404de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From adinn at openjdk.org Wed Apr 16 09:55:46 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 16 Apr 2025 09:55:46 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11] In-Reply-To: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com> References: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com> Message-ID: On Tue, 15 Apr 2025 18:18:36 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed asserts. @ferakocz I reran the test and the perf test and all appears to be good. Nice work! ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23663#pullrequestreview-2771908852 From jpai at openjdk.org Wed Apr 16 11:30:01 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 16 Apr 2025 11:30:01 GMT Subject: Integrated: Merge ed30fce6df57b1cbf7a6efebabc3558550f8ec16 Message-ID: This brings in the CPU25_04 changes into the master branch. ------------- Commit messages: The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/24683/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24683.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24683/head:pull/24683 PR: https://git.openjdk.org/jdk/pull/24683 From dfuchs at openjdk.org Wed Apr 16 11:30:01 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 16 Apr 2025 11:30:01 GMT Subject: Integrated: Merge ed30fce6df57b1cbf7a6efebabc3558550f8ec16 In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 11:20:36 GMT, Jaikiran Pai wrote: > This brings in the CPU25_04 changes into the master branch. LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24683#pullrequestreview-2772164693 From jpai at openjdk.org Wed Apr 16 11:30:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 16 Apr 2025 11:30:02 GMT Subject: Integrated: Merge ed30fce6df57b1cbf7a6efebabc3558550f8ec16 In-Reply-To: References: Message-ID: <5aoSWv3V3dVlk0FcmcAt3FpvLoE6CxWrTpYmPU5wyfw=.99fdb614-63cc-4cef-8442-b9d55f328d37@github.com> On Wed, 16 Apr 2025 11:20:36 GMT, Jaikiran Pai wrote: > This brings in the CPU25_04 changes into the master branch. Thank you Daniel for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24683#issuecomment-2809280611 From jpai at openjdk.org Wed Apr 16 11:30:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 16 Apr 2025 11:30:02 GMT Subject: Integrated: Merge ed30fce6df57b1cbf7a6efebabc3558550f8ec16 In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 11:20:36 GMT, Jaikiran Pai wrote: > This brings in the CPU25_04 changes into the master branch. This pull request has now been integrated. Changeset: c6243fc2 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/c6243fc27fafb1ff89f8610ead3acd87030caf95 Stats: 301 lines in 11 files changed: 223 ins; 25 del; 53 mod Merge Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/24683 From duke at openjdk.org Wed Apr 16 11:40:49 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 16 Apr 2025 11:40:49 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v7] In-Reply-To: References: <5j4hyPmpvOzIValSb9YGR8fSrL14z-zJikzUHr5kSnA=.131af348-ddc2-4b2a-bca3-8a22f022a244@github.com> <84xoy6ZxXhJmi5NyuTdJ_cF4QSuhS8e94-kXpvic1AQ=.6894bece-9f7d-4f95-b60e-2efce0b8f7ac@github.com> Message-ID: On Tue, 15 Apr 2025 18:21:00 GMT, Ferenc Rakoczi wrote: >>> @ferakocz >>> >>> Hi Ferenc, >>> >>> Sorry, but I still had a few comments to add to the KyberNTTMult routine to clarify exactly how the load, compute and store operations relate to the original Java source. That's the only remaining code that I felt needed further clarification for maintainers. So, after you work through them I can approve the PR. >> >> No problem , it was easy to make the changes. Thanks again! > >> @ferakocz I reran test jtreg:test/jdk/sun/security/provider/acvp/Launcher.java and hit a Java assertion: >> >> ``` >> >> ML-KEM-512 encapsulation >> 1 STDERR: >> java.lang.AssertionError >> at java.base/com.sun.crypto.provider.ML_KEM.twelve2Sixteen(ML_KEM.java:1371) >> at java.base/com.sun.crypto.provider.ML_KEM.decodePoly(ML_KEM.java:1408) >> at java.base/com.sun.crypto.provider.ML_KEM.decodeVector(ML_KEM.java:1337) >> at java.base/com.sun.crypto.provider.ML_KEM.kPkeEncrypt(ML_KEM.java:712) >> at java.base/com.sun.crypto.provider.ML_KEM.encapsulate(ML_KEM.java:555) >> at java.base/com.sun.crypto.provider.ML_KEM_Impls$K.implEncapsulate(ML_KEM_Impls.java:134) >> at java.base/sun.security.provider.NamedKEM$KeyConsumerImpl.engineEncapsulate(NamedKEM.java:124) >> at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:265) >> at java.base/javax.crypto.KEM$Encapsulator.encapsulate(KEM.java:225) >> at ML_KEM_Test.encapDecapTest(ML_KEM_Test.java:98) >> at ML_KEM_Test.run(ML_KEM_Test.java:41) >> at Launcher.run(Launcher.java:160) >> at Launcher.main(Launcher.java:122) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) >> at java.base/java.lang.Thread.run(Thread.java:1447) >> >> JavaTest Message: Test threw exception: java.lang.AssertionError >> JavaTest Message: shutting down test >> ``` >> >> The offending code is this: >> >> ``` >> private void twelve2Sixteen(byte[] condensed, int index, >> short[] parsed, int parsedLength) { >> int i = parsedLength / 64; >> int remainder = parsedLength - i * 64; >> if (remainder != 0) { >> i++; >> } >> assert (((remainder != 0) && (remainder != 48)) || <== assert here >> index + i * 96 > condensed.length); >> ``` >> >> I believe the logic is reversed here i.e. it should be: >> >> ``` >> assert ((remainder == 0) || (remainder == 48)) && >> index + i * 96 <= condensed.length); >> ``` >> >> Does that sound right? > > Aarrrrgh, yes. I forgot to negate that condition when I went from throwing an exception to assert, and I also thought, incorrectly, that -ea would enable my assertions when I tested :-( . > Thanks a lot for catching it! > @ferakocz I reran the test and the perf test and all appears to be good. Nice work! @adinn Thanks, Andrew, for all the help, it really looks nicer than it looked before your review! Would you /sponsor the integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23663#issuecomment-2809306397 From duke at openjdk.org Wed Apr 16 12:38:54 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 16 Apr 2025 12:38:54 GMT Subject: Integrated: 8349721: Add aarch64 intrinsics for ML-KEM In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 13:53:30 GMT, Ferenc Rakoczi wrote: > By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. This pull request has now been integrated. Changeset: 465c8e65 Author: Ferenc Rakoczi Committer: Andrew Dinn URL: https://git.openjdk.org/jdk/commit/465c8e658356f658ee04397936f555f6bdffc3c2 Stats: 2569 lines in 20 files changed: 2420 ins; 46 del; 103 mod 8349721: Add aarch64 intrinsics for ML-KEM Reviewed-by: adinn ------------- PR: https://git.openjdk.org/jdk/pull/23663 From abarashev at openjdk.org Wed Apr 16 14:57:20 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 16 Apr 2025 14:57:20 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v11] In-Reply-To: References: Message-ID: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com> > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Further optimization: remove unnecessary updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/ce9404de..6956caff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=09-10 Stats: 8 lines in 3 files changed: 2 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From valeriep at openjdk.org Wed Apr 16 18:55:43 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 16 Apr 2025 18:55:43 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Mon, 14 Apr 2025 19:01:45 GMT, Francisco Ferrari Bihurriet wrote: >> As far as I understand it, `HmacSHA256` is blocked, but not `PBEWithHmacSHA224AndAES_256`. >> >> ### `HmacSHA256` >> >> * Has an `HMACKeyInfo` entry with the following non-static fields: >> * `KeyInfo.algo` = `"HmacSHA256"` >> * `KeyInfo.keyType` = `CKK_GENERIC_SECRET` >> * `KeyInfo.keyGenMech` = `CK_UNAVAILABLE_INFORMATION` >> * `HMACKeyInfo.mech` = `CKM_SHA256_HMAC` >> * `HMACKeyInfo.keyLen` = `256` >> >> Given `ki.keyType` is `CKK_GENERIC_SECRET` and `alg` is `HmacSHA256`, in `P11HKDF::getDerivedKeyType` it will enter the first `case` but not the `if`. So it will finally throw the expected exception: >> >> >> InvalidAlgorithmParameterException("A key of algorithm 'HmacSHA256' is not valid for derivation.") >> >> >> ### `PBEWithHmacSHA224AndAES_256` >> >> * Has an `AESPBEKeyInfo` entry with the following non-static fields: >> * `KeyInfo.algo` = `"PBEWithHmacSHA224AndAES_256"` >> * `KeyInfo.keyType` = `CKK_AES` >> * `KeyInfo.keyGenMech` = `CK_UNAVAILABLE_INFORMATION` >> * `PBEKeyInfo.kdfMech` = `CKM_PKCS5_PBKD2` >> * `PBEKeyInfo.prfMech` = `CKP_PKCS5_PBKD2_HMAC_SHA224` >> * `PBEKeyInfo.keyLen` = `256` >> * `PBEKeyInfo.extraAttrs` = `new CK_ATTRIBUTE[] { CK_ATTRIBUTE.ENCRYPT_TRUE }` >> >> Given `ki.keyType` is `CKK_AES`, in `P11HKDF::getDerivedKeyType` it will enter the first `case` and also the `if`, returning `CKK_AES`. Later, in `P11KeyGenerator::checkKeySize(..., Token token)`, `P11KeyGenerator::getSupportedRange` will return `null`, because `ki.keyGenMech` is `CK_UNAVAILABLE_INFORMATION`. This will make `P11KeyGenerator::checkKeySize(..., CK_MECHANISM_INFO range)` enter the `default` case, and finally return the unmodified `keySize`. No exception is thrown, unless I'm missing something. > > Also, we could save one of the `if` conditions by creating a separate `case` for `CKK_GENERIC_SECRET`: > > > switch ((int) ki.keyType) { > case (int) CKK_DES, (int) CKK_DES3, (int) CKK_AES, (int) CKK_RC4, > (int) CKK_BLOWFISH, (int) CKK_CHACHA20 -> { > return ki.keyType; > } > case (int) CKK_GENERIC_SECRET -> { > if (alg.equalsIgnoreCase("Generic")) { > return ki.keyType; > } > } > // [...] > } > > > In my view, this is quicker to understand, what do you think? Yes, I much prefer this idea of separate case for `CKK_GENERIC_SECRET`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2047543388 From mullan at openjdk.org Wed Apr 16 19:21:42 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 16 Apr 2025 19:21:42 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v11] In-Reply-To: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com> References: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com> Message-ID: On Wed, 16 Apr 2025 14:57:20 GMT, Artur Barashev wrote: >> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: >> >> >> Any endpoint receiving any certificate which it would need to >> validate using any signature algorithm using an MD5 hash MUST abort >> the handshake with a "bad_certificate" alert. >> >> >> >> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. >> >> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. >> >> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Further optimization: remove unnecessary updates Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24425#pullrequestreview-2773610308 From vlivanov at openjdk.org Wed Apr 16 19:26:00 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 16 Apr 2025 19:26:00 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11] In-Reply-To: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com> References: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com> Message-ID: On Tue, 15 Apr 2025 18:18:36 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed asserts. src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 717: > 715: desc_len = (int)strlen(_cpu_desc); > 716: snprintf(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len, " %s", _features_string); > 717: fprintf(stderr, "_features_string = \"%s\"", _features_string); Was this line added by mistake? Looks like a leftover. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2047606222 From mpowers at openjdk.org Wed Apr 16 22:05:41 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 16 Apr 2025 22:05:41 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v11] In-Reply-To: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com> References: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com> Message-ID: On Wed, 16 Apr 2025 14:57:20 GMT, Artur Barashev wrote: >> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: >> >> >> Any endpoint receiving any certificate which it would need to >> validate using any signature algorithm using an MD5 hash MUST abort >> the handshake with a "bad_certificate" alert. >> >> >> >> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. >> >> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. >> >> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Further optimization: remove unnecessary updates test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 1: > 1: /* Import of `java.security.cert.Certificate` on line 54 is unnecessary. Yea I know it's not in your code. test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 131: > 129: > 130: // create a key store > 131: KeyStore ks = KeyStore.getInstance("JKS"); I wonder if PKCS12 would be a better choice in the long run. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2047831632 PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2047829144 From mbalao at openjdk.org Thu Apr 17 00:22:14 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 17 Apr 2025 00:22:14 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v3] In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- Martin Balao has updated the pull request incrementally with two additional commits since the last revision: - TLS keys added to the map. - Key type check refactoring (derivation). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24526/files - new: https://git.openjdk.org/jdk/pull/24526/files/8feb31ea..89d15ba9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=01-02 Stats: 66 lines in 4 files changed: 35 ins; 15 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24526/head:pull/24526 PR: https://git.openjdk.org/jdk/pull/24526 From mbalao at openjdk.org Thu Apr 17 00:27:42 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 17 Apr 2025 00:27:42 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v3] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 17 Apr 2025 00:22:14 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - TLS keys added to the map. > - Key type check refactoring (derivation). I've implemented the `TLSKeyInfo` suggestion and added all Tls* keys to the map ?after verifying they reach KDF::deriveKey in #24393. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24526#issuecomment-2811313579 From valeriep at openjdk.org Thu Apr 17 00:49:49 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 17 Apr 2025 00:49:49 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v3] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: <5FchScXLyAkOtEEcPButb40icYCwsUVgOgpmOah8NHg=.f7d51e64-c004-4dea-aaaf-4b4ab5a085d2@github.com> On Thu, 17 Apr 2025 00:22:14 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with two additional commits since the last revision: > > - TLS keys added to the map. > - Key type check refactoring (derivation). src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 224: > 222: if (e.match(CKR_KEY_SIZE_RANGE)) { > 223: throw new InvalidAlgorithmParameterException("Invalid key " + > 224: "size for algorithm '" + alg + "'.", e); nit: include the requested key size in the exception message? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2048004364 From abarashev at openjdk.org Thu Apr 17 01:28:46 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 17 Apr 2025 01:28:46 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v11] In-Reply-To: References: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com> Message-ID: <-nSFuBlKNGgf34rtMgoX5sLsxz826PUGHBMruYstI9o=.dba535a6-fd57-49f8-b3b1-9daa50f851ad@github.com> On Wed, 16 Apr 2025 22:01:04 GMT, Mark Powers wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Further optimization: remove unnecessary updates > > test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java line 131: > >> 129: >> 130: // create a key store >> 131: KeyStore ks = KeyStore.getInstance("JKS"); > > I wonder if PKCS12 would be a better choice in the long run. Updated, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2048041727 From abarashev at openjdk.org Thu Apr 17 01:36:30 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 17 Apr 2025 01:36:30 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v12] In-Reply-To: References: Message-ID: > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Update KeyStore type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24425/files - new: https://git.openjdk.org/jdk/pull/24425/files/6956caff..9146ab74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24425&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24425/head:pull/24425 PR: https://git.openjdk.org/jdk/pull/24425 From mbalao at openjdk.org Thu Apr 17 02:50:42 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 17 Apr 2025 02:50:42 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v3] In-Reply-To: <5FchScXLyAkOtEEcPButb40icYCwsUVgOgpmOah8NHg=.f7d51e64-c004-4dea-aaaf-4b4ab5a085d2@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <5FchScXLyAkOtEEcPButb40icYCwsUVgOgpmOah8NHg=.f7d51e64-c004-4dea-aaaf-4b4ab5a085d2@github.com> Message-ID: On Thu, 17 Apr 2025 00:47:00 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with two additional commits since the last revision: >> >> - TLS keys added to the map. >> - Key type check refactoring (derivation). > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 224: > >> 222: if (e.match(CKR_KEY_SIZE_RANGE)) { >> 223: throw new InvalidAlgorithmParameterException("Invalid key " + >> 224: "size for algorithm '" + alg + "'.", e); > > nit: include the requested key size in the exception message? Sounds good! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2048100736 From mbalao at openjdk.org Thu Apr 17 03:14:14 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 17 Apr 2025 03:14:14 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Inform key sizes in the exception when failing check. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24526/files - new: https://git.openjdk.org/jdk/pull/24526/files/89d15ba9..1ffde71f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=02-03 Stats: 14 lines in 2 files changed: 4 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/24526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24526/head:pull/24526 PR: https://git.openjdk.org/jdk/pull/24526 From mbalao at openjdk.org Thu Apr 17 04:29:46 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 17 Apr 2025 04:29:46 GMT Subject: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions [v2] In-Reply-To: <4Wwny0n2QnVHXCN_eK35cxWvcoD1NgaIw64U_GPtO_E=.c67c1cc9-5617-4b02-93ea-075c29914317@github.com> References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> <4Wwny0n2QnVHXCN_eK35cxWvcoD1NgaIw64U_GPtO_E=.c67c1cc9-5617-4b02-93ea-075c29914317@github.com> Message-ID: On Tue, 15 Apr 2025 18:38:20 GMT, Francisco Ferrari Bihurriet wrote: >> Hi, this is a proposal to fix 8352728. >> >> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following: >> >> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`. >> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`. >> >> #### Windows Case >> >> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf: >> >> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`: >> * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473") >> * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288") >> * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop) >> * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja... > > Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Do minor adjustments > > Update copyright year, improve comments and use File::toPath to convert > back to Path. > - Merge openjdk/master into JDK-8352728 > - 8352728: InternalError loading java.security due to Windows parent folder permissions Looks like `File::getCanonicalPath` is more resilient to canonicalization and resolution failures. This observation makes me wonder the following: 1) Can a normalization failure (e.g. return of a partially normalized path) affect relative includes? 2) Can a failure in symlinks resolution (which seems to be ignored) affect relative includes? Startup will fail if the included file is not found, which is a safe behavior. The problematic scenario would be one in which a different file exists in a location that uses the partially normalized or resolved path as a base, and is not what the "include" properties writer intended. While unlikely, I want to understand if this is possible and a downside of using `File::getCanonicalPath`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-2811705669 From duke at openjdk.org Thu Apr 17 09:43:03 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 17 Apr 2025 09:43:03 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11] In-Reply-To: References: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com> Message-ID: On Wed, 16 Apr 2025 19:22:51 GMT, Vladimir Ivanov wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed asserts. > > src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 717: > >> 715: desc_len = (int)strlen(_cpu_desc); >> 716: snprintf(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len, " %s", _features_string); >> 717: fprintf(stderr, "_features_string = \"%s\"", _features_string); > > Was this line added by mistake? Looks like a leftover. @iwanowww Oooops, yes. Addressed in [https://github.com/openjdk/jdk/pull/24717](url) together with another forgotten (though not strictly necessary) change. Thanks for catching it! Could you review that (really short) PR? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2048605624 From adinn at openjdk.org Thu Apr 17 09:51:04 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 17 Apr 2025 09:51:04 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11] In-Reply-To: References: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com> Message-ID: <31MkMkCnISHqrdr-puFzzw2MQB2ka-fIqnDM0ryDqhs=.fd660382-e126-45f1-a007-2b3b4b37a69f@github.com> On Thu, 17 Apr 2025 09:40:02 GMT, Ferenc Rakoczi wrote: >> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 717: >> >>> 715: desc_len = (int)strlen(_cpu_desc); >>> 716: snprintf(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len, " %s", _features_string); >>> 717: fprintf(stderr, "_features_string = \"%s\"", _features_string); >> >> Was this line added by mistake? Looks like a leftover. > > @iwanowww Oooops, yes. Addressed in [https://github.com/openjdk/jdk/pull/24717](https://github.com/openjdk/jdk/pull/24717) together with another forgotten (though not strictly necessary) change. Thanks for catching it! > Could you review that (really short) PR? @ferakocz That link has the right label but leads to the wrong place. It should point [here](https://github.com/openjdk/jdk/pull/24717). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2048618862 From adinn at openjdk.org Thu Apr 17 09:55:59 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 17 Apr 2025 09:55:59 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v11] In-Reply-To: References: <7prG6bk5z2Rqfe1JS-AoDWZH6SgqG4IH0avBr4v7CKQ=.e08451b5-9aba-4e5b-9d1d-89b8e9866f19@github.com> Message-ID: On Wed, 16 Apr 2025 19:22:51 GMT, Vladimir Ivanov wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed asserts. > > src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 717: > >> 715: desc_len = (int)strlen(_cpu_desc); >> 716: snprintf(_cpu_desc + desc_len, CPU_DETAILED_DESC_BUF_SIZE - desc_len, " %s", _features_string); >> 717: fprintf(stderr, "_features_string = \"%s\"", _features_string); > > Was this line added by mistake? Looks like a leftover. @iwanowww Thanks for the heads up! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2048625305 From myankelevich at openjdk.org Thu Apr 17 09:57:06 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 17 Apr 2025 09:57:06 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java Message-ID: * Changed the test to use scratch directory * Cleaned up the imports ------------- Commit messages: - JDK-8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java Changes: https://git.openjdk.org/jdk/pull/24718/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24718&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8183348 Stats: 25 lines in 1 file changed: 1 ins; 6 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/24718.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24718/head:pull/24718 PR: https://git.openjdk.org/jdk/pull/24718 From mullan at openjdk.org Thu Apr 17 12:36:49 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 17 Apr 2025 12:36:49 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v12] In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 01:36:30 GMT, Artur Barashev wrote: >> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: >> >> >> Any endpoint receiving any certificate which it would need to >> validate using any signature algorithm using an MD5 hash MUST abort >> the handshake with a "bad_certificate" alert. >> >> >> >> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. >> >> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. >> >> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Update KeyStore type Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24425#pullrequestreview-2775576381 From abarashev at openjdk.org Thu Apr 17 13:26:08 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 17 Apr 2025 13:26:08 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v11] In-Reply-To: References: <2QEeNTM5qqHbFXH0mjvoVwdOes8L8PqnYH6zEtXcOq4=.5358b81c-0298-4f8d-89e7-14172a21e955@github.com> Message-ID: On Wed, 16 Apr 2025 22:03:07 GMT, Mark Powers wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Further optimization: remove unnecessary updates > > test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 1: > >> 1: /* > > Import of `java.security.cert.Certificate` on line 54 is unnecessary. Yea I know it's not in your code. Those tests are going to be re-worked soon, so I guess it all will be addressed: https://bugs.openjdk.org/browse/JDK-8353738 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24425#discussion_r2048935586 From duke at openjdk.org Thu Apr 17 13:41:52 2025 From: duke at openjdk.org (duke) Date: Thu, 17 Apr 2025 13:41:52 GMT Subject: RFR: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled [v12] In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 01:36:30 GMT, Artur Barashev wrote: >> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: >> >> >> Any endpoint receiving any certificate which it would need to >> validate using any signature algorithm using an MD5 hash MUST abort >> the handshake with a "bad_certificate" alert. >> >> >> >> The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. >> >> While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. >> >> The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Update KeyStore type @artur-oracle Your change (at version 9146ab740443569be06de1ba37a151d34a0c1614) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24425#issuecomment-2812967568 From abarashev at openjdk.org Thu Apr 17 13:48:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 17 Apr 2025 13:48:54 GMT Subject: Integrated: 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 19:05:59 GMT, Artur Barashev wrote: > MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates: > > > Any endpoint receiving any certificate which it would need to > validate using any signature algorithm using an MD5 hash MUST abort > the handshake with a "bad_certificate" alert. > > > > The bug manifests itself when older versions of protocol are supported besides TLSv1.3, such as TLSv1.2. When multiple protocol versions are supported, both client and server calculate their respective SSLSessions's "localSupportedSignAlgs" based on supported signature algorithms for all active protocols and don't update it when negotiated protocol is established. Then "localSupportedSignAlgs" list is used to validate certificate's algorithm. > > While we disable "MD5withRSA" in java.security config, MD5 algorithm should not be allowed in TLSv1.3 regardless of optional configuration. > > The underlying issue we are fixing here is not MD5-specific: when multiple TLS versions are supported, we compute local supported algorithms for ALL supported TLS versions. Thus MD5 and other algorithms that are supported in TLSv1.2 are being used when actually TLSv1.3 ends up being the negotiated protocol version. This pull request has now been integrated. Changeset: abb23828 Author: Artur Barashev Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/abb23828f9dc5f4cdb75d5b924dd6f45925102cd Stats: 482 lines in 16 files changed: 299 ins; 130 del; 53 mod 8350807: Certificates using MD5 algorithm that are disabled by default are incorrectly allowed in TLSv1.3 when re-enabled Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/24425 From coffeys at openjdk.org Thu Apr 17 15:25:36 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 17 Apr 2025 15:25:36 GMT Subject: RFR: 8350582: Correct the parsing of the ssl value in javax.net.debug [v5] In-Reply-To: References: Message-ID: > Breaking the parent JDK-8044609 JBS issue into sub tasks. > > This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced. This patch should be easier for backporting also. > > Wider corrections can be followed up via parent bug. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Add extra component coverage to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23781/files - new: https://git.openjdk.org/jdk/pull/23781/files/cb444611..65758b93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23781&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23781&range=03-04 Stats: 42 lines in 1 file changed: 18 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/23781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23781/head:pull/23781 PR: https://git.openjdk.org/jdk/pull/23781 From mullan at openjdk.org Thu Apr 17 15:26:02 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 17 Apr 2025 15:26:02 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v13] In-Reply-To: <08wmiSxvUmzEN6Xl0DRsYkf-AvWnCHjzcMuLaDL54ZY=.e33d468b-56a2-463f-b466-0aac792b4e92@github.com> References: <08wmiSxvUmzEN6Xl0DRsYkf-AvWnCHjzcMuLaDL54ZY=.e33d468b-56a2-463f-b466-0aac792b4e92@github.com> Message-ID: <30X9q11p_-KYUQCqCNYz7l6QXbJFhBEKN-T6Ci66c5E=.085c50cf-dc22-44a2-b491-76c7ff22dd4d@github.com> On Thu, 13 Mar 2025 01:15:03 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: > > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - Merge in PEMRecord as part of the API. > - Merge branch 'pem-record' into pem-merge > > # Conflicts: > # src/java.base/share/classes/java/security/PEMDecoder.java > # src/java.base/share/classes/java/security/PEMRecord.java > # src/java.base/share/classes/sun/security/util/Pem.java > # test/jdk/java/security/PEM/PEMData.java > # test/jdk/java/security/PEM/PEMDecoderTest.java > # test/jdk/java/security/PEM/PEMEncoderTest.java > - Merge branch 'master' into pem-record > > # Conflicts: > # src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java > - test fixes & cleanup > - Implement stream decoding > fix StringBuffer/Builder > X509C* changes > - ... and 51 more: https://git.openjdk.org/jdk/compare/a347ecde...106788ef src/java.base/share/classes/java/security/PEMDecoder.java line 43: > 41: > 42: /** > 43: * {@code PEMDecoder} is an immutable class for Privacy-Enhanced Mail (PEM) s/for/for decoding/ src/java.base/share/classes/java/security/PEMDecoder.java line 46: > 44: * data. PEM is a textual encoding used to store and transfer security > 45: * objects, such as asymmetric keys, certificates, and certificate revocation > 46: * lists (CRL). It is defined in RFC 1421 and RFC 7468. PEM consists of a s/CRL/CRLs/ src/java.base/share/classes/java/security/PEMDecoder.java line 51: > 49: * > 50: *

    Decoding methods return an instance of a class that matches the data > 51: * type and implements {@link DEREncodable} unless specified. The following "unless otherwise specified"? src/java.base/share/classes/java/security/PEMDecoder.java line 64: > 62: *

    If the PEM does not have a corresponding JCE object, it returns a > 63: * {@link PEMRecord}. Any PEM can be decoded into a {@code PEMRecord} if the > 64: * class is specified. Decoding a {@code PEMRecord} returns corresponding What do you mean by "Decoding a PEMRecord"? s/returns/returns a/ src/java.base/share/classes/java/security/PEMDecoder.java line 65: > 63: * {@link PEMRecord}. Any PEM can be decoded into a {@code PEMRecord} if the > 64: * class is specified. Decoding a {@code PEMRecord} returns corresponding > 65: * JCE object or throws a {@link IllegalArgumentException} if no object is s/a/an/ src/java.base/share/classes/java/security/PEMDecoder.java line 68: > 66: * available. > 67: * > 68: *

    A new immutable {@code PEMDecoder} instance is created by using Suggest rewording as ... "A `PEMDecoder` can be configured with additional options by calling ..." src/java.base/share/classes/java/security/PEMDecoder.java line 71: > 69: * {@linkplain #withFactory} and/or {@linkplain #withDecryption}. Configuring > 70: * an instance for decryption does not prevent decoding with unencrypted PEM. > 71: * Any encrypted PEM that does not use the configured password will throw an s/an/a/ src/java.base/share/classes/java/security/PEMDecoder.java line 74: > 72: * {@link SecurityException}. A decoder instance not configured with decryption > 73: * returns an {@link EncryptedPrivateKeyInfo} with encrypted PEM. > 74: * EncryptedPrivateKeyInfo methods must be used to retrieve the Put code around EncryptedPrivateKeyInfo. src/java.base/share/classes/java/security/PEMDecoder.java line 197: > 195: }; > 196: } catch (GeneralSecurityException | IOException e) { > 197: throw new IllegalArgumentException(e); Should all of these decoding issues really be treated as `IllegalArgumentException`s? I would think that general decoding issues should be thrown as checked exceptions. Runtime exceptions are typically used for serious issues, like programming errors. src/java.base/share/classes/java/security/PEMDecoder.java line 202: > 200: > 201: /** > 202: * Decodes and returns {@link DEREncodable} from the given string. s/returns/returns a/ src/java.base/share/classes/java/security/PEMDecoder.java line 210: > 208: */ > 209: public DEREncodable decode(String str) { > 210: Objects.requireNonNull(str); Missing an `@throws NullPointerException` in the spec. src/java.base/share/classes/java/security/PEMDecoder.java line 236: > 234: */ > 235: public DEREncodable decode(InputStream is) throws IOException { > 236: Objects.requireNonNull(is); Missing an `@throws NullPointerException` in the spec. src/java.base/share/classes/java/security/PEMDecoder.java line 259: > 257: * @param Class type parameter that extends {@code DEREncodable} > 258: * @param string the String containing PEM data. > 259: * @param tClass the returned object class that implementing s/implementing/implements/ src/java.base/share/classes/java/security/PEMDecoder.java line 261: > 259: * @param tClass the returned object class that implementing > 260: * {@code DEREncodable}. > 261: * @return A {@code DEREncodable} typecast to {@code tClass}. s/A/a/ src/java.base/share/classes/java/security/PEMDecoder.java line 266: > 264: */ > 265: public S decode(String string, Class tClass) { > 266: Objects.requireNonNull(string); Missing an `@throws NullPointerException` in the spec. src/java.base/share/classes/java/security/PEMDecoder.java line 282: > 280: * @param Class type parameter that extends {@code DEREncodable} > 281: * @param is an InputStream containing PEM data. > 282: * @param tClass the returned object class that implementing s/implementing/implements/ src/java.base/share/classes/java/security/PEMDecoder.java line 284: > 282: * @param tClass the returned object class that implementing > 283: * {@code DEREncodable}. > 284: * @return A {@code DEREncodable} typecast to {@code tClass} s/A/a/ src/java.base/share/classes/java/security/PEMDecoder.java line 294: > 292: public S decode(InputStream is, Class tClass) > 293: throws IOException { > 294: Objects.requireNonNull(is); Missing an `@throws NullPointerException` in the spec. src/java.base/share/classes/java/security/PEMDecoder.java line 359: > 357: } > 358: return KeyFactory.getInstance(algorithm, factory); > 359: } catch(GeneralSecurityException e){ Nit, add space after `catch` and before `{`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049174941 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049175523 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049177250 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049181342 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049181631 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049187792 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049182807 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049183464 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049156935 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049122348 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049126766 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049134047 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049166538 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049167175 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049170008 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049168852 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049169282 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049170336 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049145705 From mullan at openjdk.org Thu Apr 17 15:26:05 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 17 Apr 2025 15:26:05 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v12] In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 19:59:05 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: > > - Merge branch 'pem-merge' into pem > - merge > - Merge in PEMRecord as part of the API. > - Merge branch 'pem-record' into pem-merge > > # Conflicts: > # src/java.base/share/classes/java/security/PEMDecoder.java > # src/java.base/share/classes/java/security/PEMRecord.java > # src/java.base/share/classes/sun/security/util/Pem.java > # test/jdk/java/security/PEM/PEMData.java > # test/jdk/java/security/PEM/PEMDecoderTest.java > # test/jdk/java/security/PEM/PEMEncoderTest.java > - Merge branch 'master' into pem-record > > # Conflicts: > # src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java > - test fixes & cleanup > - Implement stream decoding > fix StringBuffer/Builder > X509C* changes > - Reorg tests data > minor fixes > - merge from pem branch > - Merge branch 'pem' into pem-record > > # Conflicts: > # src/java.base/share/classes/java/security/PEMEncoder.java > # src/java.base/share/classes/sun/security/provider/X509Factory.java > # src/java.base/share/classes/sun/security/util/Pem.java > # test/jdk/java/security/PEM/PEMDecoderTest.java > # test/jdk/java/security/PEM/PEMEncoderTest.java > - ... and 48 more: https://git.openjdk.org/jdk/compare/22845a77...cc952c0b src/java.base/share/classes/java/security/PEMDecoder.java line 58: > 56: * > 57: * > 58: * A specified return class must extend {@link DEREncodable} and be an Suggest rewording as "Objects that are decoded and returned must extend ..." src/java.base/share/classes/java/security/PEMDecoder.java line 68: > 66: * available. > 67: * > 68: *

    A new immutable {@code PEMDecoder} instance is created by using s/using/calling/ src/java.base/share/classes/java/security/PEMDecoder.java line 78: > 76: * > 77: *

    {@code String} values returned by this class use character set > 78: * {@link java.nio.charset.StandardCharsets#ISO_8859_1 ISO-8859-1} Missing period at end of sentence. src/java.base/share/classes/java/security/PEMDecoder.java line 199: > 197: * Decodes and returns {@link DEREncodable} from the given string. > 198: * > 199: * @param str PEM data in a String. Remove the period at end. Same comment applies to other @param, @return and @throws descriptions. See https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#@param for more details where it says "End the phrase with a period only if another phrase or sentence follows it." src/java.base/share/classes/java/security/PEMDecoder.java line 199: > 197: * Decodes and returns {@link DEREncodable} from the given string. > 198: * > 199: * @param str PEM data in a String. Suggest rewording as "a String containing PEM data". src/java.base/share/classes/java/security/PEMDecoder.java line 200: > 198: * > 199: * @param str PEM data in a String. > 200: * @return an {@code DEREncodable} generated from the PEM data. s/an/a/ src/java.base/share/classes/java/security/PEMDecoder.java line 218: > 216: * {@code InputStream}. > 217: * > 218: *

    The method will read the {@code InputStream} until PEM data is s/The/This/ src/java.base/share/classes/java/security/PEMDecoder.java line 374: > 372: * Configures and returns a new {@code PEMDecoder} instance from the > 373: * current instance that will use KeyFactory and CertificateFactory classes > 374: * from the specified {@link Provider}. Any errors using the What if `KeyFactory` and `CertificateFactory` are in different providers? Do we want to have a method that also takes two provider parameters? src/java.base/share/classes/java/security/PEMDecoder.java line 377: > 375: * {@code provider} will occur during decoding. > 376: * > 377: *

    If {@code params} is {@code null}, a new instance is returned with There is no variable named `params` - do you mean `provider`? Also, why not throw an NPE and not allow a `null` provider, since it would be the same as calling `of()`? src/java.base/share/classes/java/security/spec/EncodedKeySpec.java line 52: > 50: > 51: private final byte[] encodedKey; > 52: private String algorithmName; I think this can be marked `final` now. src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 200: > 198: DerValue bits = value.withTag(DerValue.tag_BitString); > 199: //byte[] bytes = bits.getBitString(); > 200: //BitArray bitArray = new BitArray(bytes[0] * 8 - 2, bytes, 3); Commented out code, remove? src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 207: > 205: pubKeyEncoded = new X509Key(algid, > 206: bits.getUnalignedBitString()).getEncoded(); > 207: */ Commented out code, remove? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1951190132 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1951191331 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1951194543 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1951463902 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1951582549 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1951587981 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1951589447 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1951505364 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1951507480 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1947197843 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1949565799 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1949565548 From coffeys at openjdk.org Thu Apr 17 15:30:52 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 17 Apr 2025 15:30:52 GMT Subject: RFR: 8350582: Correct the parsing of the ssl value in javax.net.debug [v4] In-Reply-To: References: Message-ID: <1E8tdSoS9CzyKxVfaby5whMJJyg0ynMF6ZDstiFsozA=.a71124fc-3d53-412f-9956-2a92a5b93f67@github.com> On Mon, 14 Apr 2025 23:59:39 GMT, Bradford Wetmore wrote: > > This bug only handles the `ssl` change, so I'm thinking we should change the regtest for this bug to be a simple test looking for the effects of `ssl` with no `data/verbose/plaintext/packet` output, and move (or update) this more general test to be done for 8044609. > > Thoughts? Thanks for comments Brad. I've added extra component areas to the test. JDK-8044609 will bring in further clean up. Given that we've zero test coverage in this area today, I think it's important/useful to have a test that reflects what the code is doing today. Some behaviour is broken I'd argue (and conflicts with our docs and help menus) The test can be modified further with the JDK-8044609 changes. It'll also help give us a better picture around impact of upcoming changes. For that reason, I'd like to keep the current test coverage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23781#issuecomment-2813324792 From ascarpino at openjdk.org Thu Apr 17 15:51:09 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 17 Apr 2025 15:51:09 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: References: Message-ID: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> > Hi all, > > I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. > > Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: - javadoc updates - code review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17543/files - new: https://git.openjdk.org/jdk/pull/17543/files/106788ef..0db8fdb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=12-13 Stats: 83 lines in 9 files changed: 26 ins; 8 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/17543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543 PR: https://git.openjdk.org/jdk/pull/17543 From valeriep at openjdk.org Thu Apr 17 17:19:46 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 17 Apr 2025 17:19:46 GMT Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 15:30:28 GMT, Weijun Wang wrote: > Add 2 `MessageDigest` algorithms. I will take a look~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/24576#issuecomment-2813594903 From duke at openjdk.org Thu Apr 17 18:31:23 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Thu, 17 Apr 2025 18:31:23 GMT Subject: RFR: 8353001: Remove leftover Security Manager parsing code in sun.security.util.Debug Message-ID: The private marshal() method in sun.security.util.Debug still contains code to parse "permission=" and "codebase=" options. These sub-options were part of the "access" option which was removed in JDK 24 as part of JEP 486, so this code can be removed. ------------- Commit messages: - 8353001:Remove leftover Security Manager parsing code in sun.security.util.Debug - 8353001:Remove leftover Security Manager parsing code in sun.security.util.Debug Changes: https://git.openjdk.org/jdk/pull/24731/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24731&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353001 Stats: 112 lines in 2 files changed: 1 ins; 110 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24731/head:pull/24731 PR: https://git.openjdk.org/jdk/pull/24731 From mpowers at openjdk.org Thu Apr 17 20:27:58 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 17 Apr 2025 20:27:58 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v5] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 23:01:56 GMT, Valerie Peng wrote: >> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings. >> >> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > minor comment and copyright year update. src/java.base/share/classes/sun/security/util/PBEUtil.java line 270: > 268: throw new InvalidKeyException("Missing password"); > 269: } > 270: passwdChars = decodePassword(passwdBytes); Not this line, but on line 286 a little ways down, you could use pattern matching and delete line 290. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 27: > 25: package sun.security.pkcs11; > 26: > 27: import java.security.AlgorithmParameters; Down on line 41, you don't need to import PBEParameterSpec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2049416362 PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2049538889 From valeriep at openjdk.org Thu Apr 17 20:55:52 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 17 Apr 2025 20:55:52 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 17 Apr 2025 03:14:14 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Inform key sizes in the exception when failing check. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 106: > 104: } > 105: > 106: static sealed class KeyInfo permits PBEKeyInfo, HMACKeyInfo, HKDFKeyInfo, Can we add some comment about the purpose of KeyInfo and the PKCS11 classes which depend on it? E.g. HKDF will use the key algorithm to look up the corresponding key type. Also some comment for the various child key info classes would be nice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2049633301 From valeriep at openjdk.org Thu Apr 17 20:59:42 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 17 Apr 2025 20:59:42 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 17 Apr 2025 03:14:14 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Inform key sizes in the exception when failing check. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 154: > 152: } > 153: > 154: static final class TLSKeyInfo extends KeyInfo { Documenting this TLSKeyInfo is to support JSSE using HKDF to derive various keys whose algorithms are named following the "TlsXXX" convention? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2049637478 From valeriep at openjdk.org Thu Apr 17 21:35:36 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 17 Apr 2025 21:35:36 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v4] In-Reply-To: References: Message-ID: > This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. > > This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. > > Thanks in advance for the review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Undo the special workaround for JSSE in PKCS11 HKDF impl. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24393/files - new: https://git.openjdk.org/jdk/pull/24393/files/eaa0737e..38b2da73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=02-03 Stats: 23 lines in 2 files changed: 0 ins; 20 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24393/head:pull/24393 PR: https://git.openjdk.org/jdk/pull/24393 From valeriep at openjdk.org Thu Apr 17 23:02:51 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 17 Apr 2025 23:02:51 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 17 Apr 2025 03:14:14 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Inform key sizes in the exception when failing check. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 605: > 603: } > 604: } > 605: } Hmm, how about separating out AES, RC4, Blowfish and ChaCha20 to a separate case? Only DES and DES3 needs parity checking and they are very legacy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2049737012 From valeriep at openjdk.org Thu Apr 17 23:55:42 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 17 Apr 2025 23:55:42 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 17 Apr 2025 03:14:14 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Inform key sizes in the exception when failing check. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 252: > 250: throw new InvalidAlgorithmParameterException("A key of algorithm " + > 251: "'" + alg + "' is not valid for derivation."); > 252: } So, essentially, we only allow HKDF to derive keys when ki is either `TLSKeyInfo` or `KeyInfo` w/ the key types in `canDeriveKeyInfoType(long)` method? Are you checking each key algorithm just to rule out `RC2` and `IDEA`? Not sure if it's worth the extra checking. Besides, if more `CKK_xxx` is added to `KeyInfo`, it'd need to be added to `canDeriveKeyInfoType(long)` which can be easily missed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2049765576 From jnimeh at openjdk.org Fri Apr 18 01:11:48 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 18 Apr 2025 01:11:48 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 [v3] In-Reply-To: References: Message-ID: > This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. > > There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Regroup CRC32 stub generators together ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24420/files - new: https://git.openjdk.org/jdk/pull/24420/files/fe865308..7ae8802d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24420&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24420&range=01-02 Stats: 82 lines in 1 file changed: 41 ins; 41 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24420/head:pull/24420 PR: https://git.openjdk.org/jdk/pull/24420 From myankelevich at openjdk.org Fri Apr 18 10:20:18 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 18 Apr 2025 10:20:18 GMT Subject: RFR: 8230016: re-visit test sun/security/pkcs11/Serialize/SerializeProvider.java Message-ID: Provider is now added to the Security before the test ------------- Commit messages: - JDK-8230016: re-visit test sun/security/pkcs11/Serialize/SerializeProvider.java Changes: https://git.openjdk.org/jdk/pull/24750/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24750&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8230016 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24750.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24750/head:pull/24750 PR: https://git.openjdk.org/jdk/pull/24750 From dfuchs at openjdk.org Fri Apr 18 13:29:17 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 18 Apr 2025 13:29:17 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API Message-ID: Hi, Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) This JEP proposes to enhance the HttpClient implementation to support HTTP/3. It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. ------------- Commit messages: - http3: jcheck - remove trailing white spaces - http3: jcheck - fixed bad file permission - merge latest changes from master branch - http3: increase keepalive timeout in H3MultipleConnectionsToSameHost.java - http3: improve logging on reception of stateless reset - http3: CSR feedback: renamed H3DiscoveryMode and associated constants - http3: comment update in Http3PushManager.java - http3: more consistent connection labels; the label now includes the underlying transport-level protocol: tcp:1, tls:2, quic:1 - Add HTTP/3 cases to `HttpResponseConnectionLabelTest` - http3: adapt connection label to HttpQuicConnection after merge - ... and 388 more: https://git.openjdk.org/jdk/compare/4eae9b5b...9c2da664 Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349910 Stats: 102691 lines in 469 files changed: 100070 ins; 1119 del; 1502 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From mdonovan at openjdk.org Fri Apr 18 14:26:57 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 18 Apr 2025 14:26:57 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3] In-Reply-To: References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: On Thu, 3 Apr 2025 20:30:33 GMT, Artur Barashev wrote: >> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - reversed order of DN strings when making certificates. >> - Merge branch 'master' into certbuilder >> - Merge branch 'master' into certbuilder >> - Merge branch 'master' into certbuilder >> - Merge branch 'master' into certbuilder >> - changed boolean array initialization >> - 8325766: Review seclibs tests for cert expiry > > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 243: > >> 241: .addBasicConstraintsExt(false, false, -1) >> 242: .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1")) >> 243: .build(trustedCert, caKeys.getPrivate(), "MD5WithRSA"); > > MD5 algorithm is not allowed in TLSv1.3 I'll address this in [JDK-8353738](https://bugs.openjdk.org/browse/JDK-8353738) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2050704560 From mdonovan at openjdk.org Fri Apr 18 14:58:41 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 18 Apr 2025 14:58:41 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4] In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: > This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates. > > ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1) > ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa) > ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0) Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - expanded wildcard imports - Merge branch 'master' into certbuilder - Merge branch 'master' into certbuilder - reversed order of DN strings when making certificates. - Merge branch 'master' into certbuilder - Merge branch 'master' into certbuilder - Merge branch 'master' into certbuilder - Merge branch 'master' into certbuilder - changed boolean array initialization - 8325766: Review seclibs tests for cert expiry ------------- Changes: https://git.openjdk.org/jdk/pull/23700/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=03 Stats: 784 lines in 3 files changed: 158 ins; 582 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/23700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23700/head:pull/23700 PR: https://git.openjdk.org/jdk/pull/23700 From abarashev at openjdk.org Fri Apr 18 15:42:09 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 18 Apr 2025 15:42:09 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3] In-Reply-To: References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: On Fri, 18 Apr 2025 14:24:10 GMT, Matthew Donovan wrote: >> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 243: >> >>> 241: .addBasicConstraintsExt(false, false, -1) >>> 242: .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1")) >>> 243: .build(trustedCert, caKeys.getPrivate(), "MD5WithRSA"); >> >> MD5 algorithm is not allowed in TLSv1.3 > > I'll address this in [JDK-8353738](https://bugs.openjdk.org/browse/JDK-8353738) Sounds good, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2050786190 From abarashev at openjdk.org Fri Apr 18 15:42:13 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 18 Apr 2025 15:42:13 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4] In-Reply-To: References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: <_f044UeqrNVDHSyXMWBZXOb7hu4ze8OOdBEWR457d-Y=.7d6654bc-b4e3-4bc3-9930-9b9bf13f03a5@github.com> On Fri, 18 Apr 2025 14:58:41 GMT, Matthew Donovan wrote: >> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates. >> >> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1) >> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa) >> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0) > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - expanded wildcard imports > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - reversed order of DN strings when making certificates. > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - changed boolean array initialization > - 8325766: Review seclibs tests for cert expiry test/lib/jdk/test/lib/security/CertificateBuilder.java line 139: > 137: */ > 138: public static SubjectAlternativeNameExtension createDNSSubjectAltNameExt( > 139: boolean critical, String dnsName) throws IOException { Any particular reason for having this method? We already have `addSubjectAltNameDNSExt` method below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2050785449 From mdonovan at openjdk.org Fri Apr 18 15:55:58 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 18 Apr 2025 15:55:58 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4] In-Reply-To: <_f044UeqrNVDHSyXMWBZXOb7hu4ze8OOdBEWR457d-Y=.7d6654bc-b4e3-4bc3-9930-9b9bf13f03a5@github.com> References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> <_f044UeqrNVDHSyXMWBZXOb7hu4ze8OOdBEWR457d-Y=.7d6654bc-b4e3-4bc3-9930-9b9bf13f03a5@github.com> Message-ID: On Fri, 18 Apr 2025 15:38:02 GMT, Artur Barashev wrote: >> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - expanded wildcard imports >> - Merge branch 'master' into certbuilder >> - Merge branch 'master' into certbuilder >> - reversed order of DN strings when making certificates. >> - Merge branch 'master' into certbuilder >> - Merge branch 'master' into certbuilder >> - Merge branch 'master' into certbuilder >> - Merge branch 'master' into certbuilder >> - changed boolean array initialization >> - 8325766: Review seclibs tests for cert expiry > > test/lib/jdk/test/lib/security/CertificateBuilder.java line 139: > >> 137: */ >> 138: public static SubjectAlternativeNameExtension createDNSSubjectAltNameExt( >> 139: boolean critical, String dnsName) throws IOException { > > Any particular reason for having this method? We already have `addSubjectAltNameDNSExt` method below. It's been a while since I wrote that method but it's probably because the existing method hardcodes the critical flag to `false`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2050800817 From abarashev at openjdk.org Fri Apr 18 16:27:50 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 18 Apr 2025 16:27:50 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4] In-Reply-To: References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: On Fri, 18 Apr 2025 14:58:41 GMT, Matthew Donovan wrote: >> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates. >> >> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1) >> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa) >> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0) > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - expanded wildcard imports > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - reversed order of DN strings when making certificates. > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - changed boolean array initialization > - 8325766: Review seclibs tests for cert expiry LGTM ------------- Marked as reviewed by abarashev (Author). PR Review: https://git.openjdk.org/jdk/pull/23700#pullrequestreview-2778947024 From abarashev at openjdk.org Fri Apr 18 17:31:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 18 Apr 2025 17:31:54 GMT Subject: RFR: 8272875: Change the default key manager to PKIX Message-ID: The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check of the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust. ------------- Commit messages: - Rework unit tests - Use standard PKIX alias - Merge branch 'master' into JDK-8272875 - 8272875: Change the default key manager to PKIX Changes: https://git.openjdk.org/jdk/pull/24756/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8272875 Stats: 213 lines in 10 files changed: 158 ins; 25 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/24756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24756/head:pull/24756 PR: https://git.openjdk.org/jdk/pull/24756 From liach at openjdk.org Fri Apr 18 19:03:51 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 18 Apr 2025 19:03:51 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com> On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. src/java.net.http/share/classes/java/net/http/HttpRequest.java line 357: > 355: * @since TBD > 356: */ > 357: public default Builder setOption(HttpRequestOption option, T value) { return this; } Bikeshed: we usually omit the set prefix for builders. src/java.net.http/share/classes/java/net/http/HttpResponse.java line 838: > 836: /** > 837: * Represents a HTTP/3 PushID. PushIds can be shared across > 838: * multiple client initiated requests on the same HTTP/3 connection. Is this a marker interface for various kinds of push ids? Otherwise just the record is sufficient. src/java.net.http/share/classes/java/net/http/HttpResponse.java line 937: > 935: HttpRequest initiatingRequest, > 936: HttpRequest pushPromiseRequest, > 937: PushId pushid, (Warning: I know little about HTTP, my assumptions and thus whole argument may be invalid below!) This feels like users need to use push ids as units of synchronization on this handler, such as tracking this with a ConcurrentHashMap. Is it possible for users to instead provide a `Function` in `HttpClient::sendAsync`? I think this might make it easier for users as they no longer need to think about concurrency for different ids. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2050992217 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2050991104 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2051001758 From mbalao at openjdk.org Fri Apr 18 19:49:48 2025 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 18 Apr 2025 19:49:48 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 17 Apr 2025 20:52:52 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Inform key sizes in the exception when failing check. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 106: > >> 104: } >> 105: >> 106: static sealed class KeyInfo permits PBEKeyInfo, HMACKeyInfo, HKDFKeyInfo, > > Can we add some comment about the purpose of KeyInfo and the PKCS11 classes which depend on it? E.g. HKDF will use the key algorithm to look up the corresponding key type. Also some comment for the various child key info classes would be nice. Ok > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 154: > >> 152: } >> 153: >> 154: static final class TLSKeyInfo extends KeyInfo { > > Documenting this TLSKeyInfo is to support JSSE using HKDF to derive various keys whose algorithms are named following the "TlsXXX" convention? Ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2051049867 PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2051050494 From mbalao at openjdk.org Fri Apr 18 19:55:47 2025 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 18 Apr 2025 19:55:47 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: <4UTdeEQtnD4vZ6c9i1qn1KyH1I88DD-F21fqDwt-0io=.6641d426-dd4b-4c87-81f9-b356afb1a19c@github.com> On Thu, 17 Apr 2025 22:59:49 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Inform key sizes in the exception when failing check. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 605: > >> 603: } >> 604: } >> 605: } > > Hmm, how about separating out AES, RC4, Blowfish and ChaCha20 to a separate case? Only DES and DES3 needs parity checking and they are very legacy. We would need to repeat code if we separate (invocation to `P11KeyGenerator::checkKeySize`). Does not look complex enough in my opinion to merit this split. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2051055130 From mbalao at openjdk.org Fri Apr 18 20:13:47 2025 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 18 Apr 2025 20:13:47 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Thu, 17 Apr 2025 23:52:56 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Inform key sizes in the exception when failing check. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 252: > >> 250: throw new InvalidAlgorithmParameterException("A key of algorithm " + >> 251: "'" + alg + "' is not valid for derivation."); >> 252: } > > So, essentially, we only allow HKDF to derive keys when ki is either `TLSKeyInfo` or `KeyInfo` w/ the key types in `canDeriveKeyInfoType(long)` method? Are you checking each key algorithm just to rule out `RC2` and `IDEA`? Not sure if it's worth the extra checking. Besides, if more `CKK_xxx` is added to `KeyInfo`, it'd need to be added to `canDeriveKeyInfoType(long)` which can be easily missed. That's right: only `TLSKeyInfo` and selected `KeyInfo` keys allowed for HKDF derivation. If something is added to the map, it's not implicitly allowed. Same is true for `P11SecretKeyFactory::createKey` (`C_CreateObject`). Even `P11KeyGenerator` may need adjustments depending on the key type. I think that adding something should require to think what's the impact on different services, and not rely on a default/implicit behavior. I don't expect new symmetric key updates to be that frequent, though. If this becomes a problem, we can implement what @franferrax suggested and move the "uses" information to the map. I was not thinking of `RC2` or `IDEA` but of key algorithms that are not the result of a HKDF derivation and did not go through the checks that we would enforce otherwise. For example, a key of algorithm `PBEWithHmacSHA512AndAES_256` should be the result of a PBE derivation and should have a specific key size. It would be inconsistent to obtain a key of this algorithm with a different size through a HKDF derivation. When we check or convert keys to be used in services, we rely on this information. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2051070244 From mbalao at openjdk.org Fri Apr 18 20:22:44 2025 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 18 Apr 2025 20:22:44 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v5] In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- Martin Balao has updated the pull request incrementally with one additional commit since the last revision: KeyInfo class and subclasses documentation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24526/files - new: https://git.openjdk.org/jdk/pull/24526/files/1ffde71f..50e4e929 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=03-04 Stats: 27 lines in 1 file changed: 27 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24526/head:pull/24526 PR: https://git.openjdk.org/jdk/pull/24526 From liach at openjdk.org Fri Apr 18 20:38:14 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 18 Apr 2025 20:38:14 GMT Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to class file version Message-ID: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview. ------------- Depends on: https://git.openjdk.org/jdk/pull/23095 Commit messages: - 8297271: AccessFlag.maskToAccessFlags should be specific to class file version Changes: https://git.openjdk.org/jdk/pull/24760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297271 Stats: 157 lines in 9 files changed: 93 ins; 31 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/24760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760 PR: https://git.openjdk.org/jdk/pull/24760 From valeriep at openjdk.org Fri Apr 18 20:40:00 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 18 Apr 2025 20:40:00 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v5] In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 17:51:16 GMT, Mark Powers wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> minor comment and copyright year update. > > src/java.base/share/classes/sun/security/util/PBEUtil.java line 270: > >> 268: throw new InvalidKeyException("Missing password"); >> 269: } >> 270: passwdChars = decodePassword(passwdBytes); > > Not this line, but on line 286 a little ways down, you could use pattern matching and delete line 290. Sure~ > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 27: > >> 25: package sun.security.pkcs11; >> 26: >> 27: import java.security.AlgorithmParameters; > > Down on line 41, you don't need to import PBEParameterSpec. Will remove. Thanks~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2051093811 PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2051094012 From valeriep at openjdk.org Fri Apr 18 21:04:51 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 18 Apr 2025 21:04:51 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v6] In-Reply-To: References: Message-ID: > As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings. > > Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: address review comments from Mark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24068/files - new: https://git.openjdk.org/jdk/pull/24068/files/34e5d4e5..5c73f744 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=04-05 Stats: 10 lines in 2 files changed: 4 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24068/head:pull/24068 PR: https://git.openjdk.org/jdk/pull/24068 From valeriep at openjdk.org Fri Apr 18 21:20:54 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 18 Apr 2025 21:20:54 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: <4UTdeEQtnD4vZ6c9i1qn1KyH1I88DD-F21fqDwt-0io=.6641d426-dd4b-4c87-81f9-b356afb1a19c@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <4UTdeEQtnD4vZ6c9i1qn1KyH1I88DD-F21fqDwt-0io=.6641d426-dd4b-4c87-81f9-b356afb1a19c@github.com> Message-ID: On Fri, 18 Apr 2025 19:52:45 GMT, Martin Balao wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 605: >> >>> 603: } >>> 604: } >>> 605: } >> >> Hmm, how about separating out AES, RC4, Blowfish and ChaCha20 to a separate case? Only DES and DES3 needs parity checking and they are very legacy. > > We would need to repeat code if we separate (invocation to `P11KeyGenerator::checkKeySize`). Does not look complex enough in my opinion to merit this split. The separation can remove 1 conditional block, so only 1 extra line and the flow looks cleaner in my opinion, e.g. Suggestion: case (int) CKK_DES, (int) CKK_DES3 -> { keyLength = P11KeyGenerator.checkKeySize(ki.keyGenMech, n, token); fixDESParity(encoded, 0); if (keyType == CKK_DES3) { fixDESParity(encoded, 8); if (keyLength == 112) { keyType = CKK_DES2; } else { fixDESParity(encoded, 16); } } } case (int) CKK_AES, (int) CKK_RC4, (int) CKK_BLOWFISH, (int) CKK_CHACHA20 -> { keyLength = P11KeyGenerator.checkKeySize(ki.keyGenMech, n, token); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2051131893 From valeriep at openjdk.org Fri Apr 18 21:20:54 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 18 Apr 2025 21:20:54 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <4UTdeEQtnD4vZ6c9i1qn1KyH1I88DD-F21fqDwt-0io=.6641d426-dd4b-4c87-81f9-b356afb1a19c@github.com> Message-ID: On Fri, 18 Apr 2025 21:15:41 GMT, Valerie Peng wrote: >> We would need to repeat code if we separate (invocation to `P11KeyGenerator::checkKeySize`). Does not look complex enough in my opinion to merit this split. > > The separation can remove 1 conditional block, so only 1 extra line and the flow looks cleaner in my opinion, e.g. > Suggestion: > > case (int) CKK_DES, (int) CKK_DES3 -> { > keyLength = P11KeyGenerator.checkKeySize(ki.keyGenMech, n, > token); > fixDESParity(encoded, 0); > if (keyType == CKK_DES3) { > fixDESParity(encoded, 8); > if (keyLength == 112) { > keyType = CKK_DES2; > } else { > fixDESParity(encoded, 16); > } > } > } > case (int) CKK_AES, (int) CKK_RC4, (int) CKK_BLOWFISH, (int) CKK_CHACHA20 -> { > keyLength = P11KeyGenerator.checkKeySize(ki.keyGenMech, n, > token); > } If you'd still like lumping them together as you have it now, then at least move the `if (keyType == CKK_DES3)` block (line 624-630) to inside the previous if-block (line 621-623)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2051133889 From duke at openjdk.org Sat Apr 19 04:34:49 2025 From: duke at openjdk.org (duke) Date: Sat, 19 Apr 2025 04:34:49 GMT Subject: Withdrawn: 8347606: Optimize Java implementation of ML-DSA In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:43:32 GMT, Ben Perez wrote: > It turns out that initializing a multidimensional array with `int[][] a = new int[rows][cols]` is slower than allocating each column in a loop. Since we do a lot of large multidimensional array allocations in ML-DSA, the optimized initialization improves performance by roughly 10%. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23642 From duke at openjdk.org Sat Apr 19 08:56:40 2025 From: duke at openjdk.org (ExE Boss) Date: Sat, 19 Apr 2025 08:56:40 GMT Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to class file version In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> Message-ID: On Fri, 18 Apr 2025 20:33:27 GMT, Chen Liang wrote: > Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview. With?this, the?**Class?File API**?needs to?be?updated to?pass the?current class?file format?version to?the?calls of?`AccessFlag?.maskToAccessFlags(?)`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2816617102 From liach at openjdk.org Sat Apr 19 15:06:45 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 19 Apr 2025 15:06:45 GMT Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to class file version In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> Message-ID: On Fri, 18 Apr 2025 20:33:27 GMT, Chen Liang wrote: > Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview. That is tracked in a separate bug linked as a dependent on this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24760#issuecomment-2816742550 From weijun at openjdk.org Mon Apr 21 14:00:49 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 21 Apr 2025 14:00:49 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v14] In-Reply-To: <1JYX6gMahUjwiOKFNofynWUIEDlCCZSRQB4xYGgFdhg=.e32d7a25-25cd-44d2-8bb4-fcd0c65e4a47@github.com> References: <1JYX6gMahUjwiOKFNofynWUIEDlCCZSRQB4xYGgFdhg=.e32d7a25-25cd-44d2-8bb4-fcd0c65e4a47@github.com> Message-ID: On Fri, 11 Apr 2025 18:35:07 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: >> >> - put encapsulation in params from getParameters >> - receiver must specify all algorithm identifiers > > src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 53: > >> 51: *

  • {@link #of()} creates an instance with unspecified KEM, KDF, and AEAD >> 52: * algorithms, which will be determined by the implementation based on the key >> 53: * provided to {@code init()}. This instance can only be used by the sender. > > Does `Cipher.init` throw an exception if the parameters created by `HPKEParameterSpec.of()` are initialized with a cipher in decrypt mode? Yes, an `InvalidAlgorithmParameterException` is thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052418781 From weijun at openjdk.org Mon Apr 21 14:46:58 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 21 Apr 2025 14:46:58 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v14] In-Reply-To: <1JYX6gMahUjwiOKFNofynWUIEDlCCZSRQB4xYGgFdhg=.e32d7a25-25cd-44d2-8bb4-fcd0c65e4a47@github.com> References: <1JYX6gMahUjwiOKFNofynWUIEDlCCZSRQB4xYGgFdhg=.e32d7a25-25cd-44d2-8bb4-fcd0c65e4a47@github.com> Message-ID: On Fri, 11 Apr 2025 18:42:12 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision: >> >> - put encapsulation in params from getParameters >> - receiver must specify all algorithm identifiers > > src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 82: > >> 80: * public key. >> 81: *
  • >> 82: * If HPKE modes {@code mode_psk} or {@code mode_auth_psk} are used, > > If you want to use `mode_auth_psk`, do you have to call both `authKey` and `psk` methods? If so, I think it would be more readable if you have a separate paragraph for this mode, indicating calling both methods are required. OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052497133 From weijun at openjdk.org Mon Apr 21 14:46:58 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 21 Apr 2025 14:46:58 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v15] In-Reply-To: <0Ppa9h_Gyc9W1MoYIWffLA9wRiWxrMYy93zqpEwZGIg=.74790f84-fc3e-4d6c-84fd-8613f39328fc@github.com> References: <0Ppa9h_Gyc9W1MoYIWffLA9wRiWxrMYy93zqpEwZGIg=.74790f84-fc3e-4d6c-84fd-8613f39328fc@github.com> Message-ID: On Mon, 14 Apr 2025 17:25:41 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> toString, exportData, spec in HPKEParameters must have algorithm identifiers specified > > src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 78: > >> 76: * {@link #info(byte[])} method by both sides. >> 77: *
  • >> 78: * If HPKE modes {@code mode_auth} or {@code mode_auth_psk} are used, > > This could be reworded as: "To use the HPKE modes {@code mode_auth} ..." OK. > src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 35: > >> 33: public static void main(String[] args) throws Exception { >> 34: // @start region="hpke-spec-example" >> 35: // Key pair generation > > Comment should note this is the recipient's key pair. OK. > src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 46: > >> 44: sender.init(Cipher.ENCRYPT_MODE, kp.getPublic(), ps); >> 45: >> 46: // Retrieve the actual parameters used from the sender. > > I think it would be more clear if you didn't name the cipher objects `sender` and `recipient` because there can be confusion as to whether you mean the cipher objects or the sender/receiver entities. I'll named them `senderCipher` and `recipientCipher`. > src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 64: > >> 62: recipient.init(Cipher.DECRYPT_MODE, kp.getPrivate(), pr); >> 63: >> 64: // Secure communication between the 2 sides > > There is no secure communication in the code below. I would remove/change this comment. I'll change it to "Encryption and decryption". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052498558 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052500301 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052511538 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052504826 From weijun at openjdk.org Mon Apr 21 14:50:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 21 Apr 2025 14:50:51 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v15] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 13:06:42 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> toString, exportData, spec in HPKEParameters must have algorithm identifiers specified > > src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 112: > >> 110: return impl.aead.cipher.getOutputSize(inputLen); >> 111: } else { >> 112: throw new IllegalStateException("No AEAD cipher"); > > The spec is not defined to throw `IllegalStateException`. Same above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052515892 From weijun at openjdk.org Mon Apr 21 15:02:55 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 21 Apr 2025 15:02:55 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v15] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 13:04:58 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> toString, exportData, spec in HPKEParameters must have algorithm identifiers specified > > src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 103: > >> 101: return impl.aead.cipher.getBlockSize(); >> 102: } else { >> 103: throw new IllegalStateException("No AEAD cipher"); > > Should this return 0 instead per spec? The spec is not defined to throw `IllegalStateException`. It's totally OK to return 0 for the `EXPORT_ONLY` case, but before the cipher is initialized, there is no way to know if AES/GCM or ChaCha20-Poly1305 is used. Existing ciphers know the block size even there is no key. > src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 156: > >> 154: impl = new Impl(opmode); >> 155: if (!(key instanceof AsymmetricKey ak)) { >> 156: throw new InvalidKeyException("Not asymmetric key"); > > Nit: "Not an asymmetric key" OK. > src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 178: > >> 176: AlgorithmParameters params, SecureRandom random) >> 177: throws InvalidAlgorithmParameterException { >> 178: throw new InvalidAlgorithmParameterException( > > Could you support this method by extracting the `HKDFParameterSpec` from the `AlgorithmParameters`? Yes, I can do that now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052540825 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052541307 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052542330 From weijun at openjdk.org Mon Apr 21 15:27:43 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 21 Apr 2025 15:27:43 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v15] In-Reply-To: References: Message-ID: <0NVi830Oojpm9CKsu8W36dkIvJZcVrJUEI2nx88pPAk=.4ab143b6-3b6a-42c9-9b08-0c85f8c8c74f@github.com> On Tue, 15 Apr 2025 18:37:40 GMT, Sean Mullan wrote: >> src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 136: >> >>> 134: * {@snippet lang=java class="PackageSnippets" region="hpke-spec-example"} >>> 135: * >>> 136: * @implNote >> >> Making this implementation specific means that other providers could in theory choose different defaults, which reduces compatibility but an application could never be sure, or even know if this is for algorithms in RFC 9180. These are probably the most reasonable defaults for RFC 9180 compliant implementations. Did you consider making these defaults a requirement of HPKE implementations? I also wonder if "HPKE" is too general. If there is ever a new HPKE spec with say a new KEM or KDF algorithm for EC/XDH keys, would it be called "HPKE2"? > > Consider adding a String or Enum argument to `of()` with the name of the profile, ex "RFC9180". I can add a sentence saying if an implementation does not support default numeric algorithm identifiers then an exception will be thrown. I still think it's useful to provide defaults. Now that the recipient requires the numeric algorithm identifiers to be provided, at least this will no longer be an interop issue between implementations. As for future new KEM or KDF algorithms for EC/XDH keys, I believe they will have different numeric algorithm identifiers and users can just specify them so there will be need for "HPKE2". In fact, suppose the current kem_id for XDH is found insecure one day and a new one is defined, we can update the `@implNote` to make the new one the default. Those using `of()` will automatically switch to the safer one and there is no need to update the code. That said, this does need both sides supporting the new kem_id. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052587728 From weijun at openjdk.org Mon Apr 21 15:52:37 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 21 Apr 2025 15:52:37 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v16] In-Reply-To: References: Message-ID: <-VfsyMVro5yl1tl83NjmSX5yxNIuc0BPlV5k-CoFV7g=.2b7f51b6-74f4-42d5-aa6a-71b6b92107aa@github.com> > Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. > ![hpke](https://github.com/user-attachments/assets/4edc5d08-ef52-44c5-b5d5-e8890c2d2fce) Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: address Sean's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18411/files - new: https://git.openjdk.org/jdk/pull/18411/files/17dceaa9..fff8e324 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=14-15 Stats: 51 lines in 5 files changed: 18 ins; 2 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/18411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 PR: https://git.openjdk.org/jdk/pull/18411 From ajiva at apple.com Mon Apr 21 16:19:18 2025 From: ajiva at apple.com (Azeem Jiva) Date: Mon, 21 Apr 2025 09:19:18 -0700 Subject: TLS support for X25519MLKEM768. Message-ID: Hi, Are there plans for TLS support for the X25519MLKEM768 key exchange in OpenJDK? Thanks. From weijun at openjdk.org Mon Apr 21 16:27:44 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 21 Apr 2025 16:27:44 GMT Subject: RFR: 8354053: Remove unused JavaIOFilePermissionAccess [v2] In-Reply-To: References: Message-ID: <77BHgOboZY2R-mS9jo2kgJO9QNPk0jvIskCxSuiHCtU=.6045b542-c8e2-44f7-ae66-8acdb897f6fa@github.com> On Mon, 14 Apr 2025 16:14:03 GMT, Roger Riggs wrote: >> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. >> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. >> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. >> The remaining support will be removed when FilePermission is removed. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Simplify as suggested in review comments > Convert static methods to instance methods and invoke on the existing FilePermission. LGTM. In fact, there is no need to keep or test on `newPermPlusAltPath` and `newPermUsingAltPath`. Those were only used in access control checks with the "new" behavior. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24603#pullrequestreview-2781713842 From jnimeh at openjdk.org Mon Apr 21 17:07:05 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 21 Apr 2025 17:07:05 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 [v3] In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 01:11:48 GMT, Jamil Nimeh wrote: >> This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. >> >> There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Regroup CRC32 stub generators together Hi @theRealAph, just wanted to check in and see if you were happy with the function for the column/diagonal reassignments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24420#issuecomment-2819028037 From mbalao at openjdk.org Mon Apr 21 17:12:27 2025 From: mbalao at openjdk.org (Martin Balao) Date: Mon, 21 Apr 2025 17:12:27 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v4] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> <4UTdeEQtnD4vZ6c9i1qn1KyH1I88DD-F21fqDwt-0io=.6641d426-dd4b-4c87-81f9-b356afb1a19c@github.com> Message-ID: On Fri, 18 Apr 2025 21:18:04 GMT, Valerie Peng wrote: >> The separation can remove 1 conditional block, so only 1 extra line and the flow looks cleaner in my opinion, e.g. >> Suggestion: >> >> case (int) CKK_DES, (int) CKK_DES3 -> { >> keyLength = P11KeyGenerator.checkKeySize(ki.keyGenMech, n, >> token); >> fixDESParity(encoded, 0); >> if (keyType == CKK_DES3) { >> fixDESParity(encoded, 8); >> if (keyLength == 112) { >> keyType = CKK_DES2; >> } else { >> fixDESParity(encoded, 16); >> } >> } >> } >> case (int) CKK_AES, (int) CKK_RC4, (int) CKK_BLOWFISH, (int) CKK_CHACHA20 -> { >> keyLength = P11KeyGenerator.checkKeySize(ki.keyGenMech, n, >> token); >> } > > If you'd still like lumping them together as you have it now, then at least move the `if (keyType == CKK_DES3)` block (line 624-630) to inside the previous if-block (line 621-623)? Ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2052728076 From mbalao at openjdk.org Mon Apr 21 17:12:27 2025 From: mbalao at openjdk.org (Martin Balao) Date: Mon, 21 Apr 2025 17:12:27 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v6] In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Minor change. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24526/files - new: https://git.openjdk.org/jdk/pull/24526/files/50e4e929..7bec0df0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24526&range=04-05 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24526/head:pull/24526 PR: https://git.openjdk.org/jdk/pull/24526 From weijun.wang at oracle.com Mon Apr 21 18:20:40 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Mon, 21 Apr 2025 18:20:40 +0000 Subject: TLS support for X25519MLKEM768. In-Reply-To: References: Message-ID: <3AD12EC3-2CF6-4E3B-B018-E5C2B84C6CEA@oracle.com> There is an enhancement at https://bugs.openjdk.org/browse/JDK-8314323. > On Apr 21, 2025, at 12:19, Azeem Jiva wrote: > > Hi, > Are there plans for TLS support for the X25519MLKEM768 key exchange in OpenJDK? Thanks. From mdonovan at openjdk.org Mon Apr 21 18:47:19 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 21 Apr 2025 18:47:19 GMT Subject: RFR: 8354235: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java failed with java.net.SocketException: An established connection was aborted by the software in your host machine Message-ID: In this PR, I updated the default `serverAddress` field to use the loopback interface. I also removed some unnecessary logic around creating the server interface and the client connecting code. ------------- Commit messages: - 8354235: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java failed with java.net.SocketException: An established connection was aborted by the software in your host machine Changes: https://git.openjdk.org/jdk/pull/24776/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24776&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354235 Stats: 12 lines in 1 file changed: 0 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24776.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24776/head:pull/24776 PR: https://git.openjdk.org/jdk/pull/24776 From jnimeh at openjdk.org Mon Apr 21 21:53:33 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 21 Apr 2025 21:53:33 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 [v4] In-Reply-To: References: Message-ID: > This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. > > There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge with main - Regroup CRC32 stub generators together - Place columnar/diagonal alignment code into separate method - 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24420/files - new: https://git.openjdk.org/jdk/pull/24420/files/7ae8802d..b6fb9136 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24420&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24420&range=02-03 Stats: 251518 lines in 1780 files changed: 55210 ins; 190355 del; 5953 mod Patch: https://git.openjdk.org/jdk/pull/24420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24420/head:pull/24420 PR: https://git.openjdk.org/jdk/pull/24420 From valeriep at openjdk.org Mon Apr 21 22:22:48 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 21 Apr 2025 22:22:48 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v6] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Mon, 21 Apr 2025 17:12:27 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Minor change. Updates look good to me. Thanks~ ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24526#pullrequestreview-2782341799 From aph at openjdk.org Tue Apr 22 08:31:01 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 22 Apr 2025 08:31:01 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 [v3] In-Reply-To: References: Message-ID: On Mon, 21 Apr 2025 17:03:25 GMT, Jamil Nimeh wrote: > Hi @theRealAph, just wanted to check in and see if you were happy with the function for the column/diagonal reassignments. Yes, it looks fine. I think we're good to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24420#issuecomment-2820563923 From fferrari at openjdk.org Tue Apr 22 14:34:44 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Tue, 22 Apr 2025 14:34:44 GMT Subject: RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v6] In-Reply-To: References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Mon, 21 Apr 2025 17:12:27 GMT, Martin Balao wrote: >> Hi, >> >> I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. >> >> No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. >> >> Thanks, >> Martin.- > > Martin Balao has updated the pull request incrementally with one additional commit since the last revision: > > Minor change. Thanks for the updates, it looks good to me. ------------- Marked as reviewed by fferrari (Committer). PR Review: https://git.openjdk.org/jdk/pull/24526#pullrequestreview-2784337789 From mbalao at openjdk.org Tue Apr 22 14:39:49 2025 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 22 Apr 2025 14:39:49 GMT Subject: Integrated: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key In-Reply-To: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> References: <9o_zYEs4-MpseBXKpPrXOHxcsz-fS8oBfuYCtiuI6fw=.a6abd3b9-dbb9-4eb2-b1ac-e49622a27506@github.com> Message-ID: On Tue, 8 Apr 2025 20:02:56 GMT, Martin Balao wrote: > Hi, > > I would like to request a review for the fix of JDK-8350661. In this fix, we translate the native PKCS 11 error code into an `InvalidAlgorithmParameterException`, as documented in the `KDF::deriveKey` API. With that said, different PKCS 11 libraries may throw different errors and may even (in theory) delay the error until the key is used, as _SunJCE_ does. I believe that this is an improvement but further adjustments may be needed in the future. > > No regressions observed in `test/jdk/sun/security/pkcs11/KDF/TestHKDF.java`. > > Thanks, > Martin.- This pull request has now been integrated. Changeset: 5264d80b Author: Martin Balao URL: https://git.openjdk.org/jdk/commit/5264d80bea25a1ef98dae4633b04b16e8de6120f Stats: 222 lines in 5 files changed: 150 ins; 22 del; 50 mod 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key Reviewed-by: fferrari, valeriep, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/24526 From abarashev at openjdk.org Tue Apr 22 16:13:49 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 16:13:49 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com> On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 366: > 364: } > 365: > 366: public String chooseServerAlias(String keyType, This method should have default (package-private) access modifier. src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 375: > 373: } > 374: > 375: public String chooseClientAlias(String[] keyTypes, Principal[] issuers, Same as above, the method shouldn't be public. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054431358 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054432049 From abarashev at openjdk.org Tue Apr 22 16:17:48 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 16:17:48 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 226: > 224: chc.peerSupportedAuthorities == null ? null : > 225: chc.peerSupportedAuthorities.clone(), > 226: chc.algorithmConstraints); These `algorithmConstraints` won't include `peerSupportedSignAlgs`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054439669 From abarashev at openjdk.org Tue Apr 22 16:23:45 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 16:23:45 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 221: > 219: chc.peerSupportedAuthorities.clone(), > 220: engine); > 221: // TODO should we have a method that can take QuicTLSEngine? Yes, I think we should have a method for `QuicTLSEngine` in `X509KeyManagerImpl`. In that new method we should use session's `peerSupportedSignAlgs` to construct algorithm constraints the same way we do it for `SSLSocketImpl` and for `SSLEngineImpl`. This is per TLSv1.3 RFC: https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054448979 From aph at openjdk.org Tue Apr 22 16:26:43 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 22 Apr 2025 16:26:43 GMT Subject: RFR: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 [v4] In-Reply-To: References: Message-ID: On Mon, 21 Apr 2025 21:53:33 GMT, Jamil Nimeh wrote: >> This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. >> >> There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. > > Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge with main > - Regroup CRC32 stub generators together > - Place columnar/diagonal alignment code into separate method > - 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24420#pullrequestreview-2784665815 From abarashev at openjdk.org Tue Apr 22 16:41:46 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 16:41:46 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 265: > 263: // engine, localSupportedSignAlgs, false); > 264: // } else { > 265: // constraints = SSLAlgorithmConstraints.forEngine(engine, false); We need these to check peer's certificate against constraints specified in `java.security` config file. It looks like `SSLAlgorithmConstraints` class would need a new `forQuicTLSEngine` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054475193 From abarashev at openjdk.org Tue Apr 22 16:51:51 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 16:51:51 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 286: > 284: X509Certificate[] trustedChain = v.validate(chain, null, > 285: Collections.emptyList(), > 286: sslParameters.getAlgorithmConstraints(), authType); SSLParameter's algorithm constraints don't include constraints specified in `java.security` config file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054488636 From jnimeh at openjdk.org Tue Apr 22 16:52:49 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 22 Apr 2025 16:52:49 GMT Subject: Integrated: 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 16:31:39 GMT, Jamil Nimeh wrote: > This fix addresses a performance regression found on some aarch64 processors, namely the Apple M1, when we moved to a quarter round parallel implementation in JDK-8349106. After making some improvements in the ordering of the instructions in the 20-round loop we found that going back to a block-parallel implementation was faster, but it definitely needed the ordering changes for that to be the case. More importantly, the block parallel implementation with the interleaving turns out to be faster on even those processors that showed improvements when moving to the quarter round parallel implementation. > > There is a spreadsheet attached to the JBS bug that shows 3 different implementations relative to the current (QR-parallel with no interleaving) implementation on 3 different ARM64 processors. Comparative benchmarks can also be found below. This pull request has now been integrated. Changeset: 594b2651 Author: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/594b26516e5c01d7daa331db59bdbe8ab7dc0a6d Stats: 395 lines in 3 files changed: 137 ins; 80 del; 178 mod 8350126: Regression ~3% on Crypto-ChaCha20Poly1305.encrypt for MacOSX aarch64 Reviewed-by: aph ------------- PR: https://git.openjdk.org/jdk/pull/24420 From dfuchs at openjdk.org Tue Apr 22 18:23:00 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 22 Apr 2025 18:23:00 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com> References: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com> Message-ID: <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com> On Fri, 18 Apr 2025 18:49:19 GMT, Chen Liang wrote: >> Hi, >> >> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). >> >> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > src/java.net.http/share/classes/java/net/http/HttpRequest.java line 357: > >> 355: * @since TBD >> 356: */ >> 357: public default Builder setOption(HttpRequestOption option, T value) { return this; } > > Bikeshed: we usually omit the set prefix for builders. I actually hesitated quite a bit on this one. We have a precedent with `Builder.setHeader(name, value)` - where the `setHeader` method replaces any value associated with the name with the given value, while `header(name, value)` would just add another value to the list of values associated with the name. I didn't want to give the impression that you could provide several values to the same option - and thus opted for naming that method `setOption`. I could let me be convinced to rename it if there is a strong concensus. > src/java.net.http/share/classes/java/net/http/HttpResponse.java line 937: > >> 935: HttpRequest initiatingRequest, >> 936: HttpRequest pushPromiseRequest, >> 937: PushId pushid, > > (Warning: I know little about HTTP, my assumptions and thus whole argument may be invalid below!) > > This feels like users need to use push ids as units of synchronization on this handler, such as tracking this with a ConcurrentHashMap. > > Is it possible for users to instead provide a `Function` in `HttpClient::sendAsync`? I think this might make it easier for users as they no longer need to think about concurrency for different ids. PushId is an HTTP/3 concept. It would be strange to have a generic method (sendAsync) that you could call with any requests, but with a parameter that could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't think we would want to take this route. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054622121 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054623922 From liach at openjdk.org Tue Apr 22 18:50:48 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 22 Apr 2025 18:50:48 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com> References: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com> <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com> Message-ID: On Tue, 22 Apr 2025 18:18:51 GMT, Daniel Fuchs wrote: >> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 357: >> >>> 355: * @since TBD >>> 356: */ >>> 357: public default Builder setOption(HttpRequestOption option, T value) { return this; } >> >> Bikeshed: we usually omit the set prefix for builders. > > I actually hesitated quite a bit on this one. We have a precedent with `Builder.setHeader(name, value)` - where the `setHeader` method replaces any value associated with the name with the given value, while `header(name, value)` would just add another value to the list of values associated with the name. I didn't want to give the impression that you could provide several values to the same option - and thus opted for naming that method `setOption`. I could let me be convinced to rename it if there is a strong concensus. Didn't notice we already use `set` prefix in this builder. All good; consistency is more important. >> src/java.net.http/share/classes/java/net/http/HttpResponse.java line 937: >> >>> 935: HttpRequest initiatingRequest, >>> 936: HttpRequest pushPromiseRequest, >>> 937: PushId pushid, >> >> (Warning: I know little about HTTP, my assumptions and thus whole argument may be invalid below!) >> >> This feels like users need to use push ids as units of synchronization on this handler, such as tracking this with a ConcurrentHashMap. >> >> Is it possible for users to instead provide a `Function` in `HttpClient::sendAsync`? I think this might make it easier for users as they no longer need to think about concurrency for different ids. > > PushId is an HTTP/3 concept. It would be strange to have a generic method (sendAsync) that you could call with any requests, but with a parameter that could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't think we would want to take this route. Do users need to track the push ids in a thread-safe data structure like ConcurrentHashMap in a PushPromiseHandler? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054677703 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054679688 From weijun at openjdk.org Tue Apr 22 18:54:14 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 22 Apr 2025 18:54:14 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v17] In-Reply-To: References: Message-ID: > Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. > ![HPKEParameterSpec ? 11 54 ? 04-21](https://github.com/user-attachments/assets/da309585-db51-40d6-b291-3d38040d6292) Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision: - change argument order for exporters, reject null exporter_context - Merge branch 'master' into 8325448 - address Sean's comments - toString, exportData, spec in HPKEParameters must have algorithm identifiers specified - put encapsulation in params from getParameters - receiver must specify all algorithm identifiers - Merge branch 'master' into 8325448 - remove unused imports - remove disabled identifiers check - getParameters - ... and 20 more: https://git.openjdk.org/jdk/compare/020240b9...15d0b85f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18411/files - new: https://git.openjdk.org/jdk/pull/18411/files/fff8e324..15d0b85f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=15-16 Stats: 332660 lines in 3650 files changed: 82344 ins; 235053 del; 15263 mod Patch: https://git.openjdk.org/jdk/pull/18411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 PR: https://git.openjdk.org/jdk/pull/18411 From abarashev at openjdk.org Tue Apr 22 18:58:58 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 18:58:58 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 86: > 84: public static void main(String[] args) throws Exception { > 85: // re-enable 3DES > 86: Security.setProperty("jdk.tls.disabledAlgorithms", ""); Use `SecurityUtils.removeFromDisabledAlgs` and only remove 3DES from this property. test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 95: > 93: //System.setProperty("javax.net.ssl.keyStorePassword", PASSWORD); > 94: //System.setProperty("javax.net.ssl.trustStore", KEYSTORE); > 95: //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD); Why we don't delete this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054689179 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054690345 From abarashev at openjdk.org Tue Apr 22 19:02:46 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 19:02:46 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com> On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 96: > 94: //System.setProperty("javax.net.ssl.trustStore", KEYSTORE); > 95: //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD); > 96: SSLContext context = new SimpleSSLContext().get(); FYI: We are moving away from using keystore files to generating keystores on the fly as needed. `SimpleSSLContext` is using a keystore file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054695885 From abarashev at openjdk.org Tue Apr 22 19:13:48 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 19:13:48 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. We would need a unit test testing QUIC with `jdk.tls.disabledAlgorithms` and `jdk.certpath.disabledAlgorithms` algorithm constraints in `java.security` file. Those are currently being ignored as far as I can tell.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2822240636 From abarashev at openjdk.org Tue Apr 22 19:13:49 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 19:13:49 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com> References: <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com> Message-ID: On Tue, 22 Apr 2025 18:59:57 GMT, Artur Barashev wrote: >> Hi, >> >> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). >> >> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 96: > >> 94: //System.setProperty("javax.net.ssl.trustStore", KEYSTORE); >> 95: //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD); >> 96: SSLContext context = new SimpleSSLContext().get(); > > FYI: We are moving away from using keystore files to generating keystores on the fly as needed. `SimpleSSLContext` is using a keystore file. `MD5NotAllowedInTLS13CertificateSignature` contains an example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054710098 From dfuchs at openjdk.org Tue Apr 22 19:23:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 22 Apr 2025 19:23:49 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com> <_ZSeC4zTMKKyTWLnkusJQjm5usqAwsC1khEveMwVwnM=.c9918f91-190b-427c-8556-cf2772097e16@github.com> Message-ID: <3dsq7ir0jGHmoyAUr-mtFV5gxoWTj658lUVa7hJizDY=.46e944dd-4ffa-42fc-b877-c3ff4dc156c4@github.com> On Tue, 22 Apr 2025 18:48:06 GMT, Chen Liang wrote: >> PushId is an HTTP/3 concept. It would be strange to have a generic method (sendAsync) that you could call with any requests, but with a parameter that could only be used for HTTP/3. We don't have pushIds for HTTP/2. I don't think we would want to take this route. > > Do users need to track the push ids in a thread-safe data structure like ConcurrentHashMap in a PushPromiseHandler? Yes, they would need to provide a thread safe PushPromisHandler, but not in a way that would be significantly different than how they would need to do it for HTTP/2 server pushes, if they used the same handler with different concurrent requests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054721621 From abarashev at openjdk.org Tue Apr 22 19:38:47 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 22 Apr 2025 19:38:47 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1221: > 1219: tm.checkClientTrusted( > 1220: certs.clone(), > 1221: authType); This call doesn't check against `SSLAlgorithmConstraints` unlike 2 calls for `SSLSocket` and `SSLEngine` above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2054738885 From rhalade at openjdk.org Tue Apr 22 20:32:15 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 22 Apr 2025 20:32:15 GMT Subject: RFR: 8350498: Remove two Camerfirma root CA certificates Message-ID: <2M081CsD83WrCk9PYgmB01CprSr0mr4MB1CP66-847c=.a2b4262a-a020-41c3-9bed-727227739e96@github.com> The change is to remove two Camerfirma root certificates which are terminated and no longer in use. These two roots are removed from `cacerts` truststore. Distrust of these roots is also removed as these roots will no longer be trusted by JDK by default. The release-note is at [JDK-8307129](https://bugs.openjdk.org/browse/JDK-8307129) ------------- Commit messages: - 8350498: Remove two Camerfirma root CA certificates Changes: https://git.openjdk.org/jdk/pull/24800/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24800&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350498 Stats: 235 lines in 7 files changed: 2 ins; 211 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/24800.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24800/head:pull/24800 PR: https://git.openjdk.org/jdk/pull/24800 From weijun at openjdk.org Wed Apr 23 01:06:41 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 23 Apr 2025 01:06:41 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep Message-ID: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> Add more description on password handling into the keytool man page. A link to the man page is now added to the keytool help screen. When keytool output is redirected into a file or file, a warning is shown: $ keytool -genkeypair | type Warning: password will be echoed because output is redirected. Enter keystore password: password Warning: password will be echoed because output is redirected. Re-enter new password: A new manual test is added. Sorry we cannot suppress password echoing in this case at the moment because `System.console()` is not available. ------------- Commit messages: - tests - show warning when echo is on - link and man page changes Changes: https://git.openjdk.org/jdk/pull/24805/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24805&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354469 Stats: 219 lines in 11 files changed: 166 ins; 18 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/24805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24805/head:pull/24805 PR: https://git.openjdk.org/jdk/pull/24805 From jpai at openjdk.org Wed Apr 23 07:58:01 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 23 Apr 2025 07:58:01 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com> References: <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com> Message-ID: On Tue, 22 Apr 2025 16:10:19 GMT, Artur Barashev wrote: >> Hi, >> >> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). >> >> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 366: > >> 364: } >> 365: >> 366: public String chooseServerAlias(String keyType, > > This method should have default (package-private) access modifier. Hello Artur, you are right. This is an overisght and we'll fix this as part of the next refresh of this PR. > src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 375: > >> 373: } >> 374: >> 375: public String chooseClientAlias(String[] keyTypes, Principal[] issuers, > > Same as above, the method shouldn't be public. Agreed. We will address this in the next refresh of the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055469463 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055470483 From jpai at openjdk.org Wed Apr 23 08:02:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 23 Apr 2025 08:02:02 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Tue, 22 Apr 2025 18:56:19 GMT, Artur Barashev wrote: >> Hi, >> >> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). >> >> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 95: > >> 93: //System.setProperty("javax.net.ssl.keyStorePassword", PASSWORD); >> 94: //System.setProperty("javax.net.ssl.trustStore", KEYSTORE); >> 95: //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD); > > Why we don't delete this? This looks like a leftover. I'll remove this as part of the next refresh. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055478076 From jpai at openjdk.org Wed Apr 23 08:05:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 23 Apr 2025 08:05:53 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com> Message-ID: On Tue, 22 Apr 2025 19:11:24 GMT, Artur Barashev wrote: >> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 96: >> >>> 94: //System.setProperty("javax.net.ssl.trustStore", KEYSTORE); >>> 95: //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD); >>> 96: SSLContext context = new SimpleSSLContext().get(); >> >> FYI: We are moving away from using keystore files to generating keystores on the fly as needed. `SimpleSSLContext` is using a keystore file. > > `MD5NotAllowedInTLS13CertificateSignature` contains an example. A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient` currently use this `SimpleSSLContext` construct to read the `testkeys` keystore that's available in the JDK repo's test directory. Moving to a dynamically created keystore instead of a keystore that's committed in the JDK repo seems reasonable. I think it would be better to do that as a separate task in future, since that would involve updating these existing tests to use this new mechanism too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055484535 From myankelevich at openjdk.org Wed Apr 23 10:25:26 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 23 Apr 2025 10:25:26 GMT Subject: RFR: 8277424: javax/net/ssl/TLSCommon/TLSTest.java fails with connection refused Message-ID: <0gF7Q35dOatmUWSzREUx4gTAdWVGcS2D2NYIqzRaNQk=.a53bcfa1-9b71-4532-930a-5e2521d40d77@github.com> I could not replicate the issue after more than 64000 runs. However, I have done the following to increase stability and added logs in case this happens again. Changes: * Specifically binding the client to the loopback address * Added additional debug logging ------------- Commit messages: - JDK-8277424: javax/net/ssl/TLSCommon/TLSTest.java fails with connection refused Changes: https://git.openjdk.org/jdk/pull/24823/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24823&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8277424 Stats: 58 lines in 1 file changed: 0 ins; 0 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/24823.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24823/head:pull/24823 PR: https://git.openjdk.org/jdk/pull/24823 From michaelm at openjdk.org Wed Apr 23 10:51:46 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 23 Apr 2025 10:51:46 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com> References: <1BMZYXMCLuNxUcGFHy9U6TBYd1pChwilCjVOqXwHQT0=.8f352f4f-afec-40fb-90a5-5d1750b5fc45@github.com> Message-ID: On Fri, 18 Apr 2025 18:47:52 GMT, Chen Liang wrote: >> Hi, >> >> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). >> >> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > src/java.net.http/share/classes/java/net/http/HttpResponse.java line 838: > >> 836: /** >> 837: * Represents a HTTP/3 PushID. PushIds can be shared across >> 838: * multiple client initiated requests on the same HTTP/3 connection. > > Is this a marker interface for various kinds of push ids? Otherwise just the record is sufficient. We had to change the API going from HTTP/2 push promise to HTTP/3. So, we want to avoid having to do that again (except where necessary) in any future update to the definition of a Push ID. I think Push Promise is a fairly esoteric aspect of HTTP anyway and won't concern the majority of developers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2055781501 From myankelevich at openjdk.org Wed Apr 23 11:13:47 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 23 Apr 2025 11:13:47 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep In-Reply-To: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> References: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> Message-ID: <_jslQrprpFupRr_fD96Tz0q-IJeICMViCkDPmc6AxyA=.ba39e97d-5e3f-4947-abab-54a3cf7409e2@github.com> On Tue, 22 Apr 2025 22:43:08 GMT, Weijun Wang wrote: > Add more description on password handling into the keytool man page. A link to the man page is now added to the keytool help screen. > > When keytool output is redirected into a file or file, a warning is shown: > > $ keytool -genkeypair | type > > Warning: password will be echoed because output is redirected. > Enter keystore password: password > Warning: password will be echoed because output is redirected. > Re-enter new password: > > > A new manual test is added. > > Sorry we cannot suppress password echoing in this case at the moment because `System.console()` is not available. test/jdk/sun/security/tools/keytool/EchoPassword.java line 1: > 1: /* Do you think using `PassFailJFrame` here might be a simpler solution? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24805#discussion_r2055819289 From abarashev at openjdk.org Wed Apr 23 13:09:48 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 23 Apr 2025 13:09:48 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com> Message-ID: On Wed, 23 Apr 2025 08:03:02 GMT, Jaikiran Pai wrote: >> `MD5NotAllowedInTLS13CertificateSignature` contains an example. > > A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient` currently use this `SimpleSSLContext` construct to read the `testkeys` keystore that's available in the JDK repo's test directory. Moving to a dynamically created keystore instead of a keystore that's committed in the JDK repo seems reasonable. I think it would be better to do that as a separate task in future, since that would involve updating these existing tests to use this new mechanism too. Sounds good, this was just FYI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2056016233 From jpai at openjdk.org Wed Apr 23 13:29:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 23 Apr 2025 13:29:53 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Tue, 22 Apr 2025 18:55:28 GMT, Artur Barashev wrote: >> Hi, >> >> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). >> >> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 86: > >> 84: public static void main(String[] args) throws Exception { >> 85: // re-enable 3DES >> 86: Security.setProperty("jdk.tls.disabledAlgorithms", ""); > > Use `SecurityUtils.removeFromDisabledAlgs` and only remove 3DES from this property. Thank you for pointing to `SecurityUtils`. I updated this test to use that test library and the test continues to work as expected. We will include this change in the next refresh of the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2056058005 From weijun at openjdk.org Wed Apr 23 13:39:00 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 23 Apr 2025 13:39:00 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v2] In-Reply-To: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> References: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> Message-ID: > Add more description on password handling into the keytool man page. A link to the man page is now added to the keytool help screen. > > When keytool output is redirected into a file or file, a warning is shown: > > $ keytool -genkeypair | type > > Warning: password will be echoed because output is redirected. > Enter keystore password: password > Warning: password will be echoed because output is redirected. > Re-enter new password: > > > A new manual test is added. > > Sorry we cannot suppress password echoing in this case at the moment because `System.console()` is not available. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: hide warning when password is piped into the command; enhance test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24805/files - new: https://git.openjdk.org/jdk/pull/24805/files/591fd7f2..89ccc41d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24805&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24805&range=00-01 Stats: 132 lines in 3 files changed: 54 ins; 52 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/24805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24805/head:pull/24805 PR: https://git.openjdk.org/jdk/pull/24805 From myankelevich at openjdk.org Wed Apr 23 14:09:47 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 23 Apr 2025 14:09:47 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v2] In-Reply-To: References: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> Message-ID: On Wed, 23 Apr 2025 13:39:00 GMT, Weijun Wang wrote: >> Add more description on password handling into the keytool man page. A link to the man page is now added to the keytool help screen. >> >> When keytool output is redirected into a file or file, a warning is shown: >> >> $ keytool -genkeypair | type >> >> Warning: password will be echoed because output is redirected. >> Enter keystore password: password >> Warning: password will be echoed because output is redirected. >> Re-enter new password: >> >> >> A new manual test is added. >> >> Sorry we cannot suppress password echoing in this case at the moment because `System.console()` is not available. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > hide warning when password is piped into the command; enhance test test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 630: > 628: long testTimeOut, > 629: int rows, int columns, > 630: List moreButtons, Minor: wouldn't `additinalButtons` or `extraButtons` be a more intuitive name? test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 1470: > 1468: */ > 1469: public Builder addButton(JButton button) { > 1470: if (moreButtons == null) moreButtons = new ArrayList<>(); Nitpick: I'd personally make this as: if (moreButtons == null) { moreButtons = new ArrayList<>(); } just to be consistent with the other if statements in the file and package. But it is perfectly fine as it is. test/jdk/sun/security/tools/keytool/EchoPassword.java line 33: > 31: */ > 32: > 33: import javax.swing.*; Nitpick: wildcard import test/jdk/sun/security/tools/keytool/EchoPassword.java line 65: > 63: > 64: 2. Press "Copy First Command" to copy the first command into the system clipboard. > 65: Paste it into the terminal window and execute the command. I personally think, even with the button, it's better to show the full command itself to the user, just in case whoever is running the test misses the command or accidentally clear/overwrite the clipboard. What do you think ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24805#discussion_r2056108063 PR Review Comment: https://git.openjdk.org/jdk/pull/24805#discussion_r2056139794 PR Review Comment: https://git.openjdk.org/jdk/pull/24805#discussion_r2056116916 PR Review Comment: https://git.openjdk.org/jdk/pull/24805#discussion_r2056112039 From weijun at openjdk.org Wed Apr 23 15:50:59 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 23 Apr 2025 15:50:59 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> References: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> Message-ID: > Add more description on password handling into the keytool man page. A link to the man page is now added to the keytool help screen. > > When keytool output is redirected into a file or file, a warning is shown: > > $ keytool -genkeypair | type > > Warning: password will be echoed because output is redirected. > Enter keystore password: password > Warning: password will be echoed because output is redirected. > Re-enter new password: > > > A new manual test is added. > > Sorry we cannot suppress password echoing in this case at the moment because `System.console()` is not available. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: modify the test to use hyperlinks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24805/files - new: https://git.openjdk.org/jdk/pull/24805/files/89ccc41d..5e0ddfc1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24805&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24805&range=01-02 Stats: 92 lines in 2 files changed: 25 ins; 22 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/24805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24805/head:pull/24805 PR: https://git.openjdk.org/jdk/pull/24805 From ecaspole at openjdk.org Wed Apr 23 16:37:48 2025 From: ecaspole at openjdk.org (Eric Caspole) Date: Wed, 23 Apr 2025 16:37:48 GMT Subject: RFR: 8353478: Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms [v3] In-Reply-To: <3hFUKagMkYaowhCw9wP6jPdwBj4O4DLUwv0-E6S2TG8=.8861fb5c-5cec-4eee-97e0-7e6558c2d6f8@github.com> References: <3hFUKagMkYaowhCw9wP6jPdwBj4O4DLUwv0-E6S2TG8=.8861fb5c-5cec-4eee-97e0-7e6558c2d6f8@github.com> Message-ID: <7YD9f2fZ80EU2QeTK52JC7YVTqrntgHhj0ZRebDbHQ8=.dcd4d1dd-86d7-4f8e-b600-084025b3344c@github.com> On Wed, 9 Apr 2025 19:34:24 GMT, Sergey Kuksenko wrote: >> Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms. > > Sergey Kuksenko has updated the pull request incrementally with three additional commits since the last revision: > > - Update SignatureBench.java > > Specify explicit algorithm and fix copyright typo > - Update KeyPairGeneratorBench.java > > Specify explicit algorithms > - Update KEMBench.java > > Specify explicit algorithm Looks good, thanks. ------------- Marked as reviewed by ecaspole (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24369#pullrequestreview-2788032216 From weijun at openjdk.org Wed Apr 23 16:53:28 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 23 Apr 2025 16:53:28 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v2] In-Reply-To: References: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> Message-ID: <655JzRW2MOjb87ii-z6nNQFp-KrSgIUTZnkVTt9DQgc=.dff30b2b-d801-484d-80b3-73b77b130c98@github.com> On Wed, 23 Apr 2025 13:54:37 GMT, Mikhail Yankelevich wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> hide warning when password is piped into the command; enhance test > > test/jdk/sun/security/tools/keytool/EchoPassword.java line 33: > >> 31: */ >> 32: >> 33: import javax.swing.*; > > Nitpick: wildcard import Will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24805#discussion_r2056496566 From weijun at openjdk.org Wed Apr 23 16:53:28 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 23 Apr 2025 16:53:28 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v4] In-Reply-To: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> References: <6xgKCVlEhef_sVHr2qyCmR5ySOPLVQR2fwS_rgj5aAc=.a2978896-8eea-4a87-8a42-d4e0bfa001c4@github.com> Message-ID: > Add more description on password handling into the keytool man page. A link to the man page is now added to the keytool help screen. > > When keytool output is redirected into a file or file, a warning is shown: > > $ keytool -genkeypair | type > > Warning: password will be echoed because output is redirected. > Enter keystore password: password > Warning: password will be echoed because output is redirected. > Re-enter new password: > > > A new manual test is added. > > Sorry we cannot suppress password echoing in this case at the moment because `System.console()` is not available. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: no more wildcard imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24805/files - new: https://git.openjdk.org/jdk/pull/24805/files/5e0ddfc1..8677312e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24805&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24805&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24805/head:pull/24805 PR: https://git.openjdk.org/jdk/pull/24805 From skuksenko at openjdk.org Wed Apr 23 17:06:59 2025 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Wed, 23 Apr 2025 17:06:59 GMT Subject: Integrated: 8353478: Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms In-Reply-To: References: Message-ID: On Tue, 1 Apr 2025 21:41:57 GMT, Sergey Kuksenko wrote: > Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms. This pull request has now been integrated. Changeset: 35716647 Author: Sergey Kuksenko URL: https://git.openjdk.org/jdk/commit/35716647b531f0c20f9803138dfe2cedd6c4deee Stats: 1938 lines in 10 files changed: 210 ins; 1696 del; 32 mod 8353478: Update crypto microbenchmarks to cover ML-DSA, ML-KEM, and HSS algorithms Reviewed-by: ecaspole ------------- PR: https://git.openjdk.org/jdk/pull/24369 From ascarpino at openjdk.org Wed Apr 23 20:18:49 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 23 Apr 2025 20:18:49 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v3] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 12:54:31 GMT, Nibedita Jena wrote: >> Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). >> While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. >> >> Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. >> According to RFC 3546, the host_name limit allowed is 255. >> With a sample testcase when the host_name length is > 127, exception is thrown: >> javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 >> javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( >> "throwable" : { >> java.lang.NegativeArraySizeException: -1 >> at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) >> at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) >> >> e.g. >> int l = buf.get(); >> b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 >> >> For TLSv1.3, its not an issue until length > 255. >> >> According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. >> Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. > > Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: > > Updated SSLSessionImpl constructor with Record interface methods I will look at this.. At the time I wrote this I avoided using Record for a reason, but I don't remember why right now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24535#issuecomment-2825410613 From weijun at openjdk.org Wed Apr 23 20:26:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 23 Apr 2025 20:26:51 GMT Subject: RFR: 8325513: Export method for Cipher [v5] In-Reply-To: References: Message-ID: > Add `Cipher::exportKey` API. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - Merge branch 'master' into 8325513 - exportData - plural - Merge branch 'master' into 8325513 - small update - Merge branch 'master' into 8325513 - change new method to non final - rename - Merge branch 'master' into 8325513 - make test work - ... and 6 more: https://git.openjdk.org/jdk/compare/cdaab9e7...cd02570c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18409/files - new: https://git.openjdk.org/jdk/pull/18409/files/11701dce..cd02570c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18409&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18409&range=03-04 Stats: 333499 lines in 3636 files changed: 87119 ins; 232474 del; 13906 mod Patch: https://git.openjdk.org/jdk/pull/18409.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18409/head:pull/18409 PR: https://git.openjdk.org/jdk/pull/18409 From wetmore at openjdk.org Wed Apr 23 21:13:57 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 23 Apr 2025 21:13:57 GMT Subject: RFR: 8350582: Correct the parsing of the ssl value in javax.net.debug [v5] In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 15:25:36 GMT, Sean Coffey wrote: >> Breaking the parent JDK-8044609 JBS issue into sub tasks. >> >> This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced. This patch should be easier for backporting also. >> >> Wider corrections can be followed up via parent bug. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Add extra component coverage to test We never did hear from Xuelei, so will go with our best guess, which is that that change introduced a bug, and was not an intentional reversal of behavior as I initially believed. I approve this PR with the strong urging that JDK-8044609 can be fixed in JDK 25, and hopefully backported together. That change should be able to be reviewed quickly, now that we are past this big issue. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23781#pullrequestreview-2788693100 From weijun at openjdk.org Wed Apr 23 22:42:08 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 23 Apr 2025 22:42:08 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: On Thu, 17 Apr 2025 15:51:09 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: > > - javadoc updates > - code review comments Some comments on the new `EncryptedPrivateKeyInfo` APIs. Many trailing periods in `@params` tags can be removed if the descriptions are not full sentences. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 81: > 79: > 80: /** > 81: * Constructs an {@code EncryptedPrivateKeyInfo} from a given Encrypted Why is "E" capitalized? Is it a special term? src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 83: > 81: * Constructs an {@code EncryptedPrivateKeyInfo} from a given Encrypted > 82: * PKCS#8 ASN.1 encoding. > 83: * @param encoded the ASN.1 encoding which is cloned and then parsed. Somehow I prefer the original "The contents of the array...". We've used this style in a lot of places. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 324: > 322: > 323: /** > 324: * Creates and encrypts an {@code EncryptedPrivateKeyInfo} from a given Can we say "encrypt" an "EncryptedPrivateKeyInfo"? It sounds like an already encrypted thing. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 338: > 336: * > 337: * @param key the PrivateKey object to encrypt. > 338: * @param password the password used for generating the PBE key. Do we need to mention the "PBE key"? It's just the password to encrypt the private key. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 341: > 339: * @param algorithm the PBE encryption algorithm. > 340: * @param params the parameters used with the PBE encryption. > 341: * @param provider the Provider that will perform the encryption. I prefer moving (if not copying) the nullable description of `params` and `provider` here. Also, in your implementation, the provider is used to choose both `SecretkeyFactory` and `Cipher`. I hope for each provider there always exists a pair of `SecretkeyFactory` and `Cipher` with a given algorithm name. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 351: > 349: * @implNote The encryption uses the algorithm set by > 350: * `jdk.epkcs8.defaultAlgorithm` Security Property > 351: * and default the {@code AlgorithmParameterSpec} of that provider. I think this `implNote` is not necessary here. You already required `algorithm` to be non-null. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 416: > 414: * {@link PrivateKey} using the {@code encKey} and given parameters. > 415: * > 416: * If {@code algorithm} is {@code null} the default algorithm will be used. In the other `encryptKey` method using password, `algorithm` must be provided. Why the inconsistency? In fact, since you have `encKey`, doesn't it already have an algorithm name? src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 422: > 420: * > 421: * @param key the {@code PrivateKey} object to encrypt. > 422: * @param encKey the encryption {@code Key} It will be more precise if we say `key` is the key to be encrypted and `encKey` is the key used to encrypt `key`. ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2788731077 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2056901657 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2056902408 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2056903380 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2056906894 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2056908199 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2056911191 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2056949605 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2056952122 From ascarpino at openjdk.org Wed Apr 23 23:30:42 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 23 Apr 2025 23:30:42 GMT Subject: RFR: 8272875: Change the default key manager to PKIX In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 17:04:56 GMT, Artur Barashev wrote: > The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check of the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust. Do we understand why this is so much slower? I wouldn't have thought extra checking would cause this big of a performance hit. test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 147: > 145: > 146: KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); > 147: kpg.initialize(2048); I would not specify the key size and let the provider default set it. That could expose any problems between constraints and provider defaults, also it future proofs the test when key sizes are increased some day in the future. ------------- PR Review: https://git.openjdk.org/jdk/pull/24756#pullrequestreview-2788272968 PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2056617930 From coffeys at openjdk.org Thu Apr 24 12:04:56 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 24 Apr 2025 12:04:56 GMT Subject: RFR: 8350582: Correct the parsing of the ssl value in javax.net.debug [v5] In-Reply-To: References: Message-ID: <3RFYdP9GcvU_QsXVXjeDowamyMjaVBBzlP-MXZzjiTc=.78b73d21-c665-47dc-ab9a-40c85a199fd7@github.com> On Thu, 17 Apr 2025 15:25:36 GMT, Sean Coffey wrote: >> Breaking the parent JDK-8044609 JBS issue into sub tasks. >> >> This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced. This patch should be easier for backporting also. >> >> Wider corrections can be followed up via parent bug. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Add extra component coverage to test Thanks Brad - I plan to sync JDK-8044609 PR up with latest changes and restart work on it shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23781#issuecomment-2827363582 From coffeys at openjdk.org Thu Apr 24 12:04:57 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 24 Apr 2025 12:04:57 GMT Subject: Integrated: 8350582: Correct the parsing of the ssl value in javax.net.debug In-Reply-To: References: Message-ID: On Tue, 25 Feb 2025 16:20:59 GMT, Sean Coffey wrote: > Breaking the parent JDK-8044609 JBS issue into sub tasks. > > This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced. This patch should be easier for backporting also. > > Wider corrections can be followed up via parent bug. This pull request has now been integrated. Changeset: 1ec64811 Author: Sean Coffey URL: https://git.openjdk.org/jdk/commit/1ec64811a365442c902e334b56f4cf926c316a4a Stats: 190 lines in 2 files changed: 187 ins; 0 del; 3 mod 8350582: Correct the parsing of the ssl value in javax.net.debug Reviewed-by: wetmore, hchao ------------- PR: https://git.openjdk.org/jdk/pull/23781 From myankelevich at openjdk.org Thu Apr 24 13:40:54 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 24 Apr 2025 13:40:54 GMT Subject: RFR: 8349151: Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test [v2] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 19:12:30 GMT, Mikhail Yankelevich wrote: >> Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Still needs a review ------------- PR Comment: https://git.openjdk.org/jdk/pull/23394#issuecomment-2827667437 From abarashev at openjdk.org Thu Apr 24 14:24:49 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 24 Apr 2025 14:24:49 GMT Subject: RFR: 8272875: Change the default key manager to PKIX In-Reply-To: References: Message-ID: On Wed, 23 Apr 2025 17:54:38 GMT, Anthony Scarpino wrote: >> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust. > > test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 147: > >> 145: >> 146: KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); >> 147: kpg.initialize(2048); > > I would not specify the key size and let the provider default set it. That could expose any problems between constraints and provider defaults, also it future proofs the test when key sizes are increased some day in the future. I see! I'll update the test, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2058574827 From weijun at openjdk.org Thu Apr 24 15:42:41 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 24 Apr 2025 15:42:41 GMT Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 17:17:15 GMT, Valerie Peng wrote: > I will take a look~ Thanks. I have 2 concerns on this feature: 1. These algorithms are mainly used in higher-level algorithms, mainly signature algorithms. It seems seldom used on their owns. But again, even other SHA-3 algorithms are not used a lot. 2. SHAKE128 is both an XOF and a `MessageDigest` algorithm. Although it's well-known that when it is used as a `MessageDigest` algorithm the output size is 256 bits, people might still be confused or simply not aware of it. In this sense, the name might be better SHAKE128-256. Same for SHAKE256, which could be SHAKE256-512. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24576#issuecomment-2828084387 From michaelm at openjdk.org Thu Apr 24 16:43:43 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 24 Apr 2025 16:43:43 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v7] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Review update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23929/files - new: https://git.openjdk.org/jdk/pull/23929/files/da33863c..efabc485 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=05-06 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From dfuchs at openjdk.org Thu Apr 24 16:59:45 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 24 Apr 2025 16:59:45 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2] In-Reply-To: References: Message-ID: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com> > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits: - merge latest changes from master branch - http3: add missing

    separator to Http3DiscoveryMode.ALT_SVC API documentation - http3: improve documentation for Http3DiscoveryMode.ALT_SVC - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test - http3: minor improvement to log message - http3: Artur's review - remove commented out code from test - http3: Artur's review - make methods package private - http3: qpack - allow 0 capacity when max capacity is 0 - Remove flow control from stream limit comments - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=01 Stats: 102765 lines in 470 files changed: 100142 ins; 1119 del; 1504 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From mpowers at openjdk.org Thu Apr 24 17:28:05 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 24 Apr 2025 17:28:05 GMT Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException when offset is negative Message-ID: [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113) ------------- Commit messages: - first iteration Changes: https://git.openjdk.org/jdk/pull/24854/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24854&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351113 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24854.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24854/head:pull/24854 PR: https://git.openjdk.org/jdk/pull/24854 From abarashev at openjdk.org Thu Apr 24 18:06:56 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 24 Apr 2025 18:06:56 GMT Subject: RFR: 8355262: Test sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java failed: accept timed out Message-ID: Increasing the server's "accept" call time-out value from 5 to 10 seconds. ------------- Commit messages: - 8355262: Test sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java failed: accept timed out Changes: https://git.openjdk.org/jdk/pull/24857/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24857&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355262 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24857/head:pull/24857 PR: https://git.openjdk.org/jdk/pull/24857 From abarashev at openjdk.org Thu Apr 24 18:30:00 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 24 Apr 2025 18:30:00 GMT Subject: RFR: 8272875: Change the default key manager to PKIX [v2] In-Reply-To: References: Message-ID: > The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust. > > Compatibility considerations: > > 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file. > > 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake: > > **SUNX509** > Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units > SSLHandshake.doHandshake true TLSv1.2 thrpt 15 19758.012 ? 758.237 ops/s > SSLHandshake.doHandshake true TLS thrpt 15 1861.695 ? 14.681 ops/s > SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **1186.962** ? 12.085 ops/s > SSLHandshake.doHandshake false TLS thrpt 15 **1056.288** ? 7.197 ops/s > Finished running test 'micro:java.security.SSLHandshake' > > **PKIX** > Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units > SSLHandshake.doHandshake true TLSv1.2 thrpt 15 19724.887 ? 393.636 ops/s > SSLHandshake.doHandshake true TLS thrpt 15 1848.927 ? 22.946 ops/s > SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **511.684** ? 5.405 ops/s > SSLHandshake.doHandshake false TLS thrpt 15 **490.698** ? 6.453 ops/s > Finished running test 'micro:java.security.SSLHandshake' Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Skip explicit KeyPair initialization and let the provider default set it ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24756/files - new: https://git.openjdk.org/jdk/pull/24756/files/19a2ad1d..e5e83514 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24756/head:pull/24756 PR: https://git.openjdk.org/jdk/pull/24756 From weijun at openjdk.org Thu Apr 24 18:49:15 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 24 Apr 2025 18:49:15 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: On Thu, 17 Apr 2025 15:51:09 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: > > - javadoc updates > - code review comments Some comments on the `PEMxyz` classes. src/java.base/share/classes/java/security/PEMDecoder.java line 60: > 58: * A specified return class must implement {@link DEREncodable} and be an > 59: * appropriate JCE object class for the PEM; otherwise an > 60: * {@link IllegalArgumentException} is thrown. Do we need to document somewhere what "appropriate" JCE classes are for each PEM type? src/java.base/share/classes/java/security/PEMDecoder.java line 213: > 211: Objects.requireNonNull(str); > 212: try { > 213: return decode(new ByteArrayInputStream(str.getBytes())); Does `getBytes` require a charset argument? The only thing I'm concerned is someone put UTF-8 chars before the PEM block. I think we've seen certificates containing subject or issuer names there and they are not ASCII. Shall we document the encoding of leading data in `PEMRecord`? src/java.base/share/classes/java/security/PEMDecoder.java line 398: > 396: * Returns a new {@code PEMDecoder} instance from the current instance > 397: * configured to decrypt encrypted PEM data with given password. > 398: * Non-encrypted PEM may still be decoded from this instance. I assume that if users want to use a non-default cipher provider they should decode as `EncryptedPrivateKeyInfo` first and it has more sophisticated methods there. Do we need to document about this here? src/java.base/share/classes/java/security/PEMEncoder.java line 120: > 118: > 119: /** > 120: * Returns an instance of PEMEncoder. Do we need to say "simple" or "normal" or "raw" `PEMEncoder` here? Just to be clear that it does not do any encryption. src/java.base/share/classes/java/security/PEMEncoder.java line 134: > 132: private String pemEncoded(PEMRecord pem) { > 133: StringBuilder sb = new StringBuilder(1024); > 134: sb.append("-----BEGIN ").append(pem.type()).append("-----"); So you throw away the leading data? Shall we document this somewhere? src/java.base/share/classes/java/security/PEMEncoder.java line 175: > 173: throw new IllegalArgumentException("KeyPair does not " + > 174: "contain PrivateKey."); > 175: } Do we really need to care about whether the private part or the public part is null? src/java.base/share/classes/java/security/PEMEncoder.java line 235: > 233: */ > 234: public byte[] encode(DEREncodable de) { > 235: return encodeToString(de).getBytes(StandardCharsets.ISO_8859_1); Which operation is lighter? Have you considered letting `pemEncoded` to return a byte array and converting it into a string in `encodeToString()`? src/java.base/share/classes/java/security/PEMEncoder.java line 279: > 277: if (keySpec != null) { > 278: // For thread safety > 279: lock.lock(); How much does this lock buy? If someone provides a password, I assume they will use it anyway. src/java.base/share/classes/java/security/PEMEncoder.java line 287: > 285: keySpec = null; > 286: } catch (GeneralSecurityException e) { > 287: throw new SecurityException("Security property " + Let's discuss whether to use `SecurityException` here. I would use `ProviderException`. src/java.base/share/classes/java/security/PEMEncoder.java line 300: > 298: // If `key` is non-null, this is an encoder ready to encrypt. > 299: if (key != null) { > 300: if (privateBytes == null || publicBytes != null) { `publicBytes` cannot be null here. You rejected both being null at the beginning of this method. src/java.base/share/classes/java/security/PEMRecord.java line 61: > 59: * RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures > 60: */ > 61: public record PEMRecord(String type, String pem, byte[] leadingData) How about using the raw byte data instead of the `pem` string? This would automatically reject all format problems, like extra newline at the end, too wide string, and invalid Base64 chars. Also, two `PEMRecord` should equal to each other even if they are encoded differently (for example, different width). Also, how about forcing all fields to be non null? If there is no leading bytes, use an empty array. I cannot imagine how data could be empty. src/java.base/share/classes/java/security/PEMRecord.java line 79: > 77: * @param pem The data between the PEM header and footer. > 78: * @param leadingData Any non-PEM data read during the decoding process > 79: * before the PEM header. This value maybe {@code null}. Do we need to say if `leadingData` contains the final newline char? src/java.base/share/classes/java/security/PEMRecord.java line 95: > 93: // including lowercase. The onus is on the caller. > 94: if (type != null && type.startsWith("-----")) { > 95: // Remove PEM headers syntax if present. I don't think we need to be so tolerant at the beginning. Just reject it. src/java.base/share/classes/java/security/PEMRecord.java line 135: > 133: /** > 134: * Returns the binary encoding from the Base64 data contained in > 135: * {@code pem}. The name does not sound correct to me. PEM encodes binary data to an ASCII string, so "encoding" is the ASCII string. How about just `getData`? ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2792041040 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2059012734 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2059031256 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2059036057 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2058988622 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2058978573 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2058995881 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2058985486 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2058997407 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2059003315 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2059001002 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2058954734 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2058957229 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2058962946 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2058953881 From abarashev at openjdk.org Thu Apr 24 19:05:05 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 24 Apr 2025 19:05:05 GMT Subject: RFR: 8272875: Change the default key manager to PKIX [v2] In-Reply-To: References: Message-ID: On Wed, 23 Apr 2025 23:28:29 GMT, Anthony Scarpino wrote: > Do we understand why this is so much slower? I wouldn't have thought extra checking would cause this big of a performance hit. Yes, it looks that way. `SunX509` KeyManager is really simple, so adding certificate validation can decrease the performance significantly. The discussion of #17956 contains an extensive performance analyses. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2828599943 From djelinski at openjdk.org Thu Apr 24 19:17:47 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 24 Apr 2025 19:17:47 GMT Subject: RFR: 8272875: Change the default key manager to PKIX [v2] In-Reply-To: References: Message-ID: <1wkSzYpzruxGnsBswCgGt-VW-MusNzCIIQ_hHF9WAmI=.f3f22c74-2dae-415c-8dba-814c78df6029@github.com> On Thu, 24 Apr 2025 18:30:00 GMT, Artur Barashev wrote: >> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust. >> >> Compatibility considerations: >> >> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file. >> >> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake: >> >> **SUNX509** >> Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units >> SSLHandshake.doHandshake true TLSv1.2 thrpt 15 19758.012 ? 758.237 ops/s >> SSLHandshake.doHandshake true TLS thrpt 15 1861.695 ? 14.681 ops/s >> SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **1186.962** ? 12.085 ops/s >> SSLHandshake.doHandshake false TLS thrpt 15 **1056.288** ? 7.197 ops/s >> Finished running test 'micro:java.security.SSLHandshake' >> >> **PKIX** >> Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units >> SSLHandshake.doHandshake true TLSv1.2 thrpt 15 19724.887 ? 393.636 ops/s >> SSLHandshake.doHandshake true TLS thrpt 15 1848.927 ? 22.946 ops/s >> SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **511.684** ? 5.405 ops/s >> SSLHandshake.doHandshake false TLS thrpt 15 **490.698** ? 6.453 ops/s >> Finished running test 'micro:java.security.SSLHandshake' > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Skip explicit KeyPair initialization and let the provider default set it > The discussion of https://github.com/openjdk/jdk/pull/17956 contains an extensive performance analyses. TL;DR: PKCS12 decrypts the private key before every use. The performance hit comes from applying PBKDF2 to the key encryption password. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2828625887 From duke at openjdk.org Thu Apr 24 19:47:09 2025 From: duke at openjdk.org (Bernd) Date: Thu, 24 Apr 2025 19:47:09 GMT Subject: RFR: 8322767: TLS full handshake is slow with PKCS12KeyStore and X509KeyManagerImpl [v3] In-Reply-To: <_dE1fveXXmnKOJ6V3HWh-KGqvTBbLO0ha5y2dCC2ZQY=.8aaa2b49-7300-4ef5-8532-72fe49454da1@github.com> References: <_dE1fveXXmnKOJ6V3HWh-KGqvTBbLO0ha5y2dCC2ZQY=.8aaa2b49-7300-4ef5-8532-72fe49454da1@github.com> Message-ID: On Wed, 27 Mar 2024 09:18:06 GMT, Daniel Jeli?ski wrote: > Well this PR doesn't introduce new bugs, but it exacerbates a preexisting one. while it might be out of scope, but the trouble of caching keystores might also suggest that a better API support would be helpful. Be it a change callback or a per entry cache or similar. Anything which makes long term usage of keystores or key managers less tricky. BTW I agree the performance regression is a bitter pill. Especially if you look at real world scenarios where the key(store) password is most of the time a pro forms cleartext parameter next to the P12 file anyway making the protection not even useful. Gru? Bernd ------------- PR Comment: https://git.openjdk.org/jdk/pull/17956#issuecomment-2828686759 From mr at openjdk.org Thu Apr 24 20:18:09 2025 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 24 Apr 2025 20:18:09 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: On Thu, 17 Apr 2025 15:51:09 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: > > - javadoc updates > - code review comments Changes requested by mr (Lead). src/java.base/share/classes/java/security/PEMDecoder.java line 78: > 76: * > 77: *

    {@code String} values returned by this class use character set > 78: * {@link java.nio.charset.StandardCharsets#ISO_8859_1 ISO-8859-1} `String` values in Java are always encoded in UTF-16. Did you mean to write something like, "Byte streams consumed by methods in this class are assumed to represent characters encoded in the ISO-8859-1 charset" ? src/java.base/share/classes/java/security/PEMDecoder.java line 84: > 82: * 

    > 83:  *     PEMDecoder pd = PEMDecoder.of();
> 84:  *     PrivateKey priKey = pd.decode(PriKeyPEM);

s/PriKeyPEM/priKeyPEM/

src/java.base/share/classes/java/security/PEMDecoder.java line 213:

> 211:         Objects.requireNonNull(str);
> 212:         try {
> 213:             return decode(new ByteArrayInputStream(str.getBytes()));

`str.getBytes()` will return a byte array encoded in the default charset, which these days is likely to be UTF-8, but might be something completely bizarre. You probably want `str.getBytes(StandardCharsets.ISO_8859_1)`.

It could be worth running your unit tests in several different locales in order to catch similar issues.

src/java.base/share/classes/java/security/PEMEncoder.java line 74:

> 72:  *
> 73:  * 
    {@code String} values returned by this class use character set
> 74:  * {@link java.nio.charset.StandardCharsets#ISO_8859_1 ISO-8859-1}.

As above, did you mean to write something like, "Byte arrays returned by methods in this class represent characters encoded using the ISO-8859-1 charset" ?

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

PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2792362333
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2059147360
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2059147944
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2059152266
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2059157190

From weijun at openjdk.org  Thu Apr 24 21:24:49 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 24 Apr 2025 21:24:49 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v18]
In-Reply-To: 
References: 
Message-ID: 

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> ![HPKEParameterSpec ? 11 54 ? 04-21](https://github.com/user-attachments/assets/da309585-db51-40d6-b291-3d38040d6292)

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  engineGetBlockSize and engineGetOutputSize returns 0 when not initialized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/15d0b85f..a4f59e38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=16-17

  Stats: 7 lines in 2 files changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411

PR: https://git.openjdk.org/jdk/pull/18411

From weijun at openjdk.org  Thu Apr 24 22:12:48 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 24 Apr 2025 22:12:48 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v15]
In-Reply-To: <0NVi830Oojpm9CKsu8W36dkIvJZcVrJUEI2nx88pPAk=.4ab143b6-3b6a-42c9-9b08-0c85f8c8c74f@github.com>
References: 
 
 
 
 <0NVi830Oojpm9CKsu8W36dkIvJZcVrJUEI2nx88pPAk=.4ab143b6-3b6a-42c9-9b08-0c85f8c8c74f@github.com>
Message-ID: 

On Mon, 21 Apr 2025 15:24:37 GMT, Weijun Wang  wrote:

>> Consider adding a String or Enum argument to `of()` with the name of the profile, ex "RFC9180".
>
> I can add a sentence saying if an implementation does not provide default numeric algorithm identifiers then an exception will be thrown if `of()` is used by the sender.
> 
> I still think it's useful to provide defaults. Now that the recipient requires the numeric algorithm identifiers to be provided, at least this will no longer be an interop issue between implementations. As for future new KEM or KDF algorithms for EC/XDH keys, I believe they will have different numeric algorithm identifiers and users can just specify them so there will be need for "HPKE2".
> 
> In fact, suppose the current `kem_id` for XDH is found insecure one day and a new one is defined, we can update the `@implNote` to make the new one the default. Those using `of()` will automatically switch to the safer one and there is no need to update the code. That said, this does need both sides supporting the new `kem_id`.

I?d prefer requiring callers to explicitly specify the three algorithm identifiers rather than introducing profile names. There are several reasons for this:

1. Clarity and consistency: These identifiers are standardized and maintained by IANA in a single registry, making them familiar and unambiguous for all HPKE implementers.
2. Profiles are not precise enough: RFC 9180 allows multiple combinations of algorithm identifiers for a single key type. We'd still need to define what the default is within this profile, which defeats the purpose of using the profile name as a shortcut.
3. Profiles are mainly for new key types: Future profiles will most likely be introduced for new key algorithms (e.g., "RFC9180" for EC/XDH, "draft-connolly-cfrg-xwing-kem" for X-Wing, and "draft-connolly-cfrg-hpke-mlkem" for ML-KEM). Unless a profile defines new combinations for existing key types, it?s not necessary to require users to select among profile names at all. On the other hand, I assume we don?t want to introduce default profiles for key algorithms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2059310549

From myankelevich at openjdk.org  Thu Apr 24 23:23:51 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 24 Apr 2025 23:23:51 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests [v3]
In-Reply-To: <_WldHL5Zc68N5B0x4KUpoumcUV2lbgWzSdPZXRBqqYY=.07799f18-3204-4310-8712-c91bd916c165@github.com>
References: 
 <_WldHL5Zc68N5B0x4KUpoumcUV2lbgWzSdPZXRBqqYY=.07799f18-3204-4310-8712-c91bd916c165@github.com>
Message-ID: 

On Thu, 27 Mar 2025 16:55:01 GMT, Mikhail Yankelevich  wrote:

>> 8351566: Consolidate third party artifacts used in tests
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fernando's comments:
>   
>   * cleanup

Still needs a review

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

PR Comment: https://git.openjdk.org/jdk/pull/23988#issuecomment-2829058958

From skuksenko at openjdk.org  Thu Apr 24 23:28:00 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Thu, 24 Apr 2025 23:28:00 GMT
Subject: RFR: 8355559: Benchmark modification/extension shouldn't affect the
 behavior of other benchmarks
Message-ID: 

Benchmark modification/extension shouldn't affect the behavior of other benchmarks.
Precisely: [JDK-8344144](https://bugs.openjdk.org/browse/JDK-8344144) modified AESBench in that way, which caused significant changes in the behavior of other benchmarks that extend AESBench.

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

Commit messages:
 - JDK-8355559
 - JDK-8355559

Changes: https://git.openjdk.org/jdk/pull/24863/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24863&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355559
  Stats: 116 lines in 2 files changed: 92 ins; 21 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24863/head:pull/24863

PR: https://git.openjdk.org/jdk/pull/24863

From fferrari at openjdk.org  Thu Apr 24 23:47:44 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 24 Apr 2025 23:47:44 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v3]
In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
Message-ID: 

> Hi, this is a proposal to fix 8352728.
> 
> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following:
> 
> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
> 
> #### Windows Case
> 
> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
> 
> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/java.base/windows/native/libjava/c...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  Reintroduce links test using directory junctions
  
  Junctions do not require elevation, so this is a way of testing
  soft-links are resolved without requiring elevation. This is useful
  because we need to avoid elevation in order to reproduce the parent
  directories permission issue.
  
  This is testing directories structure:
  
   ? JDK-8352728-tmp-*/
   ??? jdk-parent-dir/         (ACL with REMOVED-PERMISSIONS)
   ? ??? jdk/
   ?   ??? conf/
   ?   ? ??? security/
   ?   ? ? ??? java.security
   ?   ? ? ?    ? include link-to-other-dir/other.properties
   ?   ? ? ??? link-to-other-dir/ ? ? JDK-8352728-tmp-*/other-dir
   ?   ? ? ??...               (JUNCTION)
   ?   ? ??...
   ?   ??...
   ??? other-dir/
   ? ??? other.properties
   ?      ? include ../relatively.included.properties
   ??? relatively.included.properties
        ? test.property.name=test_property_value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24465/files
  - new: https://git.openjdk.org/jdk/pull/24465/files/a8c5ca74..7abb62c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24465&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24465&range=01-02

  Stats: 64 lines in 1 file changed: 60 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24465/head:pull/24465

PR: https://git.openjdk.org/jdk/pull/24465

From jpai at openjdk.org  Fri Apr 25 02:20:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Apr 2025 02:20:54 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: 
References: 
 <9Sltn-rHaM-4yCCjxAV52Wuc2-j-Q6brdwZyP30551c=.6de1542e-d123-4b37-a199-7675c5c1d2f2@github.com>
 
Message-ID: 

On Wed, 23 Apr 2025 07:54:39 GMT, Jaikiran Pai  wrote:

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 366:
>> 
>>> 364:     }
>>> 365: 
>>> 366:     public String chooseServerAlias(String keyType,
>> 
>> This method should have default (package-private) access modifier.
>
> Hello Artur, you are right. This is an overisght and we'll fix this as part of the next refresh of this PR.

This is now addressed in the latest update to this PR.

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 375:
>> 
>>> 373:     }
>>> 374: 
>>> 375:     public String chooseClientAlias(String[] keyTypes, Principal[] issuers,
>> 
>> Same as above, the method shouldn't be public.
>
> Agreed. We will address this in the next refresh of the PR.

This is now addressed in the latest update to this PR.

>> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 86:
>> 
>>> 84:     public static void main(String[] args) throws Exception {
>>> 85:         // re-enable 3DES
>>> 86:         Security.setProperty("jdk.tls.disabledAlgorithms", "");
>> 
>> Use `SecurityUtils.removeFromDisabledAlgs` and only remove 3DES from this property.
>
> Thank you for pointing to `SecurityUtils`. I updated this test to use that test library and the test continues to work as expected. We will include this change in the next refresh of the PR.

This too is now addressed in the latest update to this PR.

>> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 95:
>> 
>>> 93:         //System.setProperty("javax.net.ssl.keyStorePassword", PASSWORD);
>>> 94:         //System.setProperty("javax.net.ssl.trustStore", KEYSTORE);
>>> 95:         //System.setProperty("javax.net.ssl.trustStorePassword", PASSWORD);
>> 
>> Why we don't delete this?
>
> This looks like a leftover. I'll remove this as part of the next refresh.

Addressed in the latest update to this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464244
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464328
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464619
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2059464758

From fguallini at openjdk.org  Fri Apr 25 08:41:52 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Fri, 25 Apr 2025 08:41:52 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v4]
In-Reply-To: 
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 
Message-ID: 

On Fri, 21 Mar 2025 12:00:57 GMT, Fernando Guallini  wrote:

>> The following tests are marked with @ignore (not running):
>> 
>> - sun/security/ssl/SSLSocketImpl/SetClientMode.java: it checks that setting the clientMode after the handshake has begun is not permitted, but this was failing intermittently due to a race condition, it was possible that SetClientMode was called before the client socket was updated with handshake isNegotiated = true. The fix is to introduce a latch to sync between client and main threads. Included additional refactoring to ensure test stability.
>> 
>> - sun/security/ssl/SSLSocketImpl/NonAutoClose.java: This test should only run in TLS <= 1.2, as TLSv1.3 changes the behaviour of close_notify. Included additional refactoring to ensure test stability.
>> 
>> Executed both tests 10K times, no test flakiness found
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   using assertThrows

Please, this needs a reviewer's approval

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

PR Comment: https://git.openjdk.org/jdk/pull/23898#issuecomment-2829754170

From djelinski at openjdk.org  Fri Apr 25 10:43:57 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 25 Apr 2025 10:43:57 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 21:35:36 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo the special workaround for JSSE in PKCS11 HKDF impl.

still LGTM.

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 260:

> 258:                 if (eae_prk instanceof SecretKeySpec s) {
> 259:                     SharedSecrets.getJavaxCryptoSpecAccess()
> 260:                             .clearSecretKeySpec(s);

I wish we could use `s.destroy()` here instead.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24393#pullrequestreview-2793711649
PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2059999631

From weijun at openjdk.org  Fri Apr 25 13:29:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 25 Apr 2025 13:29:04 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
Message-ID: 

On Thu, 17 Apr 2025 15:51:09 GMT, Anthony Scarpino  wrote:

>> Hi all,
>> 
>> I need a code review of the PEM API.  Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates.  It will be integrated into JDK24 as a Preview Feature.  Preview features does not permanently define the API and it is subject to change in future releases until it is finalized.
>> 
>> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - javadoc updates
>  - code review comments

Some comments on internal classes.

Since each `KeyFactory` now accepts PKCS8 in `generatePublicKey`, I suggest adding some tests on it. Also, add some tests to check if `new PKCS8EncodedKeySpec(data)` and `new X509EncodedKeySpec(data)` are able to detect algorithms from only data.

src/java.base/share/classes/sun/security/ec/ECKeyFactory.java line 225:

> 223:         throws GeneralSecurityException {
> 224:         if (keySpec instanceof X509EncodedKeySpec) {
> 225:             return new ECPublicKeyImpl(((X509EncodedKeySpec)keySpec).getEncoded());

We can also use `instanceof` pattern matching here. Same on line 246.

src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 157:

> 155:     }
> 156: 
> 157:     public byte[] getArrayS() {

Why remove `getArrayS0`? Not worth saving those bytes?

src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 191:

> 189:                 DerValue value = data.getDerValue();
> 190:                 if (value.isContextSpecific((byte) 0)) {
> 191:                     attributes = value.getDataBytes();  // Save DER sequence

At [0], it's `ECDomainParameters`. I don't think it's the same as `attributes` inside `OneAsymmetricKey`.

src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 195:

> 193:                         return;
> 194:                     }
> 195:                     value = data.getDerValue();

The original code does not care about whether [0] comes before [1] or if there are duplicates. You modified code ensures only [1] can be after [0] but still allows duplicates (For example, [0], [1], [1]). The `while` on line 188 can be changed to `if` and we ensure `data.available() == 0` at the end.

src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 201:

> 199:                     BitArray bitArray = bits.data.getUnalignedBitString();
> 200:                     pubKeyEncoded = new X509Key(algid,
> 201:                         bitArray).getEncoded();

We could have 2 copies of the public key, one here and one inside `OneAsymmetricKey`. Do you want to compare them?

src/java.base/share/classes/sun/security/util/DerValue.java line 195:

> 193: 
> 194:     /**
> 195:      * Returns true if the CONTEXT SPECIFIC bit is set in the type tag.

`iff` was used to mean `if and only if`. It's more precise than a simple `if`.

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

PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2793998438
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2060169867
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2060231627
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2060222850
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2060212787
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2060201102
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2060236284

From michaelm at openjdk.org  Fri Apr 25 14:26:43 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Apr 2025 14:26:43 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v8]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov 
 - doc + copyright update
 - remove file added by mistake
 - ... and 12 more: https://git.openjdk.org/jdk/compare/5c067232...9401d4c8

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=07
  Stats: 949 lines in 42 files changed: 716 ins; 101 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From myankelevich at openjdk.org  Fri Apr 25 14:59:59 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 25 Apr 2025 14:59:59 GMT
Subject: RFR: 8355559: Benchmark modification/extension shouldn't affect
 the behavior of other benchmarks
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 23:23:50 GMT, Sergey Kuksenko  wrote:

> Benchmark modification/extension shouldn't affect the behavior of other benchmarks.
> Precisely: [JDK-8344144](https://bugs.openjdk.org/browse/JDK-8344144) modified AESBench in that way, which caused significant changes in the behavior of other benchmarks that extend AESBench.

test/micro/org/openjdk/bench/javax/crypto/full/AESExtraBench.java line 59:

> 57: 
> 58:     @Setup
> 59:     public void setup() throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, BadPaddingException, IllegalBlockSizeException, InvalidAlgorithmParameterException, InvalidParameterSpecException {

Nitpick: do you think something like this would be easier to read? 
Suggestion:

    public void setup() throws NoSuchAlgorithmException, 
                    NoSuchPaddingException, 
                    InvalidKeyException, 
                    BadPaddingException, 
                    IllegalBlockSizeException, 
                    InvalidAlgorithmParameterException, 
                    InvalidParameterSpecException {

test/micro/org/openjdk/bench/javax/crypto/full/AESExtraBench.java line 64:

> 62:     }
> 63: 
> 64: //    @Benchmark

Nitpick: is this method and ` public byte[] decrypt()` intended to be commented out?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24863#discussion_r2060405666
PR Review Comment: https://git.openjdk.org/jdk/pull/24863#discussion_r2060364124

From skuksenko at openjdk.org  Fri Apr 25 15:25:11 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Fri, 25 Apr 2025 15:25:11 GMT
Subject: RFR: 8355559: Benchmark modification/extension shouldn't affect
 the behavior of other benchmarks [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 14:56:56 GMT, Mikhail Yankelevich  wrote:

>> Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update AESExtraBench.java
>
> test/micro/org/openjdk/bench/javax/crypto/full/AESExtraBench.java line 59:
> 
>> 57: 
>> 58:     @Setup
>> 59:     public void setup() throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, BadPaddingException, IllegalBlockSizeException, InvalidAlgorithmParameterException, InvalidParameterSpecException {
> 
> Nitpick: do you think something like this would be easier to read? 
> Suggestion:
> 
>     public void setup() throws NoSuchAlgorithmException, 
>                     NoSuchPaddingException, 
>                     InvalidKeyException, 
>                     BadPaddingException, 
>                     IllegalBlockSizeException, 
>                     InvalidAlgorithmParameterException, 
>                     InvalidParameterSpecException {

I keep the previous code without changing it.

> test/micro/org/openjdk/bench/javax/crypto/full/AESExtraBench.java line 64:
> 
>> 62:     }
>> 63: 
>> 64: //    @Benchmark
> 
> Nitpick: is this method and ` public byte[] decrypt()` intended to be commented out?

Thank you for pointing this out. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24863#discussion_r2060449026
PR Review Comment: https://git.openjdk.org/jdk/pull/24863#discussion_r2060448206

From skuksenko at openjdk.org  Fri Apr 25 15:25:11 2025
From: skuksenko at openjdk.org (Sergey Kuksenko)
Date: Fri, 25 Apr 2025 15:25:11 GMT
Subject: RFR: 8355559: Benchmark modification/extension shouldn't affect
 the behavior of other benchmarks [v2]
In-Reply-To: 
References: 
Message-ID: 

> Benchmark modification/extension shouldn't affect the behavior of other benchmarks.
> Precisely: [JDK-8344144](https://bugs.openjdk.org/browse/JDK-8344144) modified AESBench in that way, which caused significant changes in the behavior of other benchmarks that extend AESBench.

Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision:

  Update AESExtraBench.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24863/files
  - new: https://git.openjdk.org/jdk/pull/24863/files/9e8c2d6e..3efee852

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24863&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24863&range=00-01

  Stats: 14 lines in 1 file changed: 0 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24863/head:pull/24863

PR: https://git.openjdk.org/jdk/pull/24863

From weijun at openjdk.org  Fri Apr 25 15:43:48 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 25 Apr 2025 15:43:48 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Apr 2025 21:35:36 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo the special workaround for JSSE in PKCS11 HKDF impl.

src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 131:

> 129: 
> 130:             // derive handshake secret
> 131:             return hkdf.deriveKey(type, HKDFParameterSpec.ofExtract()

The line above may fail because the `hkdf` object has been used once on line 121 with zero-valued salt and IKM, which selected the software-based HKDF from SunJCE. At this point, however, `sharedSecret` is the result of ECDH and may be non-extractable if produced by an HSM, making it incompatible with the SunJCE implementation. To avoid this issue, get a new `hkdf` by calling `hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm)` before this line.

src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 851:

> 849:             return hkdf.deriveKey("TlsBinderKey",
> 850:                     HKDFParameterSpec.expandOnly(earlySecret, hkdfInfo,
> 851:                     hashAlg.hashLength));

Is it possible to combine the 2 `deriveKey` calls above into a single Extract-Then-Expand call? Then you don't need to clean up `earlySecret`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2060472356
PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2060479191

From valeriep at openjdk.org  Fri Apr 25 18:25:59 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 25 Apr 2025 18:25:59 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 25 Apr 2025 10:40:47 GMT, Daniel Jeli?ski  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Undo the special workaround for JSSE in PKCS11 HKDF impl.
>
> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 260:
> 
>> 258:                 if (eae_prk instanceof SecretKeySpec s) {
>> 259:                     SharedSecrets.getJavaxCryptoSpecAccess()
>> 260:                             .clearSecretKeySpec(s);
> 
> I wish we could use `s.destroy()` here instead.

Yes, it'd be nice. I reopened https://bugs.openjdk.org/browse/JDK-8160206 and we can address this separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2060697742

From valeriep at openjdk.org  Fri Apr 25 18:43:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 25 Apr 2025 18:43:02 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <3wJzRt1gIuHQVATNvjiiGQdEJyS7pqVrQPDQW_yzTE4=.ac3baed9-5659-4c85-ac6c-94240e8d5ee6@github.com>

On Fri, 25 Apr 2025 15:36:26 GMT, Weijun Wang  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Undo the special workaround for JSSE in PKCS11 HKDF impl.
>
> src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 131:
> 
>> 129: 
>> 130:             // derive handshake secret
>> 131:             return hkdf.deriveKey(type, HKDFParameterSpec.ofExtract()
> 
> The line above may fail because the `hkdf` object has been used once on line 121 with zero-valued salt and IKM, which selected the software-based HKDF from SunJCE. At this point, however, `sharedSecret` is the result of ECDH and may be non-extractable if produced by an HSM, making it incompatible with the SunJCE implementation. To avoid this issue, get a new `hkdf` by calling `hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm)` before this line.

Hmm, ok, interesting scenario. I add another `KDF.getInstance()` call as you suggested just to be safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2060720014

From abarashev at openjdk.org  Fri Apr 25 19:09:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:09:55 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: 

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
     separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 192:

> 190:      */
> 191:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
> 192:                                         String[] allowedAlgorithms,

This should probably be renamed to `supportedAlgorithms` for consistency, to match SSLEngine and SSLSocket methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2060758541

From valeriep at openjdk.org  Fri Apr 25 19:10:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 25 Apr 2025 19:10:55 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 25 Apr 2025 15:41:09 GMT, Weijun Wang  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Undo the special workaround for JSSE in PKCS11 HKDF impl.
>
> src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 851:
> 
>> 849:             return hkdf.deriveKey("TlsBinderKey",
>> 850:                     HKDFParameterSpec.expandOnly(earlySecret, hkdfInfo,
>> 851:                     hashAlg.hashLength));
> 
> Is it possible to combine the 2 `deriveKey` calls above into a single Extract-Then-Expand call? Then you don't need to clean up `earlySecret`.

Should be possible, let me give it a try. Thanks~

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2060758979

From abarashev at openjdk.org  Fri Apr 25 19:15:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:15:59 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: 

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
     separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 172:

> 170:             userSpecifiedConstraints = engine.getSSLParameters()
> 171:                     .getAlgorithmConstraints();
> 172:         }

Duplicate code block here and in the 2nd `forQUIC` method. We should move it to a private `getUserSpecifiedConstraints` method, like in SSLEngine and SSLSocket cases. In fact I think all 3 methods could be combined into a single `getUserSpecifiedConstraints(Object o)` since they all do the same thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2060764346

From abarashev at openjdk.org  Fri Apr 25 19:33:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:33:00 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: <04qyL7y-HmZj4Z_m1tc--rIZHU9aJlczhSGBQCVkWxc=.b4f05b83-6166-479f-871b-cfd03c00d9f6@github.com>

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
     separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 275:

> 273:         final X509Certificate[] trustedChain = v.validate(chain, null,
> 274:                 responseList, constraints, authType);
> 275:         if (sslParameters != null && handshakeSession != null) {

Looks like this `if` block is not needed: `sslParameters != null` condition is always `true`, and we should throw an exception in the beginning of the method if session is null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2060782742

From abarashev at openjdk.org  Fri Apr 25 19:45:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 25 Apr 2025 19:45:00 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: 

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
     separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 532:

> 530:     }
> 531: 
> 532:     public boolean isQuic() {

This method never called.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2060797765

From mpowers at openjdk.org  Fri Apr 25 20:05:07 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 25 Apr 2025 20:05:07 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v2]
In-Reply-To: 
References: 
Message-ID: 

> [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113)

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  need test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24854/files
  - new: https://git.openjdk.org/jdk/pull/24854/files/8b111728..064c847f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24854&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24854&range=00-01

  Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24854.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24854/head:pull/24854

PR: https://git.openjdk.org/jdk/pull/24854

From valeriep at openjdk.org  Fri Apr 25 20:45:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 25 Apr 2025 20:45:05 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
> 
> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
> 
> Thanks in advance for the review~

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments from Weijun.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24393/files
  - new: https://git.openjdk.org/jdk/pull/24393/files/38b2da73..ebc635ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=03-04

  Stats: 16 lines in 2 files changed: 4 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24393/head:pull/24393

PR: https://git.openjdk.org/jdk/pull/24393

From djelinski at openjdk.org  Fri Apr 25 20:54:53 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 25 Apr 2025 20:54:53 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v4]
In-Reply-To: <3wJzRt1gIuHQVATNvjiiGQdEJyS7pqVrQPDQW_yzTE4=.ac3baed9-5659-4c85-ac6c-94240e8d5ee6@github.com>
References: 
 
 
 <3wJzRt1gIuHQVATNvjiiGQdEJyS7pqVrQPDQW_yzTE4=.ac3baed9-5659-4c85-ac6c-94240e8d5ee6@github.com>
Message-ID: 

On Fri, 25 Apr 2025 18:40:17 GMT, Valerie Peng  wrote:

>> src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 131:
>> 
>>> 129: 
>>> 130:             // derive handshake secret
>>> 131:             return hkdf.deriveKey(type, HKDFParameterSpec.ofExtract()
>> 
>> The line above may fail because the `hkdf` object has been used once on line 121 with zero-valued salt and IKM, which selected the software-based HKDF from SunJCE. At this point, however, `sharedSecret` is the result of ECDH and may be non-extractable if produced by an HSM, making it incompatible with the SunJCE implementation. To avoid this issue, get a new `hkdf` by calling `hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm)` before this line.
>
> Hmm, ok, interesting scenario. I add another `KDF.getInstance()` call as you suggested just to be safe.

I think that deserves a code comment; it's far from obvious why we do that. Also, we will make P11 work with zero-valued salt soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2060870152

From wetmore at openjdk.org  Sat Apr 26 04:59:26 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 26 Apr 2025 04:59:26 GMT
Subject: RFR: 8355637: SSLSessionImpl's "serialization" list documentation is
 incorrectly ordered
Message-ID: 

Minor error in the `SSLSessionImpl` comments as to how the class is "serialized. Fix the ordering.

Do a little cleaning on the class on some obvious errors.

No testing needed.

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

Commit messages:
 - 8355637: SSLSessionImpl's "serialization" list documentation is incorrectly ordered

Changes: https://git.openjdk.org/jdk/pull/24894/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355637
  Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24894/head:pull/24894

PR: https://git.openjdk.org/jdk/pull/24894

From ascarpino at openjdk.org  Sat Apr 26 05:04:45 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 26 Apr 2025 05:04:45 GMT
Subject: RFR: 8355637: SSLSessionImpl's "serialization" list documentation
 is incorrectly ordered
In-Reply-To: 
References: 
Message-ID: 

On Sat, 26 Apr 2025 04:54:10 GMT, Bradford Wetmore  wrote:

> Minor error in the `SSLSessionImpl` comments as to how the class is "serialized. Fix the ordering.
> 
> Do a little cleaning on the class on some obvious errors.
> 
> No testing needed.

Looks good

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

PR Review: https://git.openjdk.org/jdk/pull/24894#pullrequestreview-2795753574

From ascarpino at openjdk.org  Sat Apr 26 05:37:44 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 26 Apr 2025 05:37:44 GMT
Subject: RFR: 8355637: SSLSessionImpl's "serialization" list documentation
 is incorrectly ordered
In-Reply-To: 
References: 
Message-ID: 

On Sat, 26 Apr 2025 04:54:10 GMT, Bradford Wetmore  wrote:

> Minor error in the `SSLSessionImpl` comments as to how the class is "serialized. Fix the ordering.
> 
> Do a little cleaning on the class on some obvious errors.
> 
> No testing needed.

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24894#pullrequestreview-2795767599

From wetmore at openjdk.org  Sat Apr 26 05:48:48 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 26 Apr 2025 05:48:48 GMT
Subject: Integrated: 8355637: SSLSessionImpl's "serialization" list
 documentation is incorrectly ordered
In-Reply-To: 
References: 
Message-ID: 

On Sat, 26 Apr 2025 04:54:10 GMT, Bradford Wetmore  wrote:

> Minor error in the `SSLSessionImpl` comments as to how the class is "serialized. Fix the ordering.
> 
> Do a little cleaning on the class on some obvious errors.
> 
> No testing needed.

This pull request has now been integrated.

Changeset: 21b0f5ea
Author:    Bradford Wetmore 
URL:       https://git.openjdk.org/jdk/commit/21b0f5ea153c633de7f09bdb0399308c890f7e43
Stats:     8 lines in 1 file changed: 2 ins; 3 del; 3 mod

8355637: SSLSessionImpl's "serialization" list documentation is incorrectly ordered

Reviewed-by: ascarpino

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

PR: https://git.openjdk.org/jdk/pull/24894

From ascarpino at openjdk.org  Sat Apr 26 07:26:07 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 26 Apr 2025 07:26:07 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v13]
In-Reply-To: <30X9q11p_-KYUQCqCNYz7l6QXbJFhBEKN-T6Ci66c5E=.085c50cf-dc22-44a2-b491-76c7ff22dd4d@github.com>
References: 
 <08wmiSxvUmzEN6Xl0DRsYkf-AvWnCHjzcMuLaDL54ZY=.e33d468b-56a2-463f-b466-0aac792b4e92@github.com>
 <30X9q11p_-KYUQCqCNYz7l6QXbJFhBEKN-T6Ci66c5E=.085c50cf-dc22-44a2-b491-76c7ff22dd4d@github.com>
Message-ID: 

On Thu, 17 Apr 2025 15:14:33 GMT, Sean Mullan  wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - merge with master
>>  - better comment and remove commented out code
>>  - Merge branch 'master' into pem
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - Merge in PEMRecord as part of the API.
>>  - Merge branch 'pem-record' into pem-merge
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/security/PEMDecoder.java
>>    #	src/java.base/share/classes/java/security/PEMRecord.java
>>    #	src/java.base/share/classes/sun/security/util/Pem.java
>>    #	test/jdk/java/security/PEM/PEMData.java
>>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>>  - Merge branch 'master' into pem-record
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>>  - test fixes & cleanup
>>  - Implement stream decoding
>>    fix StringBuffer/Builder
>>    X509C* changes
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/a347ecde...106788ef
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 43:
> 
>> 41: 
>> 42: /**
>> 43:  * {@code PEMDecoder} is an immutable class for Privacy-Enhanced Mail (PEM)
> 
> s/for/for decoding/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 46:
> 
>> 44:  * data.  PEM is a textual encoding used to store and transfer security
>> 45:  * objects, such as asymmetric keys, certificates, and certificate revocation
>> 46:  * lists (CRL).  It is defined in RFC 1421 and RFC 7468.  PEM consists of a
> 
> s/CRL/CRLs/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 51:
> 
>> 49:  *
>> 50:  * 
     Decoding methods return an instance of a class that matches the data
>> 51:  * type and implements {@link DEREncodable} unless specified. The following
> 
> "unless otherwise specified"?

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 64:
> 
>> 62:  * 
     If the PEM does not have a corresponding JCE object, it returns a
>> 63:  * {@link PEMRecord}. Any PEM can be decoded into a {@code PEMRecord} if the
>> 64:  * class is specified. Decoding a {@code PEMRecord} returns corresponding
> 
> What do you mean by "Decoding a PEMRecord"? 
> s/returns/returns a/

I was mistakenly documenting an internal method

> src/java.base/share/classes/java/security/PEMDecoder.java line 65:
> 
>> 63:  * {@link PEMRecord}. Any PEM can be decoded into a {@code PEMRecord} if the
>> 64:  * class is specified. Decoding a {@code PEMRecord} returns corresponding
>> 65:  * JCE object or throws a {@link IllegalArgumentException} if no object is
> 
> s/a/an/

removed

> src/java.base/share/classes/java/security/PEMDecoder.java line 68:
> 
>> 66:  * available.
>> 67:  *
>> 68:  * 
     A new immutable {@code PEMDecoder} instance is created by using
> 
> Suggest rewording as ... "A `PEMDecoder` can be configured with additional options by calling ..."

I changed "calling" to "configured".  Using your full text means the "new instance" part needs to be said elsewhere.

> src/java.base/share/classes/java/security/PEMDecoder.java line 71:
> 
>> 69:  * {@linkplain #withFactory} and/or {@linkplain #withDecryption}.  Configuring
>> 70:  * an instance for decryption does not prevent decoding with unencrypted PEM.
>> 71:  * Any encrypted PEM that does not use the configured password will throw an
> 
> s/an/a/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 74:
> 
>> 72:  * {@link SecurityException}. A decoder instance not configured with decryption
>> 73:  * returns an {@link EncryptedPrivateKeyInfo} with encrypted PEM.
>> 74:  * EncryptedPrivateKeyInfo methods must be used to retrieve the
> 
> Put code around EncryptedPrivateKeyInfo.

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 197:
> 
>> 195:             };
>> 196:         } catch (GeneralSecurityException | IOException e) {
>> 197:             throw new IllegalArgumentException(e);
> 
> Should all of these decoding issues really be treated as `IllegalArgumentException`s? I would think that general decoding issues should be thrown as checked exceptions. Runtime exceptions are typically used for serious issues, like programming errors.

It has been the intent to avoid checked exceptions with these methods and these methods follow the same behavior and exception as `Base64.Decoder.decode()`

> src/java.base/share/classes/java/security/PEMDecoder.java line 202:
> 
>> 200: 
>> 201:     /**
>> 202:      * Decodes and returns {@link DEREncodable} from the given string.
> 
> s/returns/returns a/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 210:
> 
>> 208:      */
>> 209:     public DEREncodable decode(String str) {
>> 210:         Objects.requireNonNull(str);
> 
> Missing an `@throws NullPointerException` in the spec.

Added in an intermediate changeset

> src/java.base/share/classes/java/security/PEMDecoder.java line 236:
> 
>> 234:      */
>> 235:     public DEREncodable decode(InputStream is) throws IOException {
>> 236:         Objects.requireNonNull(is);
> 
> Missing an `@throws NullPointerException` in the spec.

Added in an intermediate changeset

> src/java.base/share/classes/java/security/PEMDecoder.java line 259:
> 
>> 257:      * @param  Class type parameter that extends {@code DEREncodable}
>> 258:      * @param string the String containing PEM data.
>> 259:      * @param tClass the returned object class that implementing
> 
> s/implementing/implements/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 261:
> 
>> 259:      * @param tClass the returned object class that implementing
>> 260:      * {@code DEREncodable}.
>> 261:      * @return A {@code DEREncodable} typecast to {@code tClass}.
> 
> s/A/a/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 266:
> 
>> 264:      */
>> 265:     public  S decode(String string, Class tClass) {
>> 266:         Objects.requireNonNull(string);
> 
> Missing an `@throws NullPointerException` in the spec.

Added in an intermediate changeset

> src/java.base/share/classes/java/security/PEMDecoder.java line 282:
> 
>> 280:      * @param  Class type parameter that extends {@code DEREncodable}
>> 281:      * @param is an InputStream containing PEM data.
>> 282:      * @param tClass the returned object class that implementing
> 
> s/implementing/implements/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 284:
> 
>> 282:      * @param tClass the returned object class that implementing
>> 283:      *   {@code DEREncodable}.
>> 284:      * @return A {@code DEREncodable} typecast to {@code tClass}
> 
> s/A/a/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 294:
> 
>> 292:     public  S decode(InputStream is, Class tClass)
>> 293:         throws IOException {
>> 294:         Objects.requireNonNull(is);
> 
> Missing an `@throws NullPointerException` in the spec.

Added in the recent update

> src/java.base/share/classes/java/security/PEMDecoder.java line 359:
> 
>> 357:             }
>> 358:             return KeyFactory.getInstance(algorithm, factory);
>> 359:         } catch(GeneralSecurityException e){
> 
> Nit, add space after `catch` and before `{`.

yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052758001
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052758108
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052758230
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052679240
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052679623
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052691444
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052692601
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052692794
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049729802
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052698263
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052699015
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052699478
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052700392
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052700498
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052700709
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052700833
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052700940
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049721541
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052756431

From ascarpino at openjdk.org  Sat Apr 26 07:26:10 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 26 Apr 2025 07:26:10 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v12]
In-Reply-To: 
References: 
 
 
Message-ID: <_1S31GZs4ShW0QTVMadton7NC0v6FW4X60bfv3770EM=.9f73f136-f955-4028-8c9c-70d2071a7852@github.com>

On Tue, 11 Feb 2025 16:35:35 GMT, Sean Mullan  wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits:
>> 
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - Merge in PEMRecord as part of the API.
>>  - Merge branch 'pem-record' into pem-merge
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/security/PEMDecoder.java
>>    #	src/java.base/share/classes/java/security/PEMRecord.java
>>    #	src/java.base/share/classes/sun/security/util/Pem.java
>>    #	test/jdk/java/security/PEM/PEMData.java
>>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>>  - Merge branch 'master' into pem-record
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>>  - test fixes & cleanup
>>  - Implement stream decoding
>>    fix StringBuffer/Builder
>>    X509C* changes
>>  - Reorg tests data
>>    minor fixes
>>  - merge from pem branch
>>  - Merge branch 'pem' into pem-record
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/security/PEMEncoder.java
>>    #	src/java.base/share/classes/sun/security/provider/X509Factory.java
>>    #	src/java.base/share/classes/sun/security/util/Pem.java
>>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>>  - ... and 48 more: https://git.openjdk.org/jdk/compare/22845a77...cc952c0b
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 58:
> 
>> 56:  *
    >> 57: * >> 58: * A specified return class must extend {@link DEREncodable} and be an > > Suggest rewording as "Objects that are decoded and returned must extend ..." I think the suggestion changes the meaning a bit. The original text is about the specified return class `decode(String, **Class**)`, while the proposed text to me reads about the return value itself. > src/java.base/share/classes/java/security/PEMDecoder.java line 68: > >> 66: * available. >> 67: * >> 68: *

    A new immutable {@code PEMDecoder} instance is created by using > > s/using/calling/ ok > src/java.base/share/classes/java/security/PEMDecoder.java line 78: > >> 76: * >> 77: *

    {@code String} values returned by this class use character set >> 78: * {@link java.nio.charset.StandardCharsets#ISO_8859_1 ISO-8859-1} > > Missing period at end of sentence. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 199: > >> 197: * Decodes and returns {@link DEREncodable} from the given string. >> 198: * >> 199: * @param str PEM data in a String. > > Remove the period at end. Same comment applies to other @param, @return and @throws descriptions. See https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#@param for more details where it says "End the phrase with a period only if another phrase or sentence follows it." I'll look through them. > src/java.base/share/classes/java/security/PEMDecoder.java line 199: > >> 197: * Decodes and returns {@link DEREncodable} from the given string. >> 198: * >> 199: * @param str PEM data in a String. > > Suggest rewording as "a String containing PEM data". ok > src/java.base/share/classes/java/security/PEMDecoder.java line 200: > >> 198: * >> 199: * @param str PEM data in a String. >> 200: * @return an {@code DEREncodable} generated from the PEM data. > > s/an/a/ ok > src/java.base/share/classes/java/security/PEMDecoder.java line 218: > >> 216: * {@code InputStream}. >> 217: * >> 218: *

    The method will read the {@code InputStream} until PEM data is > > s/The/This/ ok > src/java.base/share/classes/java/security/PEMDecoder.java line 374: > >> 372: * Configures and returns a new {@code PEMDecoder} instance from the >> 373: * current instance that will use KeyFactory and CertificateFactory classes >> 374: * from the specified {@link Provider}. Any errors using the > > What if `KeyFactory` and `CertificateFactory` are in different providers? Do we want to have a method that also takes two provider parameters? I think multiple provider parameters doesn't make usability easier and adds project code complexity. In the case you describe, the user knows their providers factory support and they can just create a new PEMDecoder instance for each. If they do not know, then they don't use this method. > src/java.base/share/classes/java/security/PEMDecoder.java line 377: > >> 375: * {@code provider} will occur during decoding. >> 376: * >> 377: *

    If {@code params} is {@code null}, a new instance is returned with > > There is no variable named `params` - do you mean `provider`? Also, why not throw an NPE and not allow a `null` provider, since it would be the same as calling `of()`? It was meant to be `provider`. I didn't think checking for null and throwing an exception is necessary when it is the default operation. This shows up when coding with a provider variable with unknown value. In this case, the app doesn't have to check if `provider == null` so that it can call `of()`. Unfortunately this situation is common with `getInstance()` which result in a lot of if-else statements. > src/java.base/share/classes/java/security/spec/EncodedKeySpec.java line 52: > >> 50: >> 51: private final byte[] encodedKey; >> 52: private String algorithmName; > > I think this can be marked `final` now. ok > src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 200: > >> 198: DerValue bits = value.withTag(DerValue.tag_BitString); >> 199: //byte[] bytes = bits.getBitString(); >> 200: //BitArray bitArray = new BitArray(bytes[0] * 8 - 2, bytes, 3); > > Commented out code, remove? already removed > src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 207: > >> 205: pubKeyEncoded = new X509Key(algid, >> 206: bits.getUnalignedBitString()).getEncoded(); >> 207: */ > > Commented out code, remove? already removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052669236 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052680351 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052693549 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052698537 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052698603 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052698711 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052699218 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049720785 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2049684721 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052656953 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052649026 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2052649253 From liach at openjdk.org Sat Apr 26 20:10:19 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 26 Apr 2025 20:10:19 GMT Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to class file version [v2] In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> Message-ID: > Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Further furnish docs - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse - Merge branch 'feature/af-location-accessors' into feature/af-cffv-parse - Merge branch 'master' of https://github.com/openjdk/jdk into feature/af-cffv-parse - Redundant method - 8297271: AccessFlag.maskToAccessFlags should be specific to class file version ------------- Changes: https://git.openjdk.org/jdk/pull/24760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=01 Stats: 161 lines in 9 files changed: 94 ins; 33 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/24760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760 PR: https://git.openjdk.org/jdk/pull/24760 From liach at openjdk.org Sun Apr 27 02:10:33 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 27 Apr 2025 02:10:33 GMT Subject: RFR: 8297271: AccessFlag.maskToAccessFlags should be specific to class file version [v3] In-Reply-To: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> References: <6Uh3X1qPa571yjsHYht7Fd4joRu3HMoSzdf_hMhdeTc=.26567c5d-d8da-4df5-b64e-e5a56f9c1d74@github.com> Message-ID: > Take the class file version to reject flags not yet defined, redefined, or obsoleted. The non-cffv version can return the preview flags when the current runtime is in preview. Chen Liang has updated the pull request incrementally with two additional commits since the last revision: - Missing since - Fix javap causing strictfp tests to fail ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24760/files - new: https://git.openjdk.org/jdk/pull/24760/files/e1530d7d..3db05342 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24760&range=01-02 Stats: 72 lines in 7 files changed: 17 ins; 19 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/24760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24760/head:pull/24760 PR: https://git.openjdk.org/jdk/pull/24760 From duke at openjdk.org Sun Apr 27 07:00:48 2025 From: duke at openjdk.org (Nibedita Jena) Date: Sun, 27 Apr 2025 07:00:48 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v3] In-Reply-To: References: Message-ID: On Wed, 23 Apr 2025 20:16:17 GMT, Anthony Scarpino wrote: >> Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated SSLSessionImpl constructor with Record interface methods > > I will look at this.. At the time I wrote this I avoided using Record for a reason, but I don't remember why right now. @ascarpino @jnimeh since I am waiting for one more review, can you please review it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24535#issuecomment-2833240530 From ascarpino at openjdk.org Mon Apr 28 05:35:02 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 28 Apr 2025 05:35:02 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: On Thu, 24 Apr 2025 18:29:08 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: >> >> - javadoc updates >> - code review comments > > src/java.base/share/classes/java/security/PEMDecoder.java line 60: > >> 58: * A specified return class must implement {@link DEREncodable} and be an >> 59: * appropriate JCE object class for the PEM; otherwise an >> 60: * {@link IllegalArgumentException} is thrown. > > Do we need to document somewhere what "appropriate" JCE classes are for each PEM type? I view this as an advanced feature for experienced users. The list is large and algorithm-dependent. For example an EC private key PEM could be PrivateKey.class, ECPrivateKey.class, PEMRecord.class, PKCS8EncodedKeySpec.class. I don't think it's realistic to list everything. > src/java.base/share/classes/java/security/PEMDecoder.java line 398: > >> 396: * Returns a new {@code PEMDecoder} instance from the current instance >> 397: * configured to decrypt encrypted PEM data with given password. >> 398: * Non-encrypted PEM may still be decoded from this instance. > > I assume that if users want to use a non-default cipher provider they should decode as `EncryptedPrivateKeyInfo` first and it has more sophisticated methods there. Do we need to document about this here? I think that's would be too rare to specify in the javadoc. > src/java.base/share/classes/java/security/PEMEncoder.java line 120: > >> 118: >> 119: /** >> 120: * Returns an instance of PEMEncoder. > > Do we need to say "simple" or "normal" or "raw" `PEMEncoder` here? Just to be clear that it does not do any encryption. I'll just say "new" > src/java.base/share/classes/java/security/PEMEncoder.java line 134: > >> 132: private String pemEncoded(PEMRecord pem) { >> 133: StringBuilder sb = new StringBuilder(1024); >> 134: sb.append("-----BEGIN ").append(pem.type()).append("-----"); > > So you throw away the leading data? Shall we document this somewhere? This is a private method that just converts the `pem` and `type` into a properly formatted PEM. Leading data is not applicable here. > src/java.base/share/classes/java/security/PEMEncoder.java line 175: > >> 173: throw new IllegalArgumentException("KeyPair does not " + >> 174: "contain PrivateKey."); >> 175: } > > Do we really need to care about whether the private part or the public part is null? Previous discussions determined that a null value in a KeyPair was undefined and should not be done. > src/java.base/share/classes/java/security/PEMEncoder.java line 235: > >> 233: */ >> 234: public byte[] encode(DEREncodable de) { >> 235: return encodeToString(de).getBytes(StandardCharsets.ISO_8859_1); > > Which operation is lighter? Have you considered letting `pemEncoded` to return a byte array and converting it into a string in `encodeToString()`? It's easier to construct using StringBuilder. Either direction some data is converting String to bytes or bytes to String. > src/java.base/share/classes/java/security/PEMEncoder.java line 279: > >> 277: if (keySpec != null) { >> 278: // For thread safety >> 279: lock.lock(); > > How much does this lock buy? If someone provides a password, I assume they will use it anyway. key generation was delayed because we don't want `withEncryption()` to throw an exception as it's a config/builder method. The lock was to prevent multiple versions of the same key being generated in a threaded situation. > src/java.base/share/classes/java/security/PEMEncoder.java line 287: > >> 285: keySpec = null; >> 286: } catch (GeneralSecurityException e) { >> 287: throw new SecurityException("Security property " + > > Let's discuss whether to use `SecurityException` here. I would use `ProviderException`. This is catching any errors that may occur that may not a result of the Provider. ProviderException is for errors/problems with the Provider. > src/java.base/share/classes/java/security/PEMEncoder.java line 300: > >> 298: // If `key` is non-null, this is an encoder ready to encrypt. >> 299: if (key != null) { >> 300: if (privateBytes == null || publicBytes != null) { > > `publicBytes` cannot be null here. You rejected both being null at the beginning of this method. The check at the top is AND, while this is OR. > src/java.base/share/classes/java/security/PEMRecord.java line 61: > >> 59: * RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures >> 60: */ >> 61: public record PEMRecord(String type, String pem, byte[] leadingData) > > How about using the raw byte data instead of the `pem` string? This would automatically reject all format problems, like extra newline at the end, too wide string, and invalid Base64 chars. Also, two `PEMRecord` should equal to each other even if they are encoded differently (for example, different width). > > Also, how about forcing all fields to be non null? If there is no leading bytes, use an empty array. I cannot imagine how data could be empty. This record was built for two reasons: 1) For PEM that we do not have a cryptographic representation for (ECPrivateKey, X509Certificate, etc). 2) An early comment about reading a private key in PEM from a file, but not creating a PrivateKey object with it. The classes are only supposeed to include Base64. In fact, I found an inconsistency with `PEMEncoder` using `PEMRecord` with binary data that I've fixed but yet to push. It checking two records are equal, then overriding the `equals()` makes more sense than changing how the data is stored. Also, storing the PEM solves the simplest consistency test where PEM read from a file may be different when Base64 decoded and encoded. Some of the values have to be null because of `leadingData`. You were a proponent of storing the non-PEM data before the PEM data was found when reading from an `InputStream`. The null situation happens if at the end of the stream there is only non-PEM data. Throwing an exception or ignoring the data was inconsistent. So PEMRecord has to allow for `leadingData` with no `type` and `pem`. > src/java.base/share/classes/java/security/PEMRecord.java line 79: > >> 77: * @param pem The data between the PEM header and footer. >> 78: * @param leadingData Any non-PEM data read during the decoding process >> 79: * before the PEM header. This value maybe {@code null}. > > Do we need to say if `leadingData` contains the final newline char? I'm not sure what you mean by "final" as it contains whatever the stream contains before the dashes. The point is not to parse the non-PEM data and store it as is. > src/java.base/share/classes/java/security/PEMRecord.java line 95: > >> 93: // including lowercase. The onus is on the caller. >> 94: if (type != null && type.startsWith("-----")) { >> 95: // Remove PEM headers syntax if present. > > I don't think we need to be so tolerant at the beginning. Just reject it. ok > src/java.base/share/classes/java/security/PEMRecord.java line 135: > >> 133: /** >> 134: * Returns the binary encoding from the Base64 data contained in >> 135: * {@code pem}. > > The name does not sound correct to me. PEM encodes binary data to an ASCII string, so "encoding" is the ASCII string. How about just `getData`? `PEMRecord` implements `DEREncodable` which all the classes return DER through `getEncoded()`. I is consistent with the other implementing classes. > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 81: > >> 79: >> 80: /** >> 81: * Constructs an {@code EncryptedPrivateKeyInfo} from a given Encrypted > > Why is "E" capitalized? Is it a special term? yep > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 83: > >> 81: * Constructs an {@code EncryptedPrivateKeyInfo} from a given Encrypted >> 82: * PKCS#8 ASN.1 encoding. >> 83: * @param encoded the ASN.1 encoding which is cloned and then parsed. > > Somehow I prefer the original "The contents of the array...". We've used this style in a lot of places. I didn't change the rest of them because I didn't want to make too many unnecessary edits. I understand you like it, but it is not a concise description. The one word "cloned" is a lot simpler and means the same as: "The contents of {@code encryptedData} are copied to protect against subsequent modification when constructing this object." > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 324: > >> 322: >> 323: /** >> 324: * Creates and encrypts an {@code EncryptedPrivateKeyInfo} from a given > > Can we say "encrypt" an "EncryptedPrivateKeyInfo"? It sounds like an already encrypted thing. ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 338: > >> 336: * >> 337: * @param key the PrivateKey object to encrypt. >> 338: * @param password the password used for generating the PBE key. > > Do we need to mention the "PBE key"? It's just the password to encrypt the private key. ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 341: > >> 339: * @param algorithm the PBE encryption algorithm. >> 340: * @param params the parameters used with the PBE encryption. >> 341: * @param provider the Provider that will perform the encryption. > > I prefer moving (if not copying) the nullable description of `params` and `provider` here. > > Also, in your implementation, the provider is used to choose both `SecretkeyFactory` and `Cipher`. I hope for each provider there always exists a pair of `SecretkeyFactory` and `Cipher` with a given algorithm name. I'll move the descriptions Yes this method needs both on the same provider. If they are on separate providers, they can use the other method that takes the `Key` instead of a `password`. > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 351: > >> 349: * @implNote The encryption uses the algorithm set by >> 350: * `jdk.epkcs8.defaultAlgorithm` Security Property >> 351: * and default the {@code AlgorithmParameterSpec} of that provider. > > I think this `implNote` is not necessary here. You already required `algorithm` to be non-null. Since I changed to allow null, it's needed now. (see below) > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 416: > >> 414: * {@link PrivateKey} using the {@code encKey} and given parameters. >> 415: * >> 416: * If {@code algorithm} is {@code null} the default algorithm will be used. > > In the other `encryptKey` method using password, `algorithm` must be provided. Why the inconsistency? > > In fact, since you have `encKey`, doesn't it already have an algorithm name? It maybe good for both `encryptKey` methods do not allow null algorithms when APS is non-null. I think `PBEParameterSpec` is currently the only APS used, but if in the future a new APS is used, a default algorithm with a specified APS could lead to applications breaking. There is no guarantee the key's algorithm will be properly formatted to use as an algorithm name. I wouldn't trust it. > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 422: > >> 420: * >> 421: * @param key the {@code PrivateKey} object to encrypt. >> 422: * @param encKey the encryption {@code Key} > > It will be more precise if we say `key` is the key to be encrypted and `encKey` is the key used to encrypt `key`. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062695427 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062723080 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062725966 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062726982 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062727349 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062730381 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062733556 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062734449 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062734838 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2061221714 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2061224179 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062747907 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2061217873 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2061226526 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2061225921 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062750755 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062750997 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062873270 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2061226193 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062846705 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062876630 From ascarpino at openjdk.org Mon Apr 28 05:35:04 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 28 Apr 2025 05:35:04 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: On Thu, 24 Apr 2025 20:04:19 GMT, Mark Reinhold wrote: >> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: >> >> - javadoc updates >> - code review comments > > src/java.base/share/classes/java/security/PEMDecoder.java line 78: > >> 76: * >> 77: *

    {@code String} values returned by this class use character set >> 78: * {@link java.nio.charset.StandardCharsets#ISO_8859_1 ISO-8859-1} > > `String` values in Java are always encoded in UTF-16. Did you mean to write something like, "Byte streams consumed by methods in this class are assumed to represent characters encoded in the ISO-8859-1 charset" ? Actually this comment isn't necessary as this method doesn't return Strings. > src/java.base/share/classes/java/security/PEMDecoder.java line 84: > >> 82: * 

    >> 83:  *     PEMDecoder pd = PEMDecoder.of();
>> 84:  *     PrivateKey priKey = pd.decode(PriKeyPEM);
> 
> s/PriKeyPEM/priKeyPEM/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 213:
> 
>> 211:         Objects.requireNonNull(str);
>> 212:         try {
>> 213:             return decode(new ByteArrayInputStream(str.getBytes()));
> 
> `str.getBytes()` will return a byte array encoded in the default charset, which these days is likely to be UTF-8, but might be something completely bizarre. You probably want `str.getBytes(StandardCharsets.ISO_8859_1)`.
> 
> It could be worth running your unit tests in several different locales in order to catch similar issues.

What about the other decode methods that read from InputStream?  I thought it would be inconsistent to read `decode(String)` as a ISO 8859-1, but `decode(InputStream)` as a different charset.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062695888
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062696020
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2062701688

From michael.osipov at innomotics.com  Mon Apr 28 08:22:50 2025
From: michael.osipov at innomotics.com (Osipov, Michael (IN IT IN))
Date: Mon, 28 Apr 2025 10:22:50 +0200
Subject: [Bug] NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used
 with QOP auth-int against Active Directory
Message-ID: <46878900-7af6-42c7-8b66-f8e0ca4decb3@siemens.com>

Hi folks,
Hi Max,

please assess the following bug I have found in Java 11+, it does not exist
in Java 8. I have tried the following most versions on Azul Zulu/
OpenJDK: 8, 11, 17, 21, 24 on multiple platforms. Searched JBS as well,
nothing found.

Consider the following code:
> public static void main(String[] args) throws NamingException {
> 	DirContextSource dirSource = new DirContextSource.Builder("ldaps://ad001.siemens.net").debug(true).version(3)
> 			.readTimeout(1000).referral("throw").derefAliases("never")
> 			.additionalProperty("net.sf.michaelo.activedirectory.readTimeout", "1000")
> 			.gssApiAuth("com.sun.security.jgss.initiate").qop("auth,auth-int").mutualAuth().connectTimeout(1000).build();
> 
> 	DirContext dirContext = dirSource.getDirContext();
> 	SearchControls ctls = new SearchControls(SearchControls.OBJECT_SCOPE, 0, 0, args, false, false);
> 
> 	try {
> 		NamingEnumeration search = dirContext.search("", "(objectClass=*)", ctls);
> 		while (search.hasMore()) {
> 			SearchResult res = search.next();
> 			Attributes attrs = res.getAttributes();
> 			for (String arg : args) {
> 				Attribute attr = attrs.get(arg);
> 				if (attr != null) {
> 					System.out.println(arg + ":");
> 					NamingEnumeration all = attr.getAll();
> 
> 					while (all.hasMore()) {
> 						System.out.println("    " + all.next());
> 					}
> 				}
> 			}
> 		}
> 	} catch (LdapReferralException e) {
> 		...
> 	}
> 	dirContext.close();
> }
Please disregard DirContextSource, it is my thin OSS fluent wrapper
around InitialDirContext [1].

Create a TLS connection to Active Directory, bind with SASL GSSAPI and
require SASL integrity. Now, this is thrown by Java 8:
> Exception in thread "main" javax.naming.NamingException: LDAP
> connection has been closed; remaining name '' at
> com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133) at
> com.sun.jndi.ldap.Connection.readReply(Connection.java:469) at
> com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:638) at
> com.sun.jndi.ldap.LdapClient.search(LdapClient.java:561) at
> com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2014) at
> com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1873) at
> com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798) at
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
>  at
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
>  at
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341)
>  at
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
>  at DirTest.main(DirTest.java:24)

The reason for the closure I will describe later.

Now with Java 11+ I see:
> Exception in thread "main" java.lang.NullPointerException: Cannot
> invoke "org.ietf.jgss.GSSContext.wrap(byte[], int, int,
> org.ietf.jgss.MessageProp)" because "this.secCtx" is null at
> jdk.security.jgss/
> com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(GssKrb5Base.java:140) 
> at java.naming/
> com.sun.jndi.ldap.sasl.SaslOutputStream.write(SaslOutputStream.java:89)
>  at java.naming/
> com.sun.jndi.ldap.Connection.abandonRequest(Connection.java:582) at
> java.naming/
> com.sun.jndi.ldap.Connection.readReply(Connection.java:472) at
> java.naming/
> com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:664) at
> java.naming/com.sun.jndi.ldap.LdapClient.search(LdapClient.java:587) 
> at java.naming/com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2015) 
> at java.naming/
> com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1874) at
> java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1799) at
> java.naming/
> com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
>  at java.naming/
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
>  at java.naming/
> com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341)
>  at java.naming/
> javax.naming.directory.InitialDirContext.search(InitialDirContext.java:346)
>  at DirTest.main(DirTest.java:24)

So the bug seems to have surfaced somewhere between 8 and 11. Active
Directory does not support any SASL QOP (but auth) over a TLS connection 
[2].
Digging through RFCs [3], [4], [5] it seems to me that Active Directory
clearly violates those. What I see in the decrypted Wireshark traffic is
the following:
* SASL Bind completed
* GSS Wrap happens to negotiate the QOP, server says: 07 A0 00 00
* SASL client matches qop-int and wraps streams into SASL streams
* SearchRequest with SASL integrity is issued
* Server sends ExtendedResponse: 00000057: LdapErr: DSID-0C0C0095,
comment: Error decoding ldap message, data 0, v4563,
1.3.6.1.4.1.1466.20036 which is [6].
* Server completes with TCP RST, ACK. No TLS close_notify or similar

Of course, the client tries to decode the ExtendedResponse as a SASL
buffer and reads the first four bytes 30 84 00 00 as the SASL buffer
length and signals a swallowed exception in SaslInputStream.fill():
"java.io.IOException: 813957120exceeds the negotiated receive buffer
size limit:65536" (note the missing space) instead of the start of a
SEQUENCE caught by Connection. The forthcoming Unbind goes into oblivion.

This is how ldapsearch(1) handles it:
> $ ldapsearch -O minssf=1 -d 10 -H ldaps://ad001.siemens.net -s base -Y GSSAPI namingContexts 
> ...
> sb_sasl_generic_pkt_length: received illegal packet length of 813957120 bytes
> sasl_generic_read: want=16, got=16
>   0000:  00 7e 02 01 00 78 84 00  00 00 5d 0a 01 02 04 00   .~...x....].....
> sb_sasl_cyrus_decode: failed to decode packet: generic failure
> sb_sasl_generic_read: failed to decode packet
> ldap_read: want=8 error=Input/output error
> ber_get_next failed, errno=5.
> 
> # numResponses: 0
> ldap_result: Can't contact LDAP server (-1)
> tls_write: want=31, written=31
>   0000:  15 03 03 00 1a df 9c b5  96 48 55 9d 1e 65 dc eb   .........HU..e..
>   0010:  a1 ca 00 a5 96 10 be 5c  23 32 b9 90 68 c4 04      .......\#2..h..

libldap does properly signal in the invalid buffer size and shows the 
connection closure.

I do understand that there are several issues here and AD is clearly 
misbehaving (it should be 01 A0 00 00) and Cyrus SASL does have code to 
drop internal security if outer security is good enough [7], but least 
Java SASL GSSAPI should properly dispose the GSS security context and 
release the SASL client before it says that the connection has been closed.

All trace output, decrypted PCAPs are available privately through email. 
If you need anything else, let me know.

Note: Just using "auth" does work, of course.

Best regards,

Michael

[1] https://github.com/michael-o/dirctxsrc
[2] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-
adts/284923c1-6a5b-4510-b97a-631963c0c3bd.
[3] https://datatracker.ietf.org/doc/html/rfc4513#section-5.2.1.6
[4] https://datatracker.ietf.org/doc/html/rfc4752#section-3.3
[5] https://datatracker.ietf.org/doc/html/rfc4422#section-4 point b)
[6] https://datatracker.ietf.org/doc/html/rfc4511#section-4.4.1
[7] 
https://github.com/cyrusimap/cyrus-sasl/blob/e256dd0cc61d60cbb905b601241077f0a2ba0907/plugins/gssapi.c#L1545-L1556

From duke at openjdk.org  Mon Apr 28 10:39:52 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 28 Apr 2025 10:39:52 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 15:30:28 GMT, Weijun Wang  wrote:

> Add 2 `MessageDigest` algorithms.

I strongly support the names "SHAKE128-256" and "SHAKE256-512".

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

PR Comment: https://git.openjdk.org/jdk/pull/24576#issuecomment-2834807368

From weijun at openjdk.org  Mon Apr 28 14:45:31 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 14:45:31 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms [v2]
In-Reply-To: 
References: 
Message-ID: <1TJ5IyabNADOmoS1U9M4Sg04wuHwWmm72C4GIwGAasE=.c6e2c41b-b1b6-465f-813b-d737c7d64848@github.com>

> Add 2 `MessageDigest` algorithms.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  new algorithm names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24576/files
  - new: https://git.openjdk.org/jdk/pull/24576/files/87a6fdae..46e7ddf3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24576&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24576&range=00-01

  Stats: 14 lines in 4 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24576.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24576/head:pull/24576

PR: https://git.openjdk.org/jdk/pull/24576

From weijun at openjdk.org  Mon Apr 28 14:45:31 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 14:45:31 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Apr 2025 15:30:28 GMT, Weijun Wang  wrote:

> Add 2 `MessageDigest` algorithms.

I updated the names. I also changed the names in `KnownOID`. According to https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration#Hash, these OIDs are assigned to "Secure Hash Algorithms". I kept the old names as aliases.

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

PR Comment: https://git.openjdk.org/jdk/pull/24576#issuecomment-2835485130

From weijun at openjdk.org  Mon Apr 28 14:48:34 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 14:48:34 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms [v3]
In-Reply-To: 
References: 
Message-ID: 

> Add 2 `MessageDigest` algorithms.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  test alias usage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24576/files
  - new: https://git.openjdk.org/jdk/pull/24576/files/46e7ddf3..f5ad8a29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24576&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24576&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24576.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24576/head:pull/24576

PR: https://git.openjdk.org/jdk/pull/24576

From alanb at openjdk.org  Mon Apr 28 14:57:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Apr 2025 14:57:49 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 14:26:43 GMT, Michael McMahon  wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - Review update
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - update to minimise code changes
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    from turbanoff review
>    
>    Co-authored-by: Andrey Turbanov 
>  - doc + copyright update
>  - remove file added by mistake
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/5c067232...9401d4c8

src/java.base/share/conf/security/java.security line 1311:

> 1309: #  hostInfo - Special value which signifies the three categories above combined
> 1310: #             (socket, addressLookup, net). This is provided for compatibility
> 1311: #             with previous releases.

Are you sure "socket", "addressLookup", and "net" categories are useful and needed? I would think someone configuring this is looking to keeping sensitive fields out of the exception messages without knowing exactly which APIs are used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2063849188

From weijun at openjdk.org  Mon Apr 28 16:26:56 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 16:26:56 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
Message-ID: 

On Sun, 27 Apr 2025 22:18:13 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 287:
>> 
>>> 285:                     keySpec = null;
>>> 286:                 } catch (GeneralSecurityException e) {
>>> 287:                     throw new SecurityException("Security property " +
>> 
>> Let's discuss whether to use `SecurityException` here. I would use `ProviderException`.
>
> This is catching any errors that may occur that may not a result of the Provider.  ProviderException is for errors/problems with the Provider.

The `SecurityException` class currently says:

 * 
     This exception was originally specified for use with a SecurityManager when
 * an operation was denied. This feature no longer exists. This exception may be
 * deprecated in a future release.
 * 
 ```
I do think `ProviderException` is adequate here. This is not the user's problem. It's something that the provider assumed should not happen but unfortunately happened ("misconfiguration errors or unrecoverable internal errors" as described in javadoc of `ProviderException`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2064043746

From weijun at openjdk.org  Mon Apr 28 16:30:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 16:30:54 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
Message-ID: 

On Sun, 27 Apr 2025 22:20:32 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 300:
>> 
>>> 298:         // If `key` is non-null, this is an encoder ready to encrypt.
>>> 299:         if (key != null) {
>>> 300:             if (privateBytes == null || publicBytes != null) {
>> 
>> `publicBytes` cannot be null here. You rejected both being null at the beginning of this method.
>
> The check at the top is AND, while this is OR.

You're right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2064051233

From weijun at openjdk.org  Mon Apr 28 16:50:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 16:50:59 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
Message-ID: <0r_MsXGjNUo4t4bb5Ao-KCGfJYIDTKVlwQOo5exburc=.f1c2f835-fc8d-42d1-adf1-e0eb5866318e@github.com>

On Mon, 28 Apr 2025 03:44:43 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 416:
>> 
>>> 414:      * {@link PrivateKey} using the {@code encKey} and given parameters.
>>> 415:      *
>>> 416:      * If {@code algorithm} is {@code null} the default algorithm will be used.
>> 
>> In the other `encryptKey` method using password, `algorithm` must be provided. Why the inconsistency?
>> 
>> In fact, since you have `encKey`, doesn't it already have an algorithm name?
>
> It maybe good for both `encryptKey` methods do not allow null algorithms when APS is non-null.  I think `PBEParameterSpec` is currently the only APS used, but if in the future a new APS is used, a default algorithm with a specified APS could lead to applications breaking.
> 
> There is no guarantee the key's algorithm will be properly formatted to use as an algorithm name.  I wouldn't trust it.

I see. I noticed in your `EncryptKey` test that the algorithm can be simply "PBE".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2064083969

From weijun at openjdk.org  Mon Apr 28 16:58:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 16:58:57 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
Message-ID: 

On Sat, 26 Apr 2025 07:57:42 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMRecord.java line 135:
>> 
>>> 133:     /**
>>> 134:      * Returns the binary encoding from the Base64 data contained in
>>> 135:      * {@code pem}.
>> 
>> The name does not sound correct to me. PEM encodes binary data to an ASCII string, so "encoding" is the ASCII string. How about just `getData`?
>
> `PEMRecord` implements `DEREncodable` which all the classes return DER through `getEncoded()`.  I is consistent with the other implementing classes.

I understand the intent, though `PEMRecord` is a very special `DEREncodable`. In other cases, `DEREncodable` objects contain information to be encoded into DER, while here the content is already DER and then encoded to Base64. In that sense, I almost want to call it a `DERDecodable`. :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2064097399

From weijun at openjdk.org  Mon Apr 28 17:11:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 17:11:57 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
Message-ID: 

On Sun, 27 Apr 2025 21:33:06 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 134:
>> 
>>> 132:     private String pemEncoded(PEMRecord pem) {
>>> 133:         StringBuilder sb = new StringBuilder(1024);
>>> 134:         sb.append("-----BEGIN ").append(pem.type()).append("-----");
>> 
>> So you throw away the leading data? Shall we document this somewhere?
>
> This is a private method that just converts the `pem` and `type` into a properly formatted PEM.  Leading data is not applicable here.

Yes, this method is private. But you allow `PEMEncoder().of().encode(PEMRecord)`. People might wonder why their leading data is lost.

>> src/java.base/share/classes/java/security/PEMRecord.java line 79:
>> 
>>> 77:      * @param pem The data between the PEM header and footer.
>>> 78:      * @param leadingData Any non-PEM data read during the decoding process
>>> 79:      *                    before the PEM header.  This value maybe {@code null}.
>> 
>> Do we need to say if `leadingData` contains the final newline char?
>
> I'm not sure what you mean by "final" as it contains whatever the stream contains before the dashes.  The point is not to parse the non-PEM data and store it as is.

I meant the newline char at the end (before the "------BEGIN" chars). I just tried out your implementation, and noticed if there is nothing there, then `leadingData` is null; and if there is a line of text, `leadingData` contains the newline char at the end.

I still think this is worth mentioning. Suppose someone wants to rewrite the PEM file with the leading data, they need to know they should not use `println`.

BTW, I prefer trimming that newline char. Just my opinion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2064118829
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2064116516

From weijun at openjdk.org  Mon Apr 28 17:17:55 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 17:17:55 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
Message-ID: 

On Sun, 27 Apr 2025 22:11:57 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 279:
>> 
>>> 277:         if (keySpec != null) {
>>> 278:             // For thread safety
>>> 279:             lock.lock();
>> 
>> How much does this lock buy? If someone provides a password, I assume they will use it anyway.
>
> key generation was delayed because we don't want `withEncryption()` to throw an exception as it's a config/builder method.  The lock was to prevent multiple versions of the same key being generated in a threaded situation.

OK, throwing an exception in the builder sounds a bad idea.

>> src/java.base/share/classes/java/security/PEMRecord.java line 61:
>> 
>>> 59:  *       RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures
>>> 60:  */
>>> 61: public record PEMRecord(String type, String pem, byte[] leadingData)
>> 
>> How about using the raw byte data instead of the `pem` string? This would automatically reject all format problems, like extra newline at the end, too wide string, and invalid Base64 chars. Also, two `PEMRecord` should equal to each other even if they are encoded differently (for example, different width).
>> 
>> Also, how about forcing all fields to be non null? If there is no leading bytes, use an empty array. I cannot imagine how data could be empty.
>
> This record was built for two reasons:
> 1) For PEM that we do not have a cryptographic representation for (ECPrivateKey, X509Certificate, etc).
> 2) An early comment about reading a private key in PEM from a file, but not creating a PrivateKey object with it.
> 
>  The classes are only supposeed to include Base64.  In fact, I found an inconsistency with `PEMEncoder` using `PEMRecord` with binary data that I've fixed but yet to push. 
> 
> It checking two records are equal, then overriding the `equals()` makes more sense than changing how the data is stored.  Also, storing the PEM solves the simplest consistency test where  PEM read from a file may be different when Base64 decoded and encoded. 
> 
> Some of the values have to be null because of `leadingData`.  You were a proponent of storing the non-PEM data before the PEM data was found when reading from an `InputStream`.  The null situation happens if at the end of the stream there is only non-PEM data.  Throwing an exception or ignoring the data was inconsistent.  So PEMRecord has to allow for `leadingData` with no `type` and `pem`.

Ah, I see. I didn't realize there can be a `PEMRecord` after all PEM records. I should have read the spec carefully.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2064125957
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2064126319

From weijun at openjdk.org  Mon Apr 28 17:21:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 17:21:04 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
Message-ID: 

On Sun, 27 Apr 2025 18:36:28 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMDecoder.java line 60:
>> 
>>> 58:  * A specified return class must implement {@link DEREncodable} and be an
>>> 59:  * appropriate JCE object class for the PEM; otherwise an
>>> 60:  * {@link IllegalArgumentException} is thrown.
>> 
>> Do we need to document somewhere what "appropriate" JCE classes are for each PEM type?
>
> I view this as an advanced feature for experienced users.  The list is large and algorithm-dependent.  For example an EC private key PEM could be PrivateKey.class, ECPrivateKey.class, PEMRecord.class, PKCS8EncodedKeySpec.class.  I don't think it's realistic to list everything.

I see. Maybe at least point out `PEMRecord` is always a valid option? This gives people a chance to read arbitrary (even invalid) PEMs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2064134853

From valeriep at openjdk.org  Mon Apr 28 17:35:50 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 28 Apr 2025 17:35:50 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 14:48:34 GMT, Weijun Wang  wrote:

>> Add 2 `MessageDigest` algorithms.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test alias usage

(I thought I clicked the "comment" botton last Friday, not sure what happened. Anyhow, here it is)

> > I will take a look~
> 
> Thanks.
> 
> I have 2 concerns on this feature:
> 
>     1. These algorithms are mainly used in higher-level algorithms, mainly signature algorithms. It seems seldom used on their owns. But again, even other SHA-3 algorithms are not used a lot.
> 
>     2. SHAKE128 is both an XOF and a `MessageDigest` algorithm. Although it's well-known that when it is used as a `MessageDigest` algorithm the output size is 256 bits, people might still be confused or simply not aware of it. In this sense, the name might be better SHAKE128-256. Same for SHAKE256, which could be SHAKE256-512.

Are you referring to RFC 8702? What is the main motivation for adding these two as MessageDigest impls? Is there internal JDK usage for them already? These SHAKExxx are not included in the initial SHA-3 support because they aren't approved as hash functions due to the possible generation of related outputs. Personally, I'd strongly prefer indicating the output length when using them as fixed-length message digest algorithms, e.g. SHAKE128-256.

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

PR Comment: https://git.openjdk.org/jdk/pull/24576#issuecomment-2835984390

From fferrari at openjdk.org  Mon Apr 28 17:37:52 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 28 Apr 2025 17:37:52 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v2]
In-Reply-To: 
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <4Wwny0n2QnVHXCN_eK35cxWvcoD1NgaIw64U_GPtO_E=.c67c1cc9-5617-4b02-93ea-075c29914317@github.com>
 
Message-ID: 

On Thu, 17 Apr 2025 04:26:38 GMT, Martin Balao  wrote:

>> Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Do minor adjustments
>>    
>>    Update copyright year, improve comments and use File::toPath to convert
>>    back to Path.
>>  - Merge openjdk/master into JDK-8352728
>>  - 8352728: InternalError loading java.security due to Windows parent folder permissions
>
> Looks like `File::getCanonicalPath` is more resilient to canonicalization and resolution failures. This observation makes me wonder the following:
> 
> 1) Can a normalization failure (e.g. return of a partially normalized path) affect relative includes?
> 
> 2) Can a failure in symlinks resolution (which seems to be ignored) affect relative includes?
> 
> Startup will fail if the included file is not found, which is a safe behavior. The problematic scenario would be one in which a different file exists in a location that uses the partially normalized or resolved path as a base, and is not what the "include" properties writer intended. While unlikely, I want to understand if this is possible and a downside of using `File::getCanonicalPath`.

Hi @martinuy,

> Looks like `File::getCanonicalPath` is more resilient to canonicalization and resolution failures. This observation makes me wonder the following:
>
> 1. Can a normalization failure (e.g. return of a partially normalized path) affect relative includes?
> 2. Can a failure in symlinks resolution (which seems to be ignored) affect relative includes?
>
> Startup will fail if the included file is not found, which is a safe behavior. The problematic scenario would be one in which a different file exists in a location that uses the partially normalized or resolved path as a base, and is not what the "include" properties writer intended. While unlikely, I want to understand if this is possible and a downside of using `File::getCanonicalPath`.

By the time we are resolving a _relative include_, we already performed the following two operations on the file issuing the `include` statement, in this order:

* The path has been normalized, or partially normalized by `File::getCanonicalFile`
* The file has been opened, and we are parsing it (so it's known to be readable and exist)

I would like to put aside filesystem items creation/deletion race conditions, which of course can occur, but would always be problematic, regardless of the path canonicalization mechanism. Excluding such scenarios, we need to think of edge cases where there is a partial normalization or a symlinks resolution failure, **while at the same time, the file exists and is readable**.

### #1. Partial normalization, without symlinks resolution failure

As I understand it, in _Linux_, normalization involves resolving relative paths against the current working directory, substituting `.` or `..` path items, and resolving symlinks. In _Windows_, in addition to the _Linux_ normalization, there is the resolution of absolute paths without drive/unit against the current unit, and the case normalization for case-insensitive filesystems (including the unit letter).

The only _Linux_ partial normalization case I'm aware of, includes symlinks failures (`File::getCanonicalFile` performs `.` and `..` substitutions for inaccessible and nonexistent paths, see examples of this below).

There could be partial normalization cases in _Windows_, when `FindFirstFileW` fails due to parent directories permissions, and the actual filesystem items case is normalized up to a certain point. However, in such cases the resulting path is equivalent, and should work as expected for relative includes resolution.

### #2. Partial normalization, with symlinks resolution failure

I can't think of a _Linux_ scenario where a link is readable but not resolvable. I've tried the following.


mkdir /tmp/scratch
sudo mkdir /tmp/scratch/protected
sudo mkdir /tmp/scratch/protected/inner
sudo tee /tmp/scratch/protected/inner/regular.properties <<<'name=value' >/dev/null
tee /tmp/scratch/target.properties <<<'name=value' >/dev/null
sudo ln -s /tmp/scratch/target.properties /tmp/scratch/protected/link.properties
sudo ln -s /tmp/scratch/target.properties /tmp/scratch/protected/inner/link.properties
sudo chown -R $(whoami):$(whoami) /tmp/scratch/protected/inner
sudo chmod 766 /tmp/scratch/protected


This is the created directories structure:


fferrari at vmhost:~$ sudo tree -up /tmp/scratch
[drwxr-xr-x fferrari]  /tmp/scratch
??? [drwxrw-rw- root    ]  protected
??? ??? [drwxr-xr-x fferrari]  inner
??? ??? ??? [lrwxrwxrwx fferrari]  link.properties -> /tmp/scratch/target.properties
??? ??? ??? [-rw-r--r-- fferrari]  regular.properties
??? ??? [lrwxrwxrwx root    ]  link.properties -> /tmp/scratch/target.properties
??? [-rw-r--r-- fferrari]  target.properties

3 directories, 4 files
fferrari at vmhost:~$ cat /tmp/scratch/target.properties
name=value


Sice `protected` doesn't have execution permissions, we can't even open regular files inside `inner`:


fferrari at vmhost:~$ cat /tmp/scratch/protected/inner/regular.properties
cat: /tmp/scratch/protected/inner/regular.properties: Permission denied
fferrari at vmhost:~$ cat /tmp/scratch/protected/inner/link.properties
cat: /tmp/scratch/protected/inner/link.properties: Permission denied


This means that if we are trying to load `/tmp/scratch/protected/inner/link.properties`, even if `/tmp/scratch/target.properties` had a relative include, we wouldn't face its resolution, because `/tmp/scratch/protected/inner/link.properties` isn't readable.

Even in those cases, `File::getCanonicalFile` gives a reasonable result, and is able to substitute `.` and `..`:


fferrari at vmhost:~$ jshell -q -<<<'System.out.println(Path.of("/tmp/scratch/protected/inner/./regular.properties").toFile().getCanonicalFile())'
/tmp/scratch/protected/inner/regular.properties
fferrari at vmhost:~$ jshell -q -<<<'System.out.println(Path.of("/tmp/scratch/protected/inner/../inner/link.properties").toFile().getCanonicalFile())'
/tmp/scratch/protected/inner/link.properties


In _Windows_, as explained in the description, even if `FindFirstFileW` fails at some point, `File::getCanonicalFile` will proceed with a [later symlinks resolution](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L476). This edge case is exercised by the new test added in 7abb62c069ad35f4ec34f6cd9b9f6d05febceecc. So I can't think of a scenario where a symlink/soft-link that is readable isn't resolved.

### Final note

I might be missing something, so let me know if you have any other ideas to try. I provided commands to recreate my experiments in case you want to build on top of them.

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-2835992962

From weijun at openjdk.org  Mon Apr 28 18:10:45 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 28 Apr 2025 18:10:45 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 14:48:34 GMT, Weijun Wang  wrote:

>> Add 2 `MessageDigest` algorithms.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test alias usage

I mainly don't like the current [hardcoded branches](https://github.com/openjdk/jdk/blob/c54fc08aa3c63e4b26dc5edb2436844dfd3bab7c/src/java.base/share/classes/sun/security/pkcs/PKCS7.java#L754) (and [this one](https://github.com/openjdk/jdk/blob/c54fc08aa3c63e4b26dc5edb2436844dfd3bab7c/src/java.base/share/classes/sun/security/ec/ed/EdDSAParameters.java#L126)) currently inside JDK. I understand they are primarily used as a component of another algorithm and not directly used by end users. There will be more such code when we support preHash ML-DSA and SLH-DSA etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/24576#issuecomment-2836073545

From rriggs at openjdk.org  Mon Apr 28 18:24:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Apr 2025 18:24:53 GMT
Subject: Integrated: 8354053: Remove unused JavaIOFilePermissionAccess
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 21:26:08 GMT, Roger Riggs  wrote:

> The JavaIOFilePermissionAccess interface is removed from SharedSecrets and its implementation (FilePermCompat.java) used by the test is moved to java.io FilePermission where cross package access is not needed. 
> The test FilePermissionCollectionMerge is updated to access the internal implementation in FilePermission. 
> Modernized the initialization from the system property `jdk.io.permissionsUseCanonicalPath`. 
> The remaining support will be removed when FilePermission is removed.

This pull request has now been integrated.

Changeset: 2f844803
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/2f8448034f28276ad5ac1edfa0fb8650e47d4ffa
Stats:     260 lines in 5 files changed: 57 ins; 175 del; 28 mod

8354053: Remove unused JavaIOFilePermissionAccess

Reviewed-by: liach, weijun

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

PR: https://git.openjdk.org/jdk/pull/24603

From jnimeh at openjdk.org  Mon Apr 28 18:49:45 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 28 Apr 2025 18:49:45 GMT
Subject: RFR: 8355262: Test
 sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java failed:
 accept timed out
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 17:57:33 GMT, Artur Barashev  wrote:

> I wasn't able to reproduce the issue. Most likely it was caused by unusually high CPU load in test environment. Increasing the server's "accept" call time-out value from 5 to 10 seconds to make the test more robust.

The changes look good to me, but please add a "noreg-self" label to the JBS bug.

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

Marked as reviewed by jnimeh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24857#pullrequestreview-2800360438

From mullan at openjdk.org  Mon Apr 28 18:59:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Apr 2025 18:59:53 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: 
References: 
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
 
 
 
Message-ID: 

On Wed, 23 Apr 2025 13:07:31 GMT, Artur Barashev  wrote:

>> A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient` currently use this `SimpleSSLContext` construct to read the `testkeys` keystore that's available in the JDK repo's test directory. Moving to a dynamically created keystore instead of a keystore that's committed in the JDK repo seems reasonable. I think it would be better to do that as a separate task in future, since that would involve updating these existing tests to use this new mechanism too.
>
> Sounds good, this was just FYI.

I may be wrong, but it seems you only re-enable 3DES to test a non-TLS 1.3 cipher suite. But you don't have to use a 3DES suite to do that, you could use one of the suites that are already enabled (and are still considered strong), like "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256".

As a general comment, I would avoid re-enabling broken or disabled algorithms unless you specifically have to test that algorithm for some reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2064329287

From mullan at openjdk.org  Mon Apr 28 18:59:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Apr 2025 18:59:56 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v2]
In-Reply-To: <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
References: 
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
Message-ID: 

On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
> 
>  - merge latest changes from master branch
>  - http3: add missing 
     separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - http3: qpack - allow 0 capacity when max capacity is 0
>  - Remove flow control from stream limit comments
>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe

test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 130:

> 128:                             + "expect UnsupportedProtocolVersionException",
> 129:                     () -> connect(uriString, new SSLParameters(
> 130:                             new String[] { "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA" },

Shouldn't this be "TLS_AES_128_GCM_SHA256" (per the test comment above)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2064322739

From mullan at openjdk.org  Mon Apr 28 20:17:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Apr 2025 20:17:50 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Apr 2025 20:05:07 GMT, Mark Powers  wrote:

>> [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   need test

test/jdk/java/security/spec/InvalidArrayIndex.java line 1:

> 1: /*

Can you put this test in a new subdirectory named "RC2ParameterSpec"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24854#discussion_r2064472986

From mark.reinhold at oracle.com  Mon Apr 28 20:33:05 2025
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Mon, 28 Apr 2025 20:33:05 +0000
Subject: New candidate JEP: 470: PEM Encodings of Cryptographic Objects
 (Preview)
Message-ID: <20250428203304.731918132ED@eggemoggin.niobe.net>

https://openjdk.org/jeps/470

  Summary: Introduce an API for encoding objects that represent
  cryptographic keys, certificates, and certificate revocation lists into
  the widely-used Privacy-Enhanced Mail (PEM) transport format, and for
  decoding from that format back into objects.  This is a preview API.

- Mark

From mpowers at openjdk.org  Mon Apr 28 21:05:26 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 28 Apr 2025 21:05:26 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v3]
In-Reply-To: 
References: 
Message-ID: <4d3SMRqMpuBPY8lRiSSrIlvk5TdQVgrPxXLdPNx_IhY=.b4be6a71-ae21-4d96-95a5-6d05a64e7ff6@github.com>

> [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113)

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  comment from Sean

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24854/files
  - new: https://git.openjdk.org/jdk/pull/24854/files/064c847f..5d2a01fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24854&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24854&range=01-02

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24854.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24854/head:pull/24854

PR: https://git.openjdk.org/jdk/pull/24854

From mpowers at openjdk.org  Mon Apr 28 21:05:27 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 28 Apr 2025 21:05:27 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 28 Apr 2025 20:13:47 GMT, Sean Mullan  wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   need test
>
> test/jdk/java/security/spec/InvalidArrayIndex.java line 1:
> 
>> 1: /*
> 
> Can you put this test in a new subdirectory named "RC2ParameterSpec"?

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24854#discussion_r2064707791

From abarashev at openjdk.org  Mon Apr 28 21:37:21 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 28 Apr 2025 21:37:21 GMT
Subject: RFR: 8355779: When no "signature_algorithms_cert" extension is present
 we do not apply certificate scope constraints to algorithms in
 "signature_algorithms" extension
Message-ID: <7ccBNaPfuKqjmuPa4PaCMz4eTslkQZNZSycYSI03C0g=.0833fdd3-ffb2-4a83-bc83-52e4ef76554f@github.com>

Per TLSv1.3 RFC:


   If no "signature_algorithms_cert" extension is
   present, then the "signature_algorithms" extension also applies to
   signatures appearing in certificates.


When no "signature_algorithms_cert" extension is present in ClientHello we simply copy "signature_algorithms" extension algorithms already filtered with HANDSHAKE_SCOPE to `peerRequestedCertSignSchemes`. Instead we should filter "signature_algorithms" extension algorithms with CERTIFICATE_SCOPE as certain algorithms are allowed to be used in certificate signatures but not in handshake signatures.

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

Commit messages:
 - 8355779: When no "signature_algorithms_cert" extension is present we do not apply certificate scope constraints to algorithms in "signature_algorithms" extension

Changes: https://git.openjdk.org/jdk/pull/24939/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24939&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355779
  Stats: 94 lines in 1 file changed: 46 ins; 46 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24939/head:pull/24939

PR: https://git.openjdk.org/jdk/pull/24939

From abarashev at openjdk.org  Mon Apr 28 22:34:24 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 28 Apr 2025 22:34:24 GMT
Subject: RFR: 8355779: When no "signature_algorithms_cert" extension is
 present we do not apply certificate scope constraints to algorithms in
 "signature_algorithms" extension [v2]
In-Reply-To: <7ccBNaPfuKqjmuPa4PaCMz4eTslkQZNZSycYSI03C0g=.0833fdd3-ffb2-4a83-bc83-52e4ef76554f@github.com>
References: <7ccBNaPfuKqjmuPa4PaCMz4eTslkQZNZSycYSI03C0g=.0833fdd3-ffb2-4a83-bc83-52e4ef76554f@github.com>
Message-ID: 

> Per TLSv1.3 RFC:
> 
> 
>    If no "signature_algorithms_cert" extension is
>    present, then the "signature_algorithms" extension also applies to
>    signatures appearing in certificates.
> 
> 
> When no "signature_algorithms_cert" extension is present in ClientHello we simply copy "signature_algorithms" extension algorithms already filtered with HANDSHAKE_SCOPE to `peerRequestedCertSignSchemes`. Instead we should filter "signature_algorithms" extension algorithms with CERTIFICATE_SCOPE as certain algorithms are allowed to be used in certificate signatures but not in handshake signatures.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Take "signature_algorithms_cert" extension as parameter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24939/files
  - new: https://git.openjdk.org/jdk/pull/24939/files/7d3b3eee..ae1b3060

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24939&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24939&range=00-01

  Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24939/head:pull/24939

PR: https://git.openjdk.org/jdk/pull/24939

From valeriep at openjdk.org  Mon Apr 28 23:04:50 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 28 Apr 2025 23:04:50 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 28 Apr 2025 18:08:22 GMT, Weijun Wang  wrote:

> I mainly don't like the current [hardcoded branches](https://github.com/openjdk/jdk/blob/c54fc08aa3c63e4b26dc5edb2436844dfd3bab7c/src/java.base/share/classes/sun/security/pkcs/PKCS7.java#L754) (and [this one](https://github.com/openjdk/jdk/blob/c54fc08aa3c63e4b26dc5edb2436844dfd3bab7c/src/java.base/share/classes/sun/security/ec/ed/EdDSAParameters.java#L126)) currently inside JDK. I understand they are primarily used as a component of another algorithm and not directly used by end users. There will be more such code when we support preHash ML-DSA and SLH-DSA etc.

So, you will replace these hardcoded branches with these in a separate PR? I agree that it'd be nice to do without the hardcoded internal impls, just not sure if we need to caution people using them as regular MessageDigest algorithms.

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

PR Comment: https://git.openjdk.org/jdk/pull/24576#issuecomment-2836966712

From mpowers at openjdk.org  Tue Apr 29 01:21:44 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 29 Apr 2025 01:21:44 GMT
Subject: RFR: 8350498: Remove two Camerfirma root CA certificates
In-Reply-To: <2M081CsD83WrCk9PYgmB01CprSr0mr4MB1CP66-847c=.a2b4262a-a020-41c3-9bed-727227739e96@github.com>
References: <2M081CsD83WrCk9PYgmB01CprSr0mr4MB1CP66-847c=.a2b4262a-a020-41c3-9bed-727227739e96@github.com>
Message-ID: 

On Tue, 22 Apr 2025 20:27:04 GMT, Rajan Halade  wrote:

> The change is to remove two Camerfirma root certificates which are terminated and no longer in use. These two roots are removed from `cacerts` truststore. Distrust of these roots is also removed as these roots will no longer be trusted by JDK by default.
> 
> The release-note is at [JDK-8355325](https://bugs.openjdk.org/browse/JDK-8355325)

This looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/24800#issuecomment-2837171301

From valeriep at openjdk.org  Tue Apr 29 01:41:44 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 29 Apr 2025 01:41:44 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms [v3]
In-Reply-To: 
References: 
 
Message-ID: <7tQk66i69YQpgGj4_thPeRH0Dvx3Z5ohyzefcsLL7wA=.b11500ea-08b1-4961-b65d-e68082b56d92@github.com>

On Mon, 28 Apr 2025 14:48:34 GMT, Weijun Wang  wrote:

>> Add 2 `MessageDigest` algorithms.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test alias usage

Changes look fine. However, we should probably caution about these being different from the regular message digest algorithms, i.e. regarding their related output property.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24576#pullrequestreview-2801570550

From michael.osipov at innomotics.com  Tue Apr 29 08:54:31 2025
From: michael.osipov at innomotics.com (Osipov, Michael (IN IT IN))
Date: Tue, 29 Apr 2025 10:54:31 +0200
Subject: [Bug] NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is
 used with QOP auth-int against Active Directory
In-Reply-To: <46878900-7af6-42c7-8b66-f8e0ca4decb3@siemens.com>
References: <46878900-7af6-42c7-8b66-f8e0ca4decb3@siemens.com>
Message-ID: <9baba8d6-066a-42cd-9649-e16033108ee7@siemens.com>

On 2025-04-28 10:22, Osipov, Michael (IN IT IN) wrote:
 > Hi folks,
 > Hi Max,
 >
 > please assess the following bug I have found in Java 11+, it does not 
exist
 > in Java 8. I have tried the following most versions on Azul Zulu/
 > OpenJDK: 8, 11, 17, 21, 24 on multiple platforms. Searched JBS as well,
 > nothing found.

I was able to debug this and find the cause.
It is a regression from 
https://github.com/openjdk/jdk11u/commit/bcac47f00ac6cf511ad7709fb9d39276ac27b049, 
introduced with https://bugs.openjdk.org/browse/JDK-8313657.
I can even reproduce this with the HPE JDK 8 for HP-UX, so I guess they 
have backported that broken fix.

Connection#flushAndCloseOutputStream() closes the SaslOutputStream() 
which disposes the GSS security context and sets it to null. After that 
Connection#abandonRequest(LdapRequest, Control[]) is invoked which still 
uses the SaslOutputStream:
 >             synchronized (this) {
 >                 outStream.write(ber.getBuf(), 0, ber.getDataLen());
 >                 outStream.flush();
 >             }

Andrew,

can you log a bug here?

Michael

From mullan at openjdk.org  Tue Apr 29 13:10:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 13:10:53 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v3]
In-Reply-To: <4d3SMRqMpuBPY8lRiSSrIlvk5TdQVgrPxXLdPNx_IhY=.b4be6a71-ae21-4d96-95a5-6d05a64e7ff6@github.com>
References: 
 <4d3SMRqMpuBPY8lRiSSrIlvk5TdQVgrPxXLdPNx_IhY=.b4be6a71-ae21-4d96-95a5-6d05a64e7ff6@github.com>
Message-ID: <9yT-ZmXOhS_whlyOlxSp33EH1lNP5P6SvTQPJ1qkbtM=.5d0afa2a-9636-48de-9369-e5acdd3a818e@github.com>

On Mon, 28 Apr 2025 21:05:26 GMT, Mark Powers  wrote:

>> [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Sean

src/java.base/share/classes/javax/crypto/spec/RC2ParameterSpec.java line 107:

> 105:         if (offset < 0) {
> 106:             throw new ArrayIndexOutOfBoundsException("offset is negative");
> 107:         }

Move these lines before line 104 as `blocksize` doesn't need to be set until after this check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24854#discussion_r2066320225

From michaelm at openjdk.org  Tue Apr 29 14:05:44 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 29 Apr 2025 14:05:44 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v9]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Review update
 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov 
 - doc + copyright update
 - ... and 13 more: https://git.openjdk.org/jdk/compare/6a0c24f9...1a14f4bd

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=08
  Stats: 949 lines in 42 files changed: 716 ins; 101 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From mullan at openjdk.org  Tue Apr 29 14:19:51 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 14:19:51 GMT
Subject: RFR: 8350498: Remove two Camerfirma root CA certificates
In-Reply-To: <2M081CsD83WrCk9PYgmB01CprSr0mr4MB1CP66-847c=.a2b4262a-a020-41c3-9bed-727227739e96@github.com>
References: <2M081CsD83WrCk9PYgmB01CprSr0mr4MB1CP66-847c=.a2b4262a-a020-41c3-9bed-727227739e96@github.com>
Message-ID: 

On Tue, 22 Apr 2025 20:27:04 GMT, Rajan Halade  wrote:

> The change is to remove two Camerfirma root certificates which are terminated and no longer in use. These two roots are removed from `cacerts` truststore. Distrust of these roots is also removed as these roots will no longer be trusted by JDK by default.
> 
> The release-note is at [JDK-8355325](https://bugs.openjdk.org/browse/JDK-8355325)

Looks good. I assume you also plan to backport this.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24800#pullrequestreview-2803840984

From mpowers at openjdk.org  Tue Apr 29 16:26:35 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 29 Apr 2025 16:26:35 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v4]
In-Reply-To: 
References: 
Message-ID: 

> [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113)

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  second comment from Sean

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24854/files
  - new: https://git.openjdk.org/jdk/pull/24854/files/5d2a01fc..b0193ad7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24854&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24854&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24854.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24854/head:pull/24854

PR: https://git.openjdk.org/jdk/pull/24854

From mpowers at openjdk.org  Tue Apr 29 16:26:36 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 29 Apr 2025 16:26:36 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v3]
In-Reply-To: <9yT-ZmXOhS_whlyOlxSp33EH1lNP5P6SvTQPJ1qkbtM=.5d0afa2a-9636-48de-9369-e5acdd3a818e@github.com>
References: 
 <4d3SMRqMpuBPY8lRiSSrIlvk5TdQVgrPxXLdPNx_IhY=.b4be6a71-ae21-4d96-95a5-6d05a64e7ff6@github.com>
 <9yT-ZmXOhS_whlyOlxSp33EH1lNP5P6SvTQPJ1qkbtM=.5d0afa2a-9636-48de-9369-e5acdd3a818e@github.com>
Message-ID: 

On Tue, 29 Apr 2025 13:08:36 GMT, Sean Mullan  wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment from Sean
>
> src/java.base/share/classes/javax/crypto/spec/RC2ParameterSpec.java line 107:
> 
>> 105:         if (offset < 0) {
>> 106:             throw new ArrayIndexOutOfBoundsException("offset is negative");
>> 107:         }
> 
> Move these lines before line 104 as `blocksize` doesn't need to be set until after this check.

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24854#discussion_r2066923298

From mullan at openjdk.org  Tue Apr 29 16:54:49 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 16:54:49 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 16:26:35 GMT, Mark Powers  wrote:

>> [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   second comment from Sean

test/jdk/java/security/spec/RC2ParameterSpec/InvalidArrayIndex.java line 4:

> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 3:  * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
> 4:  */

Copyright is not correct, see other open tests for copyright to copy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24854#discussion_r2066967205

From mpowers at openjdk.org  Tue Apr 29 17:51:26 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 29 Apr 2025 17:51:26 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v5]
In-Reply-To: 
References: 
Message-ID: 

> [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113)

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  third comment from Sean

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24854/files
  - new: https://git.openjdk.org/jdk/pull/24854/files/b0193ad7..2ad5edcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24854&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24854&range=03-04

  Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24854.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24854/head:pull/24854

PR: https://git.openjdk.org/jdk/pull/24854

From mpowers at openjdk.org  Tue Apr 29 17:51:27 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 29 Apr 2025 17:51:27 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 29 Apr 2025 16:52:09 GMT, Sean Mullan  wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   second comment from Sean
>
> test/jdk/java/security/spec/RC2ParameterSpec/InvalidArrayIndex.java line 4:
> 
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
>> 3:  * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
>> 4:  */
> 
> Copyright is not correct, see other open tests for copyright to copy.

Fixed. How did that happen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24854#discussion_r2067050756

From valeriep at openjdk.org  Tue Apr 29 17:52:46 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 29 Apr 2025 17:52:46 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Apr 2025 14:48:34 GMT, Weijun Wang  wrote:

>> Add 2 `MessageDigest` algorithms.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test alias usage

Update CSR with the new names, e.g. with the output length suffix?

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

PR Comment: https://git.openjdk.org/jdk/pull/24576#issuecomment-2839724410

From wetmore at openjdk.org  Tue Apr 29 18:15:45 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 29 Apr 2025 18:15:45 GMT
Subject: RFR: 8355262: Test
 sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java failed:
 accept timed out
In-Reply-To: 
References: 
Message-ID: <2TTDJ_UzDrgEbnf-CzRJSrIAuiUFNO0WGoaUer84pz4=.00acc318-b338-4a0c-aab4-23dad75a9c7e@github.com>

On Thu, 24 Apr 2025 17:57:33 GMT, Artur Barashev  wrote:

> I wasn't able to reproduce the issue. Most likely it was caused by unusually high CPU load in test environment. Increasing the server's "accept" call time-out value from 5 to 10 seconds to make the test more robust.

LGTM.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24857#pullrequestreview-2804558288

From mullan at openjdk.org  Tue Apr 29 18:21:46 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 18:21:46 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 17:51:26 GMT, Mark Powers  wrote:

>> [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   third comment from Sean

LGTM. But see my one comment about a separate issue I noticed.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24854#pullrequestreview-2804571907

From mullan at openjdk.org  Tue Apr 29 18:21:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 18:21:47 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v3]
In-Reply-To: 
References: 
 <4d3SMRqMpuBPY8lRiSSrIlvk5TdQVgrPxXLdPNx_IhY=.b4be6a71-ae21-4d96-95a5-6d05a64e7ff6@github.com>
 <9yT-ZmXOhS_whlyOlxSp33EH1lNP5P6SvTQPJ1qkbtM=.5d0afa2a-9636-48de-9369-e5acdd3a818e@github.com>
 
Message-ID: 

On Tue, 29 Apr 2025 16:22:43 GMT, Mark Powers  wrote:

>> src/java.base/share/classes/javax/crypto/spec/RC2ParameterSpec.java line 107:
>> 
>>> 105:         if (offset < 0) {
>>> 106:             throw new ArrayIndexOutOfBoundsException("offset is negative");
>>> 107:         }
>> 
>> Move these lines before line 104 as `blocksize` doesn't need to be set until after this check.
>
> done

This is a side issue, but it looks like this API can also throw `IndexOutOfBoundsException` if an offset is input which causes `System.arraycopy` (on line 112) to access the iv out of range. Please check and file a separate issue to have this exception documented, if so.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24854#discussion_r2067096446

From mullan at openjdk.org  Tue Apr 29 18:54:48 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 18:54:48 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: 
References: 
 
Message-ID: <1Hqmd2bhIEmM17y03jXhCJOGWCuPiBXNG1yvBMq8xh4=.5521be52-9fb1-41bd-9fb6-f5cd12c6cd5f@github.com>

On Thu, 24 Apr 2025 18:30:00 GMT, Artur Barashev  wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Skip explicit KeyPair initialization and let the provider default set it

test/jdk/sun/security/tools/keytool/PrintSSL.java line 57:

> 55:                 + "-keystore keystore -storepass passphrase "
> 56:                 + "-keypass passphrase -keyalg rsa -keysize 1024 "
> 57:                 + "-sigalg MD5withRSA -alias rsa_alias -dname CN=Server");

I think it would be better to use the current weak algorithms (as the comment on line 53 notes) and set the server's keymanager to SunX509 as it seems the purpose of this test is to ensure `keytool -printcert -sslserver` can deal with weak algorithms in certs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2067150242

From duke at openjdk.org  Tue Apr 29 18:55:22 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 29 Apr 2025 18:55:22 GMT
Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM
Message-ID: 

By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

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

Commit messages:
 - 8351412: Add AVX-512 intrinsics for ML-KEM

Changes: https://git.openjdk.org/jdk/pull/24953/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24953&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351412
  Stats: 981 lines in 10 files changed: 969 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24953/head:pull/24953

PR: https://git.openjdk.org/jdk/pull/24953

From mullan at openjdk.org  Tue Apr 29 19:04:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 19:04:47 GMT
Subject: RFR: 8230016: re-visit test
 sun/security/pkcs11/Serialize/SerializeProvider.java
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Apr 2025 10:15:06 GMT, Mikhail Yankelevich  wrote:

> Provider is now added to the Security before the test

test/jdk/sun/security/pkcs11/Serialize/SerializeProvider.java line 51:

> 49: 
> 50:         if (Security.getProvider(p.getName()) != p) {
> 51:             throw new SkippedException("Provider not installed in Security, skipping");

Hmm, is this check needed? The provider was added on line 47.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24750#discussion_r2067164916

From mpowers at openjdk.org  Tue Apr 29 19:15:58 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 29 Apr 2025 19:15:58 GMT
Subject: Integrated: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 17:22:22 GMT, Mark Powers  wrote:

> [JDK-8351113](https://bugs.openjdk.org/browse/JDK-8351113)

This pull request has now been integrated.

Changeset: c2485d5f
Author:    Mark Powers 
URL:       https://git.openjdk.org/jdk/commit/c2485d5f7dd00eaed34a5d309276114eb4c78cb0
Stats:     46 lines in 2 files changed: 45 ins; 0 del; 1 mod

8351113: RC2ParameterSpec throws IllegalArgumentException when offset is negative

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk/pull/24854

From weijun at openjdk.org  Tue Apr 29 19:22:49 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 29 Apr 2025 19:22:49 GMT
Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 29 Apr 2025 17:50:01 GMT, Valerie Peng  wrote:

> Update CSR with the new names, e.g. with the output length suffix?

Thanks for reminding. Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/24576#issuecomment-2839977324

From mullan at openjdk.org  Tue Apr 29 19:25:45 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 19:25:45 GMT
Subject: RFR: 8353001: Remove leftover Security Manager parsing code in
 sun.security.util.Debug
In-Reply-To: 
References: 
Message-ID: <8yVttgfkDJbZ9shvMHBUoCdzR_MyLClkpxFWlQznNVc=.06867bed-3e80-4d9f-b08e-23c5b94fc940@github.com>

On Thu, 17 Apr 2025 17:32:03 GMT, Koushik Muthukrishnan Thirupattur  wrote:

> The private marshal() method in sun.security.util.Debug still contains code to parse "permission=" and "codebase=" options. These sub-options were part of the "access" option which was removed in JDK 24 as part of JEP 486, so this code can be removed.

src/java.base/share/classes/sun/security/util/Debug.java line 359:

> 357: 
> 358:             // convert to lower-case characters
> 359:             return String.valueOf(args.toLowerCase(Locale.ENGLISH));

You can just return `args.toLowerCase(Locale.ENGLISH)`. Or better yet, you don't need the `marshal` method anymore, and can just replace the one call to marshal with this line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24731#discussion_r2067191328

From duke at openjdk.org  Tue Apr 29 19:36:45 2025
From: duke at openjdk.org (duke)
Date: Tue, 29 Apr 2025 19:36:45 GMT
Subject: RFR: 8355262: Test
 sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java failed:
 accept timed out
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 17:57:33 GMT, Artur Barashev  wrote:

> I wasn't able to reproduce the issue. Most likely it was caused by unusually high CPU load in test environment. Increasing the server's "accept" call time-out value from 5 to 10 seconds to make the test more robust.

@artur-oracle 
Your change (at version e4cb7af4ce47c7725c2fb02d038c0dcd2fbc0589) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24857#issuecomment-2840029677

From mullan at openjdk.org  Tue Apr 29 20:01:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 20:01:50 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: 
References: 
 
Message-ID: <9LYMLlIiNt0v4FqENELTnXGo2HwLJaeuyoGTEctT5q8=.c4e59bd0-061c-4ffa-89cb-eedfca4a5727@github.com>

On Thu, 24 Apr 2025 18:30:00 GMT, Artur Barashev  wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Skip explicit KeyPair initialization and let the provider default set it

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 52:

> 50: 
> 51: public class SSLSocketParametersTest extends SSLContextTemplate implements
> 52:         Serializable {

As an aside, I can't see any reason this test needs to implement Serializable, as nothing in the test depends on it or tests it. I removed it locally and the test still passes. Consider removing it as a cleanup (but if you do, run it thru mach5 to be safe).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2067282326

From abarashev at openjdk.org  Tue Apr 29 20:45:53 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Apr 2025 20:45:53 GMT
Subject: Integrated: 8355262: Test
 sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java failed:
 accept timed out
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Apr 2025 17:57:33 GMT, Artur Barashev  wrote:

> I wasn't able to reproduce the issue. Most likely it was caused by unusually high CPU load in test environment. Increasing the server's "accept" call time-out value from 5 to 10 seconds to make the test more robust.

This pull request has now been integrated.

Changeset: 8b16897b
Author:    Artur Barashev 
Committer: Bradford Wetmore 
URL:       https://git.openjdk.org/jdk/commit/8b16897b74cfdc3c2693e3ae7e05f3d8c6468ebe
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8355262: Test sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java failed: accept timed out

Reviewed-by: jnimeh, wetmore

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

PR: https://git.openjdk.org/jdk/pull/24857

From abarashev at openjdk.org  Tue Apr 29 21:02:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Apr 2025 21:02:49 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: <1Hqmd2bhIEmM17y03jXhCJOGWCuPiBXNG1yvBMq8xh4=.5521be52-9fb1-41bd-9fb6-f5cd12c6cd5f@github.com>
References: 
 
 <1Hqmd2bhIEmM17y03jXhCJOGWCuPiBXNG1yvBMq8xh4=.5521be52-9fb1-41bd-9fb6-f5cd12c6cd5f@github.com>
Message-ID: 

On Tue, 29 Apr 2025 18:51:58 GMT, Sean Mullan  wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Skip explicit KeyPair initialization and let the provider default set it
>
> test/jdk/sun/security/tools/keytool/PrintSSL.java line 57:
> 
>> 55:                 + "-keystore keystore -storepass passphrase "
>> 56:                 + "-keypass passphrase -keyalg rsa -keysize 1024 "
>> 57:                 + "-sigalg MD5withRSA -alias rsa_alias -dname CN=Server");
> 
> I think it would be better to use the current weak algorithms (as the comment on line 53 notes) and set the server's keymanager to SunX509 (with the `javax.net.ssl.keyStoreType` system prop) as it seems the purpose of this test is to ensure `keytool -printcert -sslserver` can deal with weak algorithms in certs.

Indeed, good catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2067424166

From abarashev at openjdk.org  Tue Apr 29 21:05:47 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Apr 2025 21:05:47 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v2]
In-Reply-To: <9LYMLlIiNt0v4FqENELTnXGo2HwLJaeuyoGTEctT5q8=.c4e59bd0-061c-4ffa-89cb-eedfca4a5727@github.com>
References: 
 
 <9LYMLlIiNt0v4FqENELTnXGo2HwLJaeuyoGTEctT5q8=.c4e59bd0-061c-4ffa-89cb-eedfca4a5727@github.com>
Message-ID: 

On Tue, 29 Apr 2025 19:58:42 GMT, Sean Mullan  wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Skip explicit KeyPair initialization and let the provider default set it
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 52:
> 
>> 50: 
>> 51: public class SSLSocketParametersTest extends SSLContextTemplate implements
>> 52:         Serializable {
> 
> As an aside, I can't see any reason this test needs to implement Serializable, as nothing in the test depends on it or tests it. I removed it locally and the test still passes. Consider removing it as a cleanup (but if you do, run it thru mach5 to be safe).

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24756#discussion_r2067427345

From valeriep at openjdk.org  Tue Apr 29 21:44:26 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 29 Apr 2025 21:44:26 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: 
References: 
Message-ID: 

> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
> 
> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
> 
> Thanks in advance for the review~

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Add comment about not using the same HKDF instance.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24393/files
  - new: https://git.openjdk.org/jdk/pull/24393/files/ebc635ca..cc7fd3a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=04-05

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24393/head:pull/24393

PR: https://git.openjdk.org/jdk/pull/24393

From abarashev at openjdk.org  Tue Apr 29 21:51:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 29 Apr 2025 21:51:00 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: 
References: 
Message-ID: 

> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
> 
> Compatibility considerations:
> 
> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
> 
> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
> 
> **SUNX509**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> Finished running test 'micro:java.security.SSLHandshake'
> 
> **PKIX**
> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
> Finished running test 'micro:java.security.SSLHandshake'

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24756/files
  - new: https://git.openjdk.org/jdk/pull/24756/files/e5e83514..2b0c5525

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24756&range=01-02

  Stats: 10 lines in 2 files changed: 6 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24756/head:pull/24756

PR: https://git.openjdk.org/jdk/pull/24756

From mpowers at openjdk.org  Tue Apr 29 22:13:51 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 29 Apr 2025 22:13:51 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v3]
In-Reply-To: 
References: 
 <4d3SMRqMpuBPY8lRiSSrIlvk5TdQVgrPxXLdPNx_IhY=.b4be6a71-ae21-4d96-95a5-6d05a64e7ff6@github.com>
 <9yT-ZmXOhS_whlyOlxSp33EH1lNP5P6SvTQPJ1qkbtM=.5d0afa2a-9636-48de-9369-e5acdd3a818e@github.com>
 
 
Message-ID: 

On Tue, 29 Apr 2025 18:16:47 GMT, Sean Mullan  wrote:

>> done
>
> This is a side issue, but it looks like this API can also throw `IndexOutOfBoundsException` if an offset is input which causes `System.arraycopy` (on line 112) to access the iv out of range. Please check and file a separate issue to have this exception documented, if so.

I don't think this can happen because of the check on line 108.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24854#discussion_r2067500142

From mullan at openjdk.org  Tue Apr 29 22:37:51 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Apr 2025 22:37:51 GMT
Subject: RFR: 8351113: RC2ParameterSpec throws IllegalArgumentException
 when offset is negative [v3]
In-Reply-To: 
References: 
 <4d3SMRqMpuBPY8lRiSSrIlvk5TdQVgrPxXLdPNx_IhY=.b4be6a71-ae21-4d96-95a5-6d05a64e7ff6@github.com>
 <9yT-ZmXOhS_whlyOlxSp33EH1lNP5P6SvTQPJ1qkbtM=.5d0afa2a-9636-48de-9369-e5acdd3a818e@github.com>
 
 
 
Message-ID: 

On Tue, 29 Apr 2025 22:11:20 GMT, Mark Powers  wrote:

>> This is a side issue, but it looks like this API can also throw `IndexOutOfBoundsException` if an offset is input which causes `System.arraycopy` (on line 112) to access the iv out of range. Please check and file a separate issue to have this exception documented, if so.
>
> I don't think this can happen because of the check on line 108.

Ah yes, you're right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24854#discussion_r2067518547

From ascarpino at openjdk.org  Tue Apr 29 23:12:45 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 29 Apr 2025 23:12:45 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 21:51:00 GMT, Artur Barashev  wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

> > The discussion of #17956 contains an extensive performance analyses.
> 
> TL;DR: PKCS12 decrypts the private key before every use. The performance hit comes from applying PBKDF2 to the key encryption password.
> 
> SunX509 caches the private keys during initialization. PKIX always reads them directly from the keystore.

Is this a reflection of the perf test and not something seen in the real world, or something that needs to be fixed before or soon after this PR is integrated?

There doesn't seem to be much concern about a 2x slowdown which I'm a bit surprised about.

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2840432152

From weijun at openjdk.org  Tue Apr 29 23:59:47 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 29 Apr 2025 23:59:47 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 21:44:26 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about not using the same HKDF instance.

LGTM. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24393#pullrequestreview-2805361963

From duke at openjdk.org  Wed Apr 30 03:21:19 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 30 Apr 2025 03:21:19 GMT
Subject: RFR: 8353001: Remove leftover Security Manager parsing code in
 sun.security.util.Debug [v2]
In-Reply-To: 
References: 
Message-ID: 

> The private marshal() method in sun.security.util.Debug still contains code to parse "permission=" and "codebase=" options. These sub-options were part of the "access" option which was removed in JDK 24 as part of JEP 486, so this code can be removed.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8353001:Remove leftover Security Manager parsing code in sun.security.util.Debug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24731/files
  - new: https://git.openjdk.org/jdk/pull/24731/files/eecfa21b..e411203d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24731&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24731&range=00-01

  Stats: 14 lines in 1 file changed: 0 ins; 13 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24731.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24731/head:pull/24731

PR: https://git.openjdk.org/jdk/pull/24731

From djelinski at openjdk.org  Wed Apr 30 06:01:57 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 30 Apr 2025 06:01:57 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 21:44:26 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about not using the same HKDF instance.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24393#pullrequestreview-2805832387

From djelinski at openjdk.org  Wed Apr 30 06:20:46 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 30 Apr 2025 06:20:46 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 21:51:00 GMT, Artur Barashev  wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

This slowdown is seen in the real world. It is concerning, but not easily fixable.

I am not in the TLS server business at the moment, but the cases I used to work with [*] were perfectly well served by SunX509, so I guess some users will just keep using that. The fix for the PKIX+PKCS12 speed is not exactly easy. The options we explored were either incompatible with the existing implementation, or introduced subtle bugs in some corner cases.

[*] The servers I used to work with had either only one certificate, or one RSA and one EC certificate. We had to manually disable the TLS_RSA and TLS_ECDH ciphers, but these are disabled by default today. SunX509 serves that situation pretty well.

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2840918307

From duke at openjdk.org  Wed Apr 30 07:48:32 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 30 Apr 2025 07:48:32 GMT
Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v2]
In-Reply-To: 
References: 
Message-ID: 

> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Removed debugging changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24953/files
  - new: https://git.openjdk.org/jdk/pull/24953/files/4ef7c737..c5c6449f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24953&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24953&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24953/head:pull/24953

PR: https://git.openjdk.org/jdk/pull/24953

From dfuchs at openjdk.org  Wed Apr 30 10:19:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Apr 2025 10:19:54 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
> 
> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 411 commits:

 - merge latest changes from master branch
 - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods.
 - merge latest changes from master branch
 - http3: add missing 
     separator to Http3DiscoveryMode.ALT_SVC API documentation
 - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
 - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
 - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
 - http3: minor improvement to log message
 - http3: Artur's review - remove commented out code from test
 - http3: Artur's review - make methods package private
 - ... and 401 more: https://git.openjdk.org/jdk/compare/c2485d5f...dfa26044

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=02
  Stats: 102863 lines in 472 files changed: 100230 ins; 1120 del; 1513 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From mullan at openjdk.org  Wed Apr 30 12:27:49 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Apr 2025 12:27:49 GMT
Subject: RFR: 8353001: Remove leftover Security Manager parsing code in
 sun.security.util.Debug [v2]
In-Reply-To: 
References: 
 
Message-ID: <2PKxa9dFnctIa0Hux2ll4Ut0Yudi8AvG3-l4lpSjV14=.f88f12d6-b60e-4517-b150-01b360e8b088@github.com>

On Wed, 30 Apr 2025 03:21:19 GMT, Koushik Muthukrishnan Thirupattur  wrote:

>> The private marshal() method in sun.security.util.Debug still contains code to parse "permission=" and "codebase=" options. These sub-options were part of the "access" option which was removed in JDK 24 as part of JEP 486, so this code can be removed.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353001:Remove leftover Security Manager parsing code in sun.security.util.Debug

src/java.base/share/classes/sun/security/util/Debug.java line 369:

> 367:                 "[a-zA-Z_$][a-zA-Z0-9_$]*([.][a-zA-Z_$][a-zA-Z0-9_$]*)*";
> 368:             Pattern pattern = Pattern.compile(reg);
> 369:             Matcher matcher = pattern.matcher(source);

You can remove the import of `Matcher` as it is no longer used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24731#discussion_r2068557271

From coffeys at openjdk.org  Wed Apr 30 12:57:13 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 30 Apr 2025 12:57:13 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v12]
In-Reply-To: 
References: 
Message-ID: <-tU0WBb0H2kvRX76WDjHsuYeGJEEtp8ON2UrcjVMJyw=.95e9b07a-ca52-425d-b628-d4226d889333@github.com>

> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
> 
> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
> 
> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
> 
> 
>         System.err.println("help           print the help messages");
>         System.err.println("expand         expand debugging information");
>         System.err.println();
>         System.err.println("all            turn on all debugging");
>         System.err.println("ssl            turn on ssl debugging");
>         System.err.println();
>         System.err.println("The following can be used with ssl:");
>         System.err.println("\trecord       enable per-record tracing");
>         System.err.println("\thandshake    print each handshake message");
>         System.err.println("\tkeygen       print key generation data");
>         System.err.println("\tsession      print session activity");
>         System.err.println("\tdefaultctx   print default SSL initialization");
>         System.err.println("\tsslctx       print SSLContext tracing");
>         System.err.println("\tsessioncache print session cache tracing");
>         System.err.println("\tkeymanager   print key manager tracing");
>         System.err.println("\ttrustmanager print trust manager tracing");
>         System.err.println("\tpluggability print pluggability tracing");
>         System.err.println();
>         System.err.println("\thandshake debugging can be widened with:");
>         System.err.println("\tdata         hex dump of each handshake message");
>         System.err.println("\tverbose      verbose handshake message printing");
>         System.err.println();
>         System.err.println("\trecord debugging can be widened with:");
>         System.err.println("\tplaintext    hex dump of record plaintext");
>         System.err.println("\tpacket       print raw SSL/TLS packets");
> 
> 
> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
> 
> the output has changed slightly with respect to that  - less verbose
> 
> e.g. old style:
> 
> 
> javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut...

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - erroneous edit to test file
 - remove legacy test and minor fix ups
 - Merge branch 'master' into 8044609-ssl
 - enums refactoring and line width correction
 - convert to enum options and refactor
 - minor refactor and clean up
 - Merge branch 'master' into 8044609-ssl
 - Merge branch 'master' into 8044609-ssl
 - Fix up isOn values
 - EMPTYALL enum addition
 - ... and 19 more: https://git.openjdk.org/jdk/compare/526951db...002d421f

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

Changes: https://git.openjdk.org/jdk/pull/18764/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=11
  Stats: 1244 lines in 79 files changed: 458 ins; 97 del; 689 mod
  Patch: https://git.openjdk.org/jdk/pull/18764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764

PR: https://git.openjdk.org/jdk/pull/18764

From coffeys at openjdk.org  Wed Apr 30 13:01:45 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 30 Apr 2025 13:01:45 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v13]
In-Reply-To: 
References: 
Message-ID: 

> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
> 
> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
> 
> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
> 
> 
>         System.err.println("help           print the help messages");
>         System.err.println("expand         expand debugging information");
>         System.err.println();
>         System.err.println("all            turn on all debugging");
>         System.err.println("ssl            turn on ssl debugging");
>         System.err.println();
>         System.err.println("The following can be used with ssl:");
>         System.err.println("\trecord       enable per-record tracing");
>         System.err.println("\thandshake    print each handshake message");
>         System.err.println("\tkeygen       print key generation data");
>         System.err.println("\tsession      print session activity");
>         System.err.println("\tdefaultctx   print default SSL initialization");
>         System.err.println("\tsslctx       print SSLContext tracing");
>         System.err.println("\tsessioncache print session cache tracing");
>         System.err.println("\tkeymanager   print key manager tracing");
>         System.err.println("\ttrustmanager print trust manager tracing");
>         System.err.println("\tpluggability print pluggability tracing");
>         System.err.println();
>         System.err.println("\thandshake debugging can be widened with:");
>         System.err.println("\tdata         hex dump of each handshake message");
>         System.err.println("\tverbose      verbose handshake message printing");
>         System.err.println();
>         System.err.println("\trecord debugging can be widened with:");
>         System.err.println("\tplaintext    hex dump of record plaintext");
>         System.err.println("\tpacket       print raw SSL/TLS packets");
> 
> 
> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
> 
> the output has changed slightly with respect to that  - less verbose
> 
> e.g. old style:
> 
> 
> javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut...

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  remove whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18764/files
  - new: https://git.openjdk.org/jdk/pull/18764/files/002d421f..98b3b0c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764

PR: https://git.openjdk.org/jdk/pull/18764

From coffeys at openjdk.org  Wed Apr 30 13:13:54 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 30 Apr 2025 13:13:54 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Apr 2025 13:01:45 GMT, Sean Coffey  wrote:

>> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
>> 
>> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
>> 
>> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
>> 
>> 
>>         System.err.println("help           print the help messages");
>>         System.err.println("expand         expand debugging information");
>>         System.err.println();
>>         System.err.println("all            turn on all debugging");
>>         System.err.println("ssl            turn on ssl debugging");
>>         System.err.println();
>>         System.err.println("The following can be used with ssl:");
>>         System.err.println("\trecord       enable per-record tracing");
>>         System.err.println("\thandshake    print each handshake message");
>>         System.err.println("\tkeygen       print key generation data");
>>         System.err.println("\tsession      print session activity");
>>         System.err.println("\tdefaultctx   print default SSL initialization");
>>         System.err.println("\tsslctx       print SSLContext tracing");
>>         System.err.println("\tsessioncache print session cache tracing");
>>         System.err.println("\tkeymanager   print key manager tracing");
>>         System.err.println("\ttrustmanager print trust manager tracing");
>>         System.err.println("\tpluggability print pluggability tracing");
>>         System.err.println();
>>         System.err.println("\thandshake debugging can be widened with:");
>>         System.err.println("\tdata         hex dump of each handshake message");
>>         System.err.println("\tverbose      verbose handshake message printing");
>>         System.err.println();
>>         System.err.println("\trecord debugging can be widened with:");
>>         System.err.println("\tplaintext    hex dump of record plaintext");
>>         System.err.println("\tpacket       print raw SSL/TLS packets");
>> 
>> 
>> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
>> 
>> the output has changed slightly with respect to that  - less verbose
>> 
>> e.g. old...
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove whitespace

Seems to be agreement that the javax.net.debug property should behave in the following manner:

"all" indicates that all debug data will be logged
"ssl" by itself indicates that all debug data except data from the "data" and "packet" categories will be logged
"ssl" followed by any number of sub-components indicates that generic ssl data will be logged along will more specific data from the subcomponents specified.

As always, an empty value means a System Logger is used.			
			
Overhaul of SSLLogger to represent debug levels via a new enum (SSLLogger.Opt) - this has a couple of benefits:

* ensure that calling sites use a documented setting instead of string values
* much simpler isOn(..) logic which can be a high volume call when logging is enabled.

the new isOn method boils down to much simpler logic :


    public static boolean isOn(Opt option) {
        return Opt.ALL.on || option.on;
    }


test coverage also improved.

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

PR Comment: https://git.openjdk.org/jdk/pull/18764#issuecomment-2841928550

From mullan at openjdk.org  Wed Apr 30 13:34:48 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Apr 2025 13:34:48 GMT
Subject: RFR: 8355779: When no "signature_algorithms_cert" extension is
 present we do not apply certificate scope constraints to algorithms in
 "signature_algorithms" extension [v2]
In-Reply-To: 
References: <7ccBNaPfuKqjmuPa4PaCMz4eTslkQZNZSycYSI03C0g=.0833fdd3-ffb2-4a83-bc83-52e4ef76554f@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 22:34:24 GMT, Artur Barashev  wrote:

>> Per TLSv1.3 RFC:
>> 
>> 
>>    If no "signature_algorithms_cert" extension is
>>    present, then the "signature_algorithms" extension also applies to
>>    signatures appearing in certificates.
>> 
>> 
>> When no "signature_algorithms_cert" extension is present in ClientHello we simply copy "signature_algorithms" extension algorithms already filtered with HANDSHAKE_SCOPE to `peerRequestedCertSignSchemes`. Instead we should filter "signature_algorithms" extension algorithms with CERTIFICATE_SCOPE as certain algorithms are allowed to be used in certificate signatures but not in handshake signatures.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take "signature_algorithms_cert" extension as parameter

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24939#pullrequestreview-2807071620

From myankelevich at openjdk.org  Wed Apr 30 14:26:29 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 30 Apr 2025 14:26:29 GMT
Subject: RFR: 8230016: re-visit test
 sun/security/pkcs11/Serialize/SerializeProvider.java [v2]
In-Reply-To: 
References: 
Message-ID: 

> Provider is now added to the Security before the test

Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:

  changed to check for null provider

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24750/files
  - new: https://git.openjdk.org/jdk/pull/24750/files/f0308bb1..f43124ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24750&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24750&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24750/head:pull/24750

PR: https://git.openjdk.org/jdk/pull/24750

From mullan at openjdk.org  Wed Apr 30 14:33:52 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Apr 2025 14:33:52 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: 
References: 
 
Message-ID: <4rcvfxB8dlVQnLs81B4y10i2mIfR4hRnoi-tkddKH24=.75dc808f-5971-4841-abee-eca0b2d34e23@github.com>

On Tue, 29 Apr 2025 21:44:26 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about not using the same HKDF instance.

src/java.base/share/classes/sun/security/ssl/SSLBasicKeyDerivation.java line 31:

> 29: import java.nio.ByteBuffer;
> 30: import java.security.GeneralSecurityException;
> 31: import java.security.spec.AlgorithmParameterSpec;

You can delete this import now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2068790261

From myankelevich at openjdk.org  Wed Apr 30 14:36:02 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 30 Apr 2025 14:36:02 GMT
Subject: RFR: 8230016: re-visit test
 sun/security/pkcs11/Serialize/SerializeProvider.java [v3]
In-Reply-To: 
References: 
Message-ID: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com>

> Provider is now added to the Security before the test

Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:

  removed unneeded check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24750/files
  - new: https://git.openjdk.org/jdk/pull/24750/files/f43124ef..5963bb5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24750&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24750&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24750/head:pull/24750

PR: https://git.openjdk.org/jdk/pull/24750

From myankelevich at openjdk.org  Wed Apr 30 14:36:03 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 30 Apr 2025 14:36:03 GMT
Subject: RFR: 8230016: re-visit test
 sun/security/pkcs11/Serialize/SerializeProvider.java [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 19:02:38 GMT, Sean Mullan  wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed unneeded check
>
> test/jdk/sun/security/pkcs11/Serialize/SerializeProvider.java line 51:
> 
>> 49: 
>> 50:         if (Security.getProvider(p.getName()) != p) {
>> 51:             throw new SkippedException("Provider not installed in Security, skipping");
> 
> Hmm, is this check needed? The provider was added on line 47.

Good point, thanks. It is going to throw an skip exception in PKCS11Test before this code actually. I have removed this in the next commit. In case of the null being passed, the `if (Security.getProvider(p.getName()) != p) {` will throw a null pointer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24750#discussion_r2068791728

From dfuchs at openjdk.org  Wed Apr 30 14:47:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Apr 2025 14:47:58 GMT
Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v3]
In-Reply-To: 
References: 
 
Message-ID: <6rOiDIAFxUmXy6EAQtxDeTbep9DOF5MJIKgi4fGTnQI=.a29afc53-d854-4d0a-9135-b454146b5a3c@github.com>

On Wed, 30 Apr 2025 10:19:54 GMT, Daniel Fuchs  wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 411 commits:
> 
>  - merge latest changes from master branch
>  - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods.
>  - merge latest changes from master branch
>  - http3: add missing 
     separator to Http3DiscoveryMode.ALT_SVC API documentation
>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>  - http3: minor improvement to log message
>  - http3: Artur's review - remove commented out code from test
>  - http3: Artur's review - make methods package private
>  - ... and 401 more: https://git.openjdk.org/jdk/compare/c2485d5f...dfa26044

The PR has been updated with the following API doc changes:

 1. rename HttpRequestOption into HttpOption and make it
    a top level class.
    
 2. move Http3DiscoveryMode as an inner class in HttpOption

 3. improve the paragraph that talks about version selection
    in the HttpClient class-level impl note.

 4. improve the API documentation of the various Builder.version
    and HttpClient.version methods, adding links to the above
    paragraph

The CSR has not been updated yet - but an API documentation of the `java.net.http` module including these changes can be seen [here](https://cr.openjdk.org/~dfuchs/8291976/apidoc.02/api/java.net.http/module-summary.html)

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

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2842231948

From mullan at openjdk.org  Wed Apr 30 15:00:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Apr 2025 15:00:53 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 21:44:26 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about not using the same HKDF instance.

src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 837:

> 835:     private static SecretKey deriveBinderKey(HandshakeContext context,
> 836:             SecretKey psk, SSLSessionImpl session) throws IOException {
> 837:         SecretKey earlySecret = null;

unused variable, can delete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2068860887

From duke at openjdk.org  Wed Apr 30 15:19:10 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 30 Apr 2025 15:19:10 GMT
Subject: RFR: 8353001: Remove leftover Security Manager parsing code in
 sun.security.util.Debug [v3]
In-Reply-To: 
References: 
Message-ID: 

> The private marshal() method in sun.security.util.Debug still contains code to parse "permission=" and "codebase=" options. These sub-options were part of the "access" option which was removed in JDK 24 as part of JEP 486, so this code can be removed.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8353001:Remove leftover Security Manager parsing code in sun.security.util.Debug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24731/files
  - new: https://git.openjdk.org/jdk/pull/24731/files/e411203d..4b28c48c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24731&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24731&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24731.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24731/head:pull/24731

PR: https://git.openjdk.org/jdk/pull/24731

From mullan at openjdk.org  Wed Apr 30 15:20:48 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Apr 2025 15:20:48 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 21:44:26 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about not using the same HKDF instance.

src/java.base/share/classes/sun/security/ssl/Finished.java line 35:

> 33: import java.security.NoSuchAlgorithmException;
> 34: import java.security.ProviderException;
> 35: import java.security.spec.AlgorithmParameterSpec;

Can remove import now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2068873590

From weijun at openjdk.org  Wed Apr 30 15:50:37 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 30 Apr 2025 15:50:37 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding
Message-ID: 

The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IERTF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded.

Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/24969/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347938
  Stats: 2448 lines in 23 files changed: 1741 ins; 539 del; 168 mod
  Patch: https://git.openjdk.org/jdk/pull/24969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24969/head:pull/24969

PR: https://git.openjdk.org/jdk/pull/24969

From mullan at openjdk.org  Wed Apr 30 15:59:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Apr 2025 15:59:55 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 21:44:26 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about not using the same HKDF instance.

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 624:

> 622: 
> 623:             SSLKeyDerivation handshakeKD = ke.createKeyDerivation(shc);
> 624:             SecretKey handshakeSecret = handshakeKD.deriveKey(

It looks like this can be cleared after it is used to derive the key. Similar comment on line 1310.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2068969063

From abarashev at openjdk.org  Wed Apr 30 16:46:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 30 Apr 2025 16:46:48 GMT
Subject: RFR: 8272875: Change the default key manager to PKIX [v3]
In-Reply-To: 
References: 
 
Message-ID: <7LViYz-2xcd3Ix0etPy2I4ZuGwHZ3R6__QWRqMziVCE=.7741a4db-2db6-4fbf-b05e-42c92851340a@github.com>

On Tue, 29 Apr 2025 21:51:00 GMT, Artur Barashev  wrote:

>> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
>> 
>> Compatibility considerations:
>> 
>> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
>> 
>> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
>> 
>> **SUNX509**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>> 
>> **PKIX**
>> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
>> Finished running test 'micro:java.security.SSLHandshake'
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

I have a few points for making the change:

1. On my laptop the handshake time increased from 1ms to 2ms. So while it's a x2 increase it's not going to be noticeable.
2. I'm not 100% sure, but from what I read at least the half of the TLS connections these days are of resume type, and the performance for those is unchanged. Here is a good article from CloudFlare on this topic: https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure. They set session ticket lifetime to 18h.
3. Unlike SunX509, PKIX KeyManager checks local certificate signature algorithms against local algorithm constraints and also against peer-supported algorithms supplied by the peer. So technically we are in violation of TLSv1.3 RFC when using SunX509 because we ignore peer-supported certificate signature schemes. Also we don't respect our own algorithm constraints in `java.security` for local certificates which is the behavior users may expect.

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

PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2842610353

From duke at openjdk.org  Wed Apr 30 16:56:49 2025
From: duke at openjdk.org (duke)
Date: Wed, 30 Apr 2025 16:56:49 GMT
Subject: RFR: 8355779: When no "signature_algorithms_cert" extension is
 present we do not apply certificate scope constraints to algorithms in
 "signature_algorithms" extension [v2]
In-Reply-To: 
References: <7ccBNaPfuKqjmuPa4PaCMz4eTslkQZNZSycYSI03C0g=.0833fdd3-ffb2-4a83-bc83-52e4ef76554f@github.com>
 
Message-ID: 

On Mon, 28 Apr 2025 22:34:24 GMT, Artur Barashev  wrote:

>> Per TLSv1.3 RFC:
>> 
>> 
>>    If no "signature_algorithms_cert" extension is
>>    present, then the "signature_algorithms" extension also applies to
>>    signatures appearing in certificates.
>> 
>> 
>> When no "signature_algorithms_cert" extension is present in ClientHello we simply copy "signature_algorithms" extension algorithms already filtered with HANDSHAKE_SCOPE to `peerRequestedCertSignSchemes`. Instead we should filter "signature_algorithms" extension algorithms with CERTIFICATE_SCOPE as certain algorithms are allowed to be used in certificate signatures but not in handshake signatures.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Take "signature_algorithms_cert" extension as parameter

@artur-oracle 
Your change (at version ae1b30609fce534f7b3e272c96a8cda24853b36c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24939#issuecomment-2842637038

From fferrari at openjdk.org  Wed Apr 30 17:39:51 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 30 Apr 2025 17:39:51 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions
In-Reply-To: 
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 
Message-ID: 

On Tue, 15 Apr 2025 07:46:52 GMT, Alan Bateman  wrote:

>> Hi, this is a proposal to fix 8352728.
>> 
>> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following:
>> 
>> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`.
>> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`.
>> 
>> #### Windows Case
>> 
>> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf:
>> 
>> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`:
>>     * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473")
>>     * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288")
>>     * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop)
>>     * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja...
>
>> File::getCanonicalPath seems to take the best-effort approach (both in Linux and Windows), whereas Path::toRealPath is stricter.
> 
> Path::toRealPath is doing the right thing, and consistent with realpath(2). The issue with File::getCanonicalXXX is that it is specified to return a canonical file even if it doesn't exist, so this is why you see a lot more code to compute a result.
> 
> Maybe the recursive include check them maybe it should use the file key instead.

@AlanBateman are you ok with letting the original c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab reviewers know of this fix and take a look? Or do you think further discussion is needed somewhere else?

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-2842800806

From rhalade at openjdk.org  Wed Apr 30 18:16:52 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 30 Apr 2025 18:16:52 GMT
Subject: Integrated: 8350498: Remove two Camerfirma root CA certificates
In-Reply-To: <2M081CsD83WrCk9PYgmB01CprSr0mr4MB1CP66-847c=.a2b4262a-a020-41c3-9bed-727227739e96@github.com>
References: <2M081CsD83WrCk9PYgmB01CprSr0mr4MB1CP66-847c=.a2b4262a-a020-41c3-9bed-727227739e96@github.com>
Message-ID: <7KNvGaXc0TmC0q5ljoaKdAZbCSgZk8RIoJyoi0RLAhU=.b50277d7-6014-4a70-b224-83c6e7de065d@github.com>

On Tue, 22 Apr 2025 20:27:04 GMT, Rajan Halade  wrote:

> The change is to remove two Camerfirma root certificates which are terminated and no longer in use. These two roots are removed from `cacerts` truststore. Distrust of these roots is also removed as these roots will no longer be trusted by JDK by default.
> 
> The release-note is at [JDK-8355325](https://bugs.openjdk.org/browse/JDK-8355325)

This pull request has now been integrated.

Changeset: 1313349a
Author:    Rajan Halade 
URL:       https://git.openjdk.org/jdk/commit/1313349a2efd42ab84a543dfee11e3547f6ef4a3
Stats:     235 lines in 7 files changed: 2 ins; 211 del; 22 mod

8350498: Remove two Camerfirma root CA certificates

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk/pull/24800

From valeriep at openjdk.org  Wed Apr 30 18:27:51 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 30 Apr 2025 18:27:51 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: 
References: 
 
 
Message-ID: <_BBUu5xQbpTRlP4JBUZ6BBfBkfqkSHoOeAok4s0UV4k=.5c31c18b-a048-4033-b3d3-32e080d767fc@github.com>

On Wed, 30 Apr 2025 15:49:16 GMT, Sean Mullan  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment about not using the same HKDF instance.
>
> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 624:
> 
>> 622: 
>> 623:             SSLKeyDerivation handshakeKD = ke.createKeyDerivation(shc);
>> 624:             SecretKey handshakeSecret = handshakeKD.deriveKey(
> 
> It looks like this can be cleared after it is used to derive the key. Similar comment on line 1310.

Well, I am not sure if clearing `handshakeSecret` is ok - this `handshakeSecret` is passed to `kd` on line 636 and stored internally without cloning. Then `kd` is stored into `shc` which suggests that it may be used later. Clearing it will likely cause problems for subsequent key derivations? Same goes for line 1310. Is there something that I missed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2069231346

From mbalao at openjdk.org  Wed Apr 30 19:20:09 2025
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 30 Apr 2025 19:20:09 GMT
Subject: RFR: 8315487: Security Providers Filter [v22]
In-Reply-To: 
References: 
Message-ID: 

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge JDK-8345139 into JDK-8315487
   
   This way, we are syncing with the dependency of this PR.
   
   Fix two minor conflicts in:
     src/java.base/share/classes/java/security/Provider.java
 - Add implementation notes to public APIs
   
   Update public APIs documentation with implementation notes to reflect
   the effect of the jdk.security.providers.filter Security and System
   properties.
   
   Co-authored-by: Martin Balao Alonso 
   Co-authored-by: Francisco Ferrari Bihurriet 
 - Merge JDK-8345139 into JDK-8315487
   
   This way, we are syncing with the dependency of this PR.
   
   Manually apply src/java.base/share/classes/java/security/Provider.java
   changes, as a lot of context changed after JDK-8345139 updates.
 - Copyright date update.
   
   Co-authored-by: Martin Balao Alonso 
   Co-authored-by: Francisco Ferrari Bihurriet 
 - Add a debug message to inform the Filter property value read.
   
   See more in https://mail.openjdk.org/pipermail/security-dev/2024-October/041800.html
   
   Co-authored-by: Martin Balao Alonso 
   Co-authored-by: Francisco Ferrari Bihurriet 
 - 8315487: Security Providers Filter
   
   Co-authored-by: Francisco Ferrari Bihurriet 
   Co-authored-by: Martin Balao 

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

Changes: https://git.openjdk.org/jdk/pull/15539/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=21
  Stats: 3752 lines in 43 files changed: 3337 ins; 89 del; 326 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

PR: https://git.openjdk.org/jdk/pull/15539

From mullan at openjdk.org  Wed Apr 30 19:21:52 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Apr 2025 19:21:52 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: <_BBUu5xQbpTRlP4JBUZ6BBfBkfqkSHoOeAok4s0UV4k=.5c31c18b-a048-4033-b3d3-32e080d767fc@github.com>
References: 
 
 
 <_BBUu5xQbpTRlP4JBUZ6BBfBkfqkSHoOeAok4s0UV4k=.5c31c18b-a048-4033-b3d3-32e080d767fc@github.com>
Message-ID: 

On Wed, 30 Apr 2025 18:25:35 GMT, Valerie Peng  wrote:

>> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 624:
>> 
>>> 622: 
>>> 623:             SSLKeyDerivation handshakeKD = ke.createKeyDerivation(shc);
>>> 624:             SecretKey handshakeSecret = handshakeKD.deriveKey(
>> 
>> It looks like this can be cleared after it is used to derive the key. Similar comment on line 1310.
>
> Well, I am not sure if clearing `handshakeSecret` is ok - this `handshakeSecret` is passed to `kd` on line 636 and stored internally without cloning. Then `kd` is stored into `shc` which suggests that it may be used later. Clearing it will likely cause problems for subsequent key derivations? Same goes for line 1310. Is there something that I missed?

Ah, yes you are right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2069307086

From mpowers at openjdk.org  Wed Apr 30 20:01:47 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 30 Apr 2025 20:01:47 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Apr 2025 15:43:31 GMT, Weijun Wang  wrote:

> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded.
> 
> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input.

test/jdk/sun/security/provider/named/NamedEdDSA.java line 1:

> 1: /*

I didn't expect an EdDSA test in this PQC bug fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2069359592

From wetmore at openjdk.org  Wed Apr 30 22:40:47 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 30 Apr 2025 22:40:47 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Apr 2025 21:44:26 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about not using the same HKDF instance.

Missing test plan in the PR Description.  (i.e. tier1/tier2/JCK?)

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

PR Comment: https://git.openjdk.org/jdk/pull/24393#issuecomment-2843564278

From lmesnik at openjdk.org  Wed Apr 30 22:45:49 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 30 Apr 2025 22:45:49 GMT
Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v2]
In-Reply-To: 
References: 
 
Message-ID: <8WkNwQi7io3kVJjSYlmqGesD-8AXjE_F0kVzPAQ2KuE=.2ed2b498-18ee-4452-a655-3f5eb747fb16@github.com>

On Wed, 30 Apr 2025 07:48:32 GMT, Ferenc Rakoczi  wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed debugging changes.

Can you please explain in comments how this fix has been tested? I would like to understand which tests are relevant and which flags needs to be set to test this functionality.

src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved.

Seems the file contains only copyright changes.

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

PR Review: https://git.openjdk.org/jdk/pull/24953#pullrequestreview-2808697913
PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2069581842

From wetmore at openjdk.org  Wed Apr 30 22:45:23 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 30 Apr 2025 22:45:23 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material
Message-ID: 

Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.

CSR is underway.

Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

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

Commit messages:
 - 8341346: Add support for exporting TLS Keying Material

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341346
  Stats: 917 lines in 7 files changed: 898 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

PR: https://git.openjdk.org/jdk/pull/24976

From wetmore at openjdk.org  Wed Apr 30 23:38:03 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 30 Apr 2025 23:38:03 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3]
In-Reply-To: 
References: 
Message-ID: 

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  Moved too fast

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/e9745966..a0332f8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=01-02

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

PR: https://git.openjdk.org/jdk/pull/24976

From mpowers at openjdk.org  Wed Apr 30 23:26:45 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 30 Apr 2025 23:26:45 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Apr 2025 15:43:31 GMT, Weijun Wang  wrote:

> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded.
> 
> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input.

src/java.base/share/classes/sun/security/util/KeyUtil.java line 506:

> 504:                 if (seed == null) return null;
> 505:                 skOctets = new byte[seed.length + 2];
> 506:                 skOctets[0] = (byte)0x80;

Is there any value in using the DerValue class to put a name on these constants? I think what you have is easy enough to read.

src/java.base/share/classes/sun/security/util/KeyUtil.java line 511:

> 509:             }
> 510:             case "expandedkey" -> {
> 511:                 if (expanded == null) expanded = expand.apply(pname, seed);

This looks good to me, but the style guideline is

if (expanded == null) {
    expanded = expand.apply(pname, seed);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2069573063
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2069531486

From weijun at openjdk.org  Wed Apr 30 23:33:38 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 30 Apr 2025 23:33:38 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v4]
In-Reply-To: 
References: 
Message-ID: 

> Finalize the KDF API.

Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:

 - add a positive debug log and update exception message
 - enhancing exception messages and debug outputs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/a55c5069..6587d991

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=02-03

  Stats: 161 lines in 2 files changed: 158 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520

PR: https://git.openjdk.org/jdk/pull/24520

From wetmore at openjdk.org  Wed Apr 30 23:32:01 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 30 Apr 2025 23:32:01 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v2]
In-Reply-To: 
References: 
Message-ID: 

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak API to be more KDF like in unextractable case.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/f5a403c4..e9745966

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=00-01

  Stats: 9 lines in 2 files changed: 4 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

PR: https://git.openjdk.org/jdk/pull/24976

From per-ake.minborg at oracle.com  Thu Apr  3 11:20:41 2025
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Thu, 03 Apr 2025 11:20:41 -0000
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr>
References: 
 <1257824626.204034517.1743604437041.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: 

Hi Remi and thank you for the feedback from JChateau (what a wonderful name!).

This is one of the issues we already have on the list for the next round of preview. Now we know more folks are on the same page.

Best, Per
________________________________
From: Remi Forax 
Sent: Wednesday, April 2, 2025 4:33 PM
To: Per Minborg 
Cc: compiler-dev ; core-libs-dev ; hotspot-dev ; security-dev 
Subject: Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview)

Hi Per,
last week, at JChateau, we had a one hour session about stable values, I've build the JDK with this PR so we can discuss about it.

To present the API, i start from the double check locking, rewriting it to use the StableValue API.

The main remark was that methods like orElseSet() or isSet() are hard to used correctly.

In my opinion, the current API is a mix of a high level API and a low-level API but it's too easy to misuse the low-level API.


high level:
- methods supplier(), list() and map()
  Those are easy to use

low level:
- methods: of, of(value), orElseSet, setOrThrow(), etc
  Those are hard to use properly.

I think, not necessary in this PR, that the current API should be separated into two different classes, one in java.lang with the high level API (the static methods other than Of() and one in java.util.concurrent with the low level API where you have to know what you are doing (like with any classes of java.util.concurrent).

regards,
R?mi

----- Original Message -----
> From: "Per Minborg" 
> To: "compiler-dev" , "core-libs-dev" , "hotspot-dev"
> , "security-dev" 
> Sent: Thursday, March 13, 2025 12:20:10 PM
> Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)

> Implement JEP 502.
>
> The PR passes tier1-tier3 tests.
>
> -------------
>
> Commit messages:
> - Use acquire semantics for reading rather than volatile semantics
> - Add missing null check
> - Simplify handling of sentinel, wrap, and unwrap
> - Fix JavaDoc issues
> - Fix members in StableEnumFunction
> - Address some comments in the PR
> - Merge branch 'master' into implement-jep502
> - Revert change
> - Fix copyright issues
> - Update JEP number
> - ... and 231 more: https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6
>
> Changes: https://git.openjdk.org/jdk/pull/23972/files
>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8351565
>  Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod
>  Patch: https://git.openjdk.org/jdk/pull/23972.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972
>
> PR: https://git.openjdk.org/jdk/pull/23972
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From a_jiva at apple.com  Thu Apr 17 00:32:47 2025
From: a_jiva at apple.com (Azeem Jiva)
Date: Thu, 17 Apr 2025 00:32:47 -0000
Subject: Quantum Resistant hybrid key exchange
Message-ID: 

Hi,
 Is there a list of future quantum resistant hybrid key changes under development for future OpenJDK releases?  Thanks.