From aph at openjdk.org Mon Feb 3 10:58:48 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 3 Feb 2025 10:58:48 GMT Subject: RFR: 8349106: Change ChaCha20 intrinsic to use quarter-round parallel implementation on aarch64 In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 16:48:09 GMT, Jamil Nimeh wrote: > This enhancement makes a change to the ChaCha20 block function intrinsic on aarch64, moving away from the block parallel implementation and to the quarter-round parallel implementation that was done on x86_64. Assembly language profiling yielded an 11% improvement in throughput. When put together as an intrinsic and hooked into the JCE ChaCha20 cipher, the gains are more modest, somewhere in the 2-4% range depending on job size, but still an improvement. This looks very nice, and I'm tempted to just approve it as it is. My only concern is that the algorithm changes aren't really explained, but I guess what you have done here is the _128-Bit Vectorization_ in `https://eprint.iacr.org/2013/759.pdf`. Is that right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23397#issuecomment-2630610061 From duke at openjdk.org Mon Feb 3 15:49:01 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 3 Feb 2025 15:49:01 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v3] In-Reply-To: References: Message-ID: > By using the aarch64 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 with a new target base due to a merge or a rebase. The pull request now contains four commits: - merging master - Use SHA3Parallel for matrix generation - fixing whitespace errors - 8348561: Add aarch64 intrinsics for ML-DSA ------------- Changes: https://git.openjdk.org/jdk/pull/23300/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=02 Stats: 2133 lines in 19 files changed: 2045 ins; 11 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/23300.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23300/head:pull/23300 PR: https://git.openjdk.org/jdk/pull/23300 From weijun at openjdk.org Mon Feb 3 15:57:30 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 3 Feb 2025 15:57:30 GMT Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v6] In-Reply-To: References: Message-ID: <_g3SHHWbXyok5NcQgjYS89eb1lGWxDkl9nD5x75L830=.2948856b-7fce-411d-aebd-60e02e064dd4@github.com> > 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. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: change name from "alt" to "transformed"; supporting jdk24 encoding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23376/files - new: https://git.openjdk.org/jdk/pull/23376/files/77deb7ce..d4e19614 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23376&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23376&range=04-05 Stats: 419 lines in 14 files changed: 198 ins; 157 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/23376.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23376/head:pull/23376 PR: https://git.openjdk.org/jdk/pull/23376 From weijun at openjdk.org Mon Feb 3 16:04:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 3 Feb 2025 16:04:52 GMT Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v6] In-Reply-To: <_g3SHHWbXyok5NcQgjYS89eb1lGWxDkl9nD5x75L830=.2948856b-7fce-411d-aebd-60e02e064dd4@github.com> References: <_g3SHHWbXyok5NcQgjYS89eb1lGWxDkl9nD5x75L830=.2948856b-7fce-411d-aebd-60e02e064dd4@github.com> Message-ID: On Mon, 3 Feb 2025 15:57:30 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. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > change name from "alt" to "transformed"; supporting jdk24 encoding A new commit has been pushed. The most significant change is renaming `alt` to `transformed`, along with extensive comment updates and some minor behavior modifications: 1. Added support for JDK 24 private key encodings, i.e. transformed format wrapped in an OCTET STRING. 2. Fixed a bug in `NamedPKCS8Key::getTransformed`, which no longer compares lengths. 3. Fixed a bug in `ML_DSA_Impls::seedToTransformed`, ensuring `sk` is cleaned up in a `finally` block. 4. `NamedKeyFactory::implTransform` now has a default implementation, assuming encoding and computations use the same format. While this is not the case for ML-KEM and ML-DSA, it serves as a reasonable default. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23376#issuecomment-2631418553 From duke at openjdk.org Mon Feb 3 16:15:32 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 3 Feb 2025 16:15:32 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v4] In-Reply-To: References: Message-ID: > By using the aarch64 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: removed debugging code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23300/files - new: https://git.openjdk.org/jdk/pull/23300/files/5630fd14..9f7c4a23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=02-03 Stats: 25 lines in 3 files changed: 0 ins; 25 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23300.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23300/head:pull/23300 PR: https://git.openjdk.org/jdk/pull/23300 From jnimeh at openjdk.org Mon Feb 3 16:16:46 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 3 Feb 2025 16:16:46 GMT Subject: RFR: 8349106: Change ChaCha20 intrinsic to use quarter-round parallel implementation on aarch64 In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 10:56:28 GMT, Andrew Haley wrote: >> This enhancement makes a change to the ChaCha20 block function intrinsic on aarch64, moving away from the block parallel implementation and to the quarter-round parallel implementation that was done on x86_64. Assembly language profiling yielded an 11% improvement in throughput. When put together as an intrinsic and hooked into the JCE ChaCha20 cipher, the gains are more modest, somewhere in the 2-4% range depending on job size, but still an improvement. > > This looks very nice, and I'm tempted to just approve it as it is. My only concern is that the algorithm changes aren't really explained, but I guess what you have done here is the _128-Bit Vectorization_ in `https://eprint.iacr.org/2013/759.pdf`. Is that right? Hi @theRealAph, thanks for taking a look at the changes. Actually, I hadn't read that paper believe it or not, though it certainly looks like what I'm doing. When I was prototyping this a few years ago in x86_64 assembly it just occurred to me that directly loading the state into 4 consecutive vectors had everything align in the columnar organization such that we could do the double-round right off the bat (which must have been intentional in the design of the cipher). Then all we had to do was do the lane rotation leftward 1/2/3 for the second/third/fourth vectors and do the quarter rounds again. And longer vectors for AVX2, AVX-512, or using more vectors like on aarch64 allowed me to do more blocks at one time. It was long enough ago that I don't recall exactly why, but when I did the quarter-round and block parallel versions in aarch64 assembly initially, it seemed like they were pretty comparable in speed. At the time, I interpreted that to mean that the gains in block-parallel by not needing to do lane rotations was offset by having to gather/scatter each 32-bit state value from different vectors at 64-byte offsets, and it more or less balanced out. When I went back to look at these two approaches, I think I was able to tweak things on the quarter-round parallel version to make loads and stores a little friendlier (one ld1 and a bunch of register-to-register movs vs. 4 ld4r ops, and 4 st1 ops vs. 16 st4 ops). In terms of explaining the algorithm changes, I could add some comment text to the header of the stub function that better explains the general idea behind what is being done. It would certainly help anyone maintaining it down the line (myself included). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23397#issuecomment-2631451246 From mullan at openjdk.org Mon Feb 3 18:11:56 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 3 Feb 2025 18:11:56 GMT Subject: RFR: 8347428: Avoid using secret-key in specifications In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 20:08:31 GMT, Ben Perez wrote: > There are quite some places in API specifications that use the term "secret-key". This is not a formal term. Consider replacing them with "secret key". Some of the copyright dates need to be updated. Also, I noticed another instance in `src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java`: `* Secret-key factories in putEntries()` ------------- PR Comment: https://git.openjdk.org/jdk/pull/23342#issuecomment-2631714447 From duke at openjdk.org Mon Feb 3 18:14:54 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 3 Feb 2025 18:14:54 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v2] In-Reply-To: <7UgNYEuTu6rj7queOgM9xIy-6kQMdACrZiDLtlniMYw=.dff6f18b-1236-43b1-8280-2bce9160f32a@github.com> References: <7UgNYEuTu6rj7queOgM9xIy-6kQMdACrZiDLtlniMYw=.dff6f18b-1236-43b1-8280-2bce9160f32a@github.com> Message-ID: On Thu, 30 Jan 2025 16:23:56 GMT, Andrew Dinn wrote: > @ferakocz I'm afraid you lucked out on getting your change committed before my reorganization of the stub generation code. If you are unsure of how to do the merge so your new stub is declared and generated following the new model (see the doc comments in stubDeclarations.hpp for details) let me know and I'll be happy to help you sort it out. @adinn I think I managed to figure it out. Please take a look at the PR and let me know if I should have done anything differently. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2631720583 From duke at openjdk.org Mon Feb 3 19:12:30 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Mon, 3 Feb 2025 19:12:30 GMT Subject: RFR: 8349151: Refactor test/java/security//cert/CertificateFactory/slowstream.sh to java test [v2] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23394/files - new: https://git.openjdk.org/jdk/pull/23394/files/1fc88f2f..396844a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23394&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23394&range=00-01 Stats: 19 lines in 1 file changed: 11 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23394/head:pull/23394 PR: https://git.openjdk.org/jdk/pull/23394 From duke at openjdk.org Mon Feb 3 19:12:30 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Mon, 3 Feb 2025 19:12:30 GMT Subject: RFR: 8349151: Refactor test/java/security//cert/CertificateFactory/slowstream.sh to java test [v2] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 18:01:28 GMT, Matthew Donovan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanup > > test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 52: > >> 50: while (true) { >> 51: int len = fin.read(buffer); >> 52: if (len < 0) break; > > it's clearer to do > > `if (len < 0) { > break; > }` > > it also matches the style at line 83 Done in the next commit > test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 60: > >> 58: } catch (final Exception e) { >> 59: failed.set(true); >> 60: exception.set(e); > > If you're setting this field in both reader and writer threads, is there a chance that one overwrites the other? > > Thinking about debugging this if the test fails... in the event of a error, should each thread print its stack trace and then set failed to true. Then at the end of the test, if failed is true, throw a RuntimeException with a generic message that something failed? Done in the next commit > test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 68: > >> 66: final var factory = CertificateFactory.getInstance("X.509"); >> 67: if (factory.generateCertificates(inputStream).size() != 5) { >> 68: throw new Exception("Not all certs read"); > > To aid debugging a failure, it might help to include the number of certificates that were read. Done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r1939889619 PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r1939889552 PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r1939889676 From bperez at openjdk.org Mon Feb 3 19:18:23 2025 From: bperez at openjdk.org (Ben Perez) Date: Mon, 3 Feb 2025 19:18:23 GMT Subject: RFR: 8347428: Avoid using secret-key in specifications [v2] In-Reply-To: References: Message-ID: > There are quite some places in API specifications that use the term "secret-key". This is not a formal term. Consider replacing them with "secret key". Ben Perez has updated the pull request incrementally with one additional commit since the last revision: fixed copyright dates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23342/files - new: https://git.openjdk.org/jdk/pull/23342/files/df074e30..fba8575b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23342&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23342&range=00-01 Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23342/head:pull/23342 PR: https://git.openjdk.org/jdk/pull/23342 From bperez at openjdk.org Mon Feb 3 19:26:27 2025 From: bperez at openjdk.org (Ben Perez) Date: Mon, 3 Feb 2025 19:26:27 GMT Subject: RFR: 8261513: Various BasicConstraintsExtension issues [v3] In-Reply-To: <_-E8euMT24qWQQJBRbNusSF_tHiDCiYdWzqlVccO2BA=.d5f20c54-1178-489f-9eac-75bbbc381791@github.com> References: <_-E8euMT24qWQQJBRbNusSF_tHiDCiYdWzqlVccO2BA=.d5f20c54-1178-489f-9eac-75bbbc381791@github.com> Message-ID: > 8261513: Various BasicConstraintsExtension issues Ben Perez 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 JDK-8261513 - Added IOException for negative pathLenConstraint - Changed constructor, getPathLen, and toString to return a canonical representation for unconstrained pathLens ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20224/files - new: https://git.openjdk.org/jdk/pull/20224/files/c04afb03..64398d5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20224&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20224&range=01-02 Stats: 1074565 lines in 14088 files changed: 660798 ins; 324690 del; 89077 mod Patch: https://git.openjdk.org/jdk/pull/20224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20224/head:pull/20224 PR: https://git.openjdk.org/jdk/pull/20224 From aph at openjdk.org Mon Feb 3 19:57:42 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 3 Feb 2025 19:57:42 GMT Subject: RFR: 8349106: Change ChaCha20 intrinsic to use quarter-round parallel implementation on aarch64 In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 16:14:23 GMT, Jamil Nimeh wrote: > In terms of explaining the algorithm changes, I could add some comment text to the header of the stub function that better explains the general idea behind what is being done. It would certainly help anyone maintaining it down the line (myself included). Your call if you want to describe it yourself, or quote the paper, or both. But please do one! The paper is rather readable. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23397#issuecomment-2631929964 From mullan at openjdk.org Mon Feb 3 20:11:16 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 3 Feb 2025 20:11:16 GMT Subject: RFR: 8347428: Avoid using secret-key in specifications [v2] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 19:18:23 GMT, Ben Perez wrote: >> There are quite some places in API specifications that use the term "secret-key". This is not a formal term. Consider replacing them with "secret key". > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright dates Please add a `noreg-doc` label to the JBS issue. All fixes w/o tests need an appropriate `noreg` or `nounit` label. See https://openjdk.org/guide/#noreg. Otherwise, looks good. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23342#pullrequestreview-2590893635 From ascarpino at openjdk.org Mon Feb 3 21:31:04 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 3 Feb 2025 21:31:04 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing Message-ID: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> I need a review of this change that adds new timing controls for the initial server setup. On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect. Additional debugging is added to help identify if there are other timing issues. Thanks Tony ------------- Commit messages: - redo import change - undo import change - fix - fix Changes: https://git.openjdk.org/jdk/pull/23407/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23407&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348309 Stats: 66 lines in 5 files changed: 19 ins; 10 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/23407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23407/head:pull/23407 PR: https://git.openjdk.org/jdk/pull/23407 From bperez at openjdk.org Mon Feb 3 22:17:13 2025 From: bperez at openjdk.org (Ben Perez) Date: Mon, 3 Feb 2025 22:17:13 GMT Subject: Integrated: 8347428: Avoid using secret-key in specifications In-Reply-To: References: Message-ID: <2I7ope9lJjm_twHjge34LaULl3nMmECP3VwcG6G0vd8=.dfa9601b-38b5-4e0d-b304-02df06bfbcaa@github.com> On Tue, 28 Jan 2025 20:08:31 GMT, Ben Perez wrote: > There are quite some places in API specifications that use the term "secret-key". This is not a formal term. Consider replacing them with "secret key". This pull request has now been integrated. Changeset: 43979fb1 Author: Ben Perez URL: https://git.openjdk.org/jdk/commit/43979fb1be424157b33268db078d345b4da29119 Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod 8347428: Avoid using secret-key in specifications Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/23342 From sean.mullan at oracle.com Mon Feb 3 23:03:26 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 3 Feb 2025 18:03:26 -0500 Subject: Linux support for java.security.jgss "nativeccache" functionality In-Reply-To: References: Message-ID: <6f0f0e19-5305-4d2f-99ab-9199caaf8c6e@oracle.com> Hi Nick, This proposal does sound like it would be useful, so I think we can start some more discussions about it. Once we go a bit further in the discussions and we decide it is worthwhile, we can open a JBS issue for tracking purposes. For starters, can you confirm that your company is "D. E. Shaw & Co., LP"? --Sean On 1/31/25 12:04 PM, Hall, Nick wrote: > Hi, > > The current OpenJDK code has ?native? ccache support for both Windows/ > Mac, allowing native Kerberos credential acquisition on those platforms > via the usual system library calls rather than the pure Java code.? It > does not support Linux, meaning that only file based ccaches are > supported on that platform.? I couldn?t find any other similar bug > reports/fixes/submissions, so have developed a patch that I?d like to > contribute to improve this support (for full disclosure, this is a > corporate submission approved by my employer, and the OCA has been > appropriately signed; this is my first time contributing to the OpenJDK). > > The motivation for doing this is that the Linux Kerberos / GSS-API > system libraries support more than just file-based Kerberos credential > caches ? in particular, we?re interested in supporting KCM, which is a > standard protocol for acquiring credentials via a service based cache ? > there are two existing implementations in Heimdal Kerberos and the > RedHat SSSD.? As it stands now, supporting KCM for Java processes means > running them inside a ?kstart? shell which copies a KCM cache to a file > ccache for the process to use initially.? This is an unergonomic > approach that we would like to avoid, as it?s a source of errors in our > environment. > > The patch generalizes the Mac support to include Linux ? the C code (ref > src/java.security.jgss/macosx/native/libosxkrb5/nativeccache.c) required > here is identical to the Mac version other than the header files (and > includes a bug fix to avoid a segfault caused by a null pointer deref, > which I suspect is a dormant bug on MacOSX too).? The only other > required changes are in the Java code which loads the relevant libraries > and calls them, in both cases these are just changes to an existing > conditional. > > I?d be interested in feedback, and had some questions about how to > approach the shared nature of the code between MacOSX and Linux based on > the options I?ve tried here: > > * Option 1: duplicate the code, fix the headers and build a separate > Linux shared object.? This has the disadvantage of a lot of > duplicated code, but keeps each platform?s libraries separate/distinct. > * Option 2: build a common shared object on both MacOSX and Linux for > the nativeccache functionality, using pre-processor directives to > select the correct set of header files for each platform.? This has > the advantage of a smaller patch (lines of code), but introduces a > (no-op) change on MacOSX as a result.? MacOSX has one additional > source file (SCDynamicStoreConfig) compiled into the library that > Linux does not have. > > The draft code for option 2 can be found at https://github.com/nrhall/ > jdk/commit/7b57a48afff77ef80dbb6cd947bd0d0581c439c1 nrhall/jdk/commit/7b57a48afff77ef80dbb6cd947bd0d0581c439c1> (note that > the GH Actions jobs currently fail on Linux because the runner needs to > have at least libkrb5-dev installed, and that changes to autoconf/ > dependencies will be needed to ensure these libs/headers are installed > at compile time at least ? with some careful handling at library load > time to handle the error if not). > > If there?s interest in pursuing this, I?d be happy to raise a PR? - > please let me know if there are any questions! > > Thanks, > > Nick > From jnimeh at openjdk.org Mon Feb 3 23:56:18 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 3 Feb 2025 23:56:18 GMT Subject: RFR: 8349106: Change ChaCha20 intrinsic to use quarter-round parallel implementation on aarch64 [v2] In-Reply-To: References: Message-ID: > This enhancement makes a change to the ChaCha20 block function intrinsic on aarch64, moving away from the block parallel implementation and to the quarter-round parallel implementation that was done on x86_64. Assembly language profiling yielded an 11% improvement in throughput. When put together as an intrinsic and hooked into the JCE ChaCha20 cipher, the gains are more modest, somewhere in the 2-4% range depending on job size, but still an improvement. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Add explanatory comment and reference for quarter round intrinsic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23397/files - new: https://git.openjdk.org/jdk/pull/23397/files/41817c77..6ba0770b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23397&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23397&range=00-01 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23397/head:pull/23397 PR: https://git.openjdk.org/jdk/pull/23397 From Nick.Hall at deshaw.com Tue Feb 4 00:04:50 2025 From: Nick.Hall at deshaw.com (Hall, Nick) Date: Tue, 4 Feb 2025 00:04:50 +0000 Subject: Linux support for java.security.jgss "nativeccache" functionality In-Reply-To: <6f0f0e19-5305-4d2f-99ab-9199caaf8c6e@oracle.com> References: <6f0f0e19-5305-4d2f-99ab-9199caaf8c6e@oracle.com> Message-ID: Hi Sean, Thanks for your response - I confirm that my company is D. E. Shaw & Co. Let me know if I can provide any further information! Nick ________________________________ From: Sean Mullan Sent: Monday, February 3, 2025 11:03 pm To: Hall, Nick ; security-dev at openjdk.org Subject: Re: Linux support for java.security.jgss "nativeccache" functionality This message was sent by an external party. Hi Nick, This proposal does sound like it would be useful, so I think we can start some more discussions about it. Once we go a bit further in the discussions and we decide it is worthwhile, we can open a JBS issue for tracking purposes. For starters, can you confirm that your company is "D. E. Shaw & Co., LP"? --Sean On 1/31/25 12:04 PM, Hall, Nick wrote: > Hi, > > The current OpenJDK code has ?native? ccache support for both Windows/ > Mac, allowing native Kerberos credential acquisition on those platforms > via the usual system library calls rather than the pure Java code. It > does not support Linux, meaning that only file based ccaches are > supported on that platform. I couldn?t find any other similar bug > reports/fixes/submissions, so have developed a patch that I?d like to > contribute to improve this support (for full disclosure, this is a > corporate submission approved by my employer, and the OCA has been > appropriately signed; this is my first time contributing to the OpenJDK). > > The motivation for doing this is that the Linux Kerberos / GSS-API > system libraries support more than just file-based Kerberos credential > caches ? in particular, we?re interested in supporting KCM, which is a > standard protocol for acquiring credentials via a service based cache ? > there are two existing implementations in Heimdal Kerberos and the > RedHat SSSD. As it stands now, supporting KCM for Java processes means > running them inside a ?kstart? shell which copies a KCM cache to a file > ccache for the process to use initially. This is an unergonomic > approach that we would like to avoid, as it?s a source of errors in our > environment. > > The patch generalizes the Mac support to include Linux ? the C code (ref > src/java.security.jgss/macosx/native/libosxkrb5/nativeccache.c) required > here is identical to the Mac version other than the header files (and > includes a bug fix to avoid a segfault caused by a null pointer deref, > which I suspect is a dormant bug on MacOSX too). The only other > required changes are in the Java code which loads the relevant libraries > and calls them, in both cases these are just changes to an existing > conditional. > > I?d be interested in feedback, and had some questions about how to > approach the shared nature of the code between MacOSX and Linux based on > the options I?ve tried here: > > * Option 1: duplicate the code, fix the headers and build a separate > Linux shared object. This has the disadvantage of a lot of > duplicated code, but keeps each platform?s libraries separate/distinct. > * Option 2: build a common shared object on both MacOSX and Linux for > the nativeccache functionality, using pre-processor directives to > select the correct set of header files for each platform. This has > the advantage of a smaller patch (lines of code), but introduces a > (no-op) change on MacOSX as a result. MacOSX has one additional > source file (SCDynamicStoreConfig) compiled into the library that > Linux does not have. > > The draft code for option 2 can be found at https://github.com/nrhall/ > jdk/commit/7b57a48afff77ef80dbb6cd947bd0d0581c439c1 nrhall/jdk/commit/7b57a48afff77ef80dbb6cd947bd0d0581c439c1> (note that > the GH Actions jobs currently fail on Linux because the runner needs to > have at least libkrb5-dev installed, and that changes to autoconf/ > dependencies will be needed to ensure these libs/headers are installed > at compile time at least ? with some careful handling at library load > time to handle the error if not). > > If there?s interest in pursuing this, I?d be happy to raise a PR - > please let me know if there are any questions! > > Thanks, > > Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at openjdk.org Tue Feb 4 09:23:12 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 4 Feb 2025 09:23:12 GMT Subject: RFR: 8349106: Change ChaCha20 intrinsic to use quarter-round parallel implementation on aarch64 [v2] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 23:56:18 GMT, Jamil Nimeh wrote: >> This enhancement makes a change to the ChaCha20 block function intrinsic on aarch64, moving away from the block parallel implementation and to the quarter-round parallel implementation that was done on x86_64. Assembly language profiling yielded an 11% improvement in throughput. When put together as an intrinsic and hooked into the JCE ChaCha20 cipher, the gains are more modest, somewhere in the 2-4% range depending on job size, but still an improvement. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Add explanatory comment and reference for quarter round intrinsic Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23397#pullrequestreview-2592206831 From adinn at openjdk.org Tue Feb 4 11:48:09 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 4 Feb 2025 11:48:09 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v2] In-Reply-To: References: <7UgNYEuTu6rj7queOgM9xIy-6kQMdACrZiDLtlniMYw=.dff6f18b-1236-43b1-8280-2bce9160f32a@github.com> Message-ID: On Mon, 3 Feb 2025 18:11:51 GMT, Ferenc Rakoczi wrote: >> @ferakocz I'm afraid you lucked out on getting your change committed before my reorganization of the stub generation code. If you are unsure of how to do the merge so your new stub is declared and generated following the new model (see the doc comments in stubDeclarations.hpp for details) let me know and I'll be happy to help you sort it out. > >> @ferakocz I'm afraid you lucked out on getting your change committed before my reorganization of the stub generation code. If you are unsure of how to do the merge so your new stub is declared and generated following the new model (see the doc comments in stubDeclarations.hpp for details) let me know and I'll be happy to help you sort it out. > > @adinn I think I managed to figure it out. Please take a look at the PR and let me know if I should have done anything differently. @ferakocz Yes, the stub declaration part of it looks to be correct. The rest of the patch will need at least two reviewers (@theRealAph? @martinuy? @franferrax) and may take some time to review, given that they will probably need to read up on the maths and algorithms. As an aid for reviewers and maintainers it would be good to insert a comment into the generator file linking the implementations to the relevant maths and algorithm. I found the FIPS-204 spec and the CRYSTALS-Dilithium Algorithm Speci?cations and Supporting Documentation paper, Shi Bai, L?o Ducas et al, 2021 - are they the best ones to look at? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2633666753 From duke at openjdk.org Tue Feb 4 14:12:23 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Tue, 4 Feb 2025 14:12:23 GMT Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java Message-ID: Refactor the following to run fully in java: test/java/security//Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh test/java/security//Security/ClassLoaderDeadlock/Deadlock.sh ------------- Commit messages: - JDK-8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java Changes: https://git.openjdk.org/jdk/pull/23440/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23440&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349348 Stats: 191 lines in 4 files changed: 14 ins; 172 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23440.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23440/head:pull/23440 PR: https://git.openjdk.org/jdk/pull/23440 From jnimeh at openjdk.org Tue Feb 4 16:31:17 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 4 Feb 2025 16:31:17 GMT Subject: Integrated: 8349106: Change ChaCha20 intrinsic to use quarter-round parallel implementation on aarch64 In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 16:48:09 GMT, Jamil Nimeh wrote: > This enhancement makes a change to the ChaCha20 block function intrinsic on aarch64, moving away from the block parallel implementation and to the quarter-round parallel implementation that was done on x86_64. Assembly language profiling yielded an 11% improvement in throughput. When put together as an intrinsic and hooked into the JCE ChaCha20 cipher, the gains are more modest, somewhere in the 2-4% range depending on job size, but still an improvement. This pull request has now been integrated. Changeset: ee4caa41 Author: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/ee4caa4180e76911ee75148583c2923f847f8605 Stats: 166 lines in 1 file changed: 71 ins; 1 del; 94 mod 8349106: Change ChaCha20 intrinsic to use quarter-round parallel implementation on aarch64 Reviewed-by: aph ------------- PR: https://git.openjdk.org/jdk/pull/23397 From dfuchs at openjdk.org Tue Feb 4 17:21:12 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 4 Feb 2025 17:21:12 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 01:45:47 GMT, Bradford Wetmore wrote: > Update and clarify the sample code. > > Docs only, no additional testing other than verifying javadoc is correctly output. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 668: > 666: * String encodedHukUnI = > 667: * new String(bytes, StandardCharsets.ISO_8859_1); > 668: * Maybe a better comment here would be: * // Preserve bytes by using ISO_8859_1 encoding because we're not converting anything into anything. As far as I understand what you are trying to do is to shoe-horn a byte array into a string, so that you can retrieve the original array using `String.getBytes(StandardCharsets.ISO_8859_1)`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1941585321 From duke at openjdk.org Tue Feb 4 19:00:33 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 4 Feb 2025 19:00:33 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v2] In-Reply-To: References: <7UgNYEuTu6rj7queOgM9xIy-6kQMdACrZiDLtlniMYw=.dff6f18b-1236-43b1-8280-2bce9160f32a@github.com> Message-ID: On Mon, 3 Feb 2025 18:11:51 GMT, Ferenc Rakoczi wrote: >> @ferakocz I'm afraid you lucked out on getting your change committed before my reorganization of the stub generation code. If you are unsure of how to do the merge so your new stub is declared and generated following the new model (see the doc comments in stubDeclarations.hpp for details) let me know and I'll be happy to help you sort it out. > >> @ferakocz I'm afraid you lucked out on getting your change committed before my reorganization of the stub generation code. If you are unsure of how to do the merge so your new stub is declared and generated following the new model (see the doc comments in stubDeclarations.hpp for details) let me know and I'll be happy to help you sort it out. > > @adinn I think I managed to figure it out. Please take a look at the PR and let me know if I should have done anything differently. > @ferakocz Yes, the stub declaration part of it looks to be correct. > > The rest of the patch will need at least two reviewers (@theRealAph? @martinuy? @franferrax) and may take some time to review, given that they will probably need to read up on the maths and algorithms. As an aid for reviewers and maintainers it would be good to insert a comment into the generator file linking the implementations to the relevant maths and algorithm. I found the FIPS-204 spec and the CRYSTALS-Dilithium Algorithm Speci?cations and Supporting Documentation paper, Shi Bai, L?o Ducas et al, 2021 - are they the best ones to look at? The Java implementation of ML-DSA is based on the FIPS-204 standard and the intrinsicss' implementations are based on the corresponding Java methods, except that the montMul() calls in them are inlined. The rest of the transformation from Java code to intrinsic code is pretty straightforward, so a reviewer need not necessarily understand the whole mathematics of the ML-DSA algorithms, just that the Java and the corresponding intrinsic code do the same thing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2634810518 From hchao at openjdk.org Tue Feb 4 19:02:12 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Tue, 4 Feb 2025 19:02:12 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing In-Reply-To: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> Message-ID: <6MlNFjSs6MCfONaOAitq0S6gGcLeG00vtihtnDQoagc=.75a30d86-a77c-4d2d-a462-c06ecab92bab@github.com> On Sat, 1 Feb 2025 04:20:36 GMT, Anthony Scarpino wrote: > I need a review of this change that adds new timing controls for the initial server setup. On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect. Additional debugging is added to help identify if there are other timing issues. > > Thanks > > Tony Changes look good. One small comment in TLSBase class. Marked as reviewed by hchao (Committer). test/jdk/javax/net/ssl/templates/TLSBase.java line 152: > 150: List exceptionList = new ArrayList<>(); > 151: ExecutorService threadPool = Executors.newFixedThreadPool(1, > 152: r -> Executors.defaultThreadFactory().newThread(r)); Do you think we may simplify this to `ExecutorService threadPool = Executors.newFixedThreadPool(1);` while this line is being changed? ------------- PR Review: https://git.openjdk.org/jdk/pull/23407#pullrequestreview-2593778755 PR Review: https://git.openjdk.org/jdk/pull/23407#pullrequestreview-2593786603 PR Review Comment: https://git.openjdk.org/jdk/pull/23407#discussion_r1941737445 From wetmore at openjdk.org Tue Feb 4 19:22:14 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 4 Feb 2025 19:22:14 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v2] In-Reply-To: References: Message-ID: <9SCBuCbfBA1PG6B2QDClO4ck9_ApSzj6TWSTuan46DU=.b3bbb9d7-fc54-4519-af8d-c23ca64c8a95@github.com> > Update and clarify the sample code. > > Docs only, no additional testing other than verifying javadoc is correctly output. Bradford Wetmore 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8349121 - 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23379/files - new: https://git.openjdk.org/jdk/pull/23379/files/ac7a6cff..e5da45c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23379&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23379&range=00-01 Stats: 8485 lines in 159 files changed: 1806 ins; 4505 del; 2174 mod Patch: https://git.openjdk.org/jdk/pull/23379.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23379/head:pull/23379 PR: https://git.openjdk.org/jdk/pull/23379 From wetmore at openjdk.org Tue Feb 4 19:42:24 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 4 Feb 2025 19:42:24 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: > Update and clarify the sample code. > > Docs only, no additional testing other than verifying javadoc is correctly output. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Codereview Comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23379/files - new: https://git.openjdk.org/jdk/pull/23379/files/e5da45c1..61345a63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23379&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23379&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23379.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23379/head:pull/23379 PR: https://git.openjdk.org/jdk/pull/23379 From wetmore at openjdk.org Tue Feb 4 19:42:25 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 4 Feb 2025 19:42:25 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 17:18:09 GMT, Daniel Fuchs wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Codereview Comments > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 668: > >> 666: * String encodedHukUnI = >> 667: * new String(bytes, StandardCharsets.ISO_8859_1); >> 668: * > > Maybe a better comment here would be: > > * // Preserve bytes by using ISO_8859_1 encoding > > because we're not converting anything into anything. > > As far as I understand what you are trying to do is to shoe-horn a byte array into a string, so that you can retrieve the original array using `String.getBytes(StandardCharsets.ISO_8859_1)`? I had a similar thought over the weekend. Updated the comment to `Preserve network byte order by using ISO_8859_1 encoding`. > As far as I understand what you are trying to do... Yes. The API was String[] (implemented with 7-bit ASCII), but it was pointed out that we didn't have any way to send some of the TLS GREASE ([RFC 8701](https://www.rfc-editor.org/rfc/rfc8701.html)) values or use extended ASCII (8-bit) characters. (International Charsets was a bonus, but likely aren't used for ALPN.) This was a reasonable workaround. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1941787825 From mullan at openjdk.org Tue Feb 4 20:28:17 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 4 Feb 2025 20:28:17 GMT Subject: RFR: 8184352: Remove Sun provider information from KeyPairGenerator javadoc [v3] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 20:47:01 GMT, Ben Perez wrote: >> Removed algorithm-specific information from `KeyPairGenerator` class description and instead linked out to the Sun Provider documentation > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > fixed link Need copyright update. ------------- PR Review: https://git.openjdk.org/jdk/pull/23280#pullrequestreview-2593952753 From bperez at openjdk.org Tue Feb 4 20:37:52 2025 From: bperez at openjdk.org (Ben Perez) Date: Tue, 4 Feb 2025 20:37:52 GMT Subject: RFR: 8184352: Remove Sun provider information from KeyPairGenerator javadoc [v4] In-Reply-To: References: Message-ID: > Removed algorithm-specific information from `KeyPairGenerator` class description and instead linked out to the Sun Provider documentation Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Update copyright date ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23280/files - new: https://git.openjdk.org/jdk/pull/23280/files/1961d205..b05988d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23280&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23280&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23280/head:pull/23280 PR: https://git.openjdk.org/jdk/pull/23280 From mullan at openjdk.org Tue Feb 4 20:45:10 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 4 Feb 2025 20:45:10 GMT Subject: RFR: 8184352: Remove Sun provider information from KeyPairGenerator javadoc [v4] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 20:37:52 GMT, Ben Perez wrote: >> Removed algorithm-specific information from `KeyPairGenerator` class description and instead linked out to the Sun Provider documentation > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright date Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23280#pullrequestreview-2594020435 From swen at openjdk.org Tue Feb 4 23:10:34 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 4 Feb 2025 23:10:34 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes Message-ID: 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 ------------- Commit messages: - Eliminating nested classes Changes: https://git.openjdk.org/jdk/pull/23411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23411&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349400 Stats: 58 lines in 1 file changed: 10 ins; 33 del; 15 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 bperez at openjdk.org Tue Feb 4 23:16:13 2025 From: bperez at openjdk.org (Ben Perez) Date: Tue, 4 Feb 2025 23:16:13 GMT Subject: Integrated: 8184352: Remove Sun provider information from KeyPairGenerator javadoc In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 20:56:25 GMT, Ben Perez wrote: > Removed algorithm-specific information from `KeyPairGenerator` class description and instead linked out to the Sun Provider documentation This pull request has now been integrated. Changeset: 9d23de58 Author: Ben Perez URL: https://git.openjdk.org/jdk/commit/9d23de58d167ff7d23ee1b8da675ec1b26b885f9 Stats: 10 lines in 1 file changed: 0 ins; 7 del; 3 mod 8184352: Remove Sun provider information from KeyPairGenerator javadoc Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/23280 From mpowers at openjdk.org Tue Feb 4 23:46:47 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 4 Feb 2025 23:46:47 GMT Subject: RFR: 8349084: Update vectors used in several PQC benchmarks Message-ID: [JDK-8349084](https://bugs.openjdk.org/browse/JDK-8349084) ------------- Commit messages: - first iteration Changes: https://git.openjdk.org/jdk/pull/23452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349084 Stats: 2310 lines in 3 files changed: 0 ins; 1975 del; 335 mod Patch: https://git.openjdk.org/jdk/pull/23452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23452/head:pull/23452 PR: https://git.openjdk.org/jdk/pull/23452 From matthias.baesken at sap.com Wed Feb 5 08:00:58 2025 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Feb 2025 08:00:58 +0000 Subject: Kernel TLS (KTLS) in OpenJDK Message-ID: Hello, are there some plans or experiments to use Kernel TLS (KTLS) in OpenJDK ? https://www.kernel.org/doc/html/v6.6/networking/tls.html Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at openjdk.org Wed Feb 5 10:35:10 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 5 Feb 2025 10:35:10 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v2] In-Reply-To: References: <7UgNYEuTu6rj7queOgM9xIy-6kQMdACrZiDLtlniMYw=.dff6f18b-1236-43b1-8280-2bce9160f32a@github.com> Message-ID: On Tue, 4 Feb 2025 18:57:28 GMT, Ferenc Rakoczi wrote: >>> @ferakocz I'm afraid you lucked out on getting your change committed before my reorganization of the stub generation code. If you are unsure of how to do the merge so your new stub is declared and generated following the new model (see the doc comments in stubDeclarations.hpp for details) let me know and I'll be happy to help you sort it out. >> >> @adinn I think I managed to figure it out. Please take a look at the PR and let me know if I should have done anything differently. > >> @ferakocz Yes, the stub declaration part of it looks to be correct. >> >> The rest of the patch will need at least two reviewers (@theRealAph? @martinuy? @franferrax) and may take some time to review, given that they will probably need to read up on the maths and algorithms. As an aid for reviewers and maintainers it would be good to insert a comment into the generator file linking the implementations to the relevant maths and algorithm. I found the FIPS-204 spec and the CRYSTALS-Dilithium Algorithm Speci?cations and Supporting Documentation paper, Shi Bai, L?o Ducas et al, 2021 - are they the best ones to look at? > > The Java implementation of ML-DSA is based on the FIPS-204 standard and the intrinsicss' implementations are based on the corresponding Java methods, except that the montMul() calls in them are inlined. The rest of the transformation from Java code to intrinsic code is pretty straightforward, so a reviewer need not necessarily understand the whole mathematics of the ML-DSA algorithms, just that the Java and the corresponding intrinsic code do the same thing. @ferakocz > The Java implementation of ML-DSA is based on the FIPS-204 standard and the intrinsics' implementations are based on the corresponding Java methods, except that the montMul() calls in them are inlined. The rest of the transformation from Java code to intrinsic code is pretty straightforward, so a reviewer need not necessarily understand the whole mathematics of the ML-DSA algorithms, just that the Java and the corresponding intrinsic code do the same thing. Yes, I located the relevant Java implementations in SHA3.java (keccak) and ML_DSA.java (dilithiumXXX) plus also SHA3Parallel.java (doubleKeccak). The first file does at least mention FIPS-202. The second does not include any reference, in particular does not mention FIPS-204. I still think it would be helpful for reviewers and maintainers if you were to add a comment in front of the generator routines that 1) notes that these routines are based on the relevant Java sources and 2) mentions that the Java code is in turn based on the FIPS-202 and FIPS-204 standards. While I agree that a reviewer or maintainer could simply check the generated code against the Java code I believe access to the underlying theory will be of aid when it comes to understanding what each variant is doing and verifying the equivalence of the two. That's why I'd also prefer to have two reviews to be sure that more than one of us who may be tasked with maintaining this code can be happy that we understand, at least, the equivalence in question. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2636346476 From dfuchs at openjdk.org Wed Feb 5 12:06:10 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 5 Feb 2025 12:06:10 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:42:24 GMT, Bradford Wetmore wrote: >> Update and clarify the sample code. >> >> Docs only, no additional testing other than verifying javadoc is correctly output. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Codereview Comments src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 661: > 659: * // Encode 3 Meetei Mayek letters (HUK, UN, I) using Unicode Escapes > 660: * // 0xabcd->0xabcf, 2 Unicode bytes/letter. > 661: * String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; jshell> String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; | Error: | illegal escape character | String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; | ^ | Error: | illegal escape character | String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; | ^ | Error: | illegal escape character | String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; | ^ src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 672: > 670: * // Also, encode a two byte RFC 8701 GREASE ALPN value > 671: * // e.g. 0x0A, 0x1A, 0x2A...0xFA > 672: * String rfc8701Grease8A = "\u005cu008A\u005cu008A"; jshell> String rfc8701Grease8A = "\u005cu008A\u005cu008A"; | Error: | illegal escape character | String rfc8701Grease8A = "\u005cu008A\u005cu008A"; | ^ | Error: | illegal escape character | String rfc8701Grease8A = "\u005cu008A\u005cu008A"; | ^ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1942749685 PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1942746393 From dfuchs at openjdk.org Wed Feb 5 12:06:10 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 5 Feb 2025 12:06:10 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 11:59:49 GMT, Daniel Fuchs wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Codereview Comments > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 672: > >> 670: * // Also, encode a two byte RFC 8701 GREASE ALPN value >> 671: * // e.g. 0x0A, 0x1A, 0x2A...0xFA >> 672: * String rfc8701Grease8A = "\u005cu008A\u005cu008A"; > > jshell> String rfc8701Grease8A = "\u005cu008A\u005cu008A"; > | Error: > | illegal escape character > | String rfc8701Grease8A = "\u005cu008A\u005cu008A"; > | ^ > | Error: > | illegal escape character > | String rfc8701Grease8A = "\u005cu008A\u005cu008A"; > | ^ Is this a rendering issue or is there something missing (or superfluous) in these strings? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1942751535 From djelinski at openjdk.org Wed Feb 5 12:29:11 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 5 Feb 2025 12:29:11 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: Message-ID: 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 The reproducer you provided doesn't try to load KnownOIDs on my machine. What am I missing? Other than that, the change looks reasonable to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23411#issuecomment-2636592100 From fguallini at openjdk.org Wed Feb 5 13:56:24 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Wed, 5 Feb 2025 13:56:24 GMT Subject: RFR: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings Message-ID: When compiling the test class: jdk/test/lib/security/timestamp/TsaServer.java Two warning are shown: test/lib/security/timestamp/TsaServer.java:56: warning: [this-escape] possible 'this' escape before subclass is fully initialized setHandler(handler); - setHandler is called in the constructor and a subclass may override it. It is fixed by making the method 'final' test/lib/security/timestamp/TsaServer.java:42: warning: [try] auto-closeable resource TsaServer has a member method close() that could throw InterruptedException - Remove `throws Exception` from TsaServer.close() ------------- Commit messages: - fixed warnings in test/lib/jdk/test/lib/security/timestamp/TsaServer.java Changes: https://git.openjdk.org/jdk/pull/23463/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23463&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346049 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23463.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23463/head:pull/23463 PR: https://git.openjdk.org/jdk/pull/23463 From rriggs at openjdk.org Wed Feb 5 15:24:16 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Feb 2025 15:24:16 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: Message-ID: <9qRdcyrkrFZ1vOa0ffS0kf5ED620fKCK4Iuo1fGt99Q=.f9515948-e003-46c7-9678-c88ac98d6fcc@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 src/java.base/share/classes/sun/security/util/KnownOIDs.java line 494: > 492: this.stdName = stdName; > 493: this.registerNames = registerNames; > 494: this.aliases = new String[0]; Unless this String[] needs to be unique, it would be sufficient to use the same empty array everywhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23411#discussion_r1943166687 From weijun at openjdk.org Wed Feb 5 15:56:10 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 5 Feb 2025 15:56:10 GMT Subject: RFR: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:53:09 GMT, Fernando Guallini wrote: > When compiling the test class: jdk/test/lib/security/timestamp/TsaServer.java > > > Two warning are shown: > > > test/lib/security/timestamp/TsaServer.java:56: warning: [this-escape] possible 'this' escape before subclass is fully initialized > setHandler(handler); > > - setHandler is called in the constructor and a subclass may override it. It is fixed by making the method 'final' > > > test/lib/security/timestamp/TsaServer.java:42: warning: [try] auto-closeable resource TsaServer has a member method close() that could throw InterruptedException > > - Remove `throws Exception` from TsaServer.close() Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23463#pullrequestreview-2596243328 From mullan at openjdk.org Wed Feb 5 15:58:10 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 5 Feb 2025 15:58:10 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: Message-ID: 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 @valeriepeng can you please review this change? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23411#issuecomment-2637327858 From mpowers at openjdk.org Wed Feb 5 16:21:15 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 5 Feb 2025 16:21:15 GMT Subject: RFR: 8349084: Update vectors used in several PQC benchmarks [v2] In-Reply-To: References: Message-ID: > [JDK-8349084](https://bugs.openjdk.org/browse/JDK-8349084) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: update LMS test vectors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23452/files - new: https://git.openjdk.org/jdk/pull/23452/files/8294b4b3..b0e59582 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23452&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23452&range=00-01 Stats: 225 lines in 1 file changed: 2 ins; 7 del; 216 mod Patch: https://git.openjdk.org/jdk/pull/23452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23452/head:pull/23452 PR: https://git.openjdk.org/jdk/pull/23452 From swen at openjdk.org Wed Feb 5 16:32:10 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 5 Feb 2025 16:32:10 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: <9qRdcyrkrFZ1vOa0ffS0kf5ED620fKCK4Iuo1fGt99Q=.f9515948-e003-46c7-9678-c88ac98d6fcc@github.com> References: <9qRdcyrkrFZ1vOa0ffS0kf5ED620fKCK4Iuo1fGt99Q=.f9515948-e003-46c7-9678-c88ac98d6fcc@github.com> Message-ID: On Wed, 5 Feb 2025 15:21:59 GMT, Roger Riggs 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 > > src/java.base/share/classes/sun/security/util/KnownOIDs.java line 494: > >> 492: this.stdName = stdName; >> 493: this.registerNames = registerNames; >> 494: this.aliases = new String[0]; > > Unless this String[] needs to be unique, it would be sufficient to use the same empty array everywhere. you are right, but accessing static field from enum constructor is not allowed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23411#discussion_r1943285247 From fguallini at openjdk.org Wed Feb 5 16:37:15 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Wed, 5 Feb 2025 16:37:15 GMT Subject: RFR: 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore In-Reply-To: References: Message-ID: <5aYvsKCaAFLm0KSeNt0IWMBe-f2brIBGCI3YQBuAWEM=.c171095e-2cfc-456d-a8f6-928666dfe83d@github.com> On Wed, 2 Oct 2024 13:24:00 GMT, Fernando Guallini wrote: > The test: **sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java** relies on the `certutil.exe` tool to import and delete certificates from a keystore. It was annotated with `@ignore` due to the uncertainty of `certutil.exe` being available on the instance where the test is executed. > > Rather than ignoring the test entirely, this PR updates the logic to throw a `SkippedException` if the tool is not found, ensuring the test runs when possible, and gracefully skipped otherwise. Review pending ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21305#issuecomment-2637437446 From swen at openjdk.org Wed Feb 5 16:44:12 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 5 Feb 2025 16:44:12 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: Message-ID: <6khizncuzjbXtuD0HkQrFfh3j6KpRfHHPb504b7A1v8=.8b4c2296-d00a-4a2e-85b7-1f2fab76142a@github.com> On Wed, 5 Feb 2025 12:26:17 GMT, Daniel Jeli?ski wrote: > The reproducer you provided doesn't try to load KnownOIDs on my machine. What am I missing? > > Other than that, the change looks reasonable to me. Sorry, maybe I am wrong. My test above is using build/macosx-aarch64-server-release/jdk (exploded image) and there is this problem, but when I test with build/macosx-aarch64-server-release/images/jdk, the startup process does not load these embedded classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23411#issuecomment-2637454478 From weijun at openjdk.org Wed Feb 5 17:05:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 5 Feb 2025 17:05:11 GMT Subject: RFR: 8349084: Update vectors used in several PQC benchmarks [v2] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 16:21:15 GMT, Mark Powers wrote: >> [JDK-8349084](https://bugs.openjdk.org/browse/JDK-8349084) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > update LMS test vectors Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23452#pullrequestreview-2596434191 From bradford.wetmore at oracle.com Wed Feb 5 17:45:48 2025 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 5 Feb 2025 09:45:48 -0800 Subject: Kernel TLS (KTLS) in OpenJDK In-Reply-To: References: Message-ID: Nothing I'm aware of. We are focused on the JSSE TLS stack. Brad On 2/5/2025 12:00 AM, Baesken, Matthias wrote: > > Hello,? are there some plans or experiments to use? Kernel TLS (KTLS) > in OpenJDK ? > > https://www.kernel.org/doc/html/v6.6/networking/tls.html > > Best regards, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wetmore at openjdk.org Wed Feb 5 17:57:18 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 5 Feb 2025 17:57:18 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:02:26 GMT, Daniel Fuchs wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Codereview Comments > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 661: > >> 659: * // Encode 3 Meetei Mayek letters (HUK, UN, I) using Unicode Escapes >> 660: * // 0xabcd->0xabcf, 2 Unicode bytes/letter. >> 661: * String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; > > jshell> String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; > | Error: > | illegal escape character > | String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; > | ^ > | Error: > | illegal escape character > | String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; > | ^ > | Error: > | illegal escape character > | String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; > | ^ javadoc on "\u005c" produces the "" character. So "\u005cuabcd" renders "\uabcd..." The resulting javadoc looks like: // Encode 3 Meetei Mayek letters (HUK, UN, I) using Unicode Escapes // 0xabcd->0xabcf, 2 Unicode bytes/letter. String HUK_UN_I = "\uabcd\uabce\uabcf"; That was the way it was done elsewhere in the JDK (e.g. `Arrays`/`URI`/etc.) minus the `{@code...}`, so did the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1943396016 From wetmore at openjdk.org Wed Feb 5 17:57:20 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 5 Feb 2025 17:57:20 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:03:52 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 672: >> >>> 670: * // Also, encode a two byte RFC 8701 GREASE ALPN value >>> 671: * // e.g. 0x0A, 0x1A, 0x2A...0xFA >>> 672: * String rfc8701Grease8A = "\u005cu008A\u005cu008A"; >> >> jshell> String rfc8701Grease8A = "\u005cu008A\u005cu008A"; >> | Error: >> | illegal escape character >> | String rfc8701Grease8A = "\u005cu008A\u005cu008A"; >> | ^ >> | Error: >> | illegal escape character >> | String rfc8701Grease8A = "\u005cu008A\u005cu008A"; >> | ^ > > Is this a rendering issue or is there something missing (or superfluous) in these strings? See other comment. javadoc renders this properly in the resulting HTML. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1943396807 From duke at openjdk.org Wed Feb 5 17:57:48 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 5 Feb 2025 17:57:48 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid Message-ID: * fully automated the test * removed the race condition * client on a thread and server on a thread options are now run together automatically ------------- Commit messages: - JDK-8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid Changes: https://git.openjdk.org/jdk/pull/23469/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23469&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8249824 Stats: 108 lines in 1 file changed: 59 ins; 19 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/23469.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23469/head:pull/23469 PR: https://git.openjdk.org/jdk/pull/23469 From mpowers at openjdk.org Wed Feb 5 18:06:31 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 5 Feb 2025 18:06:31 GMT Subject: Integrated: 8349084: Update vectors used in several PQC benchmarks In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 23:39:48 GMT, Mark Powers wrote: > [JDK-8349084](https://bugs.openjdk.org/browse/JDK-8349084) This pull request has now been integrated. Changeset: 2f2f7cf0 Author: Mark Powers URL: https://git.openjdk.org/jdk/commit/2f2f7cf0dddd82f11d6dfc4f8a5401ec1c5629dc Stats: 2535 lines in 3 files changed: 2 ins; 1982 del; 551 mod 8349084: Update vectors used in several PQC benchmarks Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/23452 From dfuchs at openjdk.org Wed Feb 5 18:07:30 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 5 Feb 2025 18:07:30 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 17:42:11 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 661: >> >>> 659: * // Encode 3 Meetei Mayek letters (HUK, UN, I) using Unicode Escapes >>> 660: * // 0xabcd->0xabcf, 2 Unicode bytes/letter. >>> 661: * String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; >> >> jshell> String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; >> | Error: >> | illegal escape character >> | String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; >> | ^ >> | Error: >> | illegal escape character >> | String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; >> | ^ >> | Error: >> | illegal escape character >> | String HUK_UN_I = "\u005cuabcd\u005cuabce\u005cuabcf"; >> | ^ > > javadoc on "\u005c" produces the "" character. > > So "\u005cuabcd" renders "\uabcd..." > > The resulting javadoc looks like: > > // Encode 3 Meetei Mayek letters (HUK, UN, I) using Unicode Escapes > // 0xabcd->0xabcf, 2 Unicode bytes/letter. > String HUK_UN_I = "\uabcd\uabce\uabcf"; > > That was the way it was done elsewhere in the JDK (e.g. `Arrays`/`URI`/etc.) minus the `{@code...}`, so did the same. Ahhh! I see. Thanks for the explanation! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1943430044 From dfuchs at openjdk.org Wed Feb 5 18:15:14 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 5 Feb 2025 18:15:14 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:42:24 GMT, Bradford Wetmore wrote: >> Update and clarify the sample code. >> >> Docs only, no additional testing other than verifying javadoc is correctly output. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Codereview Comments I had to convince myself (using jshell) that `rfc8701Grease8A.getBytes("ISO_8859_1")` would return the correct result - but I see that's OK, so this looks good to me. Maybe wait for a review from someone from security-libs before integrating. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23379#pullrequestreview-2596603327 From duke at openjdk.org Wed Feb 5 18:16:55 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 5 Feb 2025 18:16:55 GMT Subject: RFR: 8344316: security/auth/callback/TextCallbackHandler/Password.java make runnable with JTReg and add the UI [v10] In-Reply-To: References: Message-ID: > * Changed security/auth/callback/TextCallbackHandler/Password.java to run with JTReg, now the dialog box with instructions will appear as a ui Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: minor, spelling and instructions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22951/files - new: https://git.openjdk.org/jdk/pull/22951/files/cbbe4284..56d1d3e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22951&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22951&range=08-09 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22951.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22951/head:pull/22951 PR: https://git.openjdk.org/jdk/pull/22951 From weijun at openjdk.org Wed Feb 5 18:21:13 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 5 Feb 2025 18:21:13 GMT Subject: RFR: 8344316: security/auth/callback/TextCallbackHandler/Password.java make runnable with JTReg and add the UI [v10] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 18:16:55 GMT, Mikhail Yankelevich wrote: >> * Changed security/auth/callback/TextCallbackHandler/Password.java to run with JTReg, now the dialog box with instructions will appear as a ui > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor, spelling and instructions Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22951#pullrequestreview-2596618220 From duke at openjdk.org Wed Feb 5 18:26:17 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 5 Feb 2025 18:26:17 GMT Subject: Integrated: 8344316: security/auth/callback/TextCallbackHandler/Password.java make runnable with JTReg and add the UI In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 16:19:58 GMT, Mikhail Yankelevich wrote: > * Changed security/auth/callback/TextCallbackHandler/Password.java to run with JTReg, now the dialog box with instructions will appear as a ui This pull request has now been integrated. Changeset: 82bc0a7f Author: Mikhail Yankelevich Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/82bc0a7f8c7ee63d2f8c3db57dc22f39963ae022 Stats: 120 lines in 1 file changed: 98 ins; 15 del; 7 mod 8344316: security/auth/callback/TextCallbackHandler/Password.java make runnable with JTReg and add the UI Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/22951 From dfuchs at openjdk.org Wed Feb 5 18:38:11 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 5 Feb 2025 18:38:11 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid In-Reply-To: References: Message-ID: <2mFQ9UAOA-z3tI8fOg7G-JCRr066l28gFenTo84niKk=.7b4d1b21-ab2b-411e-9df5-5fe0597ca2dc@github.com> On Wed, 5 Feb 2025 17:39:42 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 The new logic looks good to me. Please wait for a review from someone from security libs before integrating. test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 122: > 120: } > 121: > 122: /* send the header */ Suggestion: /* send the response headers and body */ test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 229: > 227: // setting up the error stream for further analysis > 228: var errorCapture = new ByteArrayOutputStream(); > 229: var outputStream = new PrintStream(errorCapture); Suggestion: var errorStream = new PrintStream(errorCapture); test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 231: > 229: var outputStream = new PrintStream(errorCapture); > 230: var originalErr = System.err; // saving the initial error stream, so it can be restored > 231: System.setErr(outputStream); Suggestion: System.setErr(errorStream); test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 238: > 236: try { > 237: new CloseKeepAliveCached(); > 238: }finally { Suggestion: } finally { test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 246: > 244: } > 245: > 246: // Looking for the result in the error stream, as it's used by debug (who called close SSL connection) Suggestion: // Parses the captured error stream, which is used by debug, to find out who closed the SSL connection ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23469#pullrequestreview-2596638156 PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1943462703 PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1943466722 PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1943467436 PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1943467684 PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1943470523 From dfuchs at openjdk.org Wed Feb 5 18:45:10 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 5 Feb 2025 18:45:10 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 17:39:42 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 And implementing the suggested changes would be good... ------------- Changes requested by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23469#pullrequestreview-2596673995 From duke at openjdk.org Wed Feb 5 18:50:25 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 5 Feb 2025 18:50:25 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid [v2] In-Reply-To: References: Message-ID: > * 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: Apply suggestions from cr Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23469/files - new: https://git.openjdk.org/jdk/pull/23469/files/d2f11260..5e300681 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23469&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23469&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23469.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23469/head:pull/23469 PR: https://git.openjdk.org/jdk/pull/23469 From duke at openjdk.org Wed Feb 5 18:50:25 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 5 Feb 2025 18:50:25 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid [v2] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 18:42:10 GMT, Daniel Fuchs wrote: > And implementing the suggested changes would be good... done, thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/23469#issuecomment-2637743071 From dfuchs at openjdk.org Wed Feb 5 19:50:58 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 5 Feb 2025 19:50:58 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid [v2] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 18:50:25 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: > > Apply suggestions from cr > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23469#pullrequestreview-2596826422 From mpowers at openjdk.org Wed Feb 5 20:46:28 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 5 Feb 2025 20:46:28 GMT Subject: [jdk24] RFR: JDK-8349084 : Update vectors used in several PQC benchmarks Message-ID: [JDK-8349084](https://bugs.openjdk.org/browse/JDK-8349084) ------------- Commit messages: - Backport 2f2f7cf0dddd82f11d6dfc4f8a5401ec1c5629dc Changes: https://git.openjdk.org/jdk/pull/23473/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23473&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349084 Stats: 2535 lines in 3 files changed: 2 ins; 1982 del; 551 mod Patch: https://git.openjdk.org/jdk/pull/23473.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23473/head:pull/23473 PR: https://git.openjdk.org/jdk/pull/23473 From rhalade at openjdk.org Wed Feb 5 21:40:14 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 5 Feb 2025 21:40:14 GMT Subject: RFR: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:53:09 GMT, Fernando Guallini wrote: > When compiling the test class: jdk/test/lib/security/timestamp/TsaServer.java > > > Two warning are shown: > > > test/lib/security/timestamp/TsaServer.java:56: warning: [this-escape] possible 'this' escape before subclass is fully initialized > setHandler(handler); > > - setHandler is called in the constructor and a subclass may override it. It is fixed by making the method 'final' > > > test/lib/security/timestamp/TsaServer.java:42: warning: [try] auto-closeable resource TsaServer has a member method close() that could throw InterruptedException > > - Remove `throws Exception` from TsaServer.close() Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23463#pullrequestreview-2597024302 From hchao at openjdk.org Wed Feb 5 22:31:10 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 5 Feb 2025 22:31:10 GMT Subject: RFR: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:53:09 GMT, Fernando Guallini wrote: > When compiling the test class: jdk/test/lib/security/timestamp/TsaServer.java > > > Two warning are shown: > > > test/lib/security/timestamp/TsaServer.java:56: warning: [this-escape] possible 'this' escape before subclass is fully initialized > setHandler(handler); > > - setHandler is called in the constructor and a subclass may override it. It is fixed by making the method 'final' > > > test/lib/security/timestamp/TsaServer.java:42: warning: [try] auto-closeable resource TsaServer has a member method close() that could throw InterruptedException > > - Remove `throws Exception` from TsaServer.close() Marked as reviewed by hchao (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23463#pullrequestreview-2597136008 From hchao at openjdk.org Wed Feb 5 22:48:14 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 5 Feb 2025 22:48:14 GMT Subject: RFR: 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore In-Reply-To: References: Message-ID: On Wed, 2 Oct 2024 13:24:00 GMT, Fernando Guallini wrote: > The test: **sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java** relies on the `certutil.exe` tool to import and delete certificates from a keystore. It was annotated with `@ignore` due to the uncertainty of `certutil.exe` being available on the instance where the test is executed. > > Rather than ignoring the test entirely, this PR updates the logic to throw a `SkippedException` if the tool is not found, ensuring the test runs when possible, and gracefully skipped otherwise. Nit: copyright update ------------- PR Comment: https://git.openjdk.org/jdk/pull/21305#issuecomment-2638206069 From mbalao at openjdk.org Wed Feb 5 22:51:44 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 5 Feb 2025 22:51:44 GMT Subject: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v13] In-Reply-To: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> References: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> Message-ID: > We would like to propose an implementation of the HKDF algorithms for SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key Derivation Function API (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)). > > This implementation will be under the _Preview_ umbrella until the KDF API becomes stable in a future JDK release. The benefit of this early proposal is to gather more feedback about the KDF API for future improvements. > > The `P11KDF` class has the core implementation and Java calls to the PKCS 11 API. Different native mechanism were used to merge key material: CKM_CONCATENATE_BASE_AND_DATA (key and data), CKM_CONCATENATE_BASE_AND_KEY (key and key) and CKM_CONCATENATE_DATA_AND_BASE (data and key). The implementation also supports merging data with data, at the Java level. List of HKDF algorithms supported: HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512. > > Derivation modes supported: extract, expand, and, extract-expand. > > We further advanced the consolidation of algorithm and key info in the P11SecretKeyFactory map ?this effort started with the PBE support enhancement and has helped to avoid duplication?. The map has now information about HMAC (`HMACKeyInfo` class) and HKDF (`HKDFKeyInfo` class) algorithms. P11Mac is now aligned to take the information from the map. > > Generic keys now supported in SecretKeyFactory. Derived keys could be Generic. > > Testing > > * [TestHKDF.java](https://github.com/openjdk/jdk/blob/e87ec99b90ff742f531a5031fdeeb9f2e039856d/test/jdk/sun/security/pkcs11/KDF/TestHKDF.java) test added > * All non-SHA1 & non-SHA224 RFC 5869 test vectors checked > * Cross-checking against SunJCE's HKDF implementation for every algorithm possible > * Static assertion data for resilience if SunJCE were not available > * Use of derived key for encryption check > * Concatenation of input key material and salt checked (multiple combinations) > * Multiple derivation types checked (extract only, expand only, and, extract-expand) > * Derive key and derive data checked > * All supported HKDF algorithms tested (HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512) > * DH and ECDH key derivation for TLS checked > * Informative output for debugging purposes (shown automatically if there is a test failure) > * Note: test failures do not prevent all tests for running > * Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/security/pkcs11 (114 tests passed, 0 failed) > > A CSR will be proposed. > > This proposal is... Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Align behaviour with the CSR Make a PKCS #11 library supporting only CKM_HKDF_DERIVE or CKM_HKDF_DATA to also register the HKDF algorithms. Notice that the corresponding HMAC mechanism is still required. In case only one of the mechanisms is available, KDF::deriveKey or KDF::deriveData will fail at run time. If the user disables one of CKM_HKDF_DERIVE or CKM_HKDF_DATA through sun.security.pkcs11.Config, also refrain from using it. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22215/files - new: https://git.openjdk.org/jdk/pull/22215/files/a7c82ee3..87f4820a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22215&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22215&range=11-12 Stats: 36 lines in 3 files changed: 14 ins; 10 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/22215.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22215/head:pull/22215 PR: https://git.openjdk.org/jdk/pull/22215 From weijun at openjdk.org Wed Feb 5 22:59:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 5 Feb 2025 22:59:11 GMT Subject: [jdk24] RFR: 8349084: Update vectors used in several PQC benchmarks In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 20:22:47 GMT, Mark Powers wrote: > Hi all, > > This pull request contains a backport of commit 2f2f7cf0 from the openjdk/jdk repository. > > The commit being backported was authored by Mark Powers on 5 Feb 2025 and was reviewed by Weijun Wang. > > Thanks! Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23473#pullrequestreview-2597173034 From mbalao at openjdk.org Wed Feb 5 23:06:54 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 5 Feb 2025 23:06:54 GMT Subject: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v14] In-Reply-To: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> References: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> Message-ID: <7wCfQrs53w7KWE6l-T_WxnNVMt3l4W6LuY-s0zwJprU=.44a999d7-184f-487c-b076-97e717d51af4@github.com> > We would like to propose an implementation of the HKDF algorithms for SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key Derivation Function API (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)). > > This implementation will be under the _Preview_ umbrella until the KDF API becomes stable in a future JDK release. The benefit of this early proposal is to gather more feedback about the KDF API for future improvements. > > The `P11KDF` class has the core implementation and Java calls to the PKCS 11 API. Different native mechanism were used to merge key material: CKM_CONCATENATE_BASE_AND_DATA (key and data), CKM_CONCATENATE_BASE_AND_KEY (key and key) and CKM_CONCATENATE_DATA_AND_BASE (data and key). The implementation also supports merging data with data, at the Java level. List of HKDF algorithms supported: HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512. > > Derivation modes supported: extract, expand, and, extract-expand. > > We further advanced the consolidation of algorithm and key info in the P11SecretKeyFactory map ?this effort started with the PBE support enhancement and has helped to avoid duplication?. The map has now information about HMAC (`HMACKeyInfo` class) and HKDF (`HKDFKeyInfo` class) algorithms. P11Mac is now aligned to take the information from the map. > > Generic keys now supported in SecretKeyFactory. Derived keys could be Generic. > > Testing > > * [TestHKDF.java](https://github.com/openjdk/jdk/blob/e87ec99b90ff742f531a5031fdeeb9f2e039856d/test/jdk/sun/security/pkcs11/KDF/TestHKDF.java) test added > * All non-SHA1 & non-SHA224 RFC 5869 test vectors checked > * Cross-checking against SunJCE's HKDF implementation for every algorithm possible > * Static assertion data for resilience if SunJCE were not available > * Use of derived key for encryption check > * Concatenation of input key material and salt checked (multiple combinations) > * Multiple derivation types checked (extract only, expand only, and, extract-expand) > * Derive key and derive data checked > * All supported HKDF algorithms tested (HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512) > * DH and ECDH key derivation for TLS checked > * Informative output for debugging purposes (shown automatically if there is a test failure) > * Note: test failures do not prevent all tests for running > * Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/security/pkcs11 (114 tests passed, 0 failed) > > A CSR will be proposed. > > This proposal is... Martin Balao 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 14 additional commits since the last revision: - Merge openjdk/master into JDK-8328119 Fix trivial copyright conflict in: src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java - Align behaviour with the CSR Make a PKCS #11 library supporting only CKM_HKDF_DERIVE or CKM_HKDF_DATA to also register the HKDF algorithms. Notice that the corresponding HMAC mechanism is still required. In case only one of the mechanisms is available, KDF::deriveKey or KDF::deriveData will fail at run time. If the user disables one of CKM_HKDF_DERIVE or CKM_HKDF_DATA through sun.security.pkcs11.Config, also refrain from using it. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - Add test case with empty inputs Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - Improve TestContext note about expectedOpOut Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - Renaming of P11KDF fix. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - Minor changes based on review. Copyright date adjustments. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - Check disabled PKCS #11 mechanisms when concatenating keys and data. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - Support for HKDF-SHA1 and HKDF-SHA224 removed. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - Unused import removed. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - Fix NPE in assertion. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - ... and 4 more: https://git.openjdk.org/jdk/compare/2c72ae7c...d018b4a9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22215/files - new: https://git.openjdk.org/jdk/pull/22215/files/87f4820a..d018b4a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22215&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22215&range=12-13 Stats: 361985 lines in 8749 files changed: 205004 ins; 120500 del; 36481 mod Patch: https://git.openjdk.org/jdk/pull/22215.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22215/head:pull/22215 PR: https://git.openjdk.org/jdk/pull/22215 From fferrari at openjdk.org Wed Feb 5 23:18:21 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Wed, 5 Feb 2025 23:18:21 GMT Subject: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v12] In-Reply-To: References: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> Message-ID: <2Mzg6Jn3ThLv8k8oXMXt6EzqmxjOIUheSMnCCI8qo94=.5f9625c4-440b-4e9b-820f-df0d7d5c66ba@github.com> On Wed, 22 Jan 2025 04:19:19 GMT, Valerie Peng wrote: >> Martin Balao has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case with empty inputs >> >> Co-authored-by: Martin Balao Alonso >> Co-authored-by: Francisco Ferrari Bihurriet > > Updates look fine. Hi @valeriepeng, @driverkt, @wangweij, We needed to make more changes to align the behavior with the CSR description, see 87f4820aac1b1f96a3fe3155e90057a3c1544ce7. Would you mind giving it a look? Please note that the [CSR has also been updated](https://bugs.openjdk.org/browse/JDK-8344464?focusedId=14749821&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14749821). ------------- PR Comment: https://git.openjdk.org/jdk/pull/22215#issuecomment-2638244066 From lmesnik at openjdk.org Wed Feb 5 23:20:09 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 5 Feb 2025 23:20:09 GMT Subject: RFR: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:53:09 GMT, Fernando Guallini wrote: > When compiling the test class: jdk/test/lib/security/timestamp/TsaServer.java > > > Two warning are shown: > > > test/lib/security/timestamp/TsaServer.java:56: warning: [this-escape] possible 'this' escape before subclass is fully initialized > setHandler(handler); > > - setHandler is called in the constructor and a subclass may override it. It is fixed by making the method 'final' > > > test/lib/security/timestamp/TsaServer.java:42: warning: [try] auto-closeable resource TsaServer has a member method close() that could throw InterruptedException > > - Remove `throws Exception` from TsaServer.close() Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23463#pullrequestreview-2597201901 From mpowers at openjdk.org Wed Feb 5 23:30:20 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 5 Feb 2025 23:30:20 GMT Subject: [jdk24] Integrated: 8349084: Update vectors used in several PQC benchmarks In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 20:22:47 GMT, Mark Powers wrote: > Hi all, > > This pull request contains a backport of commit 2f2f7cf0 from the openjdk/jdk repository. > > The commit being backported was authored by Mark Powers on 5 Feb 2025 and was reviewed by Weijun Wang. > > Thanks! This pull request has now been integrated. Changeset: 681c6d43 Author: Mark Powers URL: https://git.openjdk.org/jdk/commit/681c6d43399bdf19f001c4ecdd93b52fb9043c87 Stats: 2535 lines in 3 files changed: 2 ins; 1982 del; 551 mod 8349084: Update vectors used in several PQC benchmarks Reviewed-by: weijun Backport-of: 2f2f7cf0dddd82f11d6dfc4f8a5401ec1c5629dc ------------- PR: https://git.openjdk.org/jdk/pull/23473 From duke at openjdk.org Thu Feb 6 05:58:52 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Thu, 6 Feb 2025 05:58:52 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 03:55:18 GMT, Nibedita Jena wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 136: > >> 134: public static sun.security.x509.CertificateExtensions createCertificateExtensions(PublicKey publicKey) throws IOException, NoSuchAlgorithmException { >> 135: // Create Extensions >> 136: sun.security.x509.CertificateExtensions certificateExtensions = new sun.security.x509.CertificateExtensions(); > > Same comment addressed indentation ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1944142275 From duke at openjdk.org Thu Feb 6 05:58:51 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Thu, 6 Feb 2025 05:58:51 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases Message-ID: Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. ------------- Commit messages: - JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases - JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases - JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases - JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases - JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases - JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases Changes: https://git.openjdk.org/jdk/pull/23315/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346094 Stats: 229 lines in 2 files changed: 218 ins; 6 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23315/head:pull/23315 PR: https://git.openjdk.org/jdk/pull/23315 From duke at openjdk.org Thu Feb 6 05:58:52 2025 From: duke at openjdk.org (Nibedita Jena) Date: Thu, 6 Feb 2025 05:58:52 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 12:39:45 GMT, Konanki Sreenath wrote: > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1: > 1: /* Copyright year should be 2025 since the file is changed test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 27: > 25: * @test > 26: * @bug 8346094 > 27: * @summary validating getExtensionValue and getKeyUsage with specified and unspecified extensions on the X509Certificate. Check line indentation issue test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 30: > 28: * @library /test/lib > 29: * @modules java.base/sun.security.x509 > 30: * java.base/sun.security.util Check line indentation issue test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 58: > 56: * else it is incorrect > 57: */ > 58: x509Certimpl.getInfo().setExtensions(createCertificateExtensions(x509Certimpl.getInfo().getKey().getKey())); Line indentation issue test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 61: > 59: Asserts.assertNotNull(x509Certimpl.getExtensionValue("2.5.29.17")); > 60: /** > 61: * Certificate is created with extensions. Invoking getExtensionValue with invalid oid must return NULL Same comment as above test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 101: > 99: x509CertInfo.setSubject(subject); > 100: > 101: //create and set the subject and issuer unique identity Give space after // test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 126: > 124: byte[] signedCert = {}; > 125: > 126: x509Certimpl = new X509CertImpl(x509CertInfo, AlgorithmId.get("SHA256withRSA"), signedData, signedCert); Line indentation test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 134: > 132: } > 133: > 134: public static sun.security.x509.CertificateExtensions createCertificateExtensions(PublicKey publicKey) throws IOException, NoSuchAlgorithmException { Same comment as above test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 136: > 134: public static sun.security.x509.CertificateExtensions createCertificateExtensions(PublicKey publicKey) throws IOException, NoSuchAlgorithmException { > 135: // Create Extensions > 136: sun.security.x509.CertificateExtensions certificateExtensions = new sun.security.x509.CertificateExtensions(); Same comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1942207350 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1942209828 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1942210035 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1942210479 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1942210641 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1942210931 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1942211209 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1942211366 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1942211452 From duke at openjdk.org Thu Feb 6 05:58:52 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Thu, 6 Feb 2025 05:58:52 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 17:29:24 GMT, Matthew Donovan wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 1: > >> 1: > > Needs a copyright statement added the copyright statement > test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 29: > >> 27: * else it is incorrect >> 28: */ >> 29: try { > > These try/catch blocks around the assert statements seem redundant. The assert methods already throw a RuntimeException with a message. Addressed and consolidated all try-catch blocks > test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 40: > >> 38: */ >> 39: try { >> 40: System.out.println("------ cert x509Certimpl ------ " + x509Certimpl); > > The output might be a little easier to read if you put the "---- cert X509Certimpl ----" on its own line. was added these during the debug and continued the same in draft PR. I have removed these statements ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1940501046 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1940502406 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1940501952 From mdonovan at openjdk.org Thu Feb 6 05:58:52 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 6 Feb 2025 05:58:52 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 12:39:45 GMT, Konanki Sreenath wrote: > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 1: > 1: Needs a copyright statement test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 29: > 27: * else it is incorrect > 28: */ > 29: try { These try/catch blocks around the assert statements seem redundant. The assert methods already throw a RuntimeException with a message. test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 40: > 38: */ > 39: try { > 40: System.out.println("------ cert x509Certimpl ------ " + x509Certimpl); The output might be a little easier to read if you put the "---- cert X509Certimpl ----" on its own line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1937648399 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1937661846 PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1937659335 From fguallini at openjdk.org Thu Feb 6 09:47:19 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Thu, 6 Feb 2025 09:47:19 GMT Subject: RFR: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings In-Reply-To: References: Message-ID: <6i7l8HDjf834r1F64B-UMB29jqXR-myI4BvmVECN69Q=.9f67eb10-ccb4-4fe2-a3c6-c70855f3cda9@github.com> On Wed, 5 Feb 2025 12:53:09 GMT, Fernando Guallini wrote: > When compiling the test class: jdk/test/lib/security/timestamp/TsaServer.java > > > Two warning are shown: > > > test/lib/security/timestamp/TsaServer.java:56: warning: [this-escape] possible 'this' escape before subclass is fully initialized > setHandler(handler); > > - setHandler is called in the constructor and a subclass may override it. It is fixed by making the method 'final' > > > test/lib/security/timestamp/TsaServer.java:42: warning: [try] auto-closeable resource TsaServer has a member method close() that could throw InterruptedException > > - Remove `throws Exception` from TsaServer.close() Thanks for reviews ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23463#issuecomment-2639312183 From duke at openjdk.org Thu Feb 6 09:51:12 2025 From: duke at openjdk.org (duke) Date: Thu, 6 Feb 2025 09:51:12 GMT Subject: RFR: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:53:09 GMT, Fernando Guallini wrote: > When compiling the test class: jdk/test/lib/security/timestamp/TsaServer.java > > > Two warning are shown: > > > test/lib/security/timestamp/TsaServer.java:56: warning: [this-escape] possible 'this' escape before subclass is fully initialized > setHandler(handler); > > - setHandler is called in the constructor and a subclass may override it. It is fixed by making the method 'final' > > > test/lib/security/timestamp/TsaServer.java:42: warning: [try] auto-closeable resource TsaServer has a member method close() that could throw InterruptedException > > - Remove `throws Exception` from TsaServer.close() @fguallini Your change (at version 79275ce3deb22ca5b37dfa4e58b71c9541feb202) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23463#issuecomment-2639320471 From fguallini at openjdk.org Thu Feb 6 09:53:05 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Thu, 6 Feb 2025 09:53:05 GMT Subject: RFR: 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 22:45:36 GMT, Hai-May Chao wrote: > Nit: copyright update updated to 2025 now ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21305#issuecomment-2639325902 From fguallini at openjdk.org Thu Feb 6 09:53:04 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Thu, 6 Feb 2025 09:53:04 GMT Subject: RFR: 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore [v2] In-Reply-To: References: Message-ID: > The test: **sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java** relies on the `certutil.exe` tool to import and delete certificates from a keystore. It was annotated with `@ignore` due to the uncertainty of `certutil.exe` being available on the instance where the test is executed. > > Rather than ignoring the test entirely, this PR updates the logic to throw a `SkippedException` if the tool is not found, ensuring the test runs when possible, and gracefully skipped otherwise. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: Update copyright to 2025 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21305/files - new: https://git.openjdk.org/jdk/pull/21305/files/db10f3cd..618b03ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21305&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21305&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21305.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21305/head:pull/21305 PR: https://git.openjdk.org/jdk/pull/21305 From duke at openjdk.org Thu Feb 6 12:17:19 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Thu, 6 Feb 2025 12:17:19 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java Message-ID: * ./util/Pem/encoding.sh is now a java test * also added the validations for the test results, not only an error check ------------- Commit messages: - JDK-8349532: Refactor ./util/Pem/encoding.sh to run in java Changes: https://git.openjdk.org/jdk/pull/23492/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23492&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349532 Stats: 90 lines in 2 files changed: 51 ins; 35 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23492/head:pull/23492 PR: https://git.openjdk.org/jdk/pull/23492 From mullan at openjdk.org Thu Feb 6 13:58:16 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 6 Feb 2025 13:58:16 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 12:39:45 GMT, Konanki Sreenath wrote: > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. Please don't integrate until someone from the Security Group reviews this PR. Thanks. @jnimeh Can you please review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2639896749 PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2639898463 From duke at openjdk.org Thu Feb 6 13:58:19 2025 From: duke at openjdk.org (Tim Jacomb) Date: Thu, 6 Feb 2025 13:58:19 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 Possible to get a second reviewer? potentially @wangweij? Unless @seanjmullan you could suggest someone? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2639899448 From mdonovan at openjdk.org Thu Feb 6 14:05:11 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 6 Feb 2025 14:05:11 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 04:51:15 GMT, Konanki Sreenath wrote: >> test/jdk/java/security/cert/X509Certificate/CertificateExtensions.java line 29: >> >>> 27: * else it is incorrect >>> 28: */ >>> 29: try { >> >> These try/catch blocks around the assert statements seem redundant. The assert methods already throw a RuntimeException with a message. > > Addressed and consolidated all try-catch blocks Is this try/catch necessary at all? The methods in Asserts throw RuntimeExceptions already and the "test setup" code like createCertificateExceptions() throws other exceptions which is fine because main() is declared to throw Exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1944782038 From weijun.wang at oracle.com Thu Feb 6 14:12:09 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Thu, 6 Feb 2025 14:12:09 +0000 Subject: Linux support for java.security.jgss "nativeccache" functionality In-Reply-To: References: <6f0f0e19-5305-4d2f-99ab-9199caaf8c6e@oracle.com> Message-ID: <8F150178-43BB-4C87-93E0-11B2E81D3CD7@oracle.com> Hi Nick, I?ve filed https://bugs.openjdk.org/browse/JDK-8349546. It will be great if the same code could support nativeccache on both Mac and Linux. If the test cannot be automated, feel free to add some instructions for manual testing. Looking forward to your first OpenJDK contribution! Thanks, Weijun On Feb 3, 2025, at 19:04, Hall, Nick wrote: Hi Sean, Thanks for your response - I confirm that my company is D. E. Shaw & Co. Let me know if I can provide any further information! Nick ________________________________ From: Sean Mullan Sent: Monday, February 3, 2025 11:03 pm To: Hall, Nick ; security-dev at openjdk.org Subject: Re: Linux support for java.security.jgss "nativeccache" functionality This message was sent by an external party. Hi Nick, This proposal does sound like it would be useful, so I think we can start some more discussions about it. Once we go a bit further in the discussions and we decide it is worthwhile, we can open a JBS issue for tracking purposes. For starters, can you confirm that your company is "D. E. Shaw & Co., LP"? --Sean On 1/31/25 12:04 PM, Hall, Nick wrote: > Hi, > > The current OpenJDK code has ?native? ccache support for both Windows/ > Mac, allowing native Kerberos credential acquisition on those platforms > via the usual system library calls rather than the pure Java code. It > does not support Linux, meaning that only file based ccaches are > supported on that platform. I couldn?t find any other similar bug > reports/fixes/submissions, so have developed a patch that I?d like to > contribute to improve this support (for full disclosure, this is a > corporate submission approved by my employer, and the OCA has been > appropriately signed; this is my first time contributing to the OpenJDK). > > The motivation for doing this is that the Linux Kerberos / GSS-API > system libraries support more than just file-based Kerberos credential > caches ? in particular, we?re interested in supporting KCM, which is a > standard protocol for acquiring credentials via a service based cache ? > there are two existing implementations in Heimdal Kerberos and the > RedHat SSSD. As it stands now, supporting KCM for Java processes means > running them inside a ?kstart? shell which copies a KCM cache to a file > ccache for the process to use initially. This is an unergonomic > approach that we would like to avoid, as it?s a source of errors in our > environment. > > The patch generalizes the Mac support to include Linux ? the C code (ref > src/java.security.jgss/macosx/native/libosxkrb5/nativeccache.c) required > here is identical to the Mac version other than the header files (and > includes a bug fix to avoid a segfault caused by a null pointer deref, > which I suspect is a dormant bug on MacOSX too). The only other > required changes are in the Java code which loads the relevant libraries > and calls them, in both cases these are just changes to an existing > conditional. > > I?d be interested in feedback, and had some questions about how to > approach the shared nature of the code between MacOSX and Linux based on > the options I?ve tried here: > > * Option 1: duplicate the code, fix the headers and build a separate > Linux shared object. This has the disadvantage of a lot of > duplicated code, but keeps each platform?s libraries separate/distinct. > * Option 2: build a common shared object on both MacOSX and Linux for > the nativeccache functionality, using pre-processor directives to > select the correct set of header files for each platform. This has > the advantage of a smaller patch (lines of code), but introduces a > (no-op) change on MacOSX as a result. MacOSX has one additional > source file (SCDynamicStoreConfig) compiled into the library that > Linux does not have. > > The draft code for option 2 can be found at https://github.com/nrhall/ > jdk/commit/7b57a48afff77ef80dbb6cd947bd0d0581c439c1 nrhall/jdk/commit/7b57a48afff77ef80dbb6cd947bd0d0581c439c1> (note that > the GH Actions jobs currently fail on Linux because the runner needs to > have at least libkrb5-dev installed, and that changes to autoconf/ > dependencies will be needed to ensure these libs/headers are installed > at compile time at least ? with some careful handling at library load > time to handle the error if not). > > If there?s interest in pursuing this, I?d be happy to raise a PR - > please let me know if there are any questions! > > Thanks, > > Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.org Thu Feb 6 14:39:12 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 6 Feb 2025 14:39:12 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 12:39:45 GMT, Konanki Sreenath wrote: > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. I'm wondering how necessary this fix is. These are internal classes, only called inside JDK, where some pre-conditions are always met. Unless someone explicitly calls `x509Certimpl.getInfo().setExtensions(null)` (as done in the test), it seems like both the `info` and `extensions` fields should never be null. If you?re concerned about misuse of these methods leading to potential future issues, consider adding comments to clarify their expected usage. You could also include `assert` statements or `Objects.requireNonNull` calls to enforce these preconditions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2640005099 From coffeys at openjdk.org Thu Feb 6 15:13:10 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 6 Feb 2025 15:13:10 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 12:39:45 GMT, Konanki Sreenath wrote: > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. LGTM ------------- Marked as reviewed by coffeys (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23315#pullrequestreview-2598972284 From mdonovan at openjdk.org Thu Feb 6 15:27:15 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 6 Feb 2025 15:27:15 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid [v2] In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 18:50:25 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: > > Apply suggestions from cr > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 50: > 48: public static final String CLOSE_THE_SSL_CONNECTION_PASSIVE = "close the SSL connection (passive)"; > 49: > 50: static Map cookies; These two fields, Map and ServerSocket, don't look like they're used anywhere. They could be deleted. test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 225: > 223: System.setProperty("javax.net.ssl.trustStorePassword", passwd); > 224: > 225: System.setProperty("javax.net.debug", "all"); Is this printing a lot of stuff to the logs? Why did you remove the `if (debug)`? test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 241: > 239: // this will allow the error stream to be printed in case of an exception inside for debugging purposes > 240: System.setErr(originalErr); > 241: if (debug) { This field is hard-coded to false which requires rebuilding to turn it on. I have been changing that to: `static boolean debug = Boolean.getBoolean("test.debug");` So it can be turned on with a system property. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1944913967 PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1944909916 PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1944908477 From duke at openjdk.org Thu Feb 6 15:39:12 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Thu, 6 Feb 2025 15:39:12 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid [v2] In-Reply-To: References: Message-ID: <1VP_yWcakV5dg0gGfVKMJbESZoPeFnzzZB4FzZpyCGE=.3df3fcdd-bbfb-4fb7-aa81-d404c4c6b95e@github.com> On Thu, 6 Feb 2025 15:16:30 GMT, Matthew Donovan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply suggestions from cr >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 225: > >> 223: System.setProperty("javax.net.ssl.trustStorePassword", passwd); >> 224: >> 225: System.setProperty("javax.net.debug", "all"); > > Is this printing a lot of stuff to the logs? Why did you remove the `if (debug)`? Parsing it below, so now its necessary ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1944945331 From duke at openjdk.org Thu Feb 6 15:46:14 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Thu, 6 Feb 2025 15:46:14 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid [v2] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 15:18:40 GMT, Matthew Donovan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply suggestions from cr >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 50: > >> 48: public static final String CLOSE_THE_SSL_CONNECTION_PASSIVE = "close the SSL connection (passive)"; >> 49: >> 50: static Map cookies; > > These two fields, Map and ServerSocket, don't look like they're used anywhere. They could be deleted. Agree, done in the next commit > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 241: > >> 239: // this will allow the error stream to be printed in case of an exception inside for debugging purposes >> 240: System.setErr(originalErr); >> 241: if (debug) { > > This field is hard-coded to false which requires rebuilding to turn it on. I have been changing that to: > > `static boolean debug = Boolean.getBoolean("test.debug");` > > So it can be turned on with a system property. Agree, done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1944957029 PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r1944956832 From duke at openjdk.org Thu Feb 6 15:54:47 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Thu, 6 Feb 2025 15:54:47 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid [v3] In-Reply-To: References: Message-ID: > * 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23469/files - new: https://git.openjdk.org/jdk/pull/23469/files/5e300681..68c52a37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23469&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23469&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23469.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23469/head:pull/23469 PR: https://git.openjdk.org/jdk/pull/23469 From fguallini at openjdk.org Thu Feb 6 16:58:11 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Thu, 6 Feb 2025 16:58:11 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 12:12:35 GMT, Mikhail Yankelevich wrote: > * ./util/Pem/encoding.sh is now a java test > * also added the validations for the test results, not only an error check test/jdk/sun/security/util/Pem/PemEncoding.java line 47: > 45: File.separator, > 46: File.separator, > 47: File.separator); nit: the following may be easier to read Suggestion: final var certPath = Path.of(System.getProperty("test.src", ".")) .getParent() .resolve("HostnameChecker") .resolve("cert5.crt"); test/jdk/sun/security/util/Pem/PemEncoding.java line 58: > 56: final var subProcessOutput = result.getStdout(); > 57: final var subProcessErr = result.getStderr(); > 58: System.out.printf("Output:\n%s%n", subProcessOutput); No need to print the output here, JTreg automatically creates a .log file in the scratch directory with the subprocess stderr and stdout for debugging test/jdk/sun/security/util/Pem/PemEncoding.java line 72: > 70: // Some systems may automatically convert non-ASCII to ? > 71: // so this will detect the signature in all possible scenarios > 72: final var isUTF16Used = matcher.find() || subProcessOutput.contains("??: ?"); IMO, this is confusing. **isUTF16Used** seems misleading, as it actually checks for non-ASCII characters in the output, and it does not confirm that UTF-16 was used. If the goal is to double-check the default file encoding in the subprocess, instead I would simply add a verification in PemEncodingTest: if (!"UTF-16".equals(Charset.defaultCharset().displayName())) { throw new RuntimeException("File encoding is not UTF-16"); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1944946184 PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1944964050 PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1945089066 From kdriver at openjdk.org Thu Feb 6 17:14:28 2025 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 6 Feb 2025 17:14:28 GMT Subject: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v14] In-Reply-To: <7wCfQrs53w7KWE6l-T_WxnNVMt3l4W6LuY-s0zwJprU=.44a999d7-184f-487c-b076-97e717d51af4@github.com> References: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> <7wCfQrs53w7KWE6l-T_WxnNVMt3l4W6LuY-s0zwJprU=.44a999d7-184f-487c-b076-97e717d51af4@github.com> Message-ID: <-qo_jbk9rJ7MXWVpOyfabnnl34bVoSkY7yOnEvcJOeA=.a3ca9834-8756-48f4-81f0-e123d175d0b8@github.com> On Wed, 5 Feb 2025 23:06:54 GMT, Martin Balao wrote: >> We would like to propose an implementation of the HKDF algorithms for SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key Derivation Function API (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)). >> >> This implementation will be under the _Preview_ umbrella until the KDF API becomes stable in a future JDK release. The benefit of this early proposal is to gather more feedback about the KDF API for future improvements. >> >> The `P11KDF` class has the core implementation and Java calls to the PKCS 11 API. Different native mechanism were used to merge key material: CKM_CONCATENATE_BASE_AND_DATA (key and data), CKM_CONCATENATE_BASE_AND_KEY (key and key) and CKM_CONCATENATE_DATA_AND_BASE (data and key). The implementation also supports merging data with data, at the Java level. List of HKDF algorithms supported: HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512. >> >> Derivation modes supported: extract, expand, and, extract-expand. >> >> We further advanced the consolidation of algorithm and key info in the P11SecretKeyFactory map ?this effort started with the PBE support enhancement and has helped to avoid duplication?. The map has now information about HMAC (`HMACKeyInfo` class) and HKDF (`HKDFKeyInfo` class) algorithms. P11Mac is now aligned to take the information from the map. >> >> Generic keys now supported in SecretKeyFactory. Derived keys could be Generic. >> >> Testing >> >> * [TestHKDF.java](https://github.com/openjdk/jdk/blob/e87ec99b90ff742f531a5031fdeeb9f2e039856d/test/jdk/sun/security/pkcs11/KDF/TestHKDF.java) test added >> * All non-SHA1 & non-SHA224 RFC 5869 test vectors checked >> * Cross-checking against SunJCE's HKDF implementation for every algorithm possible >> * Static assertion data for resilience if SunJCE were not available >> * Use of derived key for encryption check >> * Concatenation of input key material and salt checked (multiple combinations) >> * Multiple derivation types checked (extract only, expand only, and, extract-expand) >> * Derive key and derive data checked >> * All supported HKDF algorithms tested (HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512) >> * DH and ECDH key derivation for TLS checked >> * Informative output for debugging purposes (shown automatically if there is a test failure) >> * Note: test failures do not prevent all tests for running >> * Test integrated to the SunPKCS11 tests framework >> >> * No regressions observed in jdk/sun/security/pkcs11 (114 tests pa... > > Martin Balao 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 14 additional commits since the last revision: > > - Merge openjdk/master into JDK-8328119 > > Fix trivial copyright conflict in: > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java > - Align behaviour with the CSR > > Make a PKCS #11 library supporting only CKM_HKDF_DERIVE or CKM_HKDF_DATA > to also register the HKDF algorithms. Notice that the corresponding HMAC > mechanism is still required. In case only one of the mechanisms is > available, KDF::deriveKey or KDF::deriveData will fail at run time. > > If the user disables one of CKM_HKDF_DERIVE or CKM_HKDF_DATA through > sun.security.pkcs11.Config, also refrain from using it. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Add test case with empty inputs > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Improve TestContext note about expectedOpOut > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Renaming of P11KDF fix. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Minor changes based on review. Copyright date adjustments. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Check disabled PKCS #11 mechanisms when concatenating keys and data. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Support for HKDF-SHA1 and HKDF-SHA224 removed. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Unused import removed. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Fix NPE in assertion. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - ... and 4 more: https://git.openjdk.org/jdk/compare/c54e0e0f...d018b4a9 Marked as reviewed by kdriver (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22215#pullrequestreview-2599380815 From duke at openjdk.org Thu Feb 6 18:11:30 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Thu, 6 Feb 2025 18:11:30 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v2] In-Reply-To: References: Message-ID: > * ./util/Pem/encoding.sh is now a java test > * also added the validations for the test results, not only an error check Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: changes to improve readability and removal of unneded System.out.print ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23492/files - new: https://git.openjdk.org/jdk/pull/23492/files/2f524826..88c4b729 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23492&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23492&range=00-01 Stats: 32 lines in 1 file changed: 6 ins; 21 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23492/head:pull/23492 PR: https://git.openjdk.org/jdk/pull/23492 From duke at openjdk.org Thu Feb 6 18:11:31 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Thu, 6 Feb 2025 18:11:31 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v2] In-Reply-To: References: Message-ID: <2XQiIG6tiII9lvU043h_Ssav0640hQrpOAtRc-pvBoY=.126b4360-b069-4652-9063-19a7e9c835ca@github.com> On Thu, 6 Feb 2025 15:36:48 GMT, Fernando Guallini wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> changes to improve readability and removal of unneded System.out.print > > test/jdk/sun/security/util/Pem/PemEncoding.java line 47: > >> 45: File.separator, >> 46: File.separator, >> 47: File.separator); > > nit: the following may be easier to read > > Suggestion: > > final var certPath = Path.of(System.getProperty("test.src", ".")) > .getParent() > .resolve("HostnameChecker") > .resolve("cert5.crt"); agree, done in the next commit > test/jdk/sun/security/util/Pem/PemEncoding.java line 58: > >> 56: final var subProcessOutput = result.getStdout(); >> 57: final var subProcessErr = result.getStderr(); >> 58: System.out.printf("Output:\n%s%n", subProcessOutput); > > No need to print the output here, JTreg automatically creates a .log file in the scratch directory with the subprocess stderr and stdout for debugging removed all of the output analysis in the next commit, as the change you've mentioned below will do this in a more neat way imo > test/jdk/sun/security/util/Pem/PemEncoding.java line 72: > >> 70: // Some systems may automatically convert non-ASCII to ? >> 71: // so this will detect the signature in all possible scenarios >> 72: final var isUTF16Used = matcher.find() || subProcessOutput.contains("??: ?"); > > IMO, this is confusing. **isUTF16Used** seems misleading, as it actually checks for non-ASCII characters in the output, and it does not confirm that UTF-16 was used. > > If the goal is to double-check the default file encoding in the subprocess, instead I would simply add a verification in PemEncodingTest: > > > if (!"UTF-16".equals(Charset.defaultCharset().displayName())) { > throw new RuntimeException("File encoding is not UTF-16"); > } done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1945199033 PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1945199414 PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1945199205 From duke at openjdk.org Thu Feb 6 18:47:54 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 6 Feb 2025 18:47:54 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: > By using the aarch64 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: Adding comments + some code reorganization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23300/files - new: https://git.openjdk.org/jdk/pull/23300/files/9f7c4a23..9a3a9444 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=03-04 Stats: 447 lines in 3 files changed: 140 ins; 247 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/23300.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23300/head:pull/23300 PR: https://git.openjdk.org/jdk/pull/23300 From abarashev at openjdk.org Thu Feb 6 19:14:15 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 6 Feb 2025 19:14:15 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 19:42:24 GMT, Bradford Wetmore wrote: >> Update and clarify the sample code. >> >> Docs only, no additional testing other than verifying javadoc is correctly output. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Codereview Comments src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 666: > 664: * byte[] bytes = HUK_UN_I.getBytes(StandardCharsets.UTF_8); > 665: * > 666: * // Preserve network byte order by using ISO_8859_1 encoding I find `network byte order` wording rather confusing, everything here is big-endian, but I guess that's not what we really mean by that, we really care about encoding. I would just put `Convert to the default ALPN encoding` comment here. src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 668: > 666: * // Preserve network byte order by using ISO_8859_1 encoding > 667: * String encodedHukUnI = > 668: * new String(bytes, StandardCharsets.ISO_8859_1); `ISO_8859_1` is the default ALPN encoding but it can be modified by setting `jdk.tls.alpnCharset` system property. We don't mention it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1945281873 PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1945279174 From wetmore at openjdk.org Thu Feb 6 19:26:11 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 6 Feb 2025 19:26:11 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:10:04 GMT, Artur Barashev wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Codereview Comments > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 666: > >> 664: * byte[] bytes = HUK_UN_I.getBytes(StandardCharsets.UTF_8); >> 665: * >> 666: * // Preserve network byte order by using ISO_8859_1 encoding > > I find `network byte order` wording rather confusing, everything here is big-endian, but I guess that's not what we really mean by that, we really care about encoding. I would just put `Convert to the default ALPN encoding` comment here. RFC 7301 says: o Identification Sequence: The precise set of octet values that identifies the protocol. This could be the UTF-8 encoding [[RFC3629](https://datatracker.ietf.org/doc/html/rfc3629)] of the protocol name. I'll change to `octet byte ordering`. > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 668: > >> 666: * // Preserve network byte order by using ISO_8859_1 encoding >> 667: * String encodedHukUnI = >> 668: * new String(bytes, StandardCharsets.ISO_8859_1); > > `ISO_8859_1` is the default ALPN encoding but it can be modified by setting `jdk.tls.alpnCharset` system property. We don't mention it. We usually don't mention the various properties in the javadoc specifications, but [we do in the documentation](https://docs.oracle.com/en/java/javase/23/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-05DB7FDA-2FAE-457D-AF7A-6B22E2A6402E). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1945298176 PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1945295071 From wetmore at openjdk.org Thu Feb 6 19:31:24 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 6 Feb 2025 19:31:24 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v4] In-Reply-To: References: Message-ID: > Update and clarify the sample code. > > Docs only, no additional testing other than verifying javadoc is correctly output. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: minor wording tweak ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23379/files - new: https://git.openjdk.org/jdk/pull/23379/files/61345a63..7a90be85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23379&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23379&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23379.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23379/head:pull/23379 PR: https://git.openjdk.org/jdk/pull/23379 From abarashev at openjdk.org Thu Feb 6 19:38:10 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 6 Feb 2025 19:38:10 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:23:55 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 666: >> >>> 664: * byte[] bytes = HUK_UN_I.getBytes(StandardCharsets.UTF_8); >>> 665: * >>> 666: * // Preserve network byte order by using ISO_8859_1 encoding >> >> I find `network byte order` wording rather confusing, everything here is big-endian, but I guess that's not what we really mean by that, we really care about encoding. I would just put `Convert to the default ALPN encoding` comment here. > > RFC 7301 says: > > o Identification Sequence: The precise set of octet values that > identifies the protocol. This could be the UTF-8 encoding > [[RFC3629](https://datatracker.ietf.org/doc/html/rfc3629)] of the protocol name. > > I'll change to `octet byte ordering`. I still think that `Convert to the default ALPN encoding` comment is less confusing, we are just passing the string in the encoding that the library expects. Basically your comment assumes reader's familiarity with the RFC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1945315387 From abarashev at openjdk.org Thu Feb 6 19:50:11 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 6 Feb 2025 19:50:11 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:35:22 GMT, Artur Barashev wrote: >> RFC 7301 says: >> >> o Identification Sequence: The precise set of octet values that >> identifies the protocol. This could be the UTF-8 encoding >> [[RFC3629](https://datatracker.ietf.org/doc/html/rfc3629)] of the protocol name. >> >> I'll change to `octet byte ordering`. > > I still think that `Convert to the default ALPN encoding` comment is less confusing, we are just passing the string in the encoding that the library expects. Basically your comment assumes reader's familiarity with the RFC. `Convert UTF-8 bytes to the string with default ALPN encoding` also sounds like an option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1945330434 From dfuchs at openjdk.org Thu Feb 6 21:24:16 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 6 Feb 2025 21:24:16 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:47:54 GMT, Artur Barashev wrote: >> I still think that `Convert to the default ALPN encoding` comment is less confusing, we are just passing the string in the encoding that the library expects. Basically your comment assumes reader's familiarity with the RFC. > > `Convert UTF-8 bytes to the string with default ALPN encoding` also sounds like an option. But we're not converting anything. What we do here is preserving the bytes encoded in UTF-8 by shoe-horning them into a string so that we get the same UTF-8 encoded bytes when the stack later calls String.getBytes("ISO_8859_1"). So "convert" would be misleading. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1945478698 From abarashev at openjdk.org Thu Feb 6 21:40:11 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 6 Feb 2025 21:40:11 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 21:21:36 GMT, Daniel Fuchs wrote: >> `Convert UTF-8 bytes to the string with default ALPN encoding` also sounds like an option. > > But we're not converting anything. > What we do here is preserving the bytes encoded in UTF-8 by shoe-horning them into a string so that we get the same UTF-8 encoded bytes when the stack later calls String.getBytes("ISO_8859_1"). > So "convert" would be misleading. Yes, that's what we do. What I meant is that we are converting data types, not the data itself: we are converting UTF-8 bytes into the string with the encoding expected by the library. I guess it will be confusing either way for anyone not familiar with encodings, so I'm fine if Brad wants to keep `octet byte ordering`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23379#discussion_r1945500174 From abarashev at openjdk.org Thu Feb 6 21:47:17 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 6 Feb 2025 21:47:17 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v4] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:31:24 GMT, Bradford Wetmore wrote: >> Update and clarify the sample code. >> >> Docs only, no additional testing other than verifying javadoc is correctly output. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > minor wording tweak LGTM ------------- Marked as reviewed by abarashev (Author). PR Review: https://git.openjdk.org/jdk/pull/23379#pullrequestreview-2600055805 From valeriep at openjdk.org Thu Feb 6 23:02:11 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 6 Feb 2025 23:02:11 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: Message-ID: <1KV2-cSXW9fcPvh5d-1GG2RhY2BIGSB_0q7XnXm5E5A=.7eff7367-18d7-4090-8801-1f0017ac379b@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 src/java.base/share/classes/sun/security/util/KnownOIDs.java line 452: > 450: } > 451: // only register the stdName and aliases if o.registerNames > 452: // returns true nit: "return" should be "is" since it's a field now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23411#discussion_r1945590419 From valeriep at openjdk.org Thu Feb 6 23:05:10 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 6 Feb 2025 23:05:10 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: Message-ID: 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 src/java.base/share/classes/sun/security/util/KnownOIDs.java line 486: > 484: this.oid = oid; > 485: this.stdName = stdName; > 486: this.registerNames = true; nit: can you initialize the fields in the same order for all the constructors? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23411#discussion_r1945592387 From duke at openjdk.org Thu Feb 6 23:48:18 2025 From: duke at openjdk.org (Johannes Graham) Date: Thu, 6 Feb 2025 23:48:18 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: <9qRdcyrkrFZ1vOa0ffS0kf5ED620fKCK4Iuo1fGt99Q=.f9515948-e003-46c7-9678-c88ac98d6fcc@github.com> Message-ID: On Wed, 5 Feb 2025 16:29:24 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/sun/security/util/KnownOIDs.java line 494: >> >>> 492: this.stdName = stdName; >>> 493: this.registerNames = registerNames; >>> 494: this.aliases = new String[0]; >> >> Unless this String[] needs to be unique, it would be sufficient to use the same empty array everywhere. > > you are right, but accessing static field from enum constructor is not allowed You could define the static field on another class, like SecurityConstants, and then use it in the enum constructor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23411#discussion_r1945623744 From fguallini at openjdk.org Fri Feb 7 00:34:13 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 7 Feb 2025 00:34:13 GMT Subject: Integrated: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings In-Reply-To: References: Message-ID: On Wed, 5 Feb 2025 12:53:09 GMT, Fernando Guallini wrote: > When compiling the test class: jdk/test/lib/security/timestamp/TsaServer.java > > > Two warning are shown: > > > test/lib/security/timestamp/TsaServer.java:56: warning: [this-escape] possible 'this' escape before subclass is fully initialized > setHandler(handler); > > - setHandler is called in the constructor and a subclass may override it. It is fixed by making the method 'final' > > > test/lib/security/timestamp/TsaServer.java:42: warning: [try] auto-closeable resource TsaServer has a member method close() that could throw InterruptedException > > - Remove `throws Exception` from TsaServer.close() This pull request has now been integrated. Changeset: 1eb54e42 Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.org/jdk/commit/1eb54e4228ba9319ac2f980055ed366dd861ec0b Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings Reviewed-by: weijun, rhalade, hchao, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/23463 From valeriep at openjdk.org Fri Feb 7 02:03:58 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 7 Feb 2025 02:03:58 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: <6khizncuzjbXtuD0HkQrFfh3j6KpRfHHPb504b7A1v8=.8b4c2296-d00a-4a2e-85b7-1f2fab76142a@github.com> References: <6khizncuzjbXtuD0HkQrFfh3j6KpRfHHPb504b7A1v8=.8b4c2296-d00a-4a2e-85b7-1f2fab76142a@github.com> Message-ID: On Wed, 5 Feb 2025 16:41:10 GMT, Shaojin Wen wrote: > The reproducer you provided doesn't try to load KnownOIDs on my machine. What am I missing? > > Other than that, the change looks reasonable to me. Me neither and I'm using linux. Are you sure the Startup.java is right? Just curious, do you have a percentage on how much performance difference you observe with this? How about differences in memory usage, is there any? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23411#issuecomment-2641732504 From fguallini at openjdk.org Fri Feb 7 10:53:10 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 7 Feb 2025 10:53:10 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v2] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 18:11:30 GMT, Mikhail Yankelevich wrote: >> * ./util/Pem/encoding.sh is now a java test >> * also added the validations for the test results, not only an error check > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > changes to improve readability and removal of unneded System.out.print LGTM ------------- PR Review: https://git.openjdk.org/jdk/pull/23492#pullrequestreview-2601422214 From weijun at openjdk.org Fri Feb 7 12:55:17 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 7 Feb 2025 12:55:17 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v2] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 18:11:30 GMT, Mikhail Yankelevich wrote: >> * ./util/Pem/encoding.sh is now a java test >> * also added the validations for the test results, not only an error check > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > changes to improve readability and removal of unneded System.out.print Thanks. The updated test runs fine. Out of curiosity, I append `.reportDiagnosticSummary()` to the last line in `main` and see the output string contains garbaged characters. It looks like although the original fix made it possible to read in a PEM certificate with such a default encoding, it had not fixed the `toString` part of the certificate. Can you try to fix it as well? It could be another bug since this one is only about the test. test/jdk/sun/security/util/Pem/PemEncoding.java line 29: > 27: * @summary BASE64 encoded cert not correctly parsed with UTF-16 > 28: * @library /test/lib > 29: * @run main/othervm PemEncoding Why is `othervm` required? The test launches a sub-process and this VM is not polluted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23492#issuecomment-2642831602 PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1946482071 From duke at openjdk.org Fri Feb 7 13:23:10 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Fri, 7 Feb 2025 13:23:10 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v2] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 12:52:45 GMT, Weijun Wang wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> changes to improve readability and removal of unneded System.out.print > > test/jdk/sun/security/util/Pem/PemEncoding.java line 29: > >> 27: * @summary BASE64 encoded cert not correctly parsed with UTF-16 >> 28: * @library /test/lib >> 29: * @run main/othervm PemEncoding > > Why is `othervm` required? The test launches a sub-process and this VM is not polluted. Agree, this is not needed. Will be changed in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1946516119 From duke at openjdk.org Fri Feb 7 13:39:11 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Fri, 7 Feb 2025 13:39:11 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v2] In-Reply-To: References: Message-ID: <-e7a7JushBV1BGjgKtVGAaPG6IywFEfibtJkpETgcnc=.3009803e-4c6c-483a-b201-48fb0b56a105@github.com> On Fri, 7 Feb 2025 12:51:36 GMT, Weijun Wang wrote: > Thanks. The updated test runs fine. > > Out of curiosity, I append `.reportDiagnosticSummary()` to the last line in `main` and see the output string contains garbaged characters. It looks like although the original fix made it possible to read in a PEM certificate with such a default encoding, it had not fixed the `toString` part of the certificate. Can you try to fix it as well? It could be another bug since this one is only about the test. created a new product bug for this [JDK-8349664](https://bugs.openjdk.org/browse/JDK-8349664) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23492#issuecomment-2642971120 From duke at openjdk.org Fri Feb 7 13:42:50 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Fri, 7 Feb 2025 13:42:50 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v3] In-Reply-To: References: Message-ID: > * ./util/Pem/encoding.sh is now a java test > * also added the validations for the test results, not only an error check Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: removed othervm ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23492/files - new: https://git.openjdk.org/jdk/pull/23492/files/88c4b729..0d142e54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23492&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23492&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23492/head:pull/23492 PR: https://git.openjdk.org/jdk/pull/23492 From weijun at openjdk.org Fri Feb 7 13:53:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 7 Feb 2025 13:53:11 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v3] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 13:42:50 GMT, Mikhail Yankelevich wrote: >> * ./util/Pem/encoding.sh is now a java test >> * also added the validations for the test results, not only an error check > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > removed othervm test/jdk/sun/security/util/Pem/PemEncoding.java line 29: > 27: * @summary BASE64 encoded cert not correctly parsed with UTF-16 > 28: * @library /test/lib > 29: * @run main PemEncoding The `@run` line is no longer needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1946555585 From duke at openjdk.org Fri Feb 7 14:14:26 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Fri, 7 Feb 2025 14:14:26 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v4] In-Reply-To: References: Message-ID: > * ./util/Pem/encoding.sh is now a java test > * also added the validations for the test results, not only an error check Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: removed run line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23492/files - new: https://git.openjdk.org/jdk/pull/23492/files/0d142e54..9989db6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23492&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23492&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23492/head:pull/23492 PR: https://git.openjdk.org/jdk/pull/23492 From duke at openjdk.org Fri Feb 7 14:14:26 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Fri, 7 Feb 2025 14:14:26 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v3] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 13:50:37 GMT, Weijun Wang wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> removed othervm > > test/jdk/sun/security/util/Pem/PemEncoding.java line 29: > >> 27: * @summary BASE64 encoded cert not correctly parsed with UTF-16 >> 28: * @library /test/lib >> 29: * @run main PemEncoding > > The `@run` line is no longer needed. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23492#discussion_r1946588350 From weijun at openjdk.org Fri Feb 7 14:25:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 7 Feb 2025 14:25:11 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v4] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 14:14:26 GMT, Mikhail Yankelevich wrote: >> * ./util/Pem/encoding.sh is now a java test >> * also added the validations for the test results, not only an error check > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > removed run line Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23492#pullrequestreview-2601864259 From duke at openjdk.org Fri Feb 7 14:25:11 2025 From: duke at openjdk.org (duke) Date: Fri, 7 Feb 2025 14:25:11 GMT Subject: RFR: 8349532: Refactor ./util/Pem/encoding.sh to run in java [v4] In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 14:14:26 GMT, Mikhail Yankelevich wrote: >> * ./util/Pem/encoding.sh is now a java test >> * also added the validations for the test results, not only an error check > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > removed run line @myankelev Your change (at version 9989db6c21bee70976202cb2a55cf947bf59e461) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23492#issuecomment-2643071460 From mullan at openjdk.org Fri Feb 7 15:15:16 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 7 Feb 2025 15:15:16 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 14:36:29 GMT, Weijun Wang wrote: > I'm wondering how necessary this fix is. These are internal classes, only called inside JDK, where some pre-conditions are always met. Unless someone explicitly calls `x509Certimpl.getInfo().setExtensions(null)` (as done in the test), it seems like both the `info` and `extensions` fields should never be null. > > If you?re concerned about misuse of these methods leading to potential future issues, consider adding comments to clarify their expected usage. You could also include `assert` statements or `Objects.requireNonNull` calls to enforce these preconditions. I agree with Weijun. The `info` field should never be `null` under normal circumstances. Checking if it is `null` would only make sense if there is a bug somewhere else in the code, and in that case, the bug should be fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2643211271 From duke at openjdk.org Fri Feb 7 15:43:24 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Fri, 7 Feb 2025 15:43:24 GMT Subject: Integrated: 8349532: Refactor ./util/Pem/encoding.sh to run in java In-Reply-To: References: Message-ID: <7pivl5-rbRM_JN6MYRgVk9PTXfzDDMXtRPuDw_0XLEM=.ccde6037-8d65-4083-9e17-08985e14bc18@github.com> On Thu, 6 Feb 2025 12:12:35 GMT, Mikhail Yankelevich wrote: > * ./util/Pem/encoding.sh is now a java test > * also added the validations for the test results, not only an error check This pull request has now been integrated. Changeset: 7cd5cb29 Author: Mikhail Yankelevich Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/7cd5cb2916e8a62ec57c022a5fac19fb62b7c779 Stats: 74 lines in 2 files changed: 35 ins; 35 del; 4 mod 8349532: Refactor ./util/Pem/encoding.sh to run in java Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/23492 From jnimeh at openjdk.org Fri Feb 7 16:15:23 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 7 Feb 2025 16:15:23 GMT Subject: RFR: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified [v4] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 19:31:24 GMT, Bradford Wetmore wrote: >> Update and clarify the sample code. >> >> Docs only, no additional testing other than verifying javadoc is correctly output. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > minor wording tweak Marked as reviewed by jnimeh (Reviewer). The comment changes look good to me also. ------------- PR Review: https://git.openjdk.org/jdk/pull/23379#pullrequestreview-2602167697 PR Comment: https://git.openjdk.org/jdk/pull/23379#issuecomment-2643355946 From wetmore at openjdk.org Fri Feb 7 17:12:16 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 7 Feb 2025 17:12:16 GMT Subject: Integrated: 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 01:45:47 GMT, Bradford Wetmore wrote: > Update and clarify the sample code. > > Docs only, no additional testing other than verifying javadoc is correctly output. This pull request has now been integrated. Changeset: 88a84835 Author: Bradford Wetmore URL: https://git.openjdk.org/jdk/commit/88a84835a3a13f9adfcfa2ad034acff8fbc4fadc Stats: 17 lines in 1 file changed: 10 ins; 1 del; 6 mod 8349121: SSLParameters.setApplicationProtocols() ALPN example could be clarified Reviewed-by: abarashev, jnimeh, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/23379 From hchao at openjdk.org Fri Feb 7 17:13:17 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 7 Feb 2025 17:13:17 GMT Subject: RFR: 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore [v2] In-Reply-To: References: Message-ID: <7sYctf0rCw3RRnTIZMS7FFW0PmP6g3IRGSkAzX4CsRs=.8205b46e-8dcf-4ea7-b186-3b0f44d5f4af@github.com> On Thu, 6 Feb 2025 09:53:04 GMT, Fernando Guallini wrote: >> The test: **sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java** relies on the `certutil.exe` tool to import and delete certificates from a keystore. It was annotated with `@ignore` due to the uncertainty of `certutil.exe` being available on the instance where the test is executed. >> >> Rather than ignoring the test entirely, this PR updates the logic to throw a `SkippedException` if the tool is not found, ensuring the test runs when possible, and gracefully skipped otherwise. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright to 2025 Marked as reviewed by hchao (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21305#pullrequestreview-2602331316 From davide.malpassini at gmail.com Fri Feb 7 13:56:41 2025 From: davide.malpassini at gmail.com (Davide Malpassini) Date: Fri, 7 Feb 2025 14:56:41 +0100 Subject: PKCS #12 Support RFC 9579 Message-ID: Hi, RFC 9579 , that add another MAC algorithm to PKCS#12 compatible with FIPS 140-3, has been approved and openssl 3.4 , bouncy castle and future redhat 10 already supports it. I want to know the plan to support it and avoid ending with some p12 files that cannot be read by java nut from any other tool . Best regards Davide Malpassini -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Feb 7 18:49:57 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Feb 2025 13:49:57 -0500 Subject: PKCS #12 Support RFC 9579 In-Reply-To: References: Message-ID: <6cb8ca6b-9311-4c8b-ab47-c6a29972c992@oracle.com> Hi Davide, Yes, we are working on this and it is being tracked in this issue: https://bugs.openjdk.org/browse/JDK-8343232 Thanks, Sean On 2/7/25 8:56 AM, Davide Malpassini wrote: > Hi, > RFC 9579 , that add another MAC algorithm to PKCS#12 compatible with > FIPS 140-3, has been approved and openssl 3.4 , bouncy castle and future > redhat 10 already supports it. I want to know the plan to support it and > avoid ending?with some p12 files that cannot be read by java nut from > any other tool . > Best regards > Davide Malpassini From valeriep at openjdk.org Fri Feb 7 20:14:22 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 7 Feb 2025 20:14:22 GMT Subject: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v14] In-Reply-To: <7wCfQrs53w7KWE6l-T_WxnNVMt3l4W6LuY-s0zwJprU=.44a999d7-184f-487c-b076-97e717d51af4@github.com> References: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> <7wCfQrs53w7KWE6l-T_WxnNVMt3l4W6LuY-s0zwJprU=.44a999d7-184f-487c-b076-97e717d51af4@github.com> Message-ID: On Wed, 5 Feb 2025 23:06:54 GMT, Martin Balao wrote: >> We would like to propose an implementation of the HKDF algorithms for SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key Derivation Function API (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)). >> >> This implementation will be under the _Preview_ umbrella until the KDF API becomes stable in a future JDK release. The benefit of this early proposal is to gather more feedback about the KDF API for future improvements. >> >> The `P11KDF` class has the core implementation and Java calls to the PKCS 11 API. Different native mechanism were used to merge key material: CKM_CONCATENATE_BASE_AND_DATA (key and data), CKM_CONCATENATE_BASE_AND_KEY (key and key) and CKM_CONCATENATE_DATA_AND_BASE (data and key). The implementation also supports merging data with data, at the Java level. List of HKDF algorithms supported: HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512. >> >> Derivation modes supported: extract, expand, and, extract-expand. >> >> We further advanced the consolidation of algorithm and key info in the P11SecretKeyFactory map ?this effort started with the PBE support enhancement and has helped to avoid duplication?. The map has now information about HMAC (`HMACKeyInfo` class) and HKDF (`HKDFKeyInfo` class) algorithms. P11Mac is now aligned to take the information from the map. >> >> Generic keys now supported in SecretKeyFactory. Derived keys could be Generic. >> >> Testing >> >> * [TestHKDF.java](https://github.com/openjdk/jdk/blob/e87ec99b90ff742f531a5031fdeeb9f2e039856d/test/jdk/sun/security/pkcs11/KDF/TestHKDF.java) test added >> * All non-SHA1 & non-SHA224 RFC 5869 test vectors checked >> * Cross-checking against SunJCE's HKDF implementation for every algorithm possible >> * Static assertion data for resilience if SunJCE were not available >> * Use of derived key for encryption check >> * Concatenation of input key material and salt checked (multiple combinations) >> * Multiple derivation types checked (extract only, expand only, and, extract-expand) >> * Derive key and derive data checked >> * All supported HKDF algorithms tested (HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512) >> * DH and ECDH key derivation for TLS checked >> * Informative output for debugging purposes (shown automatically if there is a test failure) >> * Note: test failures do not prevent all tests for running >> * Test integrated to the SunPKCS11 tests framework >> >> * No regressions observed in jdk/sun/security/pkcs11 (114 tests pa... > > Martin Balao 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 14 additional commits since the last revision: > > - Merge openjdk/master into JDK-8328119 > > Fix trivial copyright conflict in: > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java > - Align behaviour with the CSR > > Make a PKCS #11 library supporting only CKM_HKDF_DERIVE or CKM_HKDF_DATA > to also register the HKDF algorithms. Notice that the corresponding HMAC > mechanism is still required. In case only one of the mechanisms is > available, KDF::deriveKey or KDF::deriveData will fail at run time. > > If the user disables one of CKM_HKDF_DERIVE or CKM_HKDF_DATA through > sun.security.pkcs11.Config, also refrain from using it. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Add test case with empty inputs > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Improve TestContext note about expectedOpOut > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Renaming of P11KDF fix. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Minor changes based on review. Copyright date adjustments. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Check disabled PKCS #11 mechanisms when concatenating keys and data. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Support for HKDF-SHA1 and HKDF-SHA224 removed. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Unused import removed. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Fix NPE in assertion. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - ... and 4 more: https://git.openjdk.org/jdk/compare/87467bc0...d018b4a9 Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22215#pullrequestreview-2602738817 From rhalade at openjdk.org Fri Feb 7 20:25:19 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 7 Feb 2025 20:25:19 GMT Subject: RFR: 8337723: Remove redundant tests from com/sun/security/sasl/gsskerb [v3] In-Reply-To: References: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> Message-ID: On Tue, 28 Jan 2025 19:25:07 GMT, Fernando Guallini wrote: >> There are 3 manual GSS-API/Kerberos tests that require a manual setup and were added to the problem list years ago: >> >> - com/sun/security/sasl/gsskerb/**AuthOnly**-> Verifies that both client and server have completed the authentication process. >> - com/sun/security/sasl/gsskerb/**NoSecurityLayer** -> Attempts to use wrap and unwrap to demonstrate that these operations should not be allowed without a negotiated security layer. >> - com/sun/security/sasl/gsskerb/**ConfSecurityLayer** -> Demonstrates the use of the security layer by wrapping and unwrapping messages on both client and server sides. >> >> These tests need manual setup of a KDC environment, service/user principals, keytabs, JAAS configuration, and script adjustments. All that is time consuming and error prone. These do not fail if configured properly. >> >> In contrast, the automated test sun/security/krb5/auto/**SaslBasic** already covers these scenarios and sets up the KDC with the necessary principals **automatically**, no manual setup is required. This class starts a simple KDC with one realm, several typical principal names, generates krb5.conf and keytab files, and setup a JAAS login config file. >> >> I've enhanced SaslBasic to include additional wrap/unwrap checks with and without a security layer. As a result, the 3 manual tests and their associated files are now redundand and can be removed, as they no longer provide additional value. > > Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into 8337723 > - Merge branch 'master' into 8337723 > - refactoring > - Merge branch 'master' into 8337723 > - remov gsskerb tests test/jdk/sun/security/krb5/auto/SaslBasic.java line 118: > 116: > 117: if (!Arrays.equals(hello, token)) { > 118: throw new Exception("Client message altered"); please update these final exceptions from test to `RuntimeException` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20464#discussion_r1947139288 From rhalade at openjdk.org Fri Feb 7 20:39:15 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 7 Feb 2025 20:39:15 GMT Subject: RFR: 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore [v2] In-Reply-To: References: Message-ID: <9Arooprsga0EOIQhW-weeOALdczD6OrmOx3LKyw4dk8=.d75a3fde-e647-439f-ba2a-a1709b4739d6@github.com> On Thu, 6 Feb 2025 09:53:04 GMT, Fernando Guallini wrote: >> The test: **sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java** relies on the `certutil.exe` tool to import and delete certificates from a keystore. It was annotated with `@ignore` due to the uncertainty of `certutil.exe` being available on the instance where the test is executed. >> >> Rather than ignoring the test entirely, this PR updates the logic to throw a `SkippedException` if the tool is not found, ensuring the test runs when possible, and gracefully skipped otherwise. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright to 2025 Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21305#pullrequestreview-2602776833 From rhalade at openjdk.org Fri Feb 7 21:02:10 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 7 Feb 2025 21:02:10 GMT Subject: RFR: 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: <3W8oXM7Q_0dMJ2ObHMIwEqSXTUaY5z-LzRb9c_yMCYM=.c645dde9-403e-4ed9-af85-1edd07392a24@github.com> 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.- Changes requested by rhalade (Reviewer). test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java line 95: > 93: System.out.println(e); > 94: } > 95: throw new SkippedException("Test skipped: failure during " + I think we should update test to fail if call to `initialize` fails with any other exception than `SkippedException` which is thrown from call to `initSecmod` if NSS library fails. So you can remove try-catch here. test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java line 99: > 97: } > 98: > 99: if (shouldRun()) { you can remove the check at line 114-116 which checks `sunPKCS11NSSProvider`. It is set by call to `initialize` and fails if PKCS11 provider is not found. Let `shouldRun` fail if call to `getInstance` fails with any other reason than `NoSuchAlgorithmException` ------------- PR Review: https://git.openjdk.org/jdk/pull/23177#pullrequestreview-2602811011 PR Review Comment: https://git.openjdk.org/jdk/pull/23177#discussion_r1947173323 PR Review Comment: https://git.openjdk.org/jdk/pull/23177#discussion_r1947186406 From lmesnik at openjdk.org Fri Feb 7 21:20:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Feb 2025 21:20:41 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary Message-ID: The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. ------------- Commit messages: - 8346050: Update BuildTestLib.gmk to build whole testlibrary Changes: https://git.openjdk.org/jdk/pull/23525/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23525&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346050 Stats: 20 lines in 5 files changed: 14 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23525/head:pull/23525 PR: https://git.openjdk.org/jdk/pull/23525 From valeriep at openjdk.org Fri Feb 7 22:24:22 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 7 Feb 2025 22:24:22 GMT Subject: RFR: 8348432: Use block size as the default Hmac key length for JDK providers Message-ID: <69YqQmCsaap5PDO88Iju4_MEu3Tj5kOo_2uBVFdhCII=.3ea510be-9397-4adb-bb24-e6bf5e7a51d7@github.com> 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 ------------- Commit messages: - 8348432: Use block size as the default Hmac key length for JDK providers Changes: https://git.openjdk.org/jdk/pull/23526/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23526&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348432 Stats: 113 lines in 4 files changed: 49 ins; 10 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/23526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23526/head:pull/23526 PR: https://git.openjdk.org/jdk/pull/23526 From erikj at openjdk.org Sat Feb 8 00:11:14 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Sat, 8 Feb 2025 00:11:14 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 21:15:36 GMT, Leonid Mesnik wrote: > The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. make/test/BuildTestLib.gmk line 61: > 59: > 60: ifeq ($(call isTargetOs, linux), false) > 61: EXCLUDE_DIRS := jdk/test/lib/containers Suggestion: EXCLUDE_DIRS := jdk/test/lib/containers ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1947340369 From lmesnik at openjdk.org Sat Feb 8 05:01:03 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 8 Feb 2025 05:01:03 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v2] In-Reply-To: References: Message-ID: > The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Update make/test/BuildTestLib.gmk Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23525/files - new: https://git.openjdk.org/jdk/pull/23525/files/8afdb494..fad9ad2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23525&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23525&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23525/head:pull/23525 PR: https://git.openjdk.org/jdk/pull/23525 From swen at openjdk.org Sat Feb 8 08:47:09 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 8 Feb 2025 08:47:09 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: <9qRdcyrkrFZ1vOa0ffS0kf5ED620fKCK4Iuo1fGt99Q=.f9515948-e003-46c7-9678-c88ac98d6fcc@github.com> Message-ID: On Thu, 6 Feb 2025 23:45:57 GMT, Johannes Graham wrote: >> you are right, but accessing static field from enum constructor is not allowed > > You could define the static field on another class, like SecurityConstants, and then use it in the enum constructor. Creating a new empty string array every time is the original behavior, which has nothing to do with the purpose of this PR. Should we follow the principle of minimal changes? If we want to change it, we should submit another PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23411#discussion_r1947544944 From swen at openjdk.org Sat Feb 8 09:29:09 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 8 Feb 2025 09:29:09 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: <6khizncuzjbXtuD0HkQrFfh3j6KpRfHHPb504b7A1v8=.8b4c2296-d00a-4a2e-85b7-1f2fab76142a@github.com> Message-ID: <7xRghGPDJJfAL9SN13lILnPY_pZQE375vsxIJjMKt7U=.1a624bdd-93e3-4876-a8f3-3485a3437bcd@github.com> On Fri, 7 Feb 2025 01:46:03 GMT, Valerie Peng wrote: > > The reproducer you provided doesn't try to load KnownOIDs on my machine. What am I missing? > > Other than that, the change looks reasonable to me. > > Me neither and I'm using linux. Are you sure the Startup.java is right? Just curious, do you have a percentage on how much performance difference you observe with this? How about differences in memory usage, is there any? You are right. Class KnownOIDs are loaded during startup because it is started in IntelliJ IDE and there is an agent. git/jdk/build/macosx-aarch64-server-fastdebug/images/jdk/bin/java -verbose:class -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=58735:/Applications/IntelliJ IDEA.app/Contents/bin Therefore, this is not a problem with the default JVM startup parameters, but a problem with the Agent scenario. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23411#issuecomment-2644744352 From jnimeh at openjdk.org Sat Feb 8 16:31:00 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Sat, 8 Feb 2025 16:31:00 GMT Subject: RFR: 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree Message-ID: This takes a few test classes and moves them away from their current location in `test/jdk/java/security/testlibrary` to `test/lib/jdk/test/lib/security`, grouping them together with many other existing test utility classes. It also changes the dependent security tests to point at the new locations for these classes, as needed. ------------- Commit messages: - 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree Changes: https://git.openjdk.org/jdk/pull/23531/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23531&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349501 Stats: 146 lines in 38 files changed: 32 ins; 29 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/23531.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23531/head:pull/23531 PR: https://git.openjdk.org/jdk/pull/23531 From weijun at openjdk.org Sat Feb 8 17:19:09 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 8 Feb 2025 17:19:09 GMT Subject: RFR: 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree In-Reply-To: References: Message-ID: On Sat, 8 Feb 2025 16:23:59 GMT, Jamil Nimeh wrote: > This takes a few test classes and moves them away from their current location in `test/jdk/java/security/testlibrary` to `test/lib/jdk/test/lib/security`, grouping them together with many other existing test utility classes. It also changes the dependent security tests to point at the new locations for these classes, as needed. Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23531#pullrequestreview-2603962069 From rhalade at openjdk.org Sun Feb 9 02:23:16 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Sun, 9 Feb 2025 02:23:16 GMT Subject: RFR: 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree In-Reply-To: References: Message-ID: On Sat, 8 Feb 2025 16:23:59 GMT, Jamil Nimeh wrote: > This takes a few test classes and moves them away from their current location in `test/jdk/java/security/testlibrary` to `test/lib/jdk/test/lib/security`, grouping them together with many other existing test utility classes. It also changes the dependent security tests to point at the new locations for these classes, as needed. Following 4 tests also need to be updated: `open/test/jdk/sun/security/tools/keytool/NssTest.java open/test/jdk/sun/security/pkcs11/ec/TestECDSA2.java open/test/jdk/sun/security/pkcs11/ec/TestECDH2.java open/test/jdk/java/security/Provider/GetServiceRace.java` ------------- Changes requested by rhalade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23531#pullrequestreview-2604100103 From jnimeh at openjdk.org Sun Feb 9 05:32:10 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Sun, 9 Feb 2025 05:32:10 GMT Subject: RFR: 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree [v2] In-Reply-To: References: Message-ID: > This takes a few test classes and moves them away from their current location in `test/jdk/java/security/testlibrary` to `test/lib/jdk/test/lib/security`, grouping them together with many other existing test utility classes. It also changes the dependent security tests to point at the new locations for these classes, as needed. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded testlibrary references and minor cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23531/files - new: https://git.openjdk.org/jdk/pull/23531/files/f5e2ca1c..935324ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23531&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23531&range=00-01 Stats: 16 lines in 6 files changed: 2 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23531.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23531/head:pull/23531 PR: https://git.openjdk.org/jdk/pull/23531 From jwaters at openjdk.org Sun Feb 9 13:10:19 2025 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 9 Feb 2025 13:10:19 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 Don't close it ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2646295839 From duke at openjdk.org Mon Feb 10 06:46:45 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Mon, 10 Feb 2025 06:46:45 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v2] In-Reply-To: References: Message-ID: <23-VULWlKgQ34OhDeKRX-LL38MLEc4ATm7X5VqTP9Tw=.7b1050bd-dd63-45ec-8224-2660a3062f54@github.com> > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23315/files - new: https://git.openjdk.org/jdk/pull/23315/files/37df084e..0e288ec5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=00-01 Stats: 33 lines in 1 file changed: 0 ins; 5 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/23315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23315/head:pull/23315 PR: https://git.openjdk.org/jdk/pull/23315 From duke at openjdk.org Mon Feb 10 06:46:46 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Mon, 10 Feb 2025 06:46:46 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: <7R0vNN_yYwMma93wKwVdNLHJVbyYvMN8yoWcigpSIG0=.03797868-dee8-441f-b10f-aa02bc3a66dc@github.com> On Fri, 7 Feb 2025 15:12:08 GMT, Sean Mullan wrote: > > I'm wondering how necessary this fix is. These are internal classes, only called inside JDK, where some pre-conditions are always met. Unless someone explicitly calls `x509Certimpl.getInfo().setExtensions(null)` (as done in the test), it seems like both the `info` and `extensions` fields should never be null. > > If you?re concerned about misuse of these methods leading to potential future issues, consider adding comments to clarify their expected usage. You could also include `assert` statements or `Objects.requireNonNull` calls to enforce these preconditions. > > I agree with Weijun. The `info` field should never be `null` under normal circumstances. Checking if it is `null` would only make sense if there is a bug somewhere else in the code, and in that case, the bug should be fixed. I made these changes for the following reasons: **Null Check on info:** The X509CertImpl ref can be created with a null value for info, so I added a null check to prevent potential issues. **Consistency Across Internal Classes:** Other internal classes already perform the same null check on info. To maintain consistency, I added this change here as well. **Null Check on extensions:** The info object can be created without extensions. Since other parts of the code already handle potential null values for extensions, I added this check to maintain uniformity. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2647081463 From weijun at openjdk.org Mon Feb 10 13:40:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 10 Feb 2025 13:40:18 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v2] In-Reply-To: <23-VULWlKgQ34OhDeKRX-LL38MLEc4ATm7X5VqTP9Tw=.7b1050bd-dd63-45ec-8224-2660a3062f54@github.com> References: <23-VULWlKgQ34OhDeKRX-LL38MLEc4ATm7X5VqTP9Tw=.7b1050bd-dd63-45ec-8224-2660a3062f54@github.com> Message-ID: On Mon, 10 Feb 2025 06:46:45 GMT, Konanki Sreenath wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases I take back my word about `extensions` -- it can be null. However, `X509CertImpl` should never have a null `info`. I?d prefer to add `Objects.requireNonNull` in its constructor. Your approach of returning null instead of throwing an exception when `info == null` actually hides this problem. If there are other places when `info == null` is checked, please remove them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2648012752 From rriggs at openjdk.org Mon Feb 10 15:08:16 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 10 Feb 2025 15:08:16 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: <9qRdcyrkrFZ1vOa0ffS0kf5ED620fKCK4Iuo1fGt99Q=.f9515948-e003-46c7-9678-c88ac98d6fcc@github.com> Message-ID: On Sat, 8 Feb 2025 08:44:04 GMT, Shaojin Wen wrote: >> You could define the static field on another class, like SecurityConstants, and then use it in the enum constructor. > > Creating a new empty string array every time is the original behavior, which has nothing to do with the purpose of this PR. Should we follow the principle of minimal changes? If we want to change it, we should submit another PR Fine either way, its a fuzzy cutoff between an incidental improvement (also perf related) with the same reviewers or a new PR with a new set of emails and reviewers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23411#discussion_r1949275626 From rhalade at openjdk.org Mon Feb 10 17:14:09 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Mon, 10 Feb 2025 17:14:09 GMT Subject: RFR: 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree [v2] In-Reply-To: References: Message-ID: On Sun, 9 Feb 2025 05:32:10 GMT, Jamil Nimeh wrote: >> This takes a few test classes and moves them away from their current location in `test/jdk/java/security/testlibrary` to `test/lib/jdk/test/lib/security`, grouping them together with many other existing test utility classes. It also changes the dependent security tests to point at the new locations for these classes, as needed. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded testlibrary references and minor cleanup Thanks for the updates! LGTM ------------- Marked as reviewed by rhalade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23531#pullrequestreview-2606606007 From duke at openjdk.org Mon Feb 10 17:55:50 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Mon, 10 Feb 2025 17:55:50 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test Message-ID: Refactored the runNameEquals.sh to java test ------------- Commit messages: - 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test Changes: https://git.openjdk.org/jdk/pull/23542/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23542&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349534 Stats: 262 lines in 2 files changed: 97 ins; 136 del; 29 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 jnimeh at openjdk.org Mon Feb 10 18:22:20 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 10 Feb 2025 18:22:20 GMT Subject: Integrated: 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree In-Reply-To: References: Message-ID: On Sat, 8 Feb 2025 16:23:59 GMT, Jamil Nimeh wrote: > This takes a few test classes and moves them away from their current location in `test/jdk/java/security/testlibrary` to `test/lib/jdk/test/lib/security`, grouping them together with many other existing test utility classes. It also changes the dependent security tests to point at the new locations for these classes, as needed. This pull request has now been integrated. Changeset: b737f7fb Author: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/b737f7fb3004e4e9c95fba95c6fcda70073ae00e Stats: 155 lines in 42 files changed: 32 ins; 35 del; 88 mod 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree Reviewed-by: rhalade, weijun ------------- PR: https://git.openjdk.org/jdk/pull/23531 From mdonovan at openjdk.org Mon Feb 10 18:38:21 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Mon, 10 Feb 2025 18:38:21 GMT Subject: RFR: 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 test/jdk/sun/security/krb5/Krb5NameEquals.java line 94: > 92: > 93: if (installationIssue) { > 94: System.out.println(""" You should probably throw a SkippedException instead. test/jdk/sun/security/krb5/Krb5NameEquals.java line 125: > 123: Oid temp = null; > 124: try { > 125: temp = new Oid("1.2.840.113554.1.2.2"); // KRB5 You can't just set `MECH = new Oid(...);`? test/jdk/sun/security/krb5/Krb5NameEquals.java line 145: > 143: GSSName.NT_HOSTBASED_SERVICE, MECH); > 144: > 145: if (!name1.equals(name1) || !name1.equals(name3) || I don't know much about kerberos but is there ever a chance that `name1.equals(name1)` is false? And the same with name3 which looks to be created the same exact was as name1? test/jdk/sun/security/krb5/Krb5NameEquals.java line 148: > 146: !name1.equals((Object) name1) || > 147: !name1.equals((Object) name3)) { > 148: System.out.println("Error: should be the same name"); You can just throw exceptions and the exit code of the Java process with be 1 and the stack trace will be in the log. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1949665390 PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1949671597 PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1949677053 PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1949680536 From mpowers at openjdk.org Mon Feb 10 21:01:18 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 10 Feb 2025 21:01:18 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 18:47:54 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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: > > Adding comments + some code reorganization Some measurements: With Intrinsics --------------- keygen ML-DSA-44 38.8 us/op keygen ML-DSA-65 82.5 us/op keygen ML-DSA-87 112.6 us/op siggen ML-DSA-44 119.1 us/op siggen ML-DSA-65 186.5 us/op siggen ML-DSA-87 306.1 us/op sigver ML-DSA-44 46.4 us/op sigver ML-DSA-65 72.8 us/op sigver ML-DSA-87 123.4 us/op No Intrinsics ------------- keygen ML-DSA-44 63.1 us/op keygen ML-DSA-65 118.7 us/op keygen ML-DSA-87 167.2 us/op siggen ML-DSA-44 466.8 us/op siggen ML-DSA-65 546.3 us/op siggen ML-DSA-87 560.3 us/op sigver ML-DSA-44 71.6 us/op sigver ML-DSA-65 117.9 us/op sigver ML-DSA-87 180.4 us/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2649220775 From ihse at openjdk.org Mon Feb 10 21:18:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 10 Feb 2025 21:18:10 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v2] In-Reply-To: References: Message-ID: On Sat, 8 Feb 2025 05:01:03 GMT, Leonid Mesnik wrote: >> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > Update make/test/BuildTestLib.gmk > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> make/test/BuildTestLib.gmk line 61: > 59: > 60: ifeq ($(call isTargetOs, linux), false) > 61: EXCLUDE_DIRS := jdk/test/lib/containers Please call this either just "EXCLUDES", or even better `BUILD_TEST_LIB_JAR_EXCLUDES` (to conform with existing practice). Changing the name like this sounds like it is going to be assigned to another argument; we have various ways to exclude files and `EXCLUDES` is only one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1949903110 From bkilambi at openjdk.org Tue Feb 11 10:43:22 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 11 Feb 2025 10:43:22 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> On Thu, 6 Feb 2025 18:47:54 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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: > > Adding comments + some code reorganization src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2618: > 2616: INSN(smaxp, 0, 0b101001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S > 2617: INSN(sminp, 0, 0b101011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S > 2618: INSN(sqdmulh,0, 0b101101, false); // accepted arrangements: T4H, T8H, T2S, T4S Hi, not a comment on the algorithm itself but you might have to add these new instructions in the gtest for aarch64 here - test/hotspot/gtest/aarch64/aarch64-asmtest.py and use this file to generate test/hotspot/gtest/aarch64/asmtest.out.h which would contain these newly added instructions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1950610623 From duke at openjdk.org Tue Feb 11 11:20:11 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Tue, 11 Feb 2025 11:20:11 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 18:32:21 GMT, Matthew Donovan wrote: >> Refactored the runNameEquals.sh to java test > > test/jdk/sun/security/krb5/Krb5NameEquals.java line 145: > >> 143: GSSName.NT_HOSTBASED_SERVICE, MECH); >> 144: >> 145: if (!name1.equals(name1) || !name1.equals(name3) || > > I don't know much about kerberos but is there ever a chance that `name1.equals(name1)` is false? And the same with name3 which looks to be created the same exact was as name1? Yes, you're right. Also name1.equals((Object) name1) is always false, so removing in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1950661891 From duke at openjdk.org Tue Feb 11 11:29:59 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Tue, 11 Feb 2025 11:29:59 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v2] In-Reply-To: References: Message-ID: > Refactored the runNameEquals.sh to java test Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: minor cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23542/files - new: https://git.openjdk.org/jdk/pull/23542/files/3955548c..3d14d605 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23542&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23542&range=00-01 Stats: 29 lines in 1 file changed: 2 ins; 14 del; 13 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 duke at openjdk.org Tue Feb 11 11:30:00 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Tue, 11 Feb 2025 11:30:00 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v2] In-Reply-To: References: Message-ID: <3ubHkNjVVJAuk2qSZ0JmyZ_f4n5feJai7GMUIuNchis=.05332418-9d49-4efa-9278-45c320d937fa@github.com> On Mon, 10 Feb 2025 18:23:35 GMT, Matthew Donovan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> minor cleanup > > test/jdk/sun/security/krb5/Krb5NameEquals.java line 94: > >> 92: >> 93: if (installationIssue) { >> 94: System.out.println(""" > > You should probably throw a SkippedException instead. The initial logic in the shell file passed the test, but I agree that skip exception is going to be better in this case ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1950671438 From fguallini at openjdk.org Tue Feb 11 13:01:55 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Tue, 11 Feb 2025 13:01:55 GMT Subject: RFR: 8337723: Remove redundant tests from com/sun/security/sasl/gsskerb [v4] In-Reply-To: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> References: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> Message-ID: > There are 3 manual GSS-API/Kerberos tests that require a manual setup and were added to the problem list years ago: > > - com/sun/security/sasl/gsskerb/**AuthOnly**-> Verifies that both client and server have completed the authentication process. > - com/sun/security/sasl/gsskerb/**NoSecurityLayer** -> Attempts to use wrap and unwrap to demonstrate that these operations should not be allowed without a negotiated security layer. > - com/sun/security/sasl/gsskerb/**ConfSecurityLayer** -> Demonstrates the use of the security layer by wrapping and unwrapping messages on both client and server sides. > > These tests need manual setup of a KDC environment, service/user principals, keytabs, JAAS configuration, and script adjustments. All that is time consuming and error prone. These do not fail if configured properly. > > In contrast, the automated test sun/security/krb5/auto/**SaslBasic** already covers these scenarios and sets up the KDC with the necessary principals **automatically**, no manual setup is required. This class starts a simple KDC with one realm, several typical principal names, generates krb5.conf and keytab files, and setup a JAAS login config file. > > I've enhanced SaslBasic to include additional wrap/unwrap checks with and without a security layer. As a result, the 3 manual tests and their associated files are now redundand and can be removed, as they no longer provide additional value. Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge branch 'master' into 8337723 - Merge branch 'master' of https://github.com/openjdk/jdk - updating to openssl 3.0.14 - replace Exception with RuntimeException - Merge branch 'master' into 8337723 - Merge branch 'master' into 8337723 - refactoring - Merge branch 'master' into 8337723 - remov gsskerb tests ------------- Changes: https://git.openjdk.org/jdk/pull/20464/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20464&range=03 Stats: 919 lines in 13 files changed: 75 ins; 818 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/20464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20464/head:pull/20464 PR: https://git.openjdk.org/jdk/pull/20464 From fguallini at openjdk.org Tue Feb 11 13:05:48 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Tue, 11 Feb 2025 13:05:48 GMT Subject: RFR: 8337723: Remove redundant tests from com/sun/security/sasl/gsskerb [v5] In-Reply-To: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> References: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> Message-ID: <7uwkGtwn8oOnzeEpMP8pqM9Sxicy7PFM84_vOHTKifg=.42751a97-1995-47f4-b26f-9d3afbd9b1fc@github.com> > There are 3 manual GSS-API/Kerberos tests that require a manual setup and were added to the problem list years ago: > > - com/sun/security/sasl/gsskerb/**AuthOnly**-> Verifies that both client and server have completed the authentication process. > - com/sun/security/sasl/gsskerb/**NoSecurityLayer** -> Attempts to use wrap and unwrap to demonstrate that these operations should not be allowed without a negotiated security layer. > - com/sun/security/sasl/gsskerb/**ConfSecurityLayer** -> Demonstrates the use of the security layer by wrapping and unwrapping messages on both client and server sides. > > These tests need manual setup of a KDC environment, service/user principals, keytabs, JAAS configuration, and script adjustments. All that is time consuming and error prone. These do not fail if configured properly. > > In contrast, the automated test sun/security/krb5/auto/**SaslBasic** already covers these scenarios and sets up the KDC with the necessary principals **automatically**, no manual setup is required. This class starts a simple KDC with one realm, several typical principal names, generates krb5.conf and keytab files, and setup a JAAS login config file. > > I've enhanced SaslBasic to include additional wrap/unwrap checks with and without a security layer. As a result, the 3 manual tests and their associated files are now redundand and can be removed, as they no longer provide additional value. Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - replace Exception with RuntimeException - Merge branch 'master' into 8337723 - Merge branch 'master' into 8337723 - refactoring - Merge branch 'master' into 8337723 - remov gsskerb tests ------------- Changes: https://git.openjdk.org/jdk/pull/20464/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20464&range=04 Stats: 892 lines in 12 files changed: 58 ins; 817 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/20464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20464/head:pull/20464 PR: https://git.openjdk.org/jdk/pull/20464 From fguallini at openjdk.org Tue Feb 11 13:10:18 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Tue, 11 Feb 2025 13:10:18 GMT Subject: RFR: 8337723: Remove redundant tests from com/sun/security/sasl/gsskerb [v5] In-Reply-To: <7uwkGtwn8oOnzeEpMP8pqM9Sxicy7PFM84_vOHTKifg=.42751a97-1995-47f4-b26f-9d3afbd9b1fc@github.com> References: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> <7uwkGtwn8oOnzeEpMP8pqM9Sxicy7PFM84_vOHTKifg=.42751a97-1995-47f4-b26f-9d3afbd9b1fc@github.com> Message-ID: On Tue, 11 Feb 2025 13:05:48 GMT, Fernando Guallini wrote: >> There are 3 manual GSS-API/Kerberos tests that require a manual setup and were added to the problem list years ago: >> >> - com/sun/security/sasl/gsskerb/**AuthOnly**-> Verifies that both client and server have completed the authentication process. >> - com/sun/security/sasl/gsskerb/**NoSecurityLayer** -> Attempts to use wrap and unwrap to demonstrate that these operations should not be allowed without a negotiated security layer. >> - com/sun/security/sasl/gsskerb/**ConfSecurityLayer** -> Demonstrates the use of the security layer by wrapping and unwrapping messages on both client and server sides. >> >> These tests need manual setup of a KDC environment, service/user principals, keytabs, JAAS configuration, and script adjustments. All that is time consuming and error prone. These do not fail if configured properly. >> >> In contrast, the automated test sun/security/krb5/auto/**SaslBasic** already covers these scenarios and sets up the KDC with the necessary principals **automatically**, no manual setup is required. This class starts a simple KDC with one realm, several typical principal names, generates krb5.conf and keytab files, and setup a JAAS login config file. >> >> I've enhanced SaslBasic to include additional wrap/unwrap checks with and without a security layer. As a result, the 3 manual tests and their associated files are now redundand and can be removed, as they no longer provide additional value. > > Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - replace Exception with RuntimeException > - Merge branch 'master' into 8337723 > - Merge branch 'master' into 8337723 > - refactoring > - Merge branch 'master' into 8337723 > - remov gsskerb tests Force pushed to remove an incorrect commit from the branch ------------- PR Comment: https://git.openjdk.org/jdk/pull/20464#issuecomment-2650778494 From fguallini at openjdk.org Tue Feb 11 13:14:19 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Tue, 11 Feb 2025 13:14:19 GMT Subject: RFR: 8337723: Remove redundant tests from com/sun/security/sasl/gsskerb [v3] In-Reply-To: References: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> Message-ID: On Fri, 7 Feb 2025 20:22:52 GMT, Rajan Halade wrote: >> Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into 8337723 >> - Merge branch 'master' into 8337723 >> - refactoring >> - Merge branch 'master' into 8337723 >> - remov gsskerb tests > > test/jdk/sun/security/krb5/auto/SaslBasic.java line 118: > >> 116: >> 117: if (!Arrays.equals(hello, token)) { >> 118: throw new Exception("Client message altered"); > > please update these final exceptions from test to `RuntimeException` Updated to RuntimeException ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20464#discussion_r1950829860 From weijun at openjdk.org Tue Feb 11 13:26:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 11 Feb 2025 13:26:11 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 11:29:59 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 cleanup test/jdk/sun/security/krb5/Krb5NameEquals.java line 92: > 90: final var installationIssue = Arrays.stream(javaPropCommandResult.getStdout().split("\n")) > 91: .anyMatch(line -> line.contains("sun.arch.data.model") && line.contains("32")); > 92: Since this is already a Java program, maybe we can simply `System.getProperty("sun.arch.data.model")` here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1950846148 From weijun at openjdk.org Tue Feb 11 13:26:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 11 Feb 2025 13:26:11 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 13:22:08 GMT, Weijun Wang wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> minor cleanup > > test/jdk/sun/security/krb5/Krb5NameEquals.java line 92: > >> 90: final var installationIssue = Arrays.stream(javaPropCommandResult.getStdout().split("\n")) >> 91: .anyMatch(line -> line.contains("sun.arch.data.model") && line.contains("32")); >> 92: > > Since this is already a Java program, maybe we can simply `System.getProperty("sun.arch.data.model")` here? In fact, I'm not sure if this is still worth checking. Do we still have 32-bit Linux build? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1950847511 From weijun at openjdk.org Tue Feb 11 13:35:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 11 Feb 2025 13:35:11 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v2] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 11:29:59 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 cleanup test/jdk/sun/security/krb5/Krb5NameEquals.java line 104: > 102: result.shouldHaveExitValue(0); > 103: } > 104: } else { Both the Java provider and the native provider need to be tested. This is not an `else`. test/jdk/sun/security/krb5/Krb5NameEquals.java line 111: > 109: }; > 110: > 111: final var result = ProcessTools.executeTestJava(testCommand); There is no need to run this in a sub-process. Consider creating an individual `@run main/othervm` with the system properties is probably enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1950859905 PR Review Comment: https://git.openjdk.org/jdk/pull/23542#discussion_r1950862122 From mullan at openjdk.org Tue Feb 11 13:45:21 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 11 Feb 2025 13:45:21 GMT Subject: RFR: 8349151: Refactor test/java/security//cert/CertificateFactory/slowstream.sh to java test [v2] In-Reply-To: References: Message-ID: <9VfL0-iqlr8HArGmlaB9GNINHAPVTsccr36VYZd4e0Y=.56c339bb-f1de-477e-a578-1a1c1aab0d0f@github.com> 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 There's an extra '/' in the bug title, can you remove it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23394#issuecomment-2650866694 From duke at openjdk.org Tue Feb 11 14:14:16 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Tue, 11 Feb 2025 14:14:16 GMT Subject: RFR: 8349151: Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test [v2] In-Reply-To: <9VfL0-iqlr8HArGmlaB9GNINHAPVTsccr36VYZd4e0Y=.56c339bb-f1de-477e-a578-1a1c1aab0d0f@github.com> References: <9VfL0-iqlr8HArGmlaB9GNINHAPVTsccr36VYZd4e0Y=.56c339bb-f1de-477e-a578-1a1c1aab0d0f@github.com> Message-ID: On Tue, 11 Feb 2025 13:42:52 GMT, Sean Mullan wrote: > There's an extra '/' in the bug title, can you remove it? sure ------------- PR Comment: https://git.openjdk.org/jdk/pull/23394#issuecomment-2650941072 From lmesnik at openjdk.org Tue Feb 11 17:10:37 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Feb 2025 17:10:37 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v3] In-Reply-To: References: Message-ID: > The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - Merge branch '8346050' of https://github.com/lmesnik/jdk into 8346050 - renamed excludes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23525/files - new: https://git.openjdk.org/jdk/pull/23525/files/fad9ad2d..4813daed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23525&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23525&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23525/head:pull/23525 PR: https://git.openjdk.org/jdk/pull/23525 From jnimeh at openjdk.org Tue Feb 11 17:57:25 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 11 Feb 2025 17:57:25 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms Message-ID: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). ------------- Commit messages: - 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms Changes: https://git.openjdk.org/jdk/pull/23566/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349759 Stats: 316 lines in 3 files changed: 269 ins; 13 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/23566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23566/head:pull/23566 PR: https://git.openjdk.org/jdk/pull/23566 From duke at openjdk.org Tue Feb 11 18:00:48 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Tue, 11 Feb 2025 18:00:48 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v3] In-Reply-To: References: Message-ID: > Refactored the runNameEquals.sh to java test Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: reworked ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23542/files - new: https://git.openjdk.org/jdk/pull/23542/files/3d14d605..894c861b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23542&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23542&range=01-02 Stats: 111 lines in 1 file changed: 4 ins; 76 del; 31 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 duke at openjdk.org Tue Feb 11 18:11:12 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Tue, 11 Feb 2025 18:11:12 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v3] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 18:00:48 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: > > reworked Idea to check the availability of kerberos & code is done by @wangweij ------------- PR Comment: https://git.openjdk.org/jdk/pull/23542#issuecomment-2651624457 From duke at openjdk.org Tue Feb 11 18:46:29 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Tue, 11 Feb 2025 18:46:29 GMT Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to java test [v4] In-Reply-To: References: Message-ID: > Refactored the runNameEquals.sh to java test Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: minor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23542/files - new: https://git.openjdk.org/jdk/pull/23542/files/894c861b..70bb9737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23542&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23542&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 fferrari at openjdk.org Tue Feb 11 23:14:51 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Tue, 11 Feb 2025 23:14:51 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v3] 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 > * `impl` (`ServicesMapImpl`) > * `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 registration) > * `Current asCurrent()`: returns `impl` seen as a `Current` interface implementer > * `putService(Service svc)` > * `removeService(Service svc)` > * `Legacy asLegacy()`: returns `impl` seen as a `Legacy` interface implementer > * `putClassName(ServiceKey key, String className, String propKey)` > * `putAlias(ServiceKey key, ServiceKey aliasKey, String propKey)` > * `putAttribute(ServiceKey key, String attrName, String attrValue, String propKey)` > * `remove(ServiceKey key, String className)` > * `removeAlias(ServiceKey key, ServiceKey aliasKey)` > * `removeAttribute(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/1219321... Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: ServicesMapImpl class and Current, Legacy interfaces removed. 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/bda8971f..ac45d7c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=01-02 Stats: 1017 lines in 1 file changed: 294 ins; 403 del; 320 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 fferrari at openjdk.org Tue Feb 11 23:33:49 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Tue, 11 Feb 2025 23:33:49 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v4] 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 > * `impl` (`ServicesMapImpl`) > * `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 registration) > * `Current asCurrent()`: returns `impl` seen as a `Current` interface implementer > * `putService(Service svc)` > * `removeService(Service svc)` > * `Legacy asLegacy()`: returns `impl` seen as a `Legacy` interface implementer > * `putClassName(ServiceKey key, String className, String propKey)` > * `putAlias(ServiceKey key, ServiceKey aliasKey, String propKey)` > * `putAttribute(ServiceKey key, String attrName, String attrValue, String propKey)` > * `remove(ServiceKey key, String className)` > * `removeAlias(ServiceKey key, ServiceKey aliasKey)` > * `removeAttribute(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/1219321... Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge openjdk/master into JDK-8345139 Fix conflict caused by e20bd018c4046870d0cf632bb8e5440cb9f5c3c2: 1. Ignore the change, as this had already been identified and fixed (see JDK-8345139, section 3.1). 2. Remove the test, as it is already covered by ServicesConsistency::testInvalidServiceNotReturned. 3. Add the corresponding bug ID to ServicesConsistency. Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao Alonso - ServicesMapImpl class and Current, Legacy interfaces removed. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - Copyright update. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - 8345139: Fix bugs and inconsistencies in the Provider services map Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao ------------- Changes: https://git.openjdk.org/jdk/pull/22613/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=03 Stats: 2417 lines in 3 files changed: 1978 ins; 278 del; 161 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 Feb 11 23:47:11 2025 From: duke at openjdk.org (Bernd) Date: Tue, 11 Feb 2025 23:47:11 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: <02WAoRP3oFoYsFTUELth8tNifdLT_iWgCpmA3kxs3c4=.0230e7b3-6ca4-4ad5-8605-64948581814d@github.com> On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh wrote: > This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). Interesting! Is there no JEP Level Initiative for This? Did you do any Interop Testing, in fact are there already Root CAs offering such certificates? Does it apply Cross key typen? (ML-DSA issue signature on a ECDSA key or vice versa?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2652309271 From jnimeh at openjdk.org Tue Feb 11 23:55:11 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 11 Feb 2025 23:55:11 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: <31MLKC3JzJF2jRoIH2llf7ZnO1GlZpnhapoZgdDdwBk=.d2a30349-c715-4db9-b5cf-2ff493801b00@github.com> On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh wrote: > This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). I see no reason why an ECDSA end-entity key wouldn't work when signed from an ML-DSA root. To be clear, this just fixes these test classes I wrote a long time ago where the creation of signatures on certs and OCSP responses just wasn't done in a manner as algorithm-neutral as I intended it to be. As far as I've seen since the inclusion of ML-DSA, CertPathValidator operations seem to work just fine. I haven't gone looking to see who in the 3rd party world is doing ML-DSA certs...the goal of this PR was to make sure that we could simply build those cert chains for use with our tests, especially where we needed an OCSP server. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2652318099 From mbalao at openjdk.org Wed Feb 12 00:04:11 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 12 Feb 2025 00:04:11 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v4] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 23:54:02 GMT, Anthony Scarpino wrote: >> Just to add some more semantic value but we don't have a strong opinion, we can replace it with boolean if you want. > > Yes, please do that. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1951771232 From mbalao at openjdk.org Wed Feb 12 00:11:17 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 12 Feb 2025 00:11:17 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v4] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 23:33:49 GMT, Francisco Ferrari Bihurriet wrote: >> 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 >> * `impl` (`ServicesMapImpl`) >> * `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 registration) >> * `Current asCurrent()`: returns `impl` seen as a `Current` interface implementer >> * `putService(Service svc)` >> * `removeService(Service svc)` >> * `Legacy asLegacy()`: returns `impl` seen as a `Legacy` interface implementer >> * `putClassName(ServiceKey key, String className, String propKey)` >> * `putAlias(ServiceKey key, ServiceKey aliasKey, String propKey)` >> * `putAttribute(ServiceKey key, String attrName, String attrValue, String propKey)` >> * `remove(ServiceKey key, String className)` >> * `removeAlias(ServiceKey key, ServiceKey aliasKey)` >> * `removeAttribute(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 [... > > Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge openjdk/master into JDK-8345139 > > Fix conflict caused by e20bd018c4046870d0cf632bb8e5440cb9f5c3c2: > 1. Ignore the change, as this had already been identified and fixed > (see JDK-8345139, section 3.1). > 2. Remove the test, as it is already covered by > ServicesConsistency::testInvalidServiceNotReturned. > 3. Add the corresponding bug ID to ServicesConsistency. > > Co-authored-by: Francisco Ferrari Bihurriet > Co-authored-by: Martin Balao Alonso > - ServicesMapImpl class and Current, Legacy interfaces removed. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Copyright update. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - 8345139: Fix bugs and inconsistencies in the Provider services map > > Co-authored-by: Francisco Ferrari Bihurriet > Co-authored-by: Martin Balao The reason for having `Current` and `Legacy` interfaces was only to internally group methods and stress the distinction. We have now removed it and proposed a flat hierarchy for the `ServicesMap` (without the interfaces and impl class). ------------- PR Comment: https://git.openjdk.org/jdk/pull/22613#issuecomment-2652335492 From mbalao at openjdk.org Wed Feb 12 00:24:12 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 12 Feb 2025 00:24:12 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 00:53:13 GMT, Anthony Scarpino wrote: >> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright update. >> >> Co-authored-by: Martin Balao Alonso >> Co-authored-by: Francisco Ferrari Bihurriet > > src/java.base/share/classes/java/security/Provider.java line 2223: > >> 2221: private Service(Provider provider, ServiceKey algKey) { >> 2222: assert algKey.algorithm.intern() == algKey.algorithm : >> 2223: "Algorithm should be interned."; > > Why is `intern()` a requirement for this constructor? > > Following the call stack this AssertionError is thrown with `Provider.load()` and `Provider.putAll()` at a minimum. This could change behavior and I think it should be removed. These assertions are internal invariants that we want to sanity-check and document, specially for future code changes. They will never occur and do not depend on user API input. We went through all of them again to make sure that they are correct. For example, `ServiceKey` instances received in the referred `Service` constructor parameter must always have an internalized algorithm (the original algorithm string converted to uppercase). If you know of a call stack which may allow non-internalized `algKey.algorithm`, please let us know because it is a bug ?we couldn't find any. In the Security Manager days, the assumption was that Providers had enough privileges already to be trusted with internalizing Strings. On the contrary, code invoking `getService` was not necessarily trusted enough to internalize Strings used for queries. While this is not longer the case, we kept the distinction because Providers will use the Strings indeed and is a reduced set, whereas queries may be more open bounded. > src/java.base/share/classes/java/security/Provider.java line 2279: > >> 2277: assert aliasKey.type.equals(type) : "Invalid alias key type."; >> 2278: assert aliasKey.algorithm.intern() == aliasKey.algorithm : >> 2279: "Alias should be interned."; > > All these asserts look like they leak into the public API. If something does not match your requirements, then log a detailed message using `debug` and do not add the entry. Please have a look at my comment above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1951784544 PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1951784974 From valeriep at openjdk.org Wed Feb 12 09:21:12 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 12 Feb 2025 09:21:12 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes In-Reply-To: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> Message-ID: <2Q4JSPqsu5pLW3HPuX5uf1aidOIIS-dn0uM5smSK_dw=.6f1ba055-3c19-47b3-aa27-ba2e3283ac41@github.com> On Sat, 18 Jan 2025 00:14:58 GMT, Mark Powers wrote: > [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068) Didn't get to this until today, will take a look. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23188#issuecomment-2653089842 From djelinski at openjdk.org Wed Feb 12 10:12:01 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 12 Feb 2025 10:12:01 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec Message-ID: Please review this trivial fix that ensures that the mechanism always matches the parameter class type. I added a new test case that crashes without the fix, passes with the fix. Existing tier1-3 test cases continue to pass. ------------- Commit messages: - Fix P11TlsKeyMaterialGenerator crash Changes: https://git.openjdk.org/jdk/pull/23583/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23583&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349849 Stats: 90 lines in 2 files changed: 89 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23583.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23583/head:pull/23583 PR: https://git.openjdk.org/jdk/pull/23583 From ihse at openjdk.org Wed Feb 12 11:18:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 12 Feb 2025 11:18:09 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v3] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 17:10:37 GMT, Leonid Mesnik wrote: >> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8346050' of https://github.com/lmesnik/jdk into 8346050 > - renamed excludes LGTM now ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23525#pullrequestreview-2611595217 From duke at openjdk.org Wed Feb 12 13:19:24 2025 From: duke at openjdk.org (duke) Date: Wed, 12 Feb 2025 13:19:24 GMT Subject: RFR: 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore [v2] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 09:53:04 GMT, Fernando Guallini wrote: >> The test: **sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java** relies on the `certutil.exe` tool to import and delete certificates from a keystore. It was annotated with `@ignore` due to the uncertainty of `certutil.exe` being available on the instance where the test is executed. >> >> Rather than ignoring the test entirely, this PR updates the logic to throw a `SkippedException` if the tool is not found, ensuring the test runs when possible, and gracefully skipped otherwise. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright to 2025 @fguallini Your change (at version 618b03ee44f3136418c0bb3dcf69f59ddba79ced) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21305#issuecomment-2653684472 From mbalao at openjdk.org Wed Feb 12 14:06:23 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 12 Feb 2025 14:06:23 GMT Subject: RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v14] In-Reply-To: <7wCfQrs53w7KWE6l-T_WxnNVMt3l4W6LuY-s0zwJprU=.44a999d7-184f-487c-b076-97e717d51af4@github.com> References: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> <7wCfQrs53w7KWE6l-T_WxnNVMt3l4W6LuY-s0zwJprU=.44a999d7-184f-487c-b076-97e717d51af4@github.com> Message-ID: On Wed, 5 Feb 2025 23:06:54 GMT, Martin Balao wrote: >> We would like to propose an implementation of the HKDF algorithms for SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key Derivation Function API (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)). >> >> This implementation will be under the _Preview_ umbrella until the KDF API becomes stable in a future JDK release. The benefit of this early proposal is to gather more feedback about the KDF API for future improvements. >> >> The `P11KDF` class has the core implementation and Java calls to the PKCS 11 API. Different native mechanism were used to merge key material: CKM_CONCATENATE_BASE_AND_DATA (key and data), CKM_CONCATENATE_BASE_AND_KEY (key and key) and CKM_CONCATENATE_DATA_AND_BASE (data and key). The implementation also supports merging data with data, at the Java level. List of HKDF algorithms supported: HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512. >> >> Derivation modes supported: extract, expand, and, extract-expand. >> >> We further advanced the consolidation of algorithm and key info in the P11SecretKeyFactory map ?this effort started with the PBE support enhancement and has helped to avoid duplication?. The map has now information about HMAC (`HMACKeyInfo` class) and HKDF (`HKDFKeyInfo` class) algorithms. P11Mac is now aligned to take the information from the map. >> >> Generic keys now supported in SecretKeyFactory. Derived keys could be Generic. >> >> Testing >> >> * [TestHKDF.java](https://github.com/openjdk/jdk/blob/e87ec99b90ff742f531a5031fdeeb9f2e039856d/test/jdk/sun/security/pkcs11/KDF/TestHKDF.java) test added >> * All non-SHA1 & non-SHA224 RFC 5869 test vectors checked >> * Cross-checking against SunJCE's HKDF implementation for every algorithm possible >> * Static assertion data for resilience if SunJCE were not available >> * Use of derived key for encryption check >> * Concatenation of input key material and salt checked (multiple combinations) >> * Multiple derivation types checked (extract only, expand only, and, extract-expand) >> * Derive key and derive data checked >> * All supported HKDF algorithms tested (HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512) >> * DH and ECDH key derivation for TLS checked >> * Informative output for debugging purposes (shown automatically if there is a test failure) >> * Note: test failures do not prevent all tests for running >> * Test integrated to the SunPKCS11 tests framework >> >> * No regressions observed in jdk/sun/security/pkcs11 (114 tests pa... > > Martin Balao 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 14 additional commits since the last revision: > > - Merge openjdk/master into JDK-8328119 > > Fix trivial copyright conflict in: > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java > - Align behaviour with the CSR > > Make a PKCS #11 library supporting only CKM_HKDF_DERIVE or CKM_HKDF_DATA > to also register the HKDF algorithms. Notice that the corresponding HMAC > mechanism is still required. In case only one of the mechanisms is > available, KDF::deriveKey or KDF::deriveData will fail at run time. > > If the user disables one of CKM_HKDF_DERIVE or CKM_HKDF_DATA through > sun.security.pkcs11.Config, also refrain from using it. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Add test case with empty inputs > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Improve TestContext note about expectedOpOut > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Renaming of P11KDF fix. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Minor changes based on review. Copyright date adjustments. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Check disabled PKCS #11 mechanisms when concatenating keys and data. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Support for HKDF-SHA1 and HKDF-SHA224 removed. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Unused import removed. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Fix NPE in assertion. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - ... and 4 more: https://git.openjdk.org/jdk/compare/66d9720b...d018b4a9 CSR and PR were re-approved since our last changes. We intend to integrate this PR soon, if no one has any other concern. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22215#issuecomment-2653803290 From fferrari at openjdk.org Wed Feb 12 15:39:21 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Wed, 12 Feb 2025 15:39:21 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v4] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 23:33:49 GMT, Francisco Ferrari Bihurriet wrote: >> 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 >> * `impl` (`ServicesMapImpl`) >> * `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 registration) >> * `Current asCurrent()`: returns `impl` seen as a `Current` interface implementer >> * `putService(Service svc)` >> * `removeService(Service svc)` >> * `Legacy asLegacy()`: returns `impl` seen as a `Legacy` interface implementer >> * `putClassName(ServiceKey key, String className, String propKey)` >> * `putAlias(ServiceKey key, ServiceKey aliasKey, String propKey)` >> * `putAttribute(ServiceKey key, String attrName, String attrValue, String propKey)` >> * `remove(ServiceKey key, String className)` >> * `removeAlias(ServiceKey key, ServiceKey aliasKey)` >> * `removeAttribute(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 [... > > Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge openjdk/master into JDK-8345139 > > Fix conflict caused by e20bd018c4046870d0cf632bb8e5440cb9f5c3c2: > 1. Ignore the change, as this had already been identified and fixed > (see JDK-8345139, section 3.1). > 2. Remove the test, as it is already covered by > ServicesConsistency::testInvalidServiceNotReturned. > 3. Add the corresponding bug ID to ServicesConsistency. > > Co-authored-by: Francisco Ferrari Bihurriet > Co-authored-by: Martin Balao Alonso > - ServicesMapImpl class and Current, Legacy interfaces removed. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - Copyright update. > > Co-authored-by: Martin Balao Alonso > Co-authored-by: Francisco Ferrari Bihurriet > - 8345139: Fix bugs and inconsistencies in the Provider services map > > Co-authored-by: Francisco Ferrari Bihurriet > Co-authored-by: Martin Balao NOTE: as explained in the 35e2eaeac7438ebbbc72631091cbdc890f43b139 merge commit message, this PR now deletes `InvalidServiceTest.java` because that test is already covered by `ServicesConsistency.java`, since [JDK-8344361](https://bugs.openjdk.org/browse/JDK-8344361 "Restore null return for invalid services from legacy providers") corresponds with [JDK-8345139, section 3.1](https://bugs.openjdk.org/browse/JDK-8345139#:~:text=3.1,.,-3.2 "Fix bugs and inconsistencies in the Provider services map, section 3.1"). https://github.com/openjdk/jdk/blob/35e2eaeac7438ebbbc72631091cbdc890f43b139/test/jdk/java/security/Provider/ServicesConsistency.java#L835-L839 Just in case, we made sure that the deleted `InvalidServiceTest.java` passes in this PR branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22613#issuecomment-2654080891 From duke at openjdk.org Wed Feb 12 17:32:29 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 12 Feb 2025 17:32:29 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test Message-ID: Moved the sh file logic to jtreg java test. ------------- Commit messages: - 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test Changes: https://git.openjdk.org/jdk/pull/23590/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23590&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349535 Stats: 173 lines in 2 files changed: 34 ins; 139 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23590/head:pull/23590 PR: https://git.openjdk.org/jdk/pull/23590 From duke at openjdk.org Wed Feb 12 18:07:48 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 12 Feb 2025 18:07:48 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v2] In-Reply-To: References: Message-ID: > 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: changed the year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23590/files - new: https://git.openjdk.org/jdk/pull/23590/files/c8d4a922..a4bdd94f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23590&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23590&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23590/head:pull/23590 PR: https://git.openjdk.org/jdk/pull/23590 From rhalade at openjdk.org Wed Feb 12 18:34:13 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 12 Feb 2025 18:34:13 GMT Subject: RFR: 8337723: Remove redundant tests from com/sun/security/sasl/gsskerb [v5] In-Reply-To: <7uwkGtwn8oOnzeEpMP8pqM9Sxicy7PFM84_vOHTKifg=.42751a97-1995-47f4-b26f-9d3afbd9b1fc@github.com> References: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> <7uwkGtwn8oOnzeEpMP8pqM9Sxicy7PFM84_vOHTKifg=.42751a97-1995-47f4-b26f-9d3afbd9b1fc@github.com> Message-ID: On Tue, 11 Feb 2025 13:05:48 GMT, Fernando Guallini wrote: >> There are 3 manual GSS-API/Kerberos tests that require a manual setup and were added to the problem list years ago: >> >> - com/sun/security/sasl/gsskerb/**AuthOnly**-> Verifies that both client and server have completed the authentication process. >> - com/sun/security/sasl/gsskerb/**NoSecurityLayer** -> Attempts to use wrap and unwrap to demonstrate that these operations should not be allowed without a negotiated security layer. >> - com/sun/security/sasl/gsskerb/**ConfSecurityLayer** -> Demonstrates the use of the security layer by wrapping and unwrapping messages on both client and server sides. >> >> These tests need manual setup of a KDC environment, service/user principals, keytabs, JAAS configuration, and script adjustments. All that is time consuming and error prone. These do not fail if configured properly. >> >> In contrast, the automated test sun/security/krb5/auto/**SaslBasic** already covers these scenarios and sets up the KDC with the necessary principals **automatically**, no manual setup is required. This class starts a simple KDC with one realm, several typical principal names, generates krb5.conf and keytab files, and setup a JAAS login config file. >> >> I've enhanced SaslBasic to include additional wrap/unwrap checks with and without a security layer. As a result, the 3 manual tests and their associated files are now redundand and can be removed, as they no longer provide additional value. > > Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - replace Exception with RuntimeException > - Merge branch 'master' into 8337723 > - Merge branch 'master' into 8337723 > - refactoring > - Merge branch 'master' into 8337723 > - remov gsskerb tests Thanks for the update. ------------- Marked as reviewed by rhalade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20464#pullrequestreview-2612863507 From duke at openjdk.org Wed Feb 12 18:39:13 2025 From: duke at openjdk.org (duke) Date: Wed, 12 Feb 2025 18:39:13 GMT Subject: RFR: 8337723: Remove redundant tests from com/sun/security/sasl/gsskerb [v5] In-Reply-To: <7uwkGtwn8oOnzeEpMP8pqM9Sxicy7PFM84_vOHTKifg=.42751a97-1995-47f4-b26f-9d3afbd9b1fc@github.com> References: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> <7uwkGtwn8oOnzeEpMP8pqM9Sxicy7PFM84_vOHTKifg=.42751a97-1995-47f4-b26f-9d3afbd9b1fc@github.com> Message-ID: On Tue, 11 Feb 2025 13:05:48 GMT, Fernando Guallini wrote: >> There are 3 manual GSS-API/Kerberos tests that require a manual setup and were added to the problem list years ago: >> >> - com/sun/security/sasl/gsskerb/**AuthOnly**-> Verifies that both client and server have completed the authentication process. >> - com/sun/security/sasl/gsskerb/**NoSecurityLayer** -> Attempts to use wrap and unwrap to demonstrate that these operations should not be allowed without a negotiated security layer. >> - com/sun/security/sasl/gsskerb/**ConfSecurityLayer** -> Demonstrates the use of the security layer by wrapping and unwrapping messages on both client and server sides. >> >> These tests need manual setup of a KDC environment, service/user principals, keytabs, JAAS configuration, and script adjustments. All that is time consuming and error prone. These do not fail if configured properly. >> >> In contrast, the automated test sun/security/krb5/auto/**SaslBasic** already covers these scenarios and sets up the KDC with the necessary principals **automatically**, no manual setup is required. This class starts a simple KDC with one realm, several typical principal names, generates krb5.conf and keytab files, and setup a JAAS login config file. >> >> I've enhanced SaslBasic to include additional wrap/unwrap checks with and without a security layer. As a result, the 3 manual tests and their associated files are now redundand and can be removed, as they no longer provide additional value. > > Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - replace Exception with RuntimeException > - Merge branch 'master' into 8337723 > - Merge branch 'master' into 8337723 > - refactoring > - Merge branch 'master' into 8337723 > - remov gsskerb tests @fguallini Your change (at version 432f9c737ab9910803681179ec4e2054bddce4d7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20464#issuecomment-2654546926 From fguallini at openjdk.org Wed Feb 12 18:39:18 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Wed, 12 Feb 2025 18:39:18 GMT Subject: Integrated: 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore In-Reply-To: References: Message-ID: On Wed, 2 Oct 2024 13:24:00 GMT, Fernando Guallini wrote: > The test: **sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java** relies on the `certutil.exe` tool to import and delete certificates from a keystore. It was annotated with `@ignore` due to the uncertainty of `certutil.exe` being available on the instance where the test is executed. > > Rather than ignoring the test entirely, this PR updates the logic to throw a `SkippedException` if the tool is not found, ensuring the test runs when possible, and gracefully skipped otherwise. This pull request has now been integrated. Changeset: c5ac3c4f Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.org/jdk/commit/c5ac3c4f11e777b24d597deec522c9df09750f59 Stats: 18 lines in 1 file changed: 14 ins; 2 del; 2 mod 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore Reviewed-by: hchao, rhalade ------------- PR: https://git.openjdk.org/jdk/pull/21305 From rhalade at openjdk.org Wed Feb 12 19:22:11 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 12 Feb 2025 19:22:11 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v2] In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 18:07:48 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: > > changed the year Changes requested by rhalade (Reviewer). test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 63: > 61: private static void copyDbFiles() throws IOException { > 62: final var testFolder = System.getProperty("test.src", "."); > 63: final var destination = Paths.get(testFolder); Don't update `test.src` with a copy of these files. It should instead use `test.classes` ------------- PR Review: https://git.openjdk.org/jdk/pull/23590#pullrequestreview-2612967785 PR Review Comment: https://git.openjdk.org/jdk/pull/23590#discussion_r1953262324 From mdonovan at openjdk.org Wed Feb 12 19:32:47 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 12 Feb 2025 19:32:47 GMT Subject: RFR: 8345598: Upgrade NSS binaries for interop tests Message-ID: This is a trivial PR to update the version of NSS used for pkcs11 tests. ------------- Commit messages: - 8345598: Upgrade NSS binaries for interop tests Changes: https://git.openjdk.org/jdk/pull/23594/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23594&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345598 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23594/head:pull/23594 PR: https://git.openjdk.org/jdk/pull/23594 From rhalade at openjdk.org Wed Feb 12 19:34:17 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 12 Feb 2025 19:34:17 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v2] In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:15:46 GMT, Rajan Halade wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> changed the year > > test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 63: > >> 61: private static void copyDbFiles() throws IOException { >> 62: final var testFolder = System.getProperty("test.src", "."); >> 63: final var destination = Paths.get(testFolder); > > Don't update `test.src` with a copy of these files. It should instead use `test.classes` It should be scratch directory. Refer to PR https://github.com/openjdk/jdk/pull/21665 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23590#discussion_r1953281718 From fferrari at openjdk.org Wed Feb 12 20:46:31 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Wed, 12 Feb 2025 20:46:31 GMT Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v5] In-Reply-To: References: Message-ID: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com> > 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: Clear ServicesMap fields in the declared order Constructors assign the fields in the same order. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22613/files - new: https://git.openjdk.org/jdk/pull/22613/files/35e2eaea..3d0df51b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22613&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 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 valeriep at openjdk.org Wed Feb 12 21:12:16 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 12 Feb 2025 21:12:16 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes In-Reply-To: <6i6DTgn_AToR0vH9MHBQTlHGjPLPS-6YkYELlho10bw=.b2386ebe-f54d-4f2b-9871-09c8fa5c31ec@github.com> References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> <6i6DTgn_AToR0vH9MHBQTlHGjPLPS-6YkYELlho10bw=.b2386ebe-f54d-4f2b-9871-09c8fa5c31ec@github.com> Message-ID: On Tue, 21 Jan 2025 15:53:35 GMT, Sean Mullan wrote: >> [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068) > > src/java.base/share/classes/javax/crypto/spec/IvParameterSpec.java line 73: > >> 71: * or {@code (iv.length - offset < len)} >> 72: * @throws ArrayIndexOutOfBoundsException if {@code offset} >> 73: * or {@code len} index bytes outside the {@code iv}. > > can you fix this grammatical issue while you are changing this: > > s/outside/are outside/ Maybe we should just state that ArrayIndexOutOfBoundsException is thrown if `offset` or `len` is negative? The current wording for AIOOBE seems to suggest that it covers the case when `offset` or `len` is too large. But that is covered by the IAE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23188#discussion_r1953210851 From valeriep at openjdk.org Wed Feb 12 21:12:16 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 12 Feb 2025 21:12:16 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes In-Reply-To: References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> <6i6DTgn_AToR0vH9MHBQTlHGjPLPS-6YkYELlho10bw=.b2386ebe-f54d-4f2b-9871-09c8fa5c31ec@github.com> Message-ID: On Wed, 12 Feb 2025 18:37:38 GMT, Valerie Peng wrote: >> src/java.base/share/classes/javax/crypto/spec/IvParameterSpec.java line 73: >> >>> 71: * or {@code (iv.length - offset < len)} >>> 72: * @throws ArrayIndexOutOfBoundsException if {@code offset} >>> 73: * or {@code len} index bytes outside the {@code iv}. >> >> can you fix this grammatical issue while you are changing this: >> >> s/outside/are outside/ > > Maybe we should just state that ArrayIndexOutOfBoundsException is thrown if `offset` or `len` is negative? The current wording for AIOOBE seems to suggest that it covers the case when `offset` or `len` is too large. But that is covered by the IAE. `SecretKeySpec` constructor has this same wording for AIOOBE, so if we change to cover negative value only, we should apply the same change to `SecretKeySpec` as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23188#discussion_r1953217127 From valeriep at openjdk.org Wed Feb 12 21:12:17 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 12 Feb 2025 21:12:17 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes In-Reply-To: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> Message-ID: On Sat, 18 Jan 2025 00:14:58 GMT, Mark Powers wrote: > [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068) src/java.base/share/classes/javax/crypto/spec/IvParameterSpec.java line 73: > 71: * or {@code (iv.length - offset < len)} > 72: * @throws ArrayIndexOutOfBoundsException if {@code offset} > 73: * or {@code len} index bytes outside the {@code iv}. `RC2ParameterSpec(int, byte[], int)` ctor should be documented with AIOOBE as well. If you pass a negative offset into it, AIOOBE is thrown by the `System.arraycopy()` call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23188#discussion_r1953402235 From valeriep at openjdk.org Wed Feb 12 21:15:12 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 12 Feb 2025 21:15:12 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes In-Reply-To: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> Message-ID: On Sat, 18 Jan 2025 00:14:58 GMT, Mark Powers wrote: > [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068) I didn't see the CSR? Assuming it's not filed yet? We still need to file CSR for documenting existing behavior, but no need to cover the syntax related changes, e.g. to {@code }. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23188#issuecomment-2654855326 From mbalao at openjdk.org Wed Feb 12 21:52:57 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 12 Feb 2025 21:52:57 GMT Subject: RFR: 8315487: Security Providers Filter [v20] 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 four commits: - 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=19 Stats: 2716 lines in 21 files changed: 2500 ins; 85 del; 131 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 duke at openjdk.org Thu Feb 13 07:07:21 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Thu, 13 Feb 2025 07:07:21 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v2] In-Reply-To: References: <23-VULWlKgQ34OhDeKRX-LL38MLEc4ATm7X5VqTP9Tw=.7b1050bd-dd63-45ec-8224-2660a3062f54@github.com> Message-ID: On Mon, 10 Feb 2025 13:37:07 GMT, Weijun Wang wrote: > I take back my word about `extensions` -- it can be null. However, `X509CertImpl` should never have a null `info`. I?d prefer to add `Objects.requireNonNull` in its constructor. Your approach of returning null instead of throwing an exception when `info == null` actually hides this problem. If there are other places when `info == null` is checked, please remove them. Yes, as you suggested, this approach to the code change is much clearer. I will remove the null check on info and adding Objects.requireNonNull in the constructor of the X509CertImpl class. This will result in modifications to one of the test class to accommodate the new changes. Additionally, I will move the newly added (in this commit) CertificateExtensions class to the internal package to facilitate testing of the internal methods." ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2655700863 From duke at openjdk.org Thu Feb 13 08:42:24 2025 From: duke at openjdk.org (Nicole Xu) Date: Thu, 13 Feb 2025 08:42:24 GMT Subject: RFR: 8349943: [JMH] Use jvmArgs consistently Message-ID: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'. All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency. ------------- Commit messages: - 8349943: [JMH] Use jvmArgs consistently Changes: https://git.openjdk.org/jdk/pull/23609/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23609&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349943 Stats: 20 lines in 9 files changed: 2 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/23609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23609/head:pull/23609 PR: https://git.openjdk.org/jdk/pull/23609 From duke at openjdk.org Thu Feb 13 12:39:17 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Thu, 13 Feb 2025 12:39:17 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v2] In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:31:31 GMT, Rajan Halade wrote: >> test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 63: >> >>> 61: private static void copyDbFiles() throws IOException { >>> 62: final var testFolder = System.getProperty("test.src", "."); >>> 63: final var destination = Paths.get(testFolder); >> >> Don't update `test.src` with a copy of these files. It should instead use `test.classes` > > It should be scratch directory. Refer to PR https://github.com/openjdk/jdk/pull/21665 Changed to the scratch directory in the next commit. Thanks for pointing this out ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23590#discussion_r1954420075 From duke at openjdk.org Thu Feb 13 13:48:26 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Thu, 13 Feb 2025 13:48:26 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v3] In-Reply-To: References: Message-ID: > 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: changed to use a scratch directory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23590/files - new: https://git.openjdk.org/jdk/pull/23590/files/a4bdd94f..0969eaea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23590&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23590&range=01-02 Stats: 17 lines in 1 file changed: 9 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23590/head:pull/23590 PR: https://git.openjdk.org/jdk/pull/23590 From mbalao at openjdk.org Thu Feb 13 16:58:31 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 13 Feb 2025 16:58:31 GMT Subject: Integrated: 8328119: Support HKDF in SunPKCS11 (Preview) In-Reply-To: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> References: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com> Message-ID: <7uG1tBce7kOhb-o5THSA6WKnU4xBRS3QLl7MUmzBKlU=.cfdd6551-2c65-481c-955a-8ace3687fa60@github.com> On Mon, 18 Nov 2024 18:05:34 GMT, Martin Balao wrote: > We would like to propose an implementation of the HKDF algorithms for SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key Derivation Function API (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)). > > This implementation will be under the _Preview_ umbrella until the KDF API becomes stable in a future JDK release. The benefit of this early proposal is to gather more feedback about the KDF API for future improvements. > > The `P11KDF` class has the core implementation and Java calls to the PKCS 11 API. Different native mechanism were used to merge key material: CKM_CONCATENATE_BASE_AND_DATA (key and data), CKM_CONCATENATE_BASE_AND_KEY (key and key) and CKM_CONCATENATE_DATA_AND_BASE (data and key). The implementation also supports merging data with data, at the Java level. List of HKDF algorithms supported: HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512. > > Derivation modes supported: extract, expand, and, extract-expand. > > We further advanced the consolidation of algorithm and key info in the P11SecretKeyFactory map ?this effort started with the PBE support enhancement and has helped to avoid duplication?. The map has now information about HMAC (`HMACKeyInfo` class) and HKDF (`HKDFKeyInfo` class) algorithms. P11Mac is now aligned to take the information from the map. > > Generic keys now supported in SecretKeyFactory. Derived keys could be Generic. > > Testing > > * [TestHKDF.java](https://github.com/openjdk/jdk/blob/e87ec99b90ff742f531a5031fdeeb9f2e039856d/test/jdk/sun/security/pkcs11/KDF/TestHKDF.java) test added > * All non-SHA1 & non-SHA224 RFC 5869 test vectors checked > * Cross-checking against SunJCE's HKDF implementation for every algorithm possible > * Static assertion data for resilience if SunJCE were not available > * Use of derived key for encryption check > * Concatenation of input key material and salt checked (multiple combinations) > * Multiple derivation types checked (extract only, expand only, and, extract-expand) > * Derive key and derive data checked > * All supported HKDF algorithms tested (HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512) > * DH and ECDH key derivation for TLS checked > * Informative output for debugging purposes (shown automatically if there is a test failure) > * Note: test failures do not prevent all tests for running > * Test integrated to the SunPKCS11 tests framework > > * No regressions observed in jdk/sun/security/pkcs11 (114 tests passed, 0 failed) > > A CSR will be proposed. > > This proposal is... This pull request has now been integrated. Changeset: 6ddbcc34 Author: Martin Balao URL: https://git.openjdk.org/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa Stats: 1611 lines in 16 files changed: 1545 ins; 29 del; 37 mod 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactory Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao Reviewed-by: valeriep, kdriver, weijun ------------- PR: https://git.openjdk.org/jdk/pull/22215 From mullan at openjdk.org Thu Feb 13 17:07:41 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 13 Feb 2025 17:07:41 GMT Subject: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection Message-ID: This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates. 2 other smaller changes: - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`) ------------- Commit messages: - Fix whitespace. - Add additional text about trusting signers. - Merge - Initial fix. Changes: https://git.openjdk.org/jdk/pull/23616/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23616&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347946 Stats: 38 lines in 3 files changed: 32 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23616/head:pull/23616 PR: https://git.openjdk.org/jdk/pull/23616 From mullan at openjdk.org Thu Feb 13 18:16:11 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 13 Feb 2025 18:16:11 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 10:02:55 GMT, Daniel Jeli?ski wrote: > Please review this trivial fix that ensures that the mechanism always matches the parameter class type. > > I added a new test case that crashes without the fix, passes with the fix. Existing tier1-3 test cases continue to pass. @valeriepeng Please review this fix. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java line 122: > 120: } else if (tlsVersion == 0x0301 || tlsVersion == 0x0302) { > 121: mechanism = CKM_TLS_KEY_AND_MAC_DERIVE; > 122: } else if (tlsVersion == 0x0303) { Should TLS 1.2 also use CKM_TLS12_KEY_AND_MAC_DERIVE? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23583#issuecomment-2657385149 PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1955005436 From djelinski at openjdk.org Thu Feb 13 18:35:13 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 13 Feb 2025 18:35:13 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 18:12:52 GMT, Sean Mullan wrote: >> Please review this trivial fix that ensures that the mechanism always matches the parameter class type. >> >> I added a new test case that crashes without the fix, passes with the fix. Existing tier1-3 test cases continue to pass. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java line 122: > >> 120: } else if (tlsVersion == 0x0301 || tlsVersion == 0x0302) { >> 121: mechanism = CKM_TLS_KEY_AND_MAC_DERIVE; >> 122: } else if (tlsVersion == 0x0303) { > > Should TLS 1.2 also use CKM_TLS12_KEY_AND_MAC_DERIVE? TLS 1.2 is version 3.3. The versions are: SSL 3.0 - 3.0 TLS 1.0 - 3.1 TLS 1.1 - 3.2 TLS 1.2 - 3.3 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1955032712 From mullan at openjdk.org Thu Feb 13 18:45:16 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 13 Feb 2025 18:45:16 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec In-Reply-To: References: Message-ID: <0Cnl_2GC5sPNo5SUTyI0ziEC7tQ44LvYwSXkOthntnI=.692670c4-12ad-4d83-87ba-b443221b35c0@github.com> On Thu, 13 Feb 2025 18:32:41 GMT, Daniel Jeli?ski wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java line 122: >> >>> 120: } else if (tlsVersion == 0x0301 || tlsVersion == 0x0302) { >>> 121: mechanism = CKM_TLS_KEY_AND_MAC_DERIVE; >>> 122: } else if (tlsVersion == 0x0303) { >> >> Should TLS 1.2 also use CKM_TLS12_KEY_AND_MAC_DERIVE? > > TLS 1.2 is version 3.3. > The versions are: > SSL 3.0 - 3.0 > TLS 1.0 - 3.1 > TLS 1.1 - 3.2 > TLS 1.2 - 3.3 Ah ok. So I assume TLS 1.3 is using a different code path or KDF. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1955042992 From djelinski at openjdk.org Thu Feb 13 18:45:17 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 13 Feb 2025 18:45:17 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec In-Reply-To: <0Cnl_2GC5sPNo5SUTyI0ziEC7tQ44LvYwSXkOthntnI=.692670c4-12ad-4d83-87ba-b443221b35c0@github.com> References: <0Cnl_2GC5sPNo5SUTyI0ziEC7tQ44LvYwSXkOthntnI=.692670c4-12ad-4d83-87ba-b443221b35c0@github.com> Message-ID: On Thu, 13 Feb 2025 18:41:01 GMT, Sean Mullan wrote: >> TLS 1.2 is version 3.3. >> The versions are: >> SSL 3.0 - 3.0 >> TLS 1.0 - 3.1 >> TLS 1.1 - 3.2 >> TLS 1.2 - 3.3 > > Ah ok. So I assume TLS 1.3 is using a different code path or KDF. TLS 1.3 uses HKDF, and doesn't work with SunPKCS11 yet, see [JDK-8278640](https://bugs.openjdk.org/browse/JDK-8278640) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1955045362 From mullan at openjdk.org Thu Feb 13 19:00:10 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 13 Feb 2025 19:00:10 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh wrote: > This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). Bug needs a `noreg-self` label. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2657471939 From wetmore at openjdk.org Thu Feb 13 19:10:17 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 13 Feb 2025 19:10:17 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 10:02:55 GMT, Daniel Jeli?ski wrote: > Please review this trivial fix that ensures that the mechanism always matches the parameter class type. > > I added a new test case that crashes without the fix, passes with the fix. Existing tier1-3 test cases continue to pass. Marked as reviewed by wetmore (Reviewer). src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java line 124: > 122: } else if (tlsVersion == 0x0303) { > 123: mechanism = CKM_TLS12_KEY_AND_MAC_DERIVE; > 124: } So this hasn't worked since the TLSv1.2 support was added in 2018? Ouch! I wonder if how many are using PKCS11 for TLS. Seems like this should have been found earlier. Double check with @valeriepeng , but looks ok to me... ------------- PR Review: https://git.openjdk.org/jdk/pull/23583#pullrequestreview-2615984496 PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1955073131 From djelinski at openjdk.org Thu Feb 13 19:40:12 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 13 Feb 2025 19:40:12 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 19:06:28 GMT, Bradford Wetmore wrote: >> Please review this trivial fix that ensures that the mechanism always matches the parameter class type. >> >> I added a new test case that crashes without the fix, passes with the fix. Existing tier1-3 test cases continue to pass. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java line 124: > >> 122: } else if (tlsVersion == 0x0303) { >> 123: mechanism = CKM_TLS12_KEY_AND_MAC_DERIVE; >> 124: } > > So this hasn't worked since the TLSv1.2 support was added in 2018? Ouch! > > I wonder if how many are using PKCS11 for TLS. Seems like this should have been found earlier. > > Double check with @valeriepeng , but looks ok to me... It's not that bad, the crash only happens when you (mis-)use SunTlsKeyMaterial instead of SunTls12KeyMaterial with TLS 1.2. JSSE uses the correct one. I only hit this bug when experimenting with tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1955110134 From jnimeh at openjdk.org Thu Feb 13 19:43:11 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 13 Feb 2025 19:43:11 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Thu, 13 Feb 2025 18:58:00 GMT, Sean Mullan wrote: >> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). > > Bug needs a `noreg-self` label. @seanjmullan I wasn't sure if I should add that label because there is a test of these changes in `test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java`. However I did notice that I forgot to change the bug ID and summary in that test code, so I will update that. Given that there is a test included with the change, LMK if you still feel that it needs the noreg label and I will add it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2657550465 From jnimeh at openjdk.org Thu Feb 13 19:43:12 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 13 Feb 2025 19:43:12 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh wrote: > This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java line 26: > 24: /** > 25: * @test > 26: * @bug 8179502 Cut-n-paste bug, update this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955113230 From mullan at openjdk.org Thu Feb 13 19:48:16 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 13 Feb 2025 19:48:16 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh wrote: > This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java line 1: > 1: /* This test seems to be the more significant reason for this change - should the issue be renamed to something like "Add OCSP tests for various signature algorithms including PQC algorithms". The enhancements to the test library would then be more as an additional improvement in order to support this new test. test/lib/jdk/test/lib/security/CertificateBuilder.java line 462: > 460: throws CertificateException, IOException, NoSuchAlgorithmException { > 461: > 462: AlgorithmId signAlg; This variable looks like it is unused now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955119146 PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955105753 From mullan at openjdk.org Thu Feb 13 19:52:10 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 13 Feb 2025 19:52:10 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Thu, 13 Feb 2025 18:58:00 GMT, Sean Mullan wrote: >> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). > > Bug needs a `noreg-self` label. > @seanjmullan I wasn't sure if I should add that label because there is a test of these changes in `test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java`. However I did notice that I forgot to change the bug ID and summary in that test code, so I will update that. Given that there is a test included with the change, LMK if you still feel that it needs the noreg label and I will add it. That's a good question. I usually add the `noreg-self` label even it it is a brand new test and not a fix to an existing test and there is no other JDK code changes. @JesperIRL do you have any advice for this situation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2657569848 From mullan at openjdk.org Thu Feb 13 19:55:09 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 13 Feb 2025 19:55:09 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Thu, 13 Feb 2025 19:45:19 GMT, Sean Mullan wrote: >> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). > > test/lib-test/jdk/test/lib/security/CPVAlgTestWithOCSP.java line 1: > >> 1: /* > > This test seems to be the more significant reason for this change - should the issue be renamed to something like "Add OCSP tests for various signature algorithms including PQC algorithms". The enhancements to the test library would then be more as an additional improvement in order to support this new test. Also, should it be moved to somewhere else like jdk/test/sun/security/provider/certpath? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955130339 From jwilhelm at openjdk.org Thu Feb 13 20:04:09 2025 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 13 Feb 2025 20:04:09 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Thu, 13 Feb 2025 19:49:37 GMT, Sean Mullan wrote: > That's a good question. I usually add the `noreg-self` label even it it is a brand new test and not a fix to an existing test and there is no other JDK code changes. @JesperIRL do you have any advice for this situation? `noreg-self` is used to indicate that a change touches test code only. It doesn't matter if it's adding new tests or changing existing tests. As long as there are no product code changes the label should be there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23566#issuecomment-2657594924 From liach at openjdk.org Thu Feb 13 20:07:09 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 13 Feb 2025 20:07:09 GMT Subject: RFR: 8349943: [JMH] Use jvmArgs consistently In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> Message-ID: On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote: > As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'. > > All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency. The java.lang.foreign arg changes look fine. ------------- PR Review: https://git.openjdk.org/jdk/pull/23609#pullrequestreview-2616102653 From wetmore at openjdk.org Thu Feb 13 20:13:10 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 13 Feb 2025 20:13:10 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec In-Reply-To: References: Message-ID: <52BquBx70psY48sxAOU0oMkM9Ia51OnQvYT-EvMDvFg=.6ffd7120-96b3-47b0-9bd1-c742074f3c35@github.com> On Thu, 13 Feb 2025 19:37:39 GMT, Daniel Jeli?ski wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java line 124: >> >>> 122: } else if (tlsVersion == 0x0303) { >>> 123: mechanism = CKM_TLS12_KEY_AND_MAC_DERIVE; >>> 124: } >> >> So this hasn't worked since the TLSv1.2 support was added in 2018? Ouch! >> >> I wonder if how many are using PKCS11 for TLS. Seems like this should have been found earlier. >> >> Double check with @valeriepeng , but looks ok to me... > > It's not that bad, the crash only happens when you (mis-)use SunTlsKeyMaterial instead of SunTls12KeyMaterial with TLS 1.2. JSSE uses the correct one. I only hit this bug when experimenting with tests. Whew...thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1955151548 From jnimeh at openjdk.org Thu Feb 13 22:32:10 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 13 Feb 2025 22:32:10 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms In-Reply-To: References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Thu, 13 Feb 2025 19:52:32 GMT, Sean Mullan wrote: > Also, should it be moved to somewhere else like jdk/test/sun/security/provider/certpath? Hmmm...not sure about that, but maybe an explanation is in order: Because the JDK only implements the client side with OCSP, we rely on CertPathValidator to handle the path validation and that has never been a problem with PQC. When I did OCSP stapling a long time ago (JDK 9) that was when I wanted a way to build certs (good and malformed ones) and make OCSP servers that didn't need to fork processes outside the jtreg framework or need 3rd party code. That meant I had to implement the server-side (consumption of requests and generation of responses) and that's where things needed some tuning up. So it isn't really a CPV problem, it's a testcode problem. In order to exercise it and ensure that it worked for all the algs we use to sign stuff, I made this test-the-test-code test and at the suggestion of @rhalade I located in the lib-test tree. Using CPV in the test was mainly a way for me to drive the OCSP request from the JDK code. that is also validates consumption of the signed response and the cert chain is a nice freebie. Not opposed to making the changes, I just didn't know if it was the right way to go considering that I'm not changing any actual JDK code, just test helper classes so in the future we can do PQC cert chains and OCSP servers for our tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955301602 From duke at openjdk.org Thu Feb 13 22:40:22 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Thu, 13 Feb 2025 22:40:22 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc 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](https://github.com/user-attachments/assets/2c58dd82-363e-49be-9734-755d5d0014d7) 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. ------------- Commit messages: - 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 Changes: https://git.openjdk.org/jdk/pull/23569/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328914 Stats: 184 lines in 1 file changed: 184 ins; 0 del; 0 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 jnimeh at openjdk.org Thu Feb 13 22:47:29 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 13 Feb 2025 22:47:29 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms [v2] In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: > This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Fix JBS ID and summary in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23566/files - new: https://git.openjdk.org/jdk/pull/23566/files/bec2b43c..8c16daba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23566/head:pull/23566 PR: https://git.openjdk.org/jdk/pull/23566 From jnimeh at openjdk.org Thu Feb 13 22:47:29 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 13 Feb 2025 22:47:29 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms [v2] In-Reply-To: References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Thu, 13 Feb 2025 19:34:04 GMT, Sean Mullan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix JBS ID and summary in test > > test/lib/jdk/test/lib/security/CertificateBuilder.java line 462: > >> 460: throws CertificateException, IOException, NoSuchAlgorithmException { >> 461: >> 462: AlgorithmId signAlg; > > This variable looks like it is unused now. It's used on 476 for encoding the AlgorithmIdentifier of the certificate signature, and also on 530 to again provide that same AlgorithmIdentifier encoding in the TBSCertificate strructure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1955313651 From jnimeh at openjdk.org Thu Feb 13 23:50:50 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 13 Feb 2025 23:50:50 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms [v3] In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: > This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary throws declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23566/files - new: https://git.openjdk.org/jdk/pull/23566/files/8c16daba..d0c95035 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=01-02 Stats: 16 lines in 1 file changed: 0 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23566/head:pull/23566 PR: https://git.openjdk.org/jdk/pull/23566 From syan at openjdk.org Fri Feb 14 01:59:09 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 14 Feb 2025 01:59:09 GMT Subject: RFR: 8349943: [JMH] Use jvmArgs consistently In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> Message-ID: On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote: > As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'. > > All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency. LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/23609#pullrequestreview-2616591288 From jpai at openjdk.org Fri Feb 14 07:36:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 14 Feb 2025 07:36:09 GMT Subject: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote: > This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates. > > 2 other smaller changes: > - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead > - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`) Hello Sean, given the assertable change to the API documentation of `java.net.JarURLConnection.getCertificates()`, which now specifies the order of the returned certificates, would this require a CSR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23616#issuecomment-2658490788 From fguallini at openjdk.org Fri Feb 14 10:30:20 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 14 Feb 2025 10:30:20 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version Message-ID: This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). There are some differences between the 1.1.x and the current OpenSSL version: - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it. Additionally, It is also required to specify the path location of the legacy provider. - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead. ------------- Commit messages: - typo - it should be isX64 rather than is64bit - refactoring - using openssl 3.0.14 Changes: https://git.openjdk.org/jdk/pull/23613/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23613&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349492 Stats: 63 lines in 2 files changed: 25 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/23613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23613/head:pull/23613 PR: https://git.openjdk.org/jdk/pull/23613 From mullan at openjdk.org Fri Feb 14 14:01:18 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 14 Feb 2025 14:01:18 GMT Subject: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection In-Reply-To: References: Message-ID: <5-IbyV3FMMgxeor0wNyMY7oern2RMDpHUpFucsEM0wc=.4e43672a-60b6-461c-8a92-d279eb2f5e0e@github.com> On Fri, 14 Feb 2025 07:33:58 GMT, Jaikiran Pai wrote: > Hello Sean, given the assertable change to the API documentation of `java.net.JarURLConnection.getCertificates()`, which now specifies the order of the returned certificates, would this require a CSR? Yes, I think we should. I'll do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23616#issuecomment-2659404074 From mullan at openjdk.org Fri Feb 14 14:23:16 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 14 Feb 2025 14:23:16 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 19:16:01 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/2c58dd82-363e-49be-9734-755d5d0014d7) > > 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. @koushikthirupattur I think this will require a CSR. Even though it is a property that we have supported for a long time, I am pretty sure it is the first time we have documented it in the javadocs. Contact me if you need help writing the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2659462858 From mullan at openjdk.org Fri Feb 14 14:33:10 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 14 Feb 2025 14:33:10 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms [v3] In-Reply-To: References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: <2VARXTrDTQGfsXEIissc_EWqjZf2m8HZeJ2bse-qnII=.854008de-a31c-4b73-a609-3b2113c20df1@github.com> On Thu, 13 Feb 2025 22:43:39 GMT, Jamil Nimeh wrote: >> test/lib/jdk/test/lib/security/CertificateBuilder.java line 462: >> >>> 460: throws CertificateException, IOException, NoSuchAlgorithmException { >>> 461: >>> 462: AlgorithmId signAlg; >> >> This variable looks like it is unused now. > > It's used on 476 for encoding the AlgorithmIdentifier of the certificate signature, and also on 530 to again provide that same AlgorithmIdentifier encoding in the TBSCertificate strructure. You mean lines 458 and 466? Yes, I missed that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1956240646 From weijun at openjdk.org Fri Feb 14 15:06:10 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 15:06:10 GMT Subject: RFR: 8345598: Upgrade NSS binaries for interop tests In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 19:28:18 GMT, Matthew Donovan wrote: > This is a trivial PR to update the version of NSS used for pkcs11 tests. Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23594#pullrequestreview-2618045735 From weijun at openjdk.org Fri Feb 14 15:10:13 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 15:10:13 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v3] In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 13:48:26 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: > > changed to use a scratch directory test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 63: > 61: private static final SunPKCS11[] providers = new SunPKCS11[NUM_PROVIDERS]; > 62: > 63: private static void copyDbFiles() throws IOException { We have existing utility method for this at https://github.com/openjdk/jdk/blob/a49f8332edc7da2a9494cd0dc96e5aa7271d9883/test/jdk/sun/security/pkcs11/PKCS11Test.java#L846. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23590#discussion_r1956296145 From weijun at openjdk.org Fri Feb 14 15:15:13 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 15:15:13 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 19:16:01 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/2c58dd82-363e-49be-9734-755d5d0014d7) > > 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. Like what `java/net` did, we need a link from `java/security/package-info.java` to this new file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2659588466 From weijun at openjdk.org Fri Feb 14 15:18:20 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 15:18:20 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 19:16:01 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/2c58dd82-363e-49be-9734-755d5d0014d7) > > 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. Please also mention the `+thread` and `+timestamp` modifiers. Also, at the beginning, there is no default value for this system property. It is not `false`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2659595775 From weijun at openjdk.org Fri Feb 14 15:22:15 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 15:22:15 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 19:16:01 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/2c58dd82-363e-49be-9734-755d5d0014d7) > > 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. The `ava` sub-option for `x509` is not included. BTW, I see the rows are in alphabetical order now, this is great. Can we also reorder the help output at https://github.com/openjdk/jdk/blob/940aa7c4cf1bf770690660c8bb21fb3ddc5186e4/src/java.base/share/classes/sun/security/util/Debug.java#L85? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2659604044 From weijun at openjdk.org Fri Feb 14 15:27:12 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 15:27:12 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v3] In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 17:10:37 GMT, Leonid Mesnik wrote: >> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8346050' of https://github.com/lmesnik/jdk into 8346050 > - renamed excludes test/lib/jdk/test/lib/security/XMLUtils.java line 557: > 555: } > 556: > 557: //////////// MISC //////////// This is a section break for various groups of methods in this utility class. Before this there has been //////////// CONVERT //////////// //////////// QUERY AND EDIT //////////// //////////// SIGN //////////// //////////// VALIDATE //////////// Can you keep the format? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1956321630 From fguallini at openjdk.org Fri Feb 14 15:38:15 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 14 Feb 2025 15:38:15 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 14:58:55 GMT, Weijun Wang wrote: > The "preferred version" sounds like user can choose one. I'd rather just say "latest version". At least that is the latest our test has access to. Also, I assume you will update to newer versions later and this test is not meant to run with only the "current" version (like it used to do). True, it may sound like that. The reason I didn't use 'latest version' was that it might not always be required to be updated for every minor release, since building the binaries is time consuming. Maybe 'recent' version which does not necessarily mean the very latest ? or 'defined' in OpensslArtifactFetcher. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23613#issuecomment-2659646559 From mullan at openjdk.org Fri Feb 14 16:42:11 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 14 Feb 2025 16:42:11 GMT Subject: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection In-Reply-To: <5-IbyV3FMMgxeor0wNyMY7oern2RMDpHUpFucsEM0wc=.4e43672a-60b6-461c-8a92-d279eb2f5e0e@github.com> References: <5-IbyV3FMMgxeor0wNyMY7oern2RMDpHUpFucsEM0wc=.4e43672a-60b6-461c-8a92-d279eb2f5e0e@github.com> Message-ID: On Fri, 14 Feb 2025 13:57:12 GMT, Sean Mullan wrote: > > Hello Sean, given the assertable change to the API documentation of `java.net.JarURLConnection.getCertificates()`, which now specifies the order of the returned certificates, would this require a CSR? > > Yes, I think we should. I'll do that. Please review the CSR at https://bugs.openjdk.org/browse/JDK-8350117. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23616#issuecomment-2659794172 From fguallini at openjdk.org Fri Feb 14 16:46:52 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 14 Feb 2025 16:46:52 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version [v2] In-Reply-To: References: Message-ID: <_wIxUFRMeth1yDAycbTHCt0u6g0GC1QyXtLFiXoIYck=.d7e646ac-7ccb-4ba4-89bf-baf4689de490@github.com> > This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). > There are some differences between the 1.1.x and the current OpenSSL version: > - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it. Additionally, It is also required to specify the path location of the legacy provider. > - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: provider path depends on platform ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23613/files - new: https://git.openjdk.org/jdk/pull/23613/files/fad232e2..4b2dcbbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23613&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23613&range=00-01 Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23613/head:pull/23613 PR: https://git.openjdk.org/jdk/pull/23613 From bperez at openjdk.org Fri Feb 14 16:48:30 2025 From: bperez at openjdk.org (Ben Perez) Date: Fri, 14 Feb 2025 16:48:30 GMT Subject: RFR: 8347606: Optimize Java implementation of ML-DSA Message-ID: 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%. ------------- Commit messages: - Changed copyright, removed unnecessary comment - Added optimized boolean matrix allocs - Created optimized matrixAllocate method for 2d arrays Changes: https://git.openjdk.org/jdk/pull/23642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23642&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347606 Stats: 56 lines in 1 file changed: 23 ins; 1 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/23642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23642/head:pull/23642 PR: https://git.openjdk.org/jdk/pull/23642 From duke at openjdk.org Fri Feb 14 17:14:10 2025 From: duke at openjdk.org (Bernd) Date: Fri, 14 Feb 2025 17:14:10 GMT Subject: RFR: 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%. src/java.base/share/classes/sun/security/provider/ML_DSA.java line 1237: > 1235: return res; > 1236: } > 1237: Centralizing the allocation into a helper on its own Looks unseful (for resource Management, debugging/profiling and to pick the optimal implementation). but it?s a shame that 2 dimensional allocations are sub-optimal, shouldnt that be addressed in the jvm (or c2?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23642#discussion_r1956478480 From lancea at openjdk.org Fri Feb 14 17:15:10 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 14 Feb 2025 17:15:10 GMT Subject: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection In-Reply-To: References: Message-ID: <6vbP0qpKwSo0mMMTga3gxh-nfJ7LokJKxSxp_J_t9PU=.8c19f2c2-1e06-4cc4-916d-2596b34ed4dc@github.com> On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote: > This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates. > > 2 other smaller changes: > - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead > - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`) Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23616#pullrequestreview-2618386370 From weijun at openjdk.org Fri Feb 14 17:23:15 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 17:23:15 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version [v2] In-Reply-To: <_wIxUFRMeth1yDAycbTHCt0u6g0GC1QyXtLFiXoIYck=.d7e646ac-7ccb-4ba4-89bf-baf4689de490@github.com> References: <_wIxUFRMeth1yDAycbTHCt0u6g0GC1QyXtLFiXoIYck=.d7e646ac-7ccb-4ba4-89bf-baf4689de490@github.com> Message-ID: On Fri, 14 Feb 2025 16:46:52 GMT, Fernando Guallini wrote: >> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). >> There are some differences between the 1.1.x and the current OpenSSL version: >> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it. Additionally, It is also required to specify the path location of the legacy provider. >> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > provider path depends on platform Or "current version". I regret using this in my previous comment. I meant "this one particular version" there. And yes, it will be clear if you mention the "current version as defined by ...". ------------- PR Comment: https://git.openjdk.org/jdk/pull/23613#issuecomment-2659876941 From lmesnik at openjdk.org Fri Feb 14 18:22:26 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 14 Feb 2025 18:22:26 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v4] In-Reply-To: References: Message-ID: > The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - added copyrights - replaced commens fix with supress ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23525/files - new: https://git.openjdk.org/jdk/pull/23525/files/4813daed..83d688b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23525&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23525&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23525/head:pull/23525 PR: https://git.openjdk.org/jdk/pull/23525 From lmesnik at openjdk.org Fri Feb 14 18:22:26 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 14 Feb 2025 18:22:26 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v4] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 15:24:53 GMT, Weijun Wang wrote: >> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: >> >> - added copyrights >> - replaced commens fix with supress > > test/lib/jdk/test/lib/security/XMLUtils.java line 557: > >> 555: } >> 556: >> 557: // MISC > > This is a section break for various groups of methods in this utility class. Before this there have been > > //////////// CONVERT //////////// > //////////// QUERY AND EDIT //////////// > //////////// SIGN //////////// > //////////// VALIDATE //////////// > > Can you keep the format? sure, since such comments are cause warning, i just suppress them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1956557342 From duke at openjdk.org Fri Feb 14 19:12:51 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 14 Feb 2025 19:12:51 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v2] 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](https://github.com/user-attachments/assets/2c58dd82-363e-49be-9734-755d5d0014d7) > > 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/57901731..1067f1a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=00-01 Stats: 20 lines in 2 files changed: 18 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 Fri Feb 14 19:12:51 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 14 Feb 2025 19:12:51 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 15:12:54 GMT, Weijun Wang wrote: > Like what `java/net` did, we need a link from `java/security/package-info.java` to this new file. Added. > Please also mention the `+thread` and `+timestamp` modifiers. Also, at the beginning, there is no default value for this system property. It is not `false`. Added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2660076138 PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2660076700 From weijun at openjdk.org Fri Feb 14 19:19:12 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 19:19:12 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 19:12:51 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/2c58dd82-363e-49be-9734-755d5d0014d7) >> >> 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 The name and title should not be "Security Properties". This is about the debug system property. Also, now we have the same content in 3 places: 1. Here 2. In the Security Guide at https://docs.oracle.com/en/java/javase/23/security/troubleshooting-security.html#GUID-05F3E865-20FF-46EB-AC35-84D4B552CA48 3. At https://github.com/openjdk/jdk/blob/940aa7c4cf1bf770690660c8bb21fb3ddc5186e4/src/java.base/share/classes/sun/security/util/Debug.java#L85. Do we need to keep all of them? @seanjmullan ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2660086362 PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2660088624 From weijun at openjdk.org Fri Feb 14 19:27:12 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 19:27:12 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v4] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 19:23:54 GMT, Weijun Wang wrote: >> sure, since such comments are cause warning, i just suppress them. > > Oh, they were recognized as Markdown javadoc? I didn't think of that. > > It's strange that the other 4 show no warning, and then I noticed that changing it to > > //////////// MISC //////////// > > // Adds a new rule to "jdk.xml.dsig.secureValidationPolicy" > > can also let the warning go away. The problem is it now treats the `///` line as javadoc and `//` as nothing. This is definitely not right. Maybe I'll do some cleanup later. That said, this is just a test utility class. I'm OK with whatever style at the moment. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1956623296 From weijun at openjdk.org Fri Feb 14 19:27:12 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 19:27:12 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v4] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 18:19:17 GMT, Leonid Mesnik wrote: >> test/lib/jdk/test/lib/security/XMLUtils.java line 557: >> >>> 555: } >>> 556: >>> 557: // MISC >> >> This is a section break for various groups of methods in this utility class. Before this there have been >> >> //////////// CONVERT //////////// >> //////////// QUERY AND EDIT //////////// >> //////////// SIGN //////////// >> //////////// VALIDATE //////////// >> >> Can you keep the format? > > sure, since such comments are cause warning, i just suppress them. Oh, they were recognized as Markdown javadoc? I didn't think of that. It's strange that the other 4 show no warning, and then I noticed that changing it to //////////// MISC //////////// // Adds a new rule to "jdk.xml.dsig.secureValidationPolicy" can also let the warning go away. The problem is it now treats the `///` line as javadoc and `//` as nothing. This is definitely not right. Maybe I'll do some cleanup later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23525#discussion_r1956622006 From mullan at openjdk.org Fri Feb 14 21:16:43 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 14 Feb 2025 21:16:43 GMT Subject: RFR: 8315487: Security Providers Filter [v20] In-Reply-To: References: Message-ID: On Wed, 12 Feb 2025 21:52:57 GMT, Martin Balao wrote: >> 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 all... > > Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - 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 > I have been starting to review the code, and am initially reviewing this with respect to how it complies with the current API specification. > > All of the JCA API `getInstance` methods that do not have a provider argument have text like the following: > > > This method traverses the list of registered security Providers, starting with the most preferred Provider. A new `` object encapsulating the `Spi` implementation from the first provider that supports the specified algorithm is returned. > > However, the providers filter can be configured to prevent that object from being returned. I think this is an important difference in behavior that it should be documented as an implementation note. My initial suggestion is something like the following: > > "The JDK Reference Implementation additionally uses the `jdk.security.providers.filter` system and security property to determine which services are enabled. A provider whose algorithm is not enabled by the filter will not be selected." > > I think similar text will need to be added in the `Provider` API, but I need to review those changes more closely first. @martinuy Any comments on the above? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2660279702 From ascarpino at openjdk.org Fri Feb 14 21:27:40 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 14 Feb 2025 21:27:40 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage Message-ID: Hi, I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. thanks Tony ------------- Commit messages: - spacing - immutable - Merge branch 'ef' into xdhed - comments - cleanup - more cleanup - cleanup, both tests still pass - passing two tests - cleanup Changes: https://git.openjdk.org/jdk/pull/23647/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23647&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346129 Stats: 242 lines in 5 files changed: 218 ins; 3 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/23647.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23647/head:pull/23647 PR: https://git.openjdk.org/jdk/pull/23647 From weijun at openjdk.org Fri Feb 14 21:28:45 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Feb 2025 21:28:45 GMT Subject: RFR: 8350134: Get public key from EC private key in PKCS11 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. ------------- Commit messages: - the code change Changes: https://git.openjdk.org/jdk/pull/23651/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23651&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350134 Stats: 202 lines in 10 files changed: 166 ins; 10 del; 26 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 fferrari at openjdk.org Fri Feb 14 21:53:17 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Fri, 14 Feb 2025 21:53:17 GMT Subject: RFR: 8315487: Security Providers Filter [v20] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 21:13:45 GMT, Sean Mullan wrote: >> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - 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 > >> I have been starting to review the code, and am initially reviewing this with respect to how it complies with the current API specification. >> >> All of the JCA API `getInstance` methods that do not have a provider argument have text like the following: >> >> > This method traverses the list of registered security Providers, starting with the most preferred Provider. A new `` object encapsulating the `Spi` implementation from the first provider that supports the specified algorithm is returned. >> >> However, the providers filter can be configured to prevent that object from being returned. I think this is an important difference in behavior that it should be documented as an implementation note. My initial suggestion is something like the following: >> >> "The JDK Reference Implementation additionally uses the `jdk.security.providers.filter` system and security property to determine which services are enabled. A provider whose algorithm is not enabled by the filter will not be selected." >> >> I think similar text will need to be added in the `Provider` API, but I need to review those changes more closely first. > > @martinuy Any comments on the above? Hi @seanjmullan, We agree, including the need for documenting this in `Provider::getService` and `Provider::getServices`. We will make these changes in the coming days, we were first addressing #22613 changes and adjusting this PR which depends on it. The two PRs are now in sync, so feel free to continue your review in the meantime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2660337392 From wetmore at openjdk.org Sat Feb 15 05:07:37 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 15 Feb 2025 05:07:37 GMT Subject: RFR: 8350147: Replace example in KEM class with the one from JEP 452 Message-ID: The example code in the JEP was much clearer than that in the current `KEM` class. It's easier to keep the various nested classes straight, rather than using `var`s which require scrolling to see what the return types are. Added/tweaked example for clarity. Generated/checked javadocs, but no regression/JCK tests is necessary. ------------- Commit messages: - 8350147: Replace example in KEM class with the one from JEP 452 Changes: https://git.openjdk.org/jdk/pull/23652/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23652&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350147 Stats: 32 lines in 1 file changed: 18 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/23652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23652/head:pull/23652 PR: https://git.openjdk.org/jdk/pull/23652 From weijun at openjdk.org Sat Feb 15 14:33:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 15 Feb 2025 14:33:18 GMT Subject: RFR: 8350147: Replace example in KEM class with the one from JEP 452 In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 05:02:44 GMT, Bradford Wetmore wrote: > The example code in the JEP was much clearer than that in the current `KEM` class. It's easier to keep the various nested classes straight, rather than using `var`s which require scrolling to see what the return types are. > > Added/tweaked example for clarity. > > Generated/checked javadocs, but no regression/JCK tests is necessary. src/java.base/share/classes/javax/crypto/KEM.java line 76: > 74: * > 75: * // Sender side > 76: * KEM senderKEM = KEM.getInstance("ABC-KEM"); Maybe we should rename the `KEM` and `AlgorithmParameters` algorithms to "ABC". Modern KEM and signature algorithms are usually the same as the key algorithm names. src/java.base/share/classes/javax/crypto/KEM.java line 78: > 76: * KEM senderKEM = KEM.getInstance("ABC-KEM"); > 77: * PublicKey receiverPublicKey = retrieveKey(); > 78: * ABCKEMParameterSpec spec = new ABCKEMParameterSpec(...); Maybe we can rename `spec` to `senderSpec`. We already have `senderKEM` and `senderSecret`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23652#discussion_r1957127490 PR Review Comment: https://git.openjdk.org/jdk/pull/23652#discussion_r1957127860 From jpai at openjdk.org Sat Feb 15 15:27:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 15 Feb 2025 15:27:09 GMT Subject: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote: > This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates. > > 2 other smaller changes: > - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead > - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`) Thank you Sean, this looks good to me. I've reviewed the CSR as well. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23616#pullrequestreview-2619433656 From wetmore at openjdk.org Sat Feb 15 20:38:11 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 15 Feb 2025 20:38:11 GMT Subject: RFR: 8350147: Replace example in KEM class with the one from JEP 452 In-Reply-To: References: Message-ID: <6CuzN5Ty20eg7YPXShP0PhG8b9Xu1uxO7R26SALrRQY=.58fc91f9-86b9-4690-ad5e-ff1e96165037@github.com> On Sat, 15 Feb 2025 14:28:04 GMT, Weijun Wang wrote: >> The example code in the JEP was much clearer than that in the current `KEM` class. It's easier to keep the various nested classes straight, rather than using `var`s which require scrolling to see what the return types are. >> >> Added/tweaked example for clarity. >> >> Generated/checked javadocs, but no regression/JCK tests is necessary. > > src/java.base/share/classes/javax/crypto/KEM.java line 76: > >> 74: * >> 75: * // Sender side >> 76: * KEM senderKEM = KEM.getInstance("ABC-KEM"); > > Maybe we should rename the `KEM` and `AlgorithmParameters` algorithms to "ABC". Modern KEM and signature algorithms are usually the same as the key algorithm names. Even after all the checks, I still missed one! ;) Yes, will update. > src/java.base/share/classes/javax/crypto/KEM.java line 78: > >> 76: * KEM senderKEM = KEM.getInstance("ABC-KEM"); >> 77: * PublicKey receiverPublicKey = retrieveKey(); >> 78: * ABCKEMParameterSpec spec = new ABCKEMParameterSpec(...); > > Maybe we can rename `spec` to `senderSpec`. We already have `senderKEM` and `senderSecret`. Sure, I debated on this...will update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23652#discussion_r1957186884 PR Review Comment: https://git.openjdk.org/jdk/pull/23652#discussion_r1957186912 From wetmore at openjdk.org Sat Feb 15 21:23:10 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 15 Feb 2025 21:23:10 GMT Subject: RFR: 8350147: Replace example in KEM class with the one from JEP 452 In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 14:28:04 GMT, Weijun Wang wrote: >> The example code in the JEP was much clearer than that in the current `KEM` class. It's easier to keep the various nested classes straight, rather than using `var`s which require scrolling to see what the return types are. >> >> Added/tweaked example for clarity. >> >> Generated/checked javadocs, but no regression/JCK tests is necessary. > > src/java.base/share/classes/javax/crypto/KEM.java line 76: > >> 74: * >> 75: * // Sender side >> 76: * KEM senderKEM = KEM.getInstance("ABC-KEM"); > > Maybe we should rename the `KEM` and `AlgorithmParameters` algorithms to "ABC". Modern KEM and signature algorithms are usually the same as the key algorithm names. Sure, I can update this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23652#discussion_r1957192971 From wetmore at openjdk.org Sat Feb 15 21:44:23 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 15 Feb 2025 21:44:23 GMT Subject: RFR: 8350147: Replace example in KEM class with the one from JEP 452 [v2] In-Reply-To: References: Message-ID: > The example code in the JEP was much clearer than that in the current `KEM` class. It's easier to keep the various nested classes straight, rather than using `var`s which require scrolling to see what the return types are. > > Added/tweaked example for clarity. > > Generated/checked javadocs, but no regression/JCK tests is necessary. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Codereview Comments from Weijun ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23652/files - new: https://git.openjdk.org/jdk/pull/23652/files/d0a9900e..70a3ae85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23652&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23652&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23652/head:pull/23652 PR: https://git.openjdk.org/jdk/pull/23652 From wetmore at openjdk.org Sat Feb 15 22:33:46 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 15 Feb 2025 22:33:46 GMT Subject: RFR: 8350147: Replace example in KEM class with the one from JEP 452 [v3] In-Reply-To: References: Message-ID: > The example code in the JEP was much clearer than that in the current `KEM` class. It's easier to keep the various nested classes straight, rather than using `var`s which require scrolling to see what the return types are. > > Added/tweaked example for clarity. > > Generated/checked javadocs, but no regression/JCK tests is necessary. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Further codereview Comments from Weijun ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23652/files - new: https://git.openjdk.org/jdk/pull/23652/files/70a3ae85..fa3d293f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23652&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23652&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23652/head:pull/23652 PR: https://git.openjdk.org/jdk/pull/23652 From wetmore at openjdk.org Sat Feb 15 22:43:15 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 15 Feb 2025 22:43:15 GMT Subject: Integrated: 8350147: Replace example in KEM class with the one from JEP 452 In-Reply-To: References: Message-ID: <3H68CiAe5JB4PVkeTffBttCD9QFVKfDJ2gl_C2LbrFs=.09b13a8b-7f4e-493e-903a-c30452280363@github.com> On Sat, 15 Feb 2025 05:02:44 GMT, Bradford Wetmore wrote: > The example code in the JEP was much clearer than that in the current `KEM` class. It's easier to keep the various nested classes straight, rather than using `var`s which require scrolling to see what the return types are. > > Added/tweaked example for clarity. > > Generated/checked javadocs, but no regression/JCK tests is necessary. This pull request has now been integrated. Changeset: 7d11418c Author: Bradford Wetmore URL: https://git.openjdk.org/jdk/commit/7d11418c820b46926a25907766d16083a4b349de Stats: 32 lines in 1 file changed: 18 ins; 2 del; 12 mod 8350147: Replace example in KEM class with the one from JEP 452 Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/23652 From weijun at openjdk.org Sat Feb 15 22:43:14 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 15 Feb 2025 22:43:14 GMT Subject: RFR: 8350147: Replace example in KEM class with the one from JEP 452 [v3] In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 22:33:46 GMT, Bradford Wetmore wrote: >> The example code in the JEP was much clearer than that in the current `KEM` class. It's easier to keep the various nested classes straight, rather than using `var`s which require scrolling to see what the return types are. >> >> Added/tweaked example for clarity. >> >> Generated/checked javadocs, but no regression/JCK tests is necessary. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Further codereview Comments from Weijun LGTM. Thanks! ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23652#pullrequestreview-2619504934 From duke at openjdk.org Sun Feb 16 06:31:50 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Sun, 16 Feb 2025 06:31:50 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v3] In-Reply-To: References: Message-ID: <-AWm3AZxUC0NY-xa0imjSIQA1-mToci-Umo9MRvP0EE=.e7f3ae40-256a-42b9-9d96-5d82fb9b1285@github.com> > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23315/files - new: https://git.openjdk.org/jdk/pull/23315/files/0e288ec5..672d7b7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=01-02 Stats: 50 lines in 3 files changed: 4 ins; 44 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23315/head:pull/23315 PR: https://git.openjdk.org/jdk/pull/23315 From weijun at openjdk.org Sun Feb 16 14:39:15 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sun, 16 Feb 2025 14:39:15 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v3] In-Reply-To: <-AWm3AZxUC0NY-xa0imjSIQA1-mToci-Umo9MRvP0EE=.e7f3ae40-256a-42b9-9d96-5d82fb9b1285@github.com> References: <-AWm3AZxUC0NY-xa0imjSIQA1-mToci-Umo9MRvP0EE=.e7f3ae40-256a-42b9-9d96-5d82fb9b1285@github.com> Message-ID: <7N1FVrrOzWgg0NTI15DX22d_aJhL4URdZCFB04Y4Syw=.5c1f2896-a886-4d0e-96c4-6fae779c1671@github.com> On Sun, 16 Feb 2025 06:31:50 GMT, Konanki Sreenath wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases test/jdk/sun/security/x509/X509CertImpl/CertificateExtensions.java line 1: > 1: /* Another test `V3Certificate` in the same directory references the internal `CertificateExtensions` class by its simple name. There is a conflict with this new test and it does not compile. Consider renaming your new test. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1957341274 From liach at openjdk.org Sun Feb 16 15:44:10 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 16 Feb 2025 15:44:10 GMT Subject: RFR: 8347606: Optimize Java implementation of ML-DSA In-Reply-To: References: Message-ID: <00EzhUrlzMd_TKb6YcnzMmlnwS5MEwgsysLU9ZcAiz4=.df755691-d83f-4002-b195-e0b9b34f70f1@github.com> On Fri, 14 Feb 2025 17:11:16 GMT, Bernd 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%. > > src/java.base/share/classes/sun/security/provider/ML_DSA.java line 1237: > >> 1235: return res; >> 1236: } >> 1237: > > Centralizing the allocation into a helper on its own Looks unseful (for resource Management, debugging/profiling and to pick the optimal implementation). > > but it?s a shame that 2 dimensional allocations are sub-optimal, shouldnt that be addressed in the jvm (or c2?) Indeed, it's better if hotspot can recognize and optimize the bytecode sequence generated by javac, or javac should generate bytecode like these methods to speed up allocation in general. Is splitting the allocation into a dedicated method a factor? I know this may affect JIT compilation heuristics. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23642#discussion_r1957355167 From fguallini at openjdk.org Mon Feb 17 11:06:09 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Mon, 17 Feb 2025 11:06:09 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version [v4] In-Reply-To: References: Message-ID: > This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). > There are some differences between the 1.1.x and the current OpenSSL version: > - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it. Additionally, It is also required to specify the path location of the legacy provider. > - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead. Fernando Guallini 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 'master' into JDK-8349492 - updated wording in KeytoolOpensslInteropTest - updated wording - provider path depends on platform - typo - it should be isX64 rather than is64bit - refactoring - using openssl 3.0.14 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23613/files - new: https://git.openjdk.org/jdk/pull/23613/files/6df5414e..bcb87952 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23613&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23613&range=02-03 Stats: 10686 lines in 438 files changed: 8011 ins; 1123 del; 1552 mod Patch: https://git.openjdk.org/jdk/pull/23613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23613/head:pull/23613 PR: https://git.openjdk.org/jdk/pull/23613 From fguallini at openjdk.org Mon Feb 17 11:20:13 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Mon, 17 Feb 2025 11:20:13 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version [v2] In-Reply-To: References: <_wIxUFRMeth1yDAycbTHCt0u6g0GC1QyXtLFiXoIYck=.d7e646ac-7ccb-4ba4-89bf-baf4689de490@github.com> Message-ID: On Fri, 14 Feb 2025 17:20:11 GMT, Weijun Wang wrote: > Or "current version". I regret using this in my previous comment. I meant "this one particular version" there. > > And yes, it will be clear if you mention the "current version as defined by ...". Thanks, updated now ------------- PR Comment: https://git.openjdk.org/jdk/pull/23613#issuecomment-2662810778 From duke at openjdk.org Mon Feb 17 11:46:49 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Mon, 17 Feb 2025 11:46:49 GMT Subject: RFR: 8349664: Certificate.java toString HEX dump should always use ASCII or ISO_8859_1 Message-ID: Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. ------------- Commit messages: - 8349664: Certificate.java toString HEX dump should always use ASCII or ISO_8859_1 Changes: https://git.openjdk.org/jdk/pull/23661/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23661&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349664 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23661/head:pull/23661 PR: https://git.openjdk.org/jdk/pull/23661 From duke at openjdk.org Mon Feb 17 14:10:47 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 17 Feb 2025 14:10:47 GMT Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM 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. ------------- Commit messages: - removing trailing spaces - kyber aarch64 intrinsics Changes: https://git.openjdk.org/jdk/pull/23663/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349721 Stats: 2885 lines in 20 files changed: 2774 ins; 84 del; 27 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 alanb at openjdk.org Mon Feb 17 15:26:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 17 Feb 2025 15:26:14 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules [v2] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer wrote: >> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. >> >> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 >> >> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. >> >> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Update @serialData text to CSR-approved version I think this is oky, the CSR for the change writeExternal has already been reviewed. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2621362315 From hannesw at openjdk.org Mon Feb 17 15:34:16 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 17 Feb 2025 15:34:16 GMT Subject: Integrated: 8347123: Add missing @serial tags to other modules In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 20:13:50 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. This pull request has now been integrated. Changeset: 3f0c1370 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/3f0c1370269db978072814c2170fc3987efade85 Stats: 104 lines in 39 files changed: 45 ins; 0 del; 59 mod 8347123: Add missing @serial tags to other modules Reviewed-by: prr, nbenalla, alanb ------------- PR: https://git.openjdk.org/jdk/pull/22980 From fguallini at openjdk.org Mon Feb 17 18:55:15 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Mon, 17 Feb 2025 18:55:15 GMT Subject: RFR: 8342238: Test javax/crypto/CryptoPermissions/InconsistentEntries.java writes files in tested JDK dir In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:20:27 GMT, Fernando Guallini wrote: > The test javax/crypto/CryptoPermissions/InconsistentEntries.java should not modify the JDK home directory under test as that could impact the results of other tests, or it could fail if the JDK home dir is read-only. > > This PR updates the test to > > - clone the tested JDK into the scratch directory. > - create the required directory and file in the cloned JDK directory. > - run a subprocess using the temporal JDK to test the scenario. > > There is no need to explicitly remove the tests files with an 'after' step, as JTreg will handle cleaning the scratch directory Hi, please a review is needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23202#issuecomment-2663886806 From duke at openjdk.org Tue Feb 18 11:45:57 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Tue, 18 Feb 2025 11:45:57 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v4] In-Reply-To: References: Message-ID: <4UFgjU5Myevjoy_UgHCwGAHJMsObWKrVGueYDLfOg3s=.2b3bf170-2176-4c62-94c1-d3bc5d6f189f@github.com> > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23315/files - new: https://git.openjdk.org/jdk/pull/23315/files/672d7b7e..87a1c164 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23315/head:pull/23315 PR: https://git.openjdk.org/jdk/pull/23315 From adinn at openjdk.org Tue Feb 18 13:36:27 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 18 Feb 2025 13:36:27 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: <3kiI1J7jcczgzTRi9HZztzhGe1blcy8Ga11xoGhzueY=.98543172-5b38-4199-bead-0988de0e0e75@github.com> On Thu, 6 Feb 2025 18:47:54 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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: > > Adding comments + some code reorganization src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2594: > 2592: guarantee(T != T1Q && T != T1D, "incorrect arrangement"); \ > 2593: if (!acceptT2D) guarantee(T != T2D, "incorrect arrangement"); \ > 2594: if (strcmp(#NAME, "sqdmulh") == 0) guarantee(T != T8B && T != T16B, "incorrect arrangement"); \ Suggestion: I think it might be better to change this test from a strcmp call to (opc2 == 0b101101). The strcmp test is clearer to a reader of the code but the call may not be guaranteed to be compiled out at build time while the latter will. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1959758334 From adinn at openjdk.org Tue Feb 18 13:46:17 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 18 Feb 2025 13:46:17 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 18:47:54 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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: > > Adding comments + some code reorganization src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4066: > 4064: } > 4065: > 4066: // Execute on round of keccak of two computations in parallel. Suggestion: It would be helpful to add comments that relate the register and instruction selection to the original Java source code. e.g. change the header as follows // Performs 2 keccak round transformations using vector parallelism // // Two sets of 25 * 64-bit input states a0[lo:hi]...a24[lo:hi] are passed in // the lower/upper halves of registers v0...v24 and the transformed states // are returned in the same registers. Intermediate 64-bit pairs // c0...c5 and d0...d5 are computed in registers v25...v30. v31 is // loaded with the required pair of 64 bit rounding constants. // During computation of the output states some intermediate results are // shuffled around registers v0...v30. Comments on each line indicate // how the values in registers correspond to variables ai, ci, di in // the Java source code, likewise how the generated machine instructions // correspond to Java source operations (n.b. rol means rotate left). The annotate the generation steps as follows: __ eor3(v29, __ T16B, v4, v9, v14); // c4 = a4 ^ a9 ^ a14 __ eor3(v26, __ T16B, v1, v6, v11); // c1 = a1 ^ a16 ^ a11 __ eor3(v28, __ T16B, v3, v8, v13); // c3 = a3 ^ a8 ^a13 __ eor3(v25, __ T16B, v0, v5, v10); // c0 = a0 ^ a5 ^ a10 __ eor3(v27, __ T16B, v2, v7, v12); // c2 = a2 ^ a7 ^ a12 __ eor3(v29, __ T16B, v29, v19, v24); // c4 ^= a19 ^ a24 __ eor3(v26, __ T16B, v26, v16, v21); // c1 ^= a16 ^ a21 __ eor3(v28, __ T16B, v28, v18, v23); // c3 ^= a18 ^ a23 __ eor3(v25, __ T16B, v25, v15, v20); // c0 ^= a15 ^ a20 __ eor3(v27, __ T16B, v27, v17, v22); // c2 ^= a17 ^ a22 __ rax1(v30, __ T2D, v29, v26); // d0 = c4 ^ rol(c1, 1) __ rax1(v26, __ T2D, v26, v28); // d2 = c1 ^ rol(c3, 1) __ rax1(v28, __ T2D, v28, v25); // d4 = c3 ^ rol(c0, 1) __ rax1(v25, __ T2D, v25, v27); // d1 = c0 ^ rol(c2, 1) __ rax1(v27, __ T2D, v27, v29); // d3 = c2 ^ rol(c4, 1) __ eor(v0, __ T16B, v0, v30); // a0 = a0 ^ d0 __ xar(v29, __ T2D, v1, v25, (64 - 1)); // a10' = rol((a1^d1), 1) __ xar(v1, __ T2D, v6, v25, (64 - 44)); // a1 = rol(a6^d1), 44) __ xar(v6, __ T2D, v9, v28, (64 - 20)); // a6 = rol((a9^d4), 20) __ xar(v9, __ T2D, v22, v26, (64 - 61)); // a9 = rol((a22^d2), 61) __ xar(v22, __ T2D, v14, v28, (64 - 39)); // a22 = rol((a14^d4), 39) __ xar(v14, __ T2D, v20, v30, (64 - 18)); // a14 = rol((a20^d0), 18) __ xar(v31, __ T2D, v2, v26, (64 - 62)); // a20' = rol((a2^d2), 62) __ xar(v2, __ T2D, v12, v26, (64 - 43)); // a2 = rol((a12^d2), 43) __ xar(v12, __ T2D, v13, v27, (64 - 25)); // a12 = rol((a13^d3), 25) __ xar(v13, __ T2D, v19, v28, (64 - 8)); // a13 = rol((a19^d4), 8) __ xar(v19, __ T2D, v23, v27, (64 - 56)); // a19 = rol((a23^d3), 56) __ xar(v23, __ T2D, v15, v30, (64 - 41)); // a23 = rol((a15^d0), 41) __ xar(v15, __ T2D, v4, v28, (64 - 27)); // a15 = rol((a4^d4), 27) __ xar(v28, __ T2D, v24, v28, (64 - 14)); // a4' = rol((a24^d4), 14) __ xar(v24, __ T2D, v21, v25, (64 - 2)); // a24 = rol((a21^d1), 2) __ xar(v8, __ T2D, v8, v27, (64 - 55)); // a21' = rol((a8^d3), 55) __ xar(v4, __ T2D, v16, v25, (64 - 45)); // a8' = rol((a16^d1), 45) __ xar(v16, __ T2D, v5, v30, (64 - 36)); // a16 = rol((a5^d0), 36) __ xar(v5, __ T2D, v3, v27, (64 - 28)); // a5 = rol((a3^d3), 28) __ xar(v27, __ T2D, v18, v27, (64 - 21)); // a3' = rol((a18^d3), 21) __ xar(v3, __ T2D, v17, v26, (64 - 15)); // a18' = rol((a17^d2), 15) __ xar(v25, __ T2D, v11, v25, (64 - 10)); // a17' = rol((a11^d1), 10) __ xar(v26, __ T2D, v7, v26, (64 - 6)); // a11' = rol((a7^d2), 6) __ xar(v30, __ T2D, v10, v30, (64 - 3)); // a7' = rol((a10^d0), 3) __ bcax(v20, __ T16B, v31, v22, v8); // a20 = a20' ^ (~a21 & a22') __ bcax(v21, __ T16B, v8, v23, v22); // a21 = a21' ^ (~a22 & a23) __ bcax(v22, __ T16B, v22, v24, v23); // a22 = a22 ^ (~a23 & a24) __ bcax(v23, __ T16B, v23, v31, v24); // a23 = a23 ^ (~a24 & a20') __ bcax(v24, __ T16B, v24, v8, v31); // a24 = a24 ^ (~a20' & a21') __ ld1r(v31, __ T2D, __ post(rscratch1, 8)); // rc = round_constants[i] __ bcax(v17, __ T16B, v25, v19, v3); // a17 = a17' ^ (~a18' & a19) __ bcax(v18, __ T16B, v3, v15, v19); // a18 = a18' ^ (~a19 & a15') __ bcax(v19, __ T16B, v19, v16, v15); // a19 = a19 ^ (~a15 & a16) __ bcax(v15, __ T16B, v15, v25, v16); // a15 = a15 ^ (~a16 & a17') __ bcax(v16, __ T16B, v16, v3, v25); // a16 = a16 ^ (~a17' & a18') __ bcax(v10, __ T16B, v29, v12, v26); // a10 = a10' ^ (~a11' & a12) __ bcax(v11, __ T16B, v26, v13, v12); // a11 = a11' ^ (~a12 & a13) __ bcax(v12, __ T16B, v12, v14, v13); // a12 = a12 ^ (~a13 & a14) __ bcax(v13, __ T16B, v13, v29, v14); // a13 = a13 ^ (~a14 & a10') __ bcax(v14, __ T16B, v14, v26, v29); // a14 = a14 ^ (~a10' & a11') __ bcax(v7, __ T16B, v30, v9, v4); // a7 = a7' ^ (~a8' & a9) __ bcax(v8, __ T16B, v4, v5, v9); // a8 = a8' ^ (~a9 & a5) __ bcax(v9, __ T16B, v9, v6, v5); // a9 = a9 ^ (~a5 & a6) __ bcax(v5, __ T16B, v5, v30, v6); // a5 = a5 ^ (~a6 & a7) __ bcax(v6, __ T16B, v6, v4, v30); // a6 = a6 ^ (~a7 & a8') __ bcax(v3, __ T16B, v27, v0, v28); // a3 = a3' ^ (~a4' & a0) __ bcax(v4, __ T16B, v28, v1, v0); // a4 = a4' ^ (~a0 & a1) __ bcax(v0, __ T16B, v0, v2, v1); // a0 = a0 ^ (~a1 & a2) __ bcax(v1, __ T16B, v1, v27, v2); // a1 = a1 ^ (~a2 & a3) __ bcax(v2, __ T16B, v2, v28, v27); // a2 = a2 ^ (~a3 & a4') __ eor(v0, __ T16B, v0, v31); // a0 = a0 ^ rc ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1959776475 From weijun at openjdk.org Tue Feb 18 14:30:25 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 18 Feb 2025 14:30:25 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v3] In-Reply-To: <-AWm3AZxUC0NY-xa0imjSIQA1-mToci-Umo9MRvP0EE=.e7f3ae40-256a-42b9-9d96-5d82fb9b1285@github.com> References: <-AWm3AZxUC0NY-xa0imjSIQA1-mToci-Umo9MRvP0EE=.e7f3ae40-256a-42b9-9d96-5d82fb9b1285@github.com> Message-ID: On Sun, 16 Feb 2025 06:31:50 GMT, Konanki Sreenath wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases test/jdk/sun/security/x509/X509CertImpl/CertificateExtensions.java line 31: > 29: * @library /test/lib > 30: * @modules java.base/sun.security.x509 > 31: * java.base/sun.security.util Why remove these `@modules` lines? They are still necessary to access internal classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23315#discussion_r1959861124 From weijun at openjdk.org Tue Feb 18 14:39:20 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 18 Feb 2025 14:39:20 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version [v4] In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 11:06:09 GMT, Fernando Guallini wrote: >> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). >> There are some differences between the 1.1.x and the current OpenSSL version: >> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it. Additionally, It is also required to specify the path location of the legacy provider. >> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead. > > Fernando Guallini 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 'master' into JDK-8349492 > - updated wording in KeytoolOpensslInteropTest > - updated wording > - provider path depends on platform > - typo > - it should be isX64 rather than is64bit > - refactoring > - using openssl 3.0.14 Thanks. I see no issue, but I'll leave it to somebody more familiar with the artifact mechanism to approve the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23613#issuecomment-2665900336 From mullan at openjdk.org Tue Feb 18 19:14:31 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 18 Feb 2025 19:14:31 GMT Subject: RFR: 8350147: Replace example in KEM class with the one from JEP 452 [v3] In-Reply-To: References: Message-ID: On Sat, 15 Feb 2025 22:33:46 GMT, Bradford Wetmore wrote: >> The example code in the JEP was much clearer than that in the current `KEM` class. It's easier to keep the various nested classes straight, rather than using `var`s which require scrolling to see what the return types are. >> >> Added/tweaked example for clarity. >> >> Generated/checked javadocs, but no regression/JCK tests is necessary. > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Further codereview Comments from Weijun Reviewed this after you already integrated and noticed the typo. src/java.base/share/classes/javax/crypto/KEM.java line 68: > 66: *

> 67: * > 68: * Example operation using a ficticious {@code KEM} algorithm {@code ABC}: Typo: s/ficticious/fictitious/ ------------- PR Review: https://git.openjdk.org/jdk/pull/23652#pullrequestreview-2624366617 PR Review Comment: https://git.openjdk.org/jdk/pull/23652#discussion_r1960192397 From weijun at openjdk.org Tue Feb 18 18:55:45 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 18 Feb 2025 18:55:45 GMT Subject: RFR: 8346050: Update BuildTestLib.gmk to build whole testlibrary [v4] In-Reply-To: References: Message-ID: <8MkkDn6NoW9zqCO4Ntl62ILhOPJq45TqHB6QQFQXXJU=.9f81094c-9e59-417e-a617-3e84670eb8a9@github.com> On Fri, 14 Feb 2025 18:22:26 GMT, Leonid Mesnik wrote: >> The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - added copyrights > - replaced commens fix with supress Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23525#pullrequestreview-2624569868 From rhalade at openjdk.org Tue Feb 18 19:22:16 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Tue, 18 Feb 2025 19:22:16 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version [v4] In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 11:06:09 GMT, Fernando Guallini wrote: >> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). >> There are some differences between the 1.1.x and the current OpenSSL version: >> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it. Additionally, It is also required to specify the path location of the legacy provider. >> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead. > > Fernando Guallini 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 'master' into JDK-8349492 > - updated wording in KeytoolOpensslInteropTest > - updated wording > - provider path depends on platform > - typo > - it should be isX64 rather than is64bit > - refactoring > - using openssl 3.0.14 Few comments to update `current version` wherever possible to print the `OPENSSL_BUNDLE_VERSION`. test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 34: > 32: * openssl path using system property "test.openssl.path" or it should > 33: * be available in /usr/bin or /usr/local/bin > 34: * Required OpenSSL version : Current version as defined by OpensslArtifactFetcher Update `current version` to `OpensslArtifactFetcher.OPENSSL_BUNDLE_VERSION` test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 80: > 78: // since the current version of openssl is not available, skip all > 79: // openssl command dependent tests with a warning > 80: System.out.println("\n\u001B[31mWarning: Can't find the current version " It will be better to update this to print `OpensslArtifactFetcher.OPENSSL_BUNDLE_VERSION` with the corresponding `getTestOpenSSLBundleVersion` routine in `OpensslArtifactFetcher`. The current version verbiage is confusing. test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java line 41: > 39: > 40: /** > 41: * Gets the openssl binary path of the current version update the` current version` here to `OPENSSL_BUNDLE_VERSION` ------------- Changes requested by rhalade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23613#pullrequestreview-2624426488 PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1960231506 PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1960238639 PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1960225228 From mdonovan at openjdk.org Tue Feb 18 19:23:43 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 18 Feb 2025 19:23:43 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing In-Reply-To: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> Message-ID: <6tfInG2RiTKxngMBW96AW5mxd0IDJUNeWYVLUW2nykI=.6a181339-ee9f-4ad0-bc41-a9f3c1fd440e@github.com> On Sat, 1 Feb 2025 04:20:36 GMT, Anthony Scarpino wrote: > I need a review of this change that adds new timing controls for the initial server setup. On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect. Additional debugging is added to help identify if there are other timing issues. > > Thanks > > Tony test/jdk/javax/net/ssl/templates/TLSBase.java line 204: > 202: write(sock, read(sock)); > 203: } catch (Exception e) { > 204: System.err.println("Caught " + e.getMessage()); `e.printStackTrace()` will include the exception message. Do we need this line at all? test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTParallel.java line 76: > 74: String name = Thread.currentThread().getName(); > 75: SSLSession r; > 76: System.err.println(name + " is ready"); This test is printing some things to System.out and some to System.err. It's also using TLSBase which is printing everything to System.err. This will make the logs difficult to read and understand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23407#discussion_r1960004985 PR Review Comment: https://git.openjdk.org/jdk/pull/23407#discussion_r1960025280 From duke at openjdk.org Tue Feb 18 19:26:59 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Tue, 18 Feb 2025 19:26:59 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v5] In-Reply-To: References: Message-ID: <3qOhCuJfPQDXBbXGgz6JoHrPe22SZV3ruQJJNQcqu20=.ee887bd8-6813-44bf-8d0d-36c7e24a1299@github.com> > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23315/files - new: https://git.openjdk.org/jdk/pull/23315/files/87a1c164..dada4ce8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=03-04 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23315/head:pull/23315 PR: https://git.openjdk.org/jdk/pull/23315 From weijun at openjdk.org Tue Feb 18 19:27:07 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 18 Feb 2025 19:27:07 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v4] In-Reply-To: <4UFgjU5Myevjoy_UgHCwGAHJMsObWKrVGueYDLfOg3s=.2b3bf170-2176-4c62-94c1-d3bc5d6f189f@github.com> References: <4UFgjU5Myevjoy_UgHCwGAHJMsObWKrVGueYDLfOg3s=.2b3bf170-2176-4c62-94c1-d3bc5d6f189f@github.com> Message-ID: On Tue, 18 Feb 2025 11:45:57 GMT, Konanki Sreenath wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases There is still one `if (info != null)` check in `getTBSCertificate()`. Also, you can combine Objects.requireNonNull(info); this.info = info; to this.info = Objects.requireNonNull(info); ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2666430906 From jnimeh at openjdk.org Tue Feb 18 19:22:36 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 18 Feb 2025 19:22:36 GMT Subject: RFR: 8342238: Test javax/crypto/CryptoPermissions/InconsistentEntries.java writes files in tested JDK dir In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 18:52:17 GMT, Fernando Guallini wrote: >> The test javax/crypto/CryptoPermissions/InconsistentEntries.java should not modify the JDK home directory under test as that could impact the results of other tests, or it could fail if the JDK home dir is read-only. >> >> This PR updates the test to >> >> - clone the tested JDK into the scratch directory. >> - create the required directory and file in the cloned JDK directory. >> - run a subprocess using the temporal JDK to test the scenario. >> >> There is no need to explicitly remove the tests files with an 'after' step, as JTreg will handle cleaning the scratch directory > > Hi, please a review is needed. @fguallini I'm looking it over now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23202#issuecomment-2666349815 From ascarpino at openjdk.org Tue Feb 18 19:31:42 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Tue, 18 Feb 2025 19:31:42 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing In-Reply-To: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> Message-ID: On Sat, 1 Feb 2025 04:20:36 GMT, Anthony Scarpino wrote: > I need a review of this change that adds new timing controls for the initial server setup. On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect. Additional debugging is added to help identify if there are other timing issues. > > Thanks > > Tony It was reported back by the bug submitter that this change fixed their issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23407#issuecomment-2666745070 From ascarpino at openjdk.org Tue Feb 18 19:31:43 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Tue, 18 Feb 2025 19:31:43 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing In-Reply-To: <6MlNFjSs6MCfONaOAitq0S6gGcLeG00vtihtnDQoagc=.75a30d86-a77c-4d2d-a462-c06ecab92bab@github.com> References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> <6MlNFjSs6MCfONaOAitq0S6gGcLeG00vtihtnDQoagc=.75a30d86-a77c-4d2d-a462-c06ecab92bab@github.com> Message-ID: On Tue, 4 Feb 2025 18:56:05 GMT, Hai-May Chao wrote: >> I need a review of this change that adds new timing controls for the initial server setup. On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect. Additional debugging is added to help identify if there are other timing issues. >> >> Thanks >> >> Tony > > test/jdk/javax/net/ssl/templates/TLSBase.java line 152: > >> 150: List exceptionList = new ArrayList<>(); >> 151: ExecutorService threadPool = Executors.newFixedThreadPool(1, >> 152: r -> Executors.defaultThreadFactory().newThread(r)); > > Do you think we may simplify this to `ExecutorService threadPool = Executors.newFixedThreadPool(1);` while this line is being changed? Hmm. I'll try removing it to see if I get any failures. I don't remember why I added the threadfactory entry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23407#discussion_r1960443504 From ascarpino at openjdk.org Tue Feb 18 19:44:58 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Tue, 18 Feb 2025 19:44:58 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing In-Reply-To: <6tfInG2RiTKxngMBW96AW5mxd0IDJUNeWYVLUW2nykI=.6a181339-ee9f-4ad0-bc41-a9f3c1fd440e@github.com> References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> <6tfInG2RiTKxngMBW96AW5mxd0IDJUNeWYVLUW2nykI=.6a181339-ee9f-4ad0-bc41-a9f3c1fd440e@github.com> Message-ID: <4im7KGS0xadsrsGA5zgNxNhjHkoQ63IrIffSHwOEAz0=.eb2b38a4-c58d-4995-b59d-d9dd41ba70f6@github.com> On Tue, 18 Feb 2025 15:38:50 GMT, Matthew Donovan wrote: >> I need a review of this change that adds new timing controls for the initial server setup. On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect. Additional debugging is added to help identify if there are other timing issues. >> >> Thanks >> >> Tony > > test/jdk/javax/net/ssl/templates/TLSBase.java line 204: > >> 202: write(sock, read(sock)); >> 203: } catch (Exception e) { >> 204: System.err.println("Caught " + e.getMessage()); > > `e.printStackTrace()` will include the exception message. Do we need this line at all? true ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23407#discussion_r1960479084 From ascarpino at openjdk.org Tue Feb 18 19:48:00 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Tue, 18 Feb 2025 19:48:00 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing In-Reply-To: <4im7KGS0xadsrsGA5zgNxNhjHkoQ63IrIffSHwOEAz0=.eb2b38a4-c58d-4995-b59d-d9dd41ba70f6@github.com> References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> <6tfInG2RiTKxngMBW96AW5mxd0IDJUNeWYVLUW2nykI=.6a181339-ee9f-4ad0-bc41-a9f3c1fd440e@github.com> <4im7KGS0xadsrsGA5zgNxNhjHkoQ63IrIffSHwOEAz0=.eb2b38a4-c58d-4995-b59d-d9dd41ba70f6@github.com> Message-ID: On Tue, 18 Feb 2025 19:42:25 GMT, Anthony Scarpino wrote: >> test/jdk/javax/net/ssl/templates/TLSBase.java line 204: >> >>> 202: write(sock, read(sock)); >>> 203: } catch (Exception e) { >>> 204: System.err.println("Caught " + e.getMessage()); >> >> `e.printStackTrace()` will include the exception message. Do we need this line at all? > > true Actually the line change may not be necessary. It would be good for stdout to get the message, but the stacktrace to be left for err. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23407#discussion_r1960483461 From ascarpino at openjdk.org Tue Feb 18 19:55:00 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Tue, 18 Feb 2025 19:55:00 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing In-Reply-To: <6tfInG2RiTKxngMBW96AW5mxd0IDJUNeWYVLUW2nykI=.6a181339-ee9f-4ad0-bc41-a9f3c1fd440e@github.com> References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> <6tfInG2RiTKxngMBW96AW5mxd0IDJUNeWYVLUW2nykI=.6a181339-ee9f-4ad0-bc41-a9f3c1fd440e@github.com> Message-ID: On Tue, 18 Feb 2025 15:48:26 GMT, Matthew Donovan wrote: >> I need a review of this change that adds new timing controls for the initial server setup. On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect. Additional debugging is added to help identify if there are other timing issues. >> >> Thanks >> >> Tony > > test/jdk/sun/security/ssl/SSLSessionImpl/MultiNSTParallel.java line 76: > >> 74: String name = Thread.currentThread().getName(); >> 75: SSLSession r; >> 76: System.err.println(name + " is ready"); > > This test is printing some things to System.out and some to System.err. It's also using TLSBase which is printing everything to System.err. This will make the logs difficult to read and understand. With the threading though, some of the errors need to be printed right away. I understand your concern, but my attempt is to make stdout display obvious results without searching all the debugging info. In some cases catching an exception is a valid result, which may look like a test failure if they were all in one output buffer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23407#discussion_r1960495565 From lmesnik at openjdk.org Tue Feb 18 20:09:04 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 18 Feb 2025 20:09:04 GMT Subject: Integrated: 8346050: Update BuildTestLib.gmk to build whole testlibrary In-Reply-To: References: Message-ID: On Fri, 7 Feb 2025 21:15:36 GMT, Leonid Mesnik wrote: > The fix add remaining classes to the testlibrary jar and fix some warnings in security-related classes. This pull request has now been integrated. Changeset: 62d93f2a Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/62d93f2a2222a044ac4aa409efd69e776f0d43da Stats: 21 lines in 5 files changed: 15 ins; 0 del; 6 mod 8346050: Update BuildTestLib.gmk to build whole testlibrary Reviewed-by: weijun, ihse ------------- PR: https://git.openjdk.org/jdk/pull/23525 From mullan at openjdk.org Tue Feb 18 20:36:52 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 18 Feb 2025 20:36:52 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 11:40:59 GMT, Mikhail Yankelevich wrote: > Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. > This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. The fix needs a test or you need to add an appropriate `noreg` label to the JBS issue if it isn't necessary or practical for some reason. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23661#issuecomment-2666874604 From jnimeh at openjdk.org Tue Feb 18 21:19:52 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 18 Feb 2025 21:19:52 GMT Subject: RFR: 8342238: Test javax/crypto/CryptoPermissions/InconsistentEntries.java writes files in tested JDK dir In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:20:27 GMT, Fernando Guallini wrote: > The test javax/crypto/CryptoPermissions/InconsistentEntries.java should not modify the JDK home directory under test as that could impact the results of other tests, or it could fail if the JDK home dir is read-only. > > This PR updates the test to > > - clone the tested JDK into the scratch directory. > - create the required directory and file in the cloned JDK directory. > - run a subprocess using the temporal JDK to test the scenario. > > There is no need to explicitly remove the tests files with an 'after' step, as JTreg will handle cleaning the scratch directory Marked as reviewed by jnimeh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23202#pullrequestreview-2625051338 From abarashev at openjdk.org Tue Feb 18 21:46:19 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 18 Feb 2025 21:46:19 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope Message-ID: Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates: https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 ------------- Commit messages: - 8349583: Add mechanism to disable signature schemes based on their TLS scope Changes: https://git.openjdk.org/jdk/pull/23681/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349583 Stats: 1200 lines in 20 files changed: 859 ins; 232 del; 109 mod Patch: https://git.openjdk.org/jdk/pull/23681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681 PR: https://git.openjdk.org/jdk/pull/23681 From abarashev at openjdk.org Tue Feb 18 22:43:32 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 18 Feb 2025 22:43:32 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v2] In-Reply-To: References: Message-ID: > Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Typo fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23681/files - new: https://git.openjdk.org/jdk/pull/23681/files/f7fcbcbd..6cc2ff5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681 PR: https://git.openjdk.org/jdk/pull/23681 From haosun at openjdk.org Wed Feb 19 02:58:03 2025 From: haosun at openjdk.org (Hao Sun) Date: Wed, 19 Feb 2025 02:58:03 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 18:47:54 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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: > > Adding comments + some code reorganization Hi. Here is the test result of our CI. ### copyright year the following files should update the copyright year to 2025. src/hotspot/cpu/aarch64/assembler_aarch64.hpp src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp src/hotspot/share/runtime/globals.hpp src/java.base/share/classes/sun/security/provider/ML_DSA.java src/java.base/share/classes/sun/security/provider/SHA3Parallel.java test/micro/org/openjdk/bench/java/security/MLDSA.java ### cross-build failure Cross build for riscv64/s390/ppc64 failed. Here shows the error msg for ppc64 === Output from failing command(s) repeated here === * For target support_interim-jmods_support__create_java.base.jmod_exec: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/tmp/jdk-src/src/hotspot/share/asm/codeBuffer.hpp:200), pid=72752, tid=72769 # assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000e85cb03dc620 <= 0x0000e85cb03e8ab4 <= 0x0000e85cb03e8ab0 # # JRE version: OpenJDK Runtime Environment (25.0) (fastdebug build 25-internal-git-1e01c6deec3) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-git-1e01c6deec3, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x3b391c] Instruction_aarch64::~Instruction_aarch64()+0xbc # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /tmp/ci-scripts/jdk-src/make/ # # An error report file with more information is saved as: # /tmp/jdk-src/make/hs_err_pid72752.log ... (rest of output omitted) * All command lines available in /sysroot/ppc64el/tmp/build-ppc64el/make-support/failure-logs. === End of repeated output === I suppose we should make the similar update at file `src/hotspot/cpu/aarch64/stubDeclarations_aarch64.hpp` to other platforms ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2667389849 From duke at openjdk.org Wed Feb 19 10:27:26 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Wed, 19 Feb 2025 10:27:26 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v6] In-Reply-To: References: Message-ID: > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23315/files - new: https://git.openjdk.org/jdk/pull/23315/files/dada4ce8..ddcf284a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=04-05 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23315/head:pull/23315 PR: https://git.openjdk.org/jdk/pull/23315 From adinn at openjdk.org Wed Feb 19 10:44:55 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 19 Feb 2025 10:44:55 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v2] In-Reply-To: References: <7UgNYEuTu6rj7queOgM9xIy-6kQMdACrZiDLtlniMYw=.dff6f18b-1236-43b1-8280-2bce9160f32a@github.com> Message-ID: On Tue, 4 Feb 2025 18:57:28 GMT, Ferenc Rakoczi wrote: >>> @ferakocz I'm afraid you lucked out on getting your change committed before my reorganization of the stub generation code. If you are unsure of how to do the merge so your new stub is declared and generated following the new model (see the doc comments in stubDeclarations.hpp for details) let me know and I'll be happy to help you sort it out. >> >> @adinn I think I managed to figure it out. Please take a look at the PR and let me know if I should have done anything differently. > >> @ferakocz Yes, the stub declaration part of it looks to be correct. >> >> The rest of the patch will need at least two reviewers (@theRealAph? @martinuy? @franferrax) and may take some time to review, given that they will probably need to read up on the maths and algorithms. As an aid for reviewers and maintainers it would be good to insert a comment into the generator file linking the implementations to the relevant maths and algorithm. I found the FIPS-204 spec and the CRYSTALS-Dilithium Algorithm Speci?cations and Supporting Documentation paper, Shi Bai, L?o Ducas et al, 2021 - are they the best ones to look at? > > The Java implementation of ML-DSA is based on the FIPS-204 standard and the intrinsicss' implementations are based on the corresponding Java methods, except that the montMul() calls in them are inlined. The rest of the transformation from Java code to intrinsic code is pretty straightforward, so a reviewer need not necessarily understand the whole mathematics of the ML-DSA algorithms, just that the Java and the corresponding intrinsic code do the same thing. @ferakocz Apologies for the delays in reviewing and the limited feedback up to now. The code clearly does the job well but I think it would be made clearer and easier to maintain by tweaking/extending some of the generator methods and adding more detailed commenting. I am afraid I may take a few days to provide the relevant details because of other commitments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2668251335 From duke at openjdk.org Wed Feb 19 10:45:54 2025 From: duke at openjdk.org (Marcono1234) Date: Wed, 19 Feb 2025 10:45:54 GMT Subject: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote: > This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates. > > 2 other smaller changes: > - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead > - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`) src/java.base/share/classes/java/util/jar/JarEntry.java line 100: > 98: * reached. Otherwise, this method will return {@code null}. > 99: * > 100: *

It is recommended to use the {@link getCodeSigners} method instead, Isn't this missing a `#` to be a valid link? Suggestion: *

It is recommended to use the {@link #getCodeSigners} method instead, (Please don't use the "Commit suggestion" button to not include me as author) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23616#discussion_r1961440218 From jpai at openjdk.org Wed Feb 19 10:52:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Feb 2025 10:52:59 GMT Subject: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 10:43:06 GMT, Marcono1234 wrote: >> This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates. >> >> 2 other smaller changes: >> - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead >> - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`) > > src/java.base/share/classes/java/util/jar/JarEntry.java line 100: > >> 98: * reached. Otherwise, this method will return {@code null}. >> 99: * >> 100: *

It is recommended to use the {@link getCodeSigners} method instead, > > Isn't this missing a `#` to be a valid link? > Suggestion: > > *

It is recommended to use the {@link #getCodeSigners} method instead, > > > (Please don't use the "Commit suggestion" button to not include me as author) I had a similar reaction when I first saw it. So I checked the javadoc specification the other day and it states https://docs.oracle.com/en/java/javase/23/docs/specs/javadoc/doc-comment-spec.html#references: The most general form of a reference is: module/package.class#member This form is used by the see, link and linkplain tags. Leading components can be omitted when they can be inferred from the surrounding context. Trailing components can be omitted when they are not required. ... When the reference is to a member of the same class as that containing the documentation comment, all parts of the reference up to and including the # may be omitted, although the '#' may be retained for clarity. So, syntactically, it's fine in the current form. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23616#discussion_r1961450370 From duke at openjdk.org Wed Feb 19 11:20:55 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Wed, 19 Feb 2025 11:20:55 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v4] In-Reply-To: References: <4UFgjU5Myevjoy_UgHCwGAHJMsObWKrVGueYDLfOg3s=.2b3bf170-2176-4c62-94c1-d3bc5d6f189f@github.com> Message-ID: On Tue, 18 Feb 2025 17:44:12 GMT, Weijun Wang wrote: > There is still one `if (info != null)` check in `getTBSCertificate()`. > > Also, you can combine > > ``` > Objects.requireNonNull(info); > this.info = info; > ``` > > to > > ``` > this.info = Objects.requireNonNull(info); > ``` addressed @wangweij ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2668340588 From mullan at openjdk.org Wed Feb 19 13:20:58 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 19 Feb 2025 13:20:58 GMT Subject: Integrated: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection In-Reply-To: References: Message-ID: On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote: > This change adds an API note to these methods recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted. There was already a similar warning in the `JarFile` and `JarInputStream` class descriptions, but this adds a similar and more direct warning at the methods that return the code signer's certificates. > > 2 other smaller changes: > - In `JarEntry.getCertificates`, added a recommendation to use the `getCodeSigners` method instead > - Added details of the order of the returned certificates to `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`) This pull request has now been integrated. Changeset: 577ff98a Author: Sean Mullan URL: https://git.openjdk.org/jdk/commit/577ff98a6733a99ea49510f15d631beff39c34a5 Stats: 38 lines in 3 files changed: 32 ins; 0 del; 6 mod 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection Reviewed-by: lancea, jpai ------------- PR: https://git.openjdk.org/jdk/pull/23616 From abarashev at openjdk.org Wed Feb 19 13:26:49 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 19 Feb 2025 13:26:49 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: Message-ID: > Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Fix typo in java.security documentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23681/files - new: https://git.openjdk.org/jdk/pull/23681/files/6cc2ff5e..db7c1e75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681 PR: https://git.openjdk.org/jdk/pull/23681 From duke at openjdk.org Wed Feb 19 13:42:38 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 19 Feb 2025 13:42:38 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v2] In-Reply-To: References: Message-ID: <3cY0eN4D2ppTUXIDKLE50Mxg9KcuWXNwHcykK9xbAAI=.b64531b0-f76c-4fa6-bd73-1803d3d32dce@github.com> > Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. > This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: tests added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23661/files - new: https://git.openjdk.org/jdk/pull/23661/files/a83f2433..a9244ed8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23661&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23661&range=00-01 Stats: 124 lines in 1 file changed: 124 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23661/head:pull/23661 PR: https://git.openjdk.org/jdk/pull/23661 From duke at openjdk.org Wed Feb 19 13:42:38 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 19 Feb 2025 13:42:38 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 20:34:36 GMT, Sean Mullan wrote: > The fix needs a test or you need to add an appropriate `noreg` label to the JBS issue if it isn't necessary or practical for some reason. Working on a test for it, forgot to change PR to draft, apologies. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23661#issuecomment-2666898389 From weijun at openjdk.org Wed Feb 19 14:29:57 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 19 Feb 2025 14:29:57 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v6] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 10:27:26 GMT, Konanki Sreenath wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases Only a small nit. Copyright year for `TestHostnameChecker.java` should also be updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2668815018 From duke at openjdk.org Wed Feb 19 14:48:56 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Wed, 19 Feb 2025 14:48:56 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v7] In-Reply-To: References: Message-ID: > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23315/files - new: https://git.openjdk.org/jdk/pull/23315/files/ddcf284a..610592c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23315&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23315/head:pull/23315 PR: https://git.openjdk.org/jdk/pull/23315 From weijun at openjdk.org Wed Feb 19 14:58:54 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 19 Feb 2025 14:58:54 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v7] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 14:48:56 GMT, Konanki Sreenath wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23315#pullrequestreview-2627083182 From duke at openjdk.org Wed Feb 19 15:33:53 2025 From: duke at openjdk.org (duke) Date: Wed, 19 Feb 2025 15:33:53 GMT Subject: RFR: 8342238: Test javax/crypto/CryptoPermissions/InconsistentEntries.java writes files in tested JDK dir In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:20:27 GMT, Fernando Guallini wrote: > The test javax/crypto/CryptoPermissions/InconsistentEntries.java should not modify the JDK home directory under test as that could impact the results of other tests, or it could fail if the JDK home dir is read-only. > > This PR updates the test to > > - clone the tested JDK into the scratch directory. > - create the required directory and file in the cloned JDK directory. > - run a subprocess using the temporal JDK to test the scenario. > > There is no need to explicitly remove the tests files with an 'after' step, as JTreg will handle cleaning the scratch directory @fguallini Your change (at version f1c8db618a8bdc1ea2a0e6ba41483630a508f429) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23202#issuecomment-2668995453 From coffeys at openjdk.org Wed Feb 19 15:34:57 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 19 Feb 2025 15:34:57 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v7] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 14:48:56 GMT, Konanki Sreenath wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases LGTM ------------- Marked as reviewed by coffeys (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23315#pullrequestreview-2627197226 From duke at openjdk.org Wed Feb 19 15:41:56 2025 From: duke at openjdk.org (duke) Date: Wed, 19 Feb 2025 15:41:56 GMT Subject: RFR: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases [v7] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 14:48:56 GMT, Konanki Sreenath wrote: >> Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. >> >> After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** >> >> The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the >> **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. > > Konanki Sreenath has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8346094 : Harden X509CertImpl.getExtensionValue for NPE cases @ksreenath-ora Your change (at version 610592c9bc8bb405bced8f485423cea4d8f41e0e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23315#issuecomment-2669019142 From mdonovan at openjdk.org Wed Feb 19 15:55:59 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 19 Feb 2025 15:55:59 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry Message-ID: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> 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) ------------- Commit messages: - 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=00 Issue: https://bugs.openjdk.org/browse/JDK-8325766 Stats: 779 lines in 3 files changed: 154 ins; 599 del; 26 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 duke at openjdk.org Wed Feb 19 16:51:01 2025 From: duke at openjdk.org (Konanki Sreenath) Date: Wed, 19 Feb 2025 16:51:01 GMT Subject: Integrated: 8346094: Harden X509CertImpl.getExtensionValue for NPE cases In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 12:39:45 GMT, Konanki Sreenath wrote: > Earlier code will trigger NPE if the certificate does not contain the extensions or if the requested extensions does not exist. The better approach for hardening **getExtensionValue** here is to to check for NULL explicitly before calling **getExtensionValue()** and avoding try-catch block which ensures the readability and maintainability. > > After scanning in multiple places where invokng getExtensions on the X509CertInfo reference, the check for NULL is added in the **getKeyUsage()** as well while calling before **getExtensionValue()** > > The associated tests are written and added in test class **CertificateExtensions**. Which will ensure to validate the > **getExtensionValue()** and **getKeyUsage()** methods in **X509CertImpl** class. This pull request has now been integrated. Changeset: 70a6c0b7 Author: konanki sreenath Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/70a6c0b7ac952eebdffa1d64399cd0ee1efec1f6 Stats: 267 lines in 3 files changed: 210 ins; 47 del; 10 mod 8346094: Harden X509CertImpl.getExtensionValue for NPE cases Reviewed-by: coffeys, weijun ------------- PR: https://git.openjdk.org/jdk/pull/23315 From weijun at openjdk.org Wed Feb 19 16:55:02 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 19 Feb 2025 16:55:02 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v2] In-Reply-To: <3cY0eN4D2ppTUXIDKLE50Mxg9KcuWXNwHcykK9xbAAI=.b64531b0-f76c-4fa6-bd73-1803d3d32dce@github.com> References: <3cY0eN4D2ppTUXIDKLE50Mxg9KcuWXNwHcykK9xbAAI=.b64531b0-f76c-4fa6-bd73-1803d3d32dce@github.com> Message-ID: On Wed, 19 Feb 2025 13:42:38 GMT, Mikhail Yankelevich wrote: >> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. >> This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > tests added test/jdk/sun/security/util/HexDumpEncoderTests.java line 101: > 99: public static void main(String[] args) throws Exception { > 100: > 101: try (final FileInputStream fis = new FileInputStream(args[0])) { There is no need to read from a certificate. I think `encoder.encodeBuffer(new byte[100])` is enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23661#discussion_r1962042873 From fguallini at openjdk.org Wed Feb 19 17:03:02 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Wed, 19 Feb 2025 17:03:02 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version [v5] In-Reply-To: References: Message-ID: > This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). > There are some differences between the 1.1.x and the current OpenSSL version: > - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it. Additionally, It is also required to specify the path location of the legacy provider. > - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: updated wording of openssl version ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23613/files - new: https://git.openjdk.org/jdk/pull/23613/files/bcb87952..ad998433 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23613&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23613&range=03-04 Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23613/head:pull/23613 PR: https://git.openjdk.org/jdk/pull/23613 From fguallini at openjdk.org Wed Feb 19 17:03:05 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Wed, 19 Feb 2025 17:03:05 GMT Subject: RFR: 8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version [v4] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 17:52:14 GMT, Rajan Halade wrote: >> Fernando Guallini 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 'master' into JDK-8349492 >> - updated wording in KeytoolOpensslInteropTest >> - updated wording >> - provider path depends on platform >> - typo >> - it should be isX64 rather than is64bit >> - refactoring >> - using openssl 3.0.14 > > test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 80: > >> 78: // since the current version of openssl is not available, skip all >> 79: // openssl command dependent tests with a warning >> 80: System.out.println("\n\u001B[31mWarning: Can't find the current version " > > It will be better to update this to print `OpensslArtifactFetcher.OPENSSL_BUNDLE_VERSION` with the corresponding `getTestOpenSSLBundleVersion` routine in `OpensslArtifactFetcher`. The current version verbiage is confusing. Ok thanks, updated with suggestions ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1962053922 From duke at openjdk.org Wed Feb 19 17:07:33 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 19 Feb 2025 17:07:33 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v3] In-Reply-To: References: Message-ID: > Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. > This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: changed cert reading to the byte[100] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23661/files - new: https://git.openjdk.org/jdk/pull/23661/files/a9244ed8..68892602 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23661&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23661&range=01-02 Stats: 25 lines in 1 file changed: 0 ins; 21 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23661/head:pull/23661 PR: https://git.openjdk.org/jdk/pull/23661 From duke at openjdk.org Wed Feb 19 17:07:33 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 19 Feb 2025 17:07:33 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v2] In-Reply-To: References: <3cY0eN4D2ppTUXIDKLE50Mxg9KcuWXNwHcykK9xbAAI=.b64531b0-f76c-4fa6-bd73-1803d3d32dce@github.com> Message-ID: <10RhiqZmLoDElIbeBh5ITq5voPoRrwP69ezbdDGU8cY=.7d1efc00-a8f4-4750-adb3-7ab0cce1b0e9@github.com> On Wed, 19 Feb 2025 16:52:36 GMT, Weijun Wang wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> tests added > > test/jdk/sun/security/util/HexDumpEncoderTests.java line 101: > >> 99: public static void main(String[] args) throws Exception { >> 100: >> 101: try (final FileInputStream fis = new FileInputStream(args[0])) { > > There is no need to read from a certificate. I think `encoder.encodeBuffer(new byte[100])` is enough. changed in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23661#discussion_r1962060893 From weijun at openjdk.org Wed Feb 19 17:14:57 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 19 Feb 2025 17:14:57 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v2] In-Reply-To: <10RhiqZmLoDElIbeBh5ITq5voPoRrwP69ezbdDGU8cY=.7d1efc00-a8f4-4750-adb3-7ab0cce1b0e9@github.com> References: <3cY0eN4D2ppTUXIDKLE50Mxg9KcuWXNwHcykK9xbAAI=.b64531b0-f76c-4fa6-bd73-1803d3d32dce@github.com> <10RhiqZmLoDElIbeBh5ITq5voPoRrwP69ezbdDGU8cY=.7d1efc00-a8f4-4750-adb3-7ab0cce1b0e9@github.com> Message-ID: On Wed, 19 Feb 2025 17:04:15 GMT, Mikhail Yankelevich wrote: >> test/jdk/sun/security/util/HexDumpEncoderTests.java line 101: >> >>> 99: public static void main(String[] args) throws Exception { >>> 100: >>> 101: try (final FileInputStream fis = new FileInputStream(args[0])) { >> >> There is no need to read from a certificate. I think `encoder.encodeBuffer(new byte[100])` is enough. > > changed in the next commit Some `import`s are not needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23661#discussion_r1962072542 From duke at openjdk.org Wed Feb 19 17:21:10 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 19 Feb 2025 17:21:10 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v4] In-Reply-To: References: Message-ID: > Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. > This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: imports cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23661/files - new: https://git.openjdk.org/jdk/pull/23661/files/68892602..feb64396 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23661&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23661&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23661/head:pull/23661 PR: https://git.openjdk.org/jdk/pull/23661 From weijun at openjdk.org Wed Feb 19 17:55:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 19 Feb 2025 17:55:52 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v4] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 17:21:10 GMT, Mikhail Yankelevich wrote: >> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. >> This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > imports cleanup Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23661#pullrequestreview-2627567488 From duke at openjdk.org Wed Feb 19 17:55:53 2025 From: duke at openjdk.org (duke) Date: Wed, 19 Feb 2025 17:55:53 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v4] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 17:21:10 GMT, Mikhail Yankelevich wrote: >> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. >> This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > imports cleanup @myankelev Your change (at version feb64396e4beefc460f1567b4e70992e385fb911) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23661#issuecomment-2669364069 From duke at openjdk.org Wed Feb 19 18:59:40 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 19 Feb 2025 18:59:40 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v5] In-Reply-To: References: Message-ID: <5COgDUVp8KaNXwFX7SAEXeKhmxDup0sKmhfC4oFZfTw=.6f4c91ef-a656-4dd6-8087-70e3f210fa1a@github.com> > Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. > This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: imports fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23661/files - new: https://git.openjdk.org/jdk/pull/23661/files/feb64396..d0db323f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23661&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23661&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23661/head:pull/23661 PR: https://git.openjdk.org/jdk/pull/23661 From weijun at openjdk.org Wed Feb 19 18:59:40 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 19 Feb 2025 18:59:40 GMT Subject: RFR: 8349664: HEX dump should always use ASCII or ISO_8859_1 [v5] In-Reply-To: <5COgDUVp8KaNXwFX7SAEXeKhmxDup0sKmhfC4oFZfTw=.6f4c91ef-a656-4dd6-8087-70e3f210fa1a@github.com> References: <5COgDUVp8KaNXwFX7SAEXeKhmxDup0sKmhfC4oFZfTw=.6f4c91ef-a656-4dd6-8087-70e3f210fa1a@github.com> Message-ID: On Wed, 19 Feb 2025 18:56:40 GMT, Mikhail Yankelevich wrote: >> Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. >> This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > imports fix Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23661#pullrequestreview-2627702925 From duke at openjdk.org Wed Feb 19 18:59:41 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Wed, 19 Feb 2025 18:59:41 GMT Subject: Integrated: 8349664: HEX dump should always use ASCII or ISO_8859_1 In-Reply-To: References: Message-ID: On Mon, 17 Feb 2025 11:40:59 GMT, Mikhail Yankelevich wrote: > Changed `HexDumpEncoder`, so `encodeBuffer` always uses ISO_8859_1. > This also fixes the issue with conversion in `encode` method, as the input is always ISO_8859_1. This pull request has now been integrated. Changeset: 7734f8ed Author: Mikhail Yankelevich Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/7734f8ed13f04ba01258b4fbe18a3d9b66f7fc7a Stats: 104 lines in 2 files changed: 101 ins; 0 del; 3 mod 8349664: HEX dump should always use ASCII or ISO_8859_1 Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/23661 From mpowers at openjdk.org Wed Feb 19 21:02:09 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 19 Feb 2025 21:02:09 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes [v2] In-Reply-To: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> Message-ID: <5K5ps62TO_HKhMbGqHd85dgQ-kxeT9ZLRn4zn6x_N8o=.1906046c-9e9d-40ef-b9e7-cce753299101@github.com> > [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: review comments from Valerie and Sean ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23188/files - new: https://git.openjdk.org/jdk/pull/23188/files/7a4b8596..00db4713 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23188&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23188&range=00-01 Stats: 19 lines in 3 files changed: 3 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/23188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23188/head:pull/23188 PR: https://git.openjdk.org/jdk/pull/23188 From mullan at openjdk.org Wed Feb 19 21:21:01 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 19 Feb 2025 21:21:01 GMT Subject: RFR: 8261513: Various BasicConstraintsExtension issues [v3] In-Reply-To: References: <_-E8euMT24qWQQJBRbNusSF_tHiDCiYdWzqlVccO2BA=.d5f20c54-1178-489f-9eac-75bbbc381791@github.com> Message-ID: On Mon, 3 Feb 2025 19:26:27 GMT, Ben Perez wrote: >> 8261513: Various BasicConstraintsExtension issues > > Ben Perez 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 JDK-8261513 > - Added IOException for negative pathLenConstraint > - Changed constructor, getPathLen, and toString to return a canonical representation for unconstrained pathLens A couple more comments. You'll need to add an appropriate `noreg` label to the bug if you think it isn't practical to write a test for this. src/java.base/share/classes/sun/security/x509/BasicConstraintsExtension.java line 1: > 1: /* On line 186, it's questionable if we need to set the critical flag to the value of the ca field. This was comment #6 in the bug report. RFC 5280 gives a few cases where it is acceptable to have a non-critical BasicConstraintsExtension with a ca field set to true. I would remove that and make sure all tests still pass. src/java.base/share/classes/sun/security/x509/BasicConstraintsExtension.java line 167: > 165: String pathLenAsString; > 166: if (pathLen < 0 || pathLen == Integer.MAX_VALUE) { > 167: pathLenAsString = " unconstained"; Typo: s/unconstained/unconstrained/ But I actually prefer the words "no limit" as that is what [RFC 5280, section 4.2.1.9](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.9) uses, so please restore those words. You can use that term for the "undefined" case as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/20224#pullrequestreview-2627976730 PR Review Comment: https://git.openjdk.org/jdk/pull/20224#discussion_r1962385195 PR Review Comment: https://git.openjdk.org/jdk/pull/20224#discussion_r1962370853 From abarashev at openjdk.org Wed Feb 19 21:21:55 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 19 Feb 2025 21:21:55 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 18:44:38 GMT, Anthony Scarpino wrote: > Hi, > > I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. > > thanks > > Tony src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 79: > 77: private static List aliasXDH = null; > 78: private static List aliasX25519 = null; > 79: Wouldn't it be more concise to create a static algorithm-to-aliases map and then make getAliases() to do the map lookup? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1962387539 From abarashev at openjdk.org Wed Feb 19 21:34:51 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 19 Feb 2025 21:34:51 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 18:44:38 GMT, Anthony Scarpino wrote: > Hi, > > I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. > > thanks > > Tony src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 133: > 131: for (String a : algorithms) { > 132: if (algorithm.equalsIgnoreCase(a) || > 133: getAliases(a).contains(algorithm)) { We do case-insensitive match for the algorithm itself but then we do case-sensitive aliases lookup and case-sensitive match for the aliases `contains` call? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1962399964 From valeriep at openjdk.org Wed Feb 19 22:13:52 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 19 Feb 2025 22:13:52 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec In-Reply-To: References: <0Cnl_2GC5sPNo5SUTyI0ziEC7tQ44LvYwSXkOthntnI=.692670c4-12ad-4d83-87ba-b443221b35c0@github.com> Message-ID: On Thu, 13 Feb 2025 18:43:01 GMT, Daniel Jeli?ski wrote: >> Ah ok. So I assume TLS 1.3 is using a different code path or KDF. > > TLS 1.3 uses HKDF, and doesn't work with SunPKCS11 yet, see [JDK-8278640](https://bugs.openjdk.org/browse/JDK-8278640) I'd like to clarify the usage of `SunTlsKeyMaterial` and `SunTls12KeyMaterial` KGs first. Is `SunTlsKeyMaterial` KG expected to handle specs indicating TLS1.2 version? Is `SunTls12KeyMaterial` KeyGenerator expected to handle specs indicating SSL3.0 version? Looking at SunJCE provider's impls, `SunTlsKeyMaterial` and `SunTls12KeyMaterial` KGs are considered equivalent, e.g. one being the alias of the other. SunPKCS11 provider defines them separately mapping to different native mechs, however sharing the same impl class. Looking at the current code, it seems that `SunTls12KeyMaterial` will always set `supportSSLv3` to false which should reject specs indicating SSL3.0 version. There seems to be an inconsistency between SunJCE provider and SunPKCS11 provider? In addition, we should check that the particular mechanism is supported? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1962442625 From mullan at openjdk.org Wed Feb 19 22:37:51 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 19 Feb 2025 22:37:51 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms [v3] In-Reply-To: References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Thu, 13 Feb 2025 22:29:46 GMT, Jamil Nimeh wrote: >> Also, should it be moved to somewhere else like jdk/test/sun/security/provider/certpath? > >> Also, should it be moved to somewhere else like jdk/test/sun/security/provider/certpath? > > Hmmm...not sure about that, but maybe an explanation is in order: Because the JDK only implements the client side with OCSP, we rely on CertPathValidator to handle the path validation and that has never been a problem with PQC. When I did OCSP stapling a long time ago (JDK 9) that was when I wanted a way to build certs (good and malformed ones) and make OCSP servers that didn't need to fork processes outside the jtreg framework or need 3rd party code. That meant I had to implement the server-side (consumption of requests and generation of responses) and that's where things needed some tuning up. So it isn't really a CPV problem, it's a testcode problem. In order to exercise it and ensure that it worked for all the algs we use to sign stuff, I made this test-the-test-code test and at the suggestion of @rhalade I located in the lib-test tree. Using CPV in the test was mainly a way for me to drive the OCSP request from the JDK code. That it also validates consumption of the sign ed response and the cert chain is a nice freebie. > > Not opposed to making the changes, I just didn't know if it was the right way to go considering that I'm not changing any actual JDK code, just test helper classes so in the future we can do PQC cert chains and OCSP servers for our tests. No, I take back my comment - your explanation and the location makes sense. I hadn't realized it was a test testing a test server on my initial scan. I think the test summary should be more general and explain what the test is doing. Right now it says "Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms" but that is a side effect of adding this test, and not the main purpose of the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23566#discussion_r1962465483 From mullan at openjdk.org Wed Feb 19 22:41:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 19 Feb 2025 22:41:57 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 19:16:41 GMT, Weijun Wang wrote: > Also, now we have the same content in 3 places: > > 1. Here > > 2. In the Security Guide at https://docs.oracle.com/en/java/javase/23/security/troubleshooting-security.html#GUID-05F3E865-20FF-46EB-AC35-84D4B552CA48 > > 3. At https://github.com/openjdk/jdk/blob/940aa7c4cf1bf770690660c8bb21fb3ddc5186e4/src/java.base/share/classes/sun/security/util/Debug.java#L85 > . > Do we need to keep all of them? @seanjmullan Well, I still find #3 valuable as it is useful as a command-line help option. For #2, we don't need the duplication, but I think it is useful to still have a pointer from the guides to this new html file, so @koushikthirupattur please file a subtask (in the docs/guides category) to have the section in the security guide link to this new properties file in the javadoc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2669921633 From mullan at openjdk.org Wed Feb 19 22:53:55 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 19 Feb 2025 22:53:55 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 19:15:21 GMT, Weijun Wang wrote: > The name and title should not be "Security Properties". This is about the debug system property. Yes, this is because "Security Properties" are different than system properties, and are listed in the `java.security` file. We may want to someday also add them to this file, but not now. So, I would change it to "Security System Properties" or maybe "Security-Related System Properties" ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2669935766 From mullan at openjdk.org Wed Feb 19 22:53:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 19 Feb 2025 22:53:57 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v2] In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 19:12:51 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/2c58dd82-363e-49be-9734-755d5d0014d7) >> >> 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-properties.html line 60: > 58: the System.setProperty() API. > 59: The purpose of this document is to list > 60: and detail all of these properties. I would remove this last sentence. Although that is an eventual goal, it may not happen right away, so best to not give someone the impression that this is the only security related system property. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1962479350 From duke at openjdk.org Wed Feb 19 23:27:19 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Wed, 19 Feb 2025 23:27:19 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v3] 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](https://github.com/user-attachments/assets/2c58dd82-363e-49be-9734-755d5d0014d7) > > 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 two additional commits since the last revision: - 8328914: Document the java.security.debug property in javadoc - 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/1067f1a1..7f1f76c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 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 Wed Feb 19 23:39:54 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Wed, 19 Feb 2025 23:39:54 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v2] In-Reply-To: References: Message-ID: <6QvvRgjZLKaksy7uGxu4dN4c7Ui8wMEWixmidhho7Sw=.bc2b325b-4e0a-4d7c-9e36-4b486413764d@github.com> On Wed, 19 Feb 2025 22:39:21 GMT, Sean Mullan wrote: > > Also, now we have the same content in 3 places: > > ``` > > 1. Here > > > > 2. In the Security Guide at https://docs.oracle.com/en/java/javase/23/security/troubleshooting-security.html#GUID-05F3E865-20FF-46EB-AC35-84D4B552CA48 > > > > 3. At https://github.com/openjdk/jdk/blob/940aa7c4cf1bf770690660c8bb21fb3ddc5186e4/src/java.base/share/classes/sun/security/util/Debug.java#L85 > > . > > Do we need to keep all of them? @seanjmullan > > ``` > > Well, I still find #3 valuable as it is useful as a command-line help option. > > For #2, we don't need the duplication, but I think it is useful to still have a pointer from the guides to this new html file, so @koushikthirupattur please file a subtask (in the docs/guides category) to have the section in the security guide link to this new properties file in the javadoc. Created here [8350384](https://bugs.openjdk.org/browse/JDK-8350384) > > The name and title should not be "Security Properties". This is about the debug system property. > > Yes, this is because "Security Properties" are different than system properties, and are listed in the `java.security` file. We may want to someday also add them to this file, but not now. So, I would change it to "Security System Properties" or maybe "Security-Related System Properties" Changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2670017430 PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2670018086 From duke at openjdk.org Wed Feb 19 23:39:55 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Wed, 19 Feb 2025 23:39:55 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v2] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 22:50:40 GMT, Sean Mullan wrote: >> 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-properties.html line 60: > >> 58: the System.setProperty() API. >> 59: The purpose of this document is to list >> 60: and detail all of these properties. > > I would remove this last sentence. Although that is an eventual goal, it may not happen right away, so best to not give someone the impression that this is the only security related system property. Removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1962532696 From ascarpino at openjdk.org Wed Feb 19 23:56:52 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 19 Feb 2025 23:56:52 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 21:19:22 GMT, Artur Barashev wrote: >> Hi, >> >> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. >> >> thanks >> >> Tony > > src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 79: > >> 77: private static List aliasXDH = null; >> 78: private static List aliasX25519 = null; >> 79: > > Wouldn't it be more concise to create a static algorithm-to-aliases map and then make getAliases() to do the map lookup? It's purely a memory allocation solution here. If I make a Map, I have to populate the entries at initialization. Right now XDH and EdDSA are very unlikely to be disabled as they are relatively new algorithms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1962545286 From ascarpino at openjdk.org Thu Feb 20 00:17:54 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 20 Feb 2025 00:17:54 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 21:31:08 GMT, Artur Barashev wrote: >> Hi, >> >> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. >> >> thanks >> >> Tony > > src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 133: > >> 131: for (String a : algorithms) { >> 132: if (algorithm.equalsIgnoreCase(a) || >> 133: getAliases(a).contains(algorithm)) { > > We do case-insensitive match for the algorithm itself but then we do case-sensitive aliases lookup and case-sensitive match for the aliases `contains` call? Yep, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1962562833 From ascarpino at openjdk.org Thu Feb 20 00:20:30 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 20 Feb 2025 00:20:30 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing [v2] In-Reply-To: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> Message-ID: > I need a review of this change that adds new timing controls for the initial server setup. On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect. Additional debugging is added to help identify if there are other timing issues. > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23407/files - new: https://git.openjdk.org/jdk/pull/23407/files/0a0a7365..3ec8d051 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23407&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23407&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23407/head:pull/23407 PR: https://git.openjdk.org/jdk/pull/23407 From mpowers at openjdk.org Thu Feb 20 00:28:13 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 20 Feb 2025 00:28:13 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes [v3] In-Reply-To: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> Message-ID: > [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068) Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge master - review comments from Valerie and Sean - first iteration ------------- Changes: https://git.openjdk.org/jdk/pull/23188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23188&range=02 Stats: 32 lines in 4 files changed: 3 ins; 1 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/23188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23188/head:pull/23188 PR: https://git.openjdk.org/jdk/pull/23188 From weijun at openjdk.org Thu Feb 20 01:02:56 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 20 Feb 2025 01:02:56 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v3] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 23:27:19 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/bf8bb8bf-a63b-4b14-9790-783fa8c9c080) >> >> >> 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 two additional commits since the last revision: > > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc The `+thread` and `+timestamp` are modifiers that can be added to any value. I'd like them to be described outside the table. src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 55: > 53: There are several system properties used to > 54: alter the mechanisms and behavior of the various classes of the > 55: java.security package. Some are checked only once at startup of the VM, Code, identifiers and command line options like `java.security`, `-D`, `-XshowSettings:security`, etc should be shown in fixed-width. src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 68: > 66: specify the -XshowSettings:security option in the java command. > 67: You can enable debugging in JGSS and other related technologies with various system properties or environment variables. > 68: The following table lists java.security.debug options table:

Do you want to show some examples on how the options are specified? Especially when there are multiple options. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2670120348 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1962597531 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1962598898 From jnimeh at openjdk.org Thu Feb 20 01:12:46 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 20 Feb 2025 01:12:46 GMT Subject: RFR: 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms [v4] In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: > This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). 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 five additional commits since the last revision: - Add more descriptive summary to test - Merge with main - Remove unnecessary throws declarations - Fix JBS ID and summary in test - 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23566/files - new: https://git.openjdk.org/jdk/pull/23566/files/d0c95035..f39d0e83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23566&range=02-03 Stats: 18126 lines in 881 files changed: 12702 ins; 2531 del; 2893 mod Patch: https://git.openjdk.org/jdk/pull/23566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23566/head:pull/23566 PR: https://git.openjdk.org/jdk/pull/23566 From duke at openjdk.org Thu Feb 20 01:17:54 2025 From: duke at openjdk.org (Nicole Xu) Date: Thu, 20 Feb 2025 01:17:54 GMT Subject: RFR: 8349943: [JMH] Use jvmArgs consistently In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> Message-ID: On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote: > As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'. > > All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency. Hi @cl4es, here is a fellow-up fix of `jvmArgs` flags. Could you please review the changes? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23609#issuecomment-2670146567 From redestad at openjdk.org Thu Feb 20 01:25:59 2025 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 20 Feb 2025 01:25:59 GMT Subject: RFR: 8349943: [JMH] Use jvmArgs consistently In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> Message-ID: On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote: > As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'. > > All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency. Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23609#pullrequestreview-2628391999 From duke at openjdk.org Thu Feb 20 01:30:58 2025 From: duke at openjdk.org (Nicole Xu) Date: Thu, 20 Feb 2025 01:30:58 GMT Subject: RFR: 8349943: [JMH] Use jvmArgs consistently In-Reply-To: References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> Message-ID: On Thu, 13 Feb 2025 20:04:05 GMT, Chen Liang wrote: >> As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'. >> >> All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency. > > The java.lang.foreign arg changes look fine. @liach @sendaoYan @cl4es Thanks for your review. I'm going to integrate the patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23609#issuecomment-2670174332 From duke at openjdk.org Thu Feb 20 01:30:58 2025 From: duke at openjdk.org (duke) Date: Thu, 20 Feb 2025 01:30:58 GMT Subject: RFR: 8349943: [JMH] Use jvmArgs consistently In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> Message-ID: On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote: > As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'. > > All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency. @xyyNicole Your change (at version 06f874154e22886d7f1522a70dbdccd87fb4d004) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23609#issuecomment-2670175001 From haosun at openjdk.org Thu Feb 20 01:36:56 2025 From: haosun at openjdk.org (Hao Sun) Date: Thu, 20 Feb 2025 01:36:56 GMT Subject: RFR: 8349943: [JMH] Use jvmArgs consistently In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> Message-ID: On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote: > As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'. > > All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency. This patch has been reviewed and tested internally. GHA tests are all green. Let me sponsor it. ------------- Marked as reviewed by haosun (Committer). PR Review: https://git.openjdk.org/jdk/pull/23609#pullrequestreview-2628468812 From duke at openjdk.org Thu Feb 20 01:36:56 2025 From: duke at openjdk.org (Nicole Xu) Date: Thu, 20 Feb 2025 01:36:56 GMT Subject: Integrated: 8349943: [JMH] Use jvmArgs consistently In-Reply-To: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> References: <08dxLOf4JEBqkJxDjlJTib4_zmUraTx6-mO9FIblDx0=.61b739e3-4ea4-4be0-a3ec-459376863c5a@github.com> Message-ID: On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote: > As is suggested in [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should be used consistently in microbenchmarks to 'align with the intuition that when you use jvmArgsAppend/-Prepend intent is to add to a set of existing flags, while if you supply jvmArgs intent is "run with these and nothing else"'. > > All the previous flags were aligned in https://github.com/openjdk/jdk/pull/21683, while some recent tests use inconsistent `jvmArgs` again. We update them to keep the consistency. This pull request has now been integrated. Changeset: 3ebed783 Author: Nicole Xu Committer: Hao Sun URL: https://git.openjdk.org/jdk/commit/3ebed78328bd64d2e18369d63d6ea323b87a7b24 Stats: 20 lines in 9 files changed: 2 ins; 0 del; 18 mod 8349943: [JMH] Use jvmArgs consistently Reviewed-by: syan, redestad, haosun ------------- PR: https://git.openjdk.org/jdk/pull/23609 From duke at openjdk.org Thu Feb 20 11:26:04 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Thu, 20 Feb 2025 11:26:04 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: <6JZN5pTkkwHqTvrasCTsKDyCnLqCUnxIl_wtOH1T-aY=.27de66bf-9c75-48b2-ab8c-f2c5f6d68df8@github.com> On Wed, 19 Feb 2025 15:48:10 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) test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 35: > 33: * @run main/othervm IPIdentities > 34: * @author Xuelei Fan > 35: */ I think you might be missing ` * @modules java.base/sun.security.x509 java.base/sun.security.util` here test/lib/jdk/test/lib/security/CertificateBuilder.java line 113: > 111: SecureRandom random = new SecureRandom(); > 112: > 113: boolean [] keyUsage = new boolean[]{false, false, false, Wouldn't it be easier to just use `var keyUsage = new boolean[KeyUsage.values().length]`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r1963390414 PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r1963390219 From mdonovan at openjdk.org Thu Feb 20 12:31:37 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 20 Feb 2025 12:31:37 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v2] 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 incrementally with one additional commit since the last revision: changed boolean array initialization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23700/files - new: https://git.openjdk.org/jdk/pull/23700/files/e0da93d4..9257293e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 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 mdonovan at openjdk.org Thu Feb 20 12:50:52 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 20 Feb 2025 12:50:52 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v2] In-Reply-To: <6JZN5pTkkwHqTvrasCTsKDyCnLqCUnxIl_wtOH1T-aY=.27de66bf-9c75-48b2-ab8c-f2c5f6d68df8@github.com> References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> <6JZN5pTkkwHqTvrasCTsKDyCnLqCUnxIl_wtOH1T-aY=.27de66bf-9c75-48b2-ab8c-f2c5f6d68df8@github.com> Message-ID: <2vOQtpUqzqxrhlywzaU2bS06mybF1v50DKJoX1xqrCU=.13e3b692-cf24-49cd-aef8-283d14769e6d@github.com> On Thu, 20 Feb 2025 11:22:41 GMT, Mikhail Yankelevich wrote: >> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: >> >> changed boolean array initialization > > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 35: > >> 33: * @run main/othervm IPIdentities >> 34: * @author Xuelei Fan >> 35: */ > > I think you might be missing ` * @modules java.base/sun.security.x509 java.base/sun.security.util` here I added those modules in a TEST.properties file so I wouldn't have to update every test in the directory when I get to them. > test/lib/jdk/test/lib/security/CertificateBuilder.java line 113: > >> 111: SecureRandom random = new SecureRandom(); >> 112: >> 113: boolean [] keyUsage = new boolean[]{false, false, false, > > Wouldn't it be easier to just use `var keyUsage = new boolean[KeyUsage.values().length]`? I updated the array initialization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r1963507036 PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r1963506494 From michaelm at openjdk.org Thu Feb 20 14:05:53 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 20 Feb 2025 14:05:53 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v3] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 23:27:19 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/bf8bb8bf-a63b-4b14-9790-783fa8c9c080) >> >> >> 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 two additional commits since the last revision: > > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc As a regular user of the property, this change is a great idea. I think the text accompanying the table should describe the syntax of the property value. Is it a comma separated list etc? ------------- PR Review: https://git.openjdk.org/jdk/pull/23569#pullrequestreview-2629963339 From mullan at openjdk.org Thu Feb 20 14:24:59 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 20 Feb 2025 14:24:59 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 18:44:38 GMT, Anthony Scarpino wrote: > Hi, > > I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. > > thanks > > Tony src/java.base/share/classes/sun/security/util/KeyUtil.java line 180: > 178: If the key is a sub-algorithm of a larger group of algorithms, this method > 179: will return that sub-algorithm. For example, key.getAlgorithm() returns > 180: "EdDSA", but the underlying key maybe "Ed448". For s/maybe/may be/ src/java.base/share/classes/sun/security/util/KeyUtil.java line 184: > 182: "EdDSA" means all curves for DAC, but when using it with > 183: KeyPairGenerator, EdDSA means Ed25519. > 184: */ Use the common form for comments here, i.e.: /** * ... */ src/java.base/share/classes/sun/security/util/KeyUtil.java line 189: > 187: case EdECKey ed -> ed.getParams().getName(); > 188: case XECKey xe -> ((NamedParameterSpec) xe.getParams()).getName(); > 189: default -> key.getAlgorithm(); Do you also want to add cases for ML-KEM and ML-DSA keys? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1963656076 PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1963654110 PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1963654898 From mpowers at openjdk.org Thu Feb 20 14:36:54 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 20 Feb 2025 14:36:54 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes [v3] In-Reply-To: References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> <6i6DTgn_AToR0vH9MHBQTlHGjPLPS-6YkYELlho10bw=.b2386ebe-f54d-4f2b-9871-09c8fa5c31ec@github.com> Message-ID: On Wed, 12 Feb 2025 18:41:45 GMT, Valerie Peng wrote: >> Maybe we should just state that ArrayIndexOutOfBoundsException is thrown if `offset` or `len` is negative? The current wording for AIOOBE seems to suggest that it covers the case when `offset` or `len` is too large. But that is covered by the IAE. > > `SecretKeySpec` constructor has this same wording for AIOOBE, so if we change to cover negative value only, we should apply the same change to `SecretKeySpec` as well. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23188#discussion_r1963680366 From mpowers at openjdk.org Thu Feb 20 14:36:59 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 20 Feb 2025 14:36:59 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes [v3] In-Reply-To: References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> Message-ID: On Wed, 12 Feb 2025 21:08:50 GMT, Valerie Peng wrote: >> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge master >> - review comments from Valerie and Sean >> - first iteration > > src/java.base/share/classes/javax/crypto/spec/IvParameterSpec.java line 73: > >> 71: * or {@code (iv.length - offset < len)} >> 72: * @throws ArrayIndexOutOfBoundsException if {@code offset} >> 73: * or {@code len} index bytes outside the {@code iv}. > > `RC2ParameterSpec(int, byte[], int)` ctor should be documented with AIOOBE as well. If you pass a negative offset into it, AIOOBE is thrown by the `System.arraycopy()` call. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23188#discussion_r1963680579 From abarashev at openjdk.org Thu Feb 20 15:34:59 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 20 Feb 2025 15:34:59 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: <6TSjjEXEuS-qdzSM6UWu6uyy5DW5fv97rGiYLiiDu64=.5ae8f9a0-e7d9-481c-a340-ca1d26245126@github.com> On Wed, 19 Feb 2025 23:54:35 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 79: >> >>> 77: private static List aliasXDH = null; >>> 78: private static List aliasX25519 = null; >>> 79: >> >> Wouldn't it be more concise to create a static algorithm-to-aliases map and then make getAliases() to do the map lookup? > > It's purely a memory allocation solution here. If I make a Map, I have to populate the entries at initialization. Right now XDH and EdDSA are very unlikely to be disabled as they are relatively new algorithms. Right, I thought it was probably done to minimize memory usage. But all those string literals will be stored in a string pool at runtime and simply re-used when we allocate a list with them. So real memory saving should be very small comparing to a static map. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1963809024 From duke at openjdk.org Thu Feb 20 17:24:57 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 20 Feb 2025 17:24:57 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> References: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> Message-ID: On Tue, 11 Feb 2025 10:40:31 GMT, Bhavana Kilambi wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding comments + some code reorganization > > src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2618: > >> 2616: INSN(smaxp, 0, 0b101001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S >> 2617: INSN(sminp, 0, 0b101011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S >> 2618: INSN(sqdmulh,0, 0b101101, false); // accepted arrangements: T4H, T8H, T2S, T4S > > Hi, not a comment on the algorithm itself but you might have to add these new instructions in the gtest for aarch64 here - test/hotspot/gtest/aarch64/aarch64-asmtest.py and use this file to generate test/hotspot/gtest/aarch64/asmtest.out.h which would contain these newly added instructions. I have tried that, but the python script (actually the as command that it started) threw error messages: aarch64ops.s:338:24: error: index must be a multiple of 8 in range [0, 32760]. prfm PLDL1KEEP, [x15, 43] ^ aarch64ops.s:357:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] sub x1, x10, x23, sxth #2 ^ aarch64ops.s:359:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] add x11, x21, x5, uxtb #3 ^ aarch64ops.s:360:22: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] adds x11, x17, x17, uxtw #1 ^ aarch64ops.s:361:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] sub x11, x0, x15, uxtb #1 ^ aarch64ops.s:362:19: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] subs x7, x1, x0, sxth #2 ^ This is without any modifications from what is in the master branch currently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1964049673 From duke at openjdk.org Thu Feb 20 17:33:18 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 20 Feb 2025 17:33:18 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v6] In-Reply-To: References: Message-ID: > By using the aarch64 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 four additional commits since the last revision: - Accepting suggested change from Andrew Dinn - Added comments suggested by Andrew Dinn - Fixed copyright years - renaming a couple of functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23300/files - new: https://git.openjdk.org/jdk/pull/23300/files/9a3a9444..54373d5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=04-05 Stats: 98 lines in 6 files changed: 2 ins; 0 del; 96 mod Patch: https://git.openjdk.org/jdk/pull/23300.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23300/head:pull/23300 PR: https://git.openjdk.org/jdk/pull/23300 From mpowers at openjdk.org Thu Feb 20 17:36:14 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 20 Feb 2025 17:36:14 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes [v4] In-Reply-To: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> Message-ID: > [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: nit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23188/files - new: https://git.openjdk.org/jdk/pull/23188/files/c550f692..c5a05e97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23188&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23188&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23188/head:pull/23188 PR: https://git.openjdk.org/jdk/pull/23188 From fguallini at openjdk.org Thu Feb 20 18:54:57 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Thu, 20 Feb 2025 18:54:57 GMT Subject: Integrated: 8337723: Remove redundant tests from com/sun/security/sasl/gsskerb In-Reply-To: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> References: <7GlKRC_Mhwi2tS5sBMKlhU5XmeL9RCQhd4uWQec_2hE=.4164ff66-346b-4aee-b24d-286182f662e9@github.com> Message-ID: <7EIRsZEZjYYVC3kFuQYrVxiGMdI_LJV8JYyHQ3IxOh0=.f25fa716-5d89-4e5b-9183-1d1c3099752f@github.com> On Mon, 5 Aug 2024 10:46:32 GMT, Fernando Guallini wrote: > There are 3 manual GSS-API/Kerberos tests that require a manual setup and were added to the problem list years ago: > > - com/sun/security/sasl/gsskerb/**AuthOnly**-> Verifies that both client and server have completed the authentication process. > - com/sun/security/sasl/gsskerb/**NoSecurityLayer** -> Attempts to use wrap and unwrap to demonstrate that these operations should not be allowed without a negotiated security layer. > - com/sun/security/sasl/gsskerb/**ConfSecurityLayer** -> Demonstrates the use of the security layer by wrapping and unwrapping messages on both client and server sides. > > These tests need manual setup of a KDC environment, service/user principals, keytabs, JAAS configuration, and script adjustments. All that is time consuming and error prone. These do not fail if configured properly. > > In contrast, the automated test sun/security/krb5/auto/**SaslBasic** already covers these scenarios and sets up the KDC with the necessary principals **automatically**, no manual setup is required. This class starts a simple KDC with one realm, several typical principal names, generates krb5.conf and keytab files, and setup a JAAS login config file. > > I've enhanced SaslBasic to include additional wrap/unwrap checks with and without a security layer. As a result, the 3 manual tests and their associated files are now redundand and can be removed, as they no longer provide additional value. This pull request has now been integrated. Changeset: f979f727 Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.org/jdk/commit/f979f727b6137be9a3f85baed4fbfdd785970044 Stats: 892 lines in 12 files changed: 58 ins; 817 del; 17 mod 8337723: Remove redundant tests from com/sun/security/sasl/gsskerb Reviewed-by: rhalade ------------- PR: https://git.openjdk.org/jdk/pull/20464 From rhalade at openjdk.org Thu Feb 20 18:55:59 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 20 Feb 2025 18:55:59 GMT Subject: RFR: 8342238: Test javax/crypto/CryptoPermissions/InconsistentEntries.java writes files in tested JDK dir In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:20:27 GMT, Fernando Guallini wrote: > The test javax/crypto/CryptoPermissions/InconsistentEntries.java should not modify the JDK home directory under test as that could impact the results of other tests, or it could fail if the JDK home dir is read-only. > > This PR updates the test to > > - clone the tested JDK into the scratch directory. > - create the required directory and file in the cloned JDK directory. > - run a subprocess using the temporal JDK to test the scenario. > > There is no need to explicitly remove the tests files with an 'after' step, as JTreg will handle cleaning the scratch directory Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23202#pullrequestreview-2630861193 From fguallini at openjdk.org Thu Feb 20 18:56:00 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Thu, 20 Feb 2025 18:56:00 GMT Subject: Integrated: 8342238: Test javax/crypto/CryptoPermissions/InconsistentEntries.java writes files in tested JDK dir In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:20:27 GMT, Fernando Guallini wrote: > The test javax/crypto/CryptoPermissions/InconsistentEntries.java should not modify the JDK home directory under test as that could impact the results of other tests, or it could fail if the JDK home dir is read-only. > > This PR updates the test to > > - clone the tested JDK into the scratch directory. > - create the required directory and file in the cloned JDK directory. > - run a subprocess using the temporal JDK to test the scenario. > > There is no need to explicitly remove the tests files with an 'after' step, as JTreg will handle cleaning the scratch directory This pull request has now been integrated. Changeset: 16033ea7 Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.org/jdk/commit/16033ea79a01b27a7f5cbb31d64da0e80afc7dc3 Stats: 49 lines in 1 file changed: 21 ins; 14 del; 14 mod 8342238: Test javax/crypto/CryptoPermissions/InconsistentEntries.java writes files in tested JDK dir Reviewed-by: jnimeh, rhalade ------------- PR: https://git.openjdk.org/jdk/pull/23202 From valeriep at openjdk.org Thu Feb 20 19:20:55 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 20 Feb 2025 19:20:55 GMT Subject: RFR: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes [v4] In-Reply-To: References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> Message-ID: <17wQVnzZl9-luqLzSPFFU_sMflyMA8MZwAf2PJvRRUQ=.f01ee73d-a10d-4c7e-9eaf-f5bb7a283c35@github.com> On Thu, 20 Feb 2025 17:36:14 GMT, Mark Powers wrote: >> [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > nit Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23188#pullrequestreview-2630917979 From weijun at openjdk.org Thu Feb 20 20:29:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 20 Feb 2025 20:29:52 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v2] In-Reply-To: References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: <8FUIE2gpo0-n_UiPM1qbt9CHN9l8ZkraqlwHk9EGz4U=.aaf454e8-d97c-4aa2-bc7d-70647cac6c0b@github.com> On Thu, 20 Feb 2025 12:31:37 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 incrementally with one additional commit since the last revision: > > changed boolean array initialization The similarity between the certificate pairs is impressive! Just curious - why the change in issuer and owner names? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23700#issuecomment-2672607370 From mbalao at openjdk.org Thu Feb 20 20:31:40 2025 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 20 Feb 2025 20:31:40 GMT Subject: RFR: 8315487: Security Providers Filter [v21] In-Reply-To: References: Message-ID: <0-XKAp3GDqQpeD9D1XtAp31BwOvA-sZGWpKV5wTD-e8=.e73d4cf3-0970-41f8-b7e3-aa29ff6543db@github.com> > 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 incrementally with one additional commit since the last revision: 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15539/files - new: https://git.openjdk.org/jdk/pull/15539/files/1f23330c..1ffbe786 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=19-20 Stats: 1032 lines in 31 files changed: 833 ins; 0 del; 199 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 Thu Feb 20 21:52:55 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 20 Feb 2025 21:52:55 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v3] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 23:27:19 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/bf8bb8bf-a63b-4b14-9790-783fa8c9c080) >> >> >> 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 two additional commits since the last revision: > > - 8328914: Document the java.security.debug property in javadoc > - 8328914: Document the java.security.debug property in javadoc src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 66: > 64: which determines what trace messages are printed during execution. > 65: To view security properties, security providers, and TLS-related settings, > 66: specify the -XshowSettings:security option in the java command. This sentence seems out-of-place here. While I think it is useful to mention this, it has nothing to do with the `java.security.debug` property, so it seems a little confusing, and I suggest we not include it right now. Perhaps we can add another section on security related VM options later. src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 67: > 65: To view security properties, security providers, and TLS-related settings, > 66: specify the -XshowSettings:security option in the java command. > 67: You can enable debugging in JGSS and other related technologies with various system properties or environment variables. This is referring to other system properties like `sun.security.jgss.debug`. Since we are not documenting those other properties here (yet), we should remove this sentence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1964387349 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1964384163 From liach at openjdk.org Fri Feb 21 00:06:02 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Feb 2025 00:06:02 GMT Subject: RFR: 8350118: Simplify the layout access VarHandle Message-ID: Simplify the layout access var handles to be direct in some common cases. Also made `VarHandle::isAccessModeSupported` report if an access mode is supported for a VH. Reduces the instructions to execute this code in a simple main by 47%: long[] arr = new long[8]; var ms = MemorySegment.ofArray(arr); ms.setAtIndex(ValueLayout.JAVA_BYTE, 12, (byte) 3); Main overheads in FFM are identified to be: 1. Eager initialization of direct MethodHandle; can be CDS archived 2. MH combinator forms via LambdaFormEditor, not cached right now and always have large overhead Still need other measures to deal with common user patterns of `MethodHandles.insertCoordinates(vh, 1, 0L)` which currently is still very slow. Tests: tier 1-3 running ------------- Commit messages: - More cleanup - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline - Make sure the form impl class is initialized - Reduce MT initialization work - MH linkToStatic stall - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline - Merge branch 'master' of https://github.com/openjdk/jdk into feature/ffm-vh-inline - Enhance cache for basic value layouts - More stuff - VH inline stuff stage Changes: https://git.openjdk.org/jdk/pull/23720/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23720&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350118 Stats: 1869 lines in 16 files changed: 1056 ins; 215 del; 598 mod Patch: https://git.openjdk.org/jdk/pull/23720.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23720/head:pull/23720 PR: https://git.openjdk.org/jdk/pull/23720 From duke at openjdk.org Fri Feb 21 00:17:19 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 21 Feb 2025 00:17:19 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v4] 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](https://github.com/user-attachments/assets/bf8bb8bf-a63b-4b14-9790-783fa8c9c080) > > > 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 two additional commits since the last revision: - 8328914: Document the java.security.debug property in javadoc - 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/7f1f76c1..e950afb8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=02-03 Stats: 27 lines in 1 file changed: 13 ins; 11 del; 3 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 Fri Feb 21 00:17:19 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 21 Feb 2025 00:17:19 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v3] In-Reply-To: References: Message-ID: <0Bem7P0wAhrc3iRY9d-rp3-WIMLj1O1jzQTWrL8xLb4=.2c9471c5-8e5f-428f-bf11-4cb7fbcef9c8@github.com> On Thu, 20 Feb 2025 00:58:03 GMT, Weijun Wang wrote: >> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8328914: Document the java.security.debug property in javadoc >> - 8328914: Document the java.security.debug property in javadoc > > src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 55: > >> 53: There are several system properties used to >> 54: alter the mechanisms and behavior of the various classes of the >> 55: java.security package. Some are checked only once at startup of the VM, > > Code, identifiers and command line options like `java.security`, `-D`, `-XshowSettings:security`, etc should be shown in fixed-width. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1964539835 From duke at openjdk.org Fri Feb 21 00:17:19 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 21 Feb 2025 00:17:19 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v3] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 21:49:49 GMT, Sean Mullan wrote: >> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8328914: Document the java.security.debug property in javadoc >> - 8328914: Document the java.security.debug property in javadoc > > src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 66: > >> 64: which determines what trace messages are printed during execution. >> 65: To view security properties, security providers, and TLS-related settings, >> 66: specify the -XshowSettings:security option in the java command. > > This sentence seems out-of-place here. While I think it is useful to mention this, it has nothing to do with the `java.security.debug` property, so it seems a little confusing, and I suggest we not include it right now. Perhaps we can add another section on security related VM options later. Removed. > src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 67: > >> 65: To view security properties, security providers, and TLS-related settings, >> 66: specify the -XshowSettings:security option in the java command. >> 67: You can enable debugging in JGSS and other related technologies with various system properties or environment variables. > > This is referring to other system properties like `sun.security.jgss.debug`. Since we are not documenting those other properties here (yet), we should remove this sentence. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1964539681 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1964539551 From duke at openjdk.org Fri Feb 21 05:10:15 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 21 Feb 2025 05:10:15 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v5] 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](https://github.com/user-attachments/assets/bf8bb8bf-a63b-4b14-9790-783fa8c9c080) > > > 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/e950afb8..dbedca43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=03-04 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 wetmore at openjdk.org Fri Feb 21 06:19:02 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 21 Feb 2025 06:19:02 GMT Subject: RFR: 8350147: Replace example in KEM class with the one from JEP 452 [v3] In-Reply-To: References: Message-ID: <4BkhMP8bsKvE7cVtRzUt5by9e2wrVpqadMHUTHeqT0g=.ddfa4154-074e-4630-81d8-7926b4bc8fdd@github.com> On Tue, 18 Feb 2025 17:28:21 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Further codereview Comments from Weijun > > src/java.base/share/classes/javax/crypto/KEM.java line 68: > >> 66: *

>> 67: * >> 68: * Example operation using a ficticious {@code KEM} algorithm {@code ABC}: > > Typo: s/ficticious/fictitious/ Will fix in JDK-8350476 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23652#discussion_r1964911577 From duke at openjdk.org Fri Feb 21 10:09:56 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Fri, 21 Feb 2025 10:09:56 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: <3kiI1J7jcczgzTRi9HZztzhGe1blcy8Ga11xoGhzueY=.98543172-5b38-4199-bead-0988de0e0e75@github.com> References: <3kiI1J7jcczgzTRi9HZztzhGe1blcy8Ga11xoGhzueY=.98543172-5b38-4199-bead-0988de0e0e75@github.com> Message-ID: On Tue, 18 Feb 2025 13:33:52 GMT, Andrew Dinn wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding comments + some code reorganization > > src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2594: > >> 2592: guarantee(T != T1Q && T != T1D, "incorrect arrangement"); \ >> 2593: if (!acceptT2D) guarantee(T != T2D, "incorrect arrangement"); \ >> 2594: if (strcmp(#NAME, "sqdmulh") == 0) guarantee(T != T8B && T != T16B, "incorrect arrangement"); \ > > Suggestion: > > I think it might be better to change this test from a strcmp call to (opc2 == 0b101101). The strcmp test is clearer to a reader of the code but the call may not be guaranteed to be compiled out at build time while the latter will. Changed as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1965215153 From duke at openjdk.org Fri Feb 21 10:14:00 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Fri, 21 Feb 2025 10:14:00 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: On Tue, 18 Feb 2025 13:43:18 GMT, Andrew Dinn wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding comments + some code reorganization > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4066: > >> 4064: } >> 4065: >> 4066: // Execute on round of keccak of two computations in parallel. > > Suggestion: > > It would be helpful to add comments that relate the register and instruction selection to the original Java source code. e.g. change the header as follows > > // Performs 2 keccak round transformations using vector parallelism > // > // Two sets of 25 * 64-bit input states a0[lo:hi]...a24[lo:hi] are passed in > // the lower/upper halves of registers v0...v24 and the transformed states > // are returned in the same registers. Intermediate 64-bit pairs > // c0...c5 and d0...d5 are computed in registers v25...v30. v31 is > // loaded with the required pair of 64 bit rounding constants. > // During computation of the output states some intermediate results are > // shuffled around registers v0...v30. Comments on each line indicate > // how the values in registers correspond to variables ai, ci, di in > // the Java source code, likewise how the generated machine instructions > // correspond to Java source operations (n.b. rol means rotate left). > > The annotate the generation steps as follows: > > __ eor3(v29, __ T16B, v4, v9, v14); // c4 = a4 ^ a9 ^ a14 > __ eor3(v26, __ T16B, v1, v6, v11); // c1 = a1 ^ a16 ^ a11 > __ eor3(v28, __ T16B, v3, v8, v13); // c3 = a3 ^ a8 ^a13 > __ eor3(v25, __ T16B, v0, v5, v10); // c0 = a0 ^ a5 ^ a10 > __ eor3(v27, __ T16B, v2, v7, v12); // c2 = a2 ^ a7 ^ a12 > __ eor3(v29, __ T16B, v29, v19, v24); // c4 ^= a19 ^ a24 > __ eor3(v26, __ T16B, v26, v16, v21); // c1 ^= a16 ^ a21 > __ eor3(v28, __ T16B, v28, v18, v23); // c3 ^= a18 ^ a23 > __ eor3(v25, __ T16B, v25, v15, v20); // c0 ^= a15 ^ a20 > __ eor3(v27, __ T16B, v27, v17, v22); // c2 ^= a17 ^ a22 > > __ rax1(v30, __ T2D, v29, v26); // d0 = c4 ^ rol(c1, 1) > __ rax1(v26, __ T2D, v26, v28); // d2 = c1 ^ rol(c3, 1) > __ rax1(v28, __ T2D, v28, v25); // d4 = c3 ^ rol(c0, 1) > __ rax1(v25, __ T2D, v25, v27); // d1 = c0 ^ rol(c2, 1) > __ rax1(v27, __ T2D, v27, v29); // d3 = c2 ^ rol(c4, 1) > > __ eor(v0, __ T16B, v0, v30); // a0 = a0 ^ d0 > __ xar(v29, __ T2D, v1, v25, (64 - 1)); // a10' = rol((a1^d1), 1) > __ xar(v1, __ T2D, v6, v25, (64 - 44)); // a1 = rol(a6^d1), 44) > __ xar(v6, __ T2D, v9, v28, (64 - 20)); // a6 = rol((a9^d4), 20) > __ xar(v... Although this piece of code is not new, and I don't really think that this level of commenting is necessary, especially in code that is very unlikely to change, I added the comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1965220606 From duke at openjdk.org Fri Feb 21 10:25:59 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Fri, 21 Feb 2025 10:25:59 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 02:55:18 GMT, Hao Sun wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding comments + some code reorganization > > Hi. Here is the test result of our CI. > > ### copyright year > > the following files should update the copyright year to 2025. > > > src/hotspot/cpu/aarch64/assembler_aarch64.hpp > src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp > src/hotspot/share/runtime/globals.hpp > src/java.base/share/classes/sun/security/provider/ML_DSA.java > src/java.base/share/classes/sun/security/provider/SHA3Parallel.java > test/micro/org/openjdk/bench/java/security/MLDSA.java > > > ### cross-build failure > > Cross build for riscv64/s390/ppc64 failed. > > Here shows the error msg for ppc64 > > > === Output from failing command(s) repeated here === > * For target support_interim-jmods_support__create_java.base.jmod_exec: > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/tmp/jdk-src/src/hotspot/share/asm/codeBuffer.hpp:200), pid=72752, tid=72769 > # assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000e85cb03dc620 <= 0x0000e85cb03e8ab4 <= 0x0000e85cb03e8ab0 > # > # JRE version: OpenJDK Runtime Environment (25.0) (fastdebug build 25-internal-git-1e01c6deec3) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-git-1e01c6deec3, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) > # Problematic frame: > # V [libjvm.so+0x3b391c] Instruction_aarch64::~Instruction_aarch64()+0xbc > # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /tmp/ci-scripts/jdk-src/make/ > # > # An error report file with more information is saved as: > # /tmp/jdk-src/make/hs_err_pid72752.log > ... (rest of output omitted) > > * All command lines available in /sysroot/ppc64el/tmp/build-ppc64el/make-support/failure-logs. > === End of repeated output === > > > I suppose we should make the similar update at file `src/hotspot/cpu/aarch64/stubDeclarations_aarch64.hpp` to other platforms @shqking, I changed the copyright years, but I don't really understand how the aarch64-specific code can overflow buffers on other architectures. As far as I understand, Instruction_aarch64 should not have been there in a ppc build. Was this a build attempted on an aarch64 for the other architectures? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2674156680 From duke at openjdk.org Fri Feb 21 13:25:33 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Fri, 21 Feb 2025 13:25:33 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java Message-ID: Changed shell files to be java tests: * ./validator/certreplace.sh * ./validator/samedn.sh ------------- Commit messages: - changed to 2 different test ids - 8349533: Refactor validator tests shell files to java Changes: https://git.openjdk.org/jdk/pull/23727/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349533 Stats: 326 lines in 3 files changed: 151 ins; 174 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23727/head:pull/23727 PR: https://git.openjdk.org/jdk/pull/23727 From mdonovan at openjdk.org Fri Feb 21 13:50:54 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 21 Feb 2025 13:50:54 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v2] In-Reply-To: <8FUIE2gpo0-n_UiPM1qbt9CHN9l8ZkraqlwHk9EGz4U=.aaf454e8-d97c-4aa2-bc7d-70647cac6c0b@github.com> References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> <8FUIE2gpo0-n_UiPM1qbt9CHN9l8ZkraqlwHk9EGz4U=.aaf454e8-d97c-4aa2-bc7d-70647cac6c0b@github.com> Message-ID: On Thu, 20 Feb 2025 20:27:27 GMT, Weijun Wang wrote: > The similarity between the certificate pairs is impressive! Just curious - why the change in issuer and owner names? Looks like it's something between `keytool` and `openssl x509`. When i print the certificates with openssl, the issuer and owner names are in the opposite order from keytool. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23700#issuecomment-2674599121 From weijun at openjdk.org Fri Feb 21 15:07:57 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 21 Feb 2025 15:07:57 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java In-Reply-To: References: Message-ID: <4Ee_3k4fGObBO0CwqZXhHsGRV_on-JpQAyCTqr4bnkg=.9578022d-c629-4867-839b-33b29d414d9f@github.com> On Fri, 21 Feb 2025 11:49:26 GMT, Mikhail Yankelevich wrote: > Changed shell files to be java tests: > * ./validator/certreplace.sh > * ./validator/samedn.sh test/jdk/sun/security/validator/CertReplace.java line 117: > 115: final String outputInt = SecurityTools.keytool(ktBaseParameters + > 116: "-export -rfc -alias int").getOutput(); > 117: Files.write(certPath, outputInt.getBytes(), StandardOpenOption.APPEND); There are several places that can be enhanced, mainly to reduce `keytool` calling: 1. There is no need to export certs for `user` and `int`. You already created them as `user.cert` and `int.cert`. 2. Since "certreplace.certs" starts with "user.cert", you can directly `keytool -gencert` into this file on line 103. 3. There is no need to import "user.cert" to alias user since we will delete the entry anyway. 4. Consider replacing `keytool -import` and `keytool -delete` calls using `KeyStore` API. You can enhance `KeyStoreUtils` in `/test/lib` if worth doing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1965643259 From bperez at openjdk.org Fri Feb 21 16:40:08 2025 From: bperez at openjdk.org (Ben Perez) Date: Fri, 21 Feb 2025 16:40:08 GMT Subject: RFR: 8261513: Various BasicConstraintsExtension issues [v4] In-Reply-To: <_-E8euMT24qWQQJBRbNusSF_tHiDCiYdWzqlVccO2BA=.d5f20c54-1178-489f-9eac-75bbbc381791@github.com> References: <_-E8euMT24qWQQJBRbNusSF_tHiDCiYdWzqlVccO2BA=.d5f20c54-1178-489f-9eac-75bbbc381791@github.com> Message-ID: > 8261513: Various BasicConstraintsExtension issues Ben Perez has updated the pull request incrementally with one additional commit since the last revision: changed toString wording, no longer set critical to ca ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20224/files - new: https://git.openjdk.org/jdk/pull/20224/files/64398d5c..6ba44821 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20224&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20224&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20224/head:pull/20224 PR: https://git.openjdk.org/jdk/pull/20224 From duke at openjdk.org Fri Feb 21 16:51:54 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Fri, 21 Feb 2025 16:51:54 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java In-Reply-To: <4Ee_3k4fGObBO0CwqZXhHsGRV_on-JpQAyCTqr4bnkg=.9578022d-c629-4867-839b-33b29d414d9f@github.com> References: <4Ee_3k4fGObBO0CwqZXhHsGRV_on-JpQAyCTqr4bnkg=.9578022d-c629-4867-839b-33b29d414d9f@github.com> Message-ID: On Fri, 21 Feb 2025 15:05:00 GMT, Weijun Wang wrote: >> Changed shell files to be java tests: >> * ./validator/certreplace.sh >> * ./validator/samedn.sh > > test/jdk/sun/security/validator/CertReplace.java line 117: > >> 115: final String outputInt = SecurityTools.keytool(ktBaseParameters + >> 116: "-export -rfc -alias int").getOutput(); >> 117: Files.write(certPath, outputInt.getBytes(), StandardOpenOption.APPEND); > > There are several places that can be enhanced, mainly to reduce `keytool` calling: > 1. There is no need to export certs for `user` and `int`. You already created them as `user.cert` and `int.cert`. > 2. Since "certreplace.certs" starts with "user.cert", you can directly `keytool -gencert` into this file on line 103. > 3. There is no need to import "user.cert" to alias user since we will delete the entry anyway. > 4. Consider replacing `keytool -import` and `keytool -delete` calls using `KeyStore` API. You can enhance `KeyStoreUtils` in `/test/lib` if worth doing. done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1965868298 From liach at openjdk.org Fri Feb 21 16:54:55 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Feb 2025 16:54:55 GMT Subject: RFR: 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%. We don't need to bring hotspot in. The same issue has been described in https://bugs.openjdk.org/browse/JDK-8308105. We can proceed with this patch. src/java.base/share/classes/sun/security/provider/ML_DSA.java line 2: > 1: /* > 2: * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2024, 2025, Oracle and/or its affiliates. All rights reserved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23642#issuecomment-2675063845 PR Review Comment: https://git.openjdk.org/jdk/pull/23642#discussion_r1965870968 From duke at openjdk.org Fri Feb 21 16:57:32 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Fri, 21 Feb 2025 16:57:32 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v2] In-Reply-To: References: Message-ID: <6prT9j5xfHlmuZ_T2BJGjtDr3FkovRwTsXLuTdesYrg=.f9930b91-5a5c-4829-9cf2-2dd9f94e32a8@github.com> > Changed shell files to be java tests: > * ./validator/certreplace.sh > * ./validator/samedn.sh Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: keyStore is not used to delete, cleanup of the calls, minor refactoring ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23727/files - new: https://git.openjdk.org/jdk/pull/23727/files/a2eed266..f333ddff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=00-01 Stats: 95 lines in 1 file changed: 43 ins; 26 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/23727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23727/head:pull/23727 PR: https://git.openjdk.org/jdk/pull/23727 From hchao at openjdk.org Fri Feb 21 17:50:53 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 21 Feb 2025 17:50:53 GMT Subject: RFR: 8348309: MultiNST tests need more debugging and timing [v2] In-Reply-To: References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com> Message-ID: <_Sag2dCSHYevRSd2S_C2yBretwDM-yfSM3p7_QGkYKQ=.c7eb90d8-ed31-402c-92d9-fdf5ef53ec48@github.com> On Thu, 20 Feb 2025 00:20:30 GMT, Anthony Scarpino wrote: >> I need a review of this change that adds new timing controls for the initial server setup. On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect. Additional debugging is added to help identify if there are other timing issues. >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by hchao (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23407#pullrequestreview-2633821964 From ascarpino at openjdk.org Fri Feb 21 17:54:56 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 21 Feb 2025 17:54:56 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: <7thOhX-z4a54fLx62GDGGbrH3dRiTORK4GV7yqwthiM=.1daad2d1-86c7-4ba2-90c4-bbe9b279302d@github.com> On Thu, 20 Feb 2025 14:20:34 GMT, Sean Mullan wrote: >> Hi, >> >> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. >> >> thanks >> >> Tony > > src/java.base/share/classes/sun/security/util/KeyUtil.java line 189: > >> 187: case EdECKey ed -> ed.getParams().getName(); >> 188: case XECKey xe -> ((NamedParameterSpec) xe.getParams()).getName(); >> 189: default -> key.getAlgorithm(); > > Do you also want to add cases for ML-KEM and ML-DSA keys? @wangweij is planning on name usage for those. I'm focusing on these older curves. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1965944775 From duke at openjdk.org Fri Feb 21 18:07:58 2025 From: duke at openjdk.org (Johannes Graham) Date: Fri, 21 Feb 2025 18:07:58 GMT Subject: RFR: 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 PR might be relevant: https://github.com/openjdk/jdk/pull/22829 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23642#issuecomment-2675219511 From mullan at openjdk.org Fri Feb 21 18:31:59 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 21 Feb 2025 18:31:59 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v3] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 14:03:37 GMT, Michael McMahon wrote: > As a regular user of the property, this change is a great idea. I think the text accompanying the table should describe the syntax of the property value. Is it a comma separated list etc? The syntax has always been a bit loosely specified. So I suggest we don't say anything too specific, but just something like: "The value of the property is one or more options separated by a comma. Some options also have additional sub-options; see the list below for more details on the syntax of each." ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2675266655 From mullan at openjdk.org Fri Feb 21 18:38:54 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 21 Feb 2025 18:38:54 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: <7thOhX-z4a54fLx62GDGGbrH3dRiTORK4GV7yqwthiM=.1daad2d1-86c7-4ba2-90c4-bbe9b279302d@github.com> References: <7thOhX-z4a54fLx62GDGGbrH3dRiTORK4GV7yqwthiM=.1daad2d1-86c7-4ba2-90c4-bbe9b279302d@github.com> Message-ID: On Fri, 21 Feb 2025 17:52:18 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/sun/security/util/KeyUtil.java line 189: >> >>> 187: case EdECKey ed -> ed.getParams().getName(); >>> 188: case XECKey xe -> ((NamedParameterSpec) xe.getParams()).getName(); >>> 189: default -> key.getAlgorithm(); >> >> Do you also want to add cases for ML-KEM and ML-DSA keys? > > @wangweij is planning on name usage for those. I'm focusing on these older curves. They are already defined. I think you just want to add something like: If (key.getAlgorithm().equals("ML-KEM") || key.getAlgorithm().equals("ML-DSA")) { return ((NamedParameterSpec) key.getParams()).getName(); } Not urgent, but useful if one of these algorithms were to weaken or be broken for some reason. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966001285 From weijun at openjdk.org Fri Feb 21 18:58:56 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 21 Feb 2025 18:58:56 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v2] In-Reply-To: <6prT9j5xfHlmuZ_T2BJGjtDr3FkovRwTsXLuTdesYrg=.f9930b91-5a5c-4829-9cf2-2dd9f94e32a8@github.com> References: <6prT9j5xfHlmuZ_T2BJGjtDr3FkovRwTsXLuTdesYrg=.f9930b91-5a5c-4829-9cf2-2dd9f94e32a8@github.com> Message-ID: On Fri, 21 Feb 2025 16:57:32 GMT, Mikhail Yankelevich wrote: >> Changed shell files to be java tests: >> * ./validator/certreplace.sh >> * ./validator/samedn.sh > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > keyStore is not used to delete, cleanup of the calls, minor refactoring test/jdk/sun/security/validator/CertReplace.java line 28: > 26: */ > 27: > 28: import java.io.FileInputStream; Remove the "This test is called by certreplace.sh" line above. test/jdk/sun/security/validator/CertReplace.java line 64: > 62: * > 63: * @run main/othervm CertReplace samedn.jks samedn1.certs > 64: * @run main/othervm CertReplace samedn.jks samedn2.certs Must these tests run in `othervm`? They haven't changed any static VM properties. test/jdk/sun/security/validator/CertReplace.java line 82: > 80: final String intAliase = "int"; > 81: final String userAlias = "user"; > 82: final String caAlias = "ca"; Do you really believe creating these variables help the program looking better? There are so many string concatenations in the keytool commands. If it were me, I would remove every variable for a string literal except for `ktBaseParameters`. On the other hand, it's OK to put `"changeit".toCharArray()` into a variable. test/jdk/sun/security/validator/CertReplace.java line 120: > 118: new FileInputStream(intCertFileName) > 119: ) > 120: }; Use `CertUtils.getCertFromStream`. Also, it's better to close the file. Maybe Windows dislikes open files. test/jdk/sun/security/validator/CertReplace.java line 147: > 145: "-selfcert -alias " + caAlias); > 146: keyStore.deleteEntry(intAliase); > 147: keyStore.deleteEntry(userAlias); Call `keyStore.store` to actually remove the 2 entries inside the keystore file. But this needs to be done before the `-selfcert` call, otherwise, the old cert would overwrite the new one. test/jdk/sun/security/validator/CertReplace.java line 197: > 195: > 196: // 3. Remove user for cacerts > 197: keyStore.deleteEntry(userAlias); Call `keyStore.store` to write to the keystore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1965994249 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1966022164 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1965999262 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1966008483 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1966005851 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1966016971 From mullan at openjdk.org Fri Feb 21 19:18:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 21 Feb 2025 19:18:53 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: <9GvpZdkvoPsLDkJO3tCdy2Jf7iby5LErXi5PvHNGefk=.04dde4f7-39fc-42d6-b120-baf8a4a7e5d1@github.com> On Fri, 14 Feb 2025 18:44:38 GMT, Anthony Scarpino wrote: > Hi, > > I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. > > thanks > > Tony src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 95: > 93: case "Ed25519" -> { > 94: if (aliasEd25519 == null) { > 95: aliasEd25519 = List.of("EdDSA", "Ed25519"); Hmm. Should disabling Ed25519 also disable EdDSA? I can see the reverse, but isn't Ed25519 meant to be a specific curve for EdDSA? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966046628 From mullan at openjdk.org Fri Feb 21 19:55:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 21 Feb 2025 19:55:57 GMT Subject: RFR: 8349759: Add unit test for CertificateBuilder and SimpleOCSPServer test utilities [v4] In-Reply-To: References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Thu, 20 Feb 2025 01:12:46 GMT, Jamil Nimeh wrote: >> This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). > > 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 five additional commits since the last revision: > > - Add more descriptive summary to test > - Merge with main > - Remove unnecessary throws declarations > - Fix JBS ID and summary in test > - 8349759: Fix CertificateBuilder and SimpleOCSPServer test utilities to support PQC algorithms Looks good. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23566#pullrequestreview-2634091549 From duke at openjdk.org Fri Feb 21 19:59:14 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 21 Feb 2025 19:59:14 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v6] In-Reply-To: References: Message-ID: <4LqRv5AsD4Hyoac0oOroUI3c-Qkf6ul1B7s1iyHejlg=.3fa97db2-0687-4b64-8492-6a0d434ea576@github.com> > 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/bf8bb8bf-a63b-4b14-9790-783fa8c9c080) > > > 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/dbedca43..46954537 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=04-05 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 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 fguallini at openjdk.org Fri Feb 21 20:03:28 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 21 Feb 2025 20:03:28 GMT Subject: RFR: 8350456: Test javax/crypto/CryptoPermissions/InconsistentEntries.java crashed: EXCEPTION_ACCESS_VIOLATION Message-ID: The test javax/crypto/CryptoPermissions/InconsistentEntries.java uses CDSTestUtils.clone to copy the JDK into the scratch dir by creating symbolic links, but this was seen to crash the VM in Windows Server 2025. To ensure test stability, it should hard copy the required files. ------------- Commit messages: - refactoring imports in FileUtils - moved copyDirectory to FileUtils - hard copying jdk folder to scratch Changes: https://git.openjdk.org/jdk/pull/23726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23726&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350456 Stats: 29 lines in 2 files changed: 27 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23726.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23726/head:pull/23726 PR: https://git.openjdk.org/jdk/pull/23726 From weijun at openjdk.org Fri Feb 21 20:12:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 21 Feb 2025 20:12:52 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: <7thOhX-z4a54fLx62GDGGbrH3dRiTORK4GV7yqwthiM=.1daad2d1-86c7-4ba2-90c4-bbe9b279302d@github.com> Message-ID: On Fri, 21 Feb 2025 18:36:39 GMT, Sean Mullan wrote: >> @wangweij is planning on name usage for those. I'm focusing on these older curves. > > They are already defined. I think you just want to add something like: > > > If (key.getAlgorithm().equals("ML-KEM") || key.getAlgorithm().equals("ML-DSA")) { > return ((NamedParameterSpec) key.getParams()).getName(); > } > > > Not urgent, but useful if one of these algorithms were to weaken or be broken for some reason. Or what about this? if (key instanceof AsymmetricKey ak) { if (ak.getParams() instanceof NamedParameterSpec nps) { return nps.getName(); } } return key.getAlgorithm(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966113001 From weijun at openjdk.org Fri Feb 21 20:28:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 21 Feb 2025 20:28:52 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 18:44:38 GMT, Anthony Scarpino wrote: > Hi, > > I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. > > thanks > > Tony src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 78: > 76: private static List aliasEd25519 = null; > 77: private static List aliasXDH = null; > 78: private static List aliasX25519 = null; I am a little suspicious in this approach. At least this means for each "family" algorithm name like "EdDSA", we need to hardcode all its parameter set names here. Sounds not very sustainable. An EdDSA key always has its `getAlgorithm` being "EdDSA" (at least inside SunEC) and its `getParams()` being the parameter set name. So it looks like it's enough if we do a name comparison on both. Also, why no `aliasEd448` and `aliasX448` here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966129144 From jnimeh at openjdk.org Fri Feb 21 20:32:58 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 21 Feb 2025 20:32:58 GMT Subject: Integrated: 8349759: Add unit test for CertificateBuilder and SimpleOCSPServer test utilities In-Reply-To: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> References: <_Ju02MoTeZbyfvMfxZTVEFK6Nteu2qjlCEpXQcNFIho=.2e2c0d57-25ee-45ea-9548-fb4d3f34db18@github.com> Message-ID: On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh wrote: > This fix makes some minor changes to the internals of the `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS works better now with these changes. I've also taken this opportunity to do some cleanup on CertificateBuilder and added a method which uses a default signing algorithm based on the key, so the `build()` method no longer needs to provide that algorithm (though one can if they wish for things like RSA signatures if they want a different message digest in the signature). This pull request has now been integrated. Changeset: 9d9d7a17 Author: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/9d9d7a17d3d1a8971712ef1b22e919012350db6f Stats: 329 lines in 3 files changed: 270 ins; 21 del; 38 mod 8349759: Add unit test for CertificateBuilder and SimpleOCSPServer test utilities Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/23566 From ascarpino at openjdk.org Fri Feb 21 20:33:54 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 21 Feb 2025 20:33:54 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: <7thOhX-z4a54fLx62GDGGbrH3dRiTORK4GV7yqwthiM=.1daad2d1-86c7-4ba2-90c4-bbe9b279302d@github.com> Message-ID: On Fri, 21 Feb 2025 20:10:33 GMT, Weijun Wang wrote: >> They are already defined. I think you just want to add something like: >> >> >> If (key.getAlgorithm().equals("ML-KEM") || key.getAlgorithm().equals("ML-DSA")) { >> return ((NamedParameterSpec) key.getParams()).getName(); >> } >> >> >> Not urgent, but useful if one of these algorithms were to weaken or be broken for some reason. > > Or what about this? > > if (key instanceof AsymmetricKey ak) { > if (ak.getParams() instanceof NamedParameterSpec nps) { > return nps.getName(); > } > } > return key.getAlgorithm(); > > `AsymmetricKey` was introduced to make our lives easier. I stayed away from that because this is likely being backported ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966134944 From jnimeh at openjdk.org Fri Feb 21 20:35:54 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 21 Feb 2025 20:35:54 GMT Subject: RFR: 8350456: Test javax/crypto/CryptoPermissions/InconsistentEntries.java crashed: EXCEPTION_ACCESS_VIOLATION In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 10:31:34 GMT, Fernando Guallini wrote: > The test javax/crypto/CryptoPermissions/InconsistentEntries.java uses CDSTestUtils.clone to copy the JDK into the scratch dir by creating symbolic links, but this was seen to crash the VM in Windows Server 2025. To ensure test stability, it should hard copy the required files. Marked as reviewed by jnimeh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23726#pullrequestreview-2634162515 From weijun at openjdk.org Fri Feb 21 20:37:53 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 21 Feb 2025 20:37:53 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 18:44:38 GMT, Anthony Scarpino wrote: > Hi, > > I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. > > thanks > > Tony test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 61: > 59: case "Ed25519" -> > 60: Arrays.asList( > 61: new TestCase("EdDSA", false), As Sean mentioned in another comment, disabling "Ed25519" does not imply all EdDSA keys are not permitted. This means the result of `permits(primitives, algorithmName, parameters)` cannot be determined. That said, I noticed you've used `KeyUtil::getAlgorithm` in a lot of places. Can we guarantee that this `permits` method is never called on a family algorithm name? If so, we can get a definitive result. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966138673 From fguallini at openjdk.org Fri Feb 21 20:51:11 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 21 Feb 2025 20:51:11 GMT Subject: RFR: 8350456: Test javax/crypto/CryptoPermissions/InconsistentEntries.java crashed: EXCEPTION_ACCESS_VIOLATION [v2] In-Reply-To: References: Message-ID: > The test javax/crypto/CryptoPermissions/InconsistentEntries.java uses CDSTestUtils.clone to copy the JDK into the scratch dir by creating symbolic links, but this was seen to crash the VM in Windows Server 2025. To ensure test stability, it should hard copy the required files. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: updated comment with runtimeException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23726/files - new: https://git.openjdk.org/jdk/pull/23726/files/98aee523..fbd35872 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23726&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23726&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23726.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23726/head:pull/23726 PR: https://git.openjdk.org/jdk/pull/23726 From vpaprotski at openjdk.org Fri Feb 21 20:58:27 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Fri, 21 Feb 2025 20:58:27 GMT Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64 Message-ID: Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain) Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain. Before (no AVX512) Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units SignatureBench.ECDSA.sign SHA256withECDSA 1024 256 thrpt 40 3720.589 ? 17.879 ops/s SignatureBench.ECDSA.sign SHA256withECDSA 16384 256 thrpt 40 3605.940 ? 15.807 ops/s SignatureBench.ECDSA.verify SHA256withECDSA 1024 256 thrpt 40 1076.502 ? 4.190 ops/s SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 thrpt 40 1069.624 ? 2.484 ops/s Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 830.448 ? 2.285 ops/s After (with AVX2) Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units SignatureBench.ECDSA.sign SHA256withECDSA 1024 256 thrpt 40 6000.496 ? 39.923 ops/s SignatureBench.ECDSA.sign SHA256withECDSA 16384 256 thrpt 40 5739.878 ? 34.838 ops/s SignatureBench.ECDSA.verify SHA256withECDSA 1024 256 thrpt 40 1942.437 ? 12.179 ops/s SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 thrpt 40 1921.770 ? 8.992 ops/s Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 1399.761 ? 6.238 ops/s Before (with AVX512): Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units SignatureBench.ECDSA.sign SHA256withECDSA 1024 256 thrpt 40 9621.950 ? 27.260 ops/s SignatureBench.ECDSA.sign SHA256withECDSA 16384 256 thrpt 40 8975.654 ? 26.707 ops/s SignatureBench.ECDSA.verify SHA256withECDSA 1024 256 thrpt 40 3112.945 ? 12.930 ops/s SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 thrpt 40 3039.183 ? 12.362 ops/s Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 2248.987 ? 7.427 ops/s After (with AVX512): Benchmark (algorithm) (dataSize) (keyLength) (provider) Mode Cnt Score Error Units SignatureBench.ECDSA.sign SHA256withECDSA 1024 256 thrpt 40 9815.713 ? 23.455 ops/s SignatureBench.ECDSA.sign SHA256withECDSA 16384 256 thrpt 40 9136.786 ? 27.747 ops/s SignatureBench.ECDSA.verify SHA256withECDSA 1024 256 thrpt 40 3167.702 ? 13.331 ops/s SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 thrpt 40 3090.053 ? 12.925 ops/s Benchmark (algorithm) (keyLength) (kpgAlgorithm) (provider) Mode Cnt Score Error Units KeyAgreementBench.EC.generateSecret ECDH 256 EC thrpt 40 2278.031 ? 6.971 ops/s ------------- Commit messages: - whitespace - split up ASM and Math changes Changes: https://git.openjdk.org/jdk/pull/23719/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23719&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350459 Stats: 625 lines in 9 files changed: 525 ins; 15 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/23719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23719/head:pull/23719 PR: https://git.openjdk.org/jdk/pull/23719 From rhalade at openjdk.org Fri Feb 21 21:02:54 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 21 Feb 2025 21:02:54 GMT Subject: RFR: 8350456: Test javax/crypto/CryptoPermissions/InconsistentEntries.java crashed: EXCEPTION_ACCESS_VIOLATION [v2] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 20:51:11 GMT, Fernando Guallini wrote: >> The test javax/crypto/CryptoPermissions/InconsistentEntries.java uses CDSTestUtils.clone to copy the JDK into the scratch dir by creating symbolic links, but this was seen to crash the VM in Windows Server 2025. To ensure test stability, it should hard copy the required files. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > updated comment with runtimeException Marked as reviewed by rhalade (Reviewer). test/lib/jdk/test/lib/util/FileUtils.java line 377: > 375: * @param dst the path of the destination directory > 376: * @throws IOException > 377: * if an I/O error occurs Suggestion: * @throws RuntimeException if an I/O error occurs during the copy operation * or if the source or destination paths are invalid ------------- PR Review: https://git.openjdk.org/jdk/pull/23726#pullrequestreview-2634146048 PR Review Comment: https://git.openjdk.org/jdk/pull/23726#discussion_r1966126842 From mullan at openjdk.org Fri Feb 21 21:05:54 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 21 Feb 2025 21:05:54 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: <7thOhX-z4a54fLx62GDGGbrH3dRiTORK4GV7yqwthiM=.1daad2d1-86c7-4ba2-90c4-bbe9b279302d@github.com> Message-ID: On Fri, 21 Feb 2025 20:31:35 GMT, Anthony Scarpino wrote: >> Or what about this? >> >> if (key instanceof AsymmetricKey ak) { >> if (ak.getParams() instanceof NamedParameterSpec nps) { >> return nps.getName(); >> } >> } >> return key.getAlgorithm(); >> >> `AsymmetricKey` was introduced to make our lives easier. > > I stayed away from that because this is likely being backported Ok, well our backporters are usually good about extracting only what is necessary, but if not, can you file another issue to add support for disabling PQC algorithms? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966165821 From fguallini at openjdk.org Fri Feb 21 21:09:57 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 21 Feb 2025 21:09:57 GMT Subject: Integrated: 8350456: Test javax/crypto/CryptoPermissions/InconsistentEntries.java crashed: EXCEPTION_ACCESS_VIOLATION In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 10:31:34 GMT, Fernando Guallini wrote: > The test javax/crypto/CryptoPermissions/InconsistentEntries.java uses CDSTestUtils.clone to copy the JDK into the scratch dir by creating symbolic links, but this was seen to crash the VM in Windows Server 2025. To ensure test stability, it should hard copy the required files. This pull request has now been integrated. Changeset: 825ab20b Author: Fernando Guallini URL: https://git.openjdk.org/jdk/commit/825ab20ba99b1f1127dd94b87ae56020d1831529 Stats: 30 lines in 2 files changed: 28 ins; 1 del; 1 mod 8350456: Test javax/crypto/CryptoPermissions/InconsistentEntries.java crashed: EXCEPTION_ACCESS_VIOLATION Reviewed-by: rhalade, jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/23726 From ascarpino at openjdk.org Fri Feb 21 21:14:53 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 21 Feb 2025 21:14:53 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 20:25:59 GMT, Weijun Wang wrote: >> Hi, >> >> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. >> >> thanks >> >> Tony > > src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 78: > >> 76: private static List aliasEd25519 = null; >> 77: private static List aliasXDH = null; >> 78: private static List aliasX25519 = null; > > I am a little suspicious in this approach. At least this means for each "family" algorithm name like "EdDSA", we need to hardcode all its parameter set names here. Sounds not very sustainable. > > An EdDSA key always has its `getAlgorithm` being "EdDSA" (at least inside SunEC) and its `getParams()` being the parameter set name. So it looks like it's enough if we do a name comparison on both. > > Also, why no `aliasEd448` and `aliasX448` here? I have to give more thought on checking the algorithm and the `getParams()` against the list. That may eliminate the need for the hardcoded list.. As to why 448 curves didn't need an alias, there is no other way to specify those curves other than their given name, like mentioned with the KPG/Ed25519 example in my comment to Sean ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966173549 From ascarpino at openjdk.org Fri Feb 21 21:14:54 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 21 Feb 2025 21:14:54 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: <9GvpZdkvoPsLDkJO3tCdy2Jf7iby5LErXi5PvHNGefk=.04dde4f7-39fc-42d6-b120-baf8a4a7e5d1@github.com> References: <9GvpZdkvoPsLDkJO3tCdy2Jf7iby5LErXi5PvHNGefk=.04dde4f7-39fc-42d6-b120-baf8a4a7e5d1@github.com> Message-ID: On Fri, 21 Feb 2025 19:15:21 GMT, Sean Mullan wrote: >> Hi, >> >> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. >> >> thanks >> >> Tony > > src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 95: > >> 93: case "Ed25519" -> { >> 94: if (aliasEd25519 == null) { >> 95: aliasEd25519 = List.of("EdDSA", "Ed25519"); > > Hmm. Should disabling Ed25519 also disable EdDSA? I can see the reverse, but isn't Ed25519 meant to be a specific curve for EdDSA? This is complicated by `KeyPairGenerator.getInstance("EdDSA")` returning an Ed25519 key If someone were to check permits() with "EdDSA" the above code recognizes that "Ed25519" on the disabled algorithm list overlaps with "EdDSA". This is the first test in the test coded included in the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966171536 From ascarpino at openjdk.org Fri Feb 21 21:23:52 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 21 Feb 2025 21:23:52 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 20:35:34 GMT, Weijun Wang wrote: >> Hi, >> >> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. >> >> thanks >> >> Tony > > test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 61: > >> 59: case "Ed25519" -> >> 60: Arrays.asList( >> 61: new TestCase("EdDSA", false), > > As Sean mentioned in another comment, disabling "Ed25519" does not imply all EdDSA keys are not permitted. This means the result of `permits(primitives, algorithmName, parameters)` cannot be determined. That said, I noticed you've used `KeyUtil::getAlgorithm` in a lot of places. Can we guarantee that this `permits` method is never called on a family algorithm name? If so, we can get a definitive result. I believe my comment to Sean answers this question, but I'm not sure I understand the last question in your comment. "never called on a family algorithm name". The change is to make sure these two families return the curve name and not the family name (EdDSA & XDH). But on the other side, someone using the family name of the disabled algorithm list would disable all curves. The above test code is checking that this call ` permits(Set.of(CryptoPrimitive.SIGNATURE), "EdDSA", null)` will fail for a Ed25519 key because of the precedent set by KPG. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966189174 From weijun at openjdk.org Fri Feb 21 22:07:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 21 Feb 2025 22:07:52 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: <9GvpZdkvoPsLDkJO3tCdy2Jf7iby5LErXi5PvHNGefk=.04dde4f7-39fc-42d6-b120-baf8a4a7e5d1@github.com> Message-ID: On Fri, 21 Feb 2025 21:09:32 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 95: >> >>> 93: case "Ed25519" -> { >>> 94: if (aliasEd25519 == null) { >>> 95: aliasEd25519 = List.of("EdDSA", "Ed25519"); >> >> Hmm. Should disabling Ed25519 also disable EdDSA? I can see the reverse, but isn't Ed25519 meant to be a specific curve for EdDSA? > > This is complicated by `KeyPairGenerator.getInstance("EdDSA")` returning an Ed25519 key > > If someone were to check permits() with "EdDSA" the above code recognizes that "Ed25519" on the disabled algorithm list overlaps with "EdDSA". This is the first test in the test coded included in the PR. Do we call `permits` before instantiating a `KeyPairGenerator`? What if people call `kpg.initialize(NPS.Ed448)` after the instantiation? In reality, I think it depends on how many `permits` calls there are. Modern algorithms have the key same algorithm name and signature algorithm name. When a signature operation is carried out, do we check on both the signature algorithm and the key? It seems only checking on the key is enough. It's actually more precise, since you can get the exact parameter set name there. This is why I asked if the method is "never called on a family algorithm name". When checking a key, if we always call `permits` on the parameter set name, we get the precise result. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966259933 From weijun at openjdk.org Fri Feb 21 22:11:54 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 21 Feb 2025 22:11:54 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 21:21:24 GMT, Anthony Scarpino wrote: >> test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 61: >> >>> 59: case "Ed25519" -> >>> 60: Arrays.asList( >>> 61: new TestCase("EdDSA", false), >> >> As Sean mentioned in another comment, disabling "Ed25519" does not imply all EdDSA keys are not permitted. This means the result of `permits(primitives, algorithmName, parameters)` cannot be determined. That said, I noticed you've used `KeyUtil::getAlgorithm` in a lot of places. Can we guarantee that this `permits` method is never called on a family algorithm name? If so, we can get a definitive result. > > I believe my comment to Sean answers this question, but I'm not sure I understand the last question in your comment. "never called on a family algorithm name". The change is to make sure these two families return the curve name and not the family name (EdDSA & XDH). But on the other side, someone using the family name of the disabled algorithm list would disable all curves. > The above test code is checking that this call ` permits(Set.of(CryptoPrimitive.SIGNATURE), "EdDSA", null)` will fail for a Ed25519 key because of the precedent set by KPG. We are talking about the same in multiple comments now. In this case, if both `permits(SIGNATURE, "EdDSA", null)` and `permits(SIGNATURE, key)` are called, it's safe to bypass the 1st check as long as the 2nd one blocks the key. So it's not necessary to cover "EdDSA" when only "Ed25519" is disabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966263224 From ascarpino at openjdk.org Fri Feb 21 22:14:52 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 21 Feb 2025 22:14:52 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 21:11:54 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 78: >> >>> 76: private static List aliasEd25519 = null; >>> 77: private static List aliasXDH = null; >>> 78: private static List aliasX25519 = null; >> >> I am a little suspicious in this approach. At least this means for each "family" algorithm name like "EdDSA", we need to hardcode all its parameter set names here. Sounds not very sustainable. >> >> An EdDSA key always has its `getAlgorithm` being "EdDSA" (at least inside SunEC) and its `getParams()` being the parameter set name. So it looks like it's enough if we do a name comparison on both. >> >> Also, why no `aliasEd448` and `aliasX448` here? > > I have to give more thought on checking the algorithm and the `getParams()` against the list. That may eliminate the need for the hardcoded list.. > > As to why 448 curves didn't need an alias, there is no other way to specify those curves other than their given name, like mentioned with the KPG/Ed25519 example in my comment to Sean So using the `getAlgorithm()` and `getParams().getName()` work because there is a Key, but not for non-key situation such as `permits(Set.of(CryptoPrimitive.SIGNATURE), "EdDSA", null)`. But this does bring up a point I had not considered. The `permits()` call does not specify any key details other than the family name. Perhaps it's ok for `permits()` to return a passing result with the information given. But for a `permit()` that had more detail, it could return a failing result. However, the KPG example does make me think that the consistency in the current PR is better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966265139 From ascarpino at openjdk.org Fri Feb 21 22:31:52 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 21 Feb 2025 22:31:52 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: References: <9GvpZdkvoPsLDkJO3tCdy2Jf7iby5LErXi5PvHNGefk=.04dde4f7-39fc-42d6-b120-baf8a4a7e5d1@github.com> Message-ID: <5FfkuJBcl9mZR5DCFzVdeB95Zr5a06UNKvpoBaagXH0=.4d8ebec7-7360-43d2-988a-c52ecae4aa78@github.com> On Fri, 21 Feb 2025 22:05:03 GMT, Weijun Wang wrote: >> This is complicated by `KeyPairGenerator.getInstance("EdDSA")` returning an Ed25519 key >> >> If someone were to check permits() with "EdDSA" the above code recognizes that "Ed25519" on the disabled algorithm list overlaps with "EdDSA". This is the first test in the test coded included in the PR. > > Do we call `permits` before instantiating a `KeyPairGenerator`? What if people call `kpg.initialize(NPS.Ed448)` after the instantiation? > > In reality, I think it depends on how many `permits` calls there are. Modern algorithms have the key same algorithm name and signature algorithm name. When a signature operation is carried out, do we check on both the signature algorithm and the key? It seems only checking on the key is enough. It's actually more precise, since you can get the exact parameter set name there. This is why I asked if the method is "never called on a family algorithm name". When checking a key, if we always call `permits` on the parameter set name, we get the precise result. `permits()` are used in situations for jdk[tls|certpath|jar].disabledAlgorithms, and the SSLAlgorithmConstraints. It's not called for APIs like KPG, Signature, etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966279183 From weijun at openjdk.org Fri Feb 21 22:36:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 21 Feb 2025 22:36:52 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage In-Reply-To: <5FfkuJBcl9mZR5DCFzVdeB95Zr5a06UNKvpoBaagXH0=.4d8ebec7-7360-43d2-988a-c52ecae4aa78@github.com> References: <9GvpZdkvoPsLDkJO3tCdy2Jf7iby5LErXi5PvHNGefk=.04dde4f7-39fc-42d6-b120-baf8a4a7e5d1@github.com> <5FfkuJBcl9mZR5DCFzVdeB95Zr5a06UNKvpoBaagXH0=.4d8ebec7-7360-43d2-988a-c52ecae4aa78@github.com> Message-ID: <125_A_wq5xbaee9WJXaubM-JAPfKWpnRxJVDGFKERis=.5c885dc7-dd33-4b60-8eb6-d78b0794aad2@github.com> On Fri, 21 Feb 2025 22:29:01 GMT, Anthony Scarpino wrote: >> Do we call `permits` before instantiating a `KeyPairGenerator`? What if people call `kpg.initialize(NPS.Ed448)` after the instantiation? >> >> In reality, I think it depends on how many `permits` calls there are. Modern algorithms have the key same algorithm name and signature algorithm name. When a signature operation is carried out, do we check on both the signature algorithm and the key? It seems only checking on the key is enough. It's actually more precise, since you can get the exact parameter set name there. This is why I asked if the method is "never called on a family algorithm name". When checking a key, if we always call `permits` on the parameter set name, we get the precise result. > > `permits()` are used in situations for jdk[tls|certpath|jar].disabledAlgorithms, and the SSLAlgorithmConstraints. It's not called for APIs like KPG, Signature, etc. That's what I meant. Suppose in TLS when you verify a signature and you call `permits` on both the signature algorithm name and the key used to init the signature, it's OK if only one fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966282538 From jrose at openjdk.org Fri Feb 21 22:54:51 2025 From: jrose at openjdk.org (John R Rose) Date: Fri, 21 Feb 2025 22:54:51 GMT Subject: RFR: 8347606: Optimize Java implementation of ML-DSA In-Reply-To: <00EzhUrlzMd_TKb6YcnzMmlnwS5MEwgsysLU9ZcAiz4=.df755691-d83f-4002-b195-e0b9b34f70f1@github.com> References: <00EzhUrlzMd_TKb6YcnzMmlnwS5MEwgsysLU9ZcAiz4=.df755691-d83f-4002-b195-e0b9b34f70f1@github.com> Message-ID: <_-COyxiAAhln2AsPT-mWstClY5XvSimXVEXX4NwlBWs=.d0ee95e3-334c-4e39-9267-2263a453ad8e@github.com> On Sun, 16 Feb 2025 15:41:52 GMT, Chen Liang wrote: >> src/java.base/share/classes/sun/security/provider/ML_DSA.java line 1237: >> >>> 1235: return res; >>> 1236: } >>> 1237: >> >> Centralizing the allocation into a helper on its own Looks unseful (for resource Management, debugging/profiling and to pick the optimal implementation). >> >> but it?s a shame that 2 dimensional allocations are sub-optimal, shouldnt that be addressed in the jvm (or c2?) > > Indeed, it's better if hotspot can recognize and optimize the bytecode sequence generated by javac, or javac should generate bytecode like these methods to speed up allocation in general. > > Is splitting the allocation into a dedicated method a factor? I know this may affect JIT compilation heuristics. It is almost always a mistake to try to generate optimized code in javac behind the user's back. The VM does a better job when javac stays out of the optimization business and just provides a concise bytecode representation of the desired computation. The VM always has more information than javac, and so all optimization descisions are best deferred until VM runtime, when all classes are loaded. In addition, increasing classfile sizes to improve peak performance is likely to harm startup performance, and (of course) static application footprint. Also, even if javac gets an optimization perfectly correct for current platforms (and the footprint costs are negigible), in a few years platforms will change and the VM will want to optimize the bytecodes a different way. But the "optimization" in the classfile, will be obsolete, and the now-suboptimal code will stick around forever in release JARs; the VM's problem will then be to reverse-engineer the "optimized not-optimized" code and reorganize it, which is an unfair ask of the VM. In summary, there's nothing javac can do for optimization that is not better done by the VM, later on. Classfiles are semantic specifications, not performance engines. https://bugs.openjdk.org/browse/JDK-8308105#comment-14755577 In that line of thinking, I recommend replacing the multianewarray instruction, in javac's current translation strategy, with an invokedynamic, which can spin code that is as optimal as we need, now and in the foreseeable future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23642#discussion_r1966296640 From wetmore at openjdk.org Sat Feb 22 02:30:42 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 22 Feb 2025 02:30:42 GMT Subject: RFR: 8350476: Fix typo introduced in JDK-8350147 Message-ID: Typo: s/ficticious/fictitious/ No unit test. Check that javadoc still builds. ------------- Commit messages: - 8350476: Fix typo introduced in JDK-8350147 Changes: https://git.openjdk.org/jdk/pull/23733/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23733&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350476 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23733/head:pull/23733 PR: https://git.openjdk.org/jdk/pull/23733 From jnimeh at openjdk.org Sat Feb 22 03:46:55 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Sat, 22 Feb 2025 03:46:55 GMT Subject: RFR: 8350476: Fix typo introduced in JDK-8350147 In-Reply-To: References: Message-ID: On Sat, 22 Feb 2025 02:25:42 GMT, Bradford Wetmore wrote: > Typo: s/ficticious/fictitious/ > > No unit test. Check that javadoc still builds. Marked as reviewed by jnimeh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23733#pullrequestreview-2634674252 From jpai at openjdk.org Sat Feb 22 06:42:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 22 Feb 2025 06:42:51 GMT Subject: RFR: 8350476: Fix typo introduced in JDK-8350147 In-Reply-To: References: Message-ID: On Sat, 22 Feb 2025 02:25:42 GMT, Bradford Wetmore wrote: > Typo: s/ficticious/fictitious/ > > No unit test. Check that javadoc still builds. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23733#pullrequestreview-2634730559 From haosun at openjdk.org Mon Feb 24 07:44:55 2025 From: haosun at openjdk.org (Hao Sun) Date: Mon, 24 Feb 2025 07:44:55 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 10:23:37 GMT, Ferenc Rakoczi wrote: > Was this a build attempted on an aarch64 for the other architectures? Yes. It's a cross-build on AArch64 for other architectures. > Instruction_aarch64 should not have been there in a ppc build Oops. I didn't check the error message carefully. It might be some issue in our CI. I will check that. Sorry for the noise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2677637524 From adinn at openjdk.org Mon Feb 24 08:39:54 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 08:39:54 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 07:41:58 GMT, Hao Sun wrote: >> @shqking, I changed the copyright years, but I don't really understand how the aarch64-specific code can overflow buffers on other architectures. As far as I understand, Instruction_aarch64 should not have been there in a ppc build. >> Was this a build attempted on an aarch64 for the other architectures? > >> Was this a build attempted on an aarch64 for the other architectures? > > Yes. It's a cross-build on AArch64 for other architectures. > >> Instruction_aarch64 should not have been there in a ppc build > > Oops. I didn't check the error message carefully. It might be some issue in our CI. I will check that. > > Sorry for the noise. @shqking There is a [known issue](https://bugs.openjdk.org/browse/JDK-8349921) with cross-builds that is still being investigated. I think that may explain the problem you are seeing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2677735964 From bkilambi at openjdk.org Mon Feb 24 09:37:54 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 24 Feb 2025 09:37:54 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> Message-ID: On Thu, 20 Feb 2025 17:22:25 GMT, Ferenc Rakoczi wrote: >> src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2618: >> >>> 2616: INSN(smaxp, 0, 0b101001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S >>> 2617: INSN(sminp, 0, 0b101011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S >>> 2618: INSN(sqdmulh,0, 0b101101, false); // accepted arrangements: T4H, T8H, T2S, T4S >> >> Hi, not a comment on the algorithm itself but you might have to add these new instructions in the gtest for aarch64 here - test/hotspot/gtest/aarch64/aarch64-asmtest.py and use this file to generate test/hotspot/gtest/aarch64/asmtest.out.h which would contain these newly added instructions. > > I have tried that, but the python script (actually the as command that it started) threw error messages: > > aarch64ops.s:338:24: error: index must be a multiple of 8 in range [0, 32760]. > prfm PLDL1KEEP, [x15, 43] > ^ > aarch64ops.s:357:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > sub x1, x10, x23, sxth #2 > ^ > aarch64ops.s:359:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > add x11, x21, x5, uxtb #3 > ^ > aarch64ops.s:360:22: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > adds x11, x17, x17, uxtw #1 > ^ > aarch64ops.s:361:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > sub x11, x0, x15, uxtb #1 > ^ > aarch64ops.s:362:19: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > subs x7, x1, x0, sxth #2 > ^ > This is without any modifications from what is in the master branch currently. You might have to use an assembler from the latest binutils build (if the system default isn't the latest) and add the path to the assembler in the "AS" variable. Also you can run it something like - `python aarch64-asmtest.py | expand > asmtest.out.h`. Please let me know if you still face problems. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967284270 From adinn at openjdk.org Mon Feb 24 11:50:55 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 11:50:55 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v6] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 17:33:18 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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 four additional commits since the last revision: > > - Accepting suggested change from Andrew Dinn > - Added comments suggested by Andrew Dinn > - Fixed copyright years > - renaming a couple of functions src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4593: > 4591: // chunks of) vector registers v30 and v31, resp. > 4592: // The inputs are in v0-v7 and v16-v23 and the results go to v16-v23, > 4593: // four 32-bit values in each register Suggestion: Once again it would be good to annotate the lines in this code with comments that relate the generated code back to the original Java code. In the header comment you should refer to the relevant Java class and the var names there: // computes (in parallel across 8 x 4S vectors) // a = b * c * 2^-32 mod MONT_Q // where // inputs b and c are in v0, ..., v7 and v16, ... v23, // scratch registers v24, ... v27 are clobbered // output a is written back into v16, ... v23 // constants q and q_inv are in v30, v31 // // See the equivalent Java code in method ML_DSA.montMul Then comment the generation lines as shown below ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967490923 From adinn at openjdk.org Mon Feb 24 11:53:55 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 11:53:55 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v6] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 17:33:18 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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 four additional commits since the last revision: > > - Accepting suggested change from Andrew Dinn > - Added comments suggested by Andrew Dinn > - Fixed copyright years > - renaming a couple of functions src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4604: > 4602: FloatRegister vr7 = by_constant ? v29 : v7; > 4603: > 4604: __ sqdmulh(v24, __ T4S, vr0, v16); + __ sqdmulh(v24, __ T4S, v0, v16); // aHigh = hi32(2 * b * c) + __ mulv(v16, __ T4S, v0, v16); // aLow = lo32(b * c) src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4613: > 4611: __ mulv(v19, __ T4S, vr3, v19); > 4612: > 4613: __ mulv(v16, __ T4S, v16, v30); __ mulv(v16, __ T4S, v16, v30); // m = aLow * qinv src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4618: > 4616: __ mulv(v19, __ T4S, v19, v30); > 4617: > 4618: __ sqdmulh(v16, __ T4S, v16, v31); __ sqdmulh(v16, __ T4S, v16, v31); // n = hi32(2 * m * q) src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4623: > 4621: __ sqdmulh(v19, __ T4S, v19, v31); > 4622: > 4623: __ shsubv(v16, __ T4S, v24, v16); __ shsubv(v16, __ T4S, v24, v16); // a = (aHigh - n) / 2 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967491928 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967492635 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967493031 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967493643 From adinn at openjdk.org Mon Feb 24 14:58:57 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 14:58:57 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v6] In-Reply-To: References: Message-ID: <_ApJlty8yCwyY8FiRhczpoKGf1G83hvMuXvOWeKHb90=.5758138f-b03b-49be-ab7a-3b4b56cbe7a6@github.com> On Thu, 20 Feb 2025 17:33:18 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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 four additional commits since the last revision: > > - Accepting suggested change from Andrew Dinn > - Added comments suggested by Andrew Dinn > - Fixed copyright years > - renaming a couple of functions src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4654: > 4652: > 4653: void dilithium_add_sub32() { > 4654: __ addv(v24, __ T4S, v0, v16); __ addv(v24, __ T4S, v0, v16); // a0 = b + c src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4663: > 4661: __ addv(v31, __ T4S, v7, v23); > 4662: > 4663: __ subv(v0, __ T4S, v0, v16); __ subv(v0, __ T4S, v0, v16); // a1 = b - c src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4674: > 4672: > 4673: void dilithium_montmul_sub_add16() { > 4674: __ sqdmulh(v24, __ T4S, v1, v16); __ mulv(v16, __ T4S, v16, v30); // m = aLow * qinv ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967809436 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967809840 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967811299 From duke at openjdk.org Mon Feb 24 15:28:54 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Mon, 24 Feb 2025 15:28:54 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v2] In-Reply-To: References: <6prT9j5xfHlmuZ_T2BJGjtDr3FkovRwTsXLuTdesYrg=.f9930b91-5a5c-4829-9cf2-2dd9f94e32a8@github.com> Message-ID: On Fri, 21 Feb 2025 18:31:04 GMT, Weijun Wang wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> keyStore is not used to delete, cleanup of the calls, minor refactoring > > test/jdk/sun/security/validator/CertReplace.java line 28: > >> 26: */ >> 27: >> 28: import java.io.FileInputStream; > > Remove the "This test is called by certreplace.sh" line above. Changed in the next commit > test/jdk/sun/security/validator/CertReplace.java line 82: > >> 80: final String intAliase = "int"; >> 81: final String userAlias = "user"; >> 82: final String caAlias = "ca"; > > Do you really believe creating these variables help the program looking better? There are so many string concatenations in the keytool commands. If it were me, I would remove every variable for a string literal except for `ktBaseParameters`. > > On the other hand, it's OK to put `"changeit".toCharArray()` into a variable. Changed in the next commit > test/jdk/sun/security/validator/CertReplace.java line 120: > >> 118: new FileInputStream(intCertFileName) >> 119: ) >> 120: }; > > Use `CertUtils.getCertFromStream`. Also, it's better to close the file. Maybe Windows dislikes open files. Done in the next commit > test/jdk/sun/security/validator/CertReplace.java line 147: > >> 145: "-selfcert -alias " + caAlias); >> 146: keyStore.deleteEntry(intAliase); >> 147: keyStore.deleteEntry(userAlias); > > Call `keyStore.store` to actually remove the 2 entries inside the keystore file. But this needs to be done before the `-selfcert` call, otherwise, the old cert would overwrite the new one. Done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1967869438 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1967870760 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1967872033 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1967871506 From duke at openjdk.org Mon Feb 24 15:32:07 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Mon, 24 Feb 2025 15:32:07 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v3] In-Reply-To: References: Message-ID: <96AUt7SPxTmoyH-GHeFsrW_Th6HIyrRCRforBx2AEQY=.9d835a08-7195-4e79-acf4-a071a54bbf58@github.com> > Changed shell files to be java tests: > * ./validator/certreplace.sh > * ./validator/samedn.sh Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: keyStore store and cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23727/files - new: https://git.openjdk.org/jdk/pull/23727/files/f333ddff..9ee62904 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=01-02 Stats: 59 lines in 1 file changed: 11 ins; 20 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/23727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23727/head:pull/23727 PR: https://git.openjdk.org/jdk/pull/23727 From adinn at openjdk.org Mon Feb 24 15:33:08 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 15:33:08 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v6] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 17:33:18 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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 four additional commits since the last revision: > > - Accepting suggested change from Andrew Dinn > - Added comments suggested by Andrew Dinn > - Fixed copyright years > - renaming a couple of functions src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4683: > 4681: __ mulv(v19, __ T4S, v7, v19); > 4682: > 4683: __ mulv(v16, __ T4S, v16, v30); __ mulv(v16, __ T4S, v16, v30); // m = aLow * qinv src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4688: > 4686: __ mulv(v19, __ T4S, v19, v30); > 4687: > 4688: __ sqdmulh(v16, __ T4S, v16, v31); __ sqdmulh(v16, __ T4S, v16, v31); // n = hi32(2 * m * q) src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4693: > 4691: __ sqdmulh(v19, __ T4S, v19, v31); > 4692: > 4693: __ shsubv(v16, __ T4S, v24, v16); __ shsubv(v16, __ T4S, v24, v16); // a = (aHigh - n) / 2 src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4698: > 4696: __ shsubv(v19, __ T4S, v27, v19); > 4697: > 4698: __ subv(v1, __ T4S, v0, v16); __ subv(v1, __ T4S, v0, v16); // x1 = x - a src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4703: > 4701: __ subv(v7, __ T4S, v6, v19); > 4702: > 4703: __ addv(v0, __ T4S, v0, v16); __ addv(v0, __ T4S, v0, v16); // x0 = x + a src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4742: > 4740: > 4741: for (int i = 0; i < 4; i++) { > 4742: __ ldpq(v30, v31, Address(dilithiumConsts, 0)); __ ldpq(v30, v31, Address(dilithiumConsts, 0)); // qinv, q src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4813: > 4811: // level 5 > 4812: for (int i = 0; i < 1024; i += 256) { > 4813: __ ldpq(v30, v31, Address(dilithiumConsts, 0)); __ ldpq(v30, v31, Address(dilithiumConsts, 0)); // qinv, q src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4853: > 4851: // level 6 > 4852: for (int i = 0; i < 1024; i += 128) { > 4853: __ ldpq(v30, v31, Address(dilithiumConsts, 0)); __ ldpq(v30, v31, Address(dilithiumConsts, 0)); // qinv, q src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4876: > 4874: // level 7 > 4875: for (int i = 0; i < 1024; i += 128) { > 4876: __ ldpq(v30, v31, Address(dilithiumConsts, 0)); __ ldpq(v30, v31, Address(dilithiumConsts, 0)); // qinv, q src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4905: > 4903: > 4904: void dilithium_sub_add_montmul16() { > 4905: __ subv(v20, __ T4S, v0, v1); __ subv(v20, __ T4S, v0, v1); // b = x0 - x1 src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4910: > 4908: __ subv(v23, __ T4S, v6, v7); > 4909: > 4910: __ addv(v0, __ T4S, v0, v1); __ addv(v0, __ T4S, v0, v1); // a0 = x0 + x1 src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4915: > 4913: __ addv(v6, __ T4S, v6, v7); > 4914: > 4915: __ sqdmulh(v24, __ T4S, v20, v16); __ sqdmulh(v24, __ T4S, v20, v16); // aHigh = hi32(2 * b * c) __ mulv(v1, __ T4S, v20, v16); // aLow = lo32(b * c) src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4924: > 4922: __ mulv(v7, __ T4S, v23, v19); > 4923: > 4924: __ mulv(v1, __ T4S, v1, v30); __ mulv(v1, __ T4S, v1, v30); // m = (aLow * q) src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4929: > 4927: __ mulv(v7, __ T4S, v7, v30); > 4928: > 4929: __ sqdmulh(v1, __ T4S, v1, v31); __ sqdmulh(v1, __ T4S, v1, v31); // n = hi32(2 * m * q) src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4934: > 4932: __ sqdmulh(v7, __ T4S, v7, v31); > 4933: > 4934: __ shsubv(v1, __ T4S, v24, v1); __ shsubv(v1, __ T4S, v24, v1); // a1 = (aHigh - n) / 2 src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5044: > 5042: // level0 > 5043: for (int i = 0; i < 1024; i += 128) { > 5044: __ ldpq(v30, v31, Address(dilithiumConsts, 0)); __ ldpq(v30, v31, Address(dilithiumConsts, 0)); //qinv, q src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5115: > 5113: __ str(v31, __ Q, Address(coeffs, i + 224)); > 5114: dilithium_load32zetas(zetas); > 5115: __ ldpq(v30, v31, Address(dilithiumConsts, 0)); __ ldpq(v30, v31, Address(dilithiumConsts, 0)); //qinv, q src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5166: > 5164: __ lea(dilithiumConsts, ExternalAddress((address) StubRoutines::aarch64::_dilithiumConsts)); > 5165: > 5166: __ ldpq(v30, v31, Address(dilithiumConsts, 0)); __ ldpq(v30, v31, Address(dilithiumConsts, 0)); // qinv, q __ ldr(v29, __ Q, Address(dilithiumConsts, 48)); // rsquare src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5228: > 5226: __ lea(dilithiumConsts, ExternalAddress((address) StubRoutines::aarch64::_dilithiumConsts)); > 5227: > 5228: __ ldpq(v30, v31, Address(dilithiumConsts, 0)); __ ldpq(v30, v31, Address(dilithiumConsts, 0)); // qinv, q ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967863821 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967864748 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967865658 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967866379 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967866822 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967867752 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967869143 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967870036 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967870373 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967871386 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967871949 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967872681 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967873281 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967873918 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967874418 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967875655 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967876745 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967877717 PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1967878884 From adinn at openjdk.org Mon Feb 24 16:21:58 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 16:21:58 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v6] In-Reply-To: References: Message-ID: <6B25PDNMw8dDUm8r5rX4heL3cfvbsPVKqnVg7e1Ax84=.43b91704-15fa-4445-b8be-216fffcf12d4@github.com> On Thu, 20 Feb 2025 17:33:18 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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 four additional commits since the last revision: > > - Accepting suggested change from Andrew Dinn > - Added comments suggested by Andrew Dinn > - Fixed copyright years > - renaming a couple of functions Please add comments as indicated to relate generated code to original Java source. Otherwise good to go. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23300#pullrequestreview-2637711807 From adinn at openjdk.org Mon Feb 24 16:21:59 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 16:21:59 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: Message-ID: <36J5kPTCknNCBjMx56e9JmLK2vFbvxBXXXOvTmv5pDs=.6aaa25e2-4cd9-4217-8da3-3280c1d3c4db@github.com> On Fri, 21 Feb 2025 10:23:37 GMT, Ferenc Rakoczi wrote: >> Hi. Here is the test result of our CI. >> >> ### copyright year >> >> the following files should update the copyright year to 2025. >> >> >> src/hotspot/cpu/aarch64/assembler_aarch64.hpp >> src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp >> src/hotspot/share/runtime/globals.hpp >> src/java.base/share/classes/sun/security/provider/ML_DSA.java >> src/java.base/share/classes/sun/security/provider/SHA3Parallel.java >> test/micro/org/openjdk/bench/java/security/MLDSA.java >> >> >> ### cross-build failure >> >> Cross build for riscv64/s390/ppc64 failed. >> >> Here shows the error msg for ppc64 >> >> >> === Output from failing command(s) repeated here === >> * For target support_interim-jmods_support__create_java.base.jmod_exec: >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/tmp/jdk-src/src/hotspot/share/asm/codeBuffer.hpp:200), pid=72752, tid=72769 >> # assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000e85cb03dc620 <= 0x0000e85cb03e8ab4 <= 0x0000e85cb03e8ab0 >> # >> # JRE version: OpenJDK Runtime Environment (25.0) (fastdebug build 25-internal-git-1e01c6deec3) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-git-1e01c6deec3, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) >> # Problematic frame: >> # V [libjvm.so+0x3b391c] Instruction_aarch64::~Instruction_aarch64()+0xbc >> # >> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /tmp/ci-scripts/jdk-src/make/ >> # >> # An error report file with more information is saved as: >> # /tmp/jdk-src/make/hs_err_pid72752.log >> ... (rest of output omitted) >> >> * All command lines available in /sysroot/ppc64el/tmp/build-ppc64el/make-support/failure-logs. >> === End of repeated output === >> >> >> I suppose we should make the similar update at file `src/hotspot/cpu/aarch64/stubDeclarations_aarch64.hpp` to other platforms > > @shqking, I changed the copyright years, but I don't really understand how the aarch64-specific code can overflow buffers on other architectures. As far as I understand, Instruction_aarch64 should not have been there in a ppc build. > Was this a build attempted on an aarch64 for the other architectures? @ferakocz I have indicated a few places where I think you should add comments to clarify the relationship to the original Java code or just clarify what data is being used. I think the code is ok to go in as it is but I would really like to investigate a better structuring of the generator code. This can be done as a follow-up rather than delay getting this version committed. There are two things I still see as problematic with the current code. 1) There are lots of places in your auxiliary generator methods and also in their client methods where you generate distinct sequences of calls to the assembler sharing essentially the same code shape i.e. the same instructions but with different vector register arguments. For example, in `dilithium_montmul32` you generate the multiply sequence to montgomery multiply 4x4s registers in v0..v3 by 4x4s registers in v16..v19 and then repeat exactly the same code in exactly the same sequence to multiply the 4x4s registers in v4..v7 by 4x4s registers in v20..v23. Likewise, `dilithium_sub_add_montmul16` generates that same shape code but uses the montmul sequence with odd registers v1..v7 paired against the compact sequence v16..19. As another example, you generate various 4 or 8 long sequences of subv and addv operations at various points, including in some of the top level methods. I appreciate that you have folded one of the montmult cases into the other by adding the `bool by_constant` parameter to `dilithium_montmul32`. However, I think it would be worth investigating an alternative that would allow more use more, systematic use of auxiliary methods. 2) Your current auxiliary generator methods rely on a fixed mapping of input, output and scratch registers to specific registers. This is part of why the reason why you cannot always call your auxiliaries (or smaller pieces of them) from other locations where the same code shape is generated -- the input and output mappings of data to registers expected by the auxiliary do not match the register sequences in which the relevant data are (transiently) located. This same fact also means that the repeated code sections heavily depend on naming exactly the right register on each generator line. That makes it harder for a maintainer to recognize how, essentially, what is really just one common, abstract operation is, at each different occurrence, consuming, combining and updating several input sequences of related registers to generate one or more output sequences. That also means that it would be very easy to introduce an error if the code ever needed to be changed. I would like to investigate an alternative approach where your auxiliary generator methods and their callers pass arguments that identify the vector register sequences to be consumed as inputs, used as temporaries and written as outputs. In cases where the routines operate on sequences of 4 or 8 successive vectors then, at the very least, that would involve specifying the first register for each input, temporary or output e.g. for the montmult32 multiply v0+ by v16+ using v24+ as temporaries and v30+ as constants and output the results to v16+. However, that leaves it implicit that the first two inputs involve 8 registers while the temporaries involves 4 and the constants 2. The more general requirement is not just to specify the vector sequence length (2, 4 or 8) but also allow the default stride of one (e.g. v0, v1, ...) to be varied to allow for skip sequences (e.g. v0, v2, ...) or constant sequences (v28, v28, ... as would be needed for multiply constant). I have prototyped a simple vector sequence type `VRSeq` that models an indexable sequence of FloatRegisters and allows many of your higher level routines to simply declare register sets they operate on and then pass them as arguments to a range of simply auxiliary generator functions that can be used in many places where you currently have a lot of inline calls to the assembler -- see attachment: [vseq.zip](https://github.com/user-attachments/files/18946470/vseq.zip) I'll raise a JIRA to cover recoding the current implementation using this type and post a follow-up PR that uses it to see how far it helps simplify the code. I believe it will make it easier for maintainers to understand the structure of the generated code and observe/verify the use of registers to store specific values. It should also allow assertions about the use of registers to be added to the code to ensure that values are not being overwritten (expect in circumstances where that is legitimate). Meanwhile I'll approve this PR modulo the commenting I suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2678977770 From adinn at openjdk.org Mon Feb 24 16:33:54 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 16:33:54 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v6] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 17:33:18 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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 four additional commits since the last revision: > > - Accepting suggested change from Andrew Dinn > - Added comments suggested by Andrew Dinn > - Fixed copyright years > - renaming a couple of functions I raised [JDK-8350589](https://bugs.openjdk.org/browse/JDK-8350589) to cover investigation of an alternative implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2679012108 From duke at openjdk.org Mon Feb 24 16:47:32 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Mon, 24 Feb 2025 16:47:32 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v4] In-Reply-To: References: Message-ID: > Changed shell files to be java tests: > * ./validator/certreplace.sh > * ./validator/samedn.sh Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: othervm rm ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23727/files - new: https://git.openjdk.org/jdk/pull/23727/files/9ee62904..297b4946 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23727/head:pull/23727 PR: https://git.openjdk.org/jdk/pull/23727 From djelinski at openjdk.org Mon Feb 24 16:53:57 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 24 Feb 2025 16:53:57 GMT Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec In-Reply-To: References: <0Cnl_2GC5sPNo5SUTyI0ziEC7tQ44LvYwSXkOthntnI=.692670c4-12ad-4d83-87ba-b443221b35c0@github.com> Message-ID: <_jv-TAFGqtsNnCQovDjKJVc1g-kfJ-MJY4Aw1cmEpVE=.9b4cb54f-8abc-44db-9ed1-d872205b3fab@github.com> On Wed, 19 Feb 2025 22:11:07 GMT, Valerie Peng wrote: >> TLS 1.3 uses HKDF, and doesn't work with SunPKCS11 yet, see [JDK-8278640](https://bugs.openjdk.org/browse/JDK-8278640) > > I'd like to clarify the usage of `SunTlsKeyMaterial` and `SunTls12KeyMaterial` KGs first. > > Is `SunTlsKeyMaterial` KG expected to handle specs indicating TLS1.2 version? > Is `SunTls12KeyMaterial` KeyGenerator expected to handle specs indicating SSL3.0 version? > > Looking at SunJCE provider's impls, `SunTlsKeyMaterial` and `SunTls12KeyMaterial` KGs are considered equivalent, e.g. one being the alias of the other. SunPKCS11 provider defines them separately mapping to different native mechs, however sharing the same impl class. Looking at the current code, it seems that `SunTls12KeyMaterial` will always set `supportSSLv3` to false which should reject specs indicating SSL3.0 version. > > There seems to be an inconsistency between SunJCE provider and SunPKCS11 provider? > > In addition, we should check that the particular mechanism is supported? `SunTls12KeyMaterial` is only expected to handle TLS 1.2, and `SunTlsKeyMaterial` is only expected to handle earlier versions (SSL 3.0, TLS 1.0, and TLS 1.1), at least that's how they are used by SunJSSE. The implementation does not verify that the KG name matches the TLS version provided in the algorithm parameters, which in one case can lead to a crash. We could add code to perform that verification instead, but that would involve more code than the fix I proposed. `KeyGenerator.getInstance` verifies that at the necessary mechanisms are present. If incorrect TLS version is used, we may get a ProviderException if the mechanism corresponding to the selected TLS version is unavailable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1968038713 From ascarpino at openjdk.org Mon Feb 24 16:55:55 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 24 Feb 2025 16:55:55 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: Message-ID: On Wed, 19 Feb 2025 13:26:49 GMT, Artur Barashev wrote: >> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates: >> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in java.security documentation src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 223: > 221: // Handshake signature scope > 222: public static final Set HANDSHAKE_SCOPE = > 223: Collections.unmodifiableSet(EnumSet.of(SSLCryptoScope.HANDSHAKE)); I think you get the same with `Set.of(SSLCryptoScope.HANDSHAKE)` src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 220: > 218: > 219: // Checks if algorithm is disabled for the given TLS scopes. > 220: public boolean permits(String algorithm, Set scopes) { Is there a reason you decided to have the caller make it into a `Set` instead of passing SSLCryptoScope down? src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 978: > 976: } > 977: > 978: private boolean cachedCheckAlgorithm( The only reason you need `scopes` here is because of `checkAlgorithmTlsScopes`, which I believe can go away. If so, then you can just pass a modified algorithm+scopes value from `permit(algorithm, Set)` as all the other calls to this caching method have scopes as `null`. I still have to think if `scopes` as part of the `cacheKey` can be avoided. src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 1042: > 1040: } > 1041: > 1042: private boolean checkAlgorithmTlsScopes( If you're able to use `algorithmConstraints` with `UsageConstraint`, you won't need this scopes-specific method src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 1064: > 1062: } > 1063: > 1064: private Map> getDisabledAlgorithmScopes() { I don't think this new Map is necessary. `algorithmConstraints` would already contain this as a `UsageConstraint` with the algorithm as the key. I think if there was a UsageConstraint.permits(Set) you could have a few benefits. First, pushing the conversion from SSLCryptoScope enums to String would be more efficient as no constraint, it would cause no conversion. Secondly, you could disregard a UsageConstraint that had a non-null `nextConstraint`, that would help your previous concerns about & It also unifies all `usage` under one class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1966676283 PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1966652176 PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1966668087 PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1966667670 PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1966650043 From weijun at openjdk.org Mon Feb 24 16:58:55 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 24 Feb 2025 16:58:55 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v6] In-Reply-To: <4LqRv5AsD4Hyoac0oOroUI3c-Qkf6ul1B7s1iyHejlg=.3fa97db2-0687-4b64-8492-6a0d434ea576@github.com> References: <4LqRv5AsD4Hyoac0oOroUI3c-Qkf6ul1B7s1iyHejlg=.3fa97db2-0687-4b64-8492-6a0d434ea576@github.com> Message-ID: On Fri, 21 Feb 2025 19:59:14 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/bf8bb8bf-a63b-4b14-9790-783fa8c9c080) >> >> >> 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 Can you update your screenshot? If it's too big, zoom out and grab the whole view. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2679086174 From adinn at openjdk.org Mon Feb 24 17:15:59 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 17:15:59 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v6] In-Reply-To: References: Message-ID: On Thu, 20 Feb 2025 17:33:18 GMT, Ferenc Rakoczi wrote: >> By using the aarch64 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 four additional commits since the last revision: > > - Accepting suggested change from Andrew Dinn > - Added comments suggested by Andrew Dinn > - Fixed copyright years > - renaming a couple of functions Marked as reviewed by adinn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23300#pullrequestreview-2637878768 From weijun at openjdk.org Mon Feb 24 17:16:01 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 24 Feb 2025 17:16:01 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v6] In-Reply-To: <4LqRv5AsD4Hyoac0oOroUI3c-Qkf6ul1B7s1iyHejlg=.3fa97db2-0687-4b64-8492-6a0d434ea576@github.com> References: <4LqRv5AsD4Hyoac0oOroUI3c-Qkf6ul1B7s1iyHejlg=.3fa97db2-0687-4b64-8492-6a0d434ea576@github.com> Message-ID: On Fri, 21 Feb 2025 19:59:14 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/bf8bb8bf-a63b-4b14-9790-783fa8c9c080) >> >> >> 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 83: > 81: > 82: certpath > 83: Turns on debugging for the PKIX CertPathValidator and CertPathBuilder implementations. Use the ocsp option with the certpath option for OCSP protocol tracing. A hexadecimal dump of the OCSP request and response bytes is displayed. `ocsp` and `verbose` are sub-options. Same for `engine=` in `provider` and `ava` in `x509`. src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 93: > 91: > 92: configfile > 93: JAAS (Java Authentication and Authorization Service) configuration file loading These (and many below) do not need to be ``. src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 113: > 111: > 112: keystore > 113: Keystore debugging Consider change to `KeyStore` to be consistent with rows below. I prefer them in ``. src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 197: > 195:

> 196: > 197: Add an empty line at the end. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968077023 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968059477 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968078455 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968079282 From adinn at openjdk.org Mon Feb 24 17:16:00 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 24 Feb 2025 17:16:00 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> Message-ID: On Thu, 20 Feb 2025 17:22:25 GMT, Ferenc Rakoczi wrote: >> src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2618: >> >>> 2616: INSN(smaxp, 0, 0b101001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S >>> 2617: INSN(sminp, 0, 0b101011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S >>> 2618: INSN(sqdmulh,0, 0b101101, false); // accepted arrangements: T4H, T8H, T2S, T4S >> >> Hi, not a comment on the algorithm itself but you might have to add these new instructions in the gtest for aarch64 here - test/hotspot/gtest/aarch64/aarch64-asmtest.py and use this file to generate test/hotspot/gtest/aarch64/asmtest.out.h which would contain these newly added instructions. > > I have tried that, but the python script (actually the as command that it started) threw error messages: > > aarch64ops.s:338:24: error: index must be a multiple of 8 in range [0, 32760]. > prfm PLDL1KEEP, [x15, 43] > ^ > aarch64ops.s:357:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > sub x1, x10, x23, sxth #2 > ^ > aarch64ops.s:359:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > add x11, x21, x5, uxtb #3 > ^ > aarch64ops.s:360:22: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > adds x11, x17, x17, uxtw #1 > ^ > aarch64ops.s:361:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > sub x11, x0, x15, uxtb #1 > ^ > aarch64ops.s:362:19: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > subs x7, x1, x0, sxth #2 > ^ > This is without any modifications from what is in the master branch currently. @ferakocz This also really needs addressing before committing the patch. Perhaps @theRealAph can advise on how to circumvent the problems you found when trying to update the python script? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1968076559 From abarashev at openjdk.org Mon Feb 24 17:18:47 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 24 Feb 2025 17:18:47 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v4] In-Reply-To: References: Message-ID: > Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Use HandshakeContext's localSupportedCertSignAlgs when checking against SSLSession's localSupportedSignAlgs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23681/files - new: https://git.openjdk.org/jdk/pull/23681/files/db7c1e75..d0ef5526 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=02-03 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/23681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681 PR: https://git.openjdk.org/jdk/pull/23681 From weijun at openjdk.org Mon Feb 24 17:32:55 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 24 Feb 2025 17:32:55 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v4] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 16:47:32 GMT, Mikhail Yankelevich wrote: >> Changed shell files to be java tests: >> * ./validator/certreplace.sh >> * ./validator/samedn.sh > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > othervm rm test/jdk/sun/security/validator/CertReplace.java line 50: > 48: * @modules java.base/sun.security.validator > 49: * > 50: * @run main/othervm CertReplace certreplace.jks certreplace.certs This one does not require `othervm` either. test/jdk/sun/security/validator/CertReplace.java line 105: > 103: > 104: //putting the certificate in the keystore > 105: final CertificateFactory certificateFactory = CertificateFactory.getInstance("X509"); This is useless now. test/jdk/sun/security/validator/CertReplace.java line 113: > 111: ) > 112: }; > 113: certInputStream.close(); Usually we use `try (FileInputStream...)` but your style is also OK. Otherwise we will need to define `certs` outside. You choose. test/jdk/sun/security/validator/CertReplace.java line 171: > 169: "-genkeypair -alias user -dname CN=User -keyalg rsa"); > 170: > 171: final KeyStore keyStore = KeyStoreUtils.loadKeyStore(SAMEDN_JKS, PASSWORD); Although no change to behavior in this method, I'd prefer seeing this line right before the `deleteEntry` call. test/jdk/sun/security/validator/CertReplace.java line 205: > 203: > 204: KeyStore ks = KeyStore.getInstance("JKS"); > 205: ks.load(new FileInputStream(args[0]), "changeit".toCharArray()); You've defined `PASSWORD_CHAR_ARR` for this char array. Also, close this `FileInputStream` to be safe, and the one in `createPath` method below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1968085635 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1968087893 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1968083523 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1968093230 PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1968095859 From abarashev at openjdk.org Mon Feb 24 17:36:53 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 24 Feb 2025 17:36:53 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: Message-ID: On Sun, 23 Feb 2025 05:33:05 GMT, Anthony Scarpino wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in java.security documentation > > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 223: > >> 221: // Handshake signature scope >> 222: public static final Set HANDSHAKE_SCOPE = >> 223: Collections.unmodifiableSet(EnumSet.of(SSLCryptoScope.HANDSHAKE)); > > I think you get the same with `Set.of(SSLCryptoScope.HANDSHAKE)` Yes, looks that way. I just re-used the collections type that was used before in this code. Actually `Set.of` utilizes stricter `ImmutableCollections` as opposed to current `UnmodifiableCollection`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968109791 From duke at openjdk.org Mon Feb 24 17:54:32 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Mon, 24 Feb 2025 17:54:32 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v5] In-Reply-To: References: Message-ID: > Changed shell files to be java tests: > * ./validator/certreplace.sh > * ./validator/samedn.sh Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23727/files - new: https://git.openjdk.org/jdk/pull/23727/files/297b4946..aef7091b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=03-04 Stats: 21 lines in 1 file changed: 3 ins; 5 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/23727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23727/head:pull/23727 PR: https://git.openjdk.org/jdk/pull/23727 From abarashev at openjdk.org Mon Feb 24 18:14:17 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 24 Feb 2025 18:14:17 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v5] In-Reply-To: References: Message-ID: > Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 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 six additional commits since the last revision: - Merge branch 'master' into JDK-8349583 - Use "Set.of()" instead of "Collections.unmodifiableSet(EnumSet.of())" - Use HandshakeContext's localSupportedCertSignAlgs when checking against SSLSession's localSupportedSignAlgs - Fix typo in java.security documentation - Typo fix - 8349583: Add mechanism to disable signature schemes based on their TLS scope ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23681/files - new: https://git.openjdk.org/jdk/pull/23681/files/d0ef5526..23df4cee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=03-04 Stats: 10921 lines in 362 files changed: 5853 ins; 3807 del; 1261 mod Patch: https://git.openjdk.org/jdk/pull/23681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681 PR: https://git.openjdk.org/jdk/pull/23681 From abarashev at openjdk.org Mon Feb 24 18:20:53 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 24 Feb 2025 18:20:53 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: Message-ID: <3g3f6e98atMdWRJglnYfiFoPBGzv4amfKaiygi_Ytu4=.bc22741d-ba65-4999-a5d8-f20a5daa515d@github.com> On Mon, 24 Feb 2025 17:34:42 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 223: >> >>> 221: // Handshake signature scope >>> 222: public static final Set HANDSHAKE_SCOPE = >>> 223: Collections.unmodifiableSet(EnumSet.of(SSLCryptoScope.HANDSHAKE)); >> >> I think you get the same with `Set.of(SSLCryptoScope.HANDSHAKE)` > > Yes, looks that way. I just re-used the collections type that was used before in this code. Actually `Set.of` utilizes stricter `ImmutableCollections` as opposed to current `UnmodifiableCollection`. On the 2nd thought: `Set.of` was introduced in 2015, so it's not available in Java 8, this might be a problem when backporting this code. @seanjmullan what are your thoughts about this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968189436 From abarashev at openjdk.org Mon Feb 24 18:24:53 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 24 Feb 2025 18:24:53 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: Message-ID: On Sun, 23 Feb 2025 02:27:28 GMT, Anthony Scarpino wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in java.security documentation > > src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 220: > >> 218: >> 219: // Checks if algorithm is disabled for the given TLS scopes. >> 220: public boolean permits(String algorithm, Set scopes) { > > Is there a reason you decided to have the caller make it into a `Set` instead of passing SSLCryptoScope down? We can't introduce new public API with this change, `SSLCryptoScope` isn't public. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968193888 From abarashev at openjdk.org Mon Feb 24 18:50:05 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 24 Feb 2025 18:50:05 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: Message-ID: On Sun, 23 Feb 2025 02:08:12 GMT, Anthony Scarpino wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in java.security documentation > > src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 1064: > >> 1062: } >> 1063: >> 1064: private Map> getDisabledAlgorithmScopes() { > > I don't think this new Map is necessary. `algorithmConstraints` would already contain this as a `UsageConstraint` with the algorithm as the key. > > I think if there was a UsageConstraint.permits(Set) you could have a few benefits. First, pushing the conversion from SSLCryptoScope enums to String would be more efficient as no constraint, it would cause no conversion. > Secondly, you could disregard a UsageConstraint that had a non-null `nextConstraint`, that would help your previous concerns about & > It also unifies all `usage` under one class. I thought about it, there are multiple issues associated with this approach: - Different code path and logic behind current `UsageConstraint` implementation. I think we discussed it already at our meeting and we agreed to intercept this special TLS usage before it's consumed by constraints class. - We can't just disregard a UsageConstraint that had a non-null nextConstraint, we can have multiple scopes. - The ampersand `&` is actually used between different constraints (`usage` and `keysize` for example). For the `usage` constraint we have a space-separated list of usages, and we can't mix TLS-specific usages with other usages. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968227461 From duke at openjdk.org Mon Feb 24 18:51:42 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Mon, 24 Feb 2025 18:51:42 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v7] 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](https://github.com/user-attachments/assets/f36a1d8c-3026-4a72-a9e8-b2ecdbf9ed42) > > > 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/46954537..b731a126 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=05-06 Stats: 25 lines in 1 file changed: 0 ins; 0 del; 25 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 Mon Feb 24 18:51:42 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Mon, 24 Feb 2025 18:51:42 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v6] In-Reply-To: References: <4LqRv5AsD4Hyoac0oOroUI3c-Qkf6ul1B7s1iyHejlg=.3fa97db2-0687-4b64-8492-6a0d434ea576@github.com> Message-ID: On Mon, 24 Feb 2025 17:01:45 GMT, Weijun Wang wrote: >> 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 93: > >> 91: >> 92: configfile >> 93: JAAS (Java Authentication and Authorization Service) configuration file loading > > These (and many below) do not need to be ``. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968228514 From ascarpino at openjdk.org Mon Feb 24 19:29:55 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 24 Feb 2025 19:29:55 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: Message-ID: <6v6gY7H4MxB6_v5Ixmd26dikE-zioHux7A7ELDb2lyg=.78dd61d9-8db4-4b54-964d-f9bdad13baf3@github.com> On Mon, 24 Feb 2025 18:21:54 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 220: >> >>> 218: >>> 219: // Checks if algorithm is disabled for the given TLS scopes. >>> 220: public boolean permits(String algorithm, Set scopes) { >> >> Is there a reason you decided to have the caller make it into a `Set` instead of passing SSLCryptoScope down? > > We can't introduce new public API with this change, `SSLCryptoScope` isn't public. Which public API is interfering with this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968298642 From ascarpino at openjdk.org Mon Feb 24 19:38:55 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 24 Feb 2025 19:38:55 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: Message-ID: <684ZGYoVoaSN7SMCxLrT3stdQOwWrONpq2b0McXX-UM=.9a746336-18df-42f8-80de-8798b000b2ce@github.com> On Mon, 24 Feb 2025 18:47:44 GMT, Artur Barashev wrote: > * Different code path and logic behind current `UsageConstraint` implementation. I think we discussed it already at our meeting and we agreed to intercept this special TLS usage before it's consumed by constraints class. We may have had a different thought in deviating from `UsageConstraint`. I didn't think a different processing path was necessary to handle this case, it was something like `UsageConstraint.permit(SSLCryptoScope)` could process this differently than the current `permit(ConstraintParameters)` as that was certificate related. I don't see anything special about this constraint that needs special handling. > > * We can't just disregard a UsageConstraint that had a non-null nextConstraint, we can have multiple scopes. > > * The ampersand `&` is actually used between different constraints (`usage` and `keysize` for example). For the `usage` constraint we have a space-separated list of usages, and we can't mix TLS-specific usages with other usages. If you are ok leaving `&` support, ok. I remember you were concerned about it previously. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968310981 From weijun at openjdk.org Mon Feb 24 19:49:59 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 24 Feb 2025 19:49:59 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v4] In-Reply-To: References: Message-ID: <5D34RUAvpQtg4SOLtrf0270ocHGvzcNZa_gVMpecCvw=.346a06a4-dae3-48dd-aa66-cdc0e6c66cf3@github.com> On Mon, 24 Feb 2025 17:24:51 GMT, Weijun Wang wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> othervm rm > > test/jdk/sun/security/validator/CertReplace.java line 205: > >> 203: >> 204: KeyStore ks = KeyStore.getInstance("JKS"); >> 205: ks.load(new FileInputStream(args[0]), "changeit".toCharArray()); > > You've defined `PASSWORD_CHAR_ARR` for this char array. > > Also, close this `FileInputStream` to be safe, and the one in `createPath` method below. The opened input stream in the `createPath` method is still not closed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23727#discussion_r1968323409 From weijun at openjdk.org Mon Feb 24 19:54:55 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 24 Feb 2025 19:54:55 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v7] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 18:51:42 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/f36a1d8c-3026-4a72-a9e8-b2ecdbf9ed42) >> >> >> 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 142: > 140: provider > 141: Security provider debugging The following sub-options can be used with the provider option: > 142: engine=(engines) : The output is displayed only for a specified list of JCA engines. Precisely, the list below is not the sub-options, the `engine=` is the sub-option. So, it should probably be Security provider debugging. The following engines can be used with the `provider` sub-option: `engine=(engines)` : The output is displayed only for a specified list of JCA engines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968329770 From abarashev at openjdk.org Mon Feb 24 19:55:56 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 24 Feb 2025 19:55:56 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: <6v6gY7H4MxB6_v5Ixmd26dikE-zioHux7A7ELDb2lyg=.78dd61d9-8db4-4b54-964d-f9bdad13baf3@github.com> References: <6v6gY7H4MxB6_v5Ixmd26dikE-zioHux7A7ELDb2lyg=.78dd61d9-8db4-4b54-964d-f9bdad13baf3@github.com> Message-ID: On Mon, 24 Feb 2025 19:26:46 GMT, Anthony Scarpino wrote: >> We can't introduce new public API with this change, `SSLCryptoScope` isn't public. > > Which public API is interfering with this? We can't make `SSLCryptoScope` public, it's not visible to `DisabledAlgorithmConstraints` otherwise as they are in different modules. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968330892 From duke at openjdk.org Mon Feb 24 20:08:12 2025 From: duke at openjdk.org (Mikhail Yankelevich) Date: Mon, 24 Feb 2025 20:08:12 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v6] In-Reply-To: References: Message-ID: > Changed shell files to be java tests: > * ./validator/certreplace.sh > * ./validator/samedn.sh Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: missing close file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23727/files - new: https://git.openjdk.org/jdk/pull/23727/files/aef7091b..2985d18f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23727&range=04-05 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23727/head:pull/23727 PR: https://git.openjdk.org/jdk/pull/23727 From ascarpino at openjdk.org Mon Feb 24 20:15:51 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 24 Feb 2025 20:15:51 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: <6v6gY7H4MxB6_v5Ixmd26dikE-zioHux7A7ELDb2lyg=.78dd61d9-8db4-4b54-964d-f9bdad13baf3@github.com> Message-ID: On Mon, 24 Feb 2025 19:52:53 GMT, Artur Barashev wrote: >> Which public API is interfering with this? > > We can't make `SSLCryptoScope` public, it's not visible to `DisabledAlgorithmConstraints` otherwise as they are in different modules. Neither are public APIs. Is there a public API between that is preventing this? They are both in the same java.base module. They are in different packages, but both are not public (sun.security.ssl and sun.security.util). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968355739 From weijun at openjdk.org Mon Feb 24 20:26:56 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 24 Feb 2025 20:26:56 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v8] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:01:13 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/f36a1d8c-3026-4a72-a9e8-b2ecdbf9ed42) >> >> >> 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 183: > 181: > 182: > 183:

Printing Thread and Timestamp Information

This should be a sub-section below `

Debug

`. In fact, it should be below `

{@systemProperty java.security.debug}

`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968368247 From duke at openjdk.org Mon Feb 24 20:30:53 2025 From: duke at openjdk.org (duke) Date: Mon, 24 Feb 2025 20:30:53 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v6] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:08:12 GMT, Mikhail Yankelevich wrote: >> Changed shell files to be java tests: >> * ./validator/certreplace.sh >> * ./validator/samedn.sh > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > missing close file @myankelev Your change (at version 2985d18f7b14197956232b369f3e036420818e76) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23727#issuecomment-2679570563 From weijun at openjdk.org Mon Feb 24 20:30:53 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 24 Feb 2025 20:30:53 GMT Subject: RFR: 8349533: Refactor validator tests shell files to java [v6] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 20:08:12 GMT, Mikhail Yankelevich wrote: >> Changed shell files to be java tests: >> * ./validator/certreplace.sh >> * ./validator/samedn.sh > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > missing close file Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23727#pullrequestreview-2638364290 From mullan at openjdk.org Mon Feb 24 21:00:59 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 24 Feb 2025 21:00:59 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v8] In-Reply-To: References: Message-ID: <4cZ0qx5HUrWFIsuGG8NMKaA3kiUwptfH7-Vk5ioAP7w=.71816c17-8f9a-4a97-9a48-6d1746ab190c@github.com> On Mon, 24 Feb 2025 20:01:13 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/f36a1d8c-3026-4a72-a9e8-b2ecdbf9ed42) >> >> >> 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 65: > 63:

To monitor security access, you can set the java.security.debug system property, > 64: which determines what trace messages are printed during execution. The value of the property is one or more options separated by a comma. > 65: Some options also have additional sub-options; see the list below for more details on the syntax of each. Do we want to state a syntax for sub-options? The implementation is very flexible, it just searches for the sub-option. But I think the de-facto syntax is the option, a ":" and then a list of one more more sub-options separated by a comma. Ex: java.security.debug=certpath:ocsp,verbose src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 141: > 139: > 140: provider > 141: Security provider debugging. The following engines can be used with the `provider` sub-option: Does markdown get rendered in code font here, ex: `provider`? src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 175: > 173: > 174: x509 > 175: X.509 certificate debugging. You can use the following sub-option with X.509 s/with X.509/with x509:/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968404844 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968408603 PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968407990 From abarashev at openjdk.org Mon Feb 24 21:13:58 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 24 Feb 2025 21:13:58 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: <6v6gY7H4MxB6_v5Ixmd26dikE-zioHux7A7ELDb2lyg=.78dd61d9-8db4-4b54-964d-f9bdad13baf3@github.com> Message-ID: On Mon, 24 Feb 2025 20:13:24 GMT, Anthony Scarpino wrote: >> We can't make `SSLCryptoScope` public, it's not visible to `DisabledAlgorithmConstraints` otherwise as they are in different modules. > > Neither are public APIs. Is there a public API between that is preventing this? They are both in the same java.base module. They are in different packages, but both are not public (sun.security.ssl and sun.security.util). I meant they are in different packages. We need to make SSLCryptoScope public to exposed outside of `ssl` package. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968424276 From mullan at openjdk.org Mon Feb 24 21:21:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 24 Feb 2025 21:21:57 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v8] In-Reply-To: <4cZ0qx5HUrWFIsuGG8NMKaA3kiUwptfH7-Vk5ioAP7w=.71816c17-8f9a-4a97-9a48-6d1746ab190c@github.com> References: <4cZ0qx5HUrWFIsuGG8NMKaA3kiUwptfH7-Vk5ioAP7w=.71816c17-8f9a-4a97-9a48-6d1746ab190c@github.com> Message-ID: On Mon, 24 Feb 2025 20:54:27 GMT, Sean Mullan wrote: >> 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 65: > >> 63:

To monitor security access, you can set the java.security.debug system property, >> 64: which determines what trace messages are printed during execution. The value of the property is one or more options separated by a comma. >> 65: Some options also have additional sub-options; see the list below for more details on the syntax of each. > > Do we want to state a syntax for sub-options? The implementation is very flexible, it just searches for the sub-option. But I think the de-facto syntax is the option, a ":" and then a list of one more more sub-options separated by a comma. Ex: java.security.debug=certpath:ocsp,verbose I suggest we say something like the following, and also give an example: Sub-options are specified by appending a ":" to the option, followed by a list of one more sub-options separated by a comma. For example, to specify the `ocsp` and `verbose` options with the `certpath` option: set the property to "certpath:ocsp,verbose". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968432434 From mullan at openjdk.org Mon Feb 24 21:23:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 24 Feb 2025 21:23:53 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: References: <6v6gY7H4MxB6_v5Ixmd26dikE-zioHux7A7ELDb2lyg=.78dd61d9-8db4-4b54-964d-f9bdad13baf3@github.com> Message-ID: On Mon, 24 Feb 2025 21:11:30 GMT, Artur Barashev wrote: >> Neither are public APIs. Is there a public API between that is preventing this? They are both in the same java.base module. They are in different packages, but both are not public (sun.security.ssl and sun.security.util). > > I meant they are in different packages. We need to make SSLCryptoScope public to expose outside of `ssl` package. That's fine, you can make it public. Both classes are in internal packages in the java.base module, so it won't be exposed as a public API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968434926 From ascarpino at openjdk.org Mon Feb 24 21:25:48 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 24 Feb 2025 21:25:48 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v2] In-Reply-To: References: Message-ID: <3gMu1AjEHz_e-JAh_DwLu1mFTlSMpxdmBtPmDCHL2so=.e3374ad5-f721-4083-8cfa-2038fd9b627d@github.com> > Hi, > > I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: - undo comment - review comments and remove aliases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23647/files - new: https://git.openjdk.org/jdk/pull/23647/files/9fbddcc2..203833b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23647&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23647&range=00-01 Stats: 106 lines in 4 files changed: 37 ins; 43 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/23647.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23647/head:pull/23647 PR: https://git.openjdk.org/jdk/pull/23647 From ascarpino at openjdk.org Mon Feb 24 21:31:54 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 24 Feb 2025 21:31:54 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v3] In-Reply-To: <3g3f6e98atMdWRJglnYfiFoPBGzv4amfKaiygi_Ytu4=.bc22741d-ba65-4999-a5d8-f20a5daa515d@github.com> References: <3g3f6e98atMdWRJglnYfiFoPBGzv4amfKaiygi_Ytu4=.bc22741d-ba65-4999-a5d8-f20a5daa515d@github.com> Message-ID: On Mon, 24 Feb 2025 18:18:25 GMT, Artur Barashev wrote: >> Yes, looks that way. I just re-used the collections type that was used before in this code. Actually `Set.of` utilizes stricter `ImmutableCollections` as opposed to current `UnmodifiableCollection`. > > On the 2nd thought: `Set.of` was introduced in 2015, so it's not available in Java 8, this might be a problem when backporting this code. > @seanjmullan what are your thoughts about this? Something like this is probably ok given it's only jdk8. When many release don't have support, I think it's more of a concern. Additionally these are variable definitions, that are unlikely to change while if a deviation happened in a method, it can get more complex over time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1968442786 From wetmore at openjdk.org Mon Feb 24 22:59:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Mon, 24 Feb 2025 22:59:55 GMT Subject: Integrated: 8350476: Fix typo introduced in JDK-8350147 In-Reply-To: References: Message-ID: On Sat, 22 Feb 2025 02:25:42 GMT, Bradford Wetmore wrote: > Typo: s/ficticious/fictitious/ > > No unit test. Check that javadoc still builds. This pull request has now been integrated. Changeset: 990d40e9 Author: Bradford Wetmore URL: https://git.openjdk.org/jdk/commit/990d40e98da2ceb3261096eaa55550565af58fc1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8350476: Fix typo introduced in JDK-8350147 Reviewed-by: jnimeh, jpai ------------- PR: https://git.openjdk.org/jdk/pull/23733 From davide.malpassini at gmail.com Fri Feb 7 21:20:50 2025 From: davide.malpassini at gmail.com (Davide Malpassini) Date: Fri, 07 Feb 2025 21:20:50 -0000 Subject: PKCS #12 Support RFC 9579 In-Reply-To: <6cb8ca6b-9311-4c8b-ab47-c6a29972c992@oracle.com> References: <6cb8ca6b-9311-4c8b-ab47-c6a29972c992@oracle.com> Message-ID: Hi Sean Thank you very much. May I ask to update the issue with more updated info? It's talking about something that will be approved instead it's has been approved and already exists other tools like openssl and bouncy castle that already implements it. In any case thank you very much. Best regards Davide Malpassini Il Ven 7 Feb 2025, 19:50 Sean Mullan ha scritto: > Hi Davide, > > Yes, we are working on this and it is being tracked in this issue: > https://bugs.openjdk.org/browse/JDK-8343232 > > Thanks, > Sean > > On 2/7/25 8:56 AM, Davide Malpassini wrote: > > Hi, > > RFC 9579 , that add another MAC algorithm to PKCS#12 compatible with > > FIPS 140-3, has been approved and openssl 3.4 , bouncy castle and future > > redhat 10 already supports it. I want to know the plan to support it and > > avoid ending with some p12 files that cannot be read by java nut from > > any other tool . > > Best regards > > Davide Malpassini > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jr at qsm.co.il Sat Feb 22 12:43:22 2025 From: jr at qsm.co.il (Jonathan Rosenne) Date: Sat, 22 Feb 2025 12:43:22 +0000 Subject: JEP draft: PEM Encodings of Cryptographic Objects Message-ID: How will certificate chains be supported? Best Regards, Jonathan Rosenne -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Feb 25 00:29:35 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 25 Feb 2025 00:29:35 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v9] 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](https://github.com/user-attachments/assets/f36a1d8c-3026-4a72-a9e8-b2ecdbf9ed42) > > > 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/228d35be..11a0f818 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23569&range=07-08 Stats: 40 lines in 1 file changed: 15 ins; 13 del; 12 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 Feb 25 00:33:00 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 25 Feb 2025 00:33:00 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v8] In-Reply-To: References: <4cZ0qx5HUrWFIsuGG8NMKaA3kiUwptfH7-Vk5ioAP7w=.71816c17-8f9a-4a97-9a48-6d1746ab190c@github.com> Message-ID: On Mon, 24 Feb 2025 21:19:19 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 65: >> >>> 63:

To monitor security access, you can set the java.security.debug system property, >>> 64: which determines what trace messages are printed during execution. The value of the property is one or more options separated by a comma. >>> 65: Some options also have additional sub-options; see the list below for more details on the syntax of each. >> >> Do we want to state a syntax for sub-options? The implementation is very flexible, it just searches for the sub-option. But I think the de-facto syntax is the option, a ":" and then a list of one more more sub-options separated by a comma. Ex: java.security.debug=certpath:ocsp,verbose > > I suggest we say something like the following, and also give an example: > > Sub-options are specified by appending a ":" to the option, followed by a list of one more sub-options separated by a comma. For example, to specify the `ocsp` and `verbose` options with the `certpath` option: set the property to "certpath:ocsp,verbose". Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968620373 From duke at openjdk.org Tue Feb 25 00:33:01 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 25 Feb 2025 00:33:01 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v8] In-Reply-To: <4cZ0qx5HUrWFIsuGG8NMKaA3kiUwptfH7-Vk5ioAP7w=.71816c17-8f9a-4a97-9a48-6d1746ab190c@github.com> References: <4cZ0qx5HUrWFIsuGG8NMKaA3kiUwptfH7-Vk5ioAP7w=.71816c17-8f9a-4a97-9a48-6d1746ab190c@github.com> Message-ID: On Mon, 24 Feb 2025 20:57:38 GMT, Sean Mullan wrote: >> 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 141: > >> 139: >> 140: provider >> 141: Security provider debugging. The following engines can be used with the `provider` sub-option: > > Does markdown get rendered in code font here, ex: `provider`? I added code font. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1968620733 From aph at openjdk.org Tue Feb 25 09:40:57 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 25 Feb 2025 09:40:57 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> Message-ID: On Mon, 24 Feb 2025 17:11:24 GMT, Andrew Dinn wrote: >> I have tried that, but the python script (actually the as command that it started) threw error messages: >> >> aarch64ops.s:338:24: error: index must be a multiple of 8 in range [0, 32760]. >> prfm PLDL1KEEP, [x15, 43] >> ^ >> aarch64ops.s:357:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] >> sub x1, x10, x23, sxth #2 >> ^ >> aarch64ops.s:359:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] >> add x11, x21, x5, uxtb #3 >> ^ >> aarch64ops.s:360:22: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] >> adds x11, x17, x17, uxtw #1 >> ^ >> aarch64ops.s:361:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] >> sub x11, x0, x15, uxtb #1 >> ^ >> aarch64ops.s:362:19: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] >> subs x7, x1, x0, sxth #2 >> ^ >> This is without any modifications from what is in the master branch currently. > > @ferakocz This also really needs addressing before committing the patch. Perhaps @theRealAph can advise on how to circumvent the problems you found when trying to update the python script? > You might have to use an assembler from the latest binutils build (if the system default isn't the latest) and add the path to the assembler in the "AS" variable. Also you can run it something like - `python aarch64-asmtest.py | expand > asmtest.out.h`. Please let me know if you still face problems. People have been running this script for a decade now. Let's look at just one of these: aarch64ops.s:357:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] sub x1, x10, x23, sxth #2 >From the AArch64 manual: SUB (extended register) SUB , , {, {#}} It thinks this is a SUB (shifted register), bit it's really a SUB (extended register). fedora:aarch64 $ cat t.s sub x1, x10, x23, sxth #2 fedora:aarch64 $ as t.s fedora:aarch64 $ objdump -D a.out Disassembly of section .text: 0000000000000000 <.text>: 0: cb37a941 sub x1, x10, w23, sxth #2 So perhaps binutils expects w23 here, not x23. But the manual (ARM DDI 0487K.a) says x23 should be just fine, and, what's more, gives the x form preferred status. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1969374124 From duke at openjdk.org Tue Feb 25 11:17:58 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 25 Feb 2025 11:17:58 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> Message-ID: On Tue, 25 Feb 2025 09:36:49 GMT, Andrew Haley wrote: >> @ferakocz This also really needs addressing before committing the patch. Perhaps @theRealAph can advise on how to circumvent the problems you found when trying to update the python script? > >> You might have to use an assembler from the latest binutils build (if the system default isn't the latest) and add the path to the assembler in the "AS" variable. Also you can run it something like - `python aarch64-asmtest.py | expand > asmtest.out.h`. Please let me know if you still face problems. > > People have been running this script for a decade now. > > Let's look at just one of these: > > > aarch64ops.s:357:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > sub x1, x10, x23, sxth #2 > > > From the AArch64 manual: > > SUB (extended register) > SUB , , {, {#}} > > It thinks this is a SUB (shifted register), bit it's really a SUB (extended register). > > > fedora:aarch64 $ cat t.s > sub x1, x10, x23, sxth #2 > fedora:aarch64 $ as t.s > fedora:aarch64 $ objdump -D a.out > Disassembly of section .text: > > 0000000000000000 <.text>: > 0: cb37a941 sub x1, x10, w23, sxth #2 > > > So perhaps binutils expects w23 here, not x23. But the manual (ARM DDI 0487K.a) says x23 should be just fine, and, what's more, gives the x form preferred status. @theRealAlph, maybe we are not reading the same manual (ARM DDI 0487K.a). In my copy: SUB (extended register) is defined as SUB , , {, {#}} and should be W when is SXTH and the as I have enforces this: ferakocz at ferakocz-mac aarch64 % cat t.s sub x1, x10, w23, sxth #2 ferakocz at ferakocz-mac aarch64 % cat > t1.s sub x1, x10, x23, sxth #2 ferakocz at ferakocz-mac aarch64 % cat t.s sub x1, x10, w23, sxth #2 ferakocz at ferakocz-mac aarch64 % cat t1.s sub x1, x10, x23, sxth #2 ferakocz at ferakocz-mac aarch64 % as --version Apple clang version 16.0.0 (clang-1600.0.26.6) Target: arm64-apple-darwin24.3.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin ferakocz at ferakocz-mac aarch64 % as t.s ferakocz at ferakocz-mac aarch64 % objdump -D t.o t.o: file format mach-o arm64 Disassembly of section __TEXT,__text: 0000000000000000 : 0: cb37a941 sub x1, x10, w23, sxth #2 ferakocz at ferakocz-mac aarch64 % as t1.s t1.s:1:19: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] sub x1, x10, x23, sxth #2 ^ I have not found the place in the manual where it allows/encourages the use of x instead of w, but I admit I haven't read through all of the 14568 pages. So I'm stuck for now. What 'as' are you using? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1969561791 From aph at openjdk.org Tue Feb 25 13:19:03 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 25 Feb 2025 13:19:03 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> Message-ID: On Tue, 25 Feb 2025 13:14:52 GMT, Andrew Haley wrote: >> @theRealAlph, maybe we are not reading the same manual (ARM DDI 0487K.a). In my copy: >> SUB (extended register) is defined as >> SUB , , {, {#}} >> and should be W when is SXTH >> and the as I have enforces this: >> >> ferakocz at ferakocz-mac aarch64 % cat t.s >> sub x1, x10, w23, sxth #2 >> ferakocz at ferakocz-mac aarch64 % cat > t1.s >> sub x1, x10, x23, sxth #2 >> ferakocz at ferakocz-mac aarch64 % cat t.s >> sub x1, x10, w23, sxth #2 >> ferakocz at ferakocz-mac aarch64 % cat t1.s >> sub x1, x10, x23, sxth #2 >> ferakocz at ferakocz-mac aarch64 % as --version >> Apple clang version 16.0.0 (clang-1600.0.26.6) >> Target: arm64-apple-darwin24.3.0 >> Thread model: posix >> InstalledDir: /Library/Developer/CommandLineTools/usr/bin >> ferakocz at ferakocz-mac aarch64 % as t.s >> ferakocz at ferakocz-mac aarch64 % objdump -D t.o >> >> t.o: file format mach-o arm64 >> >> Disassembly of section __TEXT,__text: >> >> 0000000000000000 : >> 0: cb37a941 sub x1, x10, w23, sxth #2 >> ferakocz at ferakocz-mac aarch64 % as t1.s >> t1.s:1:19: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] >> sub x1, x10, x23, sxth #2 >> ^ >> >> I have not found the place in the manual where it allows/encourages the use of x instead of w, but I admit I haven't read through all of the 14568 pages. >> >> So I'm stuck for now. What 'as' are you using? > >> I have not found the place in the manual where it allows/encourages the use of x instead of w, but I admit I > haven't read through all of the 14568 pages. > > Yes, you've got a point, but it's always worked. Is this a macos thing, maybe? > >> So I'm stuck for now. What 'as' are you using? > > Latest binutils, today. I checked it out half an hour ago. > > GNU assembler (GNU Binutils) 2.44.50.20250225 > Copyright (C) 2025 Free Software Foundation, Inc. > > Try this: > > > diff --git a/test/hotspot/gtest/aarch64/aarch64-asmtest.py b/test/hotspot/gtest/aarch64/aarch64-asmtest.py > index 9c770632e25..b1674fff04d 100644 > --- a/test/hotspot/gtest/aarch64/aarch64-asmtest.py > +++ b/test/hotspot/gtest/aarch64/aarch64-asmtest.py > @@ -476,8 +476,13 @@ class AddSubExtendedOp(ThreeRegInstruction): > + ", " + str(self.amount) + ");")) > > def astr(self): > - return (super(AddSubExtendedOp, self).astr() > - + (", " + AddSubExtendedOp.optNames[self.option] > + prefix = self.asmRegPrefix > + return (super(ThreeRegInstruction, self).astr() > + + ('%s, %s, %s' > + % (self.reg[0].astr(prefix), > + self.reg[1].astr(prefix), > + self.reg[1].astr("w")) > + + ", " + AddSubExtendedOp.optNames[self.option] > + " #" + str(self.amount))) > > class AddSubImmOp(TwoRegImmedInstruction): I just tried it with top-of trunk latest binutils: fedora:aarch64 $ ~/binutils-gdb-install/bin/as -march=armv9-a+sha3+sve2-bitperm aarch64ops.s fedora:aarch64 $ ~/binutils-gdb-install/bin/as --version GNU assembler (GNU Binutils) 2.44.50.20250225 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1969761898 From aph at openjdk.org Tue Feb 25 13:19:02 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 25 Feb 2025 13:19:02 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> Message-ID: On Tue, 25 Feb 2025 11:15:39 GMT, Ferenc Rakoczi wrote: >>> You might have to use an assembler from the latest binutils build (if the system default isn't the latest) and add the path to the assembler in the "AS" variable. Also you can run it something like - `python aarch64-asmtest.py | expand > asmtest.out.h`. Please let me know if you still face problems. >> >> People have been running this script for a decade now. >> >> Let's look at just one of these: >> >> >> aarch64ops.s:357:20: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] >> sub x1, x10, x23, sxth #2 >> >> >> From the AArch64 manual: >> >> SUB (extended register) >> SUB , , {, {#}} >> >> It thinks this is a SUB (shifted register), bit it's really a SUB (extended register). >> >> >> fedora:aarch64 $ cat t.s >> sub x1, x10, x23, sxth #2 >> fedora:aarch64 $ as t.s >> fedora:aarch64 $ objdump -D a.out >> Disassembly of section .text: >> >> 0000000000000000 <.text>: >> 0: cb37a941 sub x1, x10, w23, sxth #2 >> >> >> So perhaps binutils expects w23 here, not x23. But the manual (ARM DDI 0487K.a) says x23 should be just fine, and, what's more, gives the x form preferred status. > > @theRealAlph, maybe we are not reading the same manual (ARM DDI 0487K.a). In my copy: > SUB (extended register) is defined as > SUB , , {, {#}} > and should be W when is SXTH > and the as I have enforces this: > > ferakocz at ferakocz-mac aarch64 % cat t.s > sub x1, x10, w23, sxth #2 > ferakocz at ferakocz-mac aarch64 % cat > t1.s > sub x1, x10, x23, sxth #2 > ferakocz at ferakocz-mac aarch64 % cat t.s > sub x1, x10, w23, sxth #2 > ferakocz at ferakocz-mac aarch64 % cat t1.s > sub x1, x10, x23, sxth #2 > ferakocz at ferakocz-mac aarch64 % as --version > Apple clang version 16.0.0 (clang-1600.0.26.6) > Target: arm64-apple-darwin24.3.0 > Thread model: posix > InstalledDir: /Library/Developer/CommandLineTools/usr/bin > ferakocz at ferakocz-mac aarch64 % as t.s > ferakocz at ferakocz-mac aarch64 % objdump -D t.o > > t.o: file format mach-o arm64 > > Disassembly of section __TEXT,__text: > > 0000000000000000 : > 0: cb37a941 sub x1, x10, w23, sxth #2 > ferakocz at ferakocz-mac aarch64 % as t1.s > t1.s:1:19: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] > sub x1, x10, x23, sxth #2 > ^ > > I have not found the place in the manual where it allows/encourages the use of x instead of w, but I admit I haven't read through all of the 14568 pages. > > So I'm stuck for now. What 'as' are you using? > I have not found the place in the manual where it allows/encourages the use of x instead of w, but I admit I > haven't read through all of the 14568 pages. Yes, you've got a point, but it's always worked. Is this a macos thing, maybe? > So I'm stuck for now. What 'as' are you using? Latest binutils, today. I checked it out half an hour ago. GNU assembler (GNU Binutils) 2.44.50.20250225 Copyright (C) 2025 Free Software Foundation, Inc. Try this: diff --git a/test/hotspot/gtest/aarch64/aarch64-asmtest.py b/test/hotspot/gtest/aarch64/aarch64-asmtest.py index 9c770632e25..b1674fff04d 100644 --- a/test/hotspot/gtest/aarch64/aarch64-asmtest.py +++ b/test/hotspot/gtest/aarch64/aarch64-asmtest.py @@ -476,8 +476,13 @@ class AddSubExtendedOp(ThreeRegInstruction): + ", " + str(self.amount) + ");")) def astr(self): - return (super(AddSubExtendedOp, self).astr() - + (", " + AddSubExtendedOp.optNames[self.option] + prefix = self.asmRegPrefix + return (super(ThreeRegInstruction, self).astr() + + ('%s, %s, %s' + % (self.reg[0].astr(prefix), + self.reg[1].astr(prefix), + self.reg[1].astr("w")) + + ", " + AddSubExtendedOp.optNames[self.option] + " #" + str(self.amount))) class AddSubImmOp(TwoRegImmedInstruction): ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1969760509 From aph at openjdk.org Tue Feb 25 13:52:55 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 25 Feb 2025 13:52:55 GMT Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5] In-Reply-To: References: <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com> Message-ID: On Tue, 25 Feb 2025 13:15:49 GMT, Andrew Haley wrote: >>> I have not found the place in the manual where it allows/encourages the use of x instead of w, but I admit I > haven't read through all of the 14568 pages. >> >> Yes, you've got a point, but it's always worked. Is this a macos thing, maybe? >> >>> So I'm stuck for now. What 'as' are you using? >> >> Latest binutils, today. I checked it out half an hour ago. >> >> GNU assembler (GNU Binutils) 2.44.50.20250225 >> Copyright (C) 2025 Free Software Foundation, Inc. >> >> Try this: >> >> >> diff --git a/test/hotspot/gtest/aarch64/aarch64-asmtest.py b/test/hotspot/gtest/aarch64/aarch64-asmtest.py >> index 9c770632e25..b1674fff04d 100644 >> --- a/test/hotspot/gtest/aarch64/aarch64-asmtest.py >> +++ b/test/hotspot/gtest/aarch64/aarch64-asmtest.py >> @@ -476,8 +476,13 @@ class AddSubExtendedOp(ThreeRegInstruction): >> + ", " + str(self.amount) + ");")) >> >> def astr(self): >> - return (super(AddSubExtendedOp, self).astr() >> - + (", " + AddSubExtendedOp.optNames[self.option] >> + prefix = self.asmRegPrefix >> + return (super(ThreeRegInstruction, self).astr() >> + + ('%s, %s, %s' >> + % (self.reg[0].astr(prefix), >> + self.reg[1].astr(prefix), >> + self.reg[1].astr("w")) >> + + ", " + AddSubExtendedOp.optNames[self.option] >> + " #" + str(self.amount))) >> >> class AddSubImmOp(TwoRegImmedInstruction): > > I just tried it with top-of trunk latest binutils: > > fedora:aarch64 $ ~/binutils-gdb-install/bin/as -march=armv9-a+sha3+sve2-bitperm aarch64ops.s > fedora:aarch64 $ ~/binutils-gdb-install/bin/as --version > GNU assembler (GNU Binutils) 2.44.50.20250225 Aha! aph at Andrews-MacBook-Pro ~ % as t.s t.s:1:19: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4] sub x1, x10, x23, sxth #2 ^ aph at Andrews-MacBook-Pro ~ % as --version Apple clang version 16.0.0 (clang-1600.0.26.6) Target: arm64-apple-darwin24.3.0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1969823700 From abarashev at openjdk.org Tue Feb 25 14:49:01 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 25 Feb 2025 14:49:01 GMT Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v2] In-Reply-To: <3gMu1AjEHz_e-JAh_DwLu1mFTlSMpxdmBtPmDCHL2so=.e3374ad5-f721-4083-8cfa-2038fd9b627d@github.com> References: <3gMu1AjEHz_e-JAh_DwLu1mFTlSMpxdmBtPmDCHL2so=.e3374ad5-f721-4083-8cfa-2038fd9b627d@github.com> Message-ID: On Mon, 24 Feb 2025 21:25:48 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: > > - undo comment > - review comments and remove aliases src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 92: > 90: if (algorithm.equalsIgnoreCase(a)) { > 91: return false; > 92: } We already do case-insensitive match here because `algorithms` is a case-insensitive TreeMap constructed above in `getAlgorithms()`. Existing code is also faster because it's a tree lookup instead of a linear iteration. This whole file can stay unchanged if we removed aliases already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1969931858 From mpowers at openjdk.org Tue Feb 25 15:24:02 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 25 Feb 2025 15:24:02 GMT Subject: Integrated: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes In-Reply-To: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> References: <_GL1NmUxVdvIj89fc2h4o4YlNuvdO41V3gtS8mFMX_g=.d6dae36e-9969-4525-8027-72971e2e081e@github.com> Message-ID: On Sat, 18 Jan 2025 00:14:58 GMT, Mark Powers wrote: > [JDK-8267068](https://bugs.openjdk.org/browse/JDK-8267068) This pull request has now been integrated. Changeset: 50239716 Author: Mark Powers URL: https://git.openjdk.org/jdk/commit/50239716403732fe8af73b4b6f006b6a4b7b22db Stats: 33 lines in 4 files changed: 3 ins; 1 del; 29 mod 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes Reviewed-by: valeriep, jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/23188 From abarashev at openjdk.org Tue Feb 25 15:49:37 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 25 Feb 2025 15:49:37 GMT Subject: RFR: 8349583: Add mechanism to disable signature schemes based on their TLS scope [v6] In-Reply-To: References: Message-ID: > Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: - Refactor code to use existing "usage" constraint. - Rename SSLCryptoScope to SSLScope, make it public. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23681/files - new: https://git.openjdk.org/jdk/pull/23681/files/23df4cee..f663e04f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=04-05 Stats: 254 lines in 5 files changed: 102 ins; 129 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/23681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681 PR: https://git.openjdk.org/jdk/pull/23681 From weijun at openjdk.org Tue Feb 25 15:54:09 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 25 Feb 2025 15:54:09 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v9] In-Reply-To: References: Message-ID: <6ThXIled5v2oPqFKndDzxjXw0GOptsX7fVWex2anyvw=.3340328f-0d74-4c5f-b28b-744bf0c5f4a7@github.com> On Tue, 25 Feb 2025 00:29:35 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/0c9a79f3-4cb2-414c-af1d-eac2590740ea) >> >> >> 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 29: > 27: > 28: > 29: Security-Related System Property Not what I expected. Either you keep the old name and add a few new system properties, or, just change the whole title to something like "Troubleshooting" or "Printing Debug Information". src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 58: > 56: and therefore are best set using the -D option of the java command, > 57: while others have a more dynamic nature and can also be changed using > 58: the System.setProperty() API. The `System.setProperty()` call should be in ``. src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 63: > 61:

Debug

> 62:

{@systemProperty java.security.debug}

> 63:

Printing Thread and Timestamp Information

This is still a big `

`, which is at the same level as `

Debug

`. src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 68: > 66: system property to print additional information: > 67:
    > 68:
  • +thread:Print thread and caller information
    • Put `:` outside ``. Hi @coffeys and @seanjmullan, now that we have a formal format for options and sub-options, shall we have one for these modifiers? Should it always be appended after the sub-option(s)? Like x509:ava+thread,certpath:ocsp,verbose+timestamp+thread Also, how do we specify multiple engines in `provider`? Should it look like this? provider:engine=Cipher,Mac src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 74: > 72: For example, to add thread, caller, and timestamp information to all debuging output, > 73: set the java.security.debug system property on the command line as follows:
    > 74: java -Djava.security.debug=all+thread+timestamp MyApp For the code in its own paragraph, should it be something like `
    `?

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 79:

> 77:             which determines what trace messages are printed during execution. The value of the property is one or more options separated by a comma.
> 78:             Some options also have additional sub-options. Sub-options are specified by appending a ":" to the option, followed by a list of one more sub-options separated by a comma.
> 79:             For example, to specify the ocsp and verbose options with the certpath option: set the property to "certpath:ocsp,verbose".

Do we need `"` inside ``?

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 94:

> 92:     
> 93:         all
> 94:         Turn on all the debugging options

Remove `` from the line above.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 102:

> 100:             
      
> 101:                 
    • ocsp: Dump OCSP protocol exchanges
      • 
> 102:                 
    • verbose: Print additional debugging information
      • 

Move `:` out of ``.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 128:

> 126:     
> 127:         KeyStore
> 128:         Keystore debugging

it's `KeyStore`.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 157:

> 155:         provider
> 156:         Security provider debugging. The following engines can be used with the `provider` sub-option:
> 157:             `engine=(engines)` : The output is displayed only for a specified list of JCA engines.

Remove extra "`".

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 190:

> 188:     
> 189:         x509
> 190:         X.509 certificate debugging. You can use the following sub-option with X.509

No need for "X.509" in ``.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 192:

> 190:         X.509 certificate debugging. You can use the following sub-option with X.509
> 191:             
        
> 192:                 
      • ava: Embed non-printable/non-escaped characters in AVA components as hex strings
        • 

Move `:` out of ``.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970006546
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970034740
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970008007
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970023633
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970055051
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970051804
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970053286
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970059952
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970056086
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970057231
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970058092
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1970059105

From duke at openjdk.org  Tue Feb 25 16:00:57 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 25 Feb 2025 16:00:57 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v5]
In-Reply-To: 
References: 
 
 <1yB95sOajuS5ptFI0GQWLepii5JsZ9DOsje-TEFyFYs=.a325ad18-17ed-4e77-b1e3-0bad2cf55c67@github.com>
 
 
 
 
 
 
 
Message-ID: <_CekdxBJviS_sZCVN62_yFx-cTF4qrIuAnqbIeUmFck=.3a6afffb-8fbe-4809-a4ca-1bc22b52a628@github.com>

On Tue, 25 Feb 2025 13:50:35 GMT, Andrew Haley  wrote:

>> I just tried it with top-of trunk latest binutils:
>> 
>> fedora:aarch64 $ ~/binutils-gdb-install/bin/as -march=armv9-a+sha3+sve2-bitperm aarch64ops.s
>> fedora:aarch64 $ ~/binutils-gdb-install/bin/as --version
>> GNU assembler (GNU Binutils) 2.44.50.20250225
>
> Aha!
> 
> 
> aph at Andrews-MacBook-Pro ~ % as t.s   
> t.s:1:19: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4]
> sub x1, x10, x23, sxth #2
>                   ^
> aph at Andrews-MacBook-Pro ~ % as --version
> Apple clang version 16.0.0 (clang-1600.0.26.6)
> Target: arm64-apple-darwin24.3.0

OK, so GNU as is more forgiving than Apple as...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23300#discussion_r1970076152

From weijun at openjdk.org  Tue Feb 25 16:16:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Feb 2025 16:16:06 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 25 Feb 2025 00:29:35 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/0c9a79f3-4cb2-414c-af1d-eac2590740ea)
>> 
>> 
>> 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 30:

> 28:     
> 29:     Security-Related System Property
> 30: