From lkorinth at openjdk.org Mon Sep 1 08:07:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 08:07:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8] In-Reply-To: References: Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@github.com> > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - new timeouts - Merge branch '_master_jdk' into _8260555 - update copyright - revert added timeout, it is not needed - feedback from Mark Sheppard - update testing.md, remove makefile link, fix bad text - after suggestion from Daniel - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD - After suggestions from Erik and Andrey - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06-07 Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From fferrari at openjdk.org Mon Sep 1 12:15:44 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Mon, 1 Sep 2025 12:15:44 GMT Subject: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions In-Reply-To: <45gEnigXd-WxofLVYu0K6QDbLq72YZvzroUWy-owk6M=.d25d1075-2488-4982-906f-5cc431429823@github.com> References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> <45gEnigXd-WxofLVYu0K6QDbLq72YZvzroUWy-owk6M=.d25d1075-2488-4982-906f-5cc431429823@github.com> Message-ID: On Thu, 1 May 2025 10:35:55 GMT, Alan Bateman wrote: >>> File::getCanonicalPath seems to take the best-effort approach (both in Linux and Windows), whereas Path::toRealPath is stricter. >> >> Path::toRealPath is doing the right thing, and consistent with realpath(2). The issue with File::getCanonicalXXX is that it is specified to return a canonical file even if it doesn't exist, so this is why you see a lot more code to compute a result. >> >> Maybe the recursive include check them maybe it should use the file key instead. > >> @AlanBateman are you ok with letting the original [c6f1d5f](https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab) reviewers know of this fix and take a look? Or do you think further discussion is needed somewhere else? > > Have you had time to try using the file key to detect the recursive include case? Hi @AlanBateman, have you had time to review my previous message? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3242132203 From myankelevich at openjdk.org Mon Sep 1 13:12:47 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 1 Sep 2025 13:12:47 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 18:09:55 GMT, Matthew Donovan wrote: > This PR extends security tests to use ByteBuffers backed by MemorySegments. Tests in the areas of Signature, Cipher, MessageDigest, and Mac are updated. Looks good, just one comment and a few nitpicks. IMO nits are not worth doing unless there is another commit. test/jdk/javax/crypto/Cipher/GCMAPI.java line 32: > 30: > 31: import javax.crypto.*; > 32: import javax.crypto.spec.*; Nit: Could you please remove the wildcard import here and from other files touched? test/jdk/javax/crypto/Cipher/GCMAPI.java line 72: > 70: updateAADPass(bb); > 71: > 72: try(Arena arena = Arena.ofConfined()) { nit: Suggestion: try (Arena arena = Arena.ofConfined()) { The same for: * `test/jdk/javax/crypto/Mac/ByteBuffers.java` * `test/jdk/javax/crypto/CipherSpi/DirectBBRemaining.java` * `test/jdk/javax/crypto/Cipher/ByteBuffers.java` * `test/jdk/java/security/MessageDigest/ByteBuffers.java` * `test/jdk/sun/security/pkcs11/Signature/ByteBuffers.java` * `test/jdk/sun/security/pkcs11/Cipher/TestPaddingOOB.java` * `test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphers.java` * `test/jdk/sun/security/pkcs11/MessageDigest/ByteBuffers.java` test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphers.java line 215: > 213: } > 214: > 215: private static void execTest(Cipher cipher, byte[]answer, nit: Suggestion: private static void execTest(Cipher cipher, byte[] answer, ------------- PR Review: https://git.openjdk.org/jdk/pull/26967#pullrequestreview-3173544064 PR Review Comment: https://git.openjdk.org/jdk/pull/26967#discussion_r2313919152 PR Review Comment: https://git.openjdk.org/jdk/pull/26967#discussion_r2313877756 PR Review Comment: https://git.openjdk.org/jdk/pull/26967#discussion_r2313872253 From myankelevich at openjdk.org Mon Sep 1 13:12:48 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 1 Sep 2025 13:12:48 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 11:41:59 GMT, Matthew Donovan wrote: >> test/jdk/javax/crypto/CipherSpi/CipherByteBufferOverwriteTest.java line 127: >> >>> 125: System.out.println("All Tests Passed"); >>> 126: } finally { >>> 127: arena.close(); >> >> Would it make sense to initialize `arena` in a try-with-resources, so you can get rid of the explicit `.close()`? > > I considered that for a while but I couldn't see a way to make it work without completely refactoring the whole test. Wouldn't it work if you pass arena as a param to the prepareBuffers. This way you can call try-with-resources for each test and get rid of `arena.close()`. Also, it's only `case MEMORY_SEGMENT:` which needs arena at all, so you can just pass null to all others and only for `test#3` // Test#3: against ByteBuffer backed by MemorySegment try (Arena arena = Arena.ofConfined()) { prepareBuffers(BufferType.MEMORY_SEGMENT, useRO, buf.length, buf, 0, PLAINTEXT_SIZE, offset, arena); runTest(offset, expectedPT, expectedCT); System.out.println("\tMEMSEGMENT: passed"); } all others will look like this `prepareBuffers(BufferType.ALLOCATE, useRO, buf.length, buf, 0, PLAINTEXT_SIZE, offset, null);`, making it a minor refactor, as this method is only used here. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26967#discussion_r2313915622 From lkorinth at openjdk.org Mon Sep 1 13:21:49 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 13:21:49 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From alanb at openjdk.org Mon Sep 1 13:55:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Sep 2025 13:55:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701 From duke at openjdk.org Mon Sep 1 15:04:43 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Mon, 1 Sep 2025 15:04:43 GMT Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java [v2] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 23:33:16 GMT, Thomas Fitzsimmons wrote: >> Thank you for reviewing. >> >>> Hmm, I find it somewhat obscure that the config variant property changes the value of the config file name. >> >> Yes, I see your point. >> >>> With this new config variant property, it assumes that the confg file name has a "." which is probably true most if not all times. >> >> The regular expression supports appending to a file without a ".": >> >> >> $ jshell -q >> jshell> "kryoptic".replaceFirst("(\.[^\.]*)?$", "-" + "sensitive" + "$1"); >> $1 ==> "kryoptic-sensitive" >> >> >> I should have added this case to the comment you mentioned above, will do in the expanded comment you requested. >> >>> We should document all these properties so it's clear their precedence as well as the assumptions/implications. All these security can be set independently, right? It's a bit strange that you set the CUSTOM_P11_CONFIG NAME and then setting the config variant property would actually changes the config file to a different name. >> >> Yes, conceptually I am treating file pairs like `p11-nss.txt` and `p11-nss-sensitive.txt` (and `p11-kryoptic.txt`, `p11-kryoptic-sensitive.txt`) as variants of the same configuration. When `CUSTOM_P11_CONFIG_VARIANT` is set, `CUSTOM_P11_CONFIG_NAME`'s meaning becomes something like "base configuration file name". >> >> Given the current test suite, and how I am specifying the use of Kryoptic, I wouldn't expect both `CUSTOM_P11_CONFIG_VARIANT` and `CUSTOM_P11_CONFIG_NAME` (or `CUSTOM_P11_CONFIG`) to be specified by the user at the same time. `CUSTOM_P11_CONFIG_VARIANT` is meant for hard-coding in tests that invoke the test VM separately in sensitive and normal modes. >> >>> Perhaps check the existence of the file and error out with the config file and its path if the check fails, this way, it's crystal clear. >> >> OK, I can do that. I will add a `/** ... */` block above `getNssConfig`. These two changes will hopefully reduce the weirdness of the `CUSTOM_P11_CONFIG_NAME`/`CUSTOM_P11_CONFIG_VARIANT` combination. I will also document the existing `CUSTOM_P11_CONFIG_NAME` versus `CUSTOM_P11_CONFIG` precedence since that might also be surprising when both are set. > > Done. See what you think. I am still open to other options. One idea I played around with was adding a `CONFIG_P11_CONFIG_BASE_NAME` that is just part of the file name, say `p11-nss` by default. Then in `getNssConfig` the file name could be built from the base and variant strings, instead of by changing the name. Conceptually that might be clearer but I think it would be a more invasive change given that the existing code deals with file names. And, having experimented with it, I think the new exception you suggested will make it fairly obvious what to fix if someone hits a missing configuration file. It occurred to me that I might be able to simplify this patch if I use the same configuration file names for `Kryoptic` configuration, but allow setting a property to override the base path "./nss" (`nssDirDestination` in `copyNssFiles`). Then the other tests wouldn't need any changes but could still run against `Kryoptic` even though they hard-code `p11-nss-sensitive.txt`. The weirdness would then be that the `Kryoptic` configuration files are not named after their provider, but this could be documented. I will try this approach tomorrow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26325#discussion_r2314185051 From coffeys at openjdk.org Mon Sep 1 15:28:35 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 1 Sep 2025 15:28:35 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v19] In-Reply-To: References: Message-ID: > The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago. > > Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. > > The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options : > > > System.err.println("help print the help messages"); > System.err.println("expand expand debugging information"); > System.err.println(); > System.err.println("all turn on all debugging"); > System.err.println("ssl turn on ssl debugging"); > System.err.println(); > System.err.println("The following can be used with ssl:"); > System.err.println("\trecord enable per-record tracing"); > System.err.println("\thandshake print each handshake message"); > System.err.println("\tkeygen print key generation data"); > System.err.println("\tsession print session activity"); > System.err.println("\tdefaultctx print default SSL initialization"); > System.err.println("\tsslctx print SSLContext tracing"); > System.err.println("\tsessioncache print session cache tracing"); > System.err.println("\tkeymanager print key manager tracing"); > System.err.println("\ttrustmanager print trust manager tracing"); > System.err.println("\tpluggability print pluggability tracing"); > System.err.println(); > System.err.println("\thandshake debugging can be widened with:"); > System.err.println("\tdata hex dump of each handshake message"); > System.err.println("\tverbose verbose handshake message printing"); > System.err.println(); > System.err.println("\trecord debugging can be widened with:"); > System.err.println("\tplaintext hex dump of record plaintext"); > System.err.println("\tpacket print raw SSL/TLS packets"); > > > as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. > > the output has changed slightly with respect to that - less verbose > > e.g. old style: > > > javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut... Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Initial review comments from Brad ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18764/files - new: https://git.openjdk.org/jdk/pull/18764/files/71aa0211..9399ee2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=17-18 Stats: 78 lines in 2 files changed: 32 ins; 34 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/18764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764 PR: https://git.openjdk.org/jdk/pull/18764 From coffeys at openjdk.org Mon Sep 1 15:28:38 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 1 Sep 2025 15:28:38 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v18] In-Reply-To: <5RqSiSYSiWKjuMAePFU-sQz_urkAc9iKT8v8FeIsybM=.0dfc9c96-b6cf-4734-9b78-b2a76adc81c5@github.com> References: <5RqSiSYSiWKjuMAePFU-sQz_urkAc9iKT8v8FeIsybM=.0dfc9c96-b6cf-4734-9b78-b2a76adc81c5@github.com> Message-ID: <1uSTwAZmeYMaK2GCXP9D9dvIACSbZZ-FzKHVmqKvMJ4=.925402dc-4fa3-44d8-b1d1-90d9e7e1318b@github.com> On Sat, 30 Aug 2025 01:17:28 GMT, Bradford Wetmore wrote: >> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: >> >> - Merge branch 'master' into 8044609-ssl >> - 1 file omitted during merge >> - Merge branch 'master' into 8044609-ssl >> - Merge branch 'master' into 8044609-ssl >> - Merge branch 'master' into 8044609-ssl >> - remove whitespace >> - erroneous edit to test file >> - remove legacy test and minor fix ups >> - Merge branch 'master' into 8044609-ssl >> - enums refactoring and line width correction >> - ... and 25 more: https://git.openjdk.org/jdk/compare/2b44ed70...71aa0211 > > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 198: > >> 196: System.err.println("all turn on all debugging"); >> 197: System.err.println("ssl turn on ssl debugging"); >> 198: System.err.println(); > > The ordering of the options seem random. Might suggest either alphabetical or by functional area (e.g. key/trustmanager together) Ordered them in alphabetical order now. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314227218 From coffeys at openjdk.org Mon Sep 1 15:31:52 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 1 Sep 2025 15:31:52 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v19] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 15:28:35 GMT, Sean Coffey wrote: >> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago. >> >> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. >> >> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options : >> >> >> System.err.println("help print the help messages"); >> System.err.println("expand expand debugging information"); >> System.err.println(); >> System.err.println("all turn on all debugging"); >> System.err.println("ssl turn on ssl debugging"); >> System.err.println(); >> System.err.println("The following can be used with ssl:"); >> System.err.println("\trecord enable per-record tracing"); >> System.err.println("\thandshake print each handshake message"); >> System.err.println("\tkeygen print key generation data"); >> System.err.println("\tsession print session activity"); >> System.err.println("\tdefaultctx print default SSL initialization"); >> System.err.println("\tsslctx print SSLContext tracing"); >> System.err.println("\tsessioncache print session cache tracing"); >> System.err.println("\tkeymanager print key manager tracing"); >> System.err.println("\ttrustmanager print trust manager tracing"); >> System.err.println("\tpluggability print pluggability tracing"); >> System.err.println(); >> System.err.println("\thandshake debugging can be widened with:"); >> System.err.println("\tdata hex dump of each handshake message"); >> System.err.println("\tverbose verbose handshake message printing"); >> System.err.println(); >> System.err.println("\trecord debugging can be widened with:"); >> System.err.println("\tplaintext hex dump of record plaintext"); >> System.err.println("\tpacket print raw SSL/TLS packets"); >> >> >> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. >> >> the output has changed slightly with respect to that - less verbose >> >> e.g. old... > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Initial review comments from Brad Thanks for initial comments Brad. I've taken them on board. The sub-component parsing logic might have been needlessly complex. I've introduced a new isSubComponent field directly to the new Opt enum. That helps query components and simplify the code, ------------- PR Review: https://git.openjdk.org/jdk/pull/18764#pullrequestreview-3174047981 From coffeys at openjdk.org Mon Sep 1 15:31:56 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 1 Sep 2025 15:31:56 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v18] In-Reply-To: <5RqSiSYSiWKjuMAePFU-sQz_urkAc9iKT8v8FeIsybM=.0dfc9c96-b6cf-4734-9b78-b2a76adc81c5@github.com> References: <5RqSiSYSiWKjuMAePFU-sQz_urkAc9iKT8v8FeIsybM=.0dfc9c96-b6cf-4734-9b78-b2a76adc81c5@github.com> Message-ID: On Sat, 30 Aug 2025 01:16:01 GMT, Bradford Wetmore wrote: >> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: >> >> - Merge branch 'master' into 8044609-ssl >> - 1 file omitted during merge >> - Merge branch 'master' into 8044609-ssl >> - Merge branch 'master' into 8044609-ssl >> - Merge branch 'master' into 8044609-ssl >> - remove whitespace >> - erroneous edit to test file >> - remove legacy test and minor fix ups >> - Merge branch 'master' into 8044609-ssl >> - enums refactoring and line width correction >> - ... and 25 more: https://git.openjdk.org/jdk/compare/2b44ed70...71aa0211 > > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 203: > >> 201: System.err.println("\thandshake print each handshake message"); >> 202: System.err.println("\tkeymanager print key manager tracing"); >> 203: System.err.println("\trecord enable per-record tracing"); > > What would you think of listing/indenting the suboptions here instead of down below? e.g. > > record enable per-record tracing > plaintext hex dump of record plaintext (widens record) > packet print raw SSL/TLS packets (widens record) > > same with `verbose` Good idea. I've gone with that approach. > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 223: > >> 221: } >> 222: >> 223: public enum Opt { > > A quick comment about the enum's purpose might be appreciated by someone new. "list of options, whether they are active..." Added some text to indicate purpose of the new enum type ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314229266 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314230004 From lkorinth at openjdk.org Mon Sep 1 16:00:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:00:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com> On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31: > >> 29: * @compile SuspendResume2.java >> 30: * @run driver jdk.test.lib.FileInstaller . . >> 31: * @run main/othervm/native/timeout=700 > > Why `700` instead of `480` in this file? I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387 From lkorinth at openjdk.org Mon Sep 1 16:09:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:09:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang wrote: >> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4). > >> while not multiplying a 10x factor with four resulting in a 40x factor. > > Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000) * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO. Because 40x is a very large timeout factor. I think I might misunderstand you in some way. My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263 From vyazici at openjdk.org Mon Sep 1 16:16:23 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 1 Sep 2025 16:16:23 GMT Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v11] In-Reply-To: References: Message-ID: > `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR replaces the `NoRepl` suffix with `NoReplacement` in method names and consistently uses `throws CCE` in method footprints. Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Fix `ClassCastException` spotted by `ReadWriteString` - Merge remote-tracking branch 'upstream/master' into jlaNoRepl - Improve Javadoc of touched `encode*()` methods - Rename `exceptionClass` to `exClass` - Rename `NoReplacement` suffix to `OrThrow` - Simplify `encodeWithEncoder` and trim long lines - Improve docs - Improve "sneaky throws" - Improve comment style - Renamed to `malformedASCII` - ... and 17 more: https://git.openjdk.org/jdk/compare/7f0cd648...a69f9fd3 ------------- Changes: https://git.openjdk.org/jdk/pull/26413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26413&range=10 Stats: 462 lines in 8 files changed: 242 ins; 122 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/26413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26413/head:pull/26413 PR: https://git.openjdk.org/jdk/pull/26413 From vyazici at openjdk.org Mon Sep 1 19:08:44 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 1 Sep 2025 19:08:44 GMT Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v4] In-Reply-To: <46MfOJA8bICEbZ7EpwzTealkJKqvsxREIKZhsyA-LRE=.295d951f-1eb7-4ad7-9e6a-3f2810c581ce@github.com> References: <46MfOJA8bICEbZ7EpwzTealkJKqvsxREIKZhsyA-LRE=.295d951f-1eb7-4ad7-9e6a-3f2810c581ce@github.com> Message-ID: On Tue, 19 Aug 2025 14:59:04 GMT, Roger Riggs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant type parameters > > It seems that the API is overloaded trying to satisfy too many requirements, replace/noreplace, throw/nothrow and supporting arbitrary Charsets. There are multiple callers that only need to create a string from byte array holding latin1. > They are burdened with catching and ignoring exceptions that do not occur. > > I'm suggesting breaking out that use case in PR#https://github.com/openjdk/jdk/pull/26831. > That leaves `Files.readString` that needs the full CharSet/noReplace/throw behavior. @RogerRiggs, @liach, @AlanBateman, I needed to push a `ClassCastException` fix in a69f9fd, which further simplified the sneaky-throws logic in `String`. Would one of you mind, unless you have objections, re-approving the PR, please? Note that I've attached passing `tier1,2` results to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3243114718 From wetmore at openjdk.org Tue Sep 2 00:29:52 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 2 Sep 2025 00:29:52 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v19] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 15:28:35 GMT, Sean Coffey wrote: >> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago. >> >> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. >> >> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options : >> >> >> System.err.println("help print the help messages"); >> System.err.println("expand expand debugging information"); >> System.err.println(); >> System.err.println("all turn on all debugging"); >> System.err.println("ssl turn on ssl debugging"); >> System.err.println(); >> System.err.println("The following can be used with ssl:"); >> System.err.println("\trecord enable per-record tracing"); >> System.err.println("\thandshake print each handshake message"); >> System.err.println("\tkeygen print key generation data"); >> System.err.println("\tsession print session activity"); >> System.err.println("\tdefaultctx print default SSL initialization"); >> System.err.println("\tsslctx print SSLContext tracing"); >> System.err.println("\tsessioncache print session cache tracing"); >> System.err.println("\tkeymanager print key manager tracing"); >> System.err.println("\ttrustmanager print trust manager tracing"); >> System.err.println("\tpluggability print pluggability tracing"); >> System.err.println(); >> System.err.println("\thandshake debugging can be widened with:"); >> System.err.println("\tdata hex dump of each handshake message"); >> System.err.println("\tverbose verbose handshake message printing"); >> System.err.println(); >> System.err.println("\trecord debugging can be widened with:"); >> System.err.println("\tplaintext hex dump of record plaintext"); >> System.err.println("\tpacket print raw SSL/TLS packets"); >> >> >> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. >> >> the output has changed slightly with respect to that - less verbose >> >> e.g. old... > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Initial review comments from Brad Next set of comments. Thanks for addressing the previous set! src/java.base/share/classes/sun/security/ssl/Alert.java line 228: > 226: public void consume(ConnectionContext context, > 227: ByteBuffer m) throws IOException { > 228: TransportContext tc = (TransportContext)context; Copyright updates throughout. I won't call out all cases, but noticed `Alert.java`, `AlpnExtension.java`, `CertificateAuthrotiesExtension.java`. Some of these may have been done in 2024 in earlier versions of this PR (sorry!), but some are earlier (2023, 2022, etc.) src/java.base/share/classes/sun/security/ssl/Alert.java line 231: > 229: > 230: AlertMessage am = new AlertMessage(tc, m); > 231: if (SSLLogger.logging && SSLLogger.isOn(SSLLogger.Opt.SSL)) { You're likely doing a line-line update, but in earlier discussions, we talked about not having `ssl` be a filter category on of its own? Did you decide not to got that route? That is, every call site should be some concrete enum value like `Opt.HANDSHAKE` and not a general `Opt.SSL`? For example: `Alert.java` and `SSLCipher.java`. This is more of a conversation starter than a request for change. There are some like the `Alert.java` sites that need to be assigned into the `Opt.HANDSHAKE` handshake category, but configuration items in `SSLCipher.java` don't fall cleanly into any existing category. We could have a config category, but maybe it is better to just leave as `ssl`? > ./Alert.java > ./DTLSInputRecord.java > ./DTLSOutputRecord.java > ./HandshakeOutStream.java > ./KeyUpdate.java > ./NamedGroup.java > ./OutputRecord.java > ./SessionTicketExtension.java > ./SSLCipher.java > ./SSLEngineImpl.java > ./SSLEngineOutputRecord.java > ./SSLSessionContextImpl.java > ./SSLSocketImpl.java > ./SSLSocketOutputRecord.java > ./SSLTransport.java > ./TransportContext.java > ./Utilities.java > ./X509Authentication.java Thoughts? src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 815: > 813: hc.peerRequestedSignatureSchemes, // a CertificateVerify message later > 814: ka, hc.negotiatedProtocol) != null > 815: || SSLLogger.logWarning(SSLLogger.Opt.HANDSHAKE, <=80. Would you mind tweaking the area around this too? Thanks! src/java.base/share/classes/sun/security/ssl/ClientHello.java line 434: > 432: session = null; > 433: if (SSLLogger.logging && > 434: SSLLogger.isOn(SSLLogger.Opt.HANDSHAKE_VERBOSE)) { Not your fault, but I'm not sure I like this as a verbose message. src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 79: > 77: help(); > 78: } > 79: logger = new SSLConsoleLogger("javax.net.ssl", p); Would you mind adding a comment that this takes care of the `expand` keyword, as all of the other options are processed in the new way? Thanks. src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 128: > 126: // javax.net.debug would be misconfigured property with respect > 127: // to logging if value didn't contain "all" or "ssl" > 128: logging = Opt.ALL.on || Opt.SSL.on; I don't have a strong feeling about this either way, but a usage question here. If they have specified some args but not `ssl`. e.g. -Djavax.net.debug=trustmanager,keymanager Should we: 1. quietly ignore as this is are doing 2. output a single log message saying logging is disabled. 3. a fatal error src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 210: > 208: System.err.println("\tdefaultctx print default SSL initialization"); > 209: System.err.println("\thandshake print each handshake message"); > 210: System.err.println("\t verbose verbose handshake" + This line in particular is lining up pretty ragged in the actual output. Even in the github editor, it looks off due to the variable width fonts. Maybe we can use tabs to help? e.g. the current: handshake print each handshake message verbose verbose handshake message printing (widens handshake) keymanager print key manager tracing record enable per-record tracing plaintext hex dump of record plaintext (widens record) packet print raw SSL/TLS packets (widens record) vs. System.err.println("\tdefaultctx\tprint default SSL initialization"); System.err.println("\thandshake\tprint each handshake message"); System.err.println("\t\tverbose\tverbose handshake" + " message printing (widens handshake)"); src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 216: > 214: System.err.println("\t plaintext hex dump of record" + > 215: " plaintext (widens record)"); > 216: System.err.println("\t packet print raw SSL/TLS" + Order `packet` before `plaintext`? ------------- PR Review: https://git.openjdk.org/jdk/pull/18764#pullrequestreview-3174518962 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314657243 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314658104 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314681552 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314684540 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314607893 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314601805 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314622404 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2314609182 From lkorinth at openjdk.org Tue Sep 2 07:29:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 07:29:57 GMT Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... This pull request has now been integrated. Changeset: 55e7af05 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1 Stats: 901 lines in 342 files changed: 51 ins; 91 del; 759 mod 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Reviewed-by: alanb, sspitsyn, lmesnik, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26749 From mdonovan at openjdk.org Tue Sep 2 11:20:53 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 2 Sep 2025 11:20:53 GMT Subject: Integrated: 8325766: Extend CertificateBuilder to create trust and end entity certificates programmatically In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: 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) This pull request has now been integrated. Changeset: 31847149 Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/31847149c1956b23c19a99309982660b4bbdd2d6 Stats: 771 lines in 3 files changed: 163 ins; 565 del; 43 mod 8325766: Extend CertificateBuilder to create trust and end entity certificates programmatically Reviewed-by: mullan, abarashev ------------- PR: https://git.openjdk.org/jdk/pull/23700 From alanb at openjdk.org Tue Sep 2 11:43:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Sep 2025 11:43:48 GMT Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v11] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 16:16:23 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR replaces the `NoRepl` suffix with `NoReplacement` in method names and consistently uses `throws CCE` in method footprints. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Fix `ClassCastException` spotted by `ReadWriteString` > - Merge remote-tracking branch 'upstream/master' into jlaNoRepl > - Improve Javadoc of touched `encode*()` methods > - Rename `exceptionClass` to `exClass` > - Rename `NoReplacement` suffix to `OrThrow` > - Simplify `encodeWithEncoder` and trim long lines > - Improve docs > - Improve "sneaky throws" > - Improve comment style > - Renamed to `malformedASCII` > - ... and 17 more: https://git.openjdk.org/jdk/compare/7f0cd648...a69f9fd3 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26413#pullrequestreview-3176161682 From mdonovan at openjdk.org Tue Sep 2 12:38:57 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 2 Sep 2025 12:38:57 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments [v2] In-Reply-To: References: Message-ID: > This PR extends security tests to use ByteBuffers backed by MemorySegments. Tests in the areas of Signature, Cipher, MessageDigest, and Mac are updated. Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - addressed PR comments and refactored to use try-with-resources - Merge branch 'master' into cipher-ffm - 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments ------------- Changes: https://git.openjdk.org/jdk/pull/26967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26967&range=01 Stats: 507 lines in 14 files changed: 229 ins; 62 del; 216 mod Patch: https://git.openjdk.org/jdk/pull/26967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26967/head:pull/26967 PR: https://git.openjdk.org/jdk/pull/26967 From vyazici at openjdk.org Tue Sep 2 12:46:02 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 12:46:02 GMT Subject: Integrated: 8356439: Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici wrote: > `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR replaces the `NoRepl` suffix with `NoReplacement` in method names and consistently uses `throws CCE` in method footprints. This pull request has now been integrated. Changeset: eea50fbc Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/eea50fbc1b24710b18eff4b59dc90dee3736cd95 Stats: 462 lines in 8 files changed: 242 ins; 122 del; 98 mod 8356439: Rename JavaLangAccess::*NoRepl methods Reviewed-by: alanb, liach, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/26413 From vyazici at openjdk.org Tue Sep 2 13:17:03 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 13:17:03 GMT Subject: RFR: 8356439: Backout recent JavaLangAccess changes breaking the build Message-ID: Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. ------------- Commit messages: - Revert "8356439: Rename JavaLangAccess::*NoRepl methods" Changes: https://git.openjdk.org/jdk/pull/27050/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27050&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356439 Stats: 462 lines in 8 files changed: 122 ins; 242 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/27050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27050/head:pull/27050 PR: https://git.openjdk.org/jdk/pull/27050 From jpai at openjdk.org Tue Sep 2 13:50:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 13:50:43 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. I've verified that this is a clean "git revert" of the original eea50fbc1b24710b18eff4b59dc90dee3736cd95 commit. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176660366 From serb at openjdk.org Tue Sep 2 14:08:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 Sep 2025 14:08:48 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176741003 From alanb at openjdk.org Tue Sep 2 14:11:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Sep 2025 14:11:41 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176750059 From coffeys at openjdk.org Tue Sep 2 14:27:20 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 2 Sep 2025 14:27:20 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v20] In-Reply-To: References: Message-ID: > The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago. > > Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. > > The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options : > > > System.err.println("help print the help messages"); > System.err.println("expand expand debugging information"); > System.err.println(); > System.err.println("all turn on all debugging"); > System.err.println("ssl turn on ssl debugging"); > System.err.println(); > System.err.println("The following can be used with ssl:"); > System.err.println("\trecord enable per-record tracing"); > System.err.println("\thandshake print each handshake message"); > System.err.println("\tkeygen print key generation data"); > System.err.println("\tsession print session activity"); > System.err.println("\tdefaultctx print default SSL initialization"); > System.err.println("\tsslctx print SSLContext tracing"); > System.err.println("\tsessioncache print session cache tracing"); > System.err.println("\tkeymanager print key manager tracing"); > System.err.println("\ttrustmanager print trust manager tracing"); > System.err.println("\tpluggability print pluggability tracing"); > System.err.println(); > System.err.println("\thandshake debugging can be widened with:"); > System.err.println("\tdata hex dump of each handshake message"); > System.err.println("\tverbose verbose handshake message printing"); > System.err.println(); > System.err.println("\trecord debugging can be widened with:"); > System.err.println("\tplaintext hex dump of record plaintext"); > System.err.println("\tpacket print raw SSL/TLS packets"); > > > as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. > > the output has changed slightly with respect to that - less verbose > > e.g. old style: > > > javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut... Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Further review comments, copyright years also ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18764/files - new: https://git.openjdk.org/jdk/pull/18764/files/9399ee2c..ba4b1b26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=18-19 Stats: 93 lines in 48 files changed: 17 ins; 1 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/18764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764 PR: https://git.openjdk.org/jdk/pull/18764 From coffeys at openjdk.org Tue Sep 2 14:33:50 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 2 Sep 2025 14:33:50 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v20] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 14:27:20 GMT, Sean Coffey wrote: >> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago. >> >> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. >> >> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options : >> >> >> System.err.println("help print the help messages"); >> System.err.println("expand expand debugging information"); >> System.err.println(); >> System.err.println("all turn on all debugging"); >> System.err.println("ssl turn on ssl debugging"); >> System.err.println(); >> System.err.println("The following can be used with ssl:"); >> System.err.println("\trecord enable per-record tracing"); >> System.err.println("\thandshake print each handshake message"); >> System.err.println("\tkeygen print key generation data"); >> System.err.println("\tsession print session activity"); >> System.err.println("\tdefaultctx print default SSL initialization"); >> System.err.println("\tsslctx print SSLContext tracing"); >> System.err.println("\tsessioncache print session cache tracing"); >> System.err.println("\tkeymanager print key manager tracing"); >> System.err.println("\ttrustmanager print trust manager tracing"); >> System.err.println("\tpluggability print pluggability tracing"); >> System.err.println(); >> System.err.println("\thandshake debugging can be widened with:"); >> System.err.println("\tdata hex dump of each handshake message"); >> System.err.println("\tverbose verbose handshake message printing"); >> System.err.println(); >> System.err.println("\trecord debugging can be widened with:"); >> System.err.println("\tplaintext hex dump of record plaintext"); >> System.err.println("\tpacket print raw SSL/TLS packets"); >> >> >> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. >> >> the output has changed slightly with respect to that - less verbose >> >> e.g. old... > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Further review comments, copyright years also Thanks again for the review comments Brad. I've made comments and corrections where raised. New changes pushed. ------------- PR Review: https://git.openjdk.org/jdk/pull/18764#pullrequestreview-3176028041 From coffeys at openjdk.org Tue Sep 2 14:33:55 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 2 Sep 2025 14:33:55 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v19] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 23:33:43 GMT, Bradford Wetmore wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Initial review comments from Brad > > src/java.base/share/classes/sun/security/ssl/Alert.java line 228: > >> 226: public void consume(ConnectionContext context, >> 227: ByteBuffer m) throws IOException { >> 228: TransportContext tc = (TransportContext)context; > > Copyright updates throughout. > > I won't call out all cases, but noticed `Alert.java`, `AlpnExtension.java`, `CertificateAuthrotiesExtension.java`. Some of these may have been done in 2024 in earlier versions of this PR (sorry!), but some are earlier (2023, 2022, etc.) Scanned all updated files - I think I should have them all with 2025 now. > src/java.base/share/classes/sun/security/ssl/Alert.java line 231: > >> 229: >> 230: AlertMessage am = new AlertMessage(tc, m); >> 231: if (SSLLogger.logging && SSLLogger.isOn(SSLLogger.Opt.SSL)) { > > You're likely doing a line-line update, but in earlier discussions, we talked about not having `ssl` be a filter category on of its own? Did you decide not to got that route? > > That is, every call site should be some concrete enum value like `Opt.HANDSHAKE` and not a general `Opt.SSL`? For example: `Alert.java` and `SSLCipher.java`. > > This is more of a conversation starter than a request for change. > > There are some like the `Alert.java` sites that need to be assigned into the `Opt.HANDSHAKE` handshake category, but configuration items in `SSLCipher.java` don't fall cleanly into any existing category. We could have a config category, but maybe it is better to just leave as `ssl`? > >> ./Alert.java >> ./DTLSInputRecord.java >> ./DTLSOutputRecord.java >> ./HandshakeOutStream.java >> ./KeyUpdate.java >> ./NamedGroup.java >> ./OutputRecord.java >> ./SessionTicketExtension.java >> ./SSLCipher.java >> ./SSLEngineImpl.java >> ./SSLEngineOutputRecord.java >> ./SSLSessionContextImpl.java >> ./SSLSocketImpl.java >> ./SSLSocketOutputRecord.java >> ./SSLTransport.java >> ./TransportContext.java >> ./Utilities.java >> ./X509Authentication.java > > > Thoughts? Yes - For the refactoring of the component values in calling code, I pretty much stuck to what was already there. I think allowing code to call via the Opt.SSL value is ok - some TLS code is generic to all components. *like TLS configuration data perhaps) Yes - some calls probably deserve to be tidied off to a specific filter value - probably best for a follow on JBS issue. > src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 815: > >> 813: hc.peerRequestedSignatureSchemes, // a CertificateVerify message later >> 814: ka, hc.negotiatedProtocol) != null >> 815: || SSLLogger.logWarning(SSLLogger.Opt.HANDSHAKE, > > <=80. > > Would you mind tweaking the area around this too? Thanks! done > src/java.base/share/classes/sun/security/ssl/ClientHello.java line 434: > >> 432: session = null; >> 433: if (SSLLogger.logging && >> 434: SSLLogger.isOn(SSLLogger.Opt.HANDSHAKE_VERBOSE)) { > > Not your fault, but I'm not sure I like this as a verbose message. In agreement. This sort of message strikes me as more in the `HANDSHAKE `category Will I log a follow on JBS issue to have all call sites of `Opt `examined ? > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 79: > >> 77: help(); >> 78: } >> 79: logger = new SSLConsoleLogger("javax.net.ssl", p); > > Would you mind adding a comment that this takes care of the `expand` keyword, as all of the other options are processed in the new way? Thanks. I've added a comment and tweaked the code here. We can pass boolean in SSLConsoleLogger constructor call > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 128: > >> 126: // javax.net.debug would be misconfigured property with respect >> 127: // to logging if value didn't contain "all" or "ssl" >> 128: logging = Opt.ALL.on || Opt.SSL.on; > > I don't have a strong feeling about this either way, but a usage question here. > > If they have specified some args but not `ssl`. e.g. > > -Djavax.net.debug=trustmanager,keymanager > > Should we: > > 1. quietly ignore as this is are doing > 2. output a single log message saying logging is disabled. > 3. a fatal error I'm leaning towards option 1. no logging gets enabled in misconfigured values. I've test code covering this scenario. option 2 might be useful and if there's a strong desire for that, perhaps we can alter in follow on JDK issue. option 3 sounds a bit heavy handed, Don't think we need to have a fatal error. Also, since the load time for loading SSLLogger is variable, it could be dangerous (e.g. app runs fine for 1st 10 mins and then trigger an error etc) > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 210: > >> 208: System.err.println("\tdefaultctx print default SSL initialization"); >> 209: System.err.println("\thandshake print each handshake message"); >> 210: System.err.println("\t verbose verbose handshake" + > > This line in particular is lining up pretty ragged in the actual output. Even in the github editor, it looks off due to the variable width fonts. Maybe we can use tabs to help? e.g. the current: > > handshake print each handshake message > verbose verbose handshake message printing (widens handshake) > keymanager print key manager tracing > record enable per-record tracing > plaintext hex dump of record plaintext (widens record) > packet print raw SSL/TLS packets (widens record) > > vs. > > System.err.println("\tdefaultctx\tprint default SSL initialization"); > System.err.println("\thandshake\tprint each handshake message"); > System.err.println("\t\tverbose\tverbose handshake" + > " message printing (widens handshake)"); Fair point. the tab approach crossed my mind yesterday but I stuck with original design. Just tried with tabs but it was quite ugly (too many spaces) - I've used the printf functionality. how does this look ? help print this help message and exit expand expanded (less compact) output format all turn on all debugging ssl turn on ssl debugging The following filters can be used with ssl: defaultctx print default SSL initialization handshake print each handshake message verbose -verbose handshake message printing (widens handshake) keymanager print key manager tracing record enable per-record tracing packet -print raw SSL/TLS packets (widens record) plaintext -hex dump of record plaintext (widens record) respmgr print OCSP response tracing session print session activity sessioncache print session cache tracing sslctx print SSLContext tracing trustmanager print trust manager tracing > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 216: > >> 214: System.err.println("\t plaintext hex dump of record" + >> 215: " plaintext (widens record)"); >> 216: System.err.println("\t packet print raw SSL/TLS" + > > Order `packet` before `plaintext`? fixed. thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2316095683 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2316093383 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2316110651 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2316277275 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2315725718 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2315735365 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2316085193 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2316086202 From syan at openjdk.org Tue Sep 2 14:34:41 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 14:34:41 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176850369 From rriggs at openjdk.org Tue Sep 2 14:58:42 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 2 Sep 2025 14:58:42 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176950881 From jwaters at openjdk.org Tue Sep 2 15:06:42 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 2 Sep 2025 15:06:42 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: <_JgH1bMAGxiue2ou0w7d57FsUzMu8c2XkfXOtESeZb8=.68d0423b-a0a0-4ea0-ae82-b8c9a4f81c11@github.com> On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Please get this in as soon as possible. ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176979619 From wxiao at openjdk.org Tue Sep 2 15:22:58 2025 From: wxiao at openjdk.org (Weibing Xiao) Date: Tue, 2 Sep 2025 15:22:58 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v2] In-Reply-To: References: Message-ID: > [webrev.zip](https://github.com/user-attachments/files/21517501/webrev.zip) > NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory. > > When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message and SaslOuput Stream is writing the content of the buffer; and at the time GSSContext is disposed and it is null. That's the reason to throw NPE. > > 1) Check if the context is null or not; then wrap the NPE. The change is done in GssKrb5Base.java > > No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached webrev for the reference. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: close open resource in LDAP client ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26566/files - new: https://git.openjdk.org/jdk/pull/26566/files/08528972..666dfe0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26566&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26566&range=00-01 Stats: 49 lines in 4 files changed: 21 ins; 8 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/26566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26566/head:pull/26566 PR: https://git.openjdk.org/jdk/pull/26566 From mdonovan at openjdk.org Tue Sep 2 15:23:09 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 2 Sep 2025 15:23:09 GMT Subject: RFR: 8360882: Tests throw SkippedException when they should fail [v5] In-Reply-To: <7V3ntm_1Bm823DmTwJt9rcUFZnrbqAc-DuVGoFR6_Gk=.dff492db-be0f-4332-848b-badcc7b921f6@github.com> References: <7V3ntm_1Bm823DmTwJt9rcUFZnrbqAc-DuVGoFR6_Gk=.dff492db-be0f-4332-848b-badcc7b921f6@github.com> Message-ID: > This PR updates `ArtifactResolver.fetchOne()` to throw an IOException instead of SkippedException. This allows tests to determine of a missing "artifact" should be treated as a failed or skipped test.`OpensslArtifactFetcher` is also updated to only throw SkippedException if OpenSSL is not available on the test platform. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: fixed whitespace error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26868/files - new: https://git.openjdk.org/jdk/pull/26868/files/d2d134b4..71eef8e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26868&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26868&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26868.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26868/head:pull/26868 PR: https://git.openjdk.org/jdk/pull/26868 From wxiao at openjdk.org Tue Sep 2 15:22:59 2025 From: wxiao at openjdk.org (Weibing Xiao) Date: Tue, 2 Sep 2025 15:22:59 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 20:20:33 GMT, Weibing Xiao wrote: > [webrev.zip](https://github.com/user-attachments/files/21517501/webrev.zip) > NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory. > > When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message and SaslOuput Stream is writing the content of the buffer; and at the time GSSContext is disposed and it is null. That's the reason to throw NPE. > > 1) Check if the context is null or not; then wrap the NPE. The change is done in GssKrb5Base.java > > No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached webrev for the reference. Let LDAP client implementation to close the the resource associated with Connection. It allows SASL client to handle failure message. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3245794515 From wxiao at openjdk.org Tue Sep 2 15:28:00 2025 From: wxiao at openjdk.org (Weibing Xiao) Date: Tue, 2 Sep 2025 15:28:00 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: Message-ID: > [webrev.zip](https://github.com/user-attachments/files/21517501/webrev.zip) > NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory. > > When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message and SaslOuput Stream is writing the content of the buffer; and at the time GSSContext is disposed and it is null. That's the reason to throw NPE. > > 1) Check if the context is null or not; then wrap the NPE. The change is done in GssKrb5Base.java > > No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached webrev for the reference. Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision: - remove unused code - removed the commented out code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26566/files - new: https://git.openjdk.org/jdk/pull/26566/files/666dfe0a..dd21da3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26566&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26566&range=01-02 Stats: 20 lines in 2 files changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26566/head:pull/26566 PR: https://git.openjdk.org/jdk/pull/26566 From vyazici at openjdk.org Tue Sep 2 15:29:52 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 15:29:52 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: <8Tf_P9myzruQetqPKRfcN1u4wj1_9b3J--k08F6JKbg=.5a08e454-15c0-4413-ae5f-7ae577b64732@github.com> On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. `tier1` passes on several platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27050#issuecomment-3245815752 From vyazici at openjdk.org Tue Sep 2 15:29:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 15:29:53 GMT Subject: Integrated: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. This pull request has now been integrated. Changeset: ecf05ca5 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/ecf05ca541b32736ab8e8a38d4be4f037a56361d Stats: 462 lines in 8 files changed: 122 ins; 242 del; 98 mod 8366693: Backout recent JavaLangAccess changes breaking the build Reviewed-by: jpai, serb, alanb, syan, rriggs, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/27050 From naoto at openjdk.org Tue Sep 2 16:29:32 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 16:29:32 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: References: Message-ID: > Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Refining comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26973/files - new: https://git.openjdk.org/jdk/pull/26973/files/f79c5a08..ff7e9e0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=03-04 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26973.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26973/head:pull/26973 PR: https://git.openjdk.org/jdk/pull/26973 From naoto at openjdk.org Tue Sep 2 16:29:32 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 16:29:32 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v2] In-Reply-To: <_W1WPjGtzVggv4acbIwM0uK4YUC_t_VpobbTy82Eyyk=.7da6e0d9-a746-429b-aac9-361ab5cf7778@github.com> References: <_W1WPjGtzVggv4acbIwM0uK4YUC_t_VpobbTy82Eyyk=.7da6e0d9-a746-429b-aac9-361ab5cf7778@github.com> Message-ID: On Sat, 30 Aug 2025 05:51:15 GMT, Stuart Marks wrote: > It would be good to add comments that describes this precondition. Good point. Explained it in its comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2316599042 From weijun at openjdk.org Tue Sep 2 16:54:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 2 Sep 2025 16:54:18 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v41] In-Reply-To: References: Message-ID: > Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. > > image Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: cannot reset with withMethods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18411/files - new: https://git.openjdk.org/jdk/pull/18411/files/bdd00bd8..cef55578 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=40 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=39-40 Stats: 166 lines in 3 files changed: 66 ins; 72 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/18411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 PR: https://git.openjdk.org/jdk/pull/18411 From weijun at openjdk.org Tue Sep 2 17:06:50 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 2 Sep 2025 17:06:50 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v41] In-Reply-To: References: Message-ID: <6X0yTDTtiqFsDrBW0tIcdAhq8zRXK6psy-gfHlH2PNE=.fb7a392e-b677-4511-a216-280b07792b99@github.com> On Tue, 2 Sep 2025 16:54:18 GMT, Weijun Wang wrote: >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >> >> image > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > cannot reset with withMethods New commit pushed. The `with` methods can no longer be used to "reset" a field to its default value, for example, calling `withInfo(new byte[0])` to remove the non-default info or `withAuthKey(null)` to revert to `mode_base`. Reasons: 1. Allowing a default value might hide unintended empty user input. 2. It's hard to manage all the fields in an `HPKEParameterSpec` object and reuse it back and forth. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18411#issuecomment-3246128017 From valeriep at openjdk.org Tue Sep 2 19:57:44 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 2 Sep 2025 19:57:44 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: <0YyRaglid6jYE9Bn6POjjLl9BJbkMjACGsSDFav3GEM=.e911613f-3c39-4827-b3cc-009c26bc27a9@github.com> On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 88: > 86: * > 87: * id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} > 88: * nit: instead of repeating all this here, maybe refer to sun.security.util.PBKDF2Parameters class for PBKDF2 related ASN.1 definition? src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 36: > 34: /** > 35: * This class implements the parameter set used with password-based > 36: * key derivation function 2 (PBKDF2), which is defined in PKCS#5 as follows: nit: add link to RFC 8018 here for reference ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317024083 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317021620 From valeriep at openjdk.org Tue Sep 2 20:14:44 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 2 Sep 2025 20:14:44 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 96: > 94: > 95: private static final ObjectIdentifier pkcs5PBKDF2_OID = > 96: ObjectIdentifier.of(KnownOIDs.PBKDF2WithHmacSHA1); nit: duplicated to the one defined in sun.security.util.PBKDF2Parameters class? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317056896 From valeriep at openjdk.org Tue Sep 2 20:20:46 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 2 Sep 2025 20:20:46 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: <79L5Ez8oWKsexcq0DyZWssP9TORN8sRpvs1LHPDR87A=.8289ea6f-012c-4c49-aaf7-f20d43173b4f@github.com> On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 67: > 65: * id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} > 66: */ > 67: public class PBKDF2Parameters { nit: can be marked final? src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 72: > 70: ObjectIdentifier.of(KnownOIDs.PBKDF2WithHmacSHA1); > 71: > 72: // AlgorithmIdentifier nit: comment doesn't seem related or useful? Maybe remove? src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 77: > 75: private byte[] salt = null; > 76: > 77: private int iterationCount = 0; nit: order the fields matching the ASN.1 definition? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317061330 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317065629 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317067786 From weijun at openjdk.org Tue Sep 2 21:33:09 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 2 Sep 2025 21:33:09 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v42] In-Reply-To: References: Message-ID: > Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. > image Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: about transformation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18411/files - new: https://git.openjdk.org/jdk/pull/18411/files/cef55578..a6949f51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=41 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=40-41 Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 PR: https://git.openjdk.org/jdk/pull/18411 From valeriep at openjdk.org Tue Sep 2 22:03:43 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 2 Sep 2025 22:03:43 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 156: > 154: DerValue kdf = pBMAC1_params.data.getDerValue(); > 155: var kdfParams = new PBKDF2Parameters(); > 156: String kdfAlgo = kdfParams.init(kdf); Hmm, it's somewhat obscure to return the prf algorithm as the result of `PBKDF2Parameters.init(...) `call. Is there a reason for a separate `init(...)` call? How about just `PBKDF2Parameters(kdf)` and retrieve the `prfAlgo` (instead of the "kdfAlgo" name) separately just like `salt`, `iCount` and `keyLength`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317262720 From valeriep at openjdk.org Tue Sep 2 22:06:44 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 2 Sep 2025 22:06:44 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 165: > 163: throw new IOException("PBMAC1 parameter parsing " > 164: + "error: missing keyLength field"); > 165: } Isn't this a PKCS#12 restriction? If so, this should be moved to PKCS12KeyStore class? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317268166 From valeriep at openjdk.org Tue Sep 2 22:15:45 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 2 Sep 2025 22:15:45 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 73: > 71: > 72: // AlgorithmIdentifier > 73: private String prf = null; Set the default value to "HmacSHA1" here instead of when parsing the DER encoding? src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 81: > 79: // the pseudorandom function (default is HmacSHA1) > 80: private ObjectIdentifier kdfAlgo_OID = > 81: ObjectIdentifier.of(KnownOIDs.HmacSHA1); This field is not really used? This can just be a local variable when parsing the DER encoding. src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 142: > 140: } else { > 141: kdfAlgo = "HmacSHA1"; > 142: } Can be removed if setting the `prf` default value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317284964 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317283305 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317286039 From duke at openjdk.org Wed Sep 3 00:22:16 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Wed, 3 Sep 2025 00:22:16 GMT Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java [v3] In-Reply-To: References: Message-ID: <0XADRuvWc-HhIE4exZUSxniPKI9zwGMD_bkcFWv-Tns=.02e3a87f-1dff-4071-9ab5-11a729fbf9ba@github.com> > This patch adds configurability to `PKCS11Test.java`. > > Specifically, it adds two new system properties: > > - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the `nss_library` field. Prior to this patch, `nss_library` was set to either `"softokn3"` or `"nss3"`. > > - `CUSTOM_P11_CONFIG_VARIANT`: Abstract the configuration file type to load. Prior to this patch, test cases that wanted to run `NSS` in sensitive mode would hard-code `p11-nss-sensitive.txt` on their command lines. > > The patch updates the three `p11-nss-sensitive.txt`-using test cases to use the new `CUSTOM_P11_CONFIG_VARIANT` property: > > > test/jdk/java/security/KeyAgreement/Generic.java > test/jdk/sun/security/pkcs11/Mac/TestLargeSecretKeys.java > test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java > > > I have been using this change to run `PKCS11Test.java` against the [Kryoptic](https://github.com/latchset/kryoptic) PKCS11 soft token, using this invocation: > > > make test \ > JTREG="JAVA_OPTIONS=-DCUSTOM_P11_CONFIG=/tmp/kryoptic-configuration/p11-kryoptic.txt \ > -DCUSTOM_P11_LIBRARY_NAME=kryoptic_pkcs11 \ > -Djdk.test.lib.artifacts.nsslib-linux_x64=/tmp/kryoptic-configuration \ > -DCUSTOM_DB_DIR=/tmp/kryoptic-configuration" > > > `/tmp/kryoptic-configuration` contains (among other files): > > > libkryoptic_pkcs11.so > p11-kryoptic.txt > p11-kryoptic-sensitive.txt > > > With `CUSTOM_P11_LIBRARY_NAME` set, `PKCS11Test.java` can find `libkryoptic_pkcs11.so`. > > And setting `CUSTOM_P11_CONFIG` causes the sensitive tests to use `p11-kryoptic-sensitive.txt` via the new `CUSTOM_P11_CONFIG_VARIANT` property. > > On my `Fedora 42` `x86-64` machine, I tested for regressions with: > > $ time make test JOBS=4 JTREG="JAVA_OPTIONS=-Djdk.test.lib.artifacts.nsslib-linux_x64=/usr/lib64" TEST="test/jdk/sun/security/pkcs11" > > and: > > $ time make test JOBS=4 TEST="test/jdk/sun/security/pkcs11" Thomas Fitzsimmons has updated the pull request incrementally with one additional commit since the last revision: Remove CUSTOM_P11_CONFIG_VARIANT, add CUSTOM_P11_BASE_DIR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26325/files - new: https://git.openjdk.org/jdk/pull/26325/files/621a35f3..423962fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26325&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26325&range=01-02 Stats: 75 lines in 4 files changed: 14 ins; 34 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/26325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26325/head:pull/26325 PR: https://git.openjdk.org/jdk/pull/26325 From valeriep at openjdk.org Wed Sep 3 01:24:51 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 3 Sep 2025 01:24:51 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: <10im5FEusSPtz4j4XV9MlIn3MnBI0emGj7iPnLSq51c=.79e0a0f9-53da-4ad9-8633-86b871fd4380@github.com> On Fri, 11 Jul 2025 19:53:41 GMT, Mark Powers wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 146: >> >>> 144: } >>> 145: ObjectIdentifier OID = Info[1].data.getOID(); >>> 146: KnownOIDs o = KnownOIDs.findMatch(OID.toString()); >> >> nit: indentation seems off? > > fixed The indentation still doesn't look right... Line 139 should align with line 138? Same goes for line 140-150. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2317535622 From duke at openjdk.org Wed Sep 3 14:55:47 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Wed, 3 Sep 2025 14:55:47 GMT Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java [v3] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 02:13:17 GMT, Valerie Peng wrote: >> test/jdk/sun/security/pkcs11/PKCS11Test.java line 490: >> >>> 488: configFilePath = configFilePath.replaceFirst( >>> 489: "(\\.[^\\.]*)?$", "-" + customConfigVariant + "$1"); >>> 490: } >> >> Hmm, I find it somewhat obscure that the config variant property changes the value of the config file name. With this new config variant property, it assumes that the confg file name has a "." which is probably true most if not all times. We should document all these properties so it's clear their precedence as well as the assumptions/implications. >> All these security can be set independently, right? It's a bit strange that you set the CUSTOM_P11_CONFIG NAME and then setting the config variant property would actually changes the config file to a different name. > > Perhaps check the existence of the file and error out with the config file and its path if the check fails, this way, it's crystal clear. @valeriepeng I simplified the approach; let me know what you think. I confirmed I can still configure Kryoptic as needed, though I have to name the `Kryoptic` configuration files `nss/p11-nss.txt` and `nss/p11-nss-sensitive.txt`, which is a little strange. However this has the advantage of eliminating the need to change any test case arguments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26325#discussion_r2319246269 From weijun at openjdk.org Wed Sep 3 18:30:44 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 3 Sep 2025 18:30:44 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Is it possible to hide all those real/fake algorithm name/salt/iteration concepts inside `MacData` without introducing `getKdfHmac`, `getExtraSalt` and `getExtraIterations`? I hope `PKCS12KeyStore` needn't know these details. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24429#issuecomment-3250309600 From valeriep at openjdk.org Wed Sep 3 18:58:44 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 3 Sep 2025 18:58:44 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 12:52:37 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Applied javadoc changes to getInstance(String) method and made the impl >> to match the javadoc > > test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java line 91: > >> 89: System.out.println("Expected transformation: " + transformation); >> 90: } >> 91: } catch (NoSuchAlgorithmException | NoSuchPaddingException e) { > > I think it would be good to enhance this test to distinguish between the expected exceptions for each transformation. Well, which exception is thrown depends on which provider is used and how it registers its implementations. Pinpointing the exact Exception would require running the test against a specific provider which we know how the implementations are registered. Without tying the test to a specific provider, existing transformations in this test may lead to either NSAE or NSPE, thus I just add NSPE to the catch clause. I can add more transformations which would lead to only NSAE assuming this is what you want to see? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2319901498 From mullan at openjdk.org Wed Sep 3 19:27:43 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 3 Sep 2025 19:27:43 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v6] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 18:55:57 GMT, Valerie Peng wrote: >> test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java line 91: >> >>> 89: System.out.println("Expected transformation: " + transformation); >>> 90: } >>> 91: } catch (NoSuchAlgorithmException | NoSuchPaddingException e) { >> >> I think it would be good to enhance this test to distinguish between the expected exceptions for each transformation. > > Well, which exception is thrown depends on which provider is used and how it registers its implementations. Pinpointing the exact Exception would require running the test against a specific provider which we know how the implementations are registered. Without tying the test to a specific provider, existing transformations in this test may lead to either NSAE or NSPE, thus I just add NSPE to the catch clause. I can add more transformations which would lead to only NSAE assuming this is what you want to see? I think it is ok to assume the JDK provider configuration has not been changed. Wouldn't "ChaCha20/None/PKCS5Padding" and ""ChaCha20-Poly1305/None/PKCS5Padding"" always throw `NoSuchPaddingException`, assuming the current JDK configuration is not changed? Maybe instead of passing a boolean expected parameter, you could pass the expected Exception, or null if none expected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2319968739 From mdonovan at openjdk.org Wed Sep 3 19:35:27 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 3 Sep 2025 19:35:27 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms [v3] In-Reply-To: References: Message-ID: > In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read. Matthew Donovan 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: - I removed signature algorithms output because the information is created during TLS handshake - Merge branch 'master' into secsettings - removed unused import, updated tools/launcher/Settings.java test - Merge branch 'master' into secsettings - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24424/files - new: https://git.openjdk.org/jdk/pull/24424/files/b695a812..1e21e080 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24424&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24424&range=01-02 Stats: 65854 lines in 2051 files changed: 41068 ins; 17103 del; 7683 mod Patch: https://git.openjdk.org/jdk/pull/24424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24424/head:pull/24424 PR: https://git.openjdk.org/jdk/pull/24424 From mullan at openjdk.org Wed Sep 3 19:49:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 3 Sep 2025 19:49:50 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v9] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Sat, 16 Aug 2025 00:46:13 GMT, Valerie Peng wrote: >> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s). >> >> A few implementation notes: >> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services. >> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints. >> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. >> >> CSR will be filed once the review is wrapping up. >> >> Thanks~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments from Tony and Artur. src/java.base/share/conf/security/java.security line 817: > 815: # Example: > 816: # jdk.crypto.disabledAlgorithms=Cipher.RSA/ECB/PKCS1Padding, MessageDigest.MD2 > 817: Please add 2 more lines here, like other properties such as `jdk.security.provider.preferred` that have no default values: # # jdk.crypto.disabledAlgorithms= ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2320011925 From mullan at openjdk.org Wed Sep 3 20:00:48 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 3 Sep 2025 20:00:48 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v9] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Sat, 16 Aug 2025 00:46:13 GMT, Valerie Peng wrote: >> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s). >> >> A few implementation notes: >> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services. >> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints. >> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. >> >> CSR will be filed once the review is wrapping up. >> >> Thanks~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments from Tony and Artur. src/java.base/share/conf/security/java.security line 810: > 808: # Note: The restriction is applied in the various getInstance(...) methods > 809: # of the supported Service classes, i.e. Cipher, KeyStore, MessageDigest, > 810: # and Signature. I think it would be useful to add an additional sentence: "A NoSuchAlgorithmException will be thrown if the algorithm is disabled." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2320041819 From mullan at openjdk.org Wed Sep 3 20:23:51 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 3 Sep 2025 20:23:51 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v9] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Sat, 16 Aug 2025 00:46:13 GMT, Valerie Peng wrote: >> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s). >> >> A few implementation notes: >> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services. >> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints. >> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. >> >> CSR will be filed once the review is wrapping up. >> >> Thanks~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments from Tony and Artur. test/jdk/java/security/Signature/TestDisabledAlgorithms.java line 64: > 62: } else { > 63: s = Signature.getInstance(a, p); > 64: } For these tests, you could add another call to `Signature.getInstance(a, p.getName())` so you also test the `getInstance` method that takes a provider as a string. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2320092513 From valeriep at openjdk.org Wed Sep 3 20:37:47 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 3 Sep 2025 20:37:47 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v9] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: <37oUCGV14srQUQaDPKmzhIJ8c3X6FEJd3sMuoLTXZ_U=.d34d4d1a-c0f8-4cb9-ae59-e003335658c8@github.com> On Wed, 3 Sep 2025 19:47:14 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments from Tony and Artur. > > src/java.base/share/conf/security/java.security line 817: > >> 815: # Example: >> 816: # jdk.crypto.disabledAlgorithms=Cipher.RSA/ECB/PKCS1Padding, MessageDigest.MD2 >> 817: > > Please add 2 more lines here, like other properties such as `jdk.security.provider.preferred` that have no default values: > > > # > # jdk.crypto.disabledAlgorithms= Sure~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2320125507 From valeriep at openjdk.org Wed Sep 3 20:42:47 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 3 Sep 2025 20:42:47 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v9] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Wed, 3 Sep 2025 19:58:33 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments from Tony and Artur. > > src/java.base/share/conf/security/java.security line 810: > >> 808: # Note: The restriction is applied in the various getInstance(...) methods >> 809: # of the supported Service classes, i.e. Cipher, KeyStore, MessageDigest, >> 810: # and Signature. > > I think it would be useful to add an additional sentence: "A NoSuchAlgorithmException will be thrown if the algorithm is disabled." Well, it's not necessarily NSAE, e.g. `java.security.KeyStore` class throws `KeyStoreException`. Maybe just state "An exception will be thrown if the algorithm is disabled"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2320138416 From valeriep at openjdk.org Wed Sep 3 20:46:47 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 3 Sep 2025 20:46:47 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v9] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Wed, 3 Sep 2025 20:20:29 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments from Tony and Artur. > > test/jdk/java/security/Signature/TestDisabledAlgorithms.java line 64: > >> 62: } else { >> 63: s = Signature.getInstance(a, p); >> 64: } > > For these tests, you could add another call to `Signature.getInstance(a, p.getName())` so you also test the `getInstance` method that takes a provider as a string. Sure, will do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2320147146 From mullan at openjdk.org Wed Sep 3 21:15:48 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 3 Sep 2025 21:15:48 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v9] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Wed, 3 Sep 2025 20:40:04 GMT, Valerie Peng wrote: >> src/java.base/share/conf/security/java.security line 810: >> >>> 808: # Note: The restriction is applied in the various getInstance(...) methods >>> 809: # of the supported Service classes, i.e. Cipher, KeyStore, MessageDigest, >>> 810: # and Signature. >> >> I think it would be useful to add an additional sentence: "A NoSuchAlgorithmException will be thrown if the algorithm is disabled." > > Well, it's not necessarily NSAE, e.g. `java.security.KeyStore` class throws `KeyStoreException`. Maybe just state "An exception will be thrown if the algorithm is disabled"? Ah, right. I think I would prefer if we state the actual exception thrown, even if it's a bit longer. So how about: "If the algorithm is disabled, a NoSuchAlgorithmException will be thrown by the getInstance methods of Cipher, MessageDigest, and Signature and a KeyStoreException by the getInstance methods of KeyStore." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2320231005 From valeriep at openjdk.org Thu Sep 4 00:14:24 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 4 Sep 2025 00:14:24 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v7] In-Reply-To: References: Message-ID: > This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods. > > As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear. > > Thanks in advance for the review~ > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Address review comments from Sean. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26489/files - new: https://git.openjdk.org/jdk/pull/26489/files/9b2a09f7..4d4638cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26489&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26489&range=05-06 Stats: 43 lines in 2 files changed: 22 ins; 4 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/26489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26489/head:pull/26489 PR: https://git.openjdk.org/jdk/pull/26489 From valeriep at openjdk.org Thu Sep 4 00:32:47 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 4 Sep 2025 00:32:47 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v9] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Wed, 3 Sep 2025 21:12:50 GMT, Sean Mullan wrote: >> Well, it's not necessarily NSAE, e.g. `java.security.KeyStore` class throws `KeyStoreException`. Maybe just state "An exception will be thrown if the algorithm is disabled"? > > Ah, right. I think I would prefer if we state the actual exception thrown, even if it's a bit longer. So how about: "If the algorithm is disabled, a NoSuchAlgorithmException will be thrown by the getInstance methods of Cipher, MessageDigest, and Signature and a KeyStoreException by the getInstance methods of KeyStore." Ok, I will add it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2320527177 From valeriep at openjdk.org Thu Sep 4 01:23:49 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 4 Sep 2025 01:23:49 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v10] In-Reply-To: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: > This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s). > > A few implementation notes: > 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services. > 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints. > 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. > > CSR will be filed once the review is wrapping up. > > Thanks~ > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Address review comments from Sean. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26377/files - new: https://git.openjdk.org/jdk/pull/26377/files/5e2bed18..0bd4413c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26377&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26377&range=08-09 Stats: 21 lines in 5 files changed: 18 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26377/head:pull/26377 PR: https://git.openjdk.org/jdk/pull/26377 From jnimeh at openjdk.org Thu Sep 4 02:38:23 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 4 Sep 2025 02:38:23 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks Message-ID: This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. Credit and thanks to @jaikiran for finding the issue and providing reproducer code. ------------- Commit messages: - Fix whitespace errors, add trailing newline - merge with main - 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks Changes: https://git.openjdk.org/jdk/pull/27081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366833 Stats: 135 lines in 2 files changed: 133 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27081/head:pull/27081 PR: https://git.openjdk.org/jdk/pull/27081 From jnimeh at openjdk.org Thu Sep 4 06:16:05 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 4 Sep 2025 06:16:05 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v2] In-Reply-To: References: Message-ID: > This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. > > Credit and thanks to @jaikiran for finding the issue and providing reproducer code. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27081/files - new: https://git.openjdk.org/jdk/pull/27081/files/cfff7fe7..12e08a77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27081/head:pull/27081 PR: https://git.openjdk.org/jdk/pull/27081 From vyazici at openjdk.org Thu Sep 4 06:50:18 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 06:50:18 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods Message-ID: [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 ------------- Commit messages: - Further simplify sneaky-throws in `String` - Fix `StringSupport` - Revert "8366693: Backout recent JavaLangAccess changes breaking the build" Changes: https://git.openjdk.org/jdk/pull/27084/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366765 Stats: 465 lines in 9 files changed: 242 ins; 122 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/27084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27084/head:pull/27084 PR: https://git.openjdk.org/jdk/pull/27084 From vyazici at openjdk.org Thu Sep 4 06:50:18 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 06:50:18 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Commits are consisted of the following: 1. f3e7c130391 Revert the revert 2. 3ea1d5ea009 Fix `StringSupport` 3. b48def1a22d Further simplify sneaky-throws in `String` (via @dfuch) Started `tier1,2` against b48def1a22d on 2025-09-03T07:50:32Z, and it successfully completed on 2025-09-03T14:10:35Z. Results are attached to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27084#issuecomment-3252150408 From alanb at openjdk.org Thu Sep 4 07:22:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Sep 2025 07:22:42 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: <9l-pIuhLga7chfDkPBKvUvPTx8fFcnkY0nkmTTrlI9I=.8e0b36fc-ed36-4699-8531-63b0ba4f8901@github.com> On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Can you confirm that the only change from before is the update to src/java.base/share/classes/jdk/internal/foreign/StringSupport.java to deal with the "new" usage there? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27084#issuecomment-3252266512 From vyazici at openjdk.org Thu Sep 4 07:55:50 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 07:55:50 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: <9l-pIuhLga7chfDkPBKvUvPTx8fFcnkY0nkmTTrlI9I=.8e0b36fc-ed36-4699-8531-63b0ba4f8901@github.com> References: <9l-pIuhLga7chfDkPBKvUvPTx8fFcnkY0nkmTTrlI9I=.8e0b36fc-ed36-4699-8531-63b0ba4f8901@github.com> Message-ID: On Thu, 4 Sep 2025 07:19:39 GMT, Alan Bateman wrote: > Can you confirm that the only change from before is the update to src/java.base/share/classes/jdk/internal/foreign/StringSupport.java to deal with the "new" usage there? @AlanBateman, this PR has *one additional change* to deal with the "new" usage in `StringSupport`: 1. f3e7c130391 Revert the revert 2. 3ea1d5ea009 Deal with `StringSupport` 3. b48def1a22d Further simplify sneaky-throws in `String` (via @dfuch) The diff compared to JDK-8356439 (#26413 eea50fbc) is as follows: git diff eea50fbc...b48def1a -- $(git diff --name-only upstream/master | xargs echo) diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java index 8acb8d8514b..54f74266c08 100644 --- a/src/java.base/share/classes/java/lang/String.java +++ b/src/java.base/share/classes/java/lang/String.java @@ -1348,7 +1348,7 @@ private static int malformed4(byte[] src, int sp) { * having to declare the exception */ @SuppressWarnings("unchecked") - private static E malformedInputException(int offset, int length) throws E { + private static E malformedInputException(int offset, int length) { MalformedInputException mie = new MalformedInputException(length); String msg = "malformed input offset : " + offset + ", length : " + length; mie.initCause(new IllegalArgumentException(msg)); @@ -1359,7 +1359,7 @@ private static E malformedInputException(int offset, int l * {@return a new {@link MalformedInputException} for the given malformed * ASCII string} */ - private static MalformedInputException malformedASCII(byte[] val) throws MalformedInputException { + private static MalformedInputException malformedASCII(byte[] val) { int dp = StringCoding.countPositives(val, 0, val.length); return malformedInputException(dp, 1); } @@ -1371,7 +1371,7 @@ private static MalformedInputException malformedASCII(byte[] val) throws Malform * having to declare the exception */ @SuppressWarnings("unchecked") - private static E unmappableCharacterException(int offset) throws E { + private static E unmappableCharacterException(int offset) { UnmappableCharacterException uce = new UnmappableCharacterException(1); String msg = "malformed input offset : " + offset + ", length : 1"; uce.initCause(new IllegalArgumentException(msg, uce)); @@ -1382,7 +1382,7 @@ private static E unmappableCharacterException(int offset) * {@return a new {@link UnmappableCharacterException} for the given * malformed ASCII string} */ - private static UnmappableCharacterException unmappableASCII(byte[] val) throws UnmappableCharacterException { + private static UnmappableCharacterException unmappableASCII(byte[] val) { int dp = StringCoding.countPositives(val, 0, val.length); return unmappableCharacterException(dp); } diff --git a/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java b/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java index 2f842810aa7..bb6cb2d3915 100644 --- a/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java +++ b/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java @@ -73,7 +73,7 @@ private static String readByte(AbstractMemorySegmentImpl segment, long offset, C final byte[] bytes = new byte[len]; MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len); try { - return JAVA_LANG_ACCESS.uncheckedNewStringNoRepl(bytes, charset); + return JAVA_LANG_ACCESS.uncheckedNewStringOrThrow(bytes, charset); } catch (CharacterCodingException _) { // use replacement characters for malformed input return new String(bytes, charset); @@ -92,7 +92,7 @@ private static String readShort(AbstractMemorySegmentImpl segment, long offset, byte[] bytes = new byte[len]; MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len); try { - return JAVA_LANG_ACCESS.uncheckedNewStringNoRepl(bytes, charset); + return JAVA_LANG_ACCESS.uncheckedNewStringOrThrow(bytes, charset); } catch (CharacterCodingException _) { // use replacement characters for malformed input return new String(bytes, charset); @@ -111,7 +111,7 @@ private static String readInt(AbstractMemorySegmentImpl segment, long offset, Ch byte[] bytes = new byte[len]; MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len); try { - return JAVA_LANG_ACCESS.uncheckedNewStringNoRepl(bytes, charset); + return JAVA_LANG_ACCESS.uncheckedNewStringOrThrow(bytes, charset); } catch (CharacterCodingException _) { // use replacement characters for malformed input return new String(bytes, charset); ------------- PR Comment: https://git.openjdk.org/jdk/pull/27084#issuecomment-3252376320 From alanb at openjdk.org Thu Sep 4 08:29:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Sep 2025 08:29:42 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: <_KvUNOd7WUsV5u8pgeihu3YQqXtvZQUgGs8ehozlA9o=.ce1be4e2-49cd-4b99-b949-eb4f10269e90@github.com> On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27084#pullrequestreview-3184023515 From duke at openjdk.org Thu Sep 4 08:44:45 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 4 Sep 2025 08:44:45 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:16:05 GMT, Jamil Nimeh wrote: >> This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. >> >> Credit and thanks to @jaikiran for finding the issue and providing reproducer code. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded comments test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/UpdateAADTest.java line 115: > 113: > 114: try { > 115: cipher.updateAAD(buffer); Shouldn't we also check that the cipher's state is what we expected after this update? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27081#discussion_r2321298530 From aturbanov at openjdk.org Thu Sep 4 09:07:43 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 Sep 2025 09:07:43 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 src/java.base/share/classes/java/lang/String.java line 691: > 689: } > 690: > 691: /* Is there a reason, why it can't be _converted_ to a proper javadoc? Suggestion: /** src/java.base/share/classes/java/lang/String.java line 797: > 795: * @param cs charset the byte array encoded in > 796: * > 797: * @throws CharacterCodingException for malformed input or unmappable characters Shouldn't we document NPE here too? I mean there is NPE note in `private` method `newStringUTF8OrThrow`, but not in the more widely opened `newStringOrThrow`. That's confusing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321347469 PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321350608 From vyazici at openjdk.org Thu Sep 4 09:41:43 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 09:41:43 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Improve docs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27084/files - new: https://git.openjdk.org/jdk/pull/27084/files/b48def1a..8d7dcb4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27084/head:pull/27084 PR: https://git.openjdk.org/jdk/pull/27084 From vyazici at openjdk.org Thu Sep 4 09:41:45 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 09:41:45 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:01:25 GMT, Andrey Turbanov wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/java/lang/String.java line 691: > >> 689: } >> 690: >> 691: /* > > Is there a reason, why it can't be _converted_ to a proper javadoc? > Suggestion: > > /** Improved as suggested in 8d7dcb4d410. > src/java.base/share/classes/java/lang/String.java line 797: > >> 795: * @param cs charset the byte array encoded in >> 796: * >> 797: * @throws CharacterCodingException for malformed input or unmappable characters > > Shouldn't we document NPE here too? > I mean there is NPE note in `private` method `newStringUTF8OrThrow`, but not in the more widely opened `newStringOrThrow`. That's confusing. Improved NPE docs in 8d7dcb4d410. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321446143 PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321445517 From aturbanov at openjdk.org Thu Sep 4 09:48:45 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 Sep 2025 09:48:45 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:41:43 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Improve docs src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 344: > 342: * @return the newly created string > 343: * @throws CharacterCodingException for malformed or unmappable bytes > 344: * @throws NullPointerException If {@code bytes} is null for `null` cs is also thrown ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321465942 From aturbanov at openjdk.org Thu Sep 4 10:05:43 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 Sep 2025 10:05:43 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: <-avSrcF74p9fXQU6etWKeA9APU_h3TqqTt6vMr1YppY=.c9ee2517-ffff-47b4-aaf6-4e5158026a8f@github.com> On Thu, 4 Sep 2025 09:41:43 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Improve docs src/java.base/share/classes/java/lang/String.java line 961: > 959: * @throws CharacterCodingException For malformed input or unmappable characters > 960: */ > 961: static byte[] getBytesUTF8OrThrow(String s) throws CharacterCodingException { `encodeUTF8OrThrow(s.coder(), s.value());` specified to throw `UnmappableCharacterException`. May we should to it here too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321506473 From vyazici at openjdk.org Thu Sep 4 11:22:31 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 11:22:31 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v3] In-Reply-To: References: Message-ID: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: More nullability improvements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27084/files - new: https://git.openjdk.org/jdk/pull/27084/files/8d7dcb4d..1852dccc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27084/head:pull/27084 PR: https://git.openjdk.org/jdk/pull/27084 From vyazici at openjdk.org Thu Sep 4 11:22:32 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 11:22:32 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:45:57 GMT, Andrey Turbanov wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 344: > >> 342: * @return the newly created string >> 343: * @throws CharacterCodingException for malformed or unmappable bytes >> 344: * @throws NullPointerException If {@code bytes} is null > > for `null` cs is also thrown Fixed in 1852dccc962. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321712147 From vyazici at openjdk.org Thu Sep 4 11:25:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 11:25:53 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: <-avSrcF74p9fXQU6etWKeA9APU_h3TqqTt6vMr1YppY=.c9ee2517-ffff-47b4-aaf6-4e5158026a8f@github.com> References: <-avSrcF74p9fXQU6etWKeA9APU_h3TqqTt6vMr1YppY=.c9ee2517-ffff-47b4-aaf6-4e5158026a8f@github.com> Message-ID: On Thu, 4 Sep 2025 10:03:10 GMT, Andrey Turbanov wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/java/lang/String.java line 961: > >> 959: * @throws CharacterCodingException For malformed input or unmappable characters >> 960: */ >> 961: static byte[] getBytesUTF8OrThrow(String s) throws CharacterCodingException { > > `encodeUTF8OrThrow(s.coder(), s.value());` specified to throw `UnmappableCharacterException`. May we should to it here too? UCE extends from CCE, hence `throws UCE` is already covered. Plus, what I see from `JLA::*OrThrow` methods, we only declare and document the CCE, not its subclasses. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321722048 From mullan at openjdk.org Thu Sep 4 12:58:52 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 4 Sep 2025 12:58:52 GMT Subject: RFR: 8315487: Security Providers Filter [v28] In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 17:01:30 GMT, Martin Balao Alonso 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 Alonso has updated the pull request incrementally with one additional commit since the last revision: > > Adjust ProvidersFilterTest for ec7c6be6a9e84c8cd2077fea07930592ddd13669 Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15539#pullrequestreview-3185131433 From mullan at openjdk.org Thu Sep 4 12:59:55 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 4 Sep 2025 12:59:55 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v10] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Thu, 4 Sep 2025 01:23:49 GMT, Valerie Peng wrote: >> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s). >> >> A few implementation notes: >> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services. >> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints. >> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. >> >> CSR will be filed once the review is wrapping up. >> >> Thanks~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments from Sean. One more comment, otherwise looks good. Also, add a release note. src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 51: > 49: > 50: // Disabled algorithm security property for JCE crypto services > 51: public static final String PROPERTY_CRYPTO_DISABLED_ALGS = I think this can be private. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26377#pullrequestreview-3185084037 PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2322003240 From mullan at openjdk.org Thu Sep 4 13:02:52 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 4 Sep 2025 13:02:52 GMT Subject: RFR: 8315487: Security Providers Filter [v28] In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 17:01:30 GMT, Martin Balao Alonso 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 Alonso has updated the pull request incrementally with one additional commit since the last revision: > > Adjust ProvidersFilterTest for ec7c6be6a9e84c8cd2077fea07930592ddd13669 Accidentally approved the wrong PR, so need to remove my approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-3253596641 From jpai at openjdk.org Thu Sep 4 13:03:45 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 4 Sep 2025 13:03:45 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:16:05 GMT, Jamil Nimeh wrote: >> This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. >> >> Credit and thanks to @jaikiran for finding the issue and providing reproducer code. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded comments Thank you for the fix Jamil. This looks good to me. I've built and verified this patch against the original testsuite which reproduced this issue and it now passes with this fix. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27081#pullrequestreview-3185153570 From mullan at openjdk.org Thu Sep 4 13:09:52 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 4 Sep 2025 13:09:52 GMT Subject: RFR: 8315487: Security Providers Filter [v28] In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 17:01:30 GMT, Martin Balao Alonso 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 Alonso has updated the pull request incrementally with one additional commit since the last revision: > > Adjust ProvidersFilterTest for ec7c6be6a9e84c8cd2077fea07930592ddd13669 Not requesting any specific changes right now, but this should remove my accidental approval. ------------- Changes requested by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15539#pullrequestreview-3185190804 From rriggs at openjdk.org Thu Sep 4 13:31:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 13:31:47 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 11:22:31 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > More nullability improvements Good to go! ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27084#pullrequestreview-3185310732 From fguallini at openjdk.org Thu Sep 4 13:36:53 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Thu, 4 Sep 2025 13:36:53 GMT Subject: RFR: 8366817: test/jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java and JdkProcClient.java should not delete logs Message-ID: <168uceKQ-mqaigIebpwYvP0GaL2d0uynUzSqiHd6M-Q=.4a48511e-cc1b-44be-9019-407612df2e25@github.com> The following test helpers delete logs after the test completes: jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java jdk/javax/net/ssl/TLSCommon/interop/JdkProcClient.java These helpers are used by tests located in jdk/javax/net/ssl/compatibility/*.java. Instead of explicitly deleting logs, cleanup should be handled by JTREG, as with other tests. It is possible that the server process is still writing to this log when it tries to delete it, which could cause : `java.nio.file.FileSystemException: server.log: The process cannot access the file because it is being used by another process` ------------- Commit messages: - only removing log file - remove log deletion Changes: https://git.openjdk.org/jdk/pull/27076/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27076&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366817 Stats: 9 lines in 3 files changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27076/head:pull/27076 PR: https://git.openjdk.org/jdk/pull/27076 From weijun at openjdk.org Thu Sep 4 13:49:45 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 4 Sep 2025 13:49:45 GMT Subject: RFR: 8366211: Block signature scheme names to be used with CertificateSignature algorithm constraints usage [v2] In-Reply-To: References: <6wPIjQW0SE1OR9ApU2_YGiP-HdfqCmsvLDeRr_UF7hI=.c5fa6432-f070-4fad-988a-6ee2c4063648@github.com> Message-ID: On Thu, 28 Aug 2025 21:37:22 GMT, Artur Barashev wrote: >> To avoid any user confusion, we should block signature scheme names to be used with `CertificateSignature` algorithm constraints usage. For example, `RSASSA-PSS` certificate signature algorithm corresponds to multiple signature scheme names and blocking one of those signature scheme with `CertificateSignature` usage directive won't block `RSASSA-PSS` certificate signature because other rsa_pss_* signature schemes still will be allowed. We should direct users to use certificate signature algorithm with `CertificateSignature` usage directive. For example: >> >> - To be blocked: "rsa_pss_pss_sha256 usage CertificateSignature" >> - To be allowed: `RSASSA-PSS usage CertificateSignature` or `RSA usage CertificateSignature` > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Fix string concatenation alignment. Use upper-case characters in the test signature scheme name. src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 822: > 820: // We avoid calling back the SSL layer to get these names because of > 821: // the circular dependency. > 822: private static final Set BLOCKED_FOR_CERT_SCOPE = Set.of( Will we need to update the list whenever a new scheme is introduced? I've noticed all names contain an underscore and IIRC no standard name of a Signature has it. Do you think we can just check for the underscore character as a heuristic? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26970#discussion_r2322237448 From mullan at openjdk.org Thu Sep 4 14:01:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 4 Sep 2025 14:01:50 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v7] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 00:14:24 GMT, Valerie Peng wrote: >> This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods. >> >> As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear. >> >> Thanks in advance for the review~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments from Sean. test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java line 85: > 83: > 84: checkTransformation("ChaCha20/ECB/NoPadding", Expected.NSAE_OR_NSPE); > 85: checkTransformation("ChaCha20/None/PKCS5Padding", Expected.NSAE_OR_NSPE); Isn't this always going to throw NSPE given the current provider configuration? Also, same comment on line 88. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2322282238 From mdonovan at openjdk.org Thu Sep 4 14:04:25 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 4 Sep 2025 14:04:25 GMT Subject: RFR: 8366182: Some PKCS11Tests are being skipped when they shouldn't Message-ID: This PR updates PKCS11 tests to better handle NSS version numbers. The previous code treated the version numbers as double values and used comparison operators. The problem is that it incorrectly treats 3.111 as between 3.11 and 3.12. This update parses and compares the major and minor version numbers separately. ------------- Commit messages: - 8366182: Some PKCS11Tests are being skipped when they shouldn't Changes: https://git.openjdk.org/jdk/pull/27095/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27095&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366182 Stats: 90 lines in 6 files changed: 27 ins; 20 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/27095.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27095/head:pull/27095 PR: https://git.openjdk.org/jdk/pull/27095 From dfuchs at openjdk.org Thu Sep 4 14:06:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 4 Sep 2025 14:06:52 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v16] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 653 commits: - merge latest changes from master branch - http3: fix at since - merge latest http3 changes - Remove unused variables - Simplify control flow - Remove unnecessary instanceof checks - Use IntFunction for header generator - merge latest changes from master branch - http3: minor cleanup - http3: cleanup - QuicConnectionImpl::maxInitialTimer should be volatile - ... and 643 more: https://git.openjdk.org/jdk/compare/a40afdd0...3925afda ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=15 Stats: 105850 lines in 474 files changed: 103019 ins; 1333 del; 1498 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From weijun at openjdk.org Thu Sep 4 14:08:46 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 4 Sep 2025 14:08:46 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:38:57 GMT, Matthew Donovan wrote: >> This PR extends security tests to use ByteBuffers backed by MemorySegments. Tests in the areas of Signature, Cipher, MessageDigest, and Mac are updated. > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - addressed PR comments and refactored to use try-with-resources > - Merge branch 'master' into cipher-ffm > - 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments Can we also add some negative tests? (This could be done in a different PR). For example, trying to use a read-only ByteBuffer for output, or trying to use a ByteBuffer after the arena has been closed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26967#issuecomment-3253905969 From weijun at openjdk.org Thu Sep 4 14:12:46 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 4 Sep 2025 14:12:46 GMT Subject: RFR: 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom [v2] In-Reply-To: <5EQYxvv6k-VNzWhfZ82PVEp6pEgRkubYqyueB1Z2Vus=.2a4d06bf-7115-4086-9c19-293a7382d7b1@github.com> References: <5EQYxvv6k-VNzWhfZ82PVEp6pEgRkubYqyueB1Z2Vus=.2a4d06bf-7115-4086-9c19-293a7382d7b1@github.com> Message-ID: On Tue, 26 Aug 2025 17:30:54 GMT, Mikhail Yankelevich wrote: >> Skipped tests are treated as a pass: >> >> * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java >> * test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java >> * test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java >> * test/jdk/sun/security/pkcs11/SecureRandom/Basic.java >> * test/jdk/sun/security/pkcs11/SecureRandom/TestDeserialization.java > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java line 125: > 123: test("Blowfish", bf_128Key, p, TestResult.PASS); > 124: } catch (SkippedException skippedException){ > 125: throw new SkippedException("One or more tests skipped"); The original test runs all cases but the updated would stop once any of them is skipped. Is this intended? Also, I cannot see a benefit to rethrow a `SkippedException` with only a modified message. Why not just let it bubble up? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26942#discussion_r2322324517 From djelinski at openjdk.org Thu Sep 4 14:16:03 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 4 Sep 2025 14:16:03 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v16] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:06:52 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 653 commits: > > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - merge latest changes from master branch > - http3: minor cleanup > - http3: cleanup - QuicConnectionImpl::maxInitialTimer should be volatile > - ... and 643 more: https://git.openjdk.org/jdk/compare/a40afdd0...3925afda Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3185555986 From myankelevich at openjdk.org Thu Sep 4 14:48:43 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 4 Sep 2025 14:48:43 GMT Subject: RFR: 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom [v2] In-Reply-To: References: <5EQYxvv6k-VNzWhfZ82PVEp6pEgRkubYqyueB1Z2Vus=.2a4d06bf-7115-4086-9c19-293a7382d7b1@github.com> Message-ID: On Thu, 4 Sep 2025 14:09:54 GMT, Weijun Wang wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom > > test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java line 125: > >> 123: test("Blowfish", bf_128Key, p, TestResult.PASS); >> 124: } catch (SkippedException skippedException){ >> 125: throw new SkippedException("One or more tests skipped"); > > The original test runs all cases but the updated would stop once any of them is skipped. Is this intended? > > Also, I cannot see a benefit to rethrow a `SkippedException` with only a modified message. Why not just let it bubble up? Thank you for noticing, this is definitely not intentional. It should show this error only if there are some tests skipped, but should still run all of them. This way the error will not be hidden by the skip in another test. This is also why I didn't bubble it up, as this was not supposed to be triggered until all the tests are finished. This should be fixed in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26942#discussion_r2322443827 From myankelevich at openjdk.org Thu Sep 4 15:02:02 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 4 Sep 2025 15:02:02 GMT Subject: RFR: 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom [v3] In-Reply-To: References: Message-ID: <-yJlJYEHVRkbGTv6fgS4tcKS97RktKNhU9AaD3It9Y0=.d31c780b-798f-4592-8e75-95655e814686@github.com> > Skipped tests are treated as a pass: > > * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java > * test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java > * test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java > * test/jdk/sun/security/pkcs11/SecureRandom/Basic.java > * test/jdk/sun/security/pkcs11/SecureRandom/TestDeserialization.java Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: waiting for all tests to run before skipping ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26942/files - new: https://git.openjdk.org/jdk/pull/26942/files/867b81d3..b9d3f123 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26942&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26942&range=01-02 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26942/head:pull/26942 PR: https://git.openjdk.org/jdk/pull/26942 From liach at openjdk.org Thu Sep 4 15:05:46 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 15:05:46 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 11:22:31 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > More nullability improvements Looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27084#pullrequestreview-3185780567 From jnimeh at openjdk.org Thu Sep 4 15:23:01 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 4 Sep 2025 15:23:01 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 08:42:10 GMT, Ferenc Rakoczi wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unneeded comments > > test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/UpdateAADTest.java line 115: > >> 113: >> 114: try { >> 115: cipher.updateAAD(buffer); > > Shouldn't we also check that the cipher's state is what we expected after this update? I've added a check on the buffer position and limit to ensure that the buffer has no remaining data at the end. This can only happen if processMultipleBlocks ends with the buffer's position left at the first byte of trailing data where 0 <= remaining < 16. The engineUpdate method will take care of any remaining non-block aligned data (if it exists). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27081#discussion_r2322534685 From jnimeh at openjdk.org Thu Sep 4 15:23:01 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 4 Sep 2025 15:23:01 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v3] In-Reply-To: References: Message-ID: > This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. > > Credit and thanks to @jaikiran for finding the issue and providing reproducer code. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Add buffer state check following updateAAD call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27081/files - new: https://git.openjdk.org/jdk/pull/27081/files/12e08a77..ef22bc7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=01-02 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27081/head:pull/27081 PR: https://git.openjdk.org/jdk/pull/27081 From jnimeh at openjdk.org Thu Sep 4 15:26:02 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 4 Sep 2025 15:26:02 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v4] In-Reply-To: References: Message-ID: > This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. > > Credit and thanks to @jaikiran for finding the issue and providing reproducer code. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Fix typo in exception message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27081/files - new: https://git.openjdk.org/jdk/pull/27081/files/ef22bc7d..43cc8ca2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27081/head:pull/27081 PR: https://git.openjdk.org/jdk/pull/27081 From myankelevich at openjdk.org Thu Sep 4 15:41:43 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 4 Sep 2025 15:41:43 GMT Subject: RFR: 8366182: Some PKCS11Tests are being skipped when they shouldn't In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 13:59:22 GMT, Matthew Donovan wrote: > This PR updates PKCS11 tests to better handle NSS version numbers. The previous code treated the version numbers as double values and used comparison operators. The problem is that it incorrectly treats 3.111 as between 3.11 and 3.12. This update parses and compares the major and minor version numbers separately. test/jdk/sun/security/pkcs11/Cipher/TestKATForGCM.java line 330: > 328: String osName = System.getProperty("os.name"); > 329: int idx = ver.indexOf("."); > 330: double major = Double.parseDouble(ver.substring(0, idx)); IMO the split between major version and minor is a bit hard to read. Wouldn't it be easier to just get a major.minor version entirely with something like: String[] splitParts = ver.split("//."); Double.parseDouble(splitParts.length > 1 ? splitParts[0] + "." + splitParts[1] : splitParts[0]); This way it will always take a full double value (1.13 will not be the same as 1.1, as it's now as far as I can see) and would be a bit easier to understand The checking for only major version could be either `doubleVersion<4 && doubleVersion>=3` or even cleaner, using floor function `Math.floor(doubleVersion)` And the same for the other files. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27095#discussion_r2322586969 From mdonovan at openjdk.org Thu Sep 4 16:58:50 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 4 Sep 2025 16:58:50 GMT Subject: RFR: 8366182: Some PKCS11Tests are being skipped when they shouldn't In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:37:57 GMT, Mikhail Yankelevich wrote: >> This PR updates PKCS11 tests to better handle NSS version numbers. The previous code treated the version numbers as double values and used comparison operators. The problem is that it incorrectly treats 3.111 as between 3.11 and 3.12. This update parses and compares the major and minor version numbers separately. > > test/jdk/sun/security/pkcs11/Cipher/TestKATForGCM.java line 330: > >> 328: String osName = System.getProperty("os.name"); >> 329: int idx = ver.indexOf("."); >> 330: double major = Double.parseDouble(ver.substring(0, idx)); > > IMO the split between major version and minor is a bit hard to read. Wouldn't it be easier to just get a major.minor version entirely with something like: > > > String[] splitParts = ver.split("//."); > Double.parseDouble(splitParts.length > 1 > ? splitParts[0] + "." + splitParts[1] > : splitParts[0]); > > > This way it will always take a full double value (1.13 will not be the same as 1.1, as it's now as far as I can see) and would be a bit easier to understand > > The checking for only major version could be either `doubleVersion<4 && doubleVersion>=3` or even cleaner, using floor function `Math.floor(doubleVersion)` > > And the same for the other files. > > What do you think? I may be misunderstanding your comment but it looks like you're using a single, `double` value to compare versions. The original code did that but it doesn't work in all cases. The problem occurs when checking a range such as `version >= 3.11 && version < 3.12` If the version number is 3.111, then the comparison is `true` and tests are skipped, even though _version_ 3.111 is "greater" than 3.12. So this code creates two doubles: `major` and `minor` to do separate comparisons of the values. To further complicate things, NSS also has versions of the form `x.y.z`. The original code combined the 'y' and 'z' components to go from 3.11.9 to 3.119. My change would create major version 3.0 and minor version 11.9. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27095#discussion_r2322797235 From mdonovan at openjdk.org Thu Sep 4 17:03:41 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 4 Sep 2025 17:03:41 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:05:47 GMT, Weijun Wang wrote: > Can we also add some negative tests? (This could be done in a different PR). For example, trying to use a read-only ByteBuffer for output, or trying to use a ByteBuffer after the arena has been closed. Created JDK-8366912 for negative tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26967#issuecomment-3254619707 From abarashev at openjdk.org Thu Sep 4 17:14:58 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 4 Sep 2025 17:14:58 GMT Subject: RFR: 8365953: Key manager returns no certificates when handshakeSession is not an ExtendedSSLSession Message-ID: See X509KeyManagerCertChecking#getAlgorithmConstraints. If the handshake session is not an ExtendedSSLSession, the method returns constraints using a null list of peerSupportedSignAlgs, which in turn means that all certificates will be rejected. Accepting all signature schemes would probably be a better choice here, and that's what we do when the handshake session is not available at all. The SunJSSE SSLSockets and SSLEngines both return extended SSL sessions. There are no known third-party providers that return non-extended SSL sessions. ------------- Commit messages: - 8365953: Key manager returns no certificates when handshakeSession is not an ExtendedSSLSession Changes: https://git.openjdk.org/jdk/pull/27106/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365953 Stats: 451 lines in 3 files changed: 406 ins; 14 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/27106.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27106/head:pull/27106 PR: https://git.openjdk.org/jdk/pull/27106 From mullan at openjdk.org Thu Sep 4 17:39:44 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 4 Sep 2025 17:39:44 GMT Subject: RFR: 8366211: Block signature scheme names to be used with CertificateSignature algorithm constraints usage [v2] In-Reply-To: References: <6wPIjQW0SE1OR9ApU2_YGiP-HdfqCmsvLDeRr_UF7hI=.c5fa6432-f070-4fad-988a-6ee2c4063648@github.com> Message-ID: On Thu, 28 Aug 2025 21:37:22 GMT, Artur Barashev wrote: >> To avoid any user confusion, we should block signature scheme names to be used with `CertificateSignature` algorithm constraints usage. For example, `RSASSA-PSS` certificate signature algorithm corresponds to multiple signature scheme names and blocking one of those signature scheme with `CertificateSignature` usage directive won't block `RSASSA-PSS` certificate signature because other rsa_pss_* signature schemes still will be allowed. We should direct users to use certificate signature algorithm with `CertificateSignature` usage directive. For example: >> >> - To be blocked: "rsa_pss_pss_sha256 usage CertificateSignature" >> - To be allowed: `RSASSA-PSS usage CertificateSignature` or `RSA usage CertificateSignature` > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Fix string concatenation alignment. Use upper-case characters in the test signature scheme name. src/java.base/share/conf/security/java.security line 764: > 762: # - rsa_pkcs1_sha1 usage HandshakeSignature > 763: # - SHA1withRSA usage CertificateSignature > 764: # I suggest we also include more details on the acceptable algorithms for HandshakeSignature. I suggest rewording something like: > HandshakeSignature restricts the use of the algorithm in TLS handshake signatures. The algorithm is the name of the TLS signature scheme as specified in the Signature Schemes section of the Java Security Standard Algorithm Names specification. > > CertificateSignature restricts the use of the algorithm in certificate signatures. The algorithm is the name of a java.security.Signature algorithm as specifed in the Signature Algorithms section of the Java Security Standard Algorithm Names specification. > > An algorithm with the HandshakeSignature or CertificateSignature constraint cannot include other usage types defined in the jdk.certpath.disabledAlgorithms property. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. > I don't think you need to say TLS signature schemes cannot be used with CertificateSignature as long as you are clear above as to what the acceptable algorithms are. Does HandshakeSignature only support TLS signature schemes or does it also support java.security.Signature algorithms? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26970#discussion_r2322934928 From abarashev at openjdk.org Thu Sep 4 18:15:44 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 4 Sep 2025 18:15:44 GMT Subject: RFR: 8366211: Block signature scheme names to be used with CertificateSignature algorithm constraints usage [v2] In-Reply-To: References: <6wPIjQW0SE1OR9ApU2_YGiP-HdfqCmsvLDeRr_UF7hI=.c5fa6432-f070-4fad-988a-6ee2c4063648@github.com> Message-ID: On Thu, 4 Sep 2025 17:37:06 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix string concatenation alignment. Use upper-case characters in the test signature scheme name. > > src/java.base/share/conf/security/java.security line 764: > >> 762: # - rsa_pkcs1_sha1 usage HandshakeSignature >> 763: # - SHA1withRSA usage CertificateSignature >> 764: # > > I suggest we also include more details on the acceptable algorithms for HandshakeSignature. I suggest rewording something like: > >> HandshakeSignature restricts the use of the algorithm in TLS handshake signatures. The algorithm is the name of the TLS signature scheme as specified in the Signature Schemes section of the Java Security Standard Algorithm Names specification. >> >> CertificateSignature restricts the use of the algorithm in certificate signatures. The algorithm is the name of a java.security.Signature algorithm as specifed in the Signature Algorithms section of the Java Security Standard Algorithm Names specification. >> >> An algorithm with the HandshakeSignature or CertificateSignature constraint cannot include other usage types defined in the jdk.certpath.disabledAlgorithms property. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. >> > > I don't think you need to say TLS signature schemes cannot be used with CertificateSignature as long as you are clear above as to what the acceptable algorithms are. Does HandshakeSignature only support TLS signature schemes or does it also support java.security.Signature algorithms? Both `HandshakeSignature` and `CertificateSignature` currently support 3 kinds of algorithms as defined in `SignatureScheme.java`: - Signature Schemes - Signature Algorithms - Signature Key Algorithm With this PR we are blocking `Signature Schemes` for `CertificateSignature`. Also, we don't do any algorithm decomposing for usage constraint, i.e. no sub-element matching as described in `jdk.certpath.disabledAlgorithms` documentation in `java.security`. That could be another point of confusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26970#discussion_r2323049989 From valeriep at openjdk.org Thu Sep 4 19:47:43 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 4 Sep 2025 19:47:43 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Core.java line 168: > 166: } else if (kdfAlgo.equals("HmacSHA256")) { > 167: keyLength = 256; > 168: } Why only these two algorithms? Doesn't PBMAC1Core also support other HmacSHAXXX algorithms? We should add an else block to cover unsupported algorithms to detect inconsistency also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2323326330 From valeriep at openjdk.org Thu Sep 4 19:57:46 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 4 Sep 2025 19:57:46 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 19:45:12 GMT, Valerie Peng wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Core.java line 168: > >> 166: } else if (kdfAlgo.equals("HmacSHA256")) { >> 167: keyLength = 256; >> 168: } > > Why only these two algorithms? Doesn't PBMAC1Core also support other HmacSHAXXX algorithms? We should add an else block to cover unsupported algorithms to detect inconsistency also. Is it possible to add a `keyLength` argument to the constructor, so that a different key length can be set along with the block length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2323357191 From valeriep at openjdk.org Thu Sep 4 20:00:45 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 4 Sep 2025 20:00:45 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 115: > 113: protected void engineInit(AlgorithmParameterSpec paramSpec) > 114: throws InvalidParameterSpecException > 115: { nit: move the "{" to the end of line 114, same goes for other methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2323368317 From weijun at openjdk.org Thu Sep 4 21:27:01 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 4 Sep 2025 21:27:01 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 19:54:47 GMT, Valerie Peng wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Core.java line 168: >> >>> 166: } else if (kdfAlgo.equals("HmacSHA256")) { >>> 167: keyLength = 256; >>> 168: } >> >> Why only these two algorithms? Doesn't PBMAC1Core also support other HmacSHAXXX algorithms? We should add an else block to cover unsupported algorithms to detect inconsistency also. > > Is it possible to add a `keyLength` argument to the constructor, so that a different key length can be set along with the block length. In fact, this will change the behavior of the Mac algorithm `PBEWithHmacSHA256` since we hardcoded `keyLength` as `blockLength` there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2323578277 From smarks at openjdk.org Thu Sep 4 23:49:27 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 4 Sep 2025 23:49:27 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 16:29:32 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refining comments src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 133: > 131: Charset.forName(StaticProperty.stdinEncoding(), UTF_8.INSTANCE), > 132: Charset.forName(StaticProperty.stdoutEncoding(), UTF_8.INSTANCE))) : > 133: Optional.empty(); (Finally getting back to this.) The code returns an Optional containing a JdkConsoleImpl instance, or an empty Optional. However the comment above says it returns a JdkConsoleImpl instance or null. Which do we want it to be? Either is OK, but the comment should agree with the code. I think @wangweij might want to weigh in here since his code will be calling this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2323743307 From naoto at openjdk.org Thu Sep 4 23:49:28 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 4 Sep 2025 23:49:28 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: References: Message-ID: <0ub8yevcVcLcmGSHH4edEdSjfrUwW5rAw140-Q4VuUM=.82ba246e-eae9-4b1b-a2d1-f43e8530da1b@github.com> On Thu, 4 Sep 2025 23:28:22 GMT, Stuart Marks wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Refining comments > > src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 133: > >> 131: Charset.forName(StaticProperty.stdinEncoding(), UTF_8.INSTANCE), >> 132: Charset.forName(StaticProperty.stdoutEncoding(), UTF_8.INSTANCE))) : >> 133: Optional.empty(); > > (Finally getting back to this.) > > The code returns an Optional containing a JdkConsoleImpl instance, or an empty Optional. However the comment above says it returns a JdkConsoleImpl instance or null. Which do we want it to be? Either is OK, but the comment should agree with the code. > > I think @wangweij might want to weigh in here since his code will be calling this. Ah, yes. Comment does not align with the code. I am fine either way too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2323752183 From vyazici at openjdk.org Fri Sep 5 06:43:21 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 5 Sep 2025 06:43:21 GMT Subject: Integrated: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 This pull request has now been integrated. Changeset: a2f8d3c4 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/a2f8d3c4c25fdadf378313ef52185dceee98773d Stats: 469 lines in 9 files changed: 244 ins; 121 del; 104 mod 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods Reviewed-by: rriggs, liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/27084 From djelinski at openjdk.org Fri Sep 5 07:35:11 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 5 Sep 2025 07:35:11 GMT Subject: RFR: 8365953: Key manager returns no certificates when handshakeSession is not an ExtendedSSLSession In-Reply-To: References: Message-ID: <0wcwPAXzTKxHLripcjDagaV3JaTqj0GDchSy4-cjmUU=.082d6a81-77ed-4d73-98cb-a098d58081f5@github.com> On Thu, 4 Sep 2025 17:09:29 GMT, Artur Barashev wrote: > See X509KeyManagerCertChecking#getAlgorithmConstraints. If the handshake session is not an ExtendedSSLSession, the method returns constraints using a null list of peerSupportedSignAlgs, which in turn means that all certificates will be rejected. Accepting all signature schemes would probably be a better choice here, and that's what we do when the handshake session is not available at all. > > The SunJSSE SSLSockets and SSLEngines both return extended SSL sessions. There are no known third-party providers that return non-extended SSL sessions. LGTM. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27106#pullrequestreview-3188310642 From fguallini at openjdk.org Fri Sep 5 08:33:24 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 5 Sep 2025 08:33:24 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java Message-ID: The test javax/net/ssl/DTLS/PacketLossRetransmission takes about 2 minutes to complete. The reason is that the server or client socket times out after 10 seconds while waiting to receive a DatagramPacket that has already been removed (to simulate packet loss). Given that it will time out, it is better to reduce its value. After reducing the timeout , the total test execution completes in approximately 20 seconds on average. Additionally, unnecessary scenarios are removed; for instance, when acting as a client, there is no "server_hello" message type to remove, and similarly, when acting as a server, there is no "client_hello" message on that side, so there is no corresponding packet loss to simulate. ------------- Commit messages: - add back certificate_status in server side - renamed var - Shorter time out Changes: https://git.openjdk.org/jdk/pull/27093/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27093&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8201778 Stats: 23 lines in 2 files changed: 7 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27093.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27093/head:pull/27093 PR: https://git.openjdk.org/jdk/pull/27093 From djelinski at openjdk.org Fri Sep 5 09:23:11 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 5 Sep 2025 09:23:11 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java In-Reply-To: References: Message-ID: <_9cnwuSg2mjxCwKnIej_zgVS5HrK-EeVMic6TQAQBD4=.e3ab678c-d7eb-4ae5-a28a-aa0912d86b2c@github.com> On Thu, 4 Sep 2025 12:52:31 GMT, Fernando Guallini wrote: > The test javax/net/ssl/DTLS/PacketLossRetransmission takes about 2 minutes to complete. The reason is that the server or client socket times out after 10 seconds while waiting to receive a DatagramPacket that has already been removed (to simulate packet loss). Given that it will time out, it is better to reduce its value. > After reducing the timeout , the total test execution completes in approximately 20 seconds on average. > Additionally, unnecessary scenarios are removed; for instance, when acting as a client, there is no "server_hello" message type to remove, and similarly, when acting as a server, there is no "client_hello" message on that side, so there is no corresponding packet loss to simulate. LGTM. The removal of useless test cases isn't strictly necessary. The test cases that don't lose any messages usually complete under a second. If you really want to remove all useless cases, add an assertion that needPacketLoss is false at the end of the test. If you want to improve the run time even further, this test doesn't really need to use a DatagramSocket. With some effort it could be rewritten to exchange ByteBuffers directly between the SSLEngines, similar to what is done in [`test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java`](https://github.com/openjdk/jdk/blob/9c06dcb4396c3307d625663d92c0e11d794a56ea/test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java). Then you wouldn't need to wait for the timeout to expire, and instead you could retransmit the packets immediately after dropping them, or after making sure that the peer doesn't act. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27093#pullrequestreview-3188619440 From myankelevich at openjdk.org Fri Sep 5 09:32:16 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 5 Sep 2025 09:32:16 GMT Subject: RFR: 8366182: Some PKCS11Tests are being skipped when they shouldn't In-Reply-To: References: Message-ID: <5hycwamnD-PywMqYuZ74e1_sLnIQuC-QuyKgzbI0b74=.134e7713-5834-4bcd-9fe5-037d6e06e59d@github.com> On Thu, 4 Sep 2025 16:54:48 GMT, Matthew Donovan wrote: >> test/jdk/sun/security/pkcs11/Cipher/TestKATForGCM.java line 330: >> >>> 328: String osName = System.getProperty("os.name"); >>> 329: int idx = ver.indexOf("."); >>> 330: double major = Double.parseDouble(ver.substring(0, idx)); >> >> IMO the split between major version and minor is a bit hard to read. Wouldn't it be easier to just get a major.minor version entirely with something like: >> >> >> String[] splitParts = ver.split("//."); >> Double.parseDouble(splitParts.length > 1 >> ? splitParts[0] + "." + splitParts[1] >> : splitParts[0]); >> >> >> This way it will always take a full double value (1.13 will not be the same as 1.1, as it's now as far as I can see) and would be a bit easier to understand >> >> The checking for only major version could be either `doubleVersion<4 && doubleVersion>=3` or even cleaner, using floor function `Math.floor(doubleVersion)` >> >> And the same for the other files. >> >> What do you think? > > I may be misunderstanding your comment but it looks like you're using a single, `double` value to compare versions. The original code did that but it doesn't work in all cases. The problem occurs when checking a range such as > > `version >= 3.11 && version < 3.12` > > If the version number is 3.111, then the comparison is `true` and tests are skipped, even though _version_ 3.111 is "greater" than 3.12. So this code creates two doubles: `major` and `minor` to do separate comparisons of the values. > > To further complicate things, NSS also has versions of the form `x.y.z`. The original code combined the 'y' and 'z' components to go from 3.11.9 to 3.119. My change would create major version 3.0 and minor version 11.9. Ah, you're right, I didn't think of this case! This approach will be easier then, I agree. Still, `ver.substring(idx+1)` may cause errors in cases like this [NSS 3.15.3.1 release notes](https://nss-crypto.org/reference/security/nss/legacy/nss_releases/nss_3.15.3.1_release_notes/index.html#mozilla-projects-nss-nss-3-15-3-1-release-notes). It will try to convert 15.3.1 to a double. Do you think changing to something like this would be worth it? String verSubstring = ver.substring(idx+1); String[] splitParts = verSubstring.split("//."); Double minor = Double.parseDouble(splitParts.length > 1 ? splitParts[0] + "." + splitParts[1] : splitParts[0]); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27095#discussion_r2324586473 From fguallini at openjdk.org Fri Sep 5 10:34:34 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 5 Sep 2025 10:34:34 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java [v2] In-Reply-To: References: Message-ID: > The test javax/net/ssl/DTLS/PacketLossRetransmission takes about 2 minutes to complete. The reason is that the server or client socket times out after 10 seconds while waiting to receive a DatagramPacket that has already been removed (to simulate packet loss). Given that it will time out, it is better to reduce its value. > After reducing the timeout , the total test execution completes in approximately 15 seconds on average. > Additionally, unnecessary scenarios are removed; for instance, when acting as a client, there is no "server_hello" message type to remove, and similarly, when acting as a server, there is no "client_hello" message on that side, so there is no corresponding packet loss to simulate. It should keep only the scenarios that do lose messages. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: removal of useless tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27093/files - new: https://git.openjdk.org/jdk/pull/27093/files/0f41e62c..136c9dc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27093&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27093&range=00-01 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27093.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27093/head:pull/27093 PR: https://git.openjdk.org/jdk/pull/27093 From fguallini at openjdk.org Fri Sep 5 10:34:34 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 5 Sep 2025 10:34:34 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java [v2] In-Reply-To: <_9cnwuSg2mjxCwKnIej_zgVS5HrK-EeVMic6TQAQBD4=.e3ab678c-d7eb-4ae5-a28a-aa0912d86b2c@github.com> References: <_9cnwuSg2mjxCwKnIej_zgVS5HrK-EeVMic6TQAQBD4=.e3ab678c-d7eb-4ae5-a28a-aa0912d86b2c@github.com> Message-ID: <-b8kQ4uTm7asTTRlpcR6vNiUkoxSI9wQrAanIIY4vu0=.17f8551b-bbd3-4f92-aafd-5dada9debda3@github.com> On Fri, 5 Sep 2025 09:20:19 GMT, Daniel Jeli?ski wrote: > LGTM. The removal of useless test cases isn't strictly necessary. The test cases that don't lose any messages usually complete under a second. If you really want to remove all useless cases, add an assertion that needPacketLoss is false at the end of the test. > > If you want to improve the run time even further, this test doesn't really need to use a DatagramSocket. With some effort it could be rewritten to exchange ByteBuffers directly between the SSLEngines, similar to what is done in [`test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java`](https://github.com/openjdk/jdk/blob/9c06dcb4396c3307d625663d92c0e11d794a56ea/test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java). Then you wouldn't need to wait for the timeout to expire, and instead you could retransmit the packets immediately after dropping them, or after making sure that the peer doesn't act. Thank you for the review. I have now removed all useless cases, keeping only the ones that do actually lose messages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27093#issuecomment-3257872892 From mullan at openjdk.org Fri Sep 5 12:10:12 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 5 Sep 2025 12:10:12 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Core.java line 169: > 167: keyLength = 256; > 168: } > 169: /* commented out code ... src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1489: > 1487: final MacData macData; > 1488: > 1489: if (macAlgorithm.equals("PBMAC1")) { The PBMAC1 algorithms are already defined in the standard algorithm names spec, see https://download.java.net/java/early_access/jdk25/docs/specs/security/standard-names.html#mac-algorithms The default value of the `keystore.pkcs12.macAlgorithm` security property in the `java.security`file should be changed to "PBEWithHmacSHA256" as part of this change. So you don't need to check if the algorithm is "PBMAC1", just use the algorithm that the property is set to. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2324870945 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2324918183 From djelinski at openjdk.org Fri Sep 5 12:19:11 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 5 Sep 2025 12:19:11 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 10:34:34 GMT, Fernando Guallini wrote: >> The test javax/net/ssl/DTLS/PacketLossRetransmission takes about 2 minutes to complete. The reason is that the server or client socket times out after 10 seconds while waiting to receive a DatagramPacket that has already been removed (to simulate packet loss). Given that it will time out, it is better to reduce its value. >> After reducing the timeout , the total test execution completes in approximately 15 seconds on average. >> Additionally, unnecessary scenarios are removed; for instance, when acting as a client, there is no "server_hello" message type to remove, and similarly, when acting as a server, there is no "client_hello" message on that side, so there is no corresponding packet loss to simulate. It should keep only the scenarios that do lose messages. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > removal of useless tests test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java line 55: > 53: * @run main/othervm PacketLossRetransmission server 2 server_hello > 54: * @run main/othervm PacketLossRetransmission server 3 hello_verify_request > 55: * @run main/othervm -Djdk.tls.client.enableSessionTicketExtension=false PacketLossRetransmission server 4 new_session_ticket This one is odd. With `enableSessionTicketExtension=false`, the message is not sent. With the default setting of true, the message is sent, lost, and then the handshake fails with: javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified. This is a bug. Could you comment out the line instead? Something like: @comment run main/othervm PacketLossRetransmission server 4 new_session_ticket ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27093#discussion_r2324939292 From mullan at openjdk.org Fri Sep 5 13:06:12 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 5 Sep 2025 13:06:12 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1518: > 1516: macData = new MacData(algName, macResult, params, > 1517: defaultMacAlgorithm().replace("PBE", ""), > 1518: extraSalt, extraIterationCount); I'm not sure why you need the additional parameters (`params`, `extraSalt`, `extraIterationCount`). I think you can use the existing constructor and inside `MacData`, detect if PBMAC1 is being used by checking the algorithm name, and then encode the salt and iteration count in the PBMAC1 algorithm parameters as per RFC 7292/9579. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2325037355 From mullan at openjdk.org Fri Sep 5 13:11:12 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 5 Sep 2025 13:11:12 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 544: > 542: "com.sun.crypto.provider.PBES2Parameters$HmacSHA512_256AndAES_256"); > 543: > 544: psA("AlgorithmParameters", "PBMAC1", Why do we need to expose this as a standard `AlgorithmParameters` algorithm as part of this change? Maybe this would be useful later, but I don't think it is needed as this enhancement is just for internal use in PKCS12 KeyStore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2325052115 From weijun at openjdk.org Fri Sep 5 13:33:13 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 5 Sep 2025 13:33:13 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v4] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:26:02 GMT, Jamil Nimeh wrote: >> This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. >> >> Credit and thanks to @jaikiran for finding the issue and providing reproducer code. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in exception message Looks good. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27081#pullrequestreview-3189389898 From weijun at openjdk.org Fri Sep 5 13:36:12 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 5 Sep 2025 13:36:12 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 12:38:57 GMT, Matthew Donovan wrote: >> This PR extends security tests to use ByteBuffers backed by MemorySegments. Tests in the areas of Signature, Cipher, MessageDigest, and Mac are updated. > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - addressed PR comments and refactored to use try-with-resources > - Merge branch 'master' into cipher-ffm > - 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments There is a recent bug fix at https://github.com/openjdk/jdk/pull/27081 when a slice of an array-based buffer is used. Can you investigate why it has not been caught by this test? Should it be enhanced? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26967#issuecomment-3258377065 From myankelevich at openjdk.org Fri Sep 5 13:44:11 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 5 Sep 2025 13:44:11 GMT Subject: RFR: 8366817: test/jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java and JdkProcClient.java should not delete logs In-Reply-To: <168uceKQ-mqaigIebpwYvP0GaL2d0uynUzSqiHd6M-Q=.4a48511e-cc1b-44be-9019-407612df2e25@github.com> References: <168uceKQ-mqaigIebpwYvP0GaL2d0uynUzSqiHd6M-Q=.4a48511e-cc1b-44be-9019-407612df2e25@github.com> Message-ID: On Wed, 3 Sep 2025 17:02:11 GMT, Fernando Guallini wrote: > The following test helpers delete logs after the test completes: > jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java > jdk/javax/net/ssl/TLSCommon/interop/JdkProcClient.java > > These helpers are used by tests located in jdk/javax/net/ssl/compatibility/*.java. Instead of explicitly deleting logs, cleanup should be handled by JTREG, as with other tests. > > It is possible that the server process is still writing to this log when it tries to delete it, which could cause : > > `java.nio.file.FileSystemException: server.log: The process cannot access the file because it is being used by another process` Looks good to me. Could you just update the copyright dates please ------------- PR Review: https://git.openjdk.org/jdk/pull/27076#pullrequestreview-3189430478 From weijun at openjdk.org Fri Sep 5 13:45:12 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 5 Sep 2025 13:45:12 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers wrote: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) I cannot find a place how a new keystore can be generated using the new algorithm. I added `-J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256` to a keytool command and it fails: $ keytool -keystore ks -keyalg ec -storepass changeit -genkeypair -alias a -dname CN=a -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256 -debug Command line args: [-keystore, ks, -keyalg, ec, -storepass, changeit, -genkeypair, -alias, a, -dname, CN=a, -debug] Generating 384-bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days for: CN=a keytool error: java.io.IOException: Integrity check failed: java.security.NoSuchAlgorithmException: Algorithm HmacPBEHMACSHA256 not available Exception in thread "main" java.io.IOException: Integrity check failed: java.security.NoSuchAlgorithmException: Algorithm HmacPBEHMACSHA256 not available at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2204) at java.base/sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:226) at java.base/java.security.KeyStore.load(KeyStore.java:1502) at java.base/java.security.KeyStore.getInstance(KeyStore.java:1824) at java.base/java.security.KeyStore.getInstance(KeyStore.java:1708) at java.base/sun.security.tools.keytool.Main.doCommands(Main.java:1396) at java.base/sun.security.tools.keytool.Main.run(Main.java:422) at java.base/sun.security.tools.keytool.Main.main(Main.java:403) Caused by: java.security.NoSuchAlgorithmException: Algorithm HmacPBEHMACSHA256 not available at java.base/javax.crypto.Mac.getInstance(Mac.java:192) at java.base/sun.security.pkcs12.PKCS12KeyStore.processMacData(PKCS12KeyStore.java:1939) at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2198) ... 7 more The exception above is thrown after keytool generated the keystore and try to read some info from inside. The pkcs12 file seems invalid, its MacData is still the old format (not PBMAC1) with a problematic algorithm: ... 03CB:004C [2] SEQUENCE 03CD:0030 [20] SEQUENCE 03CF:000C [200] SEQUENCE 03D1:000A [2000] OID 1.2.840.113549.2.9 (HmacSHA256) 03DB:0022 [201] OCTET STRING (1410868021, 32 bytes) 0000: 5F 0D EA C5 9F 2B 66 B3 5D 7D A4 2A 13 CF EF E6 _....+f.]..*.... 0010: 09 D3 E1 57 6D D2 DB 14 AB B3 18 B0 F5 E3 4C B9 ...Wm.........L. 03FD:0016 [21] OCTET STRING (-1902982241, 20 bytes) 0000: 23 7C B7 7C AC BB 38 E7 23 15 69 15 43 F9 FB CC #.....8.#.i.C... 0010: C7 C7 92 0F .... 0413:0004 [22] INTEGER 10000 The OID at position [2000] used to be SHA-256. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24429#issuecomment-3258401867 From mdonovan at openjdk.org Fri Sep 5 13:46:51 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 5 Sep 2025 13:46:51 GMT Subject: RFR: 8366182: Some PKCS11Tests are being skipped when they shouldn't [v2] In-Reply-To: References: Message-ID: > This PR updates PKCS11 tests to better handle NSS version numbers. The previous code treated the version numbers as double values and used comparison operators. The problem is that it incorrectly treats 3.111 as between 3.11 and 3.12. This update parses and compares the major and minor version numbers separately. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: refactored to encapsulate the version as a record instead of doing repeated string parsing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27095/files - new: https://git.openjdk.org/jdk/pull/27095/files/c869d478..cd250fab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27095&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27095&range=00-01 Stats: 62 lines in 5 files changed: 18 ins; 17 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/27095.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27095/head:pull/27095 PR: https://git.openjdk.org/jdk/pull/27095 From mdonovan at openjdk.org Fri Sep 5 13:46:52 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 5 Sep 2025 13:46:52 GMT Subject: RFR: 8366182: Some PKCS11Tests are being skipped when they shouldn't [v2] In-Reply-To: <5hycwamnD-PywMqYuZ74e1_sLnIQuC-QuyKgzbI0b74=.134e7713-5834-4bcd-9fe5-037d6e06e59d@github.com> References: <5hycwamnD-PywMqYuZ74e1_sLnIQuC-QuyKgzbI0b74=.134e7713-5834-4bcd-9fe5-037d6e06e59d@github.com> Message-ID: <-BHKnXXO6ECfNJzV5Tdqt6MNMe9k6STL7cP07Ewk9hk=.d4268876-9f08-4ce1-bec7-6701cac17f16@github.com> On Fri, 5 Sep 2025 09:29:28 GMT, Mikhail Yankelevich wrote: >> I may be misunderstanding your comment but it looks like you're using a single, `double` value to compare versions. The original code did that but it doesn't work in all cases. The problem occurs when checking a range such as >> >> `version >= 3.11 && version < 3.12` >> >> If the version number is 3.111, then the comparison is `true` and tests are skipped, even though _version_ 3.111 is "greater" than 3.12. So this code creates two doubles: `major` and `minor` to do separate comparisons of the values. >> >> To further complicate things, NSS also has versions of the form `x.y.z`. The original code combined the 'y' and 'z' components to go from 3.11.9 to 3.119. My change would create major version 3.0 and minor version 11.9. > > Ah, you're right, I didn't think of this case! This approach will be easier then, I agree. > > Still, `ver.substring(idx+1)` may cause errors in cases like this [NSS 3.15.3.1 release notes](https://nss-crypto.org/reference/security/nss/legacy/nss_releases/nss_3.15.3.1_release_notes/index.html#mozilla-projects-nss-nss-3-15-3-1-release-notes). It will try to convert 15.3.1 to a double. Do you think changing to something like this would be worth it? > > > String verSubstring = ver.substring(idx+1); > String[] splitParts = verSubstring.split("//."); > Double minor = Double.parseDouble(splitParts.length > 1 > ? splitParts[0] + "." + splitParts[1] > : splitParts[0]); That's a good point about 4-component version numbers. Frankly, I was hoping that NSS never did that. I refactored the version parsing code to create a `Version` record with major, minor, and patch versions. This way, individual tests don't have to do the String parsing. If we end up with a test that has to be skipped due to that 4th component, we can update the parsing accordingly. Alternately, I can add it since I'm here now... what is that fourth component called? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27095#discussion_r2325142358 From fguallini at openjdk.org Fri Sep 5 13:57:29 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 5 Sep 2025 13:57:29 GMT Subject: RFR: 8366817: test/jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java and JdkProcClient.java should not delete logs [v2] In-Reply-To: <168uceKQ-mqaigIebpwYvP0GaL2d0uynUzSqiHd6M-Q=.4a48511e-cc1b-44be-9019-407612df2e25@github.com> References: <168uceKQ-mqaigIebpwYvP0GaL2d0uynUzSqiHd6M-Q=.4a48511e-cc1b-44be-9019-407612df2e25@github.com> Message-ID: > The following test helpers delete logs after the test completes: > jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java > jdk/javax/net/ssl/TLSCommon/interop/JdkProcClient.java > > These helpers are used by tests located in jdk/javax/net/ssl/compatibility/*.java. Instead of explicitly deleting logs, cleanup should be handled by JTREG, as with other tests. > > It is possible that the server process is still writing to this log when it tries to delete it, which could cause : > > `java.nio.file.FileSystemException: server.log: The process cannot access the file because it is being used by another process` Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27076/files - new: https://git.openjdk.org/jdk/pull/27076/files/66bef867..ca980721 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27076&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27076&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27076/head:pull/27076 PR: https://git.openjdk.org/jdk/pull/27076 From myankelevich at openjdk.org Fri Sep 5 14:09:12 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 5 Sep 2025 14:09:12 GMT Subject: RFR: 8366182: Some PKCS11Tests are being skipped when they shouldn't [v2] In-Reply-To: <-BHKnXXO6ECfNJzV5Tdqt6MNMe9k6STL7cP07Ewk9hk=.d4268876-9f08-4ce1-bec7-6701cac17f16@github.com> References: <5hycwamnD-PywMqYuZ74e1_sLnIQuC-QuyKgzbI0b74=.134e7713-5834-4bcd-9fe5-037d6e06e59d@github.com> <-BHKnXXO6ECfNJzV5Tdqt6MNMe9k6STL7cP07Ewk9hk=.d4268876-9f08-4ce1-bec7-6701cac17f16@github.com> Message-ID: On Fri, 5 Sep 2025 13:43:04 GMT, Matthew Donovan wrote: >> Ah, you're right, I didn't think of this case! This approach will be easier then, I agree. >> >> Still, `ver.substring(idx+1)` may cause errors in cases like this [NSS 3.15.3.1 release notes](https://nss-crypto.org/reference/security/nss/legacy/nss_releases/nss_3.15.3.1_release_notes/index.html#mozilla-projects-nss-nss-3-15-3-1-release-notes). It will try to convert 15.3.1 to a double. Do you think changing to something like this would be worth it? >> >> >> String verSubstring = ver.substring(idx+1); >> String[] splitParts = verSubstring.split("//."); >> Double minor = Double.parseDouble(splitParts.length > 1 >> ? splitParts[0] + "." + splitParts[1] >> : splitParts[0]); > > That's a good point about 4-component version numbers. Frankly, I was hoping that NSS never did that. I refactored the version parsing code to create a `Version` record with major, minor, and patch versions. This way, individual tests don't have to do the String parsing. If we end up with a test that has to be skipped due to that 4th component, we can update the parsing accordingly. Alternately, I can add it since I'm here now... what is that fourth component called? Thank you for the changes! I'm not sure if it's even needed to be honest, it would be an overkill imo. I can't find the exact naming on the nss website, but I think the common one would be `major.minor.patch.hotfix` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27095#discussion_r2325202374 From jpai at openjdk.org Fri Sep 5 15:25:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Sep 2025 15:25:14 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v4] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:26:02 GMT, Jamil Nimeh wrote: >> This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. >> >> Credit and thanks to @jaikiran for finding the issue and providing reproducer code. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in exception message Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27081#pullrequestreview-3189801167 From mdonovan at openjdk.org Fri Sep 5 15:37:12 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 5 Sep 2025 15:37:12 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v4] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:26:02 GMT, Jamil Nimeh wrote: >> This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. >> >> Credit and thanks to @jaikiran for finding the issue and providing reproducer code. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in exception message test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/UpdateAADTest.java line 56: > 54: > 55: public static void main(final String[] args) throws Exception { > 56: ByteBuffer twoKBuf = ByteBuffer.allocate(2048); Is it relevant to include a test case for MemorySegment-backed ByteBuffers? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27081#discussion_r2325420966 From mdonovan at openjdk.org Fri Sep 5 15:58:12 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 5 Sep 2025 15:58:12 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments [v2] In-Reply-To: References: Message-ID: <6yYQH0LzQtqFQHwDMT9Oo0Eg-M17gbHvJIU9k28lhvk=.64d3fd10-ac6d-4ba5-b787-0f2e932887b2@github.com> On Tue, 2 Sep 2025 12:38:57 GMT, Matthew Donovan wrote: >> This PR extends security tests to use ByteBuffers backed by MemorySegments. Tests in the areas of Signature, Cipher, MessageDigest, and Mac are updated. > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - addressed PR comments and refactored to use try-with-resources > - Merge branch 'master' into cipher-ffm > - 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments > There is a recent bug fix at #27081 when a slice of an array-based buffer is used. Can you investigate why it has not been caught by this test? Should it be enhanced? Thanks. There are a lot of tests under `test/jdk/com/sun/crypto/provider` that I didn't look at. There are some that explicitly test ByteBuffers (such as `Cipher/AEAD/OverlapByteBuffer.java`) and others that could possibly be extended to include them. I think updating all the tests would be unnecessary but I can update the tests that explicitly use ByteBuffer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26967#issuecomment-3258867557 From mdonovan at openjdk.org Fri Sep 5 16:29:26 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 5 Sep 2025 16:29:26 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments [v3] In-Reply-To: References: Message-ID: <-iQorC-PWZRBEzVpBYy4__wOpcujJc_BSyomkf-5iOk=.37602150-82d6-4323-80fa-c5f0ffd0fbe6@github.com> > This PR extends security tests to use ByteBuffers backed by MemorySegments. Tests in the areas of Signature, Cipher, MessageDigest, and Mac are updated. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: added null-check for arena argument ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26967/files - new: https://git.openjdk.org/jdk/pull/26967/files/b0e61bbb..16991bab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26967&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26967&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26967/head:pull/26967 PR: https://git.openjdk.org/jdk/pull/26967 From jnimeh at openjdk.org Fri Sep 5 16:34:14 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 5 Sep 2025 16:34:14 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v4] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 15:35:02 GMT, Matthew Donovan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in exception message > > test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/UpdateAADTest.java line 56: > >> 54: >> 55: public static void main(final String[] args) throws Exception { >> 56: ByteBuffer twoKBuf = ByteBuffer.allocate(2048); > > Is it relevant to include a test case for MemorySegment-backed ByteBuffers? It depends on how the MemorySegment is made, I think. If something like `MemorySegment.ofArray(new byte[2048])` were to be used and a ByteBuffer created from that, I believe the `hasArray()` method would return true and therefore would fall into this code path. I'll make a test case using an array-backed MemorySegment and see what happens with both non-sliced and sliced ByteBuffers are used. I was planning on doing some rewrites on this test anyway to handle a test case @ferakocz wanted so I'll include this as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27081#discussion_r2325537785 From valeriep at openjdk.org Fri Sep 5 21:14:16 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 5 Sep 2025 21:14:16 GMT Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java [v3] In-Reply-To: <0XADRuvWc-HhIE4exZUSxniPKI9zwGMD_bkcFWv-Tns=.02e3a87f-1dff-4071-9ab5-11a729fbf9ba@github.com> References: <0XADRuvWc-HhIE4exZUSxniPKI9zwGMD_bkcFWv-Tns=.02e3a87f-1dff-4071-9ab5-11a729fbf9ba@github.com> Message-ID: On Wed, 3 Sep 2025 00:22:16 GMT, Thomas Fitzsimmons wrote: >> This patch adds configurability to `PKCS11Test.java`. >> >> Specifically, it adds two new system properties: >> >> - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the `nss_library` field. Prior to this patch, `nss_library` was set to either `"softokn3"` or `"nss3"`. >> >> - `CUSTOM_P11_CONFIG_VARIANT`: Abstract the configuration file type to load. Prior to this patch, test cases that wanted to run `NSS` in sensitive mode would hard-code `p11-nss-sensitive.txt` on their command lines. >> >> The patch updates the three `p11-nss-sensitive.txt`-using test cases to use the new `CUSTOM_P11_CONFIG_VARIANT` property: >> >> >> test/jdk/java/security/KeyAgreement/Generic.java >> test/jdk/sun/security/pkcs11/Mac/TestLargeSecretKeys.java >> test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java >> >> >> I have been using this change to run `PKCS11Test.java` against the [Kryoptic](https://github.com/latchset/kryoptic) PKCS11 soft token, using this invocation: >> >> >> make test \ >> JTREG="JAVA_OPTIONS=-DCUSTOM_P11_CONFIG=/tmp/kryoptic-configuration/p11-kryoptic.txt \ >> -DCUSTOM_P11_LIBRARY_NAME=kryoptic_pkcs11 \ >> -Djdk.test.lib.artifacts.nsslib-linux_x64=/tmp/kryoptic-configuration \ >> -DCUSTOM_DB_DIR=/tmp/kryoptic-configuration" >> >> >> `/tmp/kryoptic-configuration` contains (among other files): >> >> >> libkryoptic_pkcs11.so >> p11-kryoptic.txt >> p11-kryoptic-sensitive.txt >> >> >> With `CUSTOM_P11_LIBRARY_NAME` set, `PKCS11Test.java` can find `libkryoptic_pkcs11.so`. >> >> And setting `CUSTOM_P11_CONFIG` causes the sensitive tests to use `p11-kryoptic-sensitive.txt` via the new `CUSTOM_P11_CONFIG_VARIANT` property. >> >> On my `Fedora 42` `x86-64` machine, I tested for regressions with: >> >> $ time make test JOBS=4 JTREG="JAVA_OPTIONS=-Djdk.test.lib.artifacts.nsslib-linux_x64=/usr/lib64" TEST="test/jdk/sun/security/pkcs11" >> >> and: >> >> $ time make test JOBS=4 TEST="test/jdk/sun/security/pkcs11" > > Thomas Fitzsimmons has updated the pull request incrementally with one additional commit since the last revision: > > Remove CUSTOM_P11_CONFIG_VARIANT, add CUSTOM_P11_BASE_DIR Have a short vacay coming up, will resume review next Wed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26325#issuecomment-3259760075 From weijun at openjdk.org Sat Sep 6 01:12:14 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 6 Sep 2025 01:12:14 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: <0ub8yevcVcLcmGSHH4edEdSjfrUwW5rAw140-Q4VuUM=.82ba246e-eae9-4b1b-a2d1-f43e8530da1b@github.com> References: <0ub8yevcVcLcmGSHH4edEdSjfrUwW5rAw140-Q4VuUM=.82ba246e-eae9-4b1b-a2d1-f43e8530da1b@github.com> Message-ID: On Thu, 4 Sep 2025 23:37:52 GMT, Naoto Sato wrote: >> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 133: >> >>> 131: Charset.forName(StaticProperty.stdinEncoding(), UTF_8.INSTANCE), >>> 132: Charset.forName(StaticProperty.stdoutEncoding(), UTF_8.INSTANCE))) : >>> 133: Optional.empty(); >> >> (Finally getting back to this.) >> >> The code returns an Optional containing a JdkConsoleImpl instance, or an empty Optional. However the comment above says it returns a JdkConsoleImpl instance or null. Which do we want it to be? Either is OK, but the comment should agree with the code. >> >> I think @wangweij might want to weigh in here since his code will be calling this. > > Ah, yes. Comment does not align with the code. I am fine either way too. Either is OK. `Optional` sounds more modern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2326325423 From weijun at openjdk.org Sat Sep 6 15:49:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 6 Sep 2025 15:49:11 GMT Subject: RFR: 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom [v3] In-Reply-To: <-yJlJYEHVRkbGTv6fgS4tcKS97RktKNhU9AaD3It9Y0=.d31c780b-798f-4592-8e75-95655e814686@github.com> References: <-yJlJYEHVRkbGTv6fgS4tcKS97RktKNhU9AaD3It9Y0=.d31c780b-798f-4592-8e75-95655e814686@github.com> Message-ID: On Thu, 4 Sep 2025 15:02:02 GMT, Mikhail Yankelevich wrote: >> Skipped tests are treated as a pass: >> >> * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java >> * test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java >> * test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java >> * test/jdk/sun/security/pkcs11/SecureRandom/Basic.java >> * test/jdk/sun/security/pkcs11/SecureRandom/TestDeserialization.java > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > waiting for all tests to run before skipping test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java line 128: > 126: test("Blowfish", bf_128Key, p, TestResult.PASS); > 127: } catch (SkippedException skippedException){ > 128: skippedList.add(skippedException.getMessage()); Can we add a `skippedException.printStackTrace()` here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26942#discussion_r2327753529 From swen at openjdk.org Mon Sep 8 02:27:10 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 8 Sep 2025 02:27:10 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> > This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. > > Changes include: > > 1. New `appendPair` method for efficient two-digit integer formatting (00-99): > - Added `AbstractStringBuilder.appendPair(int i)` with core implementation > - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access > - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge > - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method > - Enhanced Javadoc documentation for all new methods > > 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: > - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` > - Replaced manual formatting logic with the new efficient two-digit appending > - Improved code clarity and consistency in date/time formatting > > These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge remote-tracking branch 'upstream/master' into appendPair_202508 # Conflicts: # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding - Use DecimalDigits.appendPair for formatting in time classes This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. Co-authored-by: Qwen-Coder - Optimize year formatting in DateTimeHelper by reducing modulo operation Co-authored-by: Qwen-Coder Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. Co-authored-by: Qwen-Coder - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. Co-authored-by: Qwen-Coder ------------- Changes: https://git.openjdk.org/jdk/pull/26911/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=03 Stats: 199 lines in 10 files changed: 168 ins; 4 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/26911.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911 PR: https://git.openjdk.org/jdk/pull/26911 From djelinski at openjdk.org Mon Sep 8 07:27:12 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 8 Sep 2025 07:27:12 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 12:16:48 GMT, Daniel Jeli?ski wrote: >> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: >> >> removal of useless tests > > test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java line 55: > >> 53: * @run main/othervm PacketLossRetransmission server 2 server_hello >> 54: * @run main/othervm PacketLossRetransmission server 3 hello_verify_request >> 55: * @run main/othervm -Djdk.tls.client.enableSessionTicketExtension=false PacketLossRetransmission server 4 new_session_ticket > > This one is odd. > > With `enableSessionTicketExtension=false`, the message is not sent. With the default setting of true, the message is sent, lost, and then the handshake fails with: > > javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified. > > This is a bug. > > Could you comment out the line instead? Something like: > > @comment run main/othervm PacketLossRetransmission server 4 new_session_ticket actually let me file a bug for this... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27093#discussion_r2329370843 From djelinski at openjdk.org Mon Sep 8 07:48:11 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 8 Sep 2025 07:48:11 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 10:34:34 GMT, Fernando Guallini wrote: >> The test javax/net/ssl/DTLS/PacketLossRetransmission takes about 2 minutes to complete. The reason is that the server or client socket times out after 10 seconds while waiting to receive a DatagramPacket that has already been removed (to simulate packet loss). Given that it will time out, it is better to reduce its value. >> After reducing the timeout , the total test execution completes in approximately 15 seconds on average. >> Additionally, unnecessary scenarios are removed; for instance, when acting as a client, there is no "server_hello" message type to remove, and similarly, when acting as a server, there is no "client_hello" message on that side, so there is no corresponding packet loss to simulate. It should keep only the scenarios that do lose messages. > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > removal of useless tests Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27093#pullrequestreview-3195340661 From djelinski at openjdk.org Mon Sep 8 07:48:12 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 8 Sep 2025 07:48:12 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java [v2] In-Reply-To: References: Message-ID: <4FB4PtuXWQVPcuJQc3WwT-OFwquy4QzNrsfYyiEu01s=.e39128ac-ab49-4e24-a482-208462c1aa20@github.com> On Mon, 8 Sep 2025 07:24:15 GMT, Daniel Jeli?ski wrote: >> test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java line 55: >> >>> 53: * @run main/othervm PacketLossRetransmission server 2 server_hello >>> 54: * @run main/othervm PacketLossRetransmission server 3 hello_verify_request >>> 55: * @run main/othervm -Djdk.tls.client.enableSessionTicketExtension=false PacketLossRetransmission server 4 new_session_ticket >> >> This one is odd. >> >> With `enableSessionTicketExtension=false`, the message is not sent. With the default setting of true, the message is sent, lost, and then the handshake fails with: >> >> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified. >> >> This is a bug. >> >> Could you comment out the line instead? Something like: >> >> @comment run main/othervm PacketLossRetransmission server 4 new_session_ticket > > actually let me file a bug for this... [JDK-8367059](https://bugs.openjdk.org/browse/JDK-8367059) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27093#discussion_r2329414272 From myankelevich at openjdk.org Mon Sep 8 10:18:47 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 8 Sep 2025 10:18:47 GMT Subject: RFR: 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom [v4] In-Reply-To: References: Message-ID: > Skipped tests are treated as a pass: > > * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java > * test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java > * test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java > * test/jdk/sun/security/pkcs11/SecureRandom/Basic.java > * test/jdk/sun/security/pkcs11/SecureRandom/TestDeserialization.java Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: added print stack trace for the system out ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26942/files - new: https://git.openjdk.org/jdk/pull/26942/files/b9d3f123..7a16f494 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26942&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26942&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26942/head:pull/26942 PR: https://git.openjdk.org/jdk/pull/26942 From myankelevich at openjdk.org Mon Sep 8 10:18:48 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 8 Sep 2025 10:18:48 GMT Subject: RFR: 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom [v3] In-Reply-To: References: <-yJlJYEHVRkbGTv6fgS4tcKS97RktKNhU9AaD3It9Y0=.d31c780b-798f-4592-8e75-95655e814686@github.com> Message-ID: On Sat, 6 Sep 2025 15:46:54 GMT, Weijun Wang wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> waiting for all tests to run before skipping > > test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java line 128: > >> 126: test("Blowfish", bf_128Key, p, TestResult.PASS); >> 127: } catch (SkippedException skippedException){ >> 128: skippedList.add(skippedException.getMessage()); > > Can we add a `skippedException.printStackTrace()` here? Sure, done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26942#discussion_r2329795725 From fguallini at openjdk.org Mon Sep 8 12:41:12 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Mon, 8 Sep 2025 12:41:12 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java [v2] In-Reply-To: <4FB4PtuXWQVPcuJQc3WwT-OFwquy4QzNrsfYyiEu01s=.e39128ac-ab49-4e24-a482-208462c1aa20@github.com> References: <4FB4PtuXWQVPcuJQc3WwT-OFwquy4QzNrsfYyiEu01s=.e39128ac-ab49-4e24-a482-208462c1aa20@github.com> Message-ID: On Mon, 8 Sep 2025 07:44:13 GMT, Daniel Jeli?ski wrote: >> actually let me file a bug for this... > > [JDK-8367059](https://bugs.openjdk.org/browse/JDK-8367059) Thanks for filing it ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27093#discussion_r2330116503 From abarashev at openjdk.org Mon Sep 8 13:40:13 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 8 Sep 2025 13:40:13 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v4] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 05:16:53 GMT, Nibedita Jena wrote: > Can a usecase be added for jdk.tls.server.disableExtensions if this option is being considered. Yes, added a test, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26887#issuecomment-3266374082 From weijun at openjdk.org Mon Sep 8 14:03:14 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 8 Sep 2025 14:03:14 GMT Subject: RFR: 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom [v4] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 10:18:47 GMT, Mikhail Yankelevich wrote: >> Skipped tests are treated as a pass: >> >> * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java >> * test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java >> * test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java >> * test/jdk/sun/security/pkcs11/SecureRandom/Basic.java >> * test/jdk/sun/security/pkcs11/SecureRandom/TestDeserialization.java > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > added print stack trace for the system out Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26942#pullrequestreview-3196688954 From duke at openjdk.org Mon Sep 8 14:06:16 2025 From: duke at openjdk.org (duke) Date: Mon, 8 Sep 2025 14:06:16 GMT Subject: RFR: 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom [v4] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 10:18:47 GMT, Mikhail Yankelevich wrote: >> Skipped tests are treated as a pass: >> >> * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java >> * test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java >> * test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java >> * test/jdk/sun/security/pkcs11/SecureRandom/Basic.java >> * test/jdk/sun/security/pkcs11/SecureRandom/TestDeserialization.java > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > added print stack trace for the system out @myankelev Your change (at version 7a16f494b366b44699fd00e6d4a3db59b6048a6b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26942#issuecomment-3266487307 From myankelevich at openjdk.org Mon Sep 8 14:40:19 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 8 Sep 2025 14:40:19 GMT Subject: Integrated: 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:49:33 GMT, Mikhail Yankelevich wrote: > Skipped tests are treated as a pass: > > * test/jdk/sun/security/pkcs11/KeyStore/ClientAuth.java > * test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java > * test/jdk/sun/security/pkcs11/SecretKeyFactory/TestGeneral.java > * test/jdk/sun/security/pkcs11/SecureRandom/Basic.java > * test/jdk/sun/security/pkcs11/SecureRandom/TestDeserialization.java This pull request has now been integrated. Changeset: 166ef5e7 Author: Mikhail Yankelevich Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/166ef5e7b1c6d6a9f0f1f29fedb7f65b94f53119 Stats: 59 lines in 5 files changed: 25 ins; 7 del; 27 mod 8366159: SkippedException is treated as a pass for pkcs11/KeyStore, pkcs11/SecretKeyFactory and pkcs11/SecureRandom Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/26942 From abarashev at openjdk.org Mon Sep 8 15:36:19 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 8 Sep 2025 15:36:19 GMT Subject: Withdrawn: 8366211: Block signature scheme names to be used with CertificateSignature algorithm constraints usage In-Reply-To: <6wPIjQW0SE1OR9ApU2_YGiP-HdfqCmsvLDeRr_UF7hI=.c5fa6432-f070-4fad-988a-6ee2c4063648@github.com> References: <6wPIjQW0SE1OR9ApU2_YGiP-HdfqCmsvLDeRr_UF7hI=.c5fa6432-f070-4fad-988a-6ee2c4063648@github.com> Message-ID: <8O-un1G55xjQz0WJEwC0MtwgP4MHog9-jThh0df2Gps=.56d5807a-8b88-46a2-8348-bf002bb3db1f@github.com> On Wed, 27 Aug 2025 19:04:20 GMT, Artur Barashev wrote: > To avoid any user confusion, we should block signature scheme names to be used with `CertificateSignature` algorithm constraints usage. For example, `RSASSA-PSS` certificate signature algorithm corresponds to multiple signature scheme names and blocking one of those signature scheme with `CertificateSignature` usage directive won't block `RSASSA-PSS` certificate signature because other rsa_pss_* signature schemes still will be allowed. We should direct users to use certificate signature algorithm with `CertificateSignature` usage directive. For example: > > - To be blocked: "rsa_pss_pss_sha256 usage CertificateSignature" > - To be allowed: `RSASSA-PSS usage CertificateSignature` or `RSA usage CertificateSignature` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26970 From abarashev at openjdk.org Mon Sep 8 15:36:50 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 8 Sep 2025 15:36:50 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints Message-ID: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against algorithm constraints. ------------- Commit messages: - 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints Changes: https://git.openjdk.org/jdk/pull/27146/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367104 Stats: 513 lines in 8 files changed: 353 ins; 114 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From naoto at openjdk.org Mon Sep 8 16:34:29 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Sep 2025 16:34:29 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v6] In-Reply-To: References: Message-ID: > Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26973/files - new: https://git.openjdk.org/jdk/pull/26973/files/ff7e9e0d..9306bc0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26973.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26973/head:pull/26973 PR: https://git.openjdk.org/jdk/pull/26973 From naoto at openjdk.org Mon Sep 8 16:34:29 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Sep 2025 16:34:29 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: References: <0ub8yevcVcLcmGSHH4edEdSjfrUwW5rAw140-Q4VuUM=.82ba246e-eae9-4b1b-a2d1-f43e8530da1b@github.com> Message-ID: <30fJ-qVeGVgkAj05nx8d5zyCYQ5esO3-i69q-Avym-M=.739bf041-d54e-4f2f-8ee2-0d1381c9f955@github.com> On Sat, 6 Sep 2025 01:09:04 GMT, Weijun Wang wrote: >> Ah, yes. Comment does not align with the code. I am fine either way too. > > Either is OK. `Optional` sounds more modern and forces me to consider the empty case. Fixed the comment to agree with the code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2330771936 From abarashev at openjdk.org Mon Sep 8 21:56:55 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 8 Sep 2025 21:56:55 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v2] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: More test cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/1826754b..33c27040 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=00-01 Stats: 28 lines in 2 files changed: 12 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From smarks at openjdk.org Tue Sep 9 04:47:11 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 9 Sep 2025 04:47:11 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v6] In-Reply-To: References: Message-ID: <5G_q7CDPPcLuo8d8C3GyeJht2Za6lM8-zFmXPu6BRoY=.07193205-3fc5-494d-922f-7e2999ea5e87@github.com> On Mon, 8 Sep 2025 16:34:29 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Looks good. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26973#pullrequestreview-3199187546 From myankelevich at openjdk.org Tue Sep 9 09:08:50 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 9 Sep 2025 09:08:50 GMT Subject: RFR: 8367096: jdk/open/test/jdk/sun/security/pkcs11/ rsa, ec, config, secmod and sslecc tests are skipping but showing as pass Message-ID: Tests changed: * test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java * test/jdk/sun/security/pkcs11/PKCS11Test.java * test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java * test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java * test/jdk/sun/security/pkcs11/Secmod/Crypto.java * test/jdk/sun/security/pkcs11/Secmod/GetPrivateKey.java * test/jdk/sun/security/pkcs11/Secmod/JksSetPrivateKey.java * test/jdk/sun/security/pkcs11/Secmod/LoadKeystore.java * test/jdk/sun/security/pkcs11/Secmod/TestNssDbSqlite.java * test/jdk/sun/security/pkcs11/Secmod/TrustAnchors.java * test/jdk/sun/security/pkcs11/SecmodTest.java * test/jdk/sun/security/pkcs11/ec/ReadCertificates.java * test/jdk/sun/security/pkcs11/ec/ReadPKCS12.java * test/jdk/sun/security/pkcs11/ec/TestKeyFactory.java * test/jdk/sun/security/pkcs11/rsa/KeyWrap.java * test/jdk/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java ------------- Commit messages: - JDK-8367096: jdk/open/test/jdk/sun/security/pkcs11/rsa/ and jdk/open/test/jdk/sun/security/pkcs11/ec tests are skipping but showing as pass Changes: https://git.openjdk.org/jdk/pull/27166/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27166&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367096 Stats: 79 lines in 16 files changed: 9 ins; 39 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/27166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27166/head:pull/27166 PR: https://git.openjdk.org/jdk/pull/27166 From mdonovan at openjdk.org Tue Sep 9 11:29:12 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 9 Sep 2025 11:29:12 GMT Subject: RFR: 8367096: jdk/open/test/jdk/sun/security/pkcs11/ rsa, ec, config, secmod and sslecc tests are skipping but showing as pass In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 09:02:03 GMT, Mikhail Yankelevich wrote: > Tests changed: > * test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java > * test/jdk/sun/security/pkcs11/PKCS11Test.java > * test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java > * test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java > * test/jdk/sun/security/pkcs11/Secmod/Crypto.java > * test/jdk/sun/security/pkcs11/Secmod/GetPrivateKey.java > * test/jdk/sun/security/pkcs11/Secmod/JksSetPrivateKey.java > * test/jdk/sun/security/pkcs11/Secmod/LoadKeystore.java > * test/jdk/sun/security/pkcs11/Secmod/TestNssDbSqlite.java > * test/jdk/sun/security/pkcs11/Secmod/TrustAnchors.java > * test/jdk/sun/security/pkcs11/SecmodTest.java > * test/jdk/sun/security/pkcs11/ec/ReadCertificates.java > * test/jdk/sun/security/pkcs11/ec/ReadPKCS12.java > * test/jdk/sun/security/pkcs11/ec/TestKeyFactory.java > * test/jdk/sun/security/pkcs11/rsa/KeyWrap.java > * test/jdk/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java Looks good to me, just some minor suggestions on the exception messages. Don't feel like you have to change them if you like them as-is. test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java line 51: > 49: Provider p = Security.getProvider("SunPKCS11"); > 50: if (p == null) { > 51: throw new SkippedException("Skipping test - no PKCS11 provider available"); minor wording nit: you don't need to say "skipping test" in the message of a SkippedException. test/jdk/sun/security/pkcs11/PKCS11Test.java line 784: > 782: private void premain(Provider p) throws Exception { > 783: if (skipTest(p)) { > 784: throw new SkippedException("Test is skipped due to skipTest() result, please see the log"); maybe the message could just say "See logs for details"? Ideally, I think we'd just refactor `skipTest()` into something like `checkSkippedTest()` and the method itself threw the SkippedException but that would require a lot of refactoring. test/jdk/sun/security/pkcs11/ec/ReadCertificates.java line 82: > 80: public void main(Provider p) throws Exception { > 81: if (p.getService("Signature", "SHA1withECDSA") == null) { > 82: throw new SkippedException("Provider does not support ECDSA, skipping..."); here (and the other ec/, rsa/, sslecc/ tests), you could remove the "skipping..." from the message. ------------- PR Review: https://git.openjdk.org/jdk/pull/27166#pullrequestreview-3200992297 PR Review Comment: https://git.openjdk.org/jdk/pull/27166#discussion_r2333143784 PR Review Comment: https://git.openjdk.org/jdk/pull/27166#discussion_r2333150305 PR Review Comment: https://git.openjdk.org/jdk/pull/27166#discussion_r2333155959 From myankelevich at openjdk.org Tue Sep 9 12:56:28 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 9 Sep 2025 12:56:28 GMT Subject: RFR: 8367096: jdk/open/test/jdk/sun/security/pkcs11/ rsa, ec, config, secmod and sslecc tests are skipping but showing as pass [v2] In-Reply-To: References: Message-ID: > Tests changed: > * test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java > * test/jdk/sun/security/pkcs11/PKCS11Test.java > * test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java > * test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java > * test/jdk/sun/security/pkcs11/Secmod/Crypto.java > * test/jdk/sun/security/pkcs11/Secmod/GetPrivateKey.java > * test/jdk/sun/security/pkcs11/Secmod/JksSetPrivateKey.java > * test/jdk/sun/security/pkcs11/Secmod/LoadKeystore.java > * test/jdk/sun/security/pkcs11/Secmod/TestNssDbSqlite.java > * test/jdk/sun/security/pkcs11/Secmod/TrustAnchors.java > * test/jdk/sun/security/pkcs11/SecmodTest.java > * test/jdk/sun/security/pkcs11/ec/ReadCertificates.java > * test/jdk/sun/security/pkcs11/ec/ReadPKCS12.java > * test/jdk/sun/security/pkcs11/ec/TestKeyFactory.java > * test/jdk/sun/security/pkcs11/rsa/KeyWrap.java > * test/jdk/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: Matthew's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27166/files - new: https://git.openjdk.org/jdk/pull/27166/files/dc075fcd..b40b6ee4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27166&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27166&range=00-01 Stats: 5 lines in 5 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27166/head:pull/27166 PR: https://git.openjdk.org/jdk/pull/27166 From myankelevich at openjdk.org Tue Sep 9 12:56:30 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 9 Sep 2025 12:56:30 GMT Subject: RFR: 8367096: jdk/open/test/jdk/sun/security/pkcs11/ rsa, ec, config, secmod and sslecc tests are skipping but showing as pass [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 11:19:06 GMT, Matthew Donovan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Matthew's comments > > test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java line 51: > >> 49: Provider p = Security.getProvider("SunPKCS11"); >> 50: if (p == null) { >> 51: throw new SkippedException("Skipping test - no PKCS11 provider available"); > > minor wording nit: you don't need to say "skipping test" in the message of a SkippedException. Done in the next commit > test/jdk/sun/security/pkcs11/PKCS11Test.java line 784: > >> 782: private void premain(Provider p) throws Exception { >> 783: if (skipTest(p)) { >> 784: throw new SkippedException("Test is skipped due to skipTest() result, please see the log"); > > maybe the message could just say "See logs for details"? Ideally, I think we'd just refactor `skipTest()` into something like `checkSkippedTest()` and the method itself threw the SkippedException but that would require a lot of refactoring. I agree, this can just say "See logs for details", should be done in the next commit. Refactoring skipTest will cause a change in classes that have methods overwriting this one. I'm not convinced that such a large change would be feasible given that overwritten methods log the errors anyway. > test/jdk/sun/security/pkcs11/ec/ReadCertificates.java line 82: > >> 80: public void main(Provider p) throws Exception { >> 81: if (p.getService("Signature", "SHA1withECDSA") == null) { >> 82: throw new SkippedException("Provider does not support ECDSA, skipping..."); > > here (and the other ec/, rsa/, sslecc/ tests), you could remove the "skipping..." from the message. Done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27166#discussion_r2333459439 PR Review Comment: https://git.openjdk.org/jdk/pull/27166#discussion_r2333452857 PR Review Comment: https://git.openjdk.org/jdk/pull/27166#discussion_r2333458924 From mullan at openjdk.org Tue Sep 9 15:05:47 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 9 Sep 2025 15:05:47 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v2] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Mon, 8 Sep 2025 21:56:55 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against algorithm constraints. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > More test cases src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 1453: > 1451: } > 1452: > 1453: // try the best to check the algorithm constraints Not part of your change, but can you remove the words "try the best to" - those words make it sound like it will pass even if the constraint checks fail. Also on line 1478. src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1408: > 1406: > 1407: /** > 1408: * Gets an array of supported signature schemes that the peer is s/an array/a collection/ src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1409: > 1407: /** > 1408: * Gets an array of supported signature schemes that the peer is > 1409: * willing to verify. Those are sent with "signature_algorithms_cert" s/with/with the/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2333935494 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2333917670 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2333918641 From weijun at openjdk.org Tue Sep 9 15:29:44 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 Sep 2025 15:29:44 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v6] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 16:34:29 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 137: > 135: } > 136: > 137: // Dedicated entry for sun.security.util.Password. To be more clear, I suggest this comment: // Dedicated entry for sun.security.util.Password when stdout is redirected. // This method strictly avoids producing any output by using noNewLine = true // and an empty format string. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2334014703 From abarashev at openjdk.org Tue Sep 9 16:02:27 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 16:02:27 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v2] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Tue, 9 Sep 2025 14:55:12 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> More test cases > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1408: > >> 1406: >> 1407: /** >> 1408: * Gets an array of supported signature schemes that the peer is > > s/an array/a collection/ Done, thanks! > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1409: > >> 1407: /** >> 1408: * Gets an array of supported signature schemes that the peer is >> 1409: * willing to verify. Those are sent with "signature_algorithms_cert" > > s/with/with the/ Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334106049 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334107052 From abarashev at openjdk.org Tue Sep 9 16:06:42 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 16:06:42 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v2] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: <1G3mEx6aEYgTaiLP5FpdTpSaqSybfTPwBhTLymwiCD8=.3b069d21-a341-4395-b87e-f91c8d0ab9d0@github.com> On Tue, 9 Sep 2025 15:01:04 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> More test cases > > src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 1453: > >> 1451: } >> 1452: >> 1453: // try the best to check the algorithm constraints > > Not part of your change, but can you remove the words "try the best to" - those words make it sound like it will pass even if the constraint checks fail. Also on line 1478. Good catch! Removing those comments all together as redundant, the new code is self-explanatory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334117732 From abarashev at openjdk.org Tue Sep 9 16:37:02 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 16:37:02 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v3] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: <0EbbxYapitRjNl4BJ9I91rffeHjEmo6MUP8ncR0G9MU=.a4e73d45-d2e1-4768-9c4b-800852423581@github.com> > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/33c27040..c29f7950 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=01-02 Stats: 10 lines in 4 files changed: 2 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From bperez at openjdk.org Tue Sep 9 16:46:10 2025 From: bperez at openjdk.org (Ben Perez) Date: Tue, 9 Sep 2025 16:46:10 GMT Subject: RFR: 8365581: Optimize Java implementation of P256 arithmetic [v4] In-Reply-To: References: Message-ID: > There are several places where MontgomeryIntegerPolynomialP256.mult() can be optimized. In particular, since modulus[2] = 0 several multiplications can be removed. Other multiplications can be replaced by shifts, which also saves time. Preliminary tests indicate an improvement between 5-10%. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: removed unnecessary subtraction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26792/files - new: https://git.openjdk.org/jdk/pull/26792/files/a3ddd412..bd7370c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26792&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26792&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26792/head:pull/26792 PR: https://git.openjdk.org/jdk/pull/26792 From mullan at openjdk.org Tue Sep 9 16:49:07 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 9 Sep 2025 16:49:07 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v2] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Mon, 8 Sep 2025 21:56:55 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against algorithm constraints. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > More test cases src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 52: > 50: > 51: public enum SIGNATURE_CONSTRAINTS_MODE { > 52: NONE, // Don't check against any supported signatures Do we need NONE? I don't see it used anywhere. src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 311: > 309: supportedAlgorithms = null; > 310: supportedSignatureSchemes = null; > 311: checksDisabled = false; Not necessary to initialize, those are the defaults. src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 422: > 420: } catch (InvalidParameterSpecException e) { > 421: throw new IllegalArgumentException( > 422: "Invalid AlgorithmParameters", e); I'd be more inclined to log a warning message here, but otherwise return true. This case should only occur if the RSASSS-PSS key is from some 3rd party provider that doesn't implement `AlgorithmParameters` correctly. I don't think that should result in a runtime exception - those should only be thrown if there is an issue with the `java.security` syntax for the disabled properties. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334116853 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334173269 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334202795 From asmehra at openjdk.org Tue Sep 9 16:49:12 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 9 Sep 2025 16:49:12 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 21:17:42 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run > - @DanHeidinga comments > - tightened SystemDictionary::preload_class() > - Fixed bugs found in JCK > - added entry in ProblemList-AotJdk.txt due to 8323727 > - more clean up > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501 src/hotspot/share/cds/aotOopChecker.cpp line 53: > 51: // the production run. > 52: void AOTOopChecker::check(oop obj) { > 53: precond(vmClasses::URL_klass()->is_final()); `AOTOopChecker::check` is a generic method, so this precond should ideally be inside the next block that explicitly handles URL class objects. src/hotspot/share/cds/aotOopChecker.cpp line 55: > 53: precond(vmClasses::URL_klass()->is_final()); > 54: > 55: if (obj->klass()->is_subclass_of(vmClasses::URL_klass())) { URL is a final class, so shouldn't `obj->klass() == vmClasses::URL_klass()` be sufficient? src/hotspot/share/classfile/javaClasses.cpp line 1063: > 1061: > 1062: // Statically allocate fixup lists because they always get created. > 1063: void java_lang_Class::allocate_fixup_lists() { Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? src/hotspot/share/memory/iterator.inline.hpp line 58: > 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); > 57: } else { > 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); Why is the null check and assert not valid anymore? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2331108015 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124611 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124798 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334211674 From abarashev at openjdk.org Tue Sep 9 17:00:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 17:00:54 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v2] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: <0BiCRTf527p3XJDce5QSU2Qd63q-p25btTrA_aVQPDs=.89b7ecef-9964-4a94-9c98-d8cc94488670@github.com> On Tue, 9 Sep 2025 16:03:49 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> More test cases > > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 52: > >> 50: >> 51: public enum SIGNATURE_CONSTRAINTS_MODE { >> 52: NONE, // Don't check against any supported signatures > > Do we need NONE? I don't see it used anywhere. Right, it's not being used currently, but I'd prefer to have it in case we need it in the future and just for overall code clarity. > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 311: > >> 309: supportedAlgorithms = null; >> 310: supportedSignatureSchemes = null; >> 311: checksDisabled = false; > > Not necessary to initialize, those are the defaults. Right, I just coded it this way for clarity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334234899 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334236370 From naoto at openjdk.org Tue Sep 9 17:10:10 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Sep 2025 17:10:10 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v7] In-Reply-To: References: Message-ID: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> > Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Comment refined ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26973/files - new: https://git.openjdk.org/jdk/pull/26973/files/9306bc0d..b928b2c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=05-06 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26973.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26973/head:pull/26973 PR: https://git.openjdk.org/jdk/pull/26973 From naoto at openjdk.org Tue Sep 9 17:10:13 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Sep 2025 17:10:13 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v6] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:27:20 GMT, Weijun Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments > > src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 137: > >> 135: } >> 136: >> 137: // Dedicated entry for sun.security.util.Password. > > To be more clear, I suggest this comment: > > // Dedicated entry for sun.security.util.Password when stdout is redirected. > // This method strictly avoids producing any output by using noNewLine = true > // and an empty format string. Thanks. Modified the comment as suggested ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2334255209 From weijun at openjdk.org Tue Sep 9 17:25:49 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 Sep 2025 17:25:49 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v7] In-Reply-To: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> References: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> Message-ID: <7ezREAkghyYEPsi8Xn8e61sZQ-q5_WW7kBLiBVIJpwo=.58060fae-72ab-49d2-aee2-f5940b0b87ab@github.com> On Tue, 9 Sep 2025 17:10:10 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Comment refined Marked as reviewed by weijun (Reviewer). Thanks for the comment change. Approved. ------------- PR Review: https://git.openjdk.org/jdk/pull/26973#pullrequestreview-3202579185 PR Comment: https://git.openjdk.org/jdk/pull/26973#issuecomment-3271636611 From smarks at openjdk.org Tue Sep 9 17:32:41 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 9 Sep 2025 17:32:41 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v7] In-Reply-To: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> References: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> Message-ID: On Tue, 9 Sep 2025 17:10:10 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Comment refined Not sure whether I need to re-approve, but I will anyway! ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26973#pullrequestreview-3202602888 From abarashev at openjdk.org Tue Sep 9 17:38:18 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 17:38:18 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v2] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Tue, 9 Sep 2025 16:41:57 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> More test cases > > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 422: > >> 420: } catch (InvalidParameterSpecException e) { >> 421: throw new IllegalArgumentException( >> 422: "Invalid AlgorithmParameters", e); > > I'd be more inclined to log a warning message here, but otherwise return true. This case should only occur if the RSASSS-PSS key is from some 3rd party provider that doesn't implement `AlgorithmParameters` correctly. I don't think that should result in a runtime exception - those should only be thrown if there is an issue with the `java.security` syntax for the disabled properties. Will do, thanks! I also wasn't sure whether to log it or to throw an exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334322077 From abarashev at openjdk.org Tue Sep 9 18:05:56 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 18:05:56 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v4] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Use default constraints if SIGNATURE_CONSTRAINTS_MODE is NONE. Log warning and return true on InvalidParameterSpecException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/c29f7950..7af212a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=02-03 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From abarashev at openjdk.org Tue Sep 9 18:18:44 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 18:18:44 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v2] In-Reply-To: <0BiCRTf527p3XJDce5QSU2Qd63q-p25btTrA_aVQPDs=.89b7ecef-9964-4a94-9c98-d8cc94488670@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> <0BiCRTf527p3XJDce5QSU2Qd63q-p25btTrA_aVQPDs=.89b7ecef-9964-4a94-9c98-d8cc94488670@github.com> Message-ID: On Tue, 9 Sep 2025 16:57:21 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 52: >> >>> 50: >>> 51: public enum SIGNATURE_CONSTRAINTS_MODE { >>> 52: NONE, // Don't check against any supported signatures >> >> Do we need NONE? I don't see it used anywhere. > > Right, it's not being used currently, but I'd prefer to have it in case we need it in the future and just for overall code clarity. On the 2nd thought, we can just use `null` instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334405812 From abarashev at openjdk.org Tue Sep 9 18:21:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 18:21:54 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v5] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Use null instead of SIGNATURE_CONSTRAINTS_MODE.NONE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/7af212a0..7e5ef522 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From mullan at openjdk.org Tue Sep 9 19:15:34 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 9 Sep 2025 19:15:34 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v3] In-Reply-To: <0EbbxYapitRjNl4BJ9I91rffeHjEmo6MUP8ncR0G9MU=.a4e73d45-d2e1-4768-9c4b-800852423581@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> <0EbbxYapitRjNl4BJ9I91rffeHjEmo6MUP8ncR0G9MU=.a4e73d45-d2e1-4768-9c4b-800852423581@github.com> Message-ID: On Tue, 9 Sep 2025 16:37:02 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments test/jdk/sun/security/ssl/SignatureScheme/RsaSsaPssConstraints.java line 1: > 1: /* How difficult would it be to add a test for "Rsa_pss_rsae_Sha384"? I think certificates with the rsaEncryption OID are much more common, so it would be good to add a test case for that. test/jdk/sun/security/ssl/SignatureScheme/RsaSsaPssConstraints.java line 110: > 108: algo + " usage CertificateSignature"); > 109: > 110: for (String protocol : new String[]{"TLS", "TLSv1.2"}) { I think you should test "TLSv1.3" specifically instead of "TLS", so we are sure this test is testing 1.3. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334531774 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2334486554 From naoto at openjdk.org Tue Sep 9 19:41:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Sep 2025 19:41:20 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v7] In-Reply-To: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> References: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> Message-ID: <1n1No4VjrH387wct3GaAcfW5SjpFpQOCuB8t3clKHKk=.10d66779-954b-42d8-a427-68ccbfc6d02f@github.com> On Tue, 9 Sep 2025 17:10:10 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Comment refined Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26973#issuecomment-3272029449 From naoto at openjdk.org Tue Sep 9 19:41:21 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Sep 2025 19:41:21 GMT Subject: Integrated: 8366261: Provide utility methods for sun.security.util.Password In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 22:53:28 GMT, Naoto Sato wrote: > Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. This pull request has now been integrated. Changeset: a12e9fce Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/a12e9fcebda1d7b75cb892e7920333d73fb5de9c Stats: 106 lines in 6 files changed: 81 ins; 0 del; 25 mod 8366261: Provide utility methods for sun.security.util.Password Reviewed-by: smarks, weijun ------------- PR: https://git.openjdk.org/jdk/pull/26973 From jerj at coplanar.net Tue Sep 9 23:08:38 2025 From: jerj at coplanar.net (Jeremy Jackson) Date: Tue, 9 Sep 2025 19:08:38 -0400 Subject: JGSS EncryptionKey.findKey() exception handling enhancement - guidance requested Message-ID: <8e46b12a-7ea6-4a56-9086-42594f50b295@coplanar.net> Hi All, In developing a Jetty application using SPNEGO, I encountered some misleading error messages. The browser was sending tickets that had a "kvno" that the webserver didn't have in it's keytab, yielding: GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed) Which does not point towards a solution, to say the least. There are 2 code paths, one (initiator) which requires the newest key be returned, and another (acceptor) which requires an exact kvno match. The current logic returns the newest key even when exact match is requested, instead of throwing BADKEYVER. For the acceptor case, this is an incorrect key, thus triggering exceptions related to decryption failure. According to ChatGPT: RFC 4120 says that when a server receives an AP-REQ, ?If the key version indicated by the Ticket in the KRB_AP_REQ is not one the server can use (e.g., it indicates an old key, and the server no longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is returned.? In looking at the code in src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java I can see that the BADKEYVER exception is never thrown, but is commented out *close* to the required code path with the vague explanation "For compatibility, will not fail here." I have created new test cases for all callers of EncryptionKey.findKey() and implemed the missing exception logic. The result has been that existing callers are unaffected. A test of the SPNEGO kvno-mismatch in Jetty now gives the proper exception: GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44)) As a first time contributor I would appreciate some guidance here. The comments related to the missing exception are a bit troubling, and there is also the commented out throw statement, and although I think I have test coverage on all the callers of findKey(), I would welcome some input. Regards, Jeremy From abarashev at openjdk.org Tue Sep 9 23:35:05 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 23:35:05 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v6] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Fix key algorithm bug. Add more test cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/7e5ef522..52441ecb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=04-05 Stats: 51 lines in 2 files changed: 16 ins; 4 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From abarashev at openjdk.org Tue Sep 9 23:35:07 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 9 Sep 2025 23:35:07 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v3] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> <0EbbxYapitRjNl4BJ9I91rffeHjEmo6MUP8ncR0G9MU=.a4e73d45-d2e1-4768-9c4b-800852423581@github.com> Message-ID: On Tue, 9 Sep 2025 19:12:33 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > test/jdk/sun/security/ssl/SignatureScheme/RsaSsaPssConstraints.java line 1: > >> 1: /* > > How difficult would it be to add a test for "Rsa_pss_rsae_Sha384"? I think certificates with the rsaEncryption OID are much more common, so it would be good to add a test case for that. Not difficult at all, it's a good idea to add more tests, thanks! > test/jdk/sun/security/ssl/SignatureScheme/RsaSsaPssConstraints.java line 110: > >> 108: algo + " usage CertificateSignature"); >> 109: >> 110: for (String protocol : new String[]{"TLS", "TLSv1.2"}) { > > I think you should test "TLSv1.3" specifically instead of "TLS", so we are sure this test is testing 1.3. Done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2335084030 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2335083547 From iklam at openjdk.org Wed Sep 10 04:16:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:03 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - @ashu-mehra review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @DanHeidinga comments -- added comments and asserts about the handling of enums - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run - @DanHeidinga comments - tightened SystemDictionary::preload_class() - Fixed bugs found in JCK - added entry in ProblemList-AotJdk.txt due to 8323727 - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=06 Stats: 716 lines in 44 files changed: 602 ins; 13 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Wed Sep 10 04:16:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:07 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 18:57:16 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - more clean up >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501 > > src/hotspot/share/cds/aotOopChecker.cpp line 53: > >> 51: // the production run. >> 52: void AOTOopChecker::check(oop obj) { >> 53: precond(vmClasses::URL_klass()->is_final()); > > `AOTOopChecker::check` is a generic method, so this precond should ideally be inside the next block that explicitly handles URL class objects. I moved this line inside the next block. I also added comments that in the future we may check more types of objects. > src/hotspot/share/cds/aotOopChecker.cpp line 55: > >> 53: precond(vmClasses::URL_klass()->is_final()); >> 54: >> 55: if (obj->klass()->is_subclass_of(vmClasses::URL_klass())) { > > URL is a final class, so shouldn't `obj->klass() == vmClasses::URL_klass()` be sufficient? Since the `precond` is now inside this block, I can't use `==` anymore. Othewise if we had an instance of a subclass of URL then we will never get into the `if` block. > src/hotspot/share/classfile/javaClasses.cpp line 1063: > >> 1061: >> 1062: // Statically allocate fixup lists because they always get created. >> 1063: void java_lang_Class::allocate_fixup_lists() { > > Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499266 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499303 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499362 From iklam at openjdk.org Wed Sep 10 04:16:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:10 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 16:46:13 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 > > src/hotspot/share/memory/iterator.inline.hpp line 58: > >> 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); >> 57: } else { >> 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); > > Why is the null check and assert not valid anymore? The AOT cache can have heap objects whose class are loaded by the platform/app loaders. These objects usually come from aot-linked Lambda expressions. Before this PR, the platform/app classes are loaded after executing quite a bit of Java code (i.e.,module graph initialization). It's possible for a GC to happen and discover those heap objects, whose classes are not yet loaded (i.e., having a null `cld`). After this PR, all boot/platform/app classes are loaded before GC can happen, so we will never run into such null `cld` anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499472 From myankelevich at openjdk.org Wed Sep 10 10:57:38 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 10 Sep 2025 10:57:38 GMT Subject: RFR: 8367096: jdk/open/test/jdk/sun/security/pkcs11/ rsa, ec, config, secmod and sslecc tests are skipping but showing as pass [v3] In-Reply-To: References: Message-ID: > Tests changed: > * test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java > * test/jdk/sun/security/pkcs11/PKCS11Test.java > * test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java > * test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java > * test/jdk/sun/security/pkcs11/Secmod/Crypto.java > * test/jdk/sun/security/pkcs11/Secmod/GetPrivateKey.java > * test/jdk/sun/security/pkcs11/Secmod/JksSetPrivateKey.java > * test/jdk/sun/security/pkcs11/Secmod/LoadKeystore.java > * test/jdk/sun/security/pkcs11/Secmod/TestNssDbSqlite.java > * test/jdk/sun/security/pkcs11/Secmod/TrustAnchors.java > * test/jdk/sun/security/pkcs11/SecmodTest.java > * test/jdk/sun/security/pkcs11/ec/ReadCertificates.java > * test/jdk/sun/security/pkcs11/ec/ReadPKCS12.java > * test/jdk/sun/security/pkcs11/ec/TestKeyFactory.java > * test/jdk/sun/security/pkcs11/rsa/KeyWrap.java > * test/jdk/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: Delete accidental file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27166/files - new: https://git.openjdk.org/jdk/pull/27166/files/b40b6ee4..411ac865 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27166&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27166&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27166/head:pull/27166 PR: https://git.openjdk.org/jdk/pull/27166 From mdonovan at openjdk.org Wed Sep 10 11:36:43 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 10 Sep 2025 11:36:43 GMT Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test [v8] In-Reply-To: <9P0Ta5TawO3n4lxpSaLhL0Zl183bAJrC_feVY1k0nkw=.ed70db03-492c-47b8-9566-a0e966b33f90@github.com> References: <9P0Ta5TawO3n4lxpSaLhL0Zl183bAJrC_feVY1k0nkw=.ed70db03-492c-47b8-9566-a0e966b33f90@github.com> Message-ID: On Tue, 12 Aug 2025 10:43:29 GMT, Mikhail Yankelevich wrote: >> Moved the sh file logic to jtreg java test. > > Mikhail Yankelevich has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains five new commits since the last revision: > > - rebasing to master, as merge caused an error > - Multiple logins test now extends PKCS11Test > > * Multiple logins test now extends PKCS11Test > * cleanup > * skip exceptions are now throws > - changed to use a scratch directory > - changed the year > - 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java test Looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23590#issuecomment-3274551967 From duke at openjdk.org Wed Sep 10 13:09:38 2025 From: duke at openjdk.org (Michael Osipov) Date: Wed, 10 Sep 2025 13:09:38 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao wrote: >> [webrev.zip](https://github.com/user-attachments/files/21517501/webrev.zip) >> NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory. >> >> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message and SaslOuput Stream is writing the content of the buffer; and at the time GSSContext is disposed and it is null. That's the reason to throw NPE. >> >> 1) Check if the context is null or not; then wrap the NPE. The change is done in GssKrb5Base.java >> >> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached webrev for the reference. > > Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused code > - removed the commented out code I am currently testing this change... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3274904946 From duke at openjdk.org Wed Sep 10 13:23:27 2025 From: duke at openjdk.org (Michael Osipov) Date: Wed, 10 Sep 2025 13:23:27 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao wrote: >> [webrev.zip](https://github.com/user-attachments/files/21517501/webrev.zip) >> NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory. >> >> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message and SaslOuput Stream is writing the content of the buffer; and at the time GSSContext is disposed and it is null. That's the reason to throw NPE. >> >> 1) Check if the context is null or not; then wrap the NPE. The change is done in GssKrb5Base.java >> >> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached webrev for the reference. > > Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused code > - removed the commented out code I have built and tested now. Before: krb5[0x3|main|Krb5Context.java:893|2025-09-10 15:18:00.264]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 25 87 e1 db 30 47 02 01 04 63 25 04 00 0a 01 00 0a 01 03 02 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 05 04 03 31 2e 31 a0 1b 30 19 04 17 32 2e 31 36 2e 38 34 30 2e 31 2e 31 31 33 37 33 30 2e 33 2e 34 2e 32 0d 18 15 c7 e1 41 c1 96 ab 8d fe a1 ] -> DEMCHADC08A.ad001.siemens.net:636 0000: 30 05 02 01 05 42 00 0....B. krb5[0x18|Thread-0|Krb5Context.java:893|2025-09-10 15:18:00.287]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 25 87 e1 dc 30 05 02 01 05 42 00 0a ea 9f fe c8 6d f6 3f 23 e9 69 21 ] -> DEMCHADC08A.ad001.siemens.net:636 0000: 30 06 02 01 06 50 01 04 0....P.. Exception in thread "main" java.lang.NullPointerException: Cannot invoke "org.ietf.jgss.GSSContext.wrap(byte[], int, int, org.ietf.jgss.MessageProp)" because "this.secCtx" is null at jdk.security.jgss/com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(GssKrb5Base.java:140) at java.naming/com.sun.jndi.ldap.sasl.SaslOutputStream.write(SaslOutputStream.java:89) at java.naming/com.sun.jndi.ldap.Connection.abandonRequest(Connection.java:582) at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:472) at java.naming/com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:664) at java.naming/com.sun.jndi.ldap.LdapClient.search(LdapClient.java:587) at java.naming/com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2013) at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1873) at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798) at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) at java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:346) at DirTest.main(DirTest.java:119) with the change: krb5[0x3|main|Krb5Context.java:893|2025-09-10 14:42:44.627]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 38 da 72 7f 30 47 02 01 04 63 25 04 00 0a 01 00 0a 01 03 02 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 05 04 03 31 2e 31 a0 1b 30 19 04 17 32 2e 31 36 2e 38 34 30 2e 31 2e 31 31 33 37 33 30 2e 33 2e 34 2e 32 51 a1 96 a3 b7 5c e5 fe 2c 94 91 ed ] -> DEMCHADC08A.ad001.siemens.net:636 0000: 30 05 02 01 05 42 00 0....B. krb5[0x18|Thread-0|Krb5Context.java:893|2025-09-10 14:42:44.646]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 38 da 72 80 30 05 02 01 05 42 00 94 98 24 f3 27 34 a0 af e7 bd bf 1a ] -> DEMCHADC08A.ad001.siemens.net:636 0000: 30 06 02 01 06 50 01 04 0....P.. krb5[0x3|main|Krb5Context.java:893|2025-09-10 14:42:44.649]: Krb5Context.wrap: token=[05 04 04 ff 00 0c 00 00 00 00 00 00 38 da 72 81 30 06 02 01 06 50 01 04 df 16 7c f1 ad fe 64 de bb 28 24 c7 ] Exception in thread "main" javax.naming.CommunicationException: LDAP connection has been closed [Root exception is java.io.IOException: LDAP connection has been closed]; remaining name '' at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:484) at java.naming/com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:684) at java.naming/com.sun.jndi.ldap.LdapClient.search(LdapClient.java:607) at java.naming/com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2013) at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1873) at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798) at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) at java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:346) at DirTest.main(DirTest.java:119) Caused by: java.io.IOException: LDAP connection has been closed at java.naming/com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:145) at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:460) ... 10 more @weibxiao Is the security context still cleanly disposed? >From my superficial testing this looks good now. ------------- Changes requested by michael-o at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/26566#pullrequestreview-3206134625 From wxiao at openjdk.org Wed Sep 10 14:15:29 2025 From: wxiao at openjdk.org (Weibing Xiao) Date: Wed, 10 Sep 2025 14:15:29 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: Message-ID: <4j7FblbRNFadK0m_4pdjQuRp_EHkPbR75Ahb8_VRbHU=.0f8f1951-48fb-4703-ad20-d79f47e323ff@github.com> On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao wrote: >> [webrev.zip](https://github.com/user-attachments/files/21517501/webrev.zip) >> NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory. >> >> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message and SaslOuput Stream is writing the content of the buffer; and at the time GSSContext is disposed and it is null. That's the reason to throw NPE. >> >> 1) Check if the context is null or not; then wrap the NPE. The change is done in GssKrb5Base.java >> >> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached webrev for the reference. > > Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused code > - removed the commented out code Yes. I traced the call. GSSKrb5Base::dispose was called after LDAPClient::close got call and context got closed. BTW, I will be out of office for two weeks starting next Monday. I will check review comment after coming backing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3275176138 From asmehra at openjdk.org Wed Sep 10 14:22:44 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:22:44 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 04:12:04 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 1063: >> >>> 1061: >>> 1062: // Statically allocate fixup lists because they always get created. >>> 1063: void java_lang_Class::allocate_fixup_lists() { >> >> Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? > > I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? I was referring to `fixup_module_field_list`, but the comments are for `fixup_mirror_list`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2336936776 From duke at openjdk.org Wed Sep 10 14:24:29 2025 From: duke at openjdk.org (Michael Osipov) Date: Wed, 10 Sep 2025 14:24:29 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: <4j7FblbRNFadK0m_4pdjQuRp_EHkPbR75Ahb8_VRbHU=.0f8f1951-48fb-4703-ad20-d79f47e323ff@github.com> References: <4j7FblbRNFadK0m_4pdjQuRp_EHkPbR75Ahb8_VRbHU=.0f8f1951-48fb-4703-ad20-d79f47e323ff@github.com> Message-ID: On Wed, 10 Sep 2025 14:12:26 GMT, Weibing Xiao wrote: > Yes. I traced the call. GSSKrb5Base::dispose was called after LDAPClient::close got call and context got closed. > > BTW, I will be out of office for two weeks starting next Monday. I will check review comment after coming backing. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3275211799 From mdonovan at openjdk.org Wed Sep 10 14:25:12 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 10 Sep 2025 14:25:12 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments [v4] In-Reply-To: References: Message-ID: > This PR extends security tests to use ByteBuffers backed by MemorySegments. Tests in the areas of Signature, Cipher, MessageDigest, and Mac are updated. Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - updated additional Cipher tests for MemorySegment-backed ByteBuffers - Merge branch 'master' into cipher-ffm - added null-check for arena argument - addressed PR comments and refactored to use try-with-resources - Merge branch 'master' into cipher-ffm - 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments ------------- Changes: https://git.openjdk.org/jdk/pull/26967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26967&range=03 Stats: 1208 lines in 22 files changed: 530 ins; 151 del; 527 mod Patch: https://git.openjdk.org/jdk/pull/26967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26967/head:pull/26967 PR: https://git.openjdk.org/jdk/pull/26967 From asmehra at openjdk.org Wed Sep 10 14:52:31 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:52:31 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> References: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> Message-ID: On Wed, 10 Sep 2025 04:16:03 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @ashu-mehra review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run > - @DanHeidinga comments > - tightened SystemDictionary::preload_class() > - Fixed bugs found in JCK > - added entry in ProblemList-AotJdk.txt due to 8323727 > - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 src/hotspot/share/cds/filemap.cpp line 1861: > 1859: const char* archive_type = CDSConfig::type_of_archive_being_loaded(); > 1860: CDSConfig::set_has_aot_linked_classes(true); > 1861: if (is_static()) { `CDSConfig` is a global configuration, not specific to static or dynamic archive, and IIUC it is not possible to just load a dynamic archive, without loading a static archive. So it seems `is_static()` check is redundant here. Continuing with this line of thought, it seems if `has_aot_linked_classes` is true then `is_using_preloaded_classes` will also be true. Then why do we even need this additional flag to indicate preloading of classes? This is going to be the default behavior when `has_aot_linked_classes` is true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337020552 From asmehra at openjdk.org Wed Sep 10 14:52:33 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:52:33 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 04:12:08 GMT, Ioi Lam wrote: >> src/hotspot/share/memory/iterator.inline.hpp line 58: >> >>> 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); >>> 57: } else { >>> 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); >> >> Why is the null check and assert not valid anymore? > > The AOT cache can have heap objects whose class are loaded by the platform/app loaders. These objects usually come from aot-linked Lambda expressions. > > Before this PR, the platform/app classes are loaded after executing quite a bit of Java code (i.e.,module graph initialization). It's possible for a GC to happen and discover those heap objects, whose classes are not yet loaded (i.e., having a null `cld`). > > After this PR, all boot/platform/app classes are loaded before GC can happen, so we will never run into such null `cld` anymore. That makes `is_pending_aot_linked_class` dead code. Can it be removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337025501 From weijun.wang at oracle.com Wed Sep 10 15:24:33 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Wed, 10 Sep 2025 15:24:33 +0000 Subject: JGSS EncryptionKey.findKey() exception handling enhancement - guidance requested In-Reply-To: <8e46b12a-7ea6-4a56-9086-42594f50b295@coplanar.net> References: <8e46b12a-7ea6-4a56-9086-42594f50b295@coplanar.net> Message-ID: Hi Jeremy, Please read https://bugs.openjdk.org/browse/JDK-7197159 for the reason behind the code. That said, we will see if the exception message can be enhanced or there can be extra debug messages. I've filed https://bugs.openjdk.org/browse/JDK-8367344. Thanks, Weijun > On Sep 9, 2025, at 19:08, Jeremy Jackson wrote: > > Hi All, > > In developing a Jetty application using SPNEGO, I encountered some > misleading error messages. > > The browser was sending tickets that had a "kvno" that the webserver > didn't have in it's keytab, yielding: > > GSSException: Failure unspecified at GSS-API level (Mechanism level: > Checksum failed) > > Which does not point towards a solution, to say the least. > > There are 2 code paths, one (initiator) which requires the newest key be > returned, and another (acceptor) which requires an exact kvno match. > > The current logic returns the newest key even when exact match is > requested, instead of throwing BADKEYVER. > > For the acceptor case, this is an incorrect key, thus > triggering exceptions related to decryption failure. > > According to ChatGPT: > > RFC 4120 says that when a server receives an AP-REQ, ?If the key version > indicated by the Ticket in the KRB_AP_REQ is not one the server can use > (e.g., it indicates an old key, and the server no longer possesses a > copy of the old key), the KRB_AP_ERR_BADKEYVER error is returned.? > > In looking at the code in > > src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java > > I can see that the BADKEYVER exception is never thrown, but is commented > out *close* to the required code path with the vague explanation "For > compatibility, will not fail here." > > I have created new test cases for all callers of EncryptionKey.findKey() > and implemed the missing exception logic. The result has been that > existing callers are unaffected. > > A test of the SPNEGO kvno-mismatch in Jetty now gives the proper exception: > > GSSException: Failure unspecified at GSS-API level (Mechanism level: > Specified version of key is not available (44)) > > As a first time contributor I would appreciate some guidance here. The > comments related to the missing exception are a bit troubling, and there > is also the commented out throw statement, and although I think I have > test coverage on all the callers of findKey(), I would welcome some input. > > Regards, > Jeremy > From myankelevich at openjdk.org Wed Sep 10 15:28:45 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 10 Sep 2025 15:28:45 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) Message-ID: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Tests changed in this PR: 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java 12. test/jdk/sun/security/rsa/InvalidBitString.java 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) ------------- Commit messages: - converted tests: /NoExtensions.java, CPValidatorTrustAnchor.java, Verify.java - JDK-8365072: Refactor tests to use PEM API (Phase 2) - JDK-8365072: Refactor tests to use PEM API (Phase 2) - JDK-8365072: Refactor tests to use PEM API (Phase 2) Changes: https://git.openjdk.org/jdk/pull/27194/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365072 Stats: 813 lines in 14 files changed: 169 ins; 258 del; 386 mod Patch: https://git.openjdk.org/jdk/pull/27194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194 PR: https://git.openjdk.org/jdk/pull/27194 From hchao at openjdk.org Wed Sep 10 15:45:09 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 10 Sep 2025 15:45:09 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v5] In-Reply-To: <29QfhdwnTiDMnHXjkcwueU6W9DIQd2KTNje9jsd1ufY=.6c7414f2-239e-4c48-a8cf-ee3cd106c7d9@github.com> References: <29QfhdwnTiDMnHXjkcwueU6W9DIQd2KTNje9jsd1ufY=.6c7414f2-239e-4c48-a8cf-ee3cd106c7d9@github.com> Message-ID: <_9mn1cCcnvJOOTm3acv0iO7PoJBqBBliZMEuKUj__Dk=.8eea4090-4b4e-4af7-a651-af3c9473eccc@github.com> On Tue, 26 Aug 2025 19:09:03 GMT, Artur Barashev wrote: >> [JDK-8349583](https://bugs.openjdk.org/browse/JDK-8349583) implementation assumes that OpenJDK client always sends "signature_algorithms_cert" extension together with "signature_algorithms" extension. But we didn't account for `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties which can disable producing "signature_algorithms_cert" extension. This is an issue similar to [JDK-8355779](https://bugs.openjdk.org/browse/JDK-8355779) but on the extension producing side. >> >> Per TLSv1.3 RFC: >> >>> If no "signature_algorithms_cert" extension is >>> present, then the "signature_algorithms" extension also applies to >>> signatures appearing in certificates. >> >> Also making a few cosmetic changes to the existing code. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Add a server-side unit test. Rename existing tests. src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java line 551: > 549: sigAlgs.retainAll(hc.localSupportedCertSignAlgs); > 550: } > 551: The `sigAlgs` may include handshake scope and certificate scope. Suggest to add a debug log to list the produced signature algorithms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26887#discussion_r2337181121 From hchao at openjdk.org Wed Sep 10 15:52:45 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 10 Sep 2025 15:52:45 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v5] In-Reply-To: <29QfhdwnTiDMnHXjkcwueU6W9DIQd2KTNje9jsd1ufY=.6c7414f2-239e-4c48-a8cf-ee3cd106c7d9@github.com> References: <29QfhdwnTiDMnHXjkcwueU6W9DIQd2KTNje9jsd1ufY=.6c7414f2-239e-4c48-a8cf-ee3cd106c7d9@github.com> Message-ID: On Tue, 26 Aug 2025 19:09:03 GMT, Artur Barashev wrote: >> [JDK-8349583](https://bugs.openjdk.org/browse/JDK-8349583) implementation assumes that OpenJDK client always sends "signature_algorithms_cert" extension together with "signature_algorithms" extension. But we didn't account for `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties which can disable producing "signature_algorithms_cert" extension. This is an issue similar to [JDK-8355779](https://bugs.openjdk.org/browse/JDK-8355779) but on the extension producing side. >> >> Per TLSv1.3 RFC: >> >>> If no "signature_algorithms_cert" extension is >>> present, then the "signature_algorithms" extension also applies to >>> signatures appearing in certificates. >> >> Also making a few cosmetic changes to the existing code. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Add a server-side unit test. Rename existing tests. test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS12.java line 56: > 54: + CERTIFICATE_DISABLED_SIG + " usage certificateSignature"; > 55: > 56: // Signature schemes not supported in TLSv1.3 for the handshake Add this bug number to the list of @bug test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS13.java line 68: > 66: SIG_ALGS_EXT); > 67: > 68: // These signature schemes MOST NOT be present in signature_algorithms Bug number to be added to @bug ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26887#discussion_r2337193012 PR Review Comment: https://git.openjdk.org/jdk/pull/26887#discussion_r2337199121 From naoto at openjdk.org Wed Sep 10 16:31:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 10 Sep 2025 16:31:54 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:43:52 GMT, Weijun Wang wrote: > Allow password hiding even if there is no `System.console`. A manual test is included. src/java.base/share/classes/sun/security/util/Password.java line 158: > 156: c2 = null; > 157: charset = null; > 158: } Can be simplified as: c2 = JdkConsoleImpl.passwordConsole().orElse(null); charset = (c2 != null) ? c2.charset() : null; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2337290982 From weijun at openjdk.org Wed Sep 10 17:30:13 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 17:30:13 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v2] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: decouple PassFailJFrame.java change; simplify code flow ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/9272e28f..3a5f9687 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=00-01 Stats: 32 lines in 3 files changed: 0 ins; 27 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From weijun at openjdk.org Wed Sep 10 17:33:05 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 17:33:05 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang 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 branch 'master' into 8354469 - decouple PassFailJFrame.java change; simplify code flow - the fix ------------- Changes: https://git.openjdk.org/jdk/pull/27196/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=02 Stats: 250 lines in 2 files changed: 221 ins; 5 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From jerj at coplanar.net Wed Sep 10 17:57:04 2025 From: jerj at coplanar.net (Jeremy Jackson) Date: Wed, 10 Sep 2025 13:57:04 -0400 Subject: JGSS EncryptionKey.findKey() exception handling enhancement - guidance requested In-Reply-To: References: <8e46b12a-7ea6-4a56-9086-42594f50b295@coplanar.net> Message-ID: <25b29ae1-1bdc-43c0-b071-0b87531790df@coplanar.net> On 2025-09-10 11:24, Wei-Jun Wang wrote: > Hi Jeremy, > > Please read https://bugs.openjdk.org/browse/JDK-7197159 for the reason behind the code. OK thanks, that is helpful as it explains the code comments. In https://bugs.openjdk.org/browse/JDK-6907425 I read: "...on the server side, keys are not read from keytab but generated with username/password pair and have no kvno info." however it appears that ktab.exe by default generates keys with kvno = 1, which would fail to match after my modification. Using ktab -a -n 0 would generate them with a kvno of 0, and the modifications I implemented would still allow the same findKey() behaviour. The other case, where a keytab has an existing key, with a non-zero but non-matching kvno, but a valid key, would begin to fail. I am wondering, is this non-RFC behaviour intended to be used in production or only in test scenarios where ktab.exe might be used to generate test data (keytabs)? Thanks, Jeremy > > That said, we will see if the exception message can be enhanced or there can be extra debug messages. I've filed https://bugs.openjdk.org/browse/JDK-8367344. > > Thanks, > Weijun > >> On Sep 9, 2025, at 19:08, Jeremy Jackson wrote: >> >> Hi All, >> >> In developing a Jetty application using SPNEGO, I encountered some >> misleading error messages. >> >> The browser was sending tickets that had a "kvno" that the webserver >> didn't have in it's keytab, yielding: >> >> GSSException: Failure unspecified at GSS-API level (Mechanism level: >> Checksum failed) >> >> Which does not point towards a solution, to say the least. >> >> There are 2 code paths, one (initiator) which requires the newest key be >> returned, and another (acceptor) which requires an exact kvno match. >> >> The current logic returns the newest key even when exact match is >> requested, instead of throwing BADKEYVER. >> >> For the acceptor case, this is an incorrect key, thus >> triggering exceptions related to decryption failure. >> >> According to ChatGPT: >> >> RFC 4120 says that when a server receives an AP-REQ, ?If the key version >> indicated by the Ticket in the KRB_AP_REQ is not one the server can use >> (e.g., it indicates an old key, and the server no longer possesses a >> copy of the old key), the KRB_AP_ERR_BADKEYVER error is returned.? >> >> In looking at the code in >> >> src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java >> >> I can see that the BADKEYVER exception is never thrown, but is commented >> out *close* to the required code path with the vague explanation "For >> compatibility, will not fail here." >> >> I have created new test cases for all callers of EncryptionKey.findKey() >> and implemed the missing exception logic. The result has been that >> existing callers are unaffected. >> >> A test of the SPNEGO kvno-mismatch in Jetty now gives the proper exception: >> >> GSSException: Failure unspecified at GSS-API level (Mechanism level: >> Specified version of key is not available (44)) >> >> As a first time contributor I would appreciate some guidance here. The >> comments related to the missing exception are a bit troubling, and there >> is also the commented out throw statement, and although I think I have >> test coverage on all the callers of findKey(), I would welcome some input. >> >> Regards, >> Jeremy >> > From dfuchs at openjdk.org Wed Sep 10 18:08:20 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 10 Sep 2025 18:08:20 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 656 commits: - merge latest changes from master branch - modify http3 test timeouts - qpack - take knownReceivedCount into account during DT entries eviction - merge latest changes from master branch - http3: fix at since - merge latest http3 changes - Remove unused variables - Simplify control flow - Remove unnecessary instanceof checks - Use IntFunction for header generator - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=16 Stats: 105844 lines in 474 files changed: 103013 ins; 1333 del; 1498 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From iklam at openjdk.org Wed Sep 10 18:30:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 18:30:57 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> Message-ID: On Wed, 10 Sep 2025 14:47:19 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 > > src/hotspot/share/cds/filemap.cpp line 1861: > >> 1859: const char* archive_type = CDSConfig::type_of_archive_being_loaded(); >> 1860: CDSConfig::set_has_aot_linked_classes(true); >> 1861: if (is_static()) { > > `CDSConfig` is a global configuration, not specific to static or dynamic archive, and IIUC it is not possible to just load a dynamic archive, without loading a static archive. So it seems `is_static()` check is redundant here. > Continuing with this line of thought, it seems if `has_aot_linked_classes` is true then `is_using_preloaded_classes` will also be true. Then why do we even need this additional flag to indicate preloading of classes? This is going to be the default behavior when `has_aot_linked_classes` is true. There is actually a tricky situation -- static archive doesn't have `-XX:+AOTClassLinking` but the dynamic archive was created with `-XX:+AOTClassLinking`. I have created [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366) to remove support for `-XX:+AOTClassLinking` for the dynamic archive. If that gets reviewed and integrated, then I will update this PR to remove `is_using_preloaded_classes()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337574998 From iklam at openjdk.org Wed Sep 10 18:30:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 18:30:58 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:19:33 GMT, Ashutosh Mehra wrote: >> I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? > > I was referring to `fixup_module_field_list`, but the comments are for `fixup_mirror_list`. It's needed because of `-XX:+AOTClassLinking` in the dynamic archive. I will update this after removing `-XX:+AOTClassLinking` support for the dynamic archive in [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337579397 From weijun.wang at oracle.com Wed Sep 10 18:38:23 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Wed, 10 Sep 2025 18:38:23 +0000 Subject: JGSS EncryptionKey.findKey() exception handling enhancement - guidance requested In-Reply-To: <25b29ae1-1bdc-43c0-b071-0b87531790df@coplanar.net> References: <8e46b12a-7ea6-4a56-9086-42594f50b295@coplanar.net> <25b29ae1-1bdc-43c0-b071-0b87531790df@coplanar.net> Message-ID: <3B09897E-C365-43A0-9D79-E506BD4E788F@oracle.com> The fallback to a key with the highest kvno is for production. I'm considering two enhancements: 1. Update the error message if decryption fails with a key using different kvno. 2. Add a log message when a key with unmatched kvno is returned. Thanks, Weijun > On Sep 10, 2025, at 13:57, Jeremy Jackson wrote: > > > > On 2025-09-10 11:24, Wei-Jun Wang wrote: >> Hi Jeremy, >> >> Please read https://bugs.openjdk.org/browse/JDK-7197159 for the reason behind the code. > > OK thanks, that is helpful as it explains the code comments. > > In https://bugs.openjdk.org/browse/JDK-6907425 I read: > > "...on the server side, keys are not read from keytab but generated with > username/password pair and have no kvno info." > > however it appears that ktab.exe by default generates keys with kvno = > 1, which would fail to match after my modification. Using > > ktab -a -n 0 > > would generate them with a kvno of 0, and the modifications I > implemented would still allow the same findKey() behaviour. > > The other case, where a keytab has an existing key, with a non-zero but > non-matching kvno, but a valid key, would begin to fail. > > I am wondering, is this non-RFC behaviour intended to be used in > production or only in test scenarios where ktab.exe might be used to > generate test data (keytabs)? > > Thanks, > Jeremy > >> >> That said, we will see if the exception message can be enhanced or there can be extra debug messages. I've filed https://bugs.openjdk.org/browse/JDK-8367344 . >> >> Thanks, >> Weijun >> >>> On Sep 9, 2025, at 19:08, Jeremy Jackson wrote: >>> >>> Hi All, >>> >>> In developing a Jetty application using SPNEGO, I encountered some >>> misleading error messages. >>> >>> The browser was sending tickets that had a "kvno" that the webserver >>> didn't have in it's keytab, yielding: >>> >>> GSSException: Failure unspecified at GSS-API level (Mechanism level: >>> Checksum failed) >>> >>> Which does not point towards a solution, to say the least. >>> >>> There are 2 code paths, one (initiator) which requires the newest key be >>> returned, and another (acceptor) which requires an exact kvno match. >>> >>> The current logic returns the newest key even when exact match is >>> requested, instead of throwing BADKEYVER. >>> >>> For the acceptor case, this is an incorrect key, thus >>> triggering exceptions related to decryption failure. >>> >>> According to ChatGPT: >>> >>> RFC 4120 says that when a server receives an AP-REQ, ?If the key version >>> indicated by the Ticket in the KRB_AP_REQ is not one the server can use >>> (e.g., it indicates an old key, and the server no longer possesses a >>> copy of the old key), the KRB_AP_ERR_BADKEYVER error is returned.? >>> >>> In looking at the code in >>> >>> src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java >>> >>> I can see that the BADKEYVER exception is never thrown, but is commented >>> out *close* to the required code path with the vague explanation "For >>> compatibility, will not fail here." >>> >>> I have created new test cases for all callers of EncryptionKey.findKey() >>> and implemed the missing exception logic. The result has been that >>> existing callers are unaffected. >>> >>> A test of the SPNEGO kvno-mismatch in Jetty now gives the proper exception: >>> >>> GSSException: Failure unspecified at GSS-API level (Mechanism level: >>> Specified version of key is not available (44)) >>> >>> As a first time contributor I would appreciate some guidance here. The >>> comments related to the missing exception are a bit troubling, and there >>> is also the commented out throw statement, and although I think I have >>> test coverage on all the callers of findKey(), I would welcome some input. >>> >>> Regards, >>> Jeremy >>> >> > > From fandreuzzi at openjdk.org Wed Sep 10 19:39:43 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 19:39:43 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 17:33:05 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang 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 branch 'master' into 8354469 > - decouple PassFailJFrame.java change; simplify code flow > - the fix src/java.base/share/classes/sun/security/util/Password.java line 167: > 165: if (c1 != null) { > 166: return c1.readPassword(); > 167: } else { The `else` clause is not needed, you could save an indentation level ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2337724730 From weijun at openjdk.org Wed Sep 10 19:58:55 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 19:58:55 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 19:36:54 GMT, Francesco Andreuzzi wrote: >> Weijun Wang 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 branch 'master' into 8354469 >> - decouple PassFailJFrame.java change; simplify code flow >> - the fix > > src/java.base/share/classes/sun/security/util/Password.java line 167: > >> 165: if (c1 != null) { >> 166: return c1.readPassword(); >> 167: } else { > > The `else` clause is not needed, you could save an indentation level The indentation is not very deep, and I actually like the symmetry between 2 different kind of "consoles". As long as there is no performance gain, I'll keep my style. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2337761565 From fandreuzzi at openjdk.org Wed Sep 10 20:50:43 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 20:50:43 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: On Wed, 10 Sep 2025 15:18:59 GMT, Mikhail Yankelevich wrote: > Tests changed in this PR: > 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java > 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java > 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java > 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java > 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java > 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java > 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java > 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java > 12. test/jdk/sun/security/rsa/InvalidBitString.java > 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java > 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java > 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java > > PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java line 546: > 544: > 545: // generate certificate chain > 546: Certificate serverCert =pemDecoder.decode(serverCertStr, X509Certificate.class); Suggestion: Certificate serverCert = pemDecoder.decode(serverCertStr, X509Certificate.class); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27194#discussion_r2337866487 From abarashev at openjdk.org Wed Sep 10 20:54:23 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 10 Sep 2025 20:54:23 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v7] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Add a TrustManager check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/52441ecb..5a0510d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=05-06 Stats: 50 lines in 2 files changed: 49 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From weijun at openjdk.org Wed Sep 10 23:03:23 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 23:03:23 GMT Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v2] In-Reply-To: References: Message-ID: > Add support for ML-DSA signing of JAR files. > > Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8349732 - the fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26563/files - new: https://git.openjdk.org/jdk/pull/26563/files/86579b8e..7b0beb1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=00-01 Stats: 99289 lines in 2722 files changed: 57381 ins; 29321 del; 12587 mod Patch: https://git.openjdk.org/jdk/pull/26563.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26563/head:pull/26563 PR: https://git.openjdk.org/jdk/pull/26563 From weijun at openjdk.org Wed Sep 10 23:03:49 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 23:03:49 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v43] In-Reply-To: References: Message-ID: > Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. > image Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: - Merge branch 'master' into 8325448 - about transformation - cannot reset with withMethods - algorithm identifier - withMethods - duplicated "value" words - receiver to recipient; different to specified - use different exception type - more spec change - address Sean's comments - ... and 48 more: https://git.openjdk.org/jdk/compare/7fcce270...1ec31cf5 ------------- Changes: https://git.openjdk.org/jdk/pull/18411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=42 Stats: 2124 lines in 12 files changed: 1927 ins; 74 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/18411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 PR: https://git.openjdk.org/jdk/pull/18411 From weijun at openjdk.org Wed Sep 10 23:06:29 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 23:06:29 GMT Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v7] In-Reply-To: References: Message-ID: > The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called. > > By default, the choice is "seed". > > Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - merge - Ben comment - combine security properties description; remove one test - Merge branch 'master' into 8347938 - KeyChoices class - allow expanded to be null - merge - Merge - safer privKeyToPubKey; updated desciptions for the properties; adding braces to if blocks - the fix ------------- Changes: https://git.openjdk.org/jdk/pull/24969/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=06 Stats: 2219 lines in 22 files changed: 1460 ins; 548 del; 211 mod Patch: https://git.openjdk.org/jdk/pull/24969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24969/head:pull/24969 PR: https://git.openjdk.org/jdk/pull/24969 From weijun at openjdk.org Wed Sep 10 23:25:19 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 23:25:19 GMT Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v3] In-Reply-To: References: Message-ID: > Add support for ML-DSA signing of JAR files. > > Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: some rename ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26563/files - new: https://git.openjdk.org/jdk/pull/26563/files/7b0beb1d..e200422e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26563.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26563/head:pull/26563 PR: https://git.openjdk.org/jdk/pull/26563 From duke at openjdk.org Thu Sep 11 00:47:33 2025 From: duke at openjdk.org (duke) Date: Thu, 11 Sep 2025 00:47:33 GMT Subject: Withdrawn: 8350709: [JMH] test ProtectionDomainBench failed for 2 threads config In-Reply-To: References: Message-ID: <03YR0NCdYHhZzPyRqNNfJYj2HDKlHGrbSji-4WlyTQo=.2856a4f0-1b1a-4b79-86d5-2bae84c5a998@github.com> On Mon, 14 Jul 2025 19:25:38 GMT, Mark Powers wrote: > [JDK-8350709](https://bugs.openjdk.org/browse/JDK-8350709) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26301 From jnimeh at openjdk.org Thu Sep 11 00:54:04 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 11 Sep 2025 00:54:04 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v5] In-Reply-To: References: Message-ID: > This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. > > Credit and thanks to @jaikiran for finding the issue and providing reproducer code. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Add tests for encryption correctness, also add tests for MemorySegment ByteBuffers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27081/files - new: https://git.openjdk.org/jdk/pull/27081/files/43cc8ca2..10e7e1f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=03-04 Stats: 116 lines in 1 file changed: 67 ins; 6 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/27081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27081/head:pull/27081 PR: https://git.openjdk.org/jdk/pull/27081 From wetmore at openjdk.org Thu Sep 11 01:01:28 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 11 Sep 2025 01:01:28 GMT Subject: RFR: 8365953: Key manager returns no certificates when handshakeSession is not an ExtendedSSLSession In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 17:09:29 GMT, Artur Barashev wrote: > See X509KeyManagerCertChecking#getAlgorithmConstraints. If the handshake session is not an ExtendedSSLSession, the method returns constraints using a null list of peerSupportedSignAlgs, which in turn means that all certificates will be rejected. Accepting all signature schemes would probably be a better choice here, and that's what we do when the handshake session is not available at all. > > The SunJSSE SSLSockets and SSLEngines both return extended SSL sessions. There are no known third-party providers that return non-extended SSL sessions. I missed the changeset for 8359956. Quite a bit of work there. LGTM also. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27106#pullrequestreview-3208318603 From duke at openjdk.org Thu Sep 11 05:11:11 2025 From: duke at openjdk.org (Nibedita Jena) Date: Thu, 11 Sep 2025 05:11:11 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v4] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 13:37:56 GMT, Artur Barashev wrote: > > Can a usecase be added for jdk.tls.server.disableExtensions if this option is being considered. > > Yes, added a test, thanks! Thank you ------------- PR Comment: https://git.openjdk.org/jdk/pull/26887#issuecomment-3277663797 From jpai at openjdk.org Thu Sep 11 06:17:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Sep 2025 06:17:52 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:08:20 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 656 commits: > > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3209058486 From smarks at openjdk.org Thu Sep 11 06:30:20 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 11 Sep 2025 06:30:20 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 17:33:05 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang 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 branch 'master' into 8354469 > - decouple PassFailJFrame.java change; simplify code flow > - the fix Marked as reviewed by smarks (Reviewer). src/java.base/share/classes/sun/security/util/Password.java line 193: > 191: ba[bb.position()] = '\n'; > 192: } > 193: return ba; Some random comments. This is all internal to this class, and it's all vaguely cleanup, so it's up to you whether to take any action on any of these points. It might be worth having a comment on this method that explains why it's doing this. The "obvious" way of encoding the characters is to use String.getBytes(), but you probably don't want to create a String, because (I think) you want to be able to erase the arrays afterwards. Worth explaining, if true. At lines 190-191 the mixture of buffer and array stuff is kind of confusing. I think you can check whether bb.remaining() > 0 and use bb.put(). There are actually three possibilities for what's in the returned byte array: 1) it's completely filled with encoded bytes from the input; 2) it contains the encoded input followed by an NL byte; or 3) it contains the encoded input, an NL byte, followed by an arbitrary number of zero bytes. The way that the returned array is processed by the caller handles this, but it seems a bit brittle. One possibility is always to return an array of the exact correct length, including an NL byte. Of course this entails an extra copy (and an extra array to erase) but there are fewer cases for the caller to handle. ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3209119549 PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2338827872 From djelinski at openjdk.org Thu Sep 11 06:30:50 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 11 Sep 2025 06:30:50 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:08:20 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 656 commits: > > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3209123887 From syan at openjdk.org Thu Sep 11 06:54:15 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 11 Sep 2025 06:54:15 GMT Subject: RFR: 8366817: test/jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java and JdkProcClient.java should not delete logs [v2] In-Reply-To: References: <168uceKQ-mqaigIebpwYvP0GaL2d0uynUzSqiHd6M-Q=.4a48511e-cc1b-44be-9019-407612df2e25@github.com> Message-ID: On Fri, 5 Sep 2025 13:57:29 GMT, Fernando Guallini wrote: >> The following test helpers delete logs after the test completes: >> jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java >> jdk/javax/net/ssl/TLSCommon/interop/JdkProcClient.java >> >> These helpers are used by tests located in jdk/javax/net/ssl/compatibility/*.java. Instead of explicitly deleting logs, cleanup should be handled by JTREG, as with other tests. >> >> It is possible that the server process is still writing to this log when it tries to delete it, which could cause : >> >> `java.nio.file.FileSystemException: server.log: The process cannot access the file because it is being used by another process` > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > copyright year LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/27076#pullrequestreview-3209251622 From myankelevich at openjdk.org Thu Sep 11 06:58:26 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 11 Sep 2025 06:58:26 GMT Subject: Integrated: 8366342: Key generator and key pair generator tests skipping, but showing as passed In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 11:25:54 GMT, Mikhail Yankelevich wrote: > * Minor cleanup > * Key generator and key pair generator tests skipping, but showing as passed: > * test/jdk/sun/security/pkcs11/KeyGenerator/DESParity.java > * test/jdk/sun/security/pkcs11/KeyGenerator/TestAES.java > * test/jdk/sun/security/pkcs11/KeyGenerator/TestChaCha20.java > * test/jdk/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java > * test/jdk/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java > * test/jdk/sun/security/pkcs11/KeyPairGenerator/TestDefaultDHPrivateExpSize.java This pull request has now been integrated. Changeset: 7690a45f Author: Mikhail Yankelevich URL: https://git.openjdk.org/jdk/commit/7690a45f77a2da47fa912fe7a2b2faa589f259f0 Stats: 35 lines in 6 files changed: 11 ins; 9 del; 15 mod 8366342: Key generator and key pair generator tests skipping, but showing as passed Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/26985 From myankelevich at openjdk.org Thu Sep 11 10:02:07 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 11 Sep 2025 10:02:07 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v2] In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: > Tests changed in this PR: > 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java > 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java > 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java > 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java > 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java > 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java > 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java > 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java > 12. test/jdk/sun/security/rsa/InvalidBitString.java > 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java > 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java > 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java > > PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: Francesco's comment Co-authored-by: Francesco Andreuzzi ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27194/files - new: https://git.openjdk.org/jdk/pull/27194/files/2e63af88..d44cb277 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194 PR: https://git.openjdk.org/jdk/pull/27194 From abarashev at openjdk.org Thu Sep 11 13:57:28 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 11 Sep 2025 13:57:28 GMT Subject: Integrated: 8365953: Key manager returns no certificates when handshakeSession is not an ExtendedSSLSession In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 17:09:29 GMT, Artur Barashev wrote: > See X509KeyManagerCertChecking#getAlgorithmConstraints. If the handshake session is not an ExtendedSSLSession, the method returns constraints using a null list of peerSupportedSignAlgs, which in turn means that all certificates will be rejected. Accepting all signature schemes would probably be a better choice here, and that's what we do when the handshake session is not available at all. > > The SunJSSE SSLSockets and SSLEngines both return extended SSL sessions. There are no known third-party providers that return non-extended SSL sessions. This pull request has now been integrated. Changeset: 4ea8979b Author: Artur Barashev URL: https://git.openjdk.org/jdk/commit/4ea8979b93f80e9ecbc197ee12ceb523ef8da6aa Stats: 451 lines in 3 files changed: 406 ins; 14 del; 31 mod 8365953: Key manager returns no certificates when handshakeSession is not an ExtendedSSLSession Reviewed-by: djelinski, wetmore ------------- PR: https://git.openjdk.org/jdk/pull/27106 From fguallini at openjdk.org Thu Sep 11 14:32:17 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Thu, 11 Sep 2025 14:32:17 GMT Subject: Integrated: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 12:52:31 GMT, Fernando Guallini wrote: > The test javax/net/ssl/DTLS/PacketLossRetransmission takes about 2 minutes to complete. The reason is that the server or client socket times out after 10 seconds while waiting to receive a DatagramPacket that has already been removed (to simulate packet loss). Given that it will time out, it is better to reduce its value. > After reducing the timeout , the total test execution completes in approximately 15 seconds on average. > Additionally, unnecessary scenarios are removed; for instance, when acting as a client, there is no "server_hello" message type to remove, and similarly, when acting as a server, there is no "client_hello" message on that side, so there is no corresponding packet loss to simulate. It should keep only the scenarios that do lose messages. This pull request has now been integrated. Changeset: fc3e3e26 Author: Fernando Guallini URL: https://git.openjdk.org/jdk/commit/fc3e3e26c515ae0f9ae32aec504974fba393928d Stats: 34 lines in 2 files changed: 7 ins; 22 del; 5 mod 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java Reviewed-by: djelinski ------------- PR: https://git.openjdk.org/jdk/pull/27093 From abarashev at openjdk.org Thu Sep 11 15:48:07 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 11 Sep 2025 15:48:07 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v8] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into Check_RSASSA-PSS_cert_params # Conflicts: # src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java - Add a TrustManager check - Fix key algorithm bug. Add more test cases - Use null instead of SIGNATURE_CONSTRAINTS_MODE.NONE - Use default constraints if SIGNATURE_CONSTRAINTS_MODE is NONE. Log warning and return true on InvalidParameterSpecException - Address review comments - More test cases - 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints ------------- Changes: https://git.openjdk.org/jdk/pull/27146/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=07 Stats: 580 lines in 8 files changed: 427 ins; 106 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From naoto at openjdk.org Thu Sep 11 16:03:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 11 Sep 2025 16:03:20 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: <2KENBWE0y3RP7icnmW5njdDVhjku9jIxuDCTHbHKSek=.5d70302f-df86-4b5a-a523-45e5216a77ff@github.com> On Wed, 10 Sep 2025 17:33:05 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang 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 branch 'master' into 8354469 > - decouple PassFailJFrame.java change; simplify code flow > - the fix Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3212536122 From mark.reinhold at oracle.com Thu Sep 11 16:35:23 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 11 Sep 2025 16:35:23 +0000 Subject: New candidate JEP: 524: PEM Encodings of Cryptographic Objects (Second Preview) Message-ID: <20250911163426.930B3EE@naskeag.niobe.net> https://openjdk.org/jeps/524 Summary: Introduce an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the widely-used Privacy-Enhanced Mail (PEM) transport format, and for decoding from that format back into objects. This is a preview API. - Mark From ascarpino at openjdk.org Thu Sep 11 16:58:58 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 11 Sep 2025 16:58:58 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) Message-ID: Hi Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: - Renamed the name of `PEMRecord` class to `PEM`. - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. thanks Tony ------------- Commit messages: - fix test - simplify - doc and code updates - Merge branch 'master' into pem26 - doc and code updates - Merge branch 'master' into pem26 - Initial - Merge branch 'master' into pem26 - Rename PEMRecord to PEM Changes: https://git.openjdk.org/jdk/pull/27147/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360564 Stats: 995 lines in 15 files changed: 594 ins; 199 del; 202 mod Patch: https://git.openjdk.org/jdk/pull/27147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147 PR: https://git.openjdk.org/jdk/pull/27147 From weijun at openjdk.org Thu Sep 11 17:52:33 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 Sep 2025 17:52:33 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 06:26:37 GMT, Stuart Marks wrote: >> Weijun Wang 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 branch 'master' into 8354469 >> - decouple PassFailJFrame.java change; simplify code flow >> - the fix > > src/java.base/share/classes/sun/security/util/Password.java line 193: > >> 191: ba[bb.position()] = '\n'; >> 192: } >> 193: return ba; > > Some random comments. This is all internal to this class, and it's all vaguely cleanup, so it's up to you whether to take any action on any of these points. > > It might be worth having a comment on this method that explains why it's doing this. The "obvious" way of encoding the characters is to use String.getBytes(), but you probably don't want to create a String, because (I think) you want to be able to erase the arrays afterwards. Worth explaining, if true. > > At lines 190-191 the mixture of buffer and array stuff is kind of confusing. I think you can check whether bb.remaining() > 0 and use bb.put(). > > There are actually three possibilities for what's in the returned byte array: 1) it's completely filled with encoded bytes from the input; 2) it contains the encoded input followed by an NL byte; or 3) it contains the encoded input, an NL byte, followed by an arbitrary number of zero bytes. The way that the returned array is processed by the caller handles this, but it seems a bit brittle. One possibility is always to return an array of the exact correct length, including an NL byte. Of course this entails an extra copy (and an extra array to erase) but there are fewer cases for the caller to handle. Thanks. I'll add some comments and do not mix buffer and array. The `\n` trick as a stop sign will be kept to avoid too many changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2341920574 From weijun at openjdk.org Thu Sep 11 17:57:57 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 Sep 2025 17:57:57 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v4] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: use ByteBuffer::put for newline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/3ecf2443..5fa7b2f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=02-03 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From mullan at openjdk.org Thu Sep 11 19:00:30 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 11 Sep 2025 19:00:30 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v8] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 11 Sep 2025 15:48:07 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. > > Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into Check_RSASSA-PSS_cert_params > > # Conflicts: > # src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java > - Add a TrustManager check > - Fix key algorithm bug. Add more test cases > - Use null instead of SIGNATURE_CONSTRAINTS_MODE.NONE > - Use default constraints if SIGNATURE_CONSTRAINTS_MODE is NONE. Log warning and return true on InvalidParameterSpecException > - Address review comments > - More test cases > - 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 462: > 460: > 461: // Additional certificate chain check to verify the signature > 462: // algorithms with the corresponding signing keys. Suggest rewording: "Additional certificate chain check to verify that the algorithm constraints permit the signature algorithms to be used with the corresponding signing keys." src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 463: > 461: // Additional certificate chain check to verify the signature > 462: // algorithms with the corresponding signing keys. > 463: private void constraintsCertChainCheck( Can you add a few more comments explaining why this method is important for the `rsa_pss_rsae_*` schemes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2342034385 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2342026334 From mullan at openjdk.org Thu Sep 11 19:34:07 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 11 Sep 2025 19:34:07 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v8] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 11 Sep 2025 15:48:07 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. > > Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into Check_RSASSA-PSS_cert_params > > # Conflicts: > # src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java > - Add a TrustManager check > - Fix key algorithm bug. Add more test cases > - Use null instead of SIGNATURE_CONSTRAINTS_MODE.NONE > - Use default constraints if SIGNATURE_CONSTRAINTS_MODE is NONE. Log warning and return true on InvalidParameterSpecException > - Address review comments > - More test cases > - 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 312: > 310: checksDisabled = false; > 311: > 312: if (mode == null I can't find any code where `mode` can be `null`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2342134685 From abarashev at openjdk.org Thu Sep 11 20:02:14 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 11 Sep 2025 20:02:14 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v2] In-Reply-To: <0BiCRTf527p3XJDce5QSU2Qd63q-p25btTrA_aVQPDs=.89b7ecef-9964-4a94-9c98-d8cc94488670@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> <0BiCRTf527p3XJDce5QSU2Qd63q-p25btTrA_aVQPDs=.89b7ecef-9964-4a94-9c98-d8cc94488670@github.com> Message-ID: On Tue, 9 Sep 2025 16:58:01 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 311: >> >>> 309: supportedAlgorithms = null; >>> 310: supportedSignatureSchemes = null; >>> 311: checksDisabled = false; >> >> Not necessary to initialize, those are the defaults. > > Right, I just coded it this way for clarity. Removing those lines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2342199380 From abarashev at openjdk.org Thu Sep 11 20:02:18 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 11 Sep 2025 20:02:18 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v8] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 11 Sep 2025 19:29:09 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'master' into Check_RSASSA-PSS_cert_params >> >> # Conflicts: >> # src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java >> - Add a TrustManager check >> - Fix key algorithm bug. Add more test cases >> - Use null instead of SIGNATURE_CONSTRAINTS_MODE.NONE >> - Use default constraints if SIGNATURE_CONSTRAINTS_MODE is NONE. Log warning and return true on InvalidParameterSpecException >> - Address review comments >> - More test cases >> - 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints > > src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 312: > >> 310: checksDisabled = false; >> 311: >> 312: if (mode == null > > I can't find any code where `mode` can be `null`. There is no such code currently. But if somebody makes a call with `null` mode in the future it will create `SupportedSignatureAlgorithmConstraints` object that will always return `false` on permit calls because of the `if (supportedAlgorithms == null || supportedAlgorithms.isEmpty())` check below. So I think it makes sense to check for it here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2342197304 From abarashev at openjdk.org Thu Sep 11 20:37:20 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 11 Sep 2025 20:37:20 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v8] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 11 Sep 2025 18:40:43 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'master' into Check_RSASSA-PSS_cert_params >> >> # Conflicts: >> # src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java >> - Add a TrustManager check >> - Fix key algorithm bug. Add more test cases >> - Use null instead of SIGNATURE_CONSTRAINTS_MODE.NONE >> - Use default constraints if SIGNATURE_CONSTRAINTS_MODE is NONE. Log warning and return true on InvalidParameterSpecException >> - Address review comments >> - More test cases >> - 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints > > src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 462: > >> 460: >> 461: // Additional certificate chain check to verify the signature >> 462: // algorithms with the corresponding signing keys. > > Suggest rewording: "Additional certificate chain check to verify that the algorithm constraints permit the signature algorithms to be used with the corresponding signing keys." Done, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2342277956 From abarashev at openjdk.org Thu Sep 11 20:42:22 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 11 Sep 2025 20:42:22 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v8] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 11 Sep 2025 18:36:32 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'master' into Check_RSASSA-PSS_cert_params >> >> # Conflicts: >> # src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java >> - Add a TrustManager check >> - Fix key algorithm bug. Add more test cases >> - Use null instead of SIGNATURE_CONSTRAINTS_MODE.NONE >> - Use default constraints if SIGNATURE_CONSTRAINTS_MODE is NONE. Log warning and return true on InvalidParameterSpecException >> - Address review comments >> - More test cases >> - 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints > > src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 463: > >> 461: // Additional certificate chain check to verify the signature >> 462: // algorithms with the corresponding signing keys. >> 463: private void constraintsCertChainCheck( > > Can you add a few more comments explaining why this method is important for the `rsa_pss_rsae_*` schemes? Done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2342289179 From valeriep at openjdk.org Thu Sep 11 22:03:21 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 11 Sep 2025 22:03:21 GMT Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 14:53:05 GMT, Thomas Fitzsimmons wrote: >> Perhaps check the existence of the file and error out with the config file and its path if the check fails, this way, it's crystal clear. > > @valeriepeng I simplified the approach; let me know what you think. I confirmed I can still configure Kryoptic as needed, though I have to name the `Kryoptic` configuration files `nss/p11-nss.txt` and `nss/p11-nss-sensitive.txt`, which is a little strange. However this has the advantage of eliminating the need to change any test case arguments. Yes, I like this approach, it minimizes the changes at the cost of setting up, i.e. rename Kryoptic files to match NSS file names. Thanks for this very simple approach. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26325#discussion_r2342430961 From abarashev at openjdk.org Thu Sep 11 22:06:10 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 11 Sep 2025 22:06:10 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v9] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Update comments. Remove unnecessary variable assignments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/29f8d27a..85a7b6f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=07-08 Stats: 12 lines in 2 files changed: 6 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From valeriep at openjdk.org Thu Sep 11 22:07:01 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 11 Sep 2025 22:07:01 GMT Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java [v3] In-Reply-To: <0XADRuvWc-HhIE4exZUSxniPKI9zwGMD_bkcFWv-Tns=.02e3a87f-1dff-4071-9ab5-11a729fbf9ba@github.com> References: <0XADRuvWc-HhIE4exZUSxniPKI9zwGMD_bkcFWv-Tns=.02e3a87f-1dff-4071-9ab5-11a729fbf9ba@github.com> Message-ID: On Wed, 3 Sep 2025 00:22:16 GMT, Thomas Fitzsimmons wrote: >> This patch adds configurability to `PKCS11Test.java`. >> >> Specifically, it adds two new system properties: >> >> - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the `nss_library` field. Prior to this patch, `nss_library` was set to either `"softokn3"` or `"nss3"`. >> >> - `CUSTOM_P11_CONFIG_VARIANT`: Abstract the configuration file type to load. Prior to this patch, test cases that wanted to run `NSS` in sensitive mode would hard-code `p11-nss-sensitive.txt` on their command lines. >> >> The patch updates the three `p11-nss-sensitive.txt`-using test cases to use the new `CUSTOM_P11_CONFIG_VARIANT` property: >> >> >> test/jdk/java/security/KeyAgreement/Generic.java >> test/jdk/sun/security/pkcs11/Mac/TestLargeSecretKeys.java >> test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java >> >> >> I have been using this change to run `PKCS11Test.java` against the [Kryoptic](https://github.com/latchset/kryoptic) PKCS11 soft token, using this invocation: >> >> >> make test \ >> JTREG="JAVA_OPTIONS=-DCUSTOM_P11_CONFIG=/tmp/kryoptic-configuration/p11-kryoptic.txt \ >> -DCUSTOM_P11_LIBRARY_NAME=kryoptic_pkcs11 \ >> -Djdk.test.lib.artifacts.nsslib-linux_x64=/tmp/kryoptic-configuration \ >> -DCUSTOM_DB_DIR=/tmp/kryoptic-configuration" >> >> >> `/tmp/kryoptic-configuration` contains (among other files): >> >> >> libkryoptic_pkcs11.so >> p11-kryoptic.txt >> p11-kryoptic-sensitive.txt >> >> >> With `CUSTOM_P11_LIBRARY_NAME` set, `PKCS11Test.java` can find `libkryoptic_pkcs11.so`. >> >> And setting `CUSTOM_P11_CONFIG` causes the sensitive tests to use `p11-kryoptic-sensitive.txt` via the new `CUSTOM_P11_CONFIG_VARIANT` property. >> >> On my `Fedora 42` `x86-64` machine, I tested for regressions with: >> >> $ time make test JOBS=4 JTREG="JAVA_OPTIONS=-Djdk.test.lib.artifacts.nsslib-linux_x64=/usr/lib64" TEST="test/jdk/sun/security/pkcs11" >> >> and: >> >> $ time make test JOBS=4 TEST="test/jdk/sun/security/pkcs11" > > Thomas Fitzsimmons has updated the pull request incrementally with one additional commit since the last revision: > > Remove CUSTOM_P11_CONFIG_VARIANT, add CUSTOM_P11_BASE_DIR Marked as reviewed by valeriep (Reviewer). For consistency sake, could you please update the description of https://bugs.openjdk.org/browse/JDK-8361711 to match the current PR? It no longer adds the new CUSTOM_P11_CONFIG_VARIANT property. ------------- PR Review: https://git.openjdk.org/jdk/pull/26325#pullrequestreview-3213762989 PR Comment: https://git.openjdk.org/jdk/pull/26325#issuecomment-3282771349 From hchao at openjdk.org Thu Sep 11 23:52:13 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Thu, 11 Sep 2025 23:52:13 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v4] In-Reply-To: References: Message-ID: <8Hl8M2taWGiLBmqahDqgqsKD_T6n17_C7JONGAyLcvI=.5c282639-970e-4f8f-8105-5a2e97080b08@github.com> On Thu, 11 Sep 2025 17:57:57 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > use ByteBuffer::put for newline Marked as reviewed by hchao (Reviewer). Changes look good. I ran the newly created manual test on Mac and the test was running fine. ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3214033002 PR Comment: https://git.openjdk.org/jdk/pull/27196#issuecomment-3282998016 From valeriep at openjdk.org Fri Sep 12 00:36:23 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Sep 2025 00:36:23 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v10] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Thu, 4 Sep 2025 12:46:48 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments from Sean. > > src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 51: > >> 49: >> 50: // Disabled algorithm security property for JCE crypto services >> 51: public static final String PROPERTY_CRYPTO_DISABLED_ALGS = > > I think this can be private. Yes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2342643101 From valeriep at openjdk.org Fri Sep 12 01:33:56 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Sep 2025 01:33:56 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v11] In-Reply-To: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: > This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s). > > A few implementation notes: > 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services. > 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints. > 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. > > CSR will be filed once the review is wrapping up. > > Thanks~ > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Changed public static final constant to private per Sean's suggestion. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26377/files - new: https://git.openjdk.org/jdk/pull/26377/files/0bd4413c..f6b8aae3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26377&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26377&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26377/head:pull/26377 PR: https://git.openjdk.org/jdk/pull/26377 From valeriep at openjdk.org Fri Sep 12 01:33:56 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Sep 2025 01:33:56 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v10] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: <-UVq3aI4GOjwxn0qObkRsFJ-TLLueU3412iRTaUyE0I=.376c5e62-bcc4-4b56-8252-6da7ae455d35@github.com> On Thu, 4 Sep 2025 12:57:29 GMT, Sean Mullan wrote: > One more comment, otherwise looks good. > > Also, add a release note. Done, please find it at https://bugs.openjdk.org/browse/JDK-8367477 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26377#issuecomment-3283297197 From smarks at openjdk.org Fri Sep 12 03:40:16 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 12 Sep 2025 03:40:16 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v4] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 17:57:57 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > use ByteBuffer::put for newline Marked as reviewed by smarks (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3214475801 From smarks at openjdk.org Fri Sep 12 03:40:18 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 12 Sep 2025 03:40:18 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 17:50:10 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/Password.java line 193: >> >>> 191: ba[bb.position()] = '\n'; >>> 192: } >>> 193: return ba; >> >> Some random comments. This is all internal to this class, and it's all vaguely cleanup, so it's up to you whether to take any action on any of these points. >> >> It might be worth having a comment on this method that explains why it's doing this. The "obvious" way of encoding the characters is to use String.getBytes(), but you probably don't want to create a String, because (I think) you want to be able to erase the arrays afterwards. Worth explaining, if true. >> >> At lines 190-191 the mixture of buffer and array stuff is kind of confusing. I think you can check whether bb.remaining() > 0 and use bb.put(). >> >> There are actually three possibilities for what's in the returned byte array: 1) it's completely filled with encoded bytes from the input; 2) it contains the encoded input followed by an NL byte; or 3) it contains the encoded input, an NL byte, followed by an arbitrary number of zero bytes. The way that the returned array is processed by the caller handles this, but it seems a bit brittle. One possibility is always to return an array of the exact correct length, including an NL byte. Of course this entails an extra copy (and an extra array to erase) but there are fewer cases for the caller to handle. > > Thanks. I'll add some comments and do not mix buffer and array. The `\n` trick as a stop sign will be kept to avoid too many changes. Thanks for the updates. Re-approving in case it's necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2342858920 From jpai at openjdk.org Fri Sep 12 11:32:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 11:32:18 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). >> >> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update NPE per roger review Hello Chen, I had a look at the changes, but I'm missing some broader context of this change. The JBS issue and the PR description states that this PR is in preparation (to upcoming additional work?) to support better `NullPointerException` exception messages when some code uses `Objects.requireNonNull()`. It also talks about a `java.lang.runtime.Checks::nullCheck` method, but there's no such `java.lang.runtime.Checks` class in mainline and it appears to be a proposed class in Valhalla project (https://bugs.openjdk.org/browse/JDK-8357936). But there too it's non-existent for now. So I'll leave out the `Checks` class from this discussion. If this change were to be integrated into mainline, would there be any change to NullPointerException exception messages in any code paths? If not, then would it better to do these changes along with the `Objects.requireNonNull()` change itself, as part of https://bugs.openjdk.org/browse/JDK-8233268? In JDK-8233268, there's also a comment from Goetz proposing how the new exception message should look like. If the current changes were to be done, would it allow for that proposal to be implemented? I did have a brief look at the new jtreg test cases in this PR, but it wasn't immediately clear to me which APIs would start seeing this new proposed exception messages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3284904586 From mullan at openjdk.org Fri Sep 12 13:21:35 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 Sep 2025 13:21:35 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v9] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 11 Sep 2025 22:06:10 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Update comments. Remove unnecessary variable assignments. Looks good. src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 475: > 473: // Omit checks if EE cert is also a trust anchor > 474: if (chain.length > 1) { > 475: AlgorithmChecker checker = new AlgorithmChecker( Another option would be to add this `AlgorithmChecker` as another checker in the `PKIXBuilderParameters` when instantiating a `PKIXValidator`, and then the `Validator` would just call this additional checker when validating the chain. But this is a bit more complicated because the caller can pass in their own `PKIXBuilderParameters`. But noting here for reference that it is another option. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27146#pullrequestreview-3216635377 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2344242058 From mullan at openjdk.org Fri Sep 12 13:21:40 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 Sep 2025 13:21:40 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v8] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 11 Sep 2025 19:57:48 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 312: >> >>> 310: checksDisabled = false; >>> 311: >>> 312: if (mode == null >> >> I can't find any code where `mode` can be `null`. > > There is no such code currently. But if somebody makes a call with `null` mode in the future it will create `SupportedSignatureAlgorithmConstraints` object that will always return `false` on permit calls because of the `if (supportedAlgorithms == null || supportedAlgorithms.isEmpty())` check below. So I think it makes sense to check for it here. Ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2344215826 From aefimov at openjdk.org Fri Sep 12 13:33:19 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 12 Sep 2025 13:33:19 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:08:20 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 656 commits: > > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 Marked as reviewed by aefimov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3216731618 From weijun at openjdk.org Fri Sep 12 14:15:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 Sep 2025 14:15:51 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v5] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 00:54:04 GMT, Jamil Nimeh wrote: >> This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. >> >> Credit and thanks to @jaikiran for finding the issue and providing reproducer code. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Add tests for encryption correctness, also add tests for MemorySegment ByteBuffers test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/UpdateAADTest.java line 74: > 72: > 73: public interface TestAction { > 74: void runTest(ByteBuffer buffer); If you allow `runTest` to throw an exception, then there is no need to catch and rethrow in the 2 instances. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27081#discussion_r2344388738 From jnimeh at openjdk.org Fri Sep 12 14:22:56 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 12 Sep 2025 14:22:56 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v5] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 14:12:17 GMT, Weijun Wang wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: >> >> Add tests for encryption correctness, also add tests for MemorySegment ByteBuffers > > test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/UpdateAADTest.java line 74: > >> 72: >> 73: public interface TestAction { >> 74: void runTest(ByteBuffer buffer); > > If you allow `runTest` to throw an exception, then there is no need to catch and rethrow in the 2 instances. Good point, I think that's a remnant from when I had those callbacks as `Runnable` implementations and had to rewrap the checked exceptions inside unchecked ones. I'll change the interface to throw exception as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27081#discussion_r2344405588 From mullan at openjdk.org Fri Sep 12 14:28:45 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 Sep 2025 14:28:45 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v11] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Fri, 12 Sep 2025 01:33:56 GMT, Valerie Peng wrote: >> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s). >> >> A few implementation notes: >> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services. >> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints. >> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. >> >> CSR will be filed once the review is wrapping up. >> >> Thanks~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Changed public static final constant to private per Sean's suggestion. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26377#pullrequestreview-3216967532 From mullan at openjdk.org Fri Sep 12 14:28:47 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 Sep 2025 14:28:47 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v10] In-Reply-To: <-UVq3aI4GOjwxn0qObkRsFJ-TLLueU3412iRTaUyE0I=.376c5e62-bcc4-4b56-8252-6da7ae455d35@github.com> References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> <-UVq3aI4GOjwxn0qObkRsFJ-TLLueU3412iRTaUyE0I=.376c5e62-bcc4-4b56-8252-6da7ae455d35@github.com> Message-ID: On Fri, 12 Sep 2025 01:25:53 GMT, Valerie Peng wrote: > > One more comment, otherwise looks good. > > Also, add a release note. > > Done, please find it at https://bugs.openjdk.org/browse/JDK-8367477 Thanks, I made a few minor wording edits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26377#issuecomment-3285504362 From duke at openjdk.org Fri Sep 12 14:36:01 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Fri, 12 Sep 2025 14:36:01 GMT Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java [v3] In-Reply-To: References: <0XADRuvWc-HhIE4exZUSxniPKI9zwGMD_bkcFWv-Tns=.02e3a87f-1dff-4071-9ab5-11a729fbf9ba@github.com> Message-ID: <2mMcyT7ocqTLUwsKnRY9x5qgvoymaFPQ14kTYiHILR4=.f5cdcfef-57e0-4a29-9a2c-7ef4aa5cd1cb@github.com> On Thu, 11 Sep 2025 22:03:47 GMT, Valerie Peng wrote: > For consistency sake, could you please update the description of https://bugs.openjdk.org/browse/JDK-8361711 to match the current PR? It no longer adds the new CUSTOM_P11_CONFIG_VARIANT property. Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26325#issuecomment-3285532662 From duke at openjdk.org Fri Sep 12 14:36:02 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Fri, 12 Sep 2025 14:36:02 GMT Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java [v3] In-Reply-To: References: Message-ID: <0DxVEYx6LxvH-jezuYcA4Li2aVXeuJ9xsg1symiJMM8=.ce3d6156-bf03-4744-bc5f-478c54fc6b94@github.com> On Thu, 11 Sep 2025 22:00:27 GMT, Valerie Peng wrote: >> @valeriepeng I simplified the approach; let me know what you think. I confirmed I can still configure Kryoptic as needed, though I have to name the `Kryoptic` configuration files `nss/p11-nss.txt` and `nss/p11-nss-sensitive.txt`, which is a little strange. However this has the advantage of eliminating the need to change any test case arguments. > > Yes, I like this approach, it minimizes the changes at the cost of setting up, i.e. rename Kryoptic files to match NSS file names. Thanks for this very simple approach. OK, thank you for re-reviewing and approving. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26325#discussion_r2344447880 From duke at openjdk.org Fri Sep 12 14:41:37 2025 From: duke at openjdk.org (duke) Date: Fri, 12 Sep 2025 14:41:37 GMT Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java [v3] In-Reply-To: <0XADRuvWc-HhIE4exZUSxniPKI9zwGMD_bkcFWv-Tns=.02e3a87f-1dff-4071-9ab5-11a729fbf9ba@github.com> References: <0XADRuvWc-HhIE4exZUSxniPKI9zwGMD_bkcFWv-Tns=.02e3a87f-1dff-4071-9ab5-11a729fbf9ba@github.com> Message-ID: On Wed, 3 Sep 2025 00:22:16 GMT, Thomas Fitzsimmons wrote: >> This patch adds configurability to `PKCS11Test.java`. >> >> Specifically, it adds two new system properties: >> >> - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the `nss_library` field. Prior to this patch, `nss_library` was set to either `"softokn3"` or `"nss3"`. >> >> - `CUSTOM_P11_CONFIG_VARIANT`: Abstract the configuration file type to load. Prior to this patch, test cases that wanted to run `NSS` in sensitive mode would hard-code `p11-nss-sensitive.txt` on their command lines. >> >> The patch updates the three `p11-nss-sensitive.txt`-using test cases to use the new `CUSTOM_P11_CONFIG_VARIANT` property: >> >> >> test/jdk/java/security/KeyAgreement/Generic.java >> test/jdk/sun/security/pkcs11/Mac/TestLargeSecretKeys.java >> test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java >> >> >> I have been using this change to run `PKCS11Test.java` against the [Kryoptic](https://github.com/latchset/kryoptic) PKCS11 soft token, using this invocation: >> >> >> make test \ >> JTREG="JAVA_OPTIONS=-DCUSTOM_P11_CONFIG=/tmp/kryoptic-configuration/p11-kryoptic.txt \ >> -DCUSTOM_P11_LIBRARY_NAME=kryoptic_pkcs11 \ >> -Djdk.test.lib.artifacts.nsslib-linux_x64=/tmp/kryoptic-configuration \ >> -DCUSTOM_DB_DIR=/tmp/kryoptic-configuration" >> >> >> `/tmp/kryoptic-configuration` contains (among other files): >> >> >> libkryoptic_pkcs11.so >> p11-kryoptic.txt >> p11-kryoptic-sensitive.txt >> >> >> With `CUSTOM_P11_LIBRARY_NAME` set, `PKCS11Test.java` can find `libkryoptic_pkcs11.so`. >> >> And setting `CUSTOM_P11_CONFIG` causes the sensitive tests to use `p11-kryoptic-sensitive.txt` via the new `CUSTOM_P11_CONFIG_VARIANT` property. >> >> On my `Fedora 42` `x86-64` machine, I tested for regressions with: >> >> $ time make test JOBS=4 JTREG="JAVA_OPTIONS=-Djdk.test.lib.artifacts.nsslib-linux_x64=/usr/lib64" TEST="test/jdk/sun/security/pkcs11" >> >> and: >> >> $ time make test JOBS=4 TEST="test/jdk/sun/security/pkcs11" > > Thomas Fitzsimmons has updated the pull request incrementally with one additional commit since the last revision: > > Remove CUSTOM_P11_CONFIG_VARIANT, add CUSTOM_P11_BASE_DIR @fitzsim Your change (at version 423962fe813c5c3ab656771aebcb54f493da1ff9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26325#issuecomment-3285557586 From jnimeh at openjdk.org Fri Sep 12 15:01:46 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 12 Sep 2025 15:01:46 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v6] In-Reply-To: References: Message-ID: > This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. > > Credit and thanks to @jaikiran for finding the issue and providing reproducer code. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Simplify exception behavior in test callbacks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27081/files - new: https://git.openjdk.org/jdk/pull/27081/files/10e7e1f5..f9f4f212 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27081&range=04-05 Stats: 38 lines in 1 file changed: 0 ins; 9 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/27081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27081/head:pull/27081 PR: https://git.openjdk.org/jdk/pull/27081 From weijun at openjdk.org Fri Sep 12 16:04:17 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 Sep 2025 16:04:17 GMT Subject: RFR: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks [v6] In-Reply-To: References: Message-ID: <9tlpxJ02WaviEkqIVHhu570p5jnXNFtXf-7V3wyyG78=.c260d512-754a-4551-87ca-dbac84ec1fb4@github.com> On Fri, 12 Sep 2025 15:01:46 GMT, Jamil Nimeh wrote: >> This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. >> >> Credit and thanks to @jaikiran for finding the issue and providing reproducer code. > > Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: > > Simplify exception behavior in test callbacks Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27081#pullrequestreview-3217508527 From abarashev at openjdk.org Fri Sep 12 18:16:11 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 12 Sep 2025 18:16:11 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v9] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Fri, 12 Sep 2025 13:18:25 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comments. Remove unnecessary variable assignments. > > src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 475: > >> 473: // Omit checks if EE cert is also a trust anchor >> 474: if (chain.length > 1) { >> 475: AlgorithmChecker checker = new AlgorithmChecker( > > Another option would be to add this `AlgorithmChecker` as another checker in the `PKIXBuilderParameters` when instantiating a `PKIXValidator`, and then the `Validator` would just call this additional checker when validating the chain. But this is a bit more complicated because the caller can pass in their own `PKIXBuilderParameters`. But noting here for reference that it is another option. I put together an alternative solution that avoids duplicate calls: https://github.com/openjdk/jdk/pull/27262/files#diff-c691895596058f5eb4ec609c75ad83ef4a16da85ce6f3499ca89ef412eab15bf ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2345080596 From wetmore at openjdk.org Fri Sep 12 18:42:37 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 12 Sep 2025 18:42:37 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v20] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 14:27:20 GMT, Sean Coffey wrote: >> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago. >> >> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. >> >> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options : >> >> >> System.err.println("help print the help messages"); >> System.err.println("expand expand debugging information"); >> System.err.println(); >> System.err.println("all turn on all debugging"); >> System.err.println("ssl turn on ssl debugging"); >> System.err.println(); >> System.err.println("The following can be used with ssl:"); >> System.err.println("\trecord enable per-record tracing"); >> System.err.println("\thandshake print each handshake message"); >> System.err.println("\tkeygen print key generation data"); >> System.err.println("\tsession print session activity"); >> System.err.println("\tdefaultctx print default SSL initialization"); >> System.err.println("\tsslctx print SSLContext tracing"); >> System.err.println("\tsessioncache print session cache tracing"); >> System.err.println("\tkeymanager print key manager tracing"); >> System.err.println("\ttrustmanager print trust manager tracing"); >> System.err.println("\tpluggability print pluggability tracing"); >> System.err.println(); >> System.err.println("\thandshake debugging can be widened with:"); >> System.err.println("\tdata hex dump of each handshake message"); >> System.err.println("\tverbose verbose handshake message printing"); >> System.err.println(); >> System.err.println("\trecord debugging can be widened with:"); >> System.err.println("\tplaintext hex dump of record plaintext"); >> System.err.println("\tpacket print raw SSL/TLS packets"); >> >> >> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. >> >> the output has changed slightly with respect to that - less verbose >> >> e.g. old... > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Further review comments, copyright years also A couple more minor comments. All copyrights look good. (Thanks.) src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 217: > 215: "print each handshake message"); > 216: System.err.printf(" %-12s %s%n", "verbose", > 217: "-verbose handshake message printing (widens handshake)"); Minor nit. Having "-" at the beginning of the textual description on these "wideners" looks odd to my eye. "-" are usually for in front of the command args. e.g. The following filters can be used with ssl: .... handshake print each handshake message verbose -verbose handshake message printing (widens handshake) record enable per-record tracing packet -print raw SSL/TLS packets (widens record) plaintext -hex dump of record plaintext (widens record) src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 236: > 234: System.err.printf(" %-14s %s%n", "trustmanager", > 235: "print trust manager tracing"); > 236: System.err.println(); Do we want to include something like this at the bottom?: > Adding filters to "ssl" will filter log messages to include just those categories. If "ssl" is specified by itself, all non-widening filters are enabled. ------------- PR Review: https://git.openjdk.org/jdk/pull/18764#pullrequestreview-3214120399 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2342697466 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2342710103 From wetmore at openjdk.org Fri Sep 12 18:42:41 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 12 Sep 2025 18:42:41 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v19] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 11:00:08 GMT, Sean Coffey wrote: >> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 128: >> >>> 126: // javax.net.debug would be misconfigured property with respect >>> 127: // to logging if value didn't contain "all" or "ssl" >>> 128: logging = Opt.ALL.on || Opt.SSL.on; >> >> I don't have a strong feeling about this either way, but a usage question here. >> >> If they have specified some args but not `ssl`. e.g. >> >> -Djavax.net.debug=trustmanager,keymanager >> >> Should we: >> >> 1. quietly ignore as this is are doing >> 2. output a single log message saying logging is disabled. >> 3. a fatal error > > I'm leaning towards option 1. no logging gets enabled in misconfigured values. I've test code covering this scenario. > > option 2 might be useful and if there's a strong desire for that, perhaps we can alter in follow on JDK issue. > option 3 sounds a bit heavy handed, Don't think we need to have a fatal error. Also, since the load time for loading SSLLogger is variable, it could be dangerous (e.g. app runs fine for 1st 10 mins and then trigger an error etc) I am fine with #1. We'll see if anyone requests. Just wanted to bring it up as an option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2342660580 From wetmore at openjdk.org Fri Sep 12 18:42:38 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 12 Sep 2025 18:42:38 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v20] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 02:21:53 GMT, Bradford Wetmore wrote: >> good point. I think it might have been wiped away in earlier iterations. I've added it back and added test coverage for this option. The separator logic for such options isn't specified which makes coding more tricky. I've tried to keep the syntax parsing flexible. > > Maybe add a bit about what `expand` does? > >> expand expanded (less compact) output format Thanks. This can be marked as resolved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2345123795 From wetmore at openjdk.org Fri Sep 12 18:42:39 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 12 Sep 2025 18:42:39 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v20] In-Reply-To: References: <9c4844QSgob8GctN-xTWMJZUReaX3xqFmggYay_dhHE=.5ad13589-6c6b-4dad-b3b7-29e119fdf8c7@github.com> Message-ID: On Wed, 20 Nov 2024 11:38:41 GMT, Sean Coffey wrote: >> Can we get that added back, or maybe added to a follow-on bug? That seemed useful. > > found the change where this debug option got dropped circa 2009: JDK-4918870 > > yes - we can log a new issue to track this request Thanks for adding to the `enum` and help message. Just need to add it to the actual call sites, which can be done as part of JDK-8344158. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2345115169 From valeriep at openjdk.org Fri Sep 12 19:04:25 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Sep 2025 19:04:25 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v10] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> <-UVq3aI4GOjwxn0qObkRsFJ-TLLueU3412iRTaUyE0I=.376c5e62-bcc4-4b56-8252-6da7ae455d35@github.com> Message-ID: On Fri, 12 Sep 2025 14:26:01 GMT, Sean Mullan wrote: > > > One more comment, otherwise looks good. > > > Also, add a release note. > > > > > > Done, please find it at https://bugs.openjdk.org/browse/JDK-8367477 > > Thanks, I made a few minor wording edits. Great, thanks for the review! Edits look good and I have marked it as Delivered. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26377#issuecomment-3286503429 From liach at openjdk.org Fri Sep 12 19:14:27 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Sep 2025 19:14:27 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 11:28:41 GMT, Jaikiran Pai wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update NPE per roger review > > Hello Chen, I had a look at the changes, but I'm missing some broader context of this change. > > The JBS issue and the PR description states that this PR is in preparation (to upcoming additional work?) to support better `NullPointerException` exception messages when some code uses `Objects.requireNonNull()`. It also talks about a `java.lang.runtime.Checks::nullCheck` method, but there's no such `java.lang.runtime.Checks` class in mainline and it appears to be a proposed class in Valhalla project (https://bugs.openjdk.org/browse/JDK-8357936). But there too it's non-existent for now. So I'll leave out the `Checks` class from this discussion. > > If this change were to be integrated into mainline, would there be any change to NullPointerException exception messages in any code paths? If not, then would it better to do these changes along with the `Objects.requireNonNull()` change itself, as part of https://bugs.openjdk.org/browse/JDK-8233268? In JDK-8233268, there's also a comment from Goetz proposing how the new exception message should look like. If the current changes were to be done, would it allow for that proposal to be implemented? > > I did have a brief look at the new jtreg test cases in this PR, but it wasn't immediately clear to me which APIs would start seeing this new proposed exception messages. Hi @jaikiran, this is currently neutral to mainline. I split the actual Objects.rNN changes because they have to go through CSR reviews. The actual change to hook it up was removed in https://github.com/openjdk/jdk/pull/26600/commits/39c2d16fa98276319d18cf9334e1e9c794e56779. The message is not the same as what Goetz Lindenmaier proposed, in part because the information about the source of the exception is already obvious in the stack traces (top level is always the null check API). I decided to only include which slot had null instead. In the test suite, the new API to see the proposed new exception messages would be `NullCheckAPITest::nullCheck`. This demonstrates the flexibility of this new system I added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3286532403 From weijun at openjdk.org Fri Sep 12 20:10:22 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 Sep 2025 20:10:22 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 15:42:13 GMT, Anthony Scarpino wrote: > Hi > > Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: > > - Renamed the name of `PEMRecord` class to `PEM`. > - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. > - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. > > thanks > > Tony Some comments. src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 255: > 253: if (seq.data.available() != 0) { > 254: DerValue derValue = seq.data.getDerValue(); > 255: if (derValue.isContextSpecific((byte) 1)) { If any of these `if`s is false `null` is returned. Would you rather throw an IAE? src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 159: > 157: privKeyMaterial = val.data.getOctetString(); > 158: > 159: // Special check and parsing for ECDSA's SEC1v2 format So there are 2 ways to extract public key from PKCS8. Are you going to check whether they match? Also, can we add a test case for this format? src/java.base/share/classes/sun/security/util/Pem.java line 355: > 353: return pemEncoded(pem.type(), p); > 354: } > 355: Is it correct to put the 2 new methods here? Seems not closely related to PEM. src/java.base/share/classes/sun/security/util/Pem.java line 387: > 385: * return a PrivateKey > 386: * @param provider KeyFactory provider > 387: */ This method is very similar to `PKCS8Key::parseKey`. Maybe we should combine them. test/jdk/javax/crypto/EncryptedPrivateKeyInfo/GetKeyPair.java line 87: > 85: kp.getPublic().getEncoded())) { > 86: throw new AssertionError("PublicKey didn't match the original."); > 87: } Maybe put these checks into a method and call it three times? Also, you can use `Asserts.assertEqualsByteArray`. ------------- PR Review: https://git.openjdk.org/jdk/pull/27147#pullrequestreview-3218055847 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2345111099 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2345047110 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2345040355 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2345041626 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2345020741 From weijun at openjdk.org Fri Sep 12 20:10:24 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 Sep 2025 20:10:24 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 18:29:55 GMT, Weijun Wang wrote: >> Hi >> >> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: >> >> - Renamed the name of `PEMRecord` class to `PEM`. >> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. >> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. >> >> thanks >> >> Tony > > src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 255: > >> 253: if (seq.data.available() != 0) { >> 254: DerValue derValue = seq.data.getDerValue(); >> 255: if (derValue.isContextSpecific((byte) 1)) { > > If any of these `if`s is false `null` is returned. Would you rather throw an IAE? I see there could be a parameters [0] ECDomainParameters {{ SECGCurveNames }} OPTIONAL, Shall we skip it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2345120268 From valeriep at openjdk.org Fri Sep 12 20:20:35 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Sep 2025 20:20:35 GMT Subject: Integrated: 8244336: Restrict algorithms at JCE layer In-Reply-To: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> Message-ID: On Fri, 18 Jul 2025 01:44:33 GMT, Valerie Peng wrote: > This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s). > > A few implementation notes: > 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services. > 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints. > 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. > > CSR will be filed once the review is wrapping up. > > Thanks~ > Valerie This pull request has now been integrated. Changeset: 35dabb1a Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/35dabb1a5f31d985f00de21badeeedb026a63b94 Stats: 1566 lines in 19 files changed: 1364 ins; 163 del; 39 mod 8244336: Restrict algorithms at JCE layer Reviewed-by: mullan, ascarpino, abarashev ------------- PR: https://git.openjdk.org/jdk/pull/26377 From jnimeh at openjdk.org Fri Sep 12 20:42:37 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 12 Sep 2025 20:42:37 GMT Subject: Integrated: 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks In-Reply-To: References: Message-ID: <28IsTJESypGW6uTtnFB2XjWw72fhi-658_SshtBblj4=.196477fe-2c04-40f1-99d2-c8977e331529@github.com> On Thu, 4 Sep 2025 02:23:50 GMT, Jamil Nimeh wrote: > This fix resolves an issue where the `Cipher.updateAAD(ByteBuffer)` method, when used on a ChaCha20-Poly1305 Cipher, may throw an exception due to an offset calculation error. This occurs when the ByteBuffer is array-backed, and when the buffer passed into the method is a slice of another array-backed buffer and that slice begins at a non-zero offset in the parent ByteBuffer. > > Credit and thanks to @jaikiran for finding the issue and providing reproducer code. This pull request has now been integrated. Changeset: 3eb3e0dc Author: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/3eb3e0dcb0aa06fe427adeeaa40b9568c7f07ee8 Stats: 191 lines in 2 files changed: 189 ins; 0 del; 2 mod 8366833: Poly1305 does not always correctly update position for array-backed ByteBuffers after processMultipleBlocks Co-authored-by: Jaikiran Pai Reviewed-by: weijun, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27081 From ascarpino at openjdk.org Fri Sep 12 21:14:34 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 12 Sep 2025 21:14:34 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v43] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 23:03:49 GMT, Weijun Wang wrote: >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >> image > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: > > - Merge branch 'master' into 8325448 > - about transformation > - cannot reset with withMethods > - algorithm identifier > - withMethods > - duplicated "value" words > - receiver to recipient; different to specified > - use different exception type > - more spec change > - address Sean's comments > - ... and 48 more: https://git.openjdk.org/jdk/compare/7fcce270...1ec31cf5 src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 154: > 152: /** > 153: * KEM algorithm identifier for DHKEM(P-256, HKDF-SHA256) as defined in > 154: * Section 7.1 of RFC 9180. Suggestion: It has been my impression that `@spec` was for things like this. Might it be cleaner to remove the "as defined in " and just list the RFC in an `@spec`? It also seems overkill to refer to the RFC sections for each entry as you mention that the id's are in in Section 7 in the class javadoc. src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 286: > 284: * @throws IllegalArgumentException if {@code info} is empty. > 285: */ > 286: public HPKEParameterSpec withInfo(byte[] info) { After reading your example at the class javadoc level, it left me with the impression that `withInfo()` would be used with `String`. Does it make sense to have a `withInfo(String)` method? Or maybe the example less String-specific? src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 317: > 315: throw new IllegalArgumentException("psk_id is empty"); > 316: } > 317: if ("RAW".equalsIgnoreCase(psk.getFormat())) { What happens if the format is not RAW? Is that allowed or should it be an IAE? If `psk` is an 16 byte AES Secret key is that checked somewhere or at all relevant? src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 352: > 350: * authentication key value. > 351: *

> 352: * Note: this method does not check whether the KEM supports "the KEM supports" sounds awkward to me. Do you mean non-DHKEM or the KEM provider implementation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2345198777 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2345243742 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2345408266 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2345423554 From rriggs at openjdk.org Fri Sep 12 22:30:39 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 12 Sep 2025 22:30:39 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v10] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> <-UVq3aI4GOjwxn0qObkRsFJ-TLLueU3412iRTaUyE0I=.376c5e62-bcc4-4b56-8252-6da7ae455d35@github.com> Message-ID: On Fri, 12 Sep 2025 19:01:24 GMT, Valerie Peng wrote: >>> > One more comment, otherwise looks good. >>> > Also, add a release note. >>> >>> Done, please find it at https://bugs.openjdk.org/browse/JDK-8367477 >> >> Thanks, I made a few minor wording edits. > >> > > One more comment, otherwise looks good. >> > > Also, add a release note. >> > >> > >> > Done, please find it at https://bugs.openjdk.org/browse/JDK-8367477 >> >> Thanks, I made a few minor wording edits. > > Great, thanks for the review! Edits look good and I have marked it as Delivered. @valeriepeng fyi, the PR has failing tests in the CI: sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/26377#issuecomment-3287004858 From valeriep at openjdk.org Fri Sep 12 22:44:30 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Sep 2025 22:44:30 GMT Subject: RFR: 8244336: Restrict algorithms at JCE layer [v10] In-Reply-To: References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com> <-UVq3aI4GOjwxn0qObkRsFJ-TLLueU3412iRTaUyE0I=.376c5e62-bcc4-4b56-8252-6da7ae455d35@github.com> Message-ID: On Fri, 12 Sep 2025 19:01:24 GMT, Valerie Peng wrote: >>> > One more comment, otherwise looks good. >>> > Also, add a release note. >>> >>> Done, please find it at https://bugs.openjdk.org/browse/JDK-8367477 >> >> Thanks, I made a few minor wording edits. > >> > > One more comment, otherwise looks good. >> > > Also, add a release note. >> > >> > >> > Done, please find it at https://bugs.openjdk.org/browse/JDK-8367477 >> >> Thanks, I made a few minor wording edits. > > Great, thanks for the review! Edits look good and I have marked it as Delivered. > @valeriepeng fyi, the PR has failing tests in the CI: sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java Strange, I did run a mach5 job and didn't see this failure... Wonder what happened... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26377#issuecomment-3287027680 From weijun at openjdk.org Fri Sep 12 23:25:25 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 Sep 2025 23:25:25 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v43] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 19:10:04 GMT, Anthony Scarpino wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: >> >> - Merge branch 'master' into 8325448 >> - about transformation >> - cannot reset with withMethods >> - algorithm identifier >> - withMethods >> - duplicated "value" words >> - receiver to recipient; different to specified >> - use different exception type >> - more spec change >> - address Sean's comments >> - ... and 48 more: https://git.openjdk.org/jdk/compare/7fcce270...1ec31cf5 > > src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 154: > >> 152: /** >> 153: * KEM algorithm identifier for DHKEM(P-256, HKDF-SHA256) as defined in >> 154: * Section 7.1 of RFC 9180. > > Suggestion: It has been my impression that `@spec` was for things like this. Might it be cleaner to remove the "as defined in " and just list the RFC in an `@spec`? It also seems overkill to refer to the RFC sections for each entry as you mention that the id's are in in Section 7 in the class javadoc. Both `PBEParameterSpec` and `HKDFParameterSpec` have RFC links appears in the javadoc text and as a `@spec`. I know `PEMEncoder` has not. For links into RFC sections, I was trying to be as helpful as possible. There are quite some concept here like modes and algorithm identifiers. Maybe those in the constants are too much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2345594111 From weijun at openjdk.org Fri Sep 12 23:36:20 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 Sep 2025 23:36:20 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v43] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 19:30:21 GMT, Anthony Scarpino wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: >> >> - Merge branch 'master' into 8325448 >> - about transformation >> - cannot reset with withMethods >> - algorithm identifier >> - withMethods >> - duplicated "value" words >> - receiver to recipient; different to specified >> - use different exception type >> - more spec change >> - address Sean's comments >> - ... and 48 more: https://git.openjdk.org/jdk/compare/7fcce270...1ec31cf5 > > src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 286: > >> 284: * @throws IllegalArgumentException if {@code info} is empty. >> 285: */ >> 286: public HPKEParameterSpec withInfo(byte[] info) { > > After reading your example at the class javadoc level, it left me with the impression that `withInfo()` would be used with `String`. Does it make sense to have a `withInfo(String)` method? Or maybe the example less String-specific? Oh, I just want to be self-contained in the example and `new byte[10]` seems too trivial. Actually, it's very likely not a string. For example, in TLS Encrypted Client Hello, it's `"tls ech" || 0x00 || ECHConfig`. I don't think it's worth adding an overloaded `withInfo(String)`. It's similar to the `info` in HKDF-Expand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2345601851 From weijun at openjdk.org Fri Sep 12 23:45:29 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 Sep 2025 23:45:29 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v43] In-Reply-To: References: Message-ID: <0vyXx7KpYnPSBrrt9lcNLlnmzotIYo9ACVMQy3HLX3k=.04011be3-0259-40cf-b8db-dc439a2aaf4b@github.com> On Fri, 12 Sep 2025 20:50:57 GMT, Anthony Scarpino wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: >> >> - Merge branch 'master' into 8325448 >> - about transformation >> - cannot reset with withMethods >> - algorithm identifier >> - withMethods >> - duplicated "value" words >> - receiver to recipient; different to specified >> - use different exception type >> - more spec change >> - address Sean's comments >> - ... and 48 more: https://git.openjdk.org/jdk/compare/7fcce270...1ec31cf5 > > src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 317: > >> 315: throw new IllegalArgumentException("psk_id is empty"); >> 316: } >> 317: if ("RAW".equalsIgnoreCase(psk.getFormat())) { > > What happens if the format is not RAW? Is that allowed or should it be an IAE? > If `psk` is an 16 byte AES Secret key is that checked somewhere or at all relevant? I just meant if it's not "RAW" (maybe `null`?) then I have no way to check its length. A 16 byte AES will be rejected if it has an encoding which is almost always of "RAW" format. Or, did you confuse `getAlgorithm` and `getFormat`? > src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 352: > >> 350: * authentication key value. >> 351: *

>> 352: * Note: this method does not check whether the KEM supports > > "the KEM supports" sounds awkward to me. Do you mean non-DHKEM or the KEM provider implementation? Section 5 of RFC 9180: > Note that some KEMs may not support AuthEncap() or AuthDecap(). For such KEMs, only mode_base or mode_psk are supported. Future specifications which define new KEMs MUST indicate whether these modes are supported. See [Section 7.1.5](https://www.rfc-editor.org/rfc/rfc9180.html#future-kems) for more details. I can change to "the KEM algorithm supports". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2345617709 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2345620663 From duke at openjdk.org Sat Sep 13 05:09:55 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Sat, 13 Sep 2025 05:09:55 GMT Subject: RFR: 8366978: dead code in SunCertPathBuilder Message-ID: A DESCRIPTION OF THE PROBLEM : [JDK-7194452](https://bugs.openjdk.org/browse/JDK-7194452) left the SunCertPathBuilder.anchorIsTarget orphaned. Remove the deadcode. ------------- Commit messages: - 8366978: remove dead code in SunCertPathBuilder Changes: https://git.openjdk.org/jdk/pull/27268/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27268&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366978 Stats: 15 lines in 1 file changed: 0 ins; 14 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27268.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27268/head:pull/27268 PR: https://git.openjdk.org/jdk/pull/27268 From jpai at openjdk.org Sat Sep 13 05:21:20 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 05:21:20 GMT Subject: RFR: 8367583: sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java fails after JDK-8244336 Message-ID: Can I please get a review of this test-only change which addresses the test failure in `sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java`? As noted in https://bugs.openjdk.org/browse/JDK-8367583, this test fails when run in our CI. The test intentionally sets up some Security property which is expected to cause a `ExceptionInInitializerError` when a security API is used. The test also uses the `jdk.test.lib.Utils` test library which in its static block has a piece of code which intializes a `MessageDigest` conditionally depending on whether or not the `build` part of the `Runtime.version()` is greater than `0`. The initialization of `MessageDigest` during the static initialization of the `Utils` class leads to certain security APIs to be used too early and thus causing the `ExceptionInInitializerError` much before the test expected. The test thus ends up failing in that case. For local builds, build number is by default 0, so this failure wasn't observed locally. In order to reproduce this issue, I built a local JDK with: bash configure --with-version-build=42 make clean images I then ran this test against this built JDK and it was able to reproduce this failure. The change in this PR updates the test to no longer use the test library's `Utils` class and thus avoids this issue. The test continues to test the same APIs and expectations that it was previously doing, except that it does it without the use of this test utility class. I have run this test change locally against a JDK with build number 0 and against a JDK build number greater than 0 and it passes against both. I'll launched a CI run just to make sure nothing else fails with this change. ------------- Commit messages: - 8367583: sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java fails after JDK-8244336 Changes: https://git.openjdk.org/jdk/pull/27269/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27269&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367583 Stats: 18 lines in 1 file changed: 8 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27269.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27269/head:pull/27269 PR: https://git.openjdk.org/jdk/pull/27269 From weijun at openjdk.org Sat Sep 13 13:29:24 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 13 Sep 2025 13:29:24 GMT Subject: RFR: 8367583: sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java fails after JDK-8244336 In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 05:13:39 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses the test failure in `sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java`? > > As noted in https://bugs.openjdk.org/browse/JDK-8367583, this test fails when run in our CI. The test intentionally sets up some Security property which is expected to cause a `ExceptionInInitializerError` when a security API is used. The test also uses the `jdk.test.lib.Utils` test library which in its static block has a piece of code which intializes a `MessageDigest` conditionally depending on whether or not the `build` part of the `Runtime.version()` is greater than `0`. The initialization of `MessageDigest` during the static initialization of the `Utils` class leads to certain security APIs to be used too early and thus causing the `ExceptionInInitializerError` much before the test expected. The test thus ends up failing in that case. > > For local builds, build number is by default 0, so this failure wasn't observed locally. In order to reproduce this issue, I built a local JDK with: > > > bash configure --with-version-build=42 > make clean images > > I then ran this test against this built JDK and it was able to reproduce this failure. > > The change in this PR updates the test to no longer use the test library's `Utils` class and thus avoids this issue. The test continues to test the same APIs and expectations that it was previously doing, except that it does it without the use of this test utility class. I have run this test change locally against a JDK with build number 0 and against a JDK build number greater than 0 and it passes against both. > > I'll launched a CI run just to make sure nothing else fails with this change. I've seen this before. https://bugs.openjdk.org/browse/JDK-8345578. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27269#pullrequestreview-3220746033 From jpai at openjdk.org Sat Sep 13 13:40:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 13:40:08 GMT Subject: RFR: 8367583: sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java fails after JDK-8244336 In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 13:26:22 GMT, Weijun Wang wrote: > I've seen this before. https://bugs.openjdk.org/browse/JDK-8345578. Thank you Weijun for the review. The conditional code in `Utils` test library class surprised me and looking at why it was introduced, it appears to be done as part of https://bugs.openjdk.org/browse/JDK-8253750. The motivation to do that I think is reasonable, so I won't pursue any changes to the `Utils` class further. For this current PR, would you suggest I wait for further reviews or would it be OK to go ahead with the integration? Locally I have verified this test now works (and used to previously fail). In our CI I have run tier2 and just this test too and that too passed (but that isn't of much consequence because the build number used in those runs will be 0). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27269#issuecomment-3288369632 From jpai at openjdk.org Sat Sep 13 13:55:19 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 13:55:19 GMT Subject: RFR: 8367583: sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java fails after JDK-8244336 In-Reply-To: References: Message-ID: <6cOlXDTNHqH5stFkgA_jd7cXxRHx-R5Hbr45ELmBZD8=.f27821f1-4bad-4c24-bdb4-090524bcd0f0@github.com> On Sat, 13 Sep 2025 05:13:39 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses the test failure in `sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java`? > > As noted in https://bugs.openjdk.org/browse/JDK-8367583, this test fails when run in our CI. The test intentionally sets up some Security property which is expected to cause a `ExceptionInInitializerError` when a security API is used. The test also uses the `jdk.test.lib.Utils` test library which in its static block has a piece of code which intializes a `MessageDigest` conditionally depending on whether or not the `build` part of the `Runtime.version()` is greater than `0`. The initialization of `MessageDigest` during the static initialization of the `Utils` class leads to certain security APIs to be used too early and thus causing the `ExceptionInInitializerError` much before the test expected. The test thus ends up failing in that case. > > For local builds, build number is by default 0, so this failure wasn't observed locally. In order to reproduce this issue, I built a local JDK with: > > > bash configure --with-version-build=42 > make clean images > > I then ran this test against this built JDK and it was able to reproduce this failure. > > The change in this PR updates the test to no longer use the test library's `Utils` class and thus avoids this issue. The test continues to test the same APIs and expectations that it was previously doing, except that it does it without the use of this test utility class. I have run this test change locally against a JDK with build number 0 and against a JDK build number greater than 0 and it passes against both. > > I'll launched a CI run just to make sure nothing else fails with this change. I spoke to Weijun and we decided to integrate this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27269#issuecomment-3288388358 From jpai at openjdk.org Sat Sep 13 13:55:19 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 13:55:19 GMT Subject: Integrated: 8367583: sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java fails after JDK-8244336 In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 05:13:39 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses the test failure in `sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java`? > > As noted in https://bugs.openjdk.org/browse/JDK-8367583, this test fails when run in our CI. The test intentionally sets up some Security property which is expected to cause a `ExceptionInInitializerError` when a security API is used. The test also uses the `jdk.test.lib.Utils` test library which in its static block has a piece of code which intializes a `MessageDigest` conditionally depending on whether or not the `build` part of the `Runtime.version()` is greater than `0`. The initialization of `MessageDigest` during the static initialization of the `Utils` class leads to certain security APIs to be used too early and thus causing the `ExceptionInInitializerError` much before the test expected. The test thus ends up failing in that case. > > For local builds, build number is by default 0, so this failure wasn't observed locally. In order to reproduce this issue, I built a local JDK with: > > > bash configure --with-version-build=42 > make clean images > > I then ran this test against this built JDK and it was able to reproduce this failure. > > The change in this PR updates the test to no longer use the test library's `Utils` class and thus avoids this issue. The test continues to test the same APIs and expectations that it was previously doing, except that it does it without the use of this test utility class. I have run this test change locally against a JDK with build number 0 and against a JDK build number greater than 0 and it passes against both. > > I'll launched a CI run just to make sure nothing else fails with this change. This pull request has now been integrated. Changeset: ff538c7f Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/ff538c7f5641bb24748243da44de5d964141ae31 Stats: 18 lines in 1 file changed: 8 ins; 4 del; 6 mod 8367583: sun/security/util/AlgorithmConstraints/InvalidCryptoDisabledAlgos.java fails after JDK-8244336 Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/27269 From duke at openjdk.org Sun Sep 14 21:10:13 2025 From: duke at openjdk.org (Johannes Graham) Date: Sun, 14 Sep 2025 21:10:13 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> Message-ID: On Mon, 8 Sep 2025 02:27:10 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'upstream/master' into appendPair_202508 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding > - Use DecimalDigits.appendPair for formatting in time classes > > This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. > > Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. > > Co-authored-by: Qwen-Coder > - Optimize year formatting in DateTimeHelper by reducing modulo operation > > Co-authored-by: Qwen-Coder > > Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. > - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. > > Co-authored-by: Qwen-Coder > - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. > > Co-authored-by: Qwen-Coder What is the performance like with a simpler implementation of DecimalDigits.appendPair? One that uses the DIGITS table and then simply appends each character. This would avoid the JavaLangAccess concern, but might still provide some of the benefit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3289899032 From swen at openjdk.org Mon Sep 15 02:27:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 15 Sep 2025 02:27:18 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: On Sat, 23 Aug 2025 10:23:15 GMT, Shaojin Wen wrote: > localDateTimeToString @j3graham public static void appendPair(StringBuilder buf, int v) { int packed = DIGITS[v & 0x7f]; buf.append((char) (packed & 0xFF)) .append((char) (packed >> 8)); } I have tested this implementation and the performance is not good ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3290256444 From swen at openjdk.org Mon Sep 15 02:27:23 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 15 Sep 2025 02:27:23 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: On Wed, 27 Aug 2025 11:45:09 GMT, Mikhail Yankelevich wrote: >> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge remote-tracking branch 'upstream/master' into appendPair_202508 >> >> # Conflicts: >> # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java >> - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding >> - Use DecimalDigits.appendPair for formatting in time classes >> >> This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. >> >> Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. >> >> Co-authored-by: Qwen-Coder >> - Optimize year formatting in DateTimeHelper by reducing modulo operation >> >> Co-authored-by: Qwen-Coder >> >> Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. >> - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. >> >> Co-authored-by: Qwen-Coder >> - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. >> >> Co-authored-by: Qwen-Coder > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 455: > >> 453: * If the value is between 0 and 9, it is formatted with a leading zero >> 454: * (e.g., 5 becomes "05"). If the value is outside the range 0-99, >> 455: * the behavior is unspecified. > > Just out of interest, why leave the behaviour as unspecified instead of validating and throwing an exception? Just simply trust the caller ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2347758316 From liach at openjdk.org Mon Sep 15 03:10:11 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 03:10:11 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> Message-ID: On Mon, 8 Sep 2025 02:27:10 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'upstream/master' into appendPair_202508 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding > - Use DecimalDigits.appendPair for formatting in time classes > > This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. > > Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. > > Co-authored-by: Qwen-Coder > - Optimize year formatting in DateTimeHelper by reducing modulo operation > > Co-authored-by: Qwen-Coder > > Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. > - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. > > Co-authored-by: Qwen-Coder > - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. > > Co-authored-by: Qwen-Coder If we have string templates in the future, do you think we can replace this with custom string template processors instead to accomplish the same performance (no redundant width checks)? test/jdk/jdk/internal/util/DecimalDigitsTest.java line 33: > 31: /* > 32: * @test > 33: * @bug 0000000 Suggestion: * @bug 8366224 ------------- PR Review: https://git.openjdk.org/jdk/pull/26911#pullrequestreview-3222746717 PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2347762729 From liach at openjdk.org Mon Sep 15 03:18:18 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 03:18:18 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> Message-ID: On Mon, 8 Sep 2025 02:27:10 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'upstream/master' into appendPair_202508 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding > - Use DecimalDigits.appendPair for formatting in time classes > > This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. > > Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. > > Co-authored-by: Qwen-Coder > - Optimize year formatting in DateTimeHelper by reducing modulo operation > > Co-authored-by: Qwen-Coder > > Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. > - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. > > Co-authored-by: Qwen-Coder > - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. > > Co-authored-by: Qwen-Coder This solution, if it is to be accepted, can only be a stopgap measure - I think the most likely feature to replace this hack would be String Templates. What abilities do you think that String Templates should support so that you can cover this use case (when we migrate the DateTimeFormatter to be String template instead of StringBuilder based)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3290328094 From swen at openjdk.org Mon Sep 15 06:11:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 15 Sep 2025 06:11:18 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: > This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. > > Changes include: > > 1. New `appendPair` method for efficient two-digit integer formatting (00-99): > - Added `AbstractStringBuilder.appendPair(int i)` with core implementation > - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access > - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge > - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method > - Enhanced Javadoc documentation for all new methods > > 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: > - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` > - Replaced manual formatting logic with the new efficient two-digit appending > - Improved code clarity and consistency in date/time formatting > > These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/jdk/internal/util/DecimalDigitsTest.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26911/files - new: https://git.openjdk.org/jdk/pull/26911/files/a7ffb777..d489f144 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26911.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911 PR: https://git.openjdk.org/jdk/pull/26911 From pminborg at openjdk.org Mon Sep 15 06:49:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 15 Sep 2025 06:49:15 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> On Mon, 15 Sep 2025 06:11:18 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/jdk/internal/util/DecimalDigitsTest.java > > Co-authored-by: Chen Liang We have, for long, established that changes like this should be discussed before putting forward any code. Yet, I am unable to find any discussion in the appropriate mailing list. Please send me the link to the mailing list discussion. I must have missed it for some reason. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3290708624 From swen at openjdk.org Mon Sep 15 08:28:28 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 15 Sep 2025 08:28:28 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> Message-ID: On Mon, 15 Sep 2025 06:45:25 GMT, Per Minborg wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test/jdk/jdk/internal/util/DecimalDigitsTest.java >> >> Co-authored-by: Chen Liang > > We have, for long, established that changes like this should be discussed before putting forward any code. Yet, I am unable to find any discussion in the appropriate mailing list. Please send me the link to the mailing list discussion. I must have missed it for some reason. @minborg The process went like this: On August 23rd, I posted an email to the core-libs-dev mailing list titled "Introduce and utilize DecimalDigits.appendPair for efficient two-digit formatting." The message included a link to the pull request (PR) https://github.com/openjdk/jdk/pull/26911. At the time, the PR was in draft status. On August 26th, @jodastephen commented on the PR. He's an expert in java.time, and based on his comments, I created an issue and changed the PR status to RFR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3291005980 From pminborg at openjdk.org Mon Sep 15 09:05:24 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 15 Sep 2025 09:05:24 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> Message-ID: On Mon, 15 Sep 2025 06:45:25 GMT, Per Minborg wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test/jdk/jdk/internal/util/DecimalDigitsTest.java >> >> Co-authored-by: Chen Liang > > We have, for long, established that changes like this should be discussed before putting forward any code. Yet, I am unable to find any discussion in the appropriate mailing list. Please send me the link to the mailing list discussion. I must have missed it for some reason. > @minborg > > The process went like this: > > On August 23rd, I posted an email to the core-libs-dev mailing list titled "Introduce and utilize DecimalDigits.appendPair for efficient two-digit formatting." The message included a link to the pull request (PR) #26911. At the time, the PR was in draft status. > > On August 26th, @jodastephen commented on the PR. > > He's an expert in java.time, and based on his comments, I created an issue and changed the PR status to RFR. This mail appears to merely point out that there is a PR with code. I am unable to locate any discussion *prior* to any code being presented. E.g., whether we should do this or not. What are the pros and cons, etc. What did I miss? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3291135881 From duke at openjdk.org Mon Sep 15 10:02:38 2025 From: duke at openjdk.org (Thomas Fitzsimmons) Date: Mon, 15 Sep 2025 10:02:38 GMT Subject: Integrated: 8361711: Add library name configurability to PKCS11Test.java In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 16:43:16 GMT, Thomas Fitzsimmons wrote: > This patch adds configurability to `PKCS11Test.java`. > > Specifically, it adds two new system properties: > > - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the `nss_library` field. Prior to this patch, `nss_library` was set to either `"softokn3"` or `"nss3"`. > > - `CUSTOM_P11_CONFIG_VARIANT`: Abstract the configuration file type to load. Prior to this patch, test cases that wanted to run `NSS` in sensitive mode would hard-code `p11-nss-sensitive.txt` on their command lines. > > The patch updates the three `p11-nss-sensitive.txt`-using test cases to use the new `CUSTOM_P11_CONFIG_VARIANT` property: > > > test/jdk/java/security/KeyAgreement/Generic.java > test/jdk/sun/security/pkcs11/Mac/TestLargeSecretKeys.java > test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java > > > I have been using this change to run `PKCS11Test.java` against the [Kryoptic](https://github.com/latchset/kryoptic) PKCS11 soft token, using this invocation: > > > make test \ > JTREG="JAVA_OPTIONS=-DCUSTOM_P11_CONFIG=/tmp/kryoptic-configuration/p11-kryoptic.txt \ > -DCUSTOM_P11_LIBRARY_NAME=kryoptic_pkcs11 \ > -Djdk.test.lib.artifacts.nsslib-linux_x64=/tmp/kryoptic-configuration \ > -DCUSTOM_DB_DIR=/tmp/kryoptic-configuration" > > > `/tmp/kryoptic-configuration` contains (among other files): > > > libkryoptic_pkcs11.so > p11-kryoptic.txt > p11-kryoptic-sensitive.txt > > > With `CUSTOM_P11_LIBRARY_NAME` set, `PKCS11Test.java` can find `libkryoptic_pkcs11.so`. > > And setting `CUSTOM_P11_CONFIG` causes the sensitive tests to use `p11-kryoptic-sensitive.txt` via the new `CUSTOM_P11_CONFIG_VARIANT` property. > > On my `Fedora 42` `x86-64` machine, I tested for regressions with: > > $ time make test JOBS=4 JTREG="JAVA_OPTIONS=-Djdk.test.lib.artifacts.nsslib-linux_x64=/usr/lib64" TEST="test/jdk/sun/security/pkcs11" > > and: > > $ time make test JOBS=4 TEST="test/jdk/sun/security/pkcs11" This pull request has now been integrated. Changeset: 1cb1267c Author: Thomas Fitzsimmons Committer: Francisco Ferrari Bihurriet URL: https://git.openjdk.org/jdk/commit/1cb1267ce84dea2bfcb434b03c982b859997c6d2 Stats: 46 lines in 1 file changed: 45 ins; 0 del; 1 mod 8361711: Add library name configurability to PKCS11Test.java Reviewed-by: valeriep ------------- PR: https://git.openjdk.org/jdk/pull/26325 From djelinski at openjdk.org Mon Sep 15 11:02:37 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 15 Sep 2025 11:02:37 GMT Subject: RFR: 8367133: DTLS: fragmentation of Finished message results in handshake failure Message-ID: The DTLSReassembler may release a Finished message before assembling all necessary fragments. The newly added test fails without the DTLSReassembler changes, passes with the changes. Other tier1-3 tests continue to pass. ------------- Commit messages: - Clean up comment - Extract test to a separate file - Wait for all Finished message fragments to arrive - Add a test that fragments the Finished message Changes: https://git.openjdk.org/jdk/pull/27284/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27284&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367133 Stats: 78 lines in 2 files changed: 75 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27284/head:pull/27284 PR: https://git.openjdk.org/jdk/pull/27284 From weijun at openjdk.org Mon Sep 15 13:55:48 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Sep 2025 13:55:48 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: On Mon, 15 Sep 2025 06:11:18 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/jdk/internal/util/DecimalDigitsTest.java > > Co-authored-by: Chen Liang I'd rather see a real public API even if it looks like `StringBuilder::appendInteger(boolean alwaysSign, boolean packWithZero, int minWidth, int number)`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3292294887 From mullan at openjdk.org Mon Sep 15 14:11:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 15 Sep 2025 14:11:53 GMT Subject: RFR: 8366978: dead code in SunCertPathBuilder In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 05:02:46 GMT, Koushik Muthukrishnan Thirupattur wrote: > A DESCRIPTION OF THE PROBLEM : > [JDK-7194452](https://bugs.openjdk.org/browse/JDK-7194452) left the SunCertPathBuilder.anchorIsTarget orphaned. Remove the deadcode. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27268#pullrequestreview-3224833041 From hchao at openjdk.org Mon Sep 15 15:50:47 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Mon, 15 Sep 2025 15:50:47 GMT Subject: RFR: 8366978: dead code in SunCertPathBuilder In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 05:02:46 GMT, Koushik Muthukrishnan Thirupattur wrote: > A DESCRIPTION OF THE PROBLEM : > [JDK-7194452](https://bugs.openjdk.org/browse/JDK-7194452) left the SunCertPathBuilder.anchorIsTarget orphaned. Remove the deadcode. Marked as reviewed by hchao (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27268#pullrequestreview-3225298061 From weijun at openjdk.org Mon Sep 15 16:02:35 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Sep 2025 16:02:35 GMT Subject: RFR: 8367344: Better error message when decryption of AP-REQ fails because of kvno mismatch Message-ID: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> For interoperability, AP-REQ decryption uses the key with the highest kvno in the keytab if no exact match is found. If decryption fails, a normal "checksum failed" error is reported, which may hide the real cause that the wrong key is used. This code change throws a KRB_AP_ERR_BADKEYVER error in this case. The change is only made in AP-REQ decryption to minimize impact. A previous test is enhanced to cover the case. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/27298/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27298&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367344 Stats: 60 lines in 3 files changed: 44 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/27298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27298/head:pull/27298 PR: https://git.openjdk.org/jdk/pull/27298 From duke at openjdk.org Mon Sep 15 18:34:02 2025 From: duke at openjdk.org (duke) Date: Mon, 15 Sep 2025 18:34:02 GMT Subject: RFR: 8366978: dead code in SunCertPathBuilder In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 05:02:46 GMT, Koushik Muthukrishnan Thirupattur wrote: > A DESCRIPTION OF THE PROBLEM : > [JDK-7194452](https://bugs.openjdk.org/browse/JDK-7194452) left the SunCertPathBuilder.anchorIsTarget orphaned. Remove the deadcode. @koushikthirupattur Your change (at version ce1daf8fdba7605be7c990f5c5c87323124c24d1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27268#issuecomment-3293428758 From ascarpino at openjdk.org Mon Sep 15 18:51:56 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 15 Sep 2025 18:51:56 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 18:33:53 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 255: >> >>> 253: if (seq.data.available() != 0) { >>> 254: DerValue derValue = seq.data.getDerValue(); >>> 255: if (derValue.isContextSpecific((byte) 1)) { >> >> If any of these `if`s is false `null` is returned. Would you rather throw an IAE? > > I see there could be a > > parameters [0] ECDomainParameters {{ SECGCurveNames }} OPTIONAL, > > Shall we skip it? This only checks if one is available in the private key material. If there is none, null is fine. The domain parameters are kept as part of private key SEC1v2 encoding and can be read when generating a private key with a KeyFactory. Translating the encoding could be error-prone, and maybe incompatible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2349784363 From ascarpino at openjdk.org Mon Sep 15 18:52:00 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 15 Sep 2025 18:52:00 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 17:54:49 GMT, Weijun Wang wrote: >> Hi >> >> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: >> >> - Renamed the name of `PEMRecord` class to `PEM`. >> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. >> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. >> >> thanks >> >> Tony > > src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 159: > >> 157: privKeyMaterial = val.data.getOctetString(); >> 158: >> 159: // Special check and parsing for ECDSA's SEC1v2 format > > So there are 2 ways to extract public key from PKCS8. Are you going to check whether they match? > > Also, can we add a test case for this format? In this method, there is only one path for SEC1v2 requires the version to be 1, PKCS8 requires the version to be 2. The two should not intersect in this method. It is true that a version 2 OneAsymmetricKey could contain a SEC1v2 private key encoding. At that point a KeyFactory needs to generate both keys to verify. I think that goes beyond what is necessary for what amounts to a "user error" in putting the wrong public and private key pair together. I would like to explore redoing PKCS8Key.java as it has taken on many more tasks with encoding & decoding different algorithms. But I don't want that to be tied to a JEP, rather a bug or RFE. > src/java.base/share/classes/sun/security/util/Pem.java line 355: > >> 353: return pemEncoded(pem.type(), p); >> 354: } >> 355: > > Is it correct to put the 2 new methods here? Seems not closely related to PEM. They are needed by PEM and EKPI, so this seems like the right place. > src/java.base/share/classes/sun/security/util/Pem.java line 387: > >> 385: * return a PrivateKey >> 386: * @param provider KeyFactory provider >> 387: */ > > This method is very similar to `PKCS8Key::parseKey`. Maybe we should combine them. Before the code review, I intentionally split these apart. I didn't like how the code looked and that returning a `DEREncodable` complicated `parseKey()`. It made PKCS8Key much more complicated with typecasting and passing in `pair`. If I redo `PKCS8Key.java`, this would be on the list to find a more elegant way to merge them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2349810230 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2349813496 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2349830806 From weijun at openjdk.org Mon Sep 15 19:04:26 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Sep 2025 19:04:26 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v5] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: quote keystore paths as well ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/5fa7b2f7..d57f56c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From hchao at openjdk.org Mon Sep 15 20:15:08 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Mon, 15 Sep 2025 20:15:08 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v5] In-Reply-To: References: Message-ID: <-4HE50NxrbGaKo6WT6mUTB4ts3_FtiIdiv8HU2XQiuw=.2bed667c-3149-42a6-a6bf-7b4ff8e80a9a@github.com> On Mon, 15 Sep 2025 19:04:26 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > quote keystore paths as well Marked as reviewed by hchao (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3226116534 From ascarpino at openjdk.org Mon Sep 15 22:46:17 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 15 Sep 2025 22:46:17 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v43] In-Reply-To: <0vyXx7KpYnPSBrrt9lcNLlnmzotIYo9ACVMQy3HLX3k=.04011be3-0259-40cf-b8db-dc439a2aaf4b@github.com> References: <0vyXx7KpYnPSBrrt9lcNLlnmzotIYo9ACVMQy3HLX3k=.04011be3-0259-40cf-b8db-dc439a2aaf4b@github.com> Message-ID: On Fri, 12 Sep 2025 23:39:37 GMT, Weijun Wang wrote: >> src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 317: >> >>> 315: throw new IllegalArgumentException("psk_id is empty"); >>> 316: } >>> 317: if ("RAW".equalsIgnoreCase(psk.getFormat())) { >> >> What happens if the format is not RAW? Is that allowed or should it be an IAE? >> If `psk` is an 16 byte AES Secret key is that checked somewhere or at all relevant? > > I just meant if it's not "RAW" (maybe `null`?) then I have no way to check its length. A 16 byte AES will be rejected if it has an encoding which is almost always of "RAW" format. > > Or, did you confuse `getAlgorithm` and `getFormat`? I know it's `getFormat`. Since there is a length check for "RAW", I was wondering why "PKCS#8", didn't use `psk.getEncoded().length` to checked. If you are handling the "RAW" case in this method and later on a short key is checked, that is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2350270555 From weijun at openjdk.org Mon Sep 15 23:20:35 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Sep 2025 23:20:35 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v43] In-Reply-To: References: <0vyXx7KpYnPSBrrt9lcNLlnmzotIYo9ACVMQy3HLX3k=.04011be3-0259-40cf-b8db-dc439a2aaf4b@github.com> Message-ID: On Mon, 15 Sep 2025 22:42:31 GMT, Anthony Scarpino wrote: >> I just meant if it's not "RAW" (maybe `null`?) then I have no way to check its length. A 16 byte AES will be rejected if it has an encoding which is almost always of "RAW" format. >> >> Or, did you confuse `getAlgorithm` and `getFormat`? > > I know it's `getFormat`. Since there is a length check for "RAW", I was wondering why "PKCS#8", didn't use `psk.getEncoded().length` to checked. If you are handling the "RAW" case in this method and later on a short key is checked, that is fine. I'm expecting a `SecretKey` here. If it's "PKCS#8", I probably will have to error out somewhere. But then inside `HPKE` the implementation, it should work with both software and hardware keys so I should not look at `getFormat` anymore. Anyway, I'm just trying to do as much as I can. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2350306860 From duke at openjdk.org Tue Sep 16 06:31:50 2025 From: duke at openjdk.org (Shawn M Emery) Date: Tue, 16 Sep 2025 06:31:50 GMT Subject: RFR: 8364657: Crash for SecureRandom.generateSeed(0) on Windows x86-64 Message-ID: The JVM will crash when given a zero byte seed length for SecureRandom.generateSeed() while using the Window's PRNG. The solution is to first check to see if the seed is null or not and if null then generate a zero length byte array. This may be odd but this mimics the same behavior in other operating systems such as MacOS and Linux. The new unit test case* provided with this PR replicates the issue before the fix and is confirmed not to replicate the issue after the proposed fix. * The TestStrong.java unit test code is a contribution from @jaikiran, thank you! ------------- Commit messages: - Add copyright to new unit test - Add copyright to new unit test - 8364657: Crash for SecureRandom.generateSeed(0) on Windows x86-64 Changes: https://git.openjdk.org/jdk/pull/27302/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27302&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364657 Stats: 50 lines in 2 files changed: 48 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27302.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27302/head:pull/27302 PR: https://git.openjdk.org/jdk/pull/27302 From duke at openjdk.org Tue Sep 16 06:40:46 2025 From: duke at openjdk.org (duke) Date: Tue, 16 Sep 2025 06:40:46 GMT Subject: Withdrawn: 8360562: sun/security/tools/keytool/i18n.java add an ability to add comment for failures In-Reply-To: References: Message-ID: <7BNnFnZOOfV0ldEsak9p9PLqC1e_IEaD8axeZ06sLpE=.b9d8e968-b12a-46cd-abdc-5c25e0fee494@github.com> On Mon, 21 Jul 2025 10:49:18 GMT, Mikhail Yankelevich wrote: > When the test is run now the reason for the failure will be requested providing further feedback. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26412 From duke at openjdk.org Tue Sep 16 06:49:37 2025 From: duke at openjdk.org (duke) Date: Tue, 16 Sep 2025 06:49:37 GMT Subject: Withdrawn: 8361894: sun/security/krb5/config/native/TestDynamicStore.java ensure that the test is run with sudo In-Reply-To: <78whX4UN6lwESBM5rEK0qXZqt3_zGalKTEkcgWceVn8=.bbae0b43-5a94-491b-93ec-3310236e6b45@github.com> References: <78whX4UN6lwESBM5rEK0qXZqt3_zGalKTEkcgWceVn8=.bbae0b43-5a94-491b-93ec-3310236e6b45@github.com> Message-ID: On Mon, 14 Jul 2025 12:53:55 GMT, Mikhail Yankelevich wrote: > sun/security/krb5/config/native/TestDynamicStore.java is commonly run without sudo, which leads to the access related failure. > Added a ui popup reminding to run the test with sudo, making instructions clearer and more noticeable This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26293 From duke at openjdk.org Tue Sep 16 06:54:47 2025 From: duke at openjdk.org (duke) Date: Tue, 16 Sep 2025 06:54:47 GMT Subject: Withdrawn: 8360979: Remove use of Thread.stop in krb5/auto/KDC.java In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 16:03:54 GMT, Mikhail Yankelevich wrote: > Replaced Thread::stop to Thread::interrupt This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26247 From coffeys at openjdk.org Tue Sep 16 12:49:07 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 16 Sep 2025 12:49:07 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v21] In-Reply-To: References: Message-ID: > The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago. > > Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. > > The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options : > > > System.err.println("help print the help messages"); > System.err.println("expand expand debugging information"); > System.err.println(); > System.err.println("all turn on all debugging"); > System.err.println("ssl turn on ssl debugging"); > System.err.println(); > System.err.println("The following can be used with ssl:"); > System.err.println("\trecord enable per-record tracing"); > System.err.println("\thandshake print each handshake message"); > System.err.println("\tkeygen print key generation data"); > System.err.println("\tsession print session activity"); > System.err.println("\tdefaultctx print default SSL initialization"); > System.err.println("\tsslctx print SSLContext tracing"); > System.err.println("\tsessioncache print session cache tracing"); > System.err.println("\tkeymanager print key manager tracing"); > System.err.println("\ttrustmanager print trust manager tracing"); > System.err.println("\tpluggability print pluggability tracing"); > System.err.println(); > System.err.println("\thandshake debugging can be widened with:"); > System.err.println("\tdata hex dump of each handshake message"); > System.err.println("\tverbose verbose handshake message printing"); > System.err.println(); > System.err.println("\trecord debugging can be widened with:"); > System.err.println("\tplaintext hex dump of record plaintext"); > System.err.println("\tpacket print raw SSL/TLS packets"); > > > as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. > > the output has changed slightly with respect to that - less verbose > > e.g. old style: > > > javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut... Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: - Incorporate review comments from Brad - Merge branch 'master' into 8044609-ssl - Further review comments, copyright years also - Initial review comments from Brad - Merge branch 'master' into 8044609-ssl - 1 file omitted during merge - Merge branch 'master' into 8044609-ssl - Merge branch 'master' into 8044609-ssl - Merge branch 'master' into 8044609-ssl - remove whitespace - ... and 29 more: https://git.openjdk.org/jdk/compare/eb26865c...f94c4e74 ------------- Changes: https://git.openjdk.org/jdk/pull/18764/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=20 Stats: 1308 lines in 80 files changed: 469 ins; 96 del; 743 mod Patch: https://git.openjdk.org/jdk/pull/18764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764 PR: https://git.openjdk.org/jdk/pull/18764 From coffeys at openjdk.org Tue Sep 16 12:49:07 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 16 Sep 2025 12:49:07 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v21] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 12:46:42 GMT, Sean Coffey wrote: >> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago. >> >> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. >> >> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options : >> >> >> System.err.println("help print the help messages"); >> System.err.println("expand expand debugging information"); >> System.err.println(); >> System.err.println("all turn on all debugging"); >> System.err.println("ssl turn on ssl debugging"); >> System.err.println(); >> System.err.println("The following can be used with ssl:"); >> System.err.println("\trecord enable per-record tracing"); >> System.err.println("\thandshake print each handshake message"); >> System.err.println("\tkeygen print key generation data"); >> System.err.println("\tsession print session activity"); >> System.err.println("\tdefaultctx print default SSL initialization"); >> System.err.println("\tsslctx print SSLContext tracing"); >> System.err.println("\tsessioncache print session cache tracing"); >> System.err.println("\tkeymanager print key manager tracing"); >> System.err.println("\ttrustmanager print trust manager tracing"); >> System.err.println("\tpluggability print pluggability tracing"); >> System.err.println(); >> System.err.println("\thandshake debugging can be widened with:"); >> System.err.println("\tdata hex dump of each handshake message"); >> System.err.println("\tverbose verbose handshake message printing"); >> System.err.println(); >> System.err.println("\trecord debugging can be widened with:"); >> System.err.println("\tplaintext hex dump of record plaintext"); >> System.err.println("\tpacket print raw SSL/TLS packets"); >> >> >> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. >> >> the output has changed slightly with respect to that - less verbose >> >> e.g. old... > > Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: > > - Incorporate review comments from Brad > - Merge branch 'master' into 8044609-ssl > - Further review comments, copyright years also > - Initial review comments from Brad > - Merge branch 'master' into 8044609-ssl > - 1 file omitted during merge > - Merge branch 'master' into 8044609-ssl > - Merge branch 'master' into 8044609-ssl > - Merge branch 'master' into 8044609-ssl > - remove whitespace > - ... and 29 more: https://git.openjdk.org/jdk/compare/eb26865c...f94c4e74 Thanks for comments Brad. All should be addressed. ------------- PR Review: https://git.openjdk.org/jdk/pull/18764#pullrequestreview-3229297619 From coffeys at openjdk.org Tue Sep 16 12:49:11 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 16 Sep 2025 12:49:11 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v10] In-Reply-To: <0OvnbkhGQmD38qsz0gJ4hq4i589pau0IOzjHiSp87iU=.66c71eda-1972-4bfc-bdb6-0d7a46b5163c@github.com> References: <0OvnbkhGQmD38qsz0gJ4hq4i589pau0IOzjHiSp87iU=.66c71eda-1972-4bfc-bdb6-0d7a46b5163c@github.com> Message-ID: On Fri, 22 Nov 2024 19:07:34 GMT, Bradford Wetmore wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> enum Options and logic > > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 101: > >> 99: } >> 100: } >> 101: isOn = (property.isEmpty() || property.equals("all")) > > What would you think about including `EMPTYALL` as an enum option, rather than a separate String property using separate processing checks? This would simplify the logic, and you no longer need to store `property` in the class as it's no longer needed. e.g.: > > isOn = activeComponents.contains(ComponentToken.EMPTYALL) > || activeComponents.contains(ComponentToken.SSL)); > > This would help in the `isOn()` section, where you just check for `EMPTYALL` the current isOn logic is pretty tight now also: public static boolean isOn(Opt option) { return Opt.ALL.on || option.on; } > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 154: > >> 152: } >> 153: >> 154: if (property.isEmpty() || property.equals("all")) { > > Then here this becomes: > > if (activeComponents.contains(EMPTYALL)) { > return true; > } design changed since this comment - what we have now is probably as easy to read: public static boolean isOn(Opt option) { return Opt.ALL.on || option.on; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2352026377 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2352023953 From coffeys at openjdk.org Tue Sep 16 12:49:15 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 16 Sep 2025 12:49:15 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v18] In-Reply-To: <5RqSiSYSiWKjuMAePFU-sQz_urkAc9iKT8v8FeIsybM=.0dfc9c96-b6cf-4734-9b78-b2a76adc81c5@github.com> References: <5RqSiSYSiWKjuMAePFU-sQz_urkAc9iKT8v8FeIsybM=.0dfc9c96-b6cf-4734-9b78-b2a76adc81c5@github.com> Message-ID: <4fZse5WktVBHjHd6kXil-QcScCldWdDCyV1gYpXwmdI=.520a1387-56de-4fa0-8c29-ff6466fcd375@github.com> On Sat, 30 Aug 2025 02:34:40 GMT, Bradford Wetmore wrote: >> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: >> >> - Merge branch 'master' into 8044609-ssl >> - 1 file omitted during merge >> - Merge branch 'master' into 8044609-ssl >> - Merge branch 'master' into 8044609-ssl >> - Merge branch 'master' into 8044609-ssl >> - remove whitespace >> - erroneous edit to test file >> - remove legacy test and minor fix ups >> - Merge branch 'master' into 8044609-ssl >> - enums refactoring and line width correction >> - ... and 25 more: https://git.openjdk.org/jdk/compare/2b44ed70...71aa0211 > > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 114: > >> 112: // enable all subcomponents. "ssl" logs all activity >> 113: // except for the "data" and "packet" categories >> 114: if (Opt.SSL.on && !Opt.isAnySubComponentEnabled()) { > > `isAnySubComponentEnabled()` and `enableAllSubComponents()` both call `subCompoenentList()`, so if isAnySC is false, then the list of subcomponents will be generated twice back-to-back. Since these methods are not used anywhere else, maybe do a single call instead: > > if (Opt.SSL.on) { > ifSSLOnlyEnableAllSubcompoenents() // needs a better name! > } redesigned: if (Opt.SSL.on && EnumSet.allOf(Opt.class) .stream() .noneMatch(o -> o.on && o.isSubComponent)) { for (Opt opt : Opt.values()) { if (opt.isSubComponent) { opt.on = true; } } } > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 242: > >> 240: >> 241: Opt() { >> 242: this.component = this.toString().toLowerCase(Locale.ROOT); > > Why `Locale.ROOT` instead of `Locale.English` throughout the rest of the class? Thanks - converted to Locale.English ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2352039677 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2352033146 From coffeys at openjdk.org Tue Sep 16 12:49:17 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 16 Sep 2025 12:49:17 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v20] In-Reply-To: References: Message-ID: <2N9O7vuXjNpJ7J6BgaJzM8tBZRcrszRgNsUhXf-d6f0=.2161e22f-8031-4815-8bea-ad9436da7fea@github.com> On Fri, 12 Sep 2025 01:08:21 GMT, Bradford Wetmore wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Further review comments, copyright years also > > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 217: > >> 215: "print each handshake message"); >> 216: System.err.printf(" %-12s %s%n", "verbose", >> 217: "-verbose handshake message printing (widens handshake)"); > > Minor nit. Having "-" at the beginning of the textual description on these "wideners" looks odd to my eye. "-" are usually for in front of the command args. e.g. > > The following filters can be used with ssl: > .... > handshake print each handshake message > verbose -verbose handshake message printing (widens handshake) > record enable per-record tracing > packet -print raw SSL/TLS packets (widens record) > plaintext -hex dump of record plaintext (widens record) Thanks Brad. I remove the "-" > src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 236: > >> 234: System.err.printf(" %-14s %s%n", "trustmanager", >> 235: "print trust manager tracing"); >> 236: System.err.println(); > > Do we want to include something like this at the bottom?: > >> Adding filters to "ssl" will filter log messages to include just those categories. If "ssl" is specified by itself, all non-widening filters are enabled. how about this ? help print this help message and exit expand expanded (less compact) output format all turn on all debugging ssl turn on ssl debugging The following filters can be used with ssl: defaultctx print default SSL initialization handshake print each handshake message verbose verbose handshake message printing (widens handshake) keymanager print key manager tracing record enable per-record tracing packet print raw SSL/TLS packets (widens record) plaintext hex dump of record plaintext (widens record) respmgr print OCSP response tracing session print session activity sessioncache print session cache tracing sslctx print SSLContext tracing trustmanager print trust manager tracing Adding valid filter options to "ssl" will log messages to include just those filtered categories. If "ssl" is specified by itself, all non-widening filters are enabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2352175500 PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r2352171473 From weijun at openjdk.org Tue Sep 16 13:56:47 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Sep 2025 13:56:47 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v43] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 23:32:43 GMT, Weijun Wang wrote: >> src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 286: >> >>> 284: * @throws IllegalArgumentException if {@code info} is empty. >>> 285: */ >>> 286: public HPKEParameterSpec withInfo(byte[] info) { >> >> After reading your example at the class javadoc level, it left me with the impression that `withInfo()` would be used with `String`. Does it make sense to have a `withInfo(String)` method? Or maybe the example less String-specific? > > Oh, I just want to be self-contained in the example and `new byte[10]` seems too trivial. Actually, it's very likely not a string. For example, in TLS Encrypted Client Hello, it's `"tls ech" || 0x00 || ECHConfig`. I don't think it's worth adding an overloaded `withInfo(String)`. It's similar to the `info` in HKDF-Expand. I'll change the line to `.withInfo(HexFormat.of().parseHex("010203040506"))`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2352602774 From duke at openjdk.org Tue Sep 16 14:15:20 2025 From: duke at openjdk.org (Nibedita Jena) Date: Tue, 16 Sep 2025 14:15:20 GMT Subject: RFR: 8367133: DTLS: fragmentation of Finished message results in handshake failure In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 06:49:06 GMT, Daniel Jeli?ski wrote: > The DTLSReassembler may release a Finished message before assembling all necessary fragments. > > The newly added test fails without the DTLSReassembler changes, passes with the changes. Other tier1-3 tests continue to pass. I applied the changes and verified them against both failure and success scenarios. The results look good. Thanks @djelinski ------------- PR Comment: https://git.openjdk.org/jdk/pull/27284#issuecomment-3298964984 From weijun at openjdk.org Tue Sep 16 14:58:05 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Sep 2025 14:58:05 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v44] In-Reply-To: References: Message-ID: > Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. > image Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more key checks; some small spec change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18411/files - new: https://git.openjdk.org/jdk/pull/18411/files/1ec31cf5..b86797a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=43 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=42-43 Stats: 72 lines in 4 files changed: 30 ins; 13 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/18411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 PR: https://git.openjdk.org/jdk/pull/18411 From myankelevich at openjdk.org Tue Sep 16 16:14:54 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 16 Sep 2025 16:14:54 GMT Subject: RFR: 8367344: Better error message when decryption of AP-REQ fails because of kvno mismatch In-Reply-To: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> References: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> Message-ID: On Mon, 15 Sep 2025 15:49:11 GMT, Weijun Wang wrote: > For interoperability, AP-REQ decryption uses the key with the highest kvno in the keytab if no exact match is found. If decryption fails, a normal "checksum failed" error is reported, which may hide the real cause that the wrong key is used. This code change throws a KRB_AP_ERR_BADKEYVER error in this case. > > The change is only made in AP-REQ decryption to minimize impact. A previous test is enhanced to cover the case. src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java line 578: > 576: Integer kv = keys[i].getKeyVersionNumber(); > 577: etypeFound = true; > 578: if (versionMatches(kvno, kv)) { I believe there is no coverage for this block. Do you think expanding the test would be reasonable in this pr? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27298#discussion_r2353005366 From duke at openjdk.org Tue Sep 16 16:27:32 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 16 Sep 2025 16:27:32 GMT Subject: Integrated: 8366978: dead code in SunCertPathBuilder In-Reply-To: References: Message-ID: <3wDvtqrFXA4U1qcgQwsixqyQw4VjE9MB-G0Jdl25nrk=.0dbb8d2d-55b6-4a41-8b5a-18e3204adbb4@github.com> On Sat, 13 Sep 2025 05:02:46 GMT, Koushik Muthukrishnan Thirupattur wrote: > A DESCRIPTION OF THE PROBLEM : > [JDK-7194452](https://bugs.openjdk.org/browse/JDK-7194452) left the SunCertPathBuilder.anchorIsTarget orphaned. Remove the deadcode. This pull request has now been integrated. Changeset: 15d42c6d Author: Koushik Thirupattur Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/15d42c6d772d2c4cca1f21a947407fc0931aee64 Stats: 15 lines in 1 file changed: 0 ins; 14 del; 1 mod 8366978: dead code in SunCertPathBuilder Reviewed-by: mullan, hchao ------------- PR: https://git.openjdk.org/jdk/pull/27268 From weijun at openjdk.org Tue Sep 16 17:05:31 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Sep 2025 17:05:31 GMT Subject: RFR: 8367344: Better error message when decryption of AP-REQ fails because of kvno mismatch In-Reply-To: References: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> Message-ID: On Tue, 16 Sep 2025 16:11:46 GMT, Mikhail Yankelevich wrote: >> For interoperability, AP-REQ decryption uses the key with the highest kvno in the keytab if no exact match is found. If decryption fails, a normal "checksum failed" error is reported, which may hide the real cause that the wrong key is used. This code change throws a KRB_AP_ERR_BADKEYVER error in this case. >> >> The change is only made in AP-REQ decryption to minimize impact. A previous test is enhanced to cover the case. > > src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java line 578: > >> 576: Integer kv = keys[i].getKeyVersionNumber(); >> 577: etypeFound = true; >> 578: if (versionMatches(kvno, kv)) { > > I believe there is no coverage for this block. Do you think expanding the test would be reasonable in this pr? Thanks. Actually when I tried to add a test I found some coding issues. I'm fixing now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27298#discussion_r2353132169 From fferrari at openjdk.org Tue Sep 16 17:42:28 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Tue, 16 Sep 2025 17:42:28 GMT Subject: RFR: 8367782: VerifyJarEntryName.java: Fix modifyJarEntryName to operate on bytes and re-introduce verifySignatureEntryName Message-ID: Hi, this is a second take of [JDK-8353299](https://bugs.openjdk.org/browse/JDK-8353299 "VerifyJarEntryName.java test fails") (#24337, acd4da49a01760599ec4c325ff6c56f53ba5cc9c), by making `modifyJarEntryName` operate on bytes and re-introduce `verifySignatureEntryName`. Please see [this JDK-8353299 comment](https://bugs.openjdk.org/browse/JDK-8353299?focusedId=14817153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14817153) for further explanation. ------------- Commit messages: - 8367782: VerifyJarEntryName.java: Fix modifyJarEntryName to operate on bytes and re-introduce verifySignatureEntryName Changes: https://git.openjdk.org/jdk/pull/27319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27319&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367782 Stats: 27 lines in 1 file changed: 22 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27319/head:pull/27319 PR: https://git.openjdk.org/jdk/pull/27319 From weijun at openjdk.org Tue Sep 16 17:43:34 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Sep 2025 17:43:34 GMT Subject: RFR: 8367344: Better error message when decryption of AP-REQ fails because of kvno mismatch [v2] In-Reply-To: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> References: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> Message-ID: > For interoperability, AP-REQ decryption uses the key with the highest kvno in the keytab if no exact match is found. If decryption fails, a normal "checksum failed" error is reported, which may hide the real cause that the wrong key is used. This code change throws a KRB_AP_ERR_BADKEYVER error in this case. > > The change is only made in AP-REQ decryption to minimize impact. A previous test is enhanced to cover the case. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: different exception for other etypes; test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27298/files - new: https://git.openjdk.org/jdk/pull/27298/files/28cd0d11..ecf2f5b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27298&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27298&range=00-01 Stats: 94 lines in 2 files changed: 56 ins; 12 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/27298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27298/head:pull/27298 PR: https://git.openjdk.org/jdk/pull/27298 From weijun at openjdk.org Tue Sep 16 17:53:24 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Sep 2025 17:53:24 GMT Subject: RFR: 8367344: Better error message when decryption of AP-REQ fails because of kvno mismatch [v3] In-Reply-To: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> References: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> Message-ID: > For interoperability, AP-REQ decryption uses the key with the highest kvno in the keytab if no exact match is found. If decryption fails, a normal "checksum failed" error is reported, which may hide the real cause that the wrong key is used. This code change throws a KRB_AP_ERR_BADKEYVER error in this case. > > The change is only made in AP-REQ decryption to minimize impact. A previous test is enhanced to cover the case. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more etypes in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27298/files - new: https://git.openjdk.org/jdk/pull/27298/files/ecf2f5b8..17c944a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27298&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27298&range=01-02 Stats: 19 lines in 1 file changed: 8 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27298/head:pull/27298 PR: https://git.openjdk.org/jdk/pull/27298 From weijun at openjdk.org Tue Sep 16 17:53:26 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Sep 2025 17:53:26 GMT Subject: RFR: 8367344: Better error message when decryption of AP-REQ fails because of kvno mismatch [v2] In-Reply-To: References: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> Message-ID: On Tue, 16 Sep 2025 17:43:34 GMT, Weijun Wang wrote: >> For interoperability, AP-REQ decryption uses the key with the highest kvno in the keytab if no exact match is found. If decryption fails, a normal "checksum failed" error is reported, which may hide the real cause that the wrong key is used. This code change throws a KRB_AP_ERR_BADKEYVER error in this case. >> >> The change is only made in AP-REQ decryption to minimize impact. A previous test is enhanced to cover the case. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > different exception for other etypes; test Different etypes could throw different exceptions at decryption. All are still subtypes of `KrbException`. Add test cases for all different types of etypes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27298#issuecomment-3299767697 From mpowers at openjdk.org Tue Sep 16 18:11:32 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 Sep 2025 18:11:32 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v2] In-Reply-To: References: Message-ID: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - merge - removed changes to PBMAC1Core and addressed some comments from Valerie - small changes - not used - refresh index - Merge - rework to eliminate PBMAC1ParameterSpec - merge - comments from Valerie - missed this new file - ... and 7 more: https://git.openjdk.org/jdk/compare/075ebb4e...624ef92e ------------- Changes: https://git.openjdk.org/jdk/pull/24429/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=01 Stats: 1304 lines in 8 files changed: 1146 ins; 116 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/24429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429 PR: https://git.openjdk.org/jdk/pull/24429 From mpowers at openjdk.org Tue Sep 16 18:11:37 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 Sep 2025 18:11:37 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v2] In-Reply-To: <0YyRaglid6jYE9Bn6POjjLl9BJbkMjACGsSDFav3GEM=.e911613f-3c39-4827-b3cc-009c26bc27a9@github.com> References: <0YyRaglid6jYE9Bn6POjjLl9BJbkMjACGsSDFav3GEM=.e911613f-3c39-4827-b3cc-009c26bc27a9@github.com> Message-ID: On Tue, 2 Sep 2025 19:55:13 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 17 commits: >> >> - merge >> - removed changes to PBMAC1Core and addressed some comments from Valerie >> - small changes >> - not used >> - refresh index >> - Merge >> - rework to eliminate PBMAC1ParameterSpec >> - merge >> - comments from Valerie >> - missed this new file >> - ... and 7 more: https://git.openjdk.org/jdk/compare/075ebb4e...624ef92e > > src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 88: > >> 86: * >> 87: * id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} >> 88: * > > nit: instead of repeating all this here, maybe refer to sun.security.util.PBKDF2Parameters class for PBKDF2 related ASN.1 definition? added a link > src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 96: > >> 94: >> 95: private static final ObjectIdentifier pkcs5PBKDF2_OID = >> 96: ObjectIdentifier.of(KnownOIDs.PBKDF2WithHmacSHA1); > > nit: duplicated to the one defined in sun.security.util.PBKDF2Parameters class? Good catch. Fixed. > src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 36: > >> 34: /** >> 35: * This class implements the parameter set used with password-based >> 36: * key derivation function 2 (PBKDF2), which is defined in PKCS#5 as follows: > > nit: add link to RFC 8018 here for reference done > src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 67: > >> 65: * id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} >> 66: */ >> 67: public class PBKDF2Parameters { > > nit: can be marked final? yes > src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 72: > >> 70: ObjectIdentifier.of(KnownOIDs.PBKDF2WithHmacSHA1); >> 71: >> 72: // AlgorithmIdentifier > > nit: comment doesn't seem related or useful? Maybe remove? done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353274668 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353274843 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353274459 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353275031 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353275189 From mpowers at openjdk.org Tue Sep 16 18:11:38 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 Sep 2025 18:11:38 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v2] In-Reply-To: <10im5FEusSPtz4j4XV9MlIn3MnBI0emGj7iPnLSq51c=.79e0a0f9-53da-4ad9-8633-86b871fd4380@github.com> References: <10im5FEusSPtz4j4XV9MlIn3MnBI0emGj7iPnLSq51c=.79e0a0f9-53da-4ad9-8633-86b871fd4380@github.com> Message-ID: On Wed, 3 Sep 2025 01:21:58 GMT, Valerie Peng wrote: >> fixed > > The indentation still doesn't look right... Line 139 should align with line 138? Same goes for line 140-150. Now I see it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353273364 From mpowers at openjdk.org Tue Sep 16 18:11:41 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 Sep 2025 18:11:41 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v2] In-Reply-To: References: Message-ID: <2E8f9h4SluafU6t-IOtJuZhoKATHPj9mtOSOQ_Z0IBo=.0f7f5e40-c925-4d7f-a986-8b02f1161fe2@github.com> On Fri, 11 Jul 2025 23:06:34 GMT, Mark Powers wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 162: >> >>> 160: DerValue kdf = pBMAC1_params.data.getDerValue(); >>> 161: var kdfParams = new PBKDF2Parameters(); >>> 162: String kdfAlgo = kdfParams.parseKDF(kdf); >> >> Maybe just use a `PBKDF2Parameters(DerValue) `constructor? Then retrieve the algorithm via a separate getter method. > > That constructor doesn't exist. I don't know how I would do what you suggest. I see it now. Fixed. >> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 174: >> >>> 172: throw new IOException("PMAC1 parameter parsing error: " >>> 173: + "missing keyLength field"); >>> 174: } >> >> Where is these requirements on `keyLength` documented? I found them inside RFC 9579. But no such restriction in RFC 8018. If this is PKCS12-specific requirement, I am not sure if these checks should be enforced inside `PBMAC1Parameters` class. They can be done in the `PKCS12KeyStore` class when using this object, right? > > You are right. The check belongs in the `PKCS12KeyStore` class. Since I've replaced usage of the `PBMAC1ParameterSpec` with `PBEParameterSpec`, there is no longer a way to pass keyLength to `PKCS12KeyStore`. I think the HMAC output size check can be removed since it is a SHOULD. The keyLength is present check should stay for now since it is a MUST. We can revisit this later if we switch to a different parameter spec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353274015 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353273005 From abarashev at openjdk.org Tue Sep 16 18:15:37 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 16 Sep 2025 18:15:37 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v5] In-Reply-To: References: <29QfhdwnTiDMnHXjkcwueU6W9DIQd2KTNje9jsd1ufY=.6c7414f2-239e-4c48-a8cf-ee3cd106c7d9@github.com> Message-ID: On Wed, 10 Sep 2025 15:46:35 GMT, Hai-May Chao wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a server-side unit test. Rename existing tests. > > test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS12.java line 56: > >> 54: + CERTIFICATE_DISABLED_SIG + " usage certificateSignature"; >> 55: >> 56: // Signature schemes not supported in TLSv1.3 for the handshake > > Add this bug number to the list of @bug Done, thanks! > test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS13.java line 68: > >> 66: SIG_ALGS_EXT); >> 67: >> 68: // These signature schemes MOST NOT be present in signature_algorithms > > Bug number to be added to @bug Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26887#discussion_r2353283675 PR Review Comment: https://git.openjdk.org/jdk/pull/26887#discussion_r2353286216 From abarashev at openjdk.org Tue Sep 16 18:25:08 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 16 Sep 2025 18:25:08 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v5] In-Reply-To: <_9mn1cCcnvJOOTm3acv0iO7PoJBqBBliZMEuKUj__Dk=.8eea4090-4b4e-4af7-a651-af3c9473eccc@github.com> References: <29QfhdwnTiDMnHXjkcwueU6W9DIQd2KTNje9jsd1ufY=.6c7414f2-239e-4c48-a8cf-ee3cd106c7d9@github.com> <_9mn1cCcnvJOOTm3acv0iO7PoJBqBBliZMEuKUj__Dk=.8eea4090-4b4e-4af7-a651-af3c9473eccc@github.com> Message-ID: <_v7xlXw9RiP4Tvqw6yqQe2uI9K9UJuXRhPU3TZKEEKA=.e08dc950-61eb-4d7f-b940-8d94030364af@github.com> On Wed, 10 Sep 2025 15:41:42 GMT, Hai-May Chao wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a server-side unit test. Rename existing tests. > > src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java line 551: > >> 549: sigAlgs.retainAll(hc.localSupportedCertSignAlgs); >> 550: } >> 551: > > The `sigAlgs` may include handshake scope and certificate scope. Suggest to add a debug log to list the produced signature algorithms. We actually already log the content of the `signature_algorithms` extension in `ClientHello` and `CertificateRequest` messages. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26887#discussion_r2353306435 From duke at openjdk.org Tue Sep 16 18:40:24 2025 From: duke at openjdk.org (Bernd) Date: Tue, 16 Sep 2025 18:40:24 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 18:11:32 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - merge > - removed changes to PBMAC1Core and addressed some comments from Valerie > - small changes > - not used > - refresh index > - Merge > - rework to eliminate PBMAC1ParameterSpec > - merge > - comments from Valerie > - missed this new file > - ... and 7 more: https://git.openjdk.org/jdk/compare/075ebb4e...624ef92e src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 76: > 74: private int iCount = 0; > 75: > 76: // the key derivation function (default is HmacSHA1) Is there a reason why to default to sha1, would be for a new feature good to start with a modern default (or none). I know that hmacsha1 in this usecase would still be ok, but that does Not mean that longer (and faster) hashes dont make Sense. If this is picked due to rfc compatibility, maybe name the reference in a comment? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353338481 From duke at openjdk.org Tue Sep 16 18:51:44 2025 From: duke at openjdk.org (Bernd) Date: Tue, 16 Sep 2025 18:51:44 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 18:11:32 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - merge > - removed changes to PBMAC1Core and addressed some comments from Valerie > - small changes > - not used > - refresh index > - Merge > - rework to eliminate PBMAC1ParameterSpec > - merge > - comments from Valerie > - missed this new file > - ... and 7 more: https://git.openjdk.org/jdk/compare/075ebb4e...624ef92e src/java.base/share/classes/sun/security/pkcs12/MacData.java line 106: > 104: macSalt = pbeSpec.getSalt(); > 105: String ps = digestAlgorithmParams.toString(); > 106: kdfHmac = getKdfHmac(ps); Are the macs always the same? (The encoder serializes them Independent) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353361561 From abarashev at openjdk.org Tue Sep 16 19:24:05 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 16 Sep 2025 19:24:05 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v6] In-Reply-To: References: Message-ID: > [JDK-8349583](https://bugs.openjdk.org/browse/JDK-8349583) implementation assumes that OpenJDK client always sends "signature_algorithms_cert" extension together with "signature_algorithms" extension. But we didn't account for `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties which can disable producing "signature_algorithms_cert" extension. This is an issue similar to [JDK-8355779](https://bugs.openjdk.org/browse/JDK-8355779) but on the extension producing side. > > Per TLSv1.3 RFC: > >> If no "signature_algorithms_cert" extension is >> present, then the "signature_algorithms" extension also applies to >> signatures appearing in certificates. > > Also making a few cosmetic changes to the existing code. 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 eight additional commits since the last revision: - Add a ticket number to unit tests - Merge branch 'master' into JDK-8365820 - Add a server-side unit test. Rename existing tests. - Update tests - Revert "Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3" This reverts commit adc236be4bcac11614e2741c99545aa593f6af5b. - Merge branch 'master' into JDK-8365820 - Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3 - 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26887/files - new: https://git.openjdk.org/jdk/pull/26887/files/89867a60..b934cd1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26887&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26887&range=04-05 Stats: 43636 lines in 1532 files changed: 26558 ins; 10380 del; 6698 mod Patch: https://git.openjdk.org/jdk/pull/26887.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26887/head:pull/26887 PR: https://git.openjdk.org/jdk/pull/26887 From mpowers at openjdk.org Tue Sep 16 23:03:00 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 Sep 2025 23:03:00 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: a few more comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24429/files - new: https://git.openjdk.org/jdk/pull/24429/files/624ef92e..e13d0dd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=01-02 Stats: 51 lines in 4 files changed: 9 ins; 28 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/24429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429 PR: https://git.openjdk.org/jdk/pull/24429 From mpowers at openjdk.org Tue Sep 16 23:03:03 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 Sep 2025 23:03:03 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v2] In-Reply-To: References: Message-ID: <_tlAyz9_lbDBCKMyIHBhJygdpbFvsycrkaLJLAsnEOg=.957240cc-c7a9-4854-9734-3c440790a6e0@github.com> On Tue, 16 Sep 2025 18:11:32 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - merge > - removed changes to PBMAC1Core and addressed some comments from Valerie > - small changes > - not used > - refresh index > - Merge > - rework to eliminate PBMAC1ParameterSpec > - merge > - comments from Valerie > - missed this new file > - ... and 7 more: https://git.openjdk.org/jdk/compare/075ebb4e...624ef92e [wangweij](https://github.com/wangweij) You are correct that the `keytool` example doesn't work. My bad. It works now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24429#issuecomment-3300602081 From mpowers at openjdk.org Tue Sep 16 23:03:04 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 Sep 2025 23:03:04 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: <4Iz9g8koaHJPZcPUq7fG0vlj4s1wjj7iQ1q09X5LCf0=.4fb5698a-4405-4efb-87ee-071b3d2a478a@github.com> On Thu, 4 Sep 2025 21:21:04 GMT, Weijun Wang wrote: >> Is it possible to add a `keyLength` argument to the constructor, so that a different key length can be set along with the block length. > > In fact, this will change the behavior of the Mac algorithm `PBEWithHmacSHA256` since we hardcoded `keyLength` as `blockLength` there. I made the check in MacData on the DER input stream instead. That said, I took Weijun's suggestion in JDK-8366979 and was able to avoid making any change to PBMAC1Core. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353826863 From mpowers at openjdk.org Tue Sep 16 23:03:06 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 Sep 2025 23:03:06 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 11:41:55 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> a few more comments > > src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Core.java line 169: > >> 167: keyLength = 256; >> 168: } >> 169: /* > > commented out code ... There are no longer any changes to this file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353827162 From mpowers at openjdk.org Tue Sep 16 23:03:12 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 16 Sep 2025 23:03:12 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 19:58:26 GMT, Valerie Peng wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> a few more comments > > src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 115: > >> 113: protected void engineInit(AlgorithmParameterSpec paramSpec) >> 114: throws InvalidParameterSpecException >> 115: { > > nit: move the "{" to the end of line 114, same goes for other methods. done > src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 156: > >> 154: DerValue kdf = pBMAC1_params.data.getDerValue(); >> 155: var kdfParams = new PBKDF2Parameters(); >> 156: String kdfAlgo = kdfParams.init(kdf); > > Hmm, it's somewhat obscure to return the prf algorithm as the result of `PBKDF2Parameters.init(...) `call. > Is there a reason for a separate `init(...)` call? How about just `PBKDF2Parameters(kdf)` and retrieve the `prfAlgo` (instead of the "kdfAlgo" name) separately just like `salt`, `iCount` and `keyLength`? This has been changed to `PBKDF2Parameters(kdf) `by an earlier comment. Are you suggesting to change `kdfAlgo` to `prfAlgo` or something else? > src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 165: > >> 163: throw new IOException("PBMAC1 parameter parsing " >> 164: + "error: missing keyLength field"); >> 165: } > > Isn't this a PKCS#12 restriction? If so, this should be moved to PKCS12KeyStore class? The `keyLength` is present check should stay for now since it is a MUST. We can revisit this later if we switch to a different parameter spec. Without a `PBMAC1ParameterSpec` there is no way to pass `keyLength` to PKCS12. > src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 73: > >> 71: >> 72: // AlgorithmIdentifier >> 73: private String prf = null; > > Set the default value to "HmacSHA1" here instead of when parsing the DER encoding? I set the default value of `kdfAlgo` to "HmacSHA1". > src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 77: > >> 75: private byte[] salt = null; >> 76: >> 77: private int iterationCount = 0; > > nit: order the fields matching the ASN.1 definition? done > src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 81: > >> 79: // the pseudorandom function (default is HmacSHA1) >> 80: private ObjectIdentifier kdfAlgo_OID = >> 81: ObjectIdentifier.of(KnownOIDs.HmacSHA1); > > This field is not really used? This can just be a local variable when parsing the DER encoding. It's now referenced by PBMAC1Parameters because of an earlier comment so I can't remove it. > src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 142: > >> 140: } else { >> 141: kdfAlgo = "HmacSHA1"; >> 142: } > > Can be removed if setting the `prf` default value. done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353826986 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353825760 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353825902 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353826428 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353825603 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353826085 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353826678 From ascarpino at openjdk.org Wed Sep 17 01:00:21 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 17 Sep 2025 01:00:21 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v2] In-Reply-To: References: Message-ID: > Hi > > Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: > > - Renamed the name of `PEMRecord` class to `PEM`. > - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. > - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: rework test & commented out code. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27147/files - new: https://git.openjdk.org/jdk/pull/27147/files/c493fa08..b2d0defd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=00-01 Stats: 71 lines in 2 files changed: 19 ins; 29 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/27147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147 PR: https://git.openjdk.org/jdk/pull/27147 From mdonovan at openjdk.org Wed Sep 17 11:58:25 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 17 Sep 2025 11:58:25 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures Message-ID: This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. ------------- Commit messages: - 8353738: Update TLS unit tests to not use certificates with MD5 signatures Changes: https://git.openjdk.org/jdk/pull/27342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353738 Stats: 2551 lines in 10 files changed: 400 ins; 2046 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/27342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342 PR: https://git.openjdk.org/jdk/pull/27342 From mdonovan at openjdk.org Wed Sep 17 12:29:36 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 17 Sep 2025 12:29:36 GMT Subject: RFR: 8366182: Some PKCS11Tests are being skipped when they shouldn't [v3] In-Reply-To: References: Message-ID: <0MVFVyZ7hY41WsFQptwLnK2rrbnfmLDz55-UBsTf5go=.bbccdd59-67a3-4d8e-a354-fd27d9c9d73a@github.com> > This PR updates PKCS11 tests to better handle NSS version numbers. The previous code treated the version numbers as double values and used comparison operators. The problem is that it incorrectly treats 3.111 as between 3.11 and 3.12. This update parses and compares the major and minor version numbers separately. Matthew Donovan 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 nss-skipped - refactored to encapsulate the version as a record instead of doing repeated string parsing - 8366182: Some PKCS11Tests are being skipped when they shouldn't ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27095/files - new: https://git.openjdk.org/jdk/pull/27095/files/cd250fab..da7faa4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27095&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27095&range=01-02 Stats: 38282 lines in 1123 files changed: 19273 ins; 10145 del; 8864 mod Patch: https://git.openjdk.org/jdk/pull/27095.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27095/head:pull/27095 PR: https://git.openjdk.org/jdk/pull/27095 From mdonovan at openjdk.org Wed Sep 17 12:46:17 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 17 Sep 2025 12:46:17 GMT Subject: RFR: 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments [v5] In-Reply-To: References: Message-ID: > This PR extends security tests to use ByteBuffers backed by MemorySegments. Tests in the areas of Signature, Cipher, MessageDigest, and Mac are updated. Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into cipher-ffm - updated additional Cipher tests for MemorySegment-backed ByteBuffers - Merge branch 'master' into cipher-ffm - added null-check for arena argument - addressed PR comments and refactored to use try-with-resources - Merge branch 'master' into cipher-ffm - 8357466: Create test for Ciphers that are using ByteBuffers backed by MemorySegments ------------- Changes: https://git.openjdk.org/jdk/pull/26967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26967&range=04 Stats: 1208 lines in 22 files changed: 530 ins; 151 del; 527 mod Patch: https://git.openjdk.org/jdk/pull/26967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26967/head:pull/26967 PR: https://git.openjdk.org/jdk/pull/26967 From djelinski at openjdk.org Wed Sep 17 13:19:28 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 17 Sep 2025 13:19:28 GMT Subject: RFR: 8328046: Need to keep leading zeros in TlsPremasterSecret of TLS1.3 DHKeyAgreement Message-ID: TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved. Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved. This PR changes the TLS 1.3 handshake to use the new algorithm name. It also fixes a bug in PKCS11 Generic key derivation, and updates the existing tests to verify that the Generic algorithm doesn't strip leading zeroes. I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details. Tier1-3 tests continue to pass. The `TestLeadingZeroesP11.java` test fails before the `P11KeyAgreement.java` changes, passes after. ------------- Commit messages: - Update copyright, add bug IDs - Fix PKCS11 DH key derivation - Keep leading zeroes in tls13 Changes: https://git.openjdk.org/jdk/pull/27343/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27343&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328046 Stats: 86 lines in 4 files changed: 51 ins; 24 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27343.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27343/head:pull/27343 PR: https://git.openjdk.org/jdk/pull/27343 From weijun at openjdk.org Wed Sep 17 14:50:49 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 Sep 2025 14:50:49 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> Message-ID: On Wed, 17 Sep 2025 14:19:20 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> a few more comments > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 180: > >> 178: private int macSaltLength = -1; >> 179: private byte[] extraSalt = null; >> 180: private int extraIterationCount = -1; > > I don't think it's necessary to break the user-provided mac algorithm like "PBEWithHmacSHA256" into `macAlgorithm == "PBMAC1"` and `pbmac1Hmac == "HmacSHA256"`. Keep a single one no matter what kind of mac algorithm it is. How necessary is it to remember `macSaltLength`? Before this change, we always generate a new salt of 20 bytes without looking at the old one. Also, what about `extraSalt`, and `extraIterationCount`? Since they are useless for PBMAC1, why cannot we just always hardcode them in the encoding? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2355744083 From weijun at openjdk.org Wed Sep 17 14:50:46 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 Sep 2025 14:50:46 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> On Tue, 16 Sep 2025 23:03:00 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > a few more comments Some comments on `PKC12KeyStore`. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 180: > 178: private int macSaltLength = -1; > 179: private byte[] extraSalt = null; > 180: private int extraIterationCount = -1; I don't think it's necessary to break the user-provided mac algorithm like "PBEWithHmacSHA256" into `macAlgorithm == "PBMAC1"` and `pbmac1Hmac == "HmacSHA256"`. Keep a single one no matter what kind of mac algorithm it is. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1490: > 1488: > 1489: if (macAlgorithm.equals("PBMAC1") || > 1490: defaultMacAlgorithm().startsWith("PBEWith")) { `calculateMac` is called when keystore is read from an existing file and `defaultMacAlgorithm` should not be used. Otherwise, algorithm will be modified. Try these: keytool -keystore ks -keyalg ec -storepass changeit -genkeypair -alias a -dname CN=a -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA512 keytool -keystore ks -keyalg ec -storepass changeit -genkeypair -alias b -dname CN=b -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256 src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1495: > 1493: } else if (defaultMacAlgorithm().equals("PBEWithHmacSHA256")) { > 1494: kdfHmac = "HmacSHA256"; > 1495: } else { Why don't we support `PBEWithHmacSHA384` etc? src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1509: > 1507: > 1508: var skf = SecretKeyFactory.getInstance(kdfHmac.equals("HmacSHA512") ? > 1509: "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256"); Why is PBKDF2 used for non-PBMAC1 algorithms as well? ------------- PR Review: https://git.openjdk.org/jdk/pull/24429#pullrequestreview-3234719221 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2355693464 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2355758215 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2355761701 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2355763431 From weijun at openjdk.org Wed Sep 17 14:50:48 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 Sep 2025 14:50:48 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 13:06:47 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> a few more comments > > src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 544: > >> 542: "com.sun.crypto.provider.PBES2Parameters$HmacSHA512_256AndAES_256"); >> 543: >> 544: psA("AlgorithmParameters", "PBMAC1", > > Why do we need to expose this as a standard `AlgorithmParameters` algorithm as part of this change? Maybe this would be useful later, but I don't think it is needed as this enhancement is just for internal use in PKCS12 KeyStore. @mcpowers Have you removed this in the latest commits? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2355795009 From mpowers at openjdk.org Wed Sep 17 14:57:47 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 17 Sep 2025 14:57:47 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: <65rndgokdUz7OZKSVapsWnHN8XbKfw95N0tw0V438FU=.7b8bc21a-eedc-422c-82e2-353f3d6d35bc@github.com> On Fri, 5 Sep 2025 13:06:47 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> a few more comments > > src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 544: > >> 542: "com.sun.crypto.provider.PBES2Parameters$HmacSHA512_256AndAES_256"); >> 543: >> 544: psA("AlgorithmParameters", "PBMAC1", > > Why do we need to expose this as a standard `AlgorithmParameters` algorithm as part of this change? Maybe this would be useful later, but I don't think it is needed as this enhancement is just for internal use in PKCS12 KeyStore. Not yet. I'm looking at Sean's comments today. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2355813064 From weijun at openjdk.org Wed Sep 17 14:57:48 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 Sep 2025 14:57:48 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: <65rndgokdUz7OZKSVapsWnHN8XbKfw95N0tw0V438FU=.7b8bc21a-eedc-422c-82e2-353f3d6d35bc@github.com> References: <65rndgokdUz7OZKSVapsWnHN8XbKfw95N0tw0V438FU=.7b8bc21a-eedc-422c-82e2-353f3d6d35bc@github.com> Message-ID: On Wed, 17 Sep 2025 14:52:36 GMT, Mark Powers wrote: >> src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 544: >> >>> 542: "com.sun.crypto.provider.PBES2Parameters$HmacSHA512_256AndAES_256"); >>> 543: >>> 544: psA("AlgorithmParameters", "PBMAC1", >> >> Why do we need to expose this as a standard `AlgorithmParameters` algorithm as part of this change? Maybe this would be useful later, but I don't think it is needed as this enhancement is just for internal use in PKCS12 KeyStore. > > Not yet. I'm looking at Sean's comments today. And this duplicates `MacData.getEncoded()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2355821287 From abarashev at openjdk.org Wed Sep 17 15:30:44 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 17 Sep 2025 15:30:44 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v10] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. Artur Barashev has updated the pull request incrementally with two additional commits since the last revision: - Cleaner certpath validation solution - Alternative solution for JDK-8367104 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/85a7b6f1..0be01de0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=08-09 Stats: 49 lines in 4 files changed: 6 ins; 34 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From mpowers at openjdk.org Wed Sep 17 15:43:02 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 17 Sep 2025 15:43:02 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 12:06:53 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> a few more comments > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1489: > >> 1487: final MacData macData; >> 1488: >> 1489: if (macAlgorithm.equals("PBMAC1")) { > > The PBMAC1 algorithms are already defined in the standard algorithm names spec, see https://download.java.net/java/early_access/jdk25/docs/specs/security/standard-names.html#mac-algorithms > > The default value of the `keystore.pkcs12.macAlgorithm` security property in the `java.security`file should be changed to "PBEWithHmacSHA256" as part of this change. > > So you don't need to check if the algorithm is "PBMAC1", just use the algorithm that the property is set to. Not sure if any tests will break if we make "PBEWithHmacSHA256" the default. I'll check. If the `keystore.pkcs12.macAlgorithm` security property is **not** changed, then I believe the rule is to write the keystore as it was read, meaning a keystore with the old MAC will be written as such. Removing this "PBMAC1" check would make it impossible to do this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2355942286 From jnimeh at openjdk.org Wed Sep 17 15:54:45 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Wed, 17 Sep 2025 15:54:45 GMT Subject: RFR: 8365581: Optimize Java implementation of P256 arithmetic [v4] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 16:46:10 GMT, Ben Perez wrote: >> There are several places where MontgomeryIntegerPolynomialP256.mult() can be optimized. In particular, since modulus[2] = 0 several multiplications can be removed. Other multiplications can be replaced by shifts, which also saves time. Preliminary tests indicate an improvement between 5-10%. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > removed unnecessary subtraction Marked as reviewed by jnimeh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26792#pullrequestreview-3235163498 From weijun at openjdk.org Wed Sep 17 16:12:00 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 Sep 2025 16:12:00 GMT Subject: RFR: 8367344: Better error message when decryption of AP-REQ fails because of kvno mismatch [v4] In-Reply-To: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> References: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> Message-ID: > For interoperability, AP-REQ decryption uses the key with the highest kvno in the keytab if no exact match is found. If decryption fails, a normal "checksum failed" error is reported, which may hide the real cause that the wrong key is used. This code change throws a KRB_AP_ERR_BADKEYVER error in this case. > > The change is only made in AP-REQ decryption to minimize impact. A previous test is enhanced to cover the case. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27298/files - new: https://git.openjdk.org/jdk/pull/27298/files/17c944a9..10e409d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27298&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27298&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27298/head:pull/27298 PR: https://git.openjdk.org/jdk/pull/27298 From weijun at openjdk.org Wed Sep 17 16:50:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 Sep 2025 16:50:52 GMT Subject: RFR: 8367344: Better error message when decryption of AP-REQ fails because of kvno mismatch [v5] In-Reply-To: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> References: <9ibD55S0Kxt7NCO0zN4tFoXzRq4PTei6GAioFastTX0=.41c7326e-307b-4274-9cfa-d6ed3920a84b@github.com> Message-ID: > For interoperability, AP-REQ decryption uses the key with the highest kvno in the keytab if no exact match is found. If decryption fails, a normal "checksum failed" error is reported, which may hide the real cause that the wrong key is used. This code change throws a KRB_AP_ERR_BADKEYVER error in this case. > > The change is only made in AP-REQ decryption to minimize impact. A previous test is enhanced to cover the case. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: call fromUserKtab directly with aotomatic isInitiator being false; show exception if not correct code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27298/files - new: https://git.openjdk.org/jdk/pull/27298/files/10e409d6..aee6aec3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27298&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27298&range=03-04 Stats: 17 lines in 1 file changed: 0 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27298/head:pull/27298 PR: https://git.openjdk.org/jdk/pull/27298 From dfuchs at openjdk.org Wed Sep 17 16:58:04 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 17 Sep 2025 16:58:04 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: - merge latest changes from master branch - merge latest changes from master branch - http3: CSR review feedback - merge latest changes from master branch - modify http3 test timeouts - qpack - take knownReceivedCount into account during DT entries eviction - merge latest changes from master branch - http3: fix at since - merge latest http3 changes - Remove unused variables - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=17 Stats: 105854 lines in 474 files changed: 103017 ins; 1337 del; 1500 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From mpowers at openjdk.org Wed Sep 17 18:55:22 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 17 Sep 2025 18:55:22 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:35:29 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1489: >> >>> 1487: final MacData macData; >>> 1488: >>> 1489: if (macAlgorithm.equals("PBMAC1")) { >> >> The PBMAC1 algorithms are already defined in the standard algorithm names spec, see https://download.java.net/java/early_access/jdk25/docs/specs/security/standard-names.html#mac-algorithms >> >> The default value of the `keystore.pkcs12.macAlgorithm` security property in the `java.security`file should be changed to "PBEWithHmacSHA256" as part of this change. >> >> So you don't need to check if the algorithm is "PBMAC1", just use the algorithm that the property is set to. > > Not sure if any tests will break if we make "PBEWithHmacSHA256" the default. I'll check. > > If the `keystore.pkcs12.macAlgorithm` security property is **not** changed, then I believe the rule is to write the keystore as it was read, meaning a keystore with the old MAC will be written as such. Removing this "PBMAC1" check would make it impossible to do this. I found one and maybe two existing tests that will have to be modified if "PBEWithHmacSHA256" becomes the default. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2356462159 From abarashev at openjdk.org Wed Sep 17 20:03:03 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 17 Sep 2025 20:03:03 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v11] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Remove unused import. Adjust comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/0be01de0..0ac712aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=09-10 Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From mullan at openjdk.org Wed Sep 17 20:13:55 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 17 Sep 2025 20:13:55 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 01:00:21 GMT, Anthony Scarpino wrote: >> Hi >> >> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: >> >> - Renamed the name of `PEMRecord` class to `PEM`. >> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. >> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > rework test & commented out code. src/java.base/share/classes/java/security/PEMDecoder.java line 55: > 53: *

The {@link #decode(String)} and {@link #decode(InputStream)} > 54: * methods return an instance of a class matching the PEM type and > 55: * implementing {@link DEREncodable}. Wording suggestion: "... that matches the PEM type and implements `DEREncodable`" src/java.base/share/classes/java/security/PEMDecoder.java line 58: > 56: * > 57: *

Supported PEM types and their decoded {@code DEREncodable} classes > 58: * include: "include" may suggest that this is not a complete list, and others are supported. Suggest using a different word. I prefer the prior wording because it is more definitive. src/java.base/share/classes/java/security/PEMDecoder.java line 74: > 72: * Decryption) > 73: *

  • ENCRYPTED PRIVATE KEY : {@code KeyPair} (if configured with > 74: * Decryption)
    • "Decryption" doesn't need to be capitalized. Same comment on other lines. src/java.base/share/classes/java/security/PEMDecoder.java line 81: > 79: * > 80: *

    For {@code PublicKey} and {@code PrivateKey} types, an algorithm-specific > 81: * subclass is returned if the algorithm is supported. For example an add comma after "For example" src/java.base/share/classes/java/security/PEMDecoder.java line 82: > 80: *

    For {@code PublicKey} and {@code PrivateKey} types, an algorithm-specific > 81: * subclass is returned if the algorithm is supported. For example an > 82: * ECPublicKey and ECPrivateKey for Elliptic Curve keys. Put code font around ECPublicKey and ECPrivateKey. src/java.base/share/classes/java/security/PEMDecoder.java line 90: > 88: *

    The {@link #decode(String, Class)} and > 89: * {@link #decode(InputStream, Class)} methods take a class parameter > 90: * to specify the returned {@code DEREncodable} type. These s/to specify/which specifies/ Also I think "type of {@code DEREncodable} that is returned" was more clear. src/java.base/share/classes/java/security/PEMDecoder.java line 91: > 89: * {@link #decode(InputStream, Class)} methods take a class parameter > 90: * to specify the returned {@code DEREncodable} type. These > 91: * methods are useful when extracting or changing the return class. "changing the return class" sounds confusing here. Is it better to say "These methods are useful to avoid casting the return type when the PEM type is known, or when extracting a specific type when there is more than one choice." src/java.base/share/classes/java/security/PEMDecoder.java line 92: > 90: * to specify the returned {@code DEREncodable} type. These > 91: * methods are useful when extracting or changing the return class. > 92: * For example, if the PEM contains both a public and private keys, specifying s/keys/key/ src/java.base/share/classes/java/security/PEMDecoder.java line 95: > 93: * {@code PrivateKey.class} returns only the private key. > 94: * If the class parameter specifies {@code X509EncodedKeySpec.class}, the > 95: * public key encoding is returned in that class. Any type of PEM data can be I think you could word "returned in that class" differently - how about "returned in an instance of the `X509EncodedKeySpec` class" src/java.base/share/classes/java/security/PEMDecoder.java line 103: > 101: * with {@link #withFactory(Provider)} and/or > 102: * {@link #withDecryption(char[])}. {@link #withFactory(Provider)} > 103: * restricts decoding to {@link KeyFactory} and Wording suggestion: "The withFactory method uses the specified provider to produce cryptographic objects from `KeyFactory` and `CertificateFactory`" src/java.base/share/classes/java/security/PEMDecoder.java line 107: > 105: * {@link #withDecryption(char[])} configures the decoder to process > 106: * encrypted private key PEM data using the given password. > 107: * If decryption fails, a {@link RuntimeException} is thrown. Be more specific - `IllegalArgumentException` is specified by the decode methods. src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 112: > 110: /** > 111: * Constructor that takes both public and private encodings. If > 112: * pubEncoding is null, a V1 PKCS8 encoding is created; otherwise, V2 is s/pubEncoding/publicEncoding/ src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 301: > 299: * PKCS8v2 DER-encoded byte[]. > 300: * > 301: * @param pubKeyEncoded DER-encoded PublicKey, this maybe null. s/maybe/may be/ test/jdk/java/security/PEM/PEMData.java line 290: > 288: """, RSAPrivateKey.class, "SunRsaSign"); > 289: > 290: static final Entry ecsecp256ekpi = new Entry("ecsecp256epki", Change variable name to match entry - `ecsecp256epki` test/jdk/java/security/PEM/PEMEncoderTest.java line 124: > 122: kp = d.withDecryption(PEMData.ecsecp256ekpi.password()).decode(s, KeyPair.class); > 123: var newPriv = kp.getPrivate(); > 124: if (Arrays.compare(origPriv.getEncoded(), newPriv.getEncoded()) != 0) { Just use `Arrays.equals()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356508260 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356511529 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356515723 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356517871 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356518400 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356524895 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356528661 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356530837 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356641222 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356651975 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356655793 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356448014 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356458951 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356386093 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356400320 From weijun at openjdk.org Wed Sep 17 21:06:49 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 Sep 2025 21:06:49 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v4] In-Reply-To: References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: On Wed, 27 Aug 2025 10:25:00 GMT, Sean Coffey wrote: >> SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode) >> >> SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode. >> >> Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()` >> >> DebugPropertyValuesTest also updated to test new logic. > > Sean Coffey 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 8343395-formatter > - Merge branch 'master' into 8343395-formatter > - Merge branch 'master' into 8343395-formatter > - Text Blocks use \n by default > - 8343395 Does this mean the `parameters` argument in the `SSLSimpleFormatter::format` method is always empty? And then all those `messageCompactFormatWithParas` and `messageFormatWithParas` are useless? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25934#issuecomment-3304559320 From mullan at openjdk.org Wed Sep 17 21:14:20 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 17 Sep 2025 21:14:20 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v11] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Wed, 17 Sep 2025 20:03:03 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import. Adjust comments. src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 216: > 214: } > 215: > 216: // Set trust anchor for the user-specified AlgorithmChecker. AlgorithmChecker is an internal class, so probably won't be passed in by a user. Probably just say "any passed-in AlgorithmChecker". test/jdk/sun/security/ssl/SignatureScheme/RsaSsaPssConstraints.java line 1: > 1: /* Can you also add some tests which cause a `CertPathBuilder` to be used. i.e. via the `PKIXValidator.doBuild` method? I'd like to make sure the behavior is the same. You could try mixing up the order of the chain or throwing in a couple of unnecessary certificates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2356778213 PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2356792676 From mullan at openjdk.org Wed Sep 17 21:14:23 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 17 Sep 2025 21:14:23 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v10] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Wed, 17 Sep 2025 15:30:44 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. > > Artur Barashev has updated the pull request incrementally with two additional commits since the last revision: > > - Cleaner certpath validation solution > - Alternative solution for JDK-8367104 src/java.base/share/classes/sun/security/validator/PKIXValidator.java line 264: > 262: X509Certificate last = chain[chain.length - 1]; > 263: X500Principal issuer = last.getIssuerX500Principal(); > 264: X500Principal subject = last.getSubjectX500Principal(); unused variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2356795259 From weijun at openjdk.org Wed Sep 17 21:51:38 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 Sep 2025 21:51:38 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 18:24:59 GMT, Anthony Scarpino wrote: >> I see there could be a >> >> parameters [0] ECDomainParameters {{ SECGCurveNames }} OPTIONAL, >> >> Shall we skip it? > > This only checks if one is available in the private key material. If there is none, null is fine. > > The domain parameters are kept as part of private key SEC1v2 encoding and can be read when generating a private key with a KeyFactory. Translating the encoding could be error-prone, and maybe incompatible. Oh, I meant if both [0] and [1] are there you can skip [0] and read [1]. Currently you just check for [1]. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2356863706 From abarashev at openjdk.org Wed Sep 17 21:58:19 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 17 Sep 2025 21:58:19 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v10] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Wed, 17 Sep 2025 21:11:02 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with two additional commits since the last revision: >> >> - Cleaner certpath validation solution >> - Alternative solution for JDK-8367104 > > src/java.base/share/classes/sun/security/validator/PKIXValidator.java line 264: > >> 262: X509Certificate last = chain[chain.length - 1]; >> 263: X500Principal issuer = last.getIssuerX500Principal(); >> 264: X500Principal subject = last.getSubjectX500Principal(); > > unused variable. It was there originally actually. `PKIXValidator.java` isn't being modified in this PR, I have restored it to the original state. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2356873189 From abarashev at openjdk.org Wed Sep 17 22:03:53 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 17 Sep 2025 22:03:53 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v11] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Wed, 17 Sep 2025 21:02:33 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused import. Adjust comments. > > src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 216: > >> 214: } >> 215: >> 216: // Set trust anchor for the user-specified AlgorithmChecker. > > AlgorithmChecker is an internal class, so probably won't be passed in by a user. Probably just say "any passed-in AlgorithmChecker". The meaning is that's a user-specified checker, same as a comment [here](https://github.com/openjdk/jdk/blob/e1071797a4f0ab1a6af29824a777a7800d729b0e/src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java#L420). Please also see `add user-specified checkers` comment a few lines below. So I used this wording for consistency with existing comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2356876903 From valeriep at openjdk.org Thu Sep 18 00:06:01 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 18 Sep 2025 00:06:01 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: References: Message-ID: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> > This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods. > > As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear. > > Thanks in advance for the review~ > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: updated the checkTransformation() method w/ specific provider and exception per Sean's suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26489/files - new: https://git.openjdk.org/jdk/pull/26489/files/4d4638cd..0ce7a49f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26489&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26489&range=06-07 Stats: 38 lines in 1 file changed: 0 ins; 15 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/26489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26489/head:pull/26489 PR: https://git.openjdk.org/jdk/pull/26489 From valeriep at openjdk.org Thu Sep 18 00:06:02 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 18 Sep 2025 00:06:02 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v7] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 13:59:28 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments from Sean. > > test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java line 85: > >> 83: >> 84: checkTransformation("ChaCha20/ECB/NoPadding", Expected.NSAE_OR_NSPE); >> 85: checkTransformation("ChaCha20/None/PKCS5Padding", Expected.NSAE_OR_NSPE); > > Isn't this always going to throw NSPE given the current provider configuration? Also, same comment on line 88. I can explicit specify `SunJCE` provider in the `getInstance(...)` call and then match the specific exception based on its impl. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2357054011 From valeriep at openjdk.org Thu Sep 18 00:06:03 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 18 Sep 2025 00:06:03 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v6] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 19:24:46 GMT, Sean Mullan wrote: >> Well, which exception is thrown depends on which provider is used and how it registers its implementations. Pinpointing the exact Exception would require running the test against a specific provider which we know how the implementations are registered. Without tying the test to a specific provider, existing transformations in this test may lead to either NSAE or NSPE, thus I just add NSPE to the catch clause. I can add more transformations which would lead to only NSAE assuming this is what you want to see? > > I think it is ok to assume the JDK provider configuration has not been changed. > > Wouldn't "ChaCha20/None/PKCS5Padding" and ""ChaCha20-Poly1305/None/PKCS5Padding"" always throw `NoSuchPaddingException`, assuming the current JDK configuration is not changed? Maybe instead of passing a boolean expected parameter, you could pass the expected Exception, or null if none expected. Yes, I have adopted your suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2357056150 From valeriep at openjdk.org Thu Sep 18 01:32:37 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 18 Sep 2025 01:32:37 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> Message-ID: On Thu, 18 Sep 2025 00:06:01 GMT, Valerie Peng wrote: >> This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods. >> >> As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear. >> >> Thanks in advance for the review~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > updated the checkTransformation() method w/ specific provider and > exception per Sean's suggestion Release Note is filed @ https://bugs.openjdk.org/browse/JDK-8367577 Thanks in advance for review~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/26489#issuecomment-3305067363 From swen at openjdk.org Thu Sep 18 01:33:38 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 18 Sep 2025 01:33:38 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> Message-ID: On Mon, 15 Sep 2025 09:02:11 GMT, Per Minborg wrote: >> We have, for long, established that changes like this should be discussed before putting forward any code. Yet, I am unable to find any discussion in the appropriate mailing list. Please send me the link to the mailing list discussion. I must have missed it for some reason. > >> @minborg >> >> The process went like this: >> >> On August 23rd, I posted an email to the core-libs-dev mailing list titled "Introduce and utilize DecimalDigits.appendPair for efficient two-digit formatting." The message included a link to the pull request (PR) #26911. At the time, the PR was in draft status. >> >> On August 26th, @jodastephen commented on the PR. >> >> He's an expert in java.time, and based on his comments, I created an issue and changed the PR status to RFR. > > This mail appears to merely point out that there is a PR with code. I am unable to locate any discussion *prior* to any code being presented. E.g., whether we should do this or not. What are the pros and cons, etc. What did I miss? > > @minborg > > The process went like this: > > On August 23rd, I posted an email to the core-libs-dev mailing list titled "Introduce and utilize DecimalDigits.appendPair for efficient two-digit formatting." The message included a link to the pull request (PR) #26911. At the time, the PR was in draft status. > > On August 26th, @jodastephen commented on the PR. > > He's an expert in java.time, and based on his comments, I created an issue and changed the PR status to RFR. > > This mail appears to merely point out that there is a PR with code. I am unable to locate any discussion _prior_ to any code being presented. E.g., whether we should do this or not. What are the pros and cons, etc. What did I miss? I think that discussing via email + draft Pull Request will better describe the changes and their effects than just email. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3305066592 From swen at openjdk.org Thu Sep 18 01:33:39 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 18 Sep 2025 01:33:39 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: On Mon, 15 Sep 2025 13:53:23 GMT, Weijun Wang wrote: > I'd rather see a real public API even if it looks like `StringBuilder::appendInteger(boolean alwaysSign, boolean packWithZero, int minWidth, int number)`. Methods like appendPair are provided for better performance, and you suggest that it is not easy to achieve the same performance with such an API. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3305071018 From coffeys at openjdk.org Thu Sep 18 09:23:15 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 18 Sep 2025 09:23:15 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v5] In-Reply-To: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: > SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode) > > SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode. > > Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()` > > DebugPropertyValuesTest also updated to test new logic. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Correct old typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25934/files - new: https://git.openjdk.org/jdk/pull/25934/files/4b740d23..82c5427b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25934&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25934&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25934/head:pull/25934 PR: https://git.openjdk.org/jdk/pull/25934 From coffeys at openjdk.org Thu Sep 18 09:29:18 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 18 Sep 2025 09:29:18 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v4] In-Reply-To: References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: On Wed, 17 Sep 2025 21:04:34 GMT, Weijun Wang wrote: > Does this mean the `parameters` argument in the `SSLSimpleFormatter::format` method is always empty? And then all those `messageCompactFormatWithParas` and `messageFormatWithParas` are useless? `SSLSimpleFormatter.formatParameters(params)` is still used and contains logic to decode JSSE Objects for logging purposes. On your specific question regarding messageCompactFormatWithParas / messageFormatWithParas correct - they appear to have been designed for SSLConsoleLogger use. The System.Logger option delegates back to the logging framework regarding output format. The default System Logger format already includes some fields. e.g. : Sep 18, 2025 9:10:00 AM sun.security.ssl.SSLLogger log FINE: Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25934#issuecomment-3306455651 From mullan at openjdk.org Thu Sep 18 13:21:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 13:21:53 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v11] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Wed, 17 Sep 2025 21:58:48 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java line 216: >> >>> 214: } >>> 215: >>> 216: // Set trust anchor for the user-specified AlgorithmChecker. >> >> AlgorithmChecker is an internal class, so probably won't be passed in by a user. Probably just say "any passed-in AlgorithmChecker". > > The meaning is that's a user-specified checker, same as a comment [here](https://github.com/openjdk/jdk/blob/e1071797a4f0ab1a6af29824a777a7800d729b0e/src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java#L420). Please also see `add user-specified checkers` comment a few lines below. So I used this wording for consistency with existing comments. Ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2359259924 From mullan at openjdk.org Thu Sep 18 13:21:56 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 13:21:56 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v10] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Wed, 17 Sep 2025 21:55:54 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/validator/PKIXValidator.java line 264: >> >>> 262: X509Certificate last = chain[chain.length - 1]; >>> 263: X500Principal issuer = last.getIssuerX500Principal(); >>> 264: X500Principal subject = last.getSubjectX500Principal(); >> >> unused variable. > > It was there originally actually. `PKIXValidator.java` isn't being modified in this PR, I have restored it to the original state. Ok, we can clean it up in another fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2359251770 From mullan at openjdk.org Thu Sep 18 14:33:03 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 14:33:03 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v2] In-Reply-To: References: Message-ID: <9lDol2Hy2zxBd_cuOV9dYhdBvE2osDrtOAg-F5obVJA=.c68e75e1-c3e2-4978-83cd-ee31d0d96b09@github.com> On Wed, 17 Sep 2025 01:00:21 GMT, Anthony Scarpino wrote: >> Hi >> >> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: >> >> - Renamed the name of `PEMRecord` class to `PEM`. >> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. >> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > rework test & commented out code. src/java.base/share/classes/java/security/PEM.java line 40: > 38: * Mail (PEM) data by its type and Base64 content. > 39: * > 40: *

    Methods {@link PEMDecoder#decode(String)} and Suggest rewording as "The {@link PEMDecoder#decode(String)} and {@link PEMDecoder#decode(InputStream)} methods ..." src/java.base/share/classes/java/security/PEM.java line 42: > 40: *

    Methods {@link PEMDecoder#decode(String)} and > 41: * {@link PEMDecoder#decode(InputStream)} return a {@code PEM} object when no > 42: * cryptographic object is available to represent the data type. "is available" sounds a bit odd. Maybe "when the data type cannot be represented by a cryptographic object". src/java.base/share/classes/java/security/PEM.java line 43: > 41: * {@link PEMDecoder#decode(InputStream)} return a {@code PEM} object when no > 42: * cryptographic object is available to represent the data type. > 43: * If {@code PEM} is desired instead of an available cryptographic object, "available" again sounds odd, I would just remove that word. src/java.base/share/classes/java/security/PEM.java line 44: > 42: * cryptographic object is available to represent the data type. > 43: * If {@code PEM} is desired instead of an available cryptographic object, > 44: * decoding methods {@link PEMDecoder#decode(String, Class)} or s/decoding/the decoding/ src/java.base/share/classes/java/security/PEM.java line 52: > 50: * > 51: *

    When constructing a {@code PEM} instance, {@code type} and > 52: * {@code content} may not be {@code null}. s/may not/must not/ src/java.base/share/classes/java/security/PEM.java line 63: > 61: * PRIVATE KEY, ENCRYPTED PRIVATE KEY, RSA PRIVATE KEY, or PUBLIC KEY. > 62: * > 63: *

    {@code leadingData} may be null if no non-PEM data preceded PEM header Suggest rewording as "... if there was no data preceding the PEM header ..." Why do you allow null when there is a ctor that does not have a `leadingData` parameter - is there a reason for this? src/java.base/share/classes/java/security/PEM.java line 139: > 137: > 138: /** > 139: * Returns a Base64 decoded byte array of {@code content} Missing period. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359487443 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359520960 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359538618 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359525172 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359552326 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359591951 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2359603695 From weijun at openjdk.org Thu Sep 18 14:36:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 Sep 2025 14:36:18 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v5] In-Reply-To: References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: On Thu, 18 Sep 2025 09:23:15 GMT, Sean Coffey wrote: >> SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode) >> >> SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode. >> >> Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()` >> >> DebugPropertyValuesTest also updated to test new logic. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Correct old typo Since you effectively combine the message and the extra objects, the "expand" style of log is modified, from "message" : "Produced ClientHello handshake message", "specifics" : [ ... ] to "message" : "Produced ClientHello handshake message:... Although the current output is no pure legal JSON, the combination makes it worse if there are quotation marks inside the text for extra objects. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25934#issuecomment-3307810413 From myankelevich at openjdk.org Thu Sep 18 15:04:41 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 18 Sep 2025 15:04:41 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip Message-ID: * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java *test/jdk/sun/security/pkcs11/Signature/TestDSA.java ------------- Commit messages: - JDK-8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip Changes: https://git.openjdk.org/jdk/pull/27367/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27367&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367994 Stats: 140 lines in 7 files changed: 90 ins; 11 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/27367.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27367/head:pull/27367 PR: https://git.openjdk.org/jdk/pull/27367 From bperez at openjdk.org Thu Sep 18 15:25:59 2025 From: bperez at openjdk.org (Ben Perez) Date: Thu, 18 Sep 2025 15:25:59 GMT Subject: Integrated: 8365581: Optimize Java implementation of P256 arithmetic In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 01:01:01 GMT, Ben Perez wrote: > There are several places where MontgomeryIntegerPolynomialP256.mult() can be optimized. In particular, since modulus[2] = 0 several multiplications can be removed. Other multiplications can be replaced by shifts, which also saves time. Preliminary tests indicate an improvement between 5-10%. This pull request has now been integrated. Changeset: 72e5ad3d Author: Ben Perez URL: https://git.openjdk.org/jdk/commit/72e5ad3d21effff6a4efae8ab3ed45c4f6bfba76 Stats: 20 lines in 1 file changed: 1 ins; 15 del; 4 mod 8365581: Optimize Java implementation of P256 arithmetic Reviewed-by: jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/26792 From coffeys at openjdk.org Thu Sep 18 15:39:57 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 18 Sep 2025 15:39:57 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v5] In-Reply-To: References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: On Thu, 18 Sep 2025 09:23:15 GMT, Sean Coffey wrote: >> SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode) >> >> SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode. >> >> Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()` >> >> DebugPropertyValuesTest also updated to test new logic. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Correct old typo thanks Weijun. I'd missed that point. Yes- I've already tested the solution where we test for "instanceof SSLConsoleLogger" - seems to work fine, I've updated the test case also. wondering if the System Logger should attempt to print to a similar format. Will get back to you on this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25934#issuecomment-3308174304 From weijun at openjdk.org Thu Sep 18 16:27:25 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 Sep 2025 16:27:25 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:53:03 GMT, Mark Powers wrote: >> Not sure if any tests will break if we make "PBEWithHmacSHA256" the default. I'll check. >> >> If the `keystore.pkcs12.macAlgorithm` security property is **not** changed, then I believe the rule is to write the keystore as it was read, meaning a keystore with the old MAC will be written as such. Removing this "PBMAC1" check would make it impossible to do this. > > I found one and maybe two existing tests that will have to be modified if "PBEWithHmacSHA256" becomes the default. I thought we will keep the default unchanged this time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2360163072 From fferrari at openjdk.org Thu Sep 18 17:07:34 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Thu, 18 Sep 2025 17:07:34 GMT Subject: RFR: 8367782: VerifyJarEntryName.java: Fix modifyJarEntryName to operate on bytes and re-introduce verifySignatureEntryName In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:35:17 GMT, Francisco Ferrari Bihurriet wrote: > Hi, this is a second take of [JDK-8353299](https://bugs.openjdk.org/browse/JDK-8353299 "VerifyJarEntryName.java test fails") (#24337, acd4da49a01760599ec4c325ff6c56f53ba5cc9c), by making `modifyJarEntryName` operate on bytes and re-introduce `verifySignatureEntryName`. > > Please see [this JDK-8353299 comment](https://bugs.openjdk.org/browse/JDK-8353299?focusedId=14817153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14817153) for further explanation. Hi @seanjmullan, may I ask you a review for this one? I'm working on bbd5b174c50346152a624317b6bd76ec48f7e551 backports, and would like to introduce this version of the test, for better coverage and stability. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27319#issuecomment-3308591537 From mpowers at openjdk.org Thu Sep 18 17:16:26 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 18 Sep 2025 17:16:26 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 13:02:24 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> a few more comments > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1518: > >> 1516: macData = new MacData(algName, macResult, params, >> 1517: defaultMacAlgorithm().replace("PBE", ""), >> 1518: extraSalt, extraIterationCount); > > I'm not sure why you need the additional parameters (`params`, `extraSalt`, `extraIterationCount`). I think you can use the existing constructor and inside `MacData`, detect if PBMAC1 is being used by checking the algorithm name, and then encode the salt and iteration count in the PBMAC1 algorithm parameters as per RFC 7292/9579. I took your suggestion about detecting PBMAC1 via the algorithm name. Thanks. It works. The `extra*` parameters are necessary because RFC 9579 says they have to be present. | c. If the PBMAC1 algorithm is used, the macSalt value MUST be | ignored. For backwards compatibility, it SHOULD NOT be empty. | | d. If the PBMAC1 algorithm is used, the iterations value MUST be | ignored. For backwards compatibility, it SHOULD have a non- | zero positive value. Basically a PBMAC1 protected keystore contains an unused old style MAC at the end. If upgrading an old keystore to a PBMAC1 protected keystore, then it seems better to use values from the old MAC rather than make them up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2360372932 From hchao at openjdk.org Thu Sep 18 17:44:41 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Thu, 18 Sep 2025 17:44:41 GMT Subject: RFR: 8367782: VerifyJarEntryName.java: Fix modifyJarEntryName to operate on bytes and re-introduce verifySignatureEntryName In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 17:04:45 GMT, Francisco Ferrari Bihurriet wrote: >> Hi, this is a second take of [JDK-8353299](https://bugs.openjdk.org/browse/JDK-8353299 "VerifyJarEntryName.java test fails") (#24337, acd4da49a01760599ec4c325ff6c56f53ba5cc9c), by making `modifyJarEntryName` operate on bytes and re-introduce `verifySignatureEntryName`. >> >> Please see [this JDK-8353299 comment](https://bugs.openjdk.org/browse/JDK-8353299?focusedId=14817153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14817153) for further explanation. > > Hi @seanjmullan, may I ask you a review for this one? > > I'm working on bbd5b174c50346152a624317b6bd76ec48f7e551 backports, and would like to introduce this version of the test, for better coverage and stability. @franferrax Thanks for the change, which modifies exactly the byte sequence representing the entry name. Running the mach5 jobs now just to be sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27319#issuecomment-3308757164 From djelinski at openjdk.org Thu Sep 18 17:45:17 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 18 Sep 2025 17:45:17 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: <_7u8--cDXCFXH9dBDOIxXrK977Hco0wt1tujbg8diJY=.eac75161-a9a0-4e2c-84e3-aef2489e01c4@github.com> On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3241201475 From jpai at openjdk.org Thu Sep 18 17:45:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Sep 2025 17:45:18 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3241211547 From mpowers at openjdk.org Thu Sep 18 17:47:33 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 18 Sep 2025 17:47:33 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> Message-ID: <2E3FC-_KayRSbrw9QSz7tUtviaJaZNiDwkrcXQBP1sI=.1470b844-e736-48de-8e45-4009b9e33567@github.com> On Wed, 17 Sep 2025 14:37:45 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> a few more comments > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1490: > >> 1488: >> 1489: if (macAlgorithm.equals("PBMAC1") || >> 1490: defaultMacAlgorithm().startsWith("PBEWith")) { > > `calculateMac` is called when keystore is read from an existing file and `defaultMacAlgorithm` should not be used. Otherwise, algorithm will be modified. Try these: > > keytool -keystore ks -keyalg ec -storepass changeit -genkeypair -alias a -dname CN=a -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA512 > keytool -keystore ks -keyalg ec -storepass changeit -genkeypair -alias b -dname CN=b -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256 If the keystore.pkcs12.macAlgorithm security property starts with PBE then shouldn't an old MAC protected keystore be written with PBMAC1 protection? I tried those two commands and they work as expected. I did fix a few problems in the last two days so maybe I need to push those changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2360491815 From mullan at openjdk.org Thu Sep 18 18:00:54 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 18:00:54 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:24:23 GMT, Weijun Wang wrote: >> I found one and maybe two existing tests that will have to be modified if "PBEWithHmacSHA256" becomes the default. > > I thought we will keep the default unchanged this time. Yes, I take back my earlier comment. I think it is better to keep the same default for now (HmacPBESHA256), and then target changing the default to "PBEWithHmacSHA256" in JDK 27. This allows users to try out the new algorithm in JDK 26 before we switch to it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2360541359 From mpowers at openjdk.org Thu Sep 18 18:35:20 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 18 Sep 2025 18:35:20 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v4] In-Reply-To: References: Message-ID: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: comment from Sean ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24429/files - new: https://git.openjdk.org/jdk/pull/24429/files/e13d0dd2..bfb8bd22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=02-03 Stats: 35 lines in 3 files changed: 9 ins; 14 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429 PR: https://git.openjdk.org/jdk/pull/24429 From abarashev at openjdk.org Thu Sep 18 18:39:00 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 18 Sep 2025 18:39:00 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v12] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Algorithm Constraints unit test for a mixed-up and valid cert chains ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/0ac712aa..7c3031d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=10-11 Stats: 279 lines in 2 files changed: 277 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From abarashev at openjdk.org Thu Sep 18 18:39:02 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 18 Sep 2025 18:39:02 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v11] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Wed, 17 Sep 2025 21:09:55 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused import. Adjust comments. > > test/jdk/sun/security/ssl/SignatureScheme/RsaSsaPssConstraints.java line 1: > >> 1: /* > > Can you also add some tests which cause a `CertPathBuilder` to be used. i.e. via the `PKIXValidator.doBuild` method? I'd like to make sure the behavior is the same. You could try mixing up the order of the chain or throwing in a couple of unnecessary certificates. Done, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2360676865 From mullan at openjdk.org Thu Sep 18 19:25:56 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 19:25:56 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> Message-ID: On Thu, 18 Sep 2025 00:06:01 GMT, Valerie Peng wrote: >> This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods. >> >> As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear. >> >> Thanks in advance for the review~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > updated the checkTransformation() method w/ specific provider and > exception per Sean's suggestion Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26489#pullrequestreview-3241682385 From mullan at openjdk.org Thu Sep 18 19:36:14 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 19:36:14 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> Message-ID: <0B0SUWR6qiQ_di75sZ0VA8K5eGBsrDt6DCoth8p4lHE=.dc6d551a-d738-4a20-99a9-7d61e3ad5004@github.com> On Thu, 18 Sep 2025 01:29:28 GMT, Valerie Peng wrote: > Release Note is filed @ https://bugs.openjdk.org/browse/JDK-8367577 Thanks in advance for review~ Made a couple of edits but otherwise looks fine. Also, you can use markdown instead of html, if you like. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26489#issuecomment-3309325163 From weijun at openjdk.org Thu Sep 18 20:01:48 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 Sep 2025 20:01:48 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: <0B0SUWR6qiQ_di75sZ0VA8K5eGBsrDt6DCoth8p4lHE=.dc6d551a-d738-4a20-99a9-7d61e3ad5004@github.com> References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> <0B0SUWR6qiQ_di75sZ0VA8K5eGBsrDt6DCoth8p4lHE=.dc6d551a-d738-4a20-99a9-7d61e3ad5004@github.com> Message-ID: On Thu, 18 Sep 2025 19:33:27 GMT, Sean Mullan wrote: > > Release Note is filed @ https://bugs.openjdk.org/browse/JDK-8367577 Thanks in advance for review~ > > Made a couple of edits but otherwise looks fine. Also, you can use markdown instead of html, if you like. Is it common to use _italics_ instead of `fixed width` for exception types? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26489#issuecomment-3309453817 From mullan at openjdk.org Thu Sep 18 20:12:12 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 20:12:12 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 01:00:21 GMT, Anthony Scarpino wrote: >> Hi >> >> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: >> >> - Renamed the name of `PEMRecord` class to `PEM`. >> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. >> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > rework test & commented out code. src/java.base/share/classes/java/security/PEMDecoder.java line 50: > 48: * objects, such as asymmetric keys, certificates, and certificate revocation > 49: * lists (CRLs). It is defined in RFC 1421 and RFC 7468. A PEM structure > 50: * consists of Base64-encoded binary data enclosed by a type-identifying header Make the last sentence to be consistent in `PEMEncoder`. src/java.base/share/classes/java/security/PEMEncoder.java line 89: > 87: *

  • {@code EncryptedPrivateKeyInfo} : ENCRYPTED PRIVATE KEY
    • > 88: *
  • {@code KeyPair} : PRIVATE KEY
    • > 89: *
  • {@code KeyPair} (if configured with Encryption) : ENCRYPTED PRIVATE KEY Encryption should be all lower case. src/java.base/share/classes/java/security/PEMEncoder.java line 98: > 96: * > 97: * > 98: *

    This class is immutable and thread-safe. In the examples, use either "private key" or `PrivateKey`, not both. src/java.base/share/classes/java/security/PEMEncoder.java line 121: > 119: * @see EncryptedPrivateKeyInfo > 120: * > 121: * @spec https://www.rfc-editor.org/info/rfc1421 Add a spec link to PKCS#8 2.0 since you mention it above. src/java.base/share/classes/java/security/PEMEncoder.java line 265: > 263: * uses the default encryption parameters of the provider that is selected. > 264: * For greater flexibility with encryption options and parameters, use > 265: * {@link EncryptedPrivateKeyInfo#encryptKey(DEREncodable, Key, Line 256, did you mean to say "encoded" instead of "encrypted"? i.e.: "Only {@link PrivateKey} objects can be encoded with this newly ..." It makes more sense when you read the following sentence. Also the result is an encoding, the encryption is an intermediate step. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2360942020 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2360986687 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2360993760 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2360960709 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2361016203 From weijun at openjdk.org Thu Sep 18 20:23:01 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 Sep 2025 20:23:01 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> Message-ID: <5uPUlt7h-hflZ8RCT9NFZ91Jj5mIWOgTNUxecO5-2Po=.6b03732d-eb01-4e98-89be-1e53c53b5482@github.com> On Thu, 18 Sep 2025 00:06:01 GMT, Valerie Peng wrote: >> This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods. >> >> As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear. >> >> Thanks in advance for the review~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > updated the checkTransformation() method w/ specific provider and > exception per Sean's suggestion src/java.base/share/classes/javax/crypto/Cipher.java line 507: > 505: * > 506: * @throws NoSuchAlgorithmException if {@code transformation} > 507: * is {@code null}, empty, in an invalid format, Not related to this change, but do we need an "or" before "in an valid format"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2361068714 From valeriep at openjdk.org Thu Sep 18 20:43:41 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 18 Sep 2025 20:43:41 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: <5uPUlt7h-hflZ8RCT9NFZ91Jj5mIWOgTNUxecO5-2Po=.6b03732d-eb01-4e98-89be-1e53c53b5482@github.com> References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> <5uPUlt7h-hflZ8RCT9NFZ91Jj5mIWOgTNUxecO5-2Po=.6b03732d-eb01-4e98-89be-1e53c53b5482@github.com> Message-ID: On Thu, 18 Sep 2025 20:20:25 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> updated the checkTransformation() method w/ specific provider and >> exception per Sean's suggestion > > src/java.base/share/classes/javax/crypto/Cipher.java line 507: > >> 505: * >> 506: * @throws NoSuchAlgorithmException if {@code transformation} >> 507: * is {@code null}, empty, in an invalid format, > > Not related to this change, but do we need an "or" before "in an valid format"? Hmm, how about this? @throws NoSuchAlgorithmException if {@code transformation} is {@code null}, empty or in an invalid format, or if a {@code CipherSpi} implementation is not found or is found but does not support the mode ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2361142493 From abarashev at openjdk.org Thu Sep 18 20:52:31 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 18 Sep 2025 20:52:31 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v13] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Cosmetic changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/7c3031d6..d6cf0ccc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=11-12 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From mpowers at openjdk.org Thu Sep 18 21:05:39 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 18 Sep 2025 21:05:39 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v4] In-Reply-To: <4Iz9g8koaHJPZcPUq7fG0vlj4s1wjj7iQ1q09X5LCf0=.4fb5698a-4405-4efb-87ee-071b3d2a478a@github.com> References: <4Iz9g8koaHJPZcPUq7fG0vlj4s1wjj7iQ1q09X5LCf0=.4fb5698a-4405-4efb-87ee-071b3d2a478a@github.com> Message-ID: <58N7f_VK0YHN34nZGfkrc89rqw2nwE77VUYIbS7RWVI=.61f7afa1-017d-4082-af31-fc5207c3d2d7@github.com> On Tue, 16 Sep 2025 22:56:02 GMT, Mark Powers wrote: >> In fact, this will change the behavior of the Mac algorithm `PBEWithHmacSHA256` since we hardcoded `keyLength` as `blockLength` there. > > I made the check in MacData on the DER input stream instead. That said, I took Weijun's suggestion in JDK-8366979 and was able to avoid making any change to PBMAC1Core. To clarify, the check in MacData is for other HmacSHAXXX algorithms; `IllegalArgumentException` is thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2361194670 From mullan at openjdk.org Thu Sep 18 21:06:38 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 21:06:38 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> <5uPUlt7h-hflZ8RCT9NFZ91Jj5mIWOgTNUxecO5-2Po=.6b03732d-eb01-4e98-89be-1e53c53b5482@github.com> Message-ID: On Thu, 18 Sep 2025 20:41:14 GMT, Valerie Peng wrote: >> src/java.base/share/classes/javax/crypto/Cipher.java line 507: >> >>> 505: * >>> 506: * @throws NoSuchAlgorithmException if {@code transformation} >>> 507: * is {@code null}, empty, in an invalid format, >> >> Not related to this change, but do we need an "or" before "in an valid format"? > > Hmm, how about this? > > @throws NoSuchAlgorithmException if {@code transformation} > is {@code null}, empty or in an invalid format, > or if a {@code CipherSpi} implementation is not found or > is found but does not support the mode A semi-colon (instead of a comma) after "format" might also help separate the 2 main error conditions: @throws NoSuchAlgorithmException if {@code transformation} is {@code null}, empty or in an invalid format; or if a {@code CipherSpi} implementation is not found or is found but does not support the mode ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2361194887 From mullan at openjdk.org Thu Sep 18 21:18:19 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 21:18:19 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v12] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 18 Sep 2025 18:39:00 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Algorithm Constraints unit test for a mixed-up and valid cert chains test/jdk/sun/security/ssl/X509TrustManagerImpl/CertChainAlgorithmConstraints.java line 179: > 177: ex -> { > 178: assertTrue(ex instanceof ValidatorException); > 179: assertEquals(ex.getMessage(), Can you check the cause (CertPathBuilderExc) for a similar exception message as in lines 191-196? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2361215184 From abarashev at openjdk.org Thu Sep 18 21:33:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 18 Sep 2025 21:33:54 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v12] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 18 Sep 2025 21:14:24 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Algorithm Constraints unit test for a mixed-up and valid cert chains > > test/jdk/sun/security/ssl/X509TrustManagerImpl/CertChainAlgorithmConstraints.java line 179: > >> 177: ex -> { >> 178: assertTrue(ex instanceof ValidatorException); >> 179: assertEquals(ex.getMessage(), > > Can you check the cause (CertPathBuilderExc) for a similar exception message as in lines 191-196? Done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2361240125 From abarashev at openjdk.org Thu Sep 18 21:39:31 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 18 Sep 2025 21:39:31 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v14] In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Add exception's cause type check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27146/files - new: https://git.openjdk.org/jdk/pull/27146/files/d6cf0ccc..a71ba871 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27146&range=12-13 Stats: 12 lines in 1 file changed: 7 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27146/head:pull/27146 PR: https://git.openjdk.org/jdk/pull/27146 From aefimov at openjdk.org Thu Sep 18 21:56:20 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Thu, 18 Sep 2025 21:56:20 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb Marked as reviewed by aefimov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3242208335 From mullan at openjdk.org Thu Sep 18 22:00:03 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 22:00:03 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v14] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 18 Sep 2025 21:39:31 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Add exception's cause type check test/jdk/sun/security/ssl/X509TrustManagerImpl/CertChainAlgorithmConstraints.java line 183: > 181: assertTrue(ex instanceof ValidatorException); > 182: assertTrue( > 183: ex.getCause() instanceof SunCertPathBuilderException); What about the cause's message? Can you check for a constraints check failed in the message to eliminate failures due to the wrong reason? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2361275518 From abarashev at openjdk.org Thu Sep 18 22:19:20 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 18 Sep 2025 22:19:20 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v14] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: <3EUHL3Nm0yP9hHkKtD4Dghqx9JT3d8T_-5BCSLY6oiQ=.25289504-7323-453d-a08f-26b4f3f7537b@github.com> On Thu, 18 Sep 2025 21:57:24 GMT, Sean Mullan wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add exception's cause type check > > test/jdk/sun/security/ssl/X509TrustManagerImpl/CertChainAlgorithmConstraints.java line 183: > >> 181: assertTrue(ex instanceof ValidatorException); >> 182: assertTrue( >> 183: ex.getCause() instanceof SunCertPathBuilderException); > > What about the cause's message? Can you check for a constraints check failed in the message to eliminate failures due to the wrong reason? We already checking for it below, it's being appended to the outer exception's message. But I can check for it separately if it would look cleaner. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2361299384 From abarashev at openjdk.org Thu Sep 18 22:27:05 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 18 Sep 2025 22:27:05 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v14] In-Reply-To: <3EUHL3Nm0yP9hHkKtD4Dghqx9JT3d8T_-5BCSLY6oiQ=.25289504-7323-453d-a08f-26b4f3f7537b@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> <3EUHL3Nm0yP9hHkKtD4Dghqx9JT3d8T_-5BCSLY6oiQ=.25289504-7323-453d-a08f-26b4f3f7537b@github.com> Message-ID: On Thu, 18 Sep 2025 22:16:35 GMT, Artur Barashev wrote: >> test/jdk/sun/security/ssl/X509TrustManagerImpl/CertChainAlgorithmConstraints.java line 183: >> >>> 181: assertTrue(ex instanceof ValidatorException); >>> 182: assertTrue( >>> 183: ex.getCause() instanceof SunCertPathBuilderException); >> >> What about the cause's message? Can you check for a constraints check failed in the message to eliminate failures due to the wrong reason? > > We already checking for it below, it's being appended to the outer exception's message. But I can check for it separately if it would look cleaner. SunCertPathBuilder doesn't attach any cause itself: https://github.com/openjdk/jdk/blob/6e4e966d9b71ec04618e19784b5a661f34595ef6/src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java#L148 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2361308521 From mullan at openjdk.org Thu Sep 18 22:40:55 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 22:40:55 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v14] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: On Thu, 18 Sep 2025 21:39:31 GMT, Artur Barashev wrote: >> RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Add exception's cause type check Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27146#pullrequestreview-3242276648 From mullan at openjdk.org Thu Sep 18 22:40:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 18 Sep 2025 22:40:57 GMT Subject: RFR: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints [v14] In-Reply-To: References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> <3EUHL3Nm0yP9hHkKtD4Dghqx9JT3d8T_-5BCSLY6oiQ=.25289504-7323-453d-a08f-26b4f3f7537b@github.com> Message-ID: On Thu, 18 Sep 2025 22:24:29 GMT, Artur Barashev wrote: >> We already checking for it below, it's being appended to the outer exception's message. But I can check for it separately if it would look cleaner. > > SunCertPathBuilder doesn't attach any cause itself: > https://github.com/openjdk/jdk/blob/6e4e966d9b71ec04618e19784b5a661f34595ef6/src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java#L148 Ah ok. Yes, in that case you would have to parse the debug log to find the underlying reason, but I'm ok with this as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27146#discussion_r2361323502 From hchao at openjdk.org Fri Sep 19 00:33:49 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 19 Sep 2025 00:33:49 GMT Subject: RFR: 8367782: VerifyJarEntryName.java: Fix modifyJarEntryName to operate on bytes and re-introduce verifySignatureEntryName In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:35:17 GMT, Francisco Ferrari Bihurriet wrote: > Hi, this is a second take of [JDK-8353299](https://bugs.openjdk.org/browse/JDK-8353299 "VerifyJarEntryName.java test fails") (#24337, acd4da49a01760599ec4c325ff6c56f53ba5cc9c), by making `modifyJarEntryName` operate on bytes and re-introduce `verifySignatureEntryName`. > > Please see [this JDK-8353299 comment](https://bugs.openjdk.org/browse/JDK-8353299?focusedId=14817153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14817153) for further explanation. Marked as reviewed by hchao (Reviewer). Changes look good. Thanks. ------------- PR Review: https://git.openjdk.org/jdk/pull/27319#pullrequestreview-3242407562 PR Comment: https://git.openjdk.org/jdk/pull/27319#issuecomment-3310094360 From hchao at openjdk.org Fri Sep 19 00:33:50 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 19 Sep 2025 00:33:50 GMT Subject: RFR: 8367782: VerifyJarEntryName.java: Fix modifyJarEntryName to operate on bytes and re-introduce verifySignatureEntryName In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 17:04:45 GMT, Francisco Ferrari Bihurriet wrote: >> Hi, this is a second take of [JDK-8353299](https://bugs.openjdk.org/browse/JDK-8353299 "VerifyJarEntryName.java test fails") (#24337, acd4da49a01760599ec4c325ff6c56f53ba5cc9c), by making `modifyJarEntryName` operate on bytes and re-introduce `verifySignatureEntryName`. >> >> Please see [this JDK-8353299 comment](https://bugs.openjdk.org/browse/JDK-8353299?focusedId=14817153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14817153) for further explanation. > > Hi @seanjmullan, may I ask you a review for this one? > > I'm working on bbd5b174c50346152a624317b6bd76ec48f7e551 backports, and would like to introduce this version of the test, for better coverage and stability. > @franferrax Thanks for the change, which modifies exactly the byte sequence representing the entry name. Running the mach5 jobs now just to be sure. Mach5 jobs ran fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27319#issuecomment-3310093197 From iklam at openjdk.org Fri Sep 19 01:38:25 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 01:38:25 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class - @ashu-mehra review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @DanHeidinga comments -- added comments and asserts about the handling of enums - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=07 Stats: 903 lines in 43 files changed: 498 ins; 212 del; 193 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Fri Sep 19 01:44:26 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 01:44:26 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: References: Message-ID: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> On Fri, 19 Sep 2025 01:38:25 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes > - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class > - @ashu-mehra review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 @ashu-mehra , I've remove all the code that was needed to handle aot-linked classes from the dynamic archive but is no longer needed since [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). I am able to remove about 200 lines of code. I also renamed a few functions in `AOTLinkedClassBulkLoader` to reflect the up-to-date meaning. `CDSConfig::is_using_preloaded_classes()` has been removed and replaced with `CDSConfig::is_using_aot_linked_classes()` The handling of `fixup_mirror_list()` and `fixup_module_field_list()` in javaClasses.cpp have been made uniform. Please see https://github.com/openjdk/jdk/pull/26375/commits/896ce8b9636a5534f1db487afbe27e875022fbfa ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3310193834 From mpowers at openjdk.org Fri Sep 19 02:25:18 2025 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 19 Sep 2025 02:25:18 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> Message-ID: On Wed, 17 Sep 2025 14:32:56 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 180: >> >>> 178: private int macSaltLength = -1; >>> 179: private byte[] extraSalt = null; >>> 180: private int extraIterationCount = -1; >> >> I don't think it's necessary to break the user-provided mac algorithm like "PBEWithHmacSHA256" into `macAlgorithm == "PBMAC1"` and `pbmac1Hmac == "HmacSHA256"`. Keep a single one no matter what kind of mac algorithm it is. > > How necessary is it to remember `macSaltLength`? Before this change, we always generate a new salt of 20 bytes without looking at the old one. Also, what about `extraSalt`, and `extraIterationCount`? Since they are useless for PBMAC1, why cannot we just always hardcode them in the encoding? Imagine reading a PBMAC1 protected keystore with a 32 byte salt. Now it's time to write it out. You have to remember the salt length of whatever PBMAC1 you just read in order to generate a new salt of the same length. It doesn't seem right to always generate 20 bytes of salt. We could hardcode the extras, but it seems better to me to return the original values if you're upgrading an old MAC protected keystore to a PBMAC1 protected keystore. It's is a nice touch but the code complexity might not be worth it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2361550737 From iklam at openjdk.org Fri Sep 19 04:46:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 04:46:13 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed 32-bit builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/04cb7a64..9ec10f5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=07-08 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From syan at openjdk.org Fri Sep 19 05:50:18 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 19 Sep 2025 05:50:18 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 14:56:13 GMT, Mikhail Yankelevich wrote: > * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java > * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java > * test/jdk/sun/security/pkcs11/Signature/TestDSA.java test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 49: > 47: * @test id=new_alg > 48: * @bug 8080462 8226651 8242332 > 49: * @summary Generate a RSASSA-PSS signature and verify it using PKCS11 provider Should we need comments why this test was splited to two tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2361838585 From djelinski at openjdk.org Fri Sep 19 08:43:54 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 19 Sep 2025 08:43:54 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode Message-ID: Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. ------------- Commit messages: - Add bug ID - Try to use a CKO_DATA object if secret creation fails Changes: https://git.openjdk.org/jdk/pull/27384/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27384&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368073 Stats: 99 lines in 3 files changed: 68 ins; 15 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/27384.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27384/head:pull/27384 PR: https://git.openjdk.org/jdk/pull/27384 From coffeys at openjdk.org Fri Sep 19 10:23:58 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 19 Sep 2025 10:23:58 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v6] In-Reply-To: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: > SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode) > > SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode. > > Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()` > > DebugPropertyValuesTest also updated to test new logic. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Retain use of specific field in SSLConsoleLogger formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25934/files - new: https://git.openjdk.org/jdk/pull/25934/files/82c5427b..bb0df658 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25934&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25934&range=04-05 Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25934/head:pull/25934 PR: https://git.openjdk.org/jdk/pull/25934 From fferrari at openjdk.org Fri Sep 19 10:27:00 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Fri, 19 Sep 2025 10:27:00 GMT Subject: Integrated: 8367782: VerifyJarEntryName.java: Fix modifyJarEntryName to operate on bytes and re-introduce verifySignatureEntryName In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:35:17 GMT, Francisco Ferrari Bihurriet wrote: > Hi, this is a second take of [JDK-8353299](https://bugs.openjdk.org/browse/JDK-8353299 "VerifyJarEntryName.java test fails") (#24337, acd4da49a01760599ec4c325ff6c56f53ba5cc9c), by making `modifyJarEntryName` operate on bytes and re-introduce `verifySignatureEntryName`. > > Please see [this JDK-8353299 comment](https://bugs.openjdk.org/browse/JDK-8353299?focusedId=14817153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14817153) for further explanation. This pull request has now been integrated. Changeset: 1b9a1168 Author: Francisco Ferrari Bihurriet URL: https://git.openjdk.org/jdk/commit/1b9a11682d5f73885213822423bfce8dfc17febd Stats: 27 lines in 1 file changed: 22 ins; 0 del; 5 mod 8367782: VerifyJarEntryName.java: Fix modifyJarEntryName to operate on bytes and re-introduce verifySignatureEntryName Reviewed-by: hchao ------------- PR: https://git.openjdk.org/jdk/pull/27319 From michaelm at openjdk.org Fri Sep 19 11:19:39 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 19 Sep 2025 11:19:39 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb I have reviewed the version independent changes only. They look fine to me. ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3244405763 From coffeys at openjdk.org Fri Sep 19 12:08:14 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 19 Sep 2025 12:08:14 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v7] In-Reply-To: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: <6aeZNoHPG24z2Td0KyX6YTb8LREWSQo6hg8iBB4_kxQ=.020390ef-2308-484c-a2a6-37bb898a0ba4@github.com> > SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode) > > SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode. > > Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()` > > DebugPropertyValuesTest also updated to test new logic. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Avoid Supplier API call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25934/files - new: https://git.openjdk.org/jdk/pull/25934/files/bb0df658..beba07b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25934&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25934&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25934/head:pull/25934 PR: https://git.openjdk.org/jdk/pull/25934 From abarashev at openjdk.org Fri Sep 19 13:10:17 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 19 Sep 2025 13:10:17 GMT Subject: Integrated: 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints In-Reply-To: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> References: <-ktkkQJsXjbgQRB1NwGvNiCB9S0mnnzghSiIq3pHSDs=.73a23f09-d177-4fac-8f1a-a67b88a4f0d1@github.com> Message-ID: <_8q6B_zcLiqAwcVkBSmD8rPJ42XhRxQ_qlGdo9moJ2M=.eac4ef7a-75d2-413f-93c6-0a3b72f7cf31@github.com> On Mon, 8 Sep 2025 15:31:44 GMT, Artur Barashev wrote: > RSASSA-PSS is currently the only signature algorithm we support that comes with algorithm parameters. We don't check for those parameters when validating certificates against supported signature algorithm constraints. This pull request has now been integrated. Changeset: 3798dcf7 Author: Artur Barashev URL: https://git.openjdk.org/jdk/commit/3798dcf75b547a3707cdfdacf62886648c8653cf Stats: 852 lines in 12 files changed: 686 ins; 108 del; 58 mod 8367104: Check for RSASSA-PSS parameters when validating certificates against algorithm constraints Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/27146 From fferrari at openjdk.org Fri Sep 19 13:48:03 2025 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Fri, 19 Sep 2025 13:48:03 GMT Subject: RFR: 8367782: VerifyJarEntryName.java: Fix modifyJarEntryName to operate on bytes and re-introduce verifySignatureEntryName In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 00:31:30 GMT, Hai-May Chao wrote: >> Hi, this is a second take of [JDK-8353299](https://bugs.openjdk.org/browse/JDK-8353299 "VerifyJarEntryName.java test fails") (#24337, acd4da49a01760599ec4c325ff6c56f53ba5cc9c), by making `modifyJarEntryName` operate on bytes and re-introduce `verifySignatureEntryName`. >> >> Please see [this JDK-8353299 comment](https://bugs.openjdk.org/browse/JDK-8353299?focusedId=14817153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14817153) for further explanation. > > Changes look good. Thanks. Thank you very much @haimaychao for the review and the testing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27319#issuecomment-3312263088 From fitzsim at openjdk.org Fri Sep 19 14:24:37 2025 From: fitzsim at openjdk.org (Thomas Fitzsimmons) Date: Fri, 19 Sep 2025 14:24:37 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v4] In-Reply-To: References: Message-ID: <7dxEWLWFzXpyG95XoS_iESgQtQOBp_LH36DqUUpXQ3Y=.7c523f70-97e4-4c9c-b826-f0852f015f45@github.com> On Thu, 18 Sep 2025 18:35:20 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > comment from Sean So far, I just have the one question about the necessity of the keyLength check. ------------- PR Review: https://git.openjdk.org/jdk/pull/24429#pullrequestreview-3236345589 From fitzsim at openjdk.org Fri Sep 19 14:24:40 2025 From: fitzsim at openjdk.org (Thomas Fitzsimmons) Date: Fri, 19 Sep 2025 14:24:40 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 23:03:00 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > a few more comments src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 173: > 171: if (keyLength > 0) { > 172: pBKDF2_params.putInteger(keyLength / 8); // derived key length (in octets) > 173: } I think `keyLength` is a MUST here. Maybe this should instead check if `keyLength` is `<= 0`, and if so, throw an exception. Then proceed to encode `keyLength` unconditionally. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2356839298 From weijun at openjdk.org Fri Sep 19 16:37:45 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Sep 2025 16:37:45 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v7] In-Reply-To: <6aeZNoHPG24z2Td0KyX6YTb8LREWSQo6hg8iBB4_kxQ=.020390ef-2308-484c-a2a6-37bb898a0ba4@github.com> References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> <6aeZNoHPG24z2Td0KyX6YTb8LREWSQo6hg8iBB4_kxQ=.020390ef-2308-484c-a2a6-37bb898a0ba4@github.com> Message-ID: On Fri, 19 Sep 2025 12:08:14 GMT, Sean Coffey wrote: >> SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode) >> >> SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode. >> >> Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()` >> >> DebugPropertyValuesTest also updated to test new logic. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Avoid Supplier API call Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25934#pullrequestreview-3245803599 From weijun at openjdk.org Fri Sep 19 18:08:54 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Sep 2025 18:08:54 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> Message-ID: On Fri, 19 Sep 2025 02:22:55 GMT, Mark Powers wrote: >> How necessary is it to remember `macSaltLength`? Before this change, we always generate a new salt of 20 bytes without looking at the old one. Also, what about `extraSalt`, and `extraIterationCount`? Since they are useless for PBMAC1, why cannot we just always hardcode them in the encoding? > > Imagine reading a PBMAC1 protected keystore with a 32 byte salt. Now it's time to write it out. You have to remember the salt length of whatever PBMAC1 you just read in order to generate a new salt of the same length. It doesn't seem right to always generate 20 bytes of salt. > > We could hardcode the extras, but it seems better to me to return the original values if you're upgrading an old MAC protected keystore to a PBMAC1 protected keystore. It's is a nice touch but the code complexity might not be worth it. You do have a point here, but we have always been rewriting salt with a possible different length. We can discuss this in another issue, but the change is not necessary here, especially it also affects other old Mac algorithms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2363976542 From mullan at openjdk.org Fri Sep 19 18:30:12 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 19 Sep 2025 18:30:12 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v4] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 18:35:20 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > comment from Sean src/java.base/share/classes/sun/security/pkcs12/MacData.java line 92: > 90: if (digestInfo[0].tag != DerValue.tag_Sequence) { > 91: throw new IOException("algid parse error, not a sequence"); > 92: } This check is not necessary, it was already checked by `AlgorithmId.parse` on line 83. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 105: > 103: } > 104: iterations = pbeSpec.getIterationCount(); > 105: macSalt = pbeSpec.getSalt(); Nit, use `this` for class fields (`this.iterations`, `this.macSalt`, etc) to keep method code consistent and helps distinguish from local variables. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 110: > 108: if (!(kdfHmac.equals("HmacSHA512") || > 109: kdfHmac.equals("HmacSHA256"))) { > 110: throw new IllegalArgumentException("unsupported PBMAC1 Hmac"); Hmm. I don't think we need to limit the algorithms we support on loading. It is more about when storing new keystores since the current PBMAC1 algorithm syntax doesn't allow a mix of different Mac/Prf algs. Also,`engineLoad` is not defined to throw `IllegalArgumentException`, so if this is still needed, then `IOException` is probably more appropriate. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 117: > 115: > 116: // Get the old salt. > 117: extraSalt = macData[1].getOctetString(); Do we need the `extraSalt` and `extraIterations` variables? What if you just put an `else` block here (if not PBMAC1) and then fill in the `macSalt` and `iterations`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2363905086 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2363978712 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2364032921 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2364043024 From asmehra at openjdk.org Fri Sep 19 18:41:00 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 18:41:00 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> References: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> Message-ID: On Fri, 19 Sep 2025 01:41:34 GMT, Ioi Lam wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: >> >> - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes >> - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 > > @ashu-mehra , I've remove all the code that was needed to handle aot-linked classes from the dynamic archive but is no longer needed since [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). I am able to remove about 200 lines of code. > > I also renamed a few functions in `AOTLinkedClassBulkLoader` to reflect the up-to-date meaning. > > `CDSConfig::is_using_preloaded_classes()` has been removed and replaced with `CDSConfig::is_using_aot_linked_classes()` > > The handling of `fixup_mirror_list()` and `fixup_module_field_list()` in javaClasses.cpp have been made uniform. > > Please see https://github.com/openjdk/jdk/pull/26375/commits/896ce8b9636a5534f1db487afbe27e875022fbfa @iklam thank you for updating the changes. It is much easier to follow the code now. I have just one additional comment, otherwise looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3313363526 From asmehra at openjdk.org Fri Sep 19 18:41:03 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 18:41:03 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 04:46:13 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed 32-bit builds src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 184: > 182: > 183: void AOTLinkedClassBulkLoader::link_or_init_javabase_classes(TRAPS) { > 184: link_or_init_classes_for_loader(Handle(), AOTLinkedClassTable::get()->boot1(), CHECK); Is exception check not needed here, like it is done in `link_or_init_non_javabase_classes()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2364073186 From iklam at openjdk.org Sat Sep 20 00:57:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 00:57:09 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/9ec10f5f..9072a1df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=08-09 Stats: 20 lines in 3 files changed: 14 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Sat Sep 20 00:57:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 00:57:12 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 18:35:36 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed 32-bit builds > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 184: > >> 182: >> 183: void AOTLinkedClassBulkLoader::link_or_init_javabase_classes(TRAPS) { >> 184: link_or_init_classes_for_loader(Handle(), AOTLinkedClassTable::get()->boot1(), CHECK); > > Is exception check not needed here, like it is done in `link_or_init_non_javabase_classes()`? I changed this function to do the same check as in `link_or_init_non_javabase_classes()`. I also updated the comments to explain why this is necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2364925599 From mpowers at openjdk.org Sat Sep 20 13:21:19 2025 From: mpowers at openjdk.org (Mark Powers) Date: Sat, 20 Sep 2025 13:21:19 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v4] In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 19:47:57 GMT, Mark Powers wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 231: >> >>> 229: >>> 230: var kdfParams = new PBKDF2Parameters(); >>> 231: String kdfAlgo = kdfParams.parseKDF(kdf); >> >> nit: `parseKDF()` seems a bit redundant as the KDF name is already in the class name, i.e. `PBKDF2Parameter`. Maybe name it `init()` as this is what it does, i.e. initialize the `PBKDF2Parameters` obj w/ the `DerValue` argument. > > fixed After more review comments, this was replaced with a `PBKDF2Parameters(kdf)` constructor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2365627350 From mpowers at openjdk.org Sat Sep 20 21:55:36 2025 From: mpowers at openjdk.org (Mark Powers) Date: Sat, 20 Sep 2025 21:55:36 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v5] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 22:55:17 GMT, Mark Powers wrote: >> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 156: >> >>> 154: DerValue kdf = pBMAC1_params.data.getDerValue(); >>> 155: var kdfParams = new PBKDF2Parameters(); >>> 156: String kdfAlgo = kdfParams.init(kdf); >> >> Hmm, it's somewhat obscure to return the prf algorithm as the result of `PBKDF2Parameters.init(...) `call. >> Is there a reason for a separate `init(...)` call? How about just `PBKDF2Parameters(kdf)` and retrieve the `prfAlgo` (instead of the "kdfAlgo" name) separately just like `salt`, `iCount` and `keyLength`? > > This has been changed to `PBKDF2Parameters(kdf) `by an earlier comment. Are you suggesting to change `kdfAlgo` to `prfAlgo` or something else? changed `kdfAlgo` to `prfAlgo`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2365842311 From mpowers at openjdk.org Sat Sep 20 21:55:39 2025 From: mpowers at openjdk.org (Mark Powers) Date: Sat, 20 Sep 2025 21:55:39 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v4] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 17:43:41 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> comment from Sean > > src/java.base/share/classes/sun/security/pkcs12/MacData.java line 92: > >> 90: if (digestInfo[0].tag != DerValue.tag_Sequence) { >> 91: throw new IOException("algid parse error, not a sequence"); >> 92: } > > This check is not necessary, it was already checked by `AlgorithmId.parse` on line 83. You are right. The check has been removed. > src/java.base/share/classes/sun/security/pkcs12/MacData.java line 105: > >> 103: } >> 104: iterations = pbeSpec.getIterationCount(); >> 105: macSalt = pbeSpec.getSalt(); > > Nit, use `this` for class fields (`this.iterations`, `this.macSalt`, etc) to keep method code consistent and helps distinguish from local variables. fixed > src/java.base/share/classes/sun/security/pkcs12/MacData.java line 110: > >> 108: if (!(kdfHmac.equals("HmacSHA512") || >> 109: kdfHmac.equals("HmacSHA256"))) { >> 110: throw new IllegalArgumentException("unsupported PBMAC1 Hmac"); > > Hmm. I don't think we need to limit the algorithms we support on loading. It is more about when storing new keystores since the current PBMAC1 algorithm syntax doesn't allow a mix of different Mac/Prf algs. > > Also,`engineLoad` is not defined to throw `IllegalArgumentException`, so if this is still needed, then `IOException` is probably more appropriate. We don't have a `PBMAC1ParameterSpec` to pass key length from `PBMAC1Parameters` to `PKCS12KeyStore`. By the time you get to `PKCS12KeyStore`, the only hint for key length is the suffix on the Hmac. I think we need this check, otherwise we will end up with a not very useful "failed PKCS12 integrity checking" message. I'll change `IllegalArgumentException` to `IOException`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2365842435 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2365842471 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2365842488 From mpowers at openjdk.org Sat Sep 20 21:55:35 2025 From: mpowers at openjdk.org (Mark Powers) Date: Sat, 20 Sep 2025 21:55:35 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v5] In-Reply-To: References: Message-ID: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: a few more comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24429/files - new: https://git.openjdk.org/jdk/pull/24429/files/bfb8bd22..32b56a6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=03-04 Stats: 48 lines in 4 files changed: 0 ins; 3 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/24429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429 PR: https://git.openjdk.org/jdk/pull/24429 From wenanjian at openjdk.org Sun Sep 21 00:50:18 2025 From: wenanjian at openjdk.org (Anjian Wen) Date: Sun, 21 Sep 2025 00:50:18 GMT Subject: RFR: 8365732: RISC-V: implement AES CTR intrinsics [v7] In-Reply-To: References: Message-ID: <6-c0fA19VDBsLUwN2ewcYQ_bPSD7Zt6h5lsIOhTMGpk=.80f0aca5-601b-48dd-9c0e-c79612976da9@github.com> On Fri, 19 Sep 2025 07:09:27 GMT, Fei Yang wrote: >> Anjian Wen 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 aes_ctr >> - fix the counter increase at limit and add test >> - change format >> - update reg use and instruction >> - change some name and format >> - delete useless Label, change L_judge_used to L_slow_loop >> - add Flags and fix the stubid name >> - RISC-V: implement AES-CTR mode intrinsics > > src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2667: > >> 2665: __ addi(t0, counter, 8); >> 2666: __ ld(tmp, Address(t0)); >> 2667: __ rev8(tmp, tmp); > > Note that `rev8` is only available under `UseZbb`. Maybe you should use `revb/revbw` instead which considers that the availability of Zbb extension. I used the zbb and zvbb instructions in my patch?which seem not easy to replace in vector operations, and there are some optimizations when using them, so I think we may add a extension check in vm_version_riscv.cpp? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25281#discussion_r2365883933 From wenanjian at openjdk.org Sun Sep 21 00:57:40 2025 From: wenanjian at openjdk.org (Anjian Wen) Date: Sun, 21 Sep 2025 00:57:40 GMT Subject: RFR: 8365732: RISC-V: implement AES CTR intrinsics [v9] In-Reply-To: References: Message-ID: > Hi everyone, please help review this patch which Implement the _counterMode_AESCrypt with Zvkned. On my QEMU, with Zvkned extension enabled, the tests in test/hotspot/jtreg/compiler/codegen/aes/ Passed. Anjian Wen has updated the pull request incrementally with one additional commit since the last revision: add zbb and zvbb check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25281/files - new: https://git.openjdk.org/jdk/pull/25281/files/35f82e0a..529f7cf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25281&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25281&range=07-08 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25281/head:pull/25281 PR: https://git.openjdk.org/jdk/pull/25281 From dfuchs at openjdk.org Sun Sep 21 09:10:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Sun, 21 Sep 2025 09:10:54 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v19] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 661 commits: - http3: add null check in SSLAlgorithmConstraints::forQUIC - merge latest changes from master branch - merge latest changes from master branch - merge latest changes from master branch - http3: CSR review feedback - merge latest changes from master branch - modify http3 test timeouts - qpack - take knownReceivedCount into account during DT entries eviction - merge latest changes from master branch - http3: fix at since - ... and 651 more: https://git.openjdk.org/jdk/compare/54206943...797d797c ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=18 Stats: 105840 lines in 474 files changed: 103005 ins; 1337 del; 1498 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From jpai at openjdk.org Sun Sep 21 09:43:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 21 Sep 2025 09:43:39 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v19] In-Reply-To: References: Message-ID: On Sun, 21 Sep 2025 09:10:54 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 661 commits: > > - http3: add null check in SSLAlgorithmConstraints::forQUIC > - merge latest changes from master branch > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - ... and 651 more: https://git.openjdk.org/jdk/compare/54206943...797d797c The updates look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3249956734 From aefimov at openjdk.org Sun Sep 21 09:57:38 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Sun, 21 Sep 2025 09:57:38 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v19] In-Reply-To: References: Message-ID: On Sun, 21 Sep 2025 09:10:54 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 661 commits: > > - http3: add null check in SSLAlgorithmConstraints::forQUIC > - merge latest changes from master branch > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - ... and 651 more: https://git.openjdk.org/jdk/compare/54206943...797d797c Marked as reviewed by aefimov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3249960698 From mpowers at openjdk.org Sun Sep 21 19:29:23 2025 From: mpowers at openjdk.org (Mark Powers) Date: Sun, 21 Sep 2025 19:29:23 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v4] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 18:27:25 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> comment from Sean > > src/java.base/share/classes/sun/security/pkcs12/MacData.java line 117: > >> 115: >> 116: // Get the old salt. >> 117: extraSalt = macData[1].getOctetString(); > > Do we need the `extraSalt` and `extraIterations` variables? What if you just put an `else` block here (if not PBMAC1) and then fill in the `macSalt` and `iterations`. Weijun has a similar concern. I've remove `extraSalt` and `extraIterationCount`. I no longer think it's worth the complexity to keep these. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2366359699 From mpowers at openjdk.org Sun Sep 21 20:16:07 2025 From: mpowers at openjdk.org (Mark Powers) Date: Sun, 21 Sep 2025 20:16:07 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v6] In-Reply-To: References: Message-ID: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: remove the extras ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24429/files - new: https://git.openjdk.org/jdk/pull/24429/files/32b56a6c..e190920c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=04-05 Stats: 45 lines in 2 files changed: 1 ins; 35 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/24429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429 PR: https://git.openjdk.org/jdk/pull/24429 From mpowers at openjdk.org Sun Sep 21 21:01:15 2025 From: mpowers at openjdk.org (Mark Powers) Date: Sun, 21 Sep 2025 21:01:15 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> Message-ID: <-1qU853IFYoMNSdy99BazkMttxBFvthdTMUA6H9cKB0=.3a84ec09-78f2-4b80-8035-d7e7e7a090e7@github.com> On Fri, 19 Sep 2025 18:06:14 GMT, Weijun Wang wrote: >> Imagine reading a PBMAC1 protected keystore with a 32 byte salt. Now it's time to write it out. You have to remember the salt length of whatever PBMAC1 you just read in order to generate a new salt of the same length. It doesn't seem right to always generate 20 bytes of salt. >> >> We could hardcode the extras, but it seems better to me to return the original values if you're upgrading an old MAC protected keystore to a PBMAC1 protected keystore. It's is a nice touch but the code complexity might not be worth it. > > You do have a point here, but we have always been rewriting salt with a possible different length. We can discuss this in another issue, but the change is not necessary here, especially it also affects other old Mac algorithms. Are you suggesting to always generate a 20 byte salt? Can you provide a line number for your first comment about breaking up "PBEWithHmacSHA256"? This string is read from the property file and has nothing to do with any DER encoded values read from the keystore input stream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2366391247 From mpowers at openjdk.org Sun Sep 21 21:43:20 2025 From: mpowers at openjdk.org (Mark Powers) Date: Sun, 21 Sep 2025 21:43:20 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> Message-ID: On Wed, 17 Sep 2025 14:38:52 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> a few more comments > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1495: > >> 1493: } else if (defaultMacAlgorithm().equals("PBEWithHmacSHA256")) { >> 1494: kdfHmac = "HmacSHA256"; >> 1495: } else { > > Why don't we support `PBEWithHmacSHA384` etc? SHA256 is the minimum required by RFC 9879 so that's the goal for this integration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2366405150 From djelinski at openjdk.org Mon Sep 22 07:24:06 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 22 Sep 2025 07:24:06 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v19] In-Reply-To: References: Message-ID: On Sun, 21 Sep 2025 09:10:54 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 661 commits: > > - http3: add null check in SSLAlgorithmConstraints::forQUIC > - merge latest changes from master branch > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - ... and 651 more: https://git.openjdk.org/jdk/compare/54206943...797d797c Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3250922345 From hchao at openjdk.org Mon Sep 22 08:23:06 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Mon, 22 Sep 2025 08:23:06 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v6] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:24:05 GMT, Artur Barashev wrote: >> [JDK-8349583](https://bugs.openjdk.org/browse/JDK-8349583) implementation assumes that OpenJDK client always sends "signature_algorithms_cert" extension together with "signature_algorithms" extension. But we didn't account for `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties which can disable producing "signature_algorithms_cert" extension. This is an issue similar to [JDK-8355779](https://bugs.openjdk.org/browse/JDK-8355779) but on the extension producing side. >> >> Per TLSv1.3 RFC: >> >>> If no "signature_algorithms_cert" extension is >>> present, then the "signature_algorithms" extension also applies to >>> signatures appearing in certificates. >> >> Also making a few cosmetic changes to the existing code. > > 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 eight additional commits since the last revision: > > - Add a ticket number to unit tests > - Merge branch 'master' into JDK-8365820 > - Add a server-side unit test. Rename existing tests. > - Update tests > - Revert "Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3" > > This reverts commit adc236be4bcac11614e2741c99545aa593f6af5b. > - Merge branch 'master' into JDK-8365820 > - Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3 > - 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent test/jdk/sun/security/ssl/SignatureScheme/DisableCertSignAlgsExtForServerTLS13.java line 131: > 129: // instead, depends on network setup. > 130: || ex instanceof SocketException)); > 131: } Here for TLS 1.3, handshake always fails because SHA256withRSA is not allowed for client certificates. Would you consider adding a positive test for TLS 1.3 with a client certificate signed with RSASSA-PSS so we could test handshake will succeed as the client complies? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26887#discussion_r2367086905 From alanb at openjdk.org Mon Sep 22 08:32:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 08:32:19 GMT Subject: RFR: 8368226: Remove Thread.stop Message-ID: The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/27419/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27419&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368226 Stats: 342 lines in 6 files changed: 0 ins; 334 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27419/head:pull/27419 PR: https://git.openjdk.org/jdk/pull/27419 From vklang at openjdk.org Mon Sep 22 09:31:06 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 22 Sep 2025 09:31:06 GMT Subject: RFR: 8368226: Remove Thread.stop In-Reply-To: References: Message-ID: <-H8bhWp5KoPYtcdIoZOmrG1GqP0i4KNdK1GzA-zNpZU=.0e6eea68-12fb-4322-977c-18c7694ab89b@github.com> On Mon, 22 Sep 2025 08:13:55 GMT, Alan Bateman wrote: > The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. > > Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. > > Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. And so the time has finally come. ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27419#pullrequestreview-3251400317 From coffeys at openjdk.org Mon Sep 22 10:08:43 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 22 Sep 2025 10:08:43 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v2] In-Reply-To: References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: On Wed, 25 Jun 2025 22:08:37 GMT, Mikhail Yankelevich wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Text Blocks use \n by default > > src/java.base/share/classes/sun/security/ssl/Utilities.java line 154: > >> 152: StringBuilder builder = new StringBuilder(); >> 153: if (source == null) { >> 154: builder.append(LINE_SEP).append(prefix).append(""); > > I don't think this ls covered by the test. Could you please add an empty case to cover this? @myankelev I didn't see any code in the JDK calling this method with `source == null`. Other than hacking into the internals of SSLLogger to force the method call, I'm not sure it can be covered. Would you be ok to log a follow on task/bug if you feel coverage of this corner case is warranted ? Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25934#discussion_r2367410113 From dfuchs at openjdk.org Mon Sep 22 10:16:00 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 22 Sep 2025 10:16:00 GMT Subject: Integrated: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 13:05:24 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. This pull request has now been integrated. Changeset: e8db14f5 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/e8db14f584fa92db170e056bc68074ccabae82c9 Stats: 105840 lines in 474 files changed: 103005 ins; 1337 del; 1498 mod 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API Co-authored-by: Aleksei Efimov Co-authored-by: Bradford Wetmore Co-authored-by: Daniel Jeli?ski Co-authored-by: Darragh Clarke Co-authored-by: Jaikiran Pai Co-authored-by: Michael McMahon Co-authored-by: Volkan Yazici Co-authored-by: Conor Cleary Co-authored-by: Patrick Concannon Co-authored-by: Rahul Yadav Co-authored-by: Daniel Fuchs Reviewed-by: djelinski, jpai, aefimov, abarashev, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/24751 From myankelevich at openjdk.org Mon Sep 22 11:34:23 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 22 Sep 2025 11:34:23 GMT Subject: RFR: 8368226: Remove Thread.stop In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 08:13:55 GMT, Alan Bateman wrote: > The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. > > Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. > > Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. test/jdk/sun/security/krb5/auto/KDC.java line 1651: > 1649: thread1.interrupt(); > 1650: thread2.interrupt(); > 1651: thread3.interrupt(); I don't this won't work in this test. The full change in in the pr here https://github.com/openjdk/jdk/pull/26247. There should be no conflict as far as I can see, so just noting it here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27419#discussion_r2367824447 From alanb at openjdk.org Mon Sep 22 12:09:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 12:09:05 GMT Subject: RFR: 8368226: Remove Thread.stop In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:31:10 GMT, Mikhail Yankelevich wrote: >> The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. >> >> Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. >> >> Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. > > test/jdk/sun/security/krb5/auto/KDC.java line 1651: > >> 1649: thread1.interrupt(); >> 1650: thread2.interrupt(); >> 1651: thread3.interrupt(); > > I don't this won't work in this test. The full change in in the pr here https://github.com/openjdk/jdk/pull/26247. > > There should be no conflict as far as I can see, so just noting it here I created JDK-8360979 a few months ago to get KDC fixed. The above is, as I said, temporary and would be good to get JDK-8360979 reviewed/integrated before this. removal. Right now, the successful execution of the Kerberos and DTLS tests do no rely on this, the cleanup has been throwing UOE for several years and has not been noticed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27419#discussion_r2367993000 From jpai at openjdk.org Mon Sep 22 12:40:19 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 22 Sep 2025 12:40:19 GMT Subject: RFR: 8368226: Remove Thread.stop In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 08:13:55 GMT, Alan Bateman wrote: > The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. > > Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. > > Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. This looks good to me. `ThreadDeath.java` and `KDC.java` would need a copyright year update. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27419#pullrequestreview-3252478987 From myankelevich at openjdk.org Mon Sep 22 12:54:30 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 22 Sep 2025 12:54:30 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v2] In-Reply-To: References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: On Mon, 22 Sep 2025 10:06:15 GMT, Sean Coffey wrote: >> src/java.base/share/classes/sun/security/ssl/Utilities.java line 154: >> >>> 152: StringBuilder builder = new StringBuilder(); >>> 153: if (source == null) { >>> 154: builder.append(LINE_SEP).append(prefix).append(""); >> >> I don't think this ls covered by the test. Could you please add an empty case to cover this? > > @myankelev I didn't see any code in the JDK calling this method with `source == null`. Other than hacking into the internals of SSLLogger to force the method call, I'm not sure it can be covered. Would you be ok to log a follow on task/bug if you feel coverage of this corner case is warranted ? Thanks. I think this could be rolled under this https://bugs.openjdk.org/browse/JDK-8361344. So I'm not sure it needs a separate ticket. If there is not easy way of covering it here, I think this could be addressed in JDK-8361344 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25934#discussion_r2368222667 From weijun at openjdk.org Mon Sep 22 13:26:55 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Sep 2025 13:26:55 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: <-1qU853IFYoMNSdy99BazkMttxBFvthdTMUA6H9cKB0=.3a84ec09-78f2-4b80-8035-d7e7e7a090e7@github.com> References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> <-1qU853IFYoMNSdy99BazkMttxBFvthdTMUA6H9cKB0=.3a84ec09-78f2-4b80-8035-d7e7e7a090e7@github.com> Message-ID: On Sun, 21 Sep 2025 20:58:05 GMT, Mark Powers wrote: >> You do have a point here, but we have always been rewriting salt with a possible different length. We can discuss this in another issue, but the change is not necessary here, especially it also affects other old Mac algorithms. > > Are you suggesting to always generate a 20 byte salt? > > Can you provide a line number for your first comment about breaking up "PBEWithHmacSHA256"? > This string is read from the property file and has nothing to do with any DER encoded values read from the keystore input stream. Yes, I think always generating a 20 byte salt is not a problem. For the name break up, I see that `macAlgorithm` can sometimes be `defaultMacAlgorithm()` which is the full "PBEWithHmacSHA256" (line 1250) and sometimes being "PBMAC1" only (line 2203) with `pbmac1Hmac` serving as the additional info. I suggest always using the full name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2368385738 From rriggs at openjdk.org Mon Sep 22 14:39:02 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 22 Sep 2025 14:39:02 GMT Subject: RFR: 8368226: Remove Thread.stop In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 08:13:55 GMT, Alan Bateman wrote: > The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. > > Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. > > Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 1: > 1: This seems like it should have been a file delete, but there is 1 line left. test/jdk/java/lang/Thread/ThreadStopTest.java line 1: > 1: /* This seems like it should have been a file delete, but there is 1 line left. ------------- PR Review: https://git.openjdk.org/jdk/pull/27419#pullrequestreview-3253212818 PR Review Comment: https://git.openjdk.org/jdk/pull/27419#discussion_r2368742789 PR Review Comment: https://git.openjdk.org/jdk/pull/27419#discussion_r2368744219 From alanb at openjdk.org Mon Sep 22 14:55:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 14:55:15 GMT Subject: RFR: 8368226: Remove Thread.stop [v2] In-Reply-To: References: Message-ID: > The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. > > Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. > > Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. Alan Bateman 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-8368226 - Update copyright date - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27419/files - new: https://git.openjdk.org/jdk/pull/27419/files/e59b6d8f..32fddb23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27419&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27419&range=00-01 Stats: 113268 lines in 609 files changed: 105649 ins; 5075 del; 2544 mod Patch: https://git.openjdk.org/jdk/pull/27419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27419/head:pull/27419 PR: https://git.openjdk.org/jdk/pull/27419 From alanb at openjdk.org Mon Sep 22 14:55:17 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 14:55:17 GMT Subject: RFR: 8368226: Remove Thread.stop [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 14:35:23 GMT, Roger Riggs wrote: >> Alan Bateman 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-8368226 >> - Update copyright date >> - Initial commit > > src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 1: > >> 1: > > This seems like it should have been a file delete, but there is 1 line left. I've just sync'ed up the branch and we'll see if this resolves it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27419#discussion_r2368825017 From weijun at openjdk.org Mon Sep 22 15:49:04 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Sep 2025 15:49:04 GMT Subject: RFR: 8360979: Remove use of Thread.stop in krb5/auto/KDC.java [v2] In-Reply-To: References: Message-ID: <7SbcK0oCbYyUlFGAN7Xi-7CdjTBZAAw3_aYIY-ZYtcc=.e29fc3fe-582d-41e6-bc04-7b48f5f8a602@github.com> On Tue, 15 Jul 2025 15:03:22 GMT, Mikhail Yankelevich wrote: >> Replaced Thread::stop to Thread::interrupt > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > breaking the loop when interrupt flag is set Thanks for fixing this. The `terminate` method is only called once when the KDC has its own sub-process. In that case, since the threads are daemons there is really no need to interrupt them. The fix looks good but I don't know how effective it is if a test really needs to start a KDC, terminate it, and then start it on the same port. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26247#issuecomment-3319836482 From weijun at openjdk.org Mon Sep 22 15:58:41 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Sep 2025 15:58:41 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 14:56:13 GMT, Mikhail Yankelevich wrote: > * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java > * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java > * test/jdk/sun/security/pkcs11/Signature/TestDSA.java Honestly, I don't quite understand why there are 2 tests initializing `skipTest` as true and then assign it false. Usually it's the other way round. If you know why it has to be coded this way, please add some comments there. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27367#issuecomment-3319884668 From weijun at openjdk.org Mon Sep 22 16:02:04 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Sep 2025 16:02:04 GMT Subject: RFR: 8364657: Crash for SecureRandom.generateSeed(0) on Windows x86-64 In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 01:07:18 GMT, Shawn M Emery wrote: > The JVM will crash when given a zero byte seed length for SecureRandom.generateSeed() while using the Window's PRNG. The solution is to first check to see if the seed is null or not and if null then generate a zero length byte array. This may be odd but this mimics the same behavior in other operating systems such as MacOS and Linux. > > The new unit test case* provided with this PR replicates the issue before the fix and is confirmed not to replicate the issue after the proposed fix. > > * The TestStrong.java unit test code is a contribution from @jaikiran, thank you! Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27302#pullrequestreview-3253731962 From mpowers at openjdk.org Mon Sep 22 16:14:26 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 22 Sep 2025 16:14:26 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> <-1qU853IFYoMNSdy99BazkMttxBFvthdTMUA6H9cKB0=.3a84ec09-78f2-4b80-8035-d7e7e7a090e7@github.com> Message-ID: On Mon, 22 Sep 2025 13:24:12 GMT, Weijun Wang wrote: >> Are you suggesting to always generate a 20 byte salt? >> >> Can you provide a line number for your first comment about breaking up "PBEWithHmacSHA256"? >> This string is read from the property file and has nothing to do with any DER encoded values read from the keystore input stream. > > Yes, I think always generating a 20 byte salt is not a problem. > > For the name break up, I see that `macAlgorithm` can sometimes be `defaultMacAlgorithm()` which is the full "PBEWithHmacSHA256" (line 1250) and sometimes being "PBMAC1" only (line 2203) with `pbmac1Hmac` serving as the additional info. I suggest always using the full name. I see it now. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2369221962 From iris at openjdk.org Mon Sep 22 16:17:47 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 22 Sep 2025 16:17:47 GMT Subject: RFR: 8368226: Remove Thread.stop [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 14:55:15 GMT, Alan Bateman wrote: >> The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. >> >> Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. >> >> Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. > > Alan Bateman 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-8368226 > - Update copyright date > - Initial commit I'm happy to see the final step in the journey to remove this method! ------------- PR Review: https://git.openjdk.org/jdk/pull/27419#pullrequestreview-3253823021 From serb at openjdk.org Mon Sep 22 16:17:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 22 Sep 2025 16:17:48 GMT Subject: RFR: 8368226: Remove Thread.stop [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 14:55:15 GMT, Alan Bateman wrote: >> The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. >> >> Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. >> >> Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. > > Alan Bateman 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-8368226 > - Update copyright date > - Initial commit Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27419#pullrequestreview-3253826043 From duke at openjdk.org Mon Sep 22 16:49:19 2025 From: duke at openjdk.org (Shawn M Emery) Date: Mon, 22 Sep 2025 16:49:19 GMT Subject: RFR: 8364657: Crash for SecureRandom.generateSeed(0) on Windows x86-64 In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 15:58:52 GMT, Weijun Wang wrote: >> The JVM will crash when given a zero byte seed length for SecureRandom.generateSeed() while using the Window's PRNG. The solution is to first check to see if the seed is null or not and if null then generate a zero length byte array. This may be odd but this mimics the same behavior in other operating systems such as MacOS and Linux. >> >> The new unit test case* provided with this PR replicates the issue before the fix and is confirmed not to replicate the issue after the proposed fix. >> >> * The TestStrong.java unit test code is a contribution from @jaikiran, thank you! > > Marked as reviewed by weijun (Reviewer). Thank you for your review @wangweij ------------- PR Comment: https://git.openjdk.org/jdk/pull/27302#issuecomment-3320134816 From duke at openjdk.org Mon Sep 22 16:49:20 2025 From: duke at openjdk.org (duke) Date: Mon, 22 Sep 2025 16:49:20 GMT Subject: RFR: 8364657: Crash for SecureRandom.generateSeed(0) on Windows x86-64 In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 01:07:18 GMT, Shawn M Emery wrote: > The JVM will crash when given a zero byte seed length for SecureRandom.generateSeed() while using the Window's PRNG. The solution is to first check to see if the seed is null or not and if null then generate a zero length byte array. This may be odd but this mimics the same behavior in other operating systems such as MacOS and Linux. > > The new unit test case* provided with this PR replicates the issue before the fix and is confirmed not to replicate the issue after the proposed fix. > > * The TestStrong.java unit test code is a contribution from @jaikiran, thank you! @smemery Your change (at version a10b47fde9d641d5f1dcf5e13c4344d573a1aef1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27302#issuecomment-3320142490 From valeriep at openjdk.org Mon Sep 22 17:45:05 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 22 Sep 2025 17:45:05 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: <5uPUlt7h-hflZ8RCT9NFZ91Jj5mIWOgTNUxecO5-2Po=.6b03732d-eb01-4e98-89be-1e53c53b5482@github.com> References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> <5uPUlt7h-hflZ8RCT9NFZ91Jj5mIWOgTNUxecO5-2Po=.6b03732d-eb01-4e98-89be-1e53c53b5482@github.com> Message-ID: On Thu, 18 Sep 2025 20:20:25 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> updated the checkTransformation() method w/ specific provider and >> exception per Sean's suggestion > > src/java.base/share/classes/javax/crypto/Cipher.java line 507: > >> 505: * >> 506: * @throws NoSuchAlgorithmException if {@code transformation} >> 507: * is {@code null}, empty, in an invalid format, > > Not related to this change, but do we need an "or" before "in an valid format"? Sure, will use this. Thanks for the suggestions @wangweij @seanjmullan ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2369597509 From valeriep at openjdk.org Mon Sep 22 17:55:36 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 22 Sep 2025 17:55:36 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v9] In-Reply-To: References: Message-ID: > This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods. > > As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear. > > Thanks in advance for the review~ > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Minor syntax change for the NoSuchAlgorithmException description. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26489/files - new: https://git.openjdk.org/jdk/pull/26489/files/0ce7a49f..caac7250 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26489&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26489&range=07-08 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26489/head:pull/26489 PR: https://git.openjdk.org/jdk/pull/26489 From weijun at openjdk.org Mon Sep 22 18:18:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Sep 2025 18:18:11 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> <5uPUlt7h-hflZ8RCT9NFZ91Jj5mIWOgTNUxecO5-2Po=.6b03732d-eb01-4e98-89be-1e53c53b5482@github.com> Message-ID: On Mon, 22 Sep 2025 17:42:02 GMT, Valerie Peng wrote: >> src/java.base/share/classes/javax/crypto/Cipher.java line 507: >> >>> 505: * >>> 506: * @throws NoSuchAlgorithmException if {@code transformation} >>> 507: * is {@code null}, empty, in an invalid format, >> >> Not related to this change, but do we need an "or" before "in an valid format"? > > Sure, will use this. Thanks for the suggestions @wangweij @seanjmullan Now that we are using semi-colon, do we dare add back the commas? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2369729729 From mpowers at openjdk.org Mon Sep 22 18:42:57 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 22 Sep 2025 18:42:57 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: References: Message-ID: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: default salt length and one other comment from Weijun ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24429/files - new: https://git.openjdk.org/jdk/pull/24429/files/e190920c..31b4aeaf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=05-06 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429 PR: https://git.openjdk.org/jdk/pull/24429 From coffeys at openjdk.org Mon Sep 22 18:44:19 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 22 Sep 2025 18:44:19 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v7] In-Reply-To: <6aeZNoHPG24z2Td0KyX6YTb8LREWSQo6hg8iBB4_kxQ=.020390ef-2308-484c-a2a6-37bb898a0ba4@github.com> References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> <6aeZNoHPG24z2Td0KyX6YTb8LREWSQo6hg8iBB4_kxQ=.020390ef-2308-484c-a2a6-37bb898a0ba4@github.com> Message-ID: On Fri, 19 Sep 2025 12:08:14 GMT, Sean Coffey wrote: >> SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode) >> >> SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode. >> >> Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()` >> >> DebugPropertyValuesTest also updated to test new logic. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Avoid Supplier API call Thanks for the review Weijun. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25934#issuecomment-3320768310 From coffeys at openjdk.org Mon Sep 22 18:44:20 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 22 Sep 2025 18:44:20 GMT Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v2] In-Reply-To: References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: <3r_akrvrMDI9dqxsgvJ5LZgagba12xjseratt60kF9I=.ae017e0b-0783-41bf-bb4a-cbf9d54bee98@github.com> On Mon, 22 Sep 2025 12:51:20 GMT, Mikhail Yankelevich wrote: >> @myankelev I didn't see any code in the JDK calling this method with `source == null`. Other than hacking into the internals of SSLLogger to force the method call, I'm not sure it can be covered. Would you be ok to log a follow on task/bug if you feel coverage of this corner case is warranted ? Thanks. > > I think this could be rolled under this https://bugs.openjdk.org/browse/JDK-8361344. So I'm not sure it needs a separate ticket. > > If there is not easy way of covering it here, I think this could be addressed in JDK-8361344 sounds good - thanks for the bug pointer ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25934#discussion_r2369826553 From coffeys at openjdk.org Mon Sep 22 18:44:21 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 22 Sep 2025 18:44:21 GMT Subject: Integrated: 8343395: SSLLogger doesn't work for formatted messages In-Reply-To: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com> Message-ID: On Mon, 23 Jun 2025 12:33:53 GMT, Sean Coffey wrote: > SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode) > > SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode. > > Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()` > > DebugPropertyValuesTest also updated to test new logic. This pull request has now been integrated. Changeset: 47efe3c7 Author: Sean Coffey URL: https://git.openjdk.org/jdk/commit/47efe3c794c241b7534eac597b3dd03d571677f1 Stats: 37 lines in 3 files changed: 15 ins; 9 del; 13 mod 8343395: SSLLogger doesn't work for formatted messages Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/25934 From asmehra at openjdk.org Mon Sep 22 19:30:40 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 22 Sep 2025 19:30:40 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 00:57:09 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3254807664 From weijun at openjdk.org Mon Sep 22 20:44:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Sep 2025 20:44:18 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: <2E3FC-_KayRSbrw9QSz7tUtviaJaZNiDwkrcXQBP1sI=.1470b844-e736-48de-8e45-4009b9e33567@github.com> References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> <2E3FC-_KayRSbrw9QSz7tUtviaJaZNiDwkrcXQBP1sI=.1470b844-e736-48de-8e45-4009b9e33567@github.com> Message-ID: On Thu, 18 Sep 2025 17:44:07 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1490: >> >>> 1488: >>> 1489: if (macAlgorithm.equals("PBMAC1") || >>> 1490: defaultMacAlgorithm().startsWith("PBEWith")) { >> >> `calculateMac` is called when keystore is read from an existing file and `defaultMacAlgorithm` should not be used. Otherwise, algorithm will be modified. Try these: >> >> keytool -keystore ks -keyalg ec -storepass changeit -genkeypair -alias a -dname CN=a -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA512 >> keytool -keystore ks -keyalg ec -storepass changeit -genkeypair -alias b -dname CN=b -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256 > > If the keystore.pkcs12.macAlgorithm security property starts with PBE then shouldn't an old MAC protected keystore be written with PBMAC1 protection? > > I tried those two commands and they work as expected. I did fix a few problems in the last two days so maybe I need to push those changes. No, `keystore.pkcs12.macAlgorithm` should only be used when a new keystore is created. In this example, the keystore is created in the first command, and the system property provided in the second command should be ignored. This means `defaultMacAlgorithm` should only be called on line 1248 when `macAlgorithm` is null. *Update*: since you've already removed `macAlgorithm.equals("PBMAC1")`, `kdfHmac` can be read from `macAlgorithm` now. Same at lines 1947-1953. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2370251718 From abarashev at openjdk.org Mon Sep 22 20:55:11 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 22 Sep 2025 20:55:11 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v6] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 08:19:13 GMT, Hai-May Chao wrote: >> 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 eight additional commits since the last revision: >> >> - Add a ticket number to unit tests >> - Merge branch 'master' into JDK-8365820 >> - Add a server-side unit test. Rename existing tests. >> - Update tests >> - Revert "Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3" >> >> This reverts commit adc236be4bcac11614e2741c99545aa593f6af5b. >> - Merge branch 'master' into JDK-8365820 >> - Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3 >> - 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent > > test/jdk/sun/security/ssl/SignatureScheme/DisableCertSignAlgsExtForServerTLS13.java line 131: > >> 129: // instead, depends on network setup. >> 130: || ex instanceof SocketException)); >> 131: } > > Here for TLS 1.3, handshake always fails because SHA256withRSA is not allowed for client certificates. Would you consider adding a positive test for TLS 1.3 with a client certificate signed with RSASSA-PSS so we could test handshake will succeed as the client complies? Actually SHA256withRSA is not allowed for handshake signatures in TLSv1.3, I made a mistake in the test's comment about it which is now corrected. Otherwise I have added a positive test case, good suggestion! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26887#discussion_r2370279948 From mpowers at openjdk.org Mon Sep 22 21:04:52 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 22 Sep 2025 21:04:52 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 18:37:15 GMT, Bernd 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 17 commits: >> >> - merge >> - removed changes to PBMAC1Core and addressed some comments from Valerie >> - small changes >> - not used >> - refresh index >> - Merge >> - rework to eliminate PBMAC1ParameterSpec >> - merge >> - comments from Valerie >> - missed this new file >> - ... and 7 more: https://git.openjdk.org/jdk/compare/075ebb4e...624ef92e > > src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 76: > >> 74: private int iCount = 0; >> 75: >> 76: // the key derivation function (default is HmacSHA1) > > Is there a reason why to default to sha1, would be for a new feature good to start with a modern default (or none). I know that hmacsha1 in this usecase would still be ok, but that does Not mean that longer (and faster) hashes dont make Sense. If this is picked due to rfc compatibility, maybe name the reference in a comment? Sean Mullan answered this question in an earlier comment. That target is JDK 27. "This allows users to try out the new algorithm in JDK 26 before we switch to it." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2370296392 From mpowers at openjdk.org Mon Sep 22 21:04:55 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 22 Sep 2025 21:04:55 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 05:42:52 GMT, Valerie Peng wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> default salt length and one other comment from Weijun > > src/java.base/share/classes/javax/crypto/spec/PBMAC1ParameterSpec.java line 41: > >> 39: * @since 26 >> 40: */ >> 41: public class PBMAC1ParameterSpec implements AlgorithmParameterSpec { > > PKCS#12 states that other KDF may be used, e.g. Scrypt. The current API seems to be hardcoded to PBKDF2, e.g. salt, iteration count, keyLength, prf, etc. Have you considered separating it out? I know that encapsulating all these different possibilities can be complicated. If this class doesn't have to be under javax.crypto,spec, then we can change it as we see fit. Otherwise, we will need spending more time designing the API... This was considered, but it was finally decided deliver a minimally compliant implementation, e.g. a PBKDF2 supporting only HmacSHA256 and HmacSHA512. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2370299664 From abarashev at openjdk.org Mon Sep 22 21:10:13 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 22 Sep 2025 21:10:13 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v7] In-Reply-To: References: Message-ID: <2VVdtcE6GbqW-bPOssH1iIq1TPKwON1E58yQPXlA6Yw=.98ef5dd1-aa77-495f-982a-76f65d35ec89@github.com> > [JDK-8349583](https://bugs.openjdk.org/browse/JDK-8349583) implementation assumes that OpenJDK client always sends "signature_algorithms_cert" extension together with "signature_algorithms" extension. But we didn't account for `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties which can disable producing "signature_algorithms_cert" extension. This is an issue similar to [JDK-8355779](https://bugs.openjdk.org/browse/JDK-8355779) but on the extension producing side. > > Per TLSv1.3 RFC: > >> If no "signature_algorithms_cert" extension is >> present, then the "signature_algorithms" extension also applies to >> signatures appearing in certificates. > > Also making a few cosmetic changes to the existing code. 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 10 additional commits since the last revision: - Add a positive test case - Merge branch 'master' into JDK-8365820 - Add a ticket number to unit tests - Merge branch 'master' into JDK-8365820 - Add a server-side unit test. Rename existing tests. - Update tests - Revert "Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3" This reverts commit adc236be4bcac11614e2741c99545aa593f6af5b. - Merge branch 'master' into JDK-8365820 - Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3 - 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26887/files - new: https://git.openjdk.org/jdk/pull/26887/files/b934cd1b..360ac544 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26887&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26887&range=05-06 Stats: 140199 lines in 1389 files changed: 121475 ins; 10503 del; 8221 mod Patch: https://git.openjdk.org/jdk/pull/26887.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26887/head:pull/26887 PR: https://git.openjdk.org/jdk/pull/26887 From weijun at openjdk.org Mon Sep 22 21:16:47 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Sep 2025 21:16:47 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 18:42:57 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > default salt length and one other comment from Weijun src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1964: > 1962: ((PBEParameterSpec)params).getIterationCount(), > 1963: kdfHmac.equals("HmacSHA512") ? 64*8 : 32*8)); > 1964: Mac m = Mac.getInstance(kdfHmac); `kdfHmac` is used as `prfHmac` here. If you intend to only support them being the same, please error out as early as possible when parsing PBMAC1-params. You might be able to support them at loading but still lack enough info at storing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2370318901 From mpowers at openjdk.org Mon Sep 22 21:33:13 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 22 Sep 2025 21:33:13 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> <2E3FC-_KayRSbrw9QSz7tUtviaJaZNiDwkrcXQBP1sI=.1470b844-e736-48de-8e45-4009b9e33567@github.com> Message-ID: On Mon, 22 Sep 2025 20:39:22 GMT, Weijun Wang wrote: >> If the keystore.pkcs12.macAlgorithm security property starts with PBE then shouldn't an old MAC protected keystore be written with PBMAC1 protection? >> >> I tried those two commands and they work as expected. I did fix a few problems in the last two days so maybe I need to push those changes. > > No, `keystore.pkcs12.macAlgorithm` should only be used when a new keystore is created. In this example, the keystore is created in the first command, and the system property provided in the second command should be ignored. This means `defaultMacAlgorithm` should only be called on line 1248 when `macAlgorithm` is null. > > *Update*: since you've already removed `macAlgorithm.equals("PBMAC1")`, `kdfHmac` can be read from `macAlgorithm` now. Same at lines 1947-1953. Then you can't read in an old keystore and write it back out as a PBMAC1 keystore? I thought the PBE* security property value, if present, applied to all keystore writes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2370348348 From weijun at openjdk.org Mon Sep 22 22:50:15 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Sep 2025 22:50:15 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> <2E3FC-_KayRSbrw9QSz7tUtviaJaZNiDwkrcXQBP1sI=.1470b844-e736-48de-8e45-4009b9e33567@github.com> Message-ID: On Mon, 22 Sep 2025 21:29:42 GMT, Mark Powers wrote: >> No, `keystore.pkcs12.macAlgorithm` should only be used when a new keystore is created. In this example, the keystore is created in the first command, and the system property provided in the second command should be ignored. This means `defaultMacAlgorithm` should only be called on line 1248 when `macAlgorithm` is null. >> >> *Update*: since you've already removed `macAlgorithm.equals("PBMAC1")`, `kdfHmac` can be read from `macAlgorithm` now. Same at lines 1947-1953. > > Then you can't read in an old keystore and write it back out as a PBMAC1 keystore? > > I thought the PBE* security property value, if present, applied to all keystore writes. It writes back using the original Mac algorithm. If you really want to "upgrade" a keystore, run `keytool -importkeystore`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2370478374 From valeriep at openjdk.org Mon Sep 22 23:54:29 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 22 Sep 2025 23:54:29 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode In-Reply-To: References: Message-ID: <4CiF7EzqjreuJPA_q9XpPoswn_HPHvwDQ4s5Hq29x3g=.565c6a84-13d3-4b10-b62a-5f903fb3ed05@github.com> On Fri, 19 Sep 2025 08:32:41 GMT, Daniel Jeli?ski wrote: > Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. > > This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. > > I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 178: > 176: if (!isExtract || !"RAW".equalsIgnoreCase(baseKey.getFormat())) { > 177: throw pe; > 178: } How about merging line 202-207 with this code block, so that the key/data conversion is together. + long baseKeyID = 0L; + P11Key p11BaseKey = null; + try { + p11BaseKey = convertKey(baseKey, (isExtract ? "IKM" : "PRK") + + " could not be converted to a token key for HKDF derivation."); + baseKeyID = p11BaseKey.getKeyID(); + } catch (ProviderException pe) { + // special handling for FIPS mode when key cannot be imported + if (isExtract && "RAW".equalsIgnoreCase(baseKey.getFormat())) { + baseKeyID = convertKeyToData(baseKey); + } else { + throw pe; + } + } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27384#discussion_r2370660885 From valeriep at openjdk.org Mon Sep 22 23:59:58 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 22 Sep 2025 23:59:58 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:32:41 GMT, Daniel Jeli?ski wrote: > Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. > > This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. > > I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 268: > 266: } > 267: > 268: private long convertKeyToData(byte[] keyBytes) { Check `keyBytes` being non-null? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27384#discussion_r2370666449 From valeriep at openjdk.org Tue Sep 23 00:05:42 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 23 Sep 2025 00:05:42 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 23:57:20 GMT, Valerie Peng wrote: >> Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. >> >> This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. >> >> I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 268: > >> 266: } >> 267: >> 268: private long convertKeyToData(byte[] keyBytes) { > > Check `keyBytes` being non-null? Consider using `SecretKey` argument instead of `byte[]` so it's clear that `keyBytes` is entirely internal, then add a `finally` block to the `try` block to erase the key encoding, i.e. + } finally { + Arrays.fill(keyBytes, (byte)0); + } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27384#discussion_r2370671871 From valeriep at openjdk.org Tue Sep 23 00:14:24 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 23 Sep 2025 00:14:24 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:32:41 GMT, Daniel Jeli?ski wrote: > Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. > > This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. > > I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. test/jdk/sun/security/pkcs11/tls/tls12/nss.cfg line 14: > 12: > 13: attributes(*,CKO_SECRET_KEY,CKK_GENERIC_SECRET) = { > 14: CKA_SIGN = true also add `CKA_EXTRACTABLE = false` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27384#discussion_r2370679569 From kvn at openjdk.org Tue Sep 23 02:05:15 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 02:05:15 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 00:57:09 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() Few comments. src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 60: > 58: // Preloading requires that the Java heap objects of java.lang.Class, java.lang.Package and > 59: // java.security.ProtectionDomain already exist for the preloaded classes. Therefore, we support preloading > 60: // only for the classes in the static CDS archive. Classes in the dynamic archive are not supported because "for the classes in the static CDS archive"? Do you mean "AOT cache"? Or this feature also works for old static CDS archive? src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 97: > 95: } > 96: > 97: ClassLoaderData* loader_data = ClassLoaderData::class_loader_data(loader()); `loader_data` is not used in this method. src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp line 52: > 50: // > 51: // [2] load_javabase_classes() and load_non_javabase_classes(): > 52: // This happens after some Java code is executed, to load aot-linked classes in the dynamic archive. Previous comment say that dynamic archive is not supported. src/hotspot/share/cds/aotLinkedClassTable.hpp line 45: > 43: > 44: Array* _boot1; // boot classes in java.base module > 45: Array* _boot2; // boot classes in all other (named and unnamed) modules Do you mean JDK's modules or user's modules too? ------------- PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3255743679 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370759818 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370778138 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370797359 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370798743 From kvn at openjdk.org Tue Sep 23 02:05:16 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 02:05:16 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: <5Tw9z22Y6nsL7pGxDqShTXtMBnaaoWUAG1AjXOhUL2s=.104e2915-21b3-4474-8a12-2b4f435d268b@github.com> On Tue, 23 Sep 2025 01:18:29 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 60: > >> 58: // Preloading requires that the Java heap objects of java.lang.Class, java.lang.Package and >> 59: // java.security.ProtectionDomain already exist for the preloaded classes. Therefore, we support preloading >> 60: // only for the classes in the static CDS archive. Classes in the dynamic archive are not supported because > > "for the classes in the static CDS archive"? Do you mean "AOT cache"? Or this feature also works for old static CDS archive? I see `precond(CDSConfig::is_using_aot_linked_classes())` on following cod. Which means it only works for AOT cache. Please update comment to avoid confusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370761057 From iklam at openjdk.org Tue Sep 23 03:24:28 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 03:24:28 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v11] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - @vnkozlov review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() - Fixed 32-bit builds - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class - @ashu-mehra review comments - ... and 21 more: https://git.openjdk.org/jdk/compare/61c5245b...bd08a0b5 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=10 Stats: 941 lines in 43 files changed: 534 ins; 236 del; 171 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Tue Sep 23 03:24:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 03:24:30 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: <5Tw9z22Y6nsL7pGxDqShTXtMBnaaoWUAG1AjXOhUL2s=.104e2915-21b3-4474-8a12-2b4f435d268b@github.com> References: <5Tw9z22Y6nsL7pGxDqShTXtMBnaaoWUAG1AjXOhUL2s=.104e2915-21b3-4474-8a12-2b4f435d268b@github.com> Message-ID: On Tue, 23 Sep 2025 01:19:59 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 60: >> >>> 58: // Preloading requires that the Java heap objects of java.lang.Class, java.lang.Package and >>> 59: // java.security.ProtectionDomain already exist for the preloaded classes. Therefore, we support preloading >>> 60: // only for the classes in the static CDS archive. Classes in the dynamic archive are not supported because >> >> "for the classes in the static CDS archive"? Do you mean "AOT cache"? Or this feature also works for old static CDS archive? > > I see `precond(CDSConfig::is_using_aot_linked_classes())` on following cod. Which means it only works for AOT cache. Please update comment to avoid confusion. AOTClassLinking for the dynamic archive has been removed in [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). Currently, AOT-linked classes are supported for both the static archive and AOT cache. I've updated the comments to reflect that. We probably should remove AOTClassLinking from static CDS archive as well. I've created [JDK-8368350](https://bugs.openjdk.org/browse/JDK-8368350) for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370946875 From iklam at openjdk.org Tue Sep 23 03:24:34 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 03:24:34 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 01:29:00 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 97: > >> 95: } >> 96: >> 97: ClassLoaderData* loader_data = ClassLoaderData::class_loader_data(loader()); > > `loader_data` is not used in this method. Removed. > src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp line 52: > >> 50: // >> 51: // [2] load_javabase_classes() and load_non_javabase_classes(): >> 52: // This happens after some Java code is executed, to load aot-linked classes in the dynamic archive. > > Previous comment say that dynamic archive is not supported. That comment was written before AOTClassLinking was removed from dynamic archive. I have removed it. I also added a comment about the new `link_or_init_xxx()` functions added in this PR. > src/hotspot/share/cds/aotLinkedClassTable.hpp line 45: > >> 43: >> 44: Array* _boot1; // boot classes in java.base module >> 45: Array* _boot2; // boot classes in all other (named and unnamed) modules > > Do you mean JDK's modules or user's modules too? Currently it's not possible to use `--module-path` to add user modules to the boot loader, so the only kind of user classes that can be loaded in `boot2` are the ones from `-Xbootclasspath/a`, which are loaded from the unnamed module. I updated the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370946983 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370947364 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370948225 From jpai at openjdk.org Tue Sep 23 07:57:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 23 Sep 2025 07:57:50 GMT Subject: RFR: 8364657: Crash for SecureRandom.generateSeed(0) on Windows x86-64 In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 01:07:18 GMT, Shawn M Emery wrote: > The JVM will crash when given a zero byte seed length for SecureRandom.generateSeed() while using the Window's PRNG. The solution is to first check to see if the seed is null or not and if null then generate a zero length byte array. This may be odd but this mimics the same behavior in other operating systems such as MacOS and Linux. > > The new unit test case* provided with this PR replicates the issue before the fix and is confirmed not to replicate the issue after the proposed fix. > > * The TestStrong.java unit test code is a contribution from @jaikiran, thank you! This is not an area I'm familiar with, but the change itself looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27302#pullrequestreview-3256713769 From duke at openjdk.org Tue Sep 23 07:57:51 2025 From: duke at openjdk.org (Shawn M Emery) Date: Tue, 23 Sep 2025 07:57:51 GMT Subject: Integrated: 8364657: Crash for SecureRandom.generateSeed(0) on Windows x86-64 In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 01:07:18 GMT, Shawn M Emery wrote: > The JVM will crash when given a zero byte seed length for SecureRandom.generateSeed() while using the Window's PRNG. The solution is to first check to see if the seed is null or not and if null then generate a zero length byte array. This may be odd but this mimics the same behavior in other operating systems such as MacOS and Linux. > > The new unit test case* provided with this PR replicates the issue before the fix and is confirmed not to replicate the issue after the proposed fix. > > * The TestStrong.java unit test code is a contribution from @jaikiran, thank you! This pull request has now been integrated. Changeset: 360b6af1 Author: Shawn M Emery Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/360b6af1b1c39e6d3a01c4a32473cf007ed632c6 Stats: 50 lines in 2 files changed: 48 ins; 0 del; 2 mod 8364657: Crash for SecureRandom.generateSeed(0) on Windows x86-64 Co-authored-by: Jaikiran Pai Reviewed-by: weijun, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27302 From duke at openjdk.org Tue Sep 23 09:59:43 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Tue, 23 Sep 2025 09:59:43 GMT Subject: RFR: 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body Message-ID: According to RFC 8446 section 5.4, third paragraph > Application Data records may contain a zero-length > TLSInnerPlaintext.content if the sender desires. This permits > generation of plausibly sized cover traffic in contexts where the > presence or absence of activity may be sensitive. Implementations > MUST NOT send Handshake and Alert records that have a zero-length > TLSInnerPlaintext.content; if such a message is received, the > receiving implementation MUST terminate the connection with an > "unexpected_message" alert. The proposed change removes an off by 1 error in the SSLCipher implementation, forces the correct Alert message to be sent in response to zero-length Alert fragments, as well as updating some tests which detected the BadPaddingException but now detect a SSLProtocolException, which is thrown by `TransportContext.fatal` ------------- Commit messages: - clearer error message and test fix - 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body Changes: https://git.openjdk.org/jdk/pull/27438/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27438&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366454 Stats: 17 lines in 4 files changed: 10 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27438.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27438/head:pull/27438 PR: https://git.openjdk.org/jdk/pull/27438 From mdonovan at openjdk.org Tue Sep 23 11:47:37 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 23 Sep 2025 11:47:37 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: References: Message-ID: <_o21Ka_ZkI3a5noqBvHjwynh4ceOQ1gIIdJC2xlJkUk=.4ed60c3f-5ea9-4fdf-9f8e-576349544c77@github.com> On Mon, 22 Sep 2025 18:42:57 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > default salt length and one other comment from Weijun test/jdk/sun/security/pkcs12/PBMAC1Encoding.java line 39: > 37: public class PBMAC1Encoding { > 38: // A.1. Valid PKCS #12 File with SHA-256 HMAC and PRF > 39: static final String A1 = Can you add a comment explaining how to create these Strings? test/jdk/sun/security/pkcs12/PBMAC1Encoding.java line 423: > 421: ks = KeyStore.getInstance("PKCS12"); > 422: ks.load(new ByteArrayInputStream(Base64.getDecoder().decode(A2)), > 423: password.toCharArray()); Throw an exception after `ks.load()`. Otherwise, if `load()` doesn't throw anything, the test will pass when it shouldn't. test/jdk/sun/security/pkcs12/PBMAC1Encoding.java line 445: > 443: ks = KeyStore.getInstance("PKCS12"); > 444: ks.load(new ByteArrayInputStream(Base64.getDecoder().decode(A4)), > 445: password.toCharArray()); throw an exception after `ks.load()` here and for A.5 and A.6 test cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2372021710 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2372029145 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2372033887 From duke at openjdk.org Tue Sep 23 13:40:18 2025 From: duke at openjdk.org (Raghu) Date: Tue, 23 Sep 2025 13:40:18 GMT Subject: RFR: 8367133: DTLS: fragmentation of Finished message results in handshake failure In-Reply-To: References: Message-ID: <_pri_dFpLvTwb2_sNwmryniZqqp_l2cmPfJ2vCLksn8=.5322a3ff-fcb3-4dbf-a5c0-4eec5129a66f@github.com> On Mon, 15 Sep 2025 06:49:06 GMT, Daniel Jeli?ski wrote: > The DTLSReassembler may release a Finished message before assembling all necessary fragments. > > The newly added test fails without the DTLSReassembler changes, passes with the changes. Other tier1-3 tests continue to pass. Marked as reviewed by ragkale at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/27284#pullrequestreview-3251212035 From kvn at openjdk.org Tue Sep 23 13:47:26 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 13:47:26 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v11] In-Reply-To: References: Message-ID: <0IoLphlvsBS-Kr7-NbUG0pNMjTe3B8kJ7VsDypm9xHw=.2105c0b4-60c5-4eaa-98a2-bedbbbaae995@github.com> On Tue, 23 Sep 2025 03:24:28 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - @vnkozlov review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() > - Fixed 32-bit builds > - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes > - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class > - @ashu-mehra review comments > - ... and 21 more: https://git.openjdk.org/jdk/compare/61c5245b...bd08a0b5 Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3258111898 From iklam at openjdk.org Tue Sep 23 14:43:45 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 14:43:45 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 19:18:41 GMT, Dan Heidinga wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @DanHeidinga comments -- added comments and asserts about the handling of enums > > My concerns have been addressed. Thanks Ioi Thanks @DanHeidinga @ashu-mehra @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3324325748 From iklam at openjdk.org Tue Sep 23 14:46:17 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 14:46:17 GMT Subject: Integrated: 8350550: Preload classes from AOT cache during VM bootstrap In-Reply-To: References: Message-ID: <0g4ainvBjH046UiFMkElHNhUgLhBTEhVih6KTHLTgmA=.37cb0c1d-8239-4b7c-a150-6bdb272df63c@github.com> On Thu, 17 Jul 2025 22:38:48 GMT, Ioi Lam wrote: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. This pull request has now been integrated. Changeset: fd30ae98 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/fd30ae988bc512b5d2a5a3fd1bc1ed351af974c7 Stats: 941 lines in 43 files changed: 534 ins; 236 del; 171 mod 8350550: Preload classes from AOT cache during VM bootstrap Reviewed-by: kvn, heidinga, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/26375 From liach at openjdk.org Tue Sep 23 14:59:53 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Sep 2025 14:59:53 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). >> >> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update NPE per roger review Can anyone come and review this little enhancement again? I think I have addressed the review comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3324389047 From mdonovan at openjdk.org Tue Sep 23 15:15:20 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 23 Sep 2025 15:15:20 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 14:56:13 GMT, Mikhail Yankelevich wrote: > * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java > * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java > * test/jdk/sun/security/pkcs11/Signature/TestDSA.java test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 98: > 96: hashAlg, > 97: mgfHashAlg); > 98: skipTest = true; should this test also be split into separate @test blocks? There are about 18 test cases and 17 of them could pass and the last one skipped and the test gets marked as skipped. test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 38: > 36: > 37: /** > 38: * @test id=old_alg For id's, "old_alg" and "new_alg" aren't very descriptive/useful. Maybe change them to "sha" and "sha3"? test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 79: > 77: private static final int UPDATE_TIMES_HUNDRED = 100; > 78: > 79: private static boolean skipTest = true; It looks like this field is still being and we might test some algorithms but the still throw a SkippedException. Can you get rid of this uncertainty somehow? test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java line 39: > 37: > 38: /** > 39: * @test id=old_alg use more descriptive id names ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2372663754 PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2372622197 PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2372626034 PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2372624291 From myankelevich at openjdk.org Tue Sep 23 15:21:42 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 23 Sep 2025 15:21:42 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 05:46:35 GMT, SendaoYan wrote: >> * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java >> * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java >> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java >> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java >> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java >> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java >> * test/jdk/sun/security/pkcs11/Signature/TestDSA.java > > test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 49: > >> 47: * @test id=new_alg >> 48: * @bug 8080462 8226651 8242332 >> 49: * @summary Generate a RSASSA-PSS signature and verify it using PKCS11 provider > > Should we need comments why this test was splited to two tests. There is no support for sha3 in nss for now it seems, so this is why it's split. I'm not sure if this makes any difference if highlighted in the comment, but I can add in the next commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2372684838 From myankelevich at openjdk.org Tue Sep 23 15:33:00 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 23 Sep 2025 15:33:00 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip [v2] In-Reply-To: References: Message-ID: > * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java > * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java > * test/jdk/sun/security/pkcs11/Signature/TestDSA.java Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: renamed id ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27367/files - new: https://git.openjdk.org/jdk/pull/27367/files/2370b672..e390ba72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27367&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27367&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27367.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27367/head:pull/27367 PR: https://git.openjdk.org/jdk/pull/27367 From myankelevich at openjdk.org Tue Sep 23 15:33:03 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 23 Sep 2025 15:33:03 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 15:11:53 GMT, Matthew Donovan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed id > > test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java line 98: > >> 96: hashAlg, >> 97: mgfHashAlg); >> 98: skipTest = true; > > should this test also be split into separate @test blocks? There are about 18 test cases and 17 of them could pass and the last one skipped and the test gets marked as skipped. There should be no skips in this test with nss, so I don't think this should be an issue here. Splitting this into different `@test` would be though, as it will increase the execution time significantly. > test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 38: > >> 36: >> 37: /** >> 38: * @test id=old_alg > > For id's, "old_alg" and "new_alg" aren't very descriptive/useful. Maybe change them to "sha" and "sha3"? Done in the next commit > test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 79: > >> 77: private static final int UPDATE_TIMES_HUNDRED = 100; >> 78: >> 79: private static boolean skipTest = true; > > It looks like this field is still being and we might test some algorithms but the still throw a SkippedException. Can you get rid of this uncertainty somehow? I'm not sure what you mean here. I think the best way would be to split the `@test` and test each algorithm separately. However this approach will take forever to execute, which is a dealbreaker. I can add all the skips into one list and only then print out the skipped parameters, if this helps. However, given that the test is split into sha and sha3, all sha3 will be skipped for now. I'm not sure it would bring much more clarity in this case. What do you think? > test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java line 39: > >> 37: >> 38: /** >> 39: * @test id=old_alg > > use more descriptive id names Done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2372711689 PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2372704609 PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2372698054 PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2372702634 From mullan at openjdk.org Tue Sep 23 16:08:34 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 23 Sep 2025 16:08:34 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v9] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 17:55:36 GMT, Valerie Peng wrote: >> This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods. >> >> As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear. >> >> Thanks in advance for the review~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Minor syntax change for the NoSuchAlgorithmException description. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26489#pullrequestreview-3258722265 From mullan at openjdk.org Tue Sep 23 16:08:35 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 23 Sep 2025 16:08:35 GMT Subject: RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v8] In-Reply-To: References: <1_2yHKLRyDe3dWiZ2pfkJ3XzlpC8_8-KOkIJ56xKFso=.b74f4c3e-bcad-4cd2-8255-e1f7e3616bd1@github.com> <5uPUlt7h-hflZ8RCT9NFZ91Jj5mIWOgTNUxecO5-2Po=.6b03732d-eb01-4e98-89be-1e53c53b5482@github.com> Message-ID: On Mon, 22 Sep 2025 18:15:47 GMT, Weijun Wang wrote: >> Sure, will use this. Thanks for the suggestions @wangweij @seanjmullan > > Now that we are using semi-colon, do we dare add back the commas? Don't think it makes a significant difference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2372813785 From djelinski at openjdk.org Tue Sep 23 16:16:22 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Sep 2025 16:16:22 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode [v2] In-Reply-To: References: Message-ID: > Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. > > This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. > > I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27384/files - new: https://git.openjdk.org/jdk/pull/27384/files/730427d5..81b470e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27384&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27384&range=00-01 Stats: 61 lines in 1 file changed: 34 ins; 24 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27384.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27384/head:pull/27384 PR: https://git.openjdk.org/jdk/pull/27384 From djelinski at openjdk.org Tue Sep 23 16:16:22 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Sep 2025 16:16:22 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 16:12:52 GMT, Daniel Jeli?ski wrote: >> Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. >> >> This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. >> >> I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Thanks @valeriepeng for your review. I updated the PR, let me know if that looks acceptable. ------------- PR Review: https://git.openjdk.org/jdk/pull/27384#pullrequestreview-3258615121 From djelinski at openjdk.org Tue Sep 23 16:16:26 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Sep 2025 16:16:26 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 00:03:18 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 268: >> >>> 266: } >>> 267: >>> 268: private long convertKeyToData(byte[] keyBytes) { >> >> Check `keyBytes` being non-null? > > Consider using `SecretKey` argument instead of `byte[]` so it's clear that `keyBytes` is entirely internal, then add a `finally` block to the `try` block to erase the key encoding, i.e. > > + } finally { > + Arrays.fill(keyBytes, (byte)0); > + } Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27384#discussion_r2372780641 From djelinski at openjdk.org Tue Sep 23 16:16:25 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 23 Sep 2025 16:16:25 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode [v2] In-Reply-To: <4CiF7EzqjreuJPA_q9XpPoswn_HPHvwDQ4s5Hq29x3g=.565c6a84-13d3-4b10-b62a-5f903fb3ed05@github.com> References: <4CiF7EzqjreuJPA_q9XpPoswn_HPHvwDQ4s5Hq29x3g=.565c6a84-13d3-4b10-b62a-5f903fb3ed05@github.com> Message-ID: On Mon, 22 Sep 2025 23:52:04 GMT, Valerie Peng wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line 178: > >> 176: if (!isExtract || !"RAW".equalsIgnoreCase(baseKey.getFormat())) { >> 177: throw pe; >> 178: } > > How about merging line 202-207 with this code block, so that the key/data conversion is together. > > + long baseKeyID = 0L; > + P11Key p11BaseKey = null; > + try { > + p11BaseKey = convertKey(baseKey, (isExtract ? "IKM" : "PRK") + > + " could not be converted to a token key for HKDF derivation."); > + baseKeyID = p11BaseKey.getKeyID(); > + } catch (ProviderException pe) { > + // special handling for FIPS mode when key cannot be imported > + if (isExtract && "RAW".equalsIgnoreCase(baseKey.getFormat())) { > + baseKeyID = convertKeyToData(baseKey); > + } else { > + throw pe; > + } > + } Done. > test/jdk/sun/security/pkcs11/tls/tls12/nss.cfg line 14: > >> 12: >> 13: attributes(*,CKO_SECRET_KEY,CKK_GENERIC_SECRET) = { >> 14: CKA_SIGN = true > > also add `CKA_EXTRACTABLE = false` ? I'd rather not. That would disable key extraction, and would likely bring back [JDK-6913047](https://bugs.openjdk.org/browse/JDK-6913047) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27384#discussion_r2372779361 PR Review Comment: https://git.openjdk.org/jdk/pull/27384#discussion_r2372740241 From weijun at openjdk.org Tue Sep 23 18:17:29 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 23 Sep 2025 18:17:29 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 18:42:57 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > default salt length and one other comment from Weijun src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2196: > 2194: String algName = > 2195: macData.getDigestAlgName().toUpperCase(Locale.ENGLISH); > 2196: if (algName.equals("PBMAC1")) { We should manage to move algorithm-specific logic inside `MacData` as much as possible, ideally everything. For example, instead of letting `macData.getDigestAlgName()` returning either "HmacSHA256" or "PBMAC1", it should return the final `macAlgorithm` we need. If the calculation and verification must be different, they can also be moved into `MacData`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2373110289 From mullan at openjdk.org Tue Sep 23 19:44:02 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 23 Sep 2025 19:44:02 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: References: Message-ID: <-faEDvXY3byz0308qDR_faSreg9DkQYtg-txROBLYL0=.0229eabd-d5a3-40a6-82b0-d9f9791110a0@github.com> On Mon, 22 Sep 2025 18:42:57 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > default salt length and one other comment from Weijun src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2208: > 2206: } else { > 2207: > 2208: // Change SHA-1 to SHA1 While you are in this code, can you update this comment? It's not only SHA-1, it's any message digest with a "-" in it, so suggest changing it to something like: `// Remove "-" from digest algorithm names` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2373286486 From dholmes at openjdk.org Tue Sep 23 22:46:12 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Sep 2025 22:46:12 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). >> >> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update NPE per roger review src/hotspot/share/interpreter/bytecodeUtils.cpp line 205: > 203: // A slot is found > 204: FOUND > 205: }; So you define an ENUM to capture the negative cases but then you can use any int >= 0 and pretend it is a member of the enum. ?? Is that typical C++ enum usage? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2373618080 From liach at openjdk.org Tue Sep 23 23:17:17 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Sep 2025 23:17:17 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: <0oXmVu02mX_lRIUGFSCAoG_u3xXWtZh4Rx0oPfUrWy4=.454eb8c7-038c-4843-bfba-8dced19327d5@github.com> On Tue, 23 Sep 2025 22:43:53 GMT, David Holmes wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update NPE per roger review > > src/hotspot/share/interpreter/bytecodeUtils.cpp line 205: > >> 203: // A slot is found >> 204: FOUND >> 205: }; > > So you define an ENUM to capture the negative cases but then you can use any int >= 0 and pretend it is a member of the enum. ?? Is that typical C++ enum usage? This was from @jdksjolen's suggestion. I emulated how valhalla's LayoutKind is declared. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2373654413 From prappo at openjdk.org Tue Sep 23 23:28:02 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 23 Sep 2025 23:28:02 GMT Subject: RFR: 8368226: Remove Thread.stop [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 14:55:15 GMT, Alan Bateman wrote: >> The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. >> >> Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. >> >> Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. > > Alan Bateman 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-8368226 > - Update copyright date > - Initial commit src/java.base/share/classes/java/lang/ThreadDeath.java line 34: > 32: * @deprecated {@code Thread} originally specified a "{@code stop}" method to stop a > 33: * victim thread by causing the victim thread to throw a {@code ThreadDeath}. It > 34: * was inherently unsafe and deprecated in an early JDK release. The stop method A trivial issue: it's a method name, so Suggestion: * was inherently unsafe and deprecated in an early JDK release. The {@code stop} method ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27419#discussion_r2373667668 From hchao at openjdk.org Wed Sep 24 01:31:24 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 24 Sep 2025 01:31:24 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v6] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 20:52:56 GMT, Artur Barashev wrote: >> test/jdk/sun/security/ssl/SignatureScheme/DisableCertSignAlgsExtForServerTLS13.java line 131: >> >>> 129: // instead, depends on network setup. >>> 130: || ex instanceof SocketException)); >>> 131: } >> >> Here for TLS 1.3, handshake always fails because SHA256withRSA is not allowed for client certificates. Would you consider adding a positive test for TLS 1.3 with a client certificate signed with RSASSA-PSS so we could test handshake will succeed as the client complies? > > Actually SHA256withRSA is not allowed for handshake signatures in TLSv1.3, I made a mistake in the test's comment about it which is now corrected. Otherwise I have added a positive test case, good suggestion! Update looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26887#discussion_r2373824682 From hchao at openjdk.org Wed Sep 24 01:46:57 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Wed, 24 Sep 2025 01:46:57 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v7] In-Reply-To: <2VVdtcE6GbqW-bPOssH1iIq1TPKwON1E58yQPXlA6Yw=.98ef5dd1-aa77-495f-982a-76f65d35ec89@github.com> References: <2VVdtcE6GbqW-bPOssH1iIq1TPKwON1E58yQPXlA6Yw=.98ef5dd1-aa77-495f-982a-76f65d35ec89@github.com> Message-ID: On Mon, 22 Sep 2025 21:10:13 GMT, Artur Barashev wrote: >> [JDK-8349583](https://bugs.openjdk.org/browse/JDK-8349583) implementation assumes that OpenJDK client always sends "signature_algorithms_cert" extension together with "signature_algorithms" extension. But we didn't account for `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties which can disable producing "signature_algorithms_cert" extension. This is an issue similar to [JDK-8355779](https://bugs.openjdk.org/browse/JDK-8355779) but on the extension producing side. >> >> Per TLSv1.3 RFC: >> >>> If no "signature_algorithms_cert" extension is >>> present, then the "signature_algorithms" extension also applies to >>> signatures appearing in certificates. >> >> Also making a few cosmetic changes to the existing code. > > 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 10 additional commits since the last revision: > > - Add a positive test case > - Merge branch 'master' into JDK-8365820 > - Add a ticket number to unit tests > - Merge branch 'master' into JDK-8365820 > - Add a server-side unit test. Rename existing tests. > - Update tests > - Revert "Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3" > > This reverts commit adc236be4bcac11614e2741c99545aa593f6af5b. > - Merge branch 'master' into JDK-8365820 > - Include RSASSA-PKCS1-v1_5 and Legacy algorithms in signature_algorithms for TLSv1.3 > - 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent The @summary in DisableCertSignAlgsExtForServerTLS13, DisableCertSignAlgsExtForClientTLS13, and DisableCertSignAlgsExtForClientTLS12 are identical. Suggest to include difference from client or sever perspective, and protocol version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26887#issuecomment-3326146117 From valeriep at openjdk.org Wed Sep 24 02:17:42 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 Sep 2025 02:17:42 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode [v2] In-Reply-To: References: Message-ID: <_DOk3w3S_als7xpm1x31qL5T_KHxZMZjNCAYc0Vo1TM=.cd8156ed-db37-4946-adf9-83f7b2e11f58@github.com> On Tue, 23 Sep 2025 16:16:22 GMT, Daniel Jeli?ski wrote: >> Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. >> >> This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. >> >> I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Looks good to me. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27384#pullrequestreview-3260363472 From valeriep at openjdk.org Wed Sep 24 02:17:44 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 Sep 2025 02:17:44 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode [v2] In-Reply-To: References: <4CiF7EzqjreuJPA_q9XpPoswn_HPHvwDQ4s5Hq29x3g=.565c6a84-13d3-4b10-b62a-5f903fb3ed05@github.com> Message-ID: On Tue, 23 Sep 2025 15:36:26 GMT, Daniel Jeli?ski wrote: >> test/jdk/sun/security/pkcs11/tls/tls12/nss.cfg line 14: >> >>> 12: >>> 13: attributes(*,CKO_SECRET_KEY,CKK_GENERIC_SECRET) = { >>> 14: CKA_SIGN = true >> >> also add `CKA_EXTRACTABLE = false` ? > > I'd rather not. That would disable key extraction, and would likely bring back [JDK-6913047](https://bugs.openjdk.org/browse/JDK-6913047) Ok, either way is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27384#discussion_r2373871002 From mpowers at openjdk.org Wed Sep 24 02:51:45 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 24 Sep 2025 02:51:45 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 21:13:38 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> default salt length and one other comment from Weijun > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1964: > >> 1962: ((PBEParameterSpec)params).getIterationCount(), >> 1963: kdfHmac.equals("HmacSHA512") ? 64*8 : 32*8)); >> 1964: Mac m = Mac.getInstance(kdfHmac); > > `kdfHmac` is used as `prfHmac` here. If you intend to only support them being the same, please error out as early as possible when parsing PBMAC1-params. You might be able to support them at loading but still lack enough info at storing. An exception is now thrown in `MacData` when reading. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2373906919 From mpowers at openjdk.org Wed Sep 24 02:51:42 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 24 Sep 2025 02:51:42 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3] In-Reply-To: References: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com> <2E3FC-_KayRSbrw9QSz7tUtviaJaZNiDwkrcXQBP1sI=.1470b844-e736-48de-8e45-4009b9e33567@github.com> Message-ID: On Mon, 22 Sep 2025 22:47:10 GMT, Weijun Wang wrote: >> Then you can't read in an old keystore and write it back out as a PBMAC1 keystore? >> >> I thought the PBE* security property value, if present, applied to all keystore writes. > > It writes back using the original Mac algorithm. > > If you really want to "upgrade" a keystore, run `keytool -importkeystore`. Another iteration on this (sigh). This sequence now works: keytool -keystore ks -keyalg ec -storepass changeit -genkeypair -alias a -dname CN=a -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA512 keytool -keystore ks -keyalg ec -storepass changeit -genkeypair -alias b -dname CN=b -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256 keytool -importkeystore -srckeystore ks -storepass changeit -destkeystore ks.new -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2373906624 From mpowers at openjdk.org Wed Sep 24 02:57:12 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 24 Sep 2025 02:57:12 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: References: Message-ID: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: fix behavior with keytool ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24429/files - new: https://git.openjdk.org/jdk/pull/24429/files/31b4aeaf..069ef254 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=06-07 Stats: 56 lines in 2 files changed: 35 ins; 6 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/24429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429 PR: https://git.openjdk.org/jdk/pull/24429 From djelinski at openjdk.org Wed Sep 24 06:22:29 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Sep 2025 06:22:29 GMT Subject: RFR: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 16:16:22 GMT, Daniel Jeli?ski wrote: >> Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. >> >> This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. >> >> I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Thanks for the re-review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27384#issuecomment-3326700267 From djelinski at openjdk.org Wed Sep 24 06:22:30 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Sep 2025 06:22:30 GMT Subject: Integrated: 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode In-Reply-To: References: Message-ID: <29MHKv0DulS9qdVfan1V1kMA0w8d5HKBSq4yzUF8XSA=.25dd6e61-7e22-4cdb-932e-0dc07dd6427f@github.com> On Fri, 19 Sep 2025 08:32:41 GMT, Daniel Jeli?ski wrote: > Enable HDKF to work with providers that do not allow secret keys to be created from arbitrary data. > > This permits the TLS 1.3 handshake to complete with SunPKCS11 provider backed by NSS in FIPS mode. > > I added a TLS 1.3 test case to an existing test. The new test passes with the HKDF changes, fails without them. Other tier1-3 tests continue to pass. This pull request has now been integrated. Changeset: 3183a13f Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/3183a13f666ff38c03c0628e139998803be8a719 Stats: 147 lines in 3 files changed: 97 ins; 34 del; 16 mod 8368073: PKCS11 HKDF can't use byte array IKM in FIPS mode Reviewed-by: valeriep ------------- PR: https://git.openjdk.org/jdk/pull/27384 From djelinski at openjdk.org Wed Sep 24 08:16:37 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Sep 2025 08:16:37 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers Message-ID: Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. Tier1-3 tests continue to pass. ------------- Commit messages: - Add bug ID - Test session resumption - Fix session resumption Changes: https://git.openjdk.org/jdk/pull/27463/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27463&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368514 Stats: 32 lines in 2 files changed: 16 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27463.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27463/head:pull/27463 PR: https://git.openjdk.org/jdk/pull/27463 From alanb at openjdk.org Wed Sep 24 09:49:20 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 24 Sep 2025 09:49:20 GMT Subject: RFR: 8368226: Remove Thread.stop [v3] In-Reply-To: References: Message-ID: > The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. > > Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. > > Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. Alan Bateman 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: - Use {@code .. } for stop method - Merge branch 'master' into JDK-8368226 - Merge branch 'master' into JDK-8368226 - Update copyright date - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27419/files - new: https://git.openjdk.org/jdk/pull/27419/files/32fddb23..7a2e47fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27419&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27419&range=01-02 Stats: 3467 lines in 167 files changed: 1691 ins; 1276 del; 500 mod Patch: https://git.openjdk.org/jdk/pull/27419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27419/head:pull/27419 PR: https://git.openjdk.org/jdk/pull/27419 From jpai at openjdk.org Wed Sep 24 10:26:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 24 Sep 2025 10:26:50 GMT Subject: RFR: 8368226: Remove Thread.stop [v3] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 09:49:20 GMT, Alan Bateman wrote: >> The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. >> >> Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. >> >> Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. > > Alan Bateman 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: > > - Use {@code .. } for stop method > - Merge branch 'master' into JDK-8368226 > - Merge branch 'master' into JDK-8368226 > - Update copyright date > - Initial commit Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27419#pullrequestreview-3262207954 From myankelevich at openjdk.org Wed Sep 24 10:29:37 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 24 Sep 2025 10:29:37 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 15:56:11 GMT, Weijun Wang wrote: > Honestly, I don't quite understand why there are 2 tests initializing `skipTest` as true and then assign it false. Usually it's the other way round. If you know why it has to be coded this way, please add some comments there. Thanks. I was just keeping the previous logic that was present before and could be seen in the other files. I personally don't think flipping the logic will bring any benefits. Especially as it may bring accidental confusion if several tests with flipped and not flipped logic are involved in some fix/enhancement in the future. But overall I'm fine with doing this, so if you think I should - I will. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27367#issuecomment-3327659645 From alanb at openjdk.org Wed Sep 24 10:39:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 24 Sep 2025 10:39:58 GMT Subject: RFR: 8368226: Remove Thread.stop [v3] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:31:10 GMT, Mikhail Yankelevich wrote: >> Alan Bateman 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: >> >> - Use {@code .. } for stop method >> - Merge branch 'master' into JDK-8368226 >> - Merge branch 'master' into JDK-8368226 >> - Update copyright date >> - Initial commit > > test/jdk/sun/security/krb5/auto/KDC.java line 1651: > >> 1649: thread1.interrupt(); >> 1650: thread2.interrupt(); >> 1651: thread3.interrupt(); > > I don't think this will work in this test. The full change in in the pr here https://github.com/openjdk/jdk/pull/26247. > > There should be no conflict as far as I can see @myankelev @wangweij Are you planning to wrap up JDK-8360979 soon? Just wondering whether to integrate with the change to KDF or wait a few days. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27419#discussion_r2375335231 From lancea at openjdk.org Wed Sep 24 11:09:14 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 24 Sep 2025 11:09:14 GMT Subject: RFR: 8368226: Remove Thread.stop [v3] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 09:49:20 GMT, Alan Bateman wrote: >> The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. >> >> Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. >> >> Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. > > Alan Bateman 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: > > - Use {@code .. } for stop method > - Merge branch 'master' into JDK-8368226 > - Merge branch 'master' into JDK-8368226 > - Update copyright date > - Initial commit Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27419#pullrequestreview-3262345568 From vklang at openjdk.org Wed Sep 24 11:46:48 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 24 Sep 2025 11:46:48 GMT Subject: RFR: 8368226: Remove Thread.stop [v3] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 09:49:20 GMT, Alan Bateman wrote: >> The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. >> >> Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. >> >> Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. > > Alan Bateman 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: > > - Use {@code .. } for stop method > - Merge branch 'master' into JDK-8368226 > - Merge branch 'master' into JDK-8368226 > - Update copyright date > - Initial commit Marked as reviewed by vklang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27419#pullrequestreview-3262500272 From myankelevich at openjdk.org Wed Sep 24 11:57:40 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 24 Sep 2025 11:57:40 GMT Subject: RFR: 8360979: Remove use of Thread.stop in krb5/auto/KDC.java [v2] In-Reply-To: <7SbcK0oCbYyUlFGAN7Xi-7CdjTBZAAw3_aYIY-ZYtcc=.e29fc3fe-582d-41e6-bc04-7b48f5f8a602@github.com> References: <7SbcK0oCbYyUlFGAN7Xi-7CdjTBZAAw3_aYIY-ZYtcc=.e29fc3fe-582d-41e6-bc04-7b48f5f8a602@github.com> Message-ID: On Mon, 22 Sep 2025 15:46:26 GMT, Weijun Wang wrote: > Thanks for fixing this. The `terminate` method is only called once when the KDC has its own sub-process. In that case, since the threads are daemons there is really no need to interrupt them. The fix looks good but I don't know how effective it is if a test really needs to start a KDC, terminate it, and then start it on the same port. This pr just replaces the thread.stop with the same functionality without changing the logic of the test. Do you propose reworking test and removing the interruption all together? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26247#issuecomment-3328048329 From alanb at openjdk.org Wed Sep 24 13:03:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 24 Sep 2025 13:03:36 GMT Subject: RFR: 8368226: Remove Thread.stop [v3] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 09:49:20 GMT, Alan Bateman wrote: >> The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. >> >> Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. >> >> Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. > > Alan Bateman 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: > > - Use {@code .. } for stop method > - Merge branch 'master' into JDK-8368226 > - Merge branch 'master' into JDK-8368226 > - Update copyright date > - Initial commit Thanks for all the reviews, we can finally put a stop to Thread.stop. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27419#issuecomment-3328306639 From mdonovan at openjdk.org Wed Sep 24 13:03:37 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 24 Sep 2025 13:03:37 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 15:33:00 GMT, Mikhail Yankelevich wrote: >> * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java >> * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java >> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java >> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java >> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java >> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java >> * test/jdk/sun/security/pkcs11/Signature/TestDSA.java > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > renamed id test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 59: > 57: > 58: private static final int[] KEYSIZES = { 2048, 3072 }; > 59: private static String[] DIGESTS = { suggested name changes DIGESTS = "SHA_DIGESTS" and "DIGESTS_NEW" = "SHA3_DIGESTS" test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 82: > 80: > 81: public static void main(String[] args) throws Exception { > 82: if (args.length>0 && "new-alg".equals(args[0])){ The parameter passed for the sha3 tests is "new-algS" so this will always run the SHA algorithms. If you keep the SHA3 tests, I suggest renaming the parameter to sha3 in the @run instruction and here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2375689908 PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2375687531 From mdonovan at openjdk.org Wed Sep 24 13:03:40 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 24 Sep 2025 13:03:40 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip [v2] In-Reply-To: References: Message-ID: <_1K7EoCD8dKGUOxoIu8LBYFVTEgiuWe2rpES2oLBuPw=.5398896a-d2e7-4758-a393-9c76513dda06@github.com> On Tue, 23 Sep 2025 15:23:23 GMT, Mikhail Yankelevich wrote: >> test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 79: >> >>> 77: private static final int UPDATE_TIMES_HUNDRED = 100; >>> 78: >>> 79: private static boolean skipTest = true; >> >> It looks like this field is still being and we might test some algorithms but the still throw a SkippedException. Can you get rid of this uncertainty somehow? > > I'm not sure what you mean here. I think the best way would be to split the `@test` and test each algorithm separately. However this approach will take forever to execute, which is a dealbreaker. > > I can add all the skips into one list and only then print out the skipped parameters, if this helps. However, given that the test is split into sha and sha3, all sha3 will be skipped for now. I'm not sure it would bring much more clarity in this case. What do you think? In my opinion, tests shouldn't have logic that runs some test cases and skips others. It creates uncertainty when trying to analyze test coverage. In this case, if a SkippedException is thrown, we don't know what -- if any -- algorithms were successfully tested unless we review the logs and that's an unnecessary burden. If NSS doesn't support the SHA3 algorithms, then we shouldn't try to test them. When we update the NSS library, we need to look at what's newly supported (or removed) and update tests accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2375715510 From weijun at openjdk.org Wed Sep 24 13:04:40 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 24 Sep 2025 13:04:40 GMT Subject: RFR: 8360979: Remove use of Thread.stop in krb5/auto/KDC.java [v2] In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 15:03:22 GMT, Mikhail Yankelevich wrote: >> Replaced Thread::stop to Thread::interrupt > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > breaking the loop when interrupt flag is set Marked as reviewed by weijun (Reviewer). The fix looks fine. I might be only questioning the quality of the original test. ------------- PR Review: https://git.openjdk.org/jdk/pull/26247#pullrequestreview-3262794027 PR Comment: https://git.openjdk.org/jdk/pull/26247#issuecomment-3328307310 From alanb at openjdk.org Wed Sep 24 13:07:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 24 Sep 2025 13:07:15 GMT Subject: Integrated: 8368226: Remove Thread.stop In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 08:13:55 GMT, Alan Bateman wrote: > The no-arg Thread.stop has been deprecated since JDK 1.2, deprecated for removal since JDK 18, and re-specified to throw UOE unconditionally since JDK 20. It is time to finally remove the method. Its more evil sibling Thread.stop(Throwable) was removed in JDK 11. > > Code that uses Thread.stop will no longer compile. Code using this method that was compiled to older releases will throw NoSuchMethodError instead of UnsupportedOperationException. > > Most of the tests using Thread.stop have already been fixed in advance of this PR. However, the tests for Kerberos and DTLS use the KDC server as infrastructure and don't compile because it uses Thread.stop and swallows the UOE. This is tracked by JDK-8360979. It is temporarily changed to use Thread.interrupt to avoid excluding many of tests in these areas. If JDK-8360979 is fixed then no change to KDC is needed. This pull request has now been integrated. Changeset: 727d41d2 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/727d41d2882e972e19e6dd431a9080a2f9ad4a22 Stats: 343 lines in 6 files changed: 0 ins; 334 del; 9 mod 8368226: Remove Thread.stop Reviewed-by: vklang, jpai, lancea, serb ------------- PR: https://git.openjdk.org/jdk/pull/27419 From myankelevich at openjdk.org Wed Sep 24 13:21:31 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 24 Sep 2025 13:21:31 GMT Subject: RFR: 8360979: Remove use of Thread.stop in krb5/auto/KDC.java [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:00:56 GMT, Weijun Wang wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> breaking the loop when interrupt flag is set > > The fix looks fine. I might be only questioning the quality of the original test. Thanks for the review @wangweij! I've created [JDK-8368561]( https://bugs.openjdk.org/browse/JDK-8368561) to revisit and review the test logic itself to make it simpler if possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26247#issuecomment-3328398884 From myankelevich at openjdk.org Wed Sep 24 13:25:11 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 24 Sep 2025 13:25:11 GMT Subject: Integrated: 8360979: Remove use of Thread.stop in krb5/auto/KDC.java In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 16:03:54 GMT, Mikhail Yankelevich wrote: > Replaced Thread::stop to Thread::interrupt This pull request has now been integrated. Changeset: 2a232d02 Author: Mikhail Yankelevich URL: https://git.openjdk.org/jdk/commit/2a232d0210015606da7207edab793760fdb61b57 Stats: 52 lines in 1 file changed: 7 ins; 7 del; 38 mod 8360979: Remove use of Thread.stop in krb5/auto/KDC.java Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/26247 From myankelevich at openjdk.org Wed Sep 24 13:25:14 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 24 Sep 2025 13:25:14 GMT Subject: RFR: 8368226: Remove Thread.stop [v3] In-Reply-To: References: Message-ID: <33RKyLzlCXtSbMf4epYgKD9RbfQwtl0XVbYHyD__Vk4=.1393c407-525a-48bc-b2af-27979e1493aa@github.com> On Wed, 24 Sep 2025 10:37:05 GMT, Alan Bateman wrote: >> test/jdk/sun/security/krb5/auto/KDC.java line 1651: >> >>> 1649: thread1.interrupt(); >>> 1650: thread2.interrupt(); >>> 1651: thread3.interrupt(); >> >> I don't think this will work in this test. The full change in in the pr here https://github.com/openjdk/jdk/pull/26247. >> >> There should be no conflict as far as I can see > > @myankelev @wangweij Are you planning to wrap up JDK-8360979 soon? Just wondering whether to integrate with the change to KDF or wait a few days. Should be merging now ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27419#discussion_r2375782018 From weijun at openjdk.org Wed Sep 24 13:27:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 24 Sep 2025 13:27:18 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> Message-ID: On Wed, 24 Sep 2025 02:57:12 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > fix behavior with keytool src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1487: > 1485: int writeIterationCount = macIterationCount; > 1486: > 1487: if (newKeystore) { I cannot see how `newKeystore` is useful. Back when it's set to true, `macAlgorithm` was also set to `defaultMacAlgorithm()`. Therefore there is no need to try `defaultMacAlgorithm()` again below. As for `writeIterationCount`, for a new keystore it is -1, so we can use this to decide whether it should be assigned `defaultMacIterationCount()`. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1493: > 1491: if (!(kdfHmac.equals("HmacSHA512") || > 1492: kdfHmac.equals("HmacSHA256"))) { > 1493: kdfHmac = pbmac1Hmac; // use value associated with keystore `kdfHmac` is probably null now. If you decide to reject other algorithms (which I don't find necessary), error out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2375788823 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2375791879 From djelinski at openjdk.org Wed Sep 24 13:30:34 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Sep 2025 13:30:34 GMT Subject: RFR: 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body In-Reply-To: References: Message-ID: <2fEQEVpM6Am0iixQ8KYccfqEgyp4aUnGtS8atKjNIxM=.5403a452-de2b-4547-ad4c-6880bd0969f7@github.com> On Mon, 22 Sep 2025 20:20:19 GMT, Alice Pellegrini wrote: > According to RFC 8446 section 5.4, third paragraph >> Application Data records may contain a zero-length >> TLSInnerPlaintext.content if the sender desires. This permits >> generation of plausibly sized cover traffic in contexts where the >> presence or absence of activity may be sensitive. Implementations >> MUST NOT send Handshake and Alert records that have a zero-length >> TLSInnerPlaintext.content; if such a message is received, the >> receiving implementation MUST terminate the connection with an >> "unexpected_message" alert. > > > The proposed change removes an off by 1 error in the SSLCipher implementation, forces the correct Alert message to be sent in response to zero-length Alert fragments, as well as updating some tests which detected the BadPaddingException but now detect a SSLProtocolException, which is thrown by `TransportContext.fatal` Looks reasonable. Would it be possible to add a test for the empty plaintext case? Or do we never generate empty plaintexts? Please update the copyright years. src/java.base/share/classes/sun/security/ssl/SSLCipher.java line 1926: > 1924: // remove inner plaintext padding > 1925: int i = pt.limit() - 1; > 1926: for (; i > 0 && pt.get(i) == 0; i--); Suggestion: for (; i >= pos && pt.get(i) == 0; i--); src/java.base/share/classes/sun/security/ssl/SSLCipher.java line 2444: > 2442: // remove inner plaintext padding > 2443: int i = pt.limit() - 1; > 2444: for (; i > 0 && pt.get(i) == 0; i--) { Suggestion: for (; i >= pos && pt.get(i) == 0; i--) { ------------- PR Review: https://git.openjdk.org/jdk/pull/27438#pullrequestreview-3262902812 PR Review Comment: https://git.openjdk.org/jdk/pull/27438#discussion_r2375791852 PR Review Comment: https://git.openjdk.org/jdk/pull/27438#discussion_r2375792997 From myankelevich at openjdk.org Wed Sep 24 13:32:50 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 24 Sep 2025 13:32:50 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 12:50:10 GMT, Matthew Donovan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed id > > test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 82: > >> 80: >> 81: public static void main(String[] args) throws Exception { >> 82: if (args.length>0 && "new-alg".equals(args[0])){ > > The parameter passed for the sha3 tests is "new-algS" so this will always run the SHA algorithms. If you keep the SHA3 tests, I suggest renaming the parameter to sha3 in the @run instruction and here. Missed this one, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2375812191 From coffeys at openjdk.org Wed Sep 24 13:39:03 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 24 Sep 2025 13:39:03 GMT Subject: RFR: 8044609: javax.net.debug options not working and documented as expected [v22] In-Reply-To: References: Message-ID: > The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago. > > Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. > > The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options : > > > System.err.println("help print the help messages"); > System.err.println("expand expand debugging information"); > System.err.println(); > System.err.println("all turn on all debugging"); > System.err.println("ssl turn on ssl debugging"); > System.err.println(); > System.err.println("The following can be used with ssl:"); > System.err.println("\trecord enable per-record tracing"); > System.err.println("\thandshake print each handshake message"); > System.err.println("\tkeygen print key generation data"); > System.err.println("\tsession print session activity"); > System.err.println("\tdefaultctx print default SSL initialization"); > System.err.println("\tsslctx print SSLContext tracing"); > System.err.println("\tsessioncache print session cache tracing"); > System.err.println("\tkeymanager print key manager tracing"); > System.err.println("\ttrustmanager print trust manager tracing"); > System.err.println("\tpluggability print pluggability tracing"); > System.err.println(); > System.err.println("\thandshake debugging can be widened with:"); > System.err.println("\tdata hex dump of each handshake message"); > System.err.println("\tverbose verbose handshake message printing"); > System.err.println(); > System.err.println("\trecord debugging can be widened with:"); > System.err.println("\tplaintext hex dump of record plaintext"); > System.err.println("\tpacket print raw SSL/TLS packets"); > > > as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. > > the output has changed slightly with respect to that - less verbose > > e.g. old style: > > > javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut... Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge branch 'master' into 8044609-ssl - Incorporate review comments from Brad - Merge branch 'master' into 8044609-ssl - Further review comments, copyright years also - Initial review comments from Brad - Merge branch 'master' into 8044609-ssl - 1 file omitted during merge - Merge branch 'master' into 8044609-ssl - Merge branch 'master' into 8044609-ssl - Merge branch 'master' into 8044609-ssl - ... and 30 more: https://git.openjdk.org/jdk/compare/47efe3c7...4d4af430 ------------- Changes: https://git.openjdk.org/jdk/pull/18764/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=21 Stats: 1332 lines in 84 files changed: 483 ins; 87 del; 762 mod Patch: https://git.openjdk.org/jdk/pull/18764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764 PR: https://git.openjdk.org/jdk/pull/18764 From myankelevich at openjdk.org Wed Sep 24 13:56:01 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 24 Sep 2025 13:56:01 GMT Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip [v3] In-Reply-To: References: Message-ID: > * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java > * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java > * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java > * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java > * test/jdk/sun/security/pkcs11/Signature/TestDSA.java Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: name changes for arrays ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27367/files - new: https://git.openjdk.org/jdk/pull/27367/files/e390ba72..e4f20a3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27367&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27367&range=01-02 Stats: 19 lines in 2 files changed: 6 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27367.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27367/head:pull/27367 PR: https://git.openjdk.org/jdk/pull/27367 From mullan at openjdk.org Wed Sep 24 14:05:45 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 24 Sep 2025 14:05:45 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> Message-ID: On Wed, 24 Sep 2025 02:57:12 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > fix behavior with keytool src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1953: > 1951: private void processMacData(AlgorithmParameterSpec params, > 1952: MacData macData, char[] password, byte[] data, String macAlgorithm) > 1953: throws Exception { Try just throwing the exceptions that can be thrown by code in this method, rather than `Exception` for everything. I know there is a "try/catch (Exception)" block in `engineLoad` when calling this method, but I think it is cleaner to only declare the exceptions that can be thrown here. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2214: > 2212: new PBEParameterSpec(salt, ic); > 2213: processMacData(params, macData, password, authSafeData, > 2214: macAlgorithm); These 4 lines can be moved below after the if/else block since they are the same for both conditions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2375772213 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2375760985 From mullan at openjdk.org Wed Sep 24 14:05:49 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 24 Sep 2025 14:05:49 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 18:15:00 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> default salt length and one other comment from Weijun > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2196: > >> 2194: String algName = >> 2195: macData.getDigestAlgName().toUpperCase(Locale.ENGLISH); >> 2196: if (algName.equals("PBMAC1")) { > > We should manage to move algorithm-specific logic inside `MacData` as much as possible, ideally everything. For example, instead of letting `macData.getDigestAlgName()` returning either "HmacSHA256" or "PBMAC1", it should return the final `macAlgorithm` we need. If the calculation and verification must be different, they can also be moved into `MacData`. This makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2375918643 From duke at openjdk.org Wed Sep 24 14:32:00 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Wed, 24 Sep 2025 14:32:00 GMT Subject: RFR: 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body In-Reply-To: <2fEQEVpM6Am0iixQ8KYccfqEgyp4aUnGtS8atKjNIxM=.5403a452-de2b-4547-ad4c-6880bd0969f7@github.com> References: <2fEQEVpM6Am0iixQ8KYccfqEgyp4aUnGtS8atKjNIxM=.5403a452-de2b-4547-ad4c-6880bd0969f7@github.com> Message-ID: On Wed, 24 Sep 2025 13:27:54 GMT, Daniel Jeli?ski wrote: > Or do we never generate empty plaintexts? That seems to be the case: both [SSLEngine](https://github.c?om/openjdk/jdk/blob/735afd93bbdd63d53dc4cec0ac970026ac95cc64/src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java#L216-L223) and [SSLSocket](https://github.com/openjdk/jdk/blob/735afd93bbdd63d53dc4cec0ac970026ac95cc64/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java#L1278-L1286) skip them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27438#issuecomment-3328830107 From duke at openjdk.org Wed Sep 24 14:55:57 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Wed, 24 Sep 2025 14:55:57 GMT Subject: RFR: 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body [v2] In-Reply-To: References: Message-ID: > According to RFC 8446 section 5.4, third paragraph >> Application Data records may contain a zero-length >> TLSInnerPlaintext.content if the sender desires. This permits >> generation of plausibly sized cover traffic in contexts where the >> presence or absence of activity may be sensitive. Implementations >> MUST NOT send Handshake and Alert records that have a zero-length >> TLSInnerPlaintext.content; if such a message is received, the >> receiving implementation MUST terminate the connection with an >> "unexpected_message" alert. > > > The proposed change removes an off by 1 error in the SSLCipher implementation, forces the correct Alert message to be sent in response to zero-length Alert fragments, as well as updating some tests which detected the BadPaddingException but now detect a SSLProtocolException, which is thrown by `TransportContext.fatal` Alice Pellegrini has updated the pull request incrementally with one additional commit since the last revision: Update copyright, apply suggestions from review, more consistent style for for loop between the two ciphers Co-authored-by: Daniel Jelinski ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27438/files - new: https://git.openjdk.org/jdk/pull/27438/files/6a99f91a..a76fa9c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27438&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27438&range=00-01 Stats: 7 lines in 3 files changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27438.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27438/head:pull/27438 PR: https://git.openjdk.org/jdk/pull/27438 From djelinski at openjdk.org Wed Sep 24 15:25:09 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Sep 2025 15:25:09 GMT Subject: RFR: 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 14:55:57 GMT, Alice Pellegrini wrote: >> According to RFC 8446 section 5.4, third paragraph >>> Application Data records may contain a zero-length >>> TLSInnerPlaintext.content if the sender desires. This permits >>> generation of plausibly sized cover traffic in contexts where the >>> presence or absence of activity may be sensitive. Implementations >>> MUST NOT send Handshake and Alert records that have a zero-length >>> TLSInnerPlaintext.content; if such a message is received, the >>> receiving implementation MUST terminate the connection with an >>> "unexpected_message" alert. >> >> >> The proposed change removes an off by 1 error in the SSLCipher implementation, forces the correct Alert message to be sent in response to zero-length Alert fragments, as well as updating some tests which detected the BadPaddingException but now detect a SSLProtocolException, which is thrown by `TransportContext.fatal` > > Alice Pellegrini has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright, apply suggestions from review, more consistent style for for loop between the two ciphers > > Co-authored-by: Daniel Jelinski LGTM. Thanks! ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27438#pullrequestreview-3263449324 From duke at openjdk.org Wed Sep 24 15:34:53 2025 From: duke at openjdk.org (duke) Date: Wed, 24 Sep 2025 15:34:53 GMT Subject: RFR: 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 14:55:57 GMT, Alice Pellegrini wrote: >> According to RFC 8446 section 5.4, third paragraph >>> Application Data records may contain a zero-length >>> TLSInnerPlaintext.content if the sender desires. This permits >>> generation of plausibly sized cover traffic in contexts where the >>> presence or absence of activity may be sensitive. Implementations >>> MUST NOT send Handshake and Alert records that have a zero-length >>> TLSInnerPlaintext.content; if such a message is received, the >>> receiving implementation MUST terminate the connection with an >>> "unexpected_message" alert. >> >> >> The proposed change removes an off by 1 error in the SSLCipher implementation, forces the correct Alert message to be sent in response to zero-length Alert fragments, as well as updating some tests which detected the BadPaddingException but now detect a SSLProtocolException, which is thrown by `TransportContext.fatal` > > Alice Pellegrini has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright, apply suggestions from review, more consistent style for for loop between the two ciphers > > Co-authored-by: Daniel Jelinski @friedbyalice Your change (at version a76fa9c3fc50b92947659c638bbfb7437ac5c6b0) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27438#issuecomment-3329457790 From abarashev at openjdk.org Wed Sep 24 15:41:29 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 24 Sep 2025 15:41:29 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers In-Reply-To: References: Message-ID: <4SnGK3zK3T2XNY4fn733_qqMrRGwkBSwZQfrBOX5mgk=.74c7da42-6f91-404e-9eee-af603eada3da@github.com> On Wed, 24 Sep 2025 08:08:11 GMT, Daniel Jeli?ski wrote: > Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. > > I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. > > Tier1-3 tests continue to pass. test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java line 35: > 33: * @run main/othervm/timeout=120 -Djdk.tls.client.protocols=TLSv1.2 > 34: * -Djdk.tls.useExtendedMasterSecret=false > 35: * -Djdk.tls.client.enableSessionTicketExtension=false FipsModeTLS12 Why do we need to set `jdk.tls.client.enableSessionTicketExtension` to false? test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java line 282: > 280: SSLEngine clientSSLEngine = engineToTest[0]; > 281: SSLEngine serverSSLEngine = engineToTest[1]; > 282: // Check that session resumption works I would put more details in this comment about what exactly we are testing here: stateless session ticket decryption using the most preferred currently installed provider - NSS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27463#discussion_r2376211880 PR Review Comment: https://git.openjdk.org/jdk/pull/27463#discussion_r2376204562 From mpowers at openjdk.org Wed Sep 24 15:53:14 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 24 Sep 2025 15:53:14 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> Message-ID: On Wed, 24 Sep 2025 13:23:44 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> fix behavior with keytool > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1487: > >> 1485: int writeIterationCount = macIterationCount; >> 1486: >> 1487: if (newKeystore) { > > I cannot see how `newKeystore` is useful. Back when it's set to true, `macAlgorithm` was also set to `defaultMacAlgorithm()`. Therefore there is no need to try `defaultMacAlgorithm()` again below. As for `writeIterationCount`, for a new keystore it is -1, so we can use this to decide whether it should be assigned `defaultMacIterationCount()`. `newKeystore` and `macAlgorithm` are not always set together. When creating a keystore, they are both set, but when reading a keystore only `macAlgorithm` is set. So if I read first and then write (no create), `newKeystore` will not be set. Therefore, I can't remove `newKeystore` and only use `macAlgorithm` if that's what you're suggesting. I agree that `defaultMacAlgorithm()` can be replaced by `macAlgorithm` on lines 1489 and 1490. `writeIterationCount` is initialized to `defaultMacIterationCount()` on. line 1253 so it is never -1 when `calculateMac` is entered. `writeIterationCount` is also set when a keystore is read (lines 2209 and 2220). I probably shouldn't be doing that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2376265799 From mpowers at openjdk.org Wed Sep 24 16:00:53 2025 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 24 Sep 2025 16:00:53 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> Message-ID: <4Ws4EnpXUanfhcF5Mvh0No4Vi7g6hEwBDN1Mkn6moFI=.248ecf09-a866-4c8f-b7ba-278d3376cf2e@github.com> On Wed, 24 Sep 2025 15:50:21 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1487: >> >>> 1485: int writeIterationCount = macIterationCount; >>> 1486: >>> 1487: if (newKeystore) { >> >> I cannot see how `newKeystore` is useful. Back when it's set to true, `macAlgorithm` was also set to `defaultMacAlgorithm()`. Therefore there is no need to try `defaultMacAlgorithm()` again below. As for `writeIterationCount`, for a new keystore it is -1, so we can use this to decide whether it should be assigned `defaultMacIterationCount()`. > > `newKeystore` and `macAlgorithm` are not always set together. When creating a keystore, they are both set, but when reading a keystore only `macAlgorithm` is set. So if I read first and then write (no create), `newKeystore` will not be set. Therefore, I can't remove `newKeystore` and only use `macAlgorithm` if that's what you're suggesting. > > I agree that `defaultMacAlgorithm()` can be replaced by `macAlgorithm` on lines 1489 and 1490. > > `writeIterationCount` is initialized to `defaultMacIterationCount()` on. line 1253 so it is never -1 when `calculateMac` is entered. `writeIterationCount` is also set when a keystore is read (lines 2209 and 2220). I probably shouldn't be doing that. Maybe `macAlgorithm` shouldn't be set when reading a keystore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2376288340 From djelinski at openjdk.org Wed Sep 24 16:03:06 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Sep 2025 16:03:06 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers In-Reply-To: <4SnGK3zK3T2XNY4fn733_qqMrRGwkBSwZQfrBOX5mgk=.74c7da42-6f91-404e-9eee-af603eada3da@github.com> References: <4SnGK3zK3T2XNY4fn733_qqMrRGwkBSwZQfrBOX5mgk=.74c7da42-6f91-404e-9eee-af603eada3da@github.com> Message-ID: On Wed, 24 Sep 2025 15:36:47 GMT, Artur Barashev wrote: >> Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. >> >> I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. >> >> Tier1-3 tests continue to pass. > > test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java line 35: > >> 33: * @run main/othervm/timeout=120 -Djdk.tls.client.protocols=TLSv1.2 >> 34: * -Djdk.tls.useExtendedMasterSecret=false >> 35: * -Djdk.tls.client.enableSessionTicketExtension=false FipsModeTLS12 > > Why do we need to set `jdk.tls.client.enableSessionTicketExtension` to false? because with TLS 1.2, the server can't produce a stateless ticket; it fails when trying to extract the master secret. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27463#discussion_r2376293874 From djelinski at openjdk.org Wed Sep 24 16:06:35 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 24 Sep 2025 16:06:35 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers In-Reply-To: <4SnGK3zK3T2XNY4fn733_qqMrRGwkBSwZQfrBOX5mgk=.74c7da42-6f91-404e-9eee-af603eada3da@github.com> References: <4SnGK3zK3T2XNY4fn733_qqMrRGwkBSwZQfrBOX5mgk=.74c7da42-6f91-404e-9eee-af603eada3da@github.com> Message-ID: On Wed, 24 Sep 2025 15:34:55 GMT, Artur Barashev wrote: >> Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. >> >> I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. >> >> Tier1-3 tests continue to pass. > > test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java line 282: > >> 280: SSLEngine clientSSLEngine = engineToTest[0]; >> 281: SSLEngine serverSSLEngine = engineToTest[1]; >> 282: // Check that session resumption works > > I would put more details in this comment about what exactly we are testing here: stateless session ticket decryption using the most preferred currently installed provider - NSS. well, thing is, we only check that the session resumption works. The TLS 1.2 case is testing the stateful resumption, the TLS 1.3 case is testing the stateless resumption, end to end. Stateless session ticket decryption just happens to be the only detail that needed to be fixed for the session resumption to work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27463#discussion_r2376303887 From abarashev at openjdk.org Wed Sep 24 16:43:35 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 24 Sep 2025 16:43:35 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers In-Reply-To: References: Message-ID: <-ZtvsgFWfI49pcYP3KMBvVxa78pPjaXUi54-XinbV00=.84095acc-a8f7-4a72-93ec-f23b5479bfa4@github.com> On Wed, 24 Sep 2025 08:08:11 GMT, Daniel Jeli?ski wrote: > Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. > > I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. > > Tier1-3 tests continue to pass. test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java line 106: > 104: > 105: // Self-integrity test (complete TLS communication) > 106: testTLS12SunPKCS11Communication.initSslContext(); Should we rename `testTLS12SunPKCS11Communication` method to `testTLSSunPKCS11Communication` now that we test TLSv1.3 also? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27463#discussion_r2376394488 From weijun at openjdk.org Wed Sep 24 16:44:41 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 24 Sep 2025 16:44:41 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: <4Ws4EnpXUanfhcF5Mvh0No4Vi7g6hEwBDN1Mkn6moFI=.248ecf09-a866-4c8f-b7ba-278d3376cf2e@github.com> References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> <4Ws4EnpXUanfhcF5Mvh0No4Vi7g6hEwBDN1Mkn6moFI=.248ecf09-a866-4c8f-b7ba-278d3376cf2e@github.com> Message-ID: <3-4I8Ao43vrp0yAxzpHD0AU14ON4oza9h8KPrV_Hcpo=.451a4dac-d9bc-4ab3-a308-f83c2f6e2c99@github.com> On Wed, 24 Sep 2025 15:58:16 GMT, Mark Powers wrote: >> `newKeystore` and `macAlgorithm` are not always set together. When creating a keystore, they are both set, but when reading a keystore only `macAlgorithm` is set. So if I read first and then write (no create), `newKeystore` will not be set. Therefore, I can't remove `newKeystore` and only use `macAlgorithm` if that's what you're suggesting. >> >> I agree that `defaultMacAlgorithm()` can be replaced by `macAlgorithm` on lines 1489 and 1490. >> >> `writeIterationCount` is initialized to `defaultMacIterationCount()` on. line 1253 so it is never -1 when `calculateMac` is entered. `writeIterationCount` is also set when a keystore is read (lines 2209 and 2220). I probably shouldn't be doing that. > > Maybe `macAlgorithm` shouldn't be set when reading a keystore. There is no difference whether `newKeystore` is true or false. Yes, I can see `writeIterationCount` has already been set to `defaultMacIterationCount()` before, but then there is no need to set it to the same value again here. `macAlgorithm` needs to be set when reading a keystore. This ensures when `store` is called, the original algorithm is used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2376395823 From weijun at openjdk.org Wed Sep 24 16:51:03 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 24 Sep 2025 16:51:03 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: <3-4I8Ao43vrp0yAxzpHD0AU14ON4oza9h8KPrV_Hcpo=.451a4dac-d9bc-4ab3-a308-f83c2f6e2c99@github.com> References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> <4Ws4EnpXUanfhcF5Mvh0No4Vi7g6hEwBDN1Mkn6moFI=.248ecf09-a866-4c8f-b7ba-278d3376cf2e@github.com> <3-4I8Ao43vrp0yAxzpHD0AU14ON4oza9h8KPrV_Hcpo=.451a4dac-d9bc-4ab3-a308-f83c2f6e2c99@github.com> Message-ID: <6msqSRuJOehVa1Ib63ms-lcQukjVNt6Ctz1mqeYxV9g=.83b7dd10-c1e0-4062-a8a8-0ac989b60a7d@github.com> On Wed, 24 Sep 2025 16:41:33 GMT, Weijun Wang wrote: >> Maybe `macAlgorithm` shouldn't be set when reading a keystore. > > There is no difference whether `newKeystore` is true or false. Yes, I can see `writeIterationCount` has already been set to `defaultMacIterationCount()` before, but then there is no need to set it to the same value again here. > > `macAlgorithm` needs to be set when reading a keystore. This ensures when `store` is called, the original algorithm is used. The `macAlgorithm` and `writeIterationCount` fields are initialized to be null and -1. When reading a keystore, they are filled with the actual values. When storing a keystore, if they are still null or -1, default values are used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2376409359 From weijun at openjdk.org Wed Sep 24 16:56:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 24 Sep 2025 16:56:18 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> Message-ID: On Wed, 24 Sep 2025 13:24:49 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> fix behavior with keytool > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1493: > >> 1491: if (!(kdfHmac.equals("HmacSHA512") || >> 1492: kdfHmac.equals("HmacSHA256"))) { >> 1493: kdfHmac = pbmac1Hmac; // use value associated with keystore > > `pbmac1Hmac` is probably null now. If you decide to reject other algorithms (which I don't find necessary), error out. Why is `pbmac1Hmac` necessary? Do we want to support writing with different PRF and HMAC? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2376426464 From valeriep at openjdk.org Wed Sep 24 18:55:46 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 Sep 2025 18:55:46 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers In-Reply-To: References: Message-ID: <-5yvKjfT_KsTkusNyAmlElJ5lgnXnKxmFvaHmO3yEp0=.36c3105d-a0fc-4391-aafa-1b85c36af07d@github.com> On Wed, 24 Sep 2025 08:08:11 GMT, Daniel Jeli?ski wrote: > Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. > > I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. > > Tier1-3 tests continue to pass. Generally looks ok, just minor comment. src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 282: > 280: > 281: ByteBuffer out = ByteBuffer.allocate( > 282: c.getOutputSize(data.remaining())); add a comment to recommend about using the getOutputSize() output for buffer size. Maybe include this bug id for future reference. ------------- PR Review: https://git.openjdk.org/jdk/pull/27463#pullrequestreview-3264249497 PR Review Comment: https://git.openjdk.org/jdk/pull/27463#discussion_r2376759921 From valeriep at openjdk.org Wed Sep 24 18:55:49 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 Sep 2025 18:55:49 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers In-Reply-To: <-ZtvsgFWfI49pcYP3KMBvVxa78pPjaXUi54-XinbV00=.84095acc-a8f7-4a72-93ec-f23b5479bfa4@github.com> References: <-ZtvsgFWfI49pcYP3KMBvVxa78pPjaXUi54-XinbV00=.84095acc-a8f7-4a72-93ec-f23b5479bfa4@github.com> Message-ID: On Wed, 24 Sep 2025 16:41:01 GMT, Artur Barashev wrote: >> Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. >> >> I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. >> >> Tier1-3 tests continue to pass. > > test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java line 106: > >> 104: >> 105: // Self-integrity test (complete TLS communication) >> 106: testTLS12SunPKCS11Communication.initSslContext(); > > Should we rename `testTLS12SunPKCS11Communication` class to `testTLSSunPKCS11Communication` now that we test TLSv1.3 also? +1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27463#discussion_r2376752590 From mullan at openjdk.org Wed Sep 24 19:31:20 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 24 Sep 2025 19:31:20 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> Message-ID: On Wed, 24 Sep 2025 02:57:12 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > fix behavior with keytool src/java.base/share/classes/sun/security/pkcs12/MacData.java line 94: > 92: pbeSpec = > 93: this.digestAlgorithmParams.getParameterSpec( > 94: PBEParameterSpec.class); I think you may already be working on this, so mainly registering this as a comment. This code should be replaced with an internal method that calls `AlgorithmId.getEncodedParams()` and decodes the parameters, reusing much of the code you have already written in `PBMAC1Parameters.engineInit()`. This will avoid having to create an `AlgorithmParameters` implementation as part of this feature, which isn't strictly needed. We can consider adding that on a follow-on Enhancement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2376844304 From abarashev at openjdk.org Wed Sep 24 21:20:23 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 24 Sep 2025 21:20:23 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v8] In-Reply-To: References: Message-ID: <4xX7Ff80H0dFXr6u412P5tItM2DfqilpQRmClbcWIDk=.6a172038-dba3-480c-8429-a1249d1b323f@github.com> > [JDK-8349583](https://bugs.openjdk.org/browse/JDK-8349583) implementation assumes that OpenJDK client always sends "signature_algorithms_cert" extension together with "signature_algorithms" extension. But we didn't account for `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties which can disable producing "signature_algorithms_cert" extension. This is an issue similar to [JDK-8355779](https://bugs.openjdk.org/browse/JDK-8355779) but on the extension producing side. > > Per TLSv1.3 RFC: > >> If no "signature_algorithms_cert" extension is >> present, then the "signature_algorithms" extension also applies to >> signatures appearing in certificates. > > Also making a few cosmetic changes to the existing code. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Update the tests summary discription ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26887/files - new: https://git.openjdk.org/jdk/pull/26887/files/360ac544..41f76ebc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26887&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26887&range=06-07 Stats: 12 lines in 3 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26887.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26887/head:pull/26887 PR: https://git.openjdk.org/jdk/pull/26887 From abarashev at openjdk.org Wed Sep 24 21:20:25 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 24 Sep 2025 21:20:25 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v7] In-Reply-To: References: <2VVdtcE6GbqW-bPOssH1iIq1TPKwON1E58yQPXlA6Yw=.98ef5dd1-aa77-495f-982a-76f65d35ec89@github.com> Message-ID: <24gAWRkDnvJPeg5ZrERVX0uoDNID77cDGXx3ADuQBhU=.da647fd9-cd5a-4606-908d-2faf48b3e7ea@github.com> On Wed, 24 Sep 2025 01:44:04 GMT, Hai-May Chao wrote: > The @summary in DisableCertSignAlgsExtForServerTLS13, DisableCertSignAlgsExtForClientTLS13, and DisableCertSignAlgsExtForClientTLS12 are identical. Suggest to include difference from client or sever perspective, and protocol version. Done, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26887#issuecomment-3330742665 From hchao at openjdk.org Thu Sep 25 01:42:54 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Thu, 25 Sep 2025 01:42:54 GMT Subject: RFR: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent [v8] In-Reply-To: <4xX7Ff80H0dFXr6u412P5tItM2DfqilpQRmClbcWIDk=.6a172038-dba3-480c-8429-a1249d1b323f@github.com> References: <4xX7Ff80H0dFXr6u412P5tItM2DfqilpQRmClbcWIDk=.6a172038-dba3-480c-8429-a1249d1b323f@github.com> Message-ID: On Wed, 24 Sep 2025 21:20:23 GMT, Artur Barashev wrote: >> [JDK-8349583](https://bugs.openjdk.org/browse/JDK-8349583) implementation assumes that OpenJDK client always sends "signature_algorithms_cert" extension together with "signature_algorithms" extension. But we didn't account for `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties which can disable producing "signature_algorithms_cert" extension. This is an issue similar to [JDK-8355779](https://bugs.openjdk.org/browse/JDK-8355779) but on the extension producing side. >> >> Per TLSv1.3 RFC: >> >>> If no "signature_algorithms_cert" extension is >>> present, then the "signature_algorithms" extension also applies to >>> signatures appearing in certificates. >> >> Also making a few cosmetic changes to the existing code. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Update the tests summary discription Changes look good. ------------- Marked as reviewed by hchao (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26887#pullrequestreview-3265229319 From duke at openjdk.org Thu Sep 25 08:47:32 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Thu, 25 Sep 2025 08:47:32 GMT Subject: Integrated: 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body In-Reply-To: References: Message-ID: <6Sj2uZ6o2y_jrEImLuf3Gx7BGQX7KPU4vNuTqUiwPo4=.19356964-2c52-4afd-86f9-c6a0a4343fee@github.com> On Mon, 22 Sep 2025 20:20:19 GMT, Alice Pellegrini wrote: > According to RFC 8446 section 5.4, third paragraph >> Application Data records may contain a zero-length >> TLSInnerPlaintext.content if the sender desires. This permits >> generation of plausibly sized cover traffic in contexts where the >> presence or absence of activity may be sensitive. Implementations >> MUST NOT send Handshake and Alert records that have a zero-length >> TLSInnerPlaintext.content; if such a message is received, the >> receiving implementation MUST terminate the connection with an >> "unexpected_message" alert. > > > The proposed change removes an off by 1 error in the SSLCipher implementation, forces the correct Alert message to be sent in response to zero-length Alert fragments, as well as updating some tests which detected the BadPaddingException but now detect a SSLProtocolException, which is thrown by `TransportContext.fatal` This pull request has now been integrated. Changeset: ba44656b Author: Alice Pellegrini Committer: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/ba44656b97b7103d96718452e300df8a6bd59c87 Stats: 24 lines in 4 files changed: 10 ins; 1 del; 13 mod 8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body Co-authored-by: Daniel Jeli?ski Reviewed-by: djelinski ------------- PR: https://git.openjdk.org/jdk/pull/27438 From mullan at openjdk.org Thu Sep 25 12:02:32 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 25 Sep 2025 12:02:32 GMT Subject: RFR: 8360882: Tests throw SkippedException when they should fail [v5] In-Reply-To: References: <7V3ntm_1Bm823DmTwJt9rcUFZnrbqAc-DuVGoFR6_Gk=.dff492db-be0f-4332-848b-badcc7b921f6@github.com> Message-ID: On Tue, 2 Sep 2025 15:23:09 GMT, Matthew Donovan wrote: >> This PR updates `ArtifactResolver.fetchOne()` to throw an IOException instead of SkippedException. This allows tests to determine of a missing "artifact" should be treated as a failed or skipped test.`OpensslArtifactFetcher` is also updated to only throw SkippedException if OpenSSL is not available on the test platform. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > fixed whitespace error Seems ok to me. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26868#pullrequestreview-3267312863 From mdonovan at openjdk.org Thu Sep 25 12:18:37 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 25 Sep 2025 12:18:37 GMT Subject: Integrated: 8360882: Tests throw SkippedException when they should fail In-Reply-To: <7V3ntm_1Bm823DmTwJt9rcUFZnrbqAc-DuVGoFR6_Gk=.dff492db-be0f-4332-848b-badcc7b921f6@github.com> References: <7V3ntm_1Bm823DmTwJt9rcUFZnrbqAc-DuVGoFR6_Gk=.dff492db-be0f-4332-848b-badcc7b921f6@github.com> Message-ID: On Wed, 20 Aug 2025 19:57:59 GMT, Matthew Donovan wrote: > This PR updates `ArtifactResolver.fetchOne()` to throw an IOException instead of SkippedException. This allows tests to determine of a missing "artifact" should be treated as a failed or skipped test.`OpensslArtifactFetcher` is also updated to only throw SkippedException if OpenSSL is not available on the test platform. This pull request has now been integrated. Changeset: 26b5708c Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/26b5708c47150023798a1546ba095c1b0b7807e1 Stats: 38 lines in 3 files changed: 15 ins; 8 del; 15 mod 8360882: Tests throw SkippedException when they should fail Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/26868 From duke at openjdk.org Thu Sep 25 12:44:33 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 12:44:33 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v15] In-Reply-To: References: Message-ID: > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: - Merge branch 'openjdk:master' into jdk-8360498 - Removes not needed changes - Revert "Removes not needed changes" This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb. - Removes not needed changes - Removes extra white lines - Merge branch 'pr/25971' into jdk-8360498 - Merge branch 'openjdk:master' into jdk-8158801 - Merge branch 'pr/25971' into jdk-8360498 - Merge branch 'openjdk:master' into jdk-8158801 - Centers missed frames in the middle of screen - ... and 64 more: https://git.openjdk.org/jdk/compare/26b5708c...e5753d14 ------------- Changes: https://git.openjdk.org/jdk/pull/26625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14 Stats: 185 lines in 14 files changed: 96 ins; 44 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From duke at openjdk.org Thu Sep 25 13:03:51 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 13:03:51 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: References: Message-ID: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: Resolves confict for when there is a merge with jdk-8158801 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26625/files - new: https://git.openjdk.org/jdk/pull/26625/files/e5753d14..8794db9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14-15 Stats: 55 lines in 1 file changed: 36 ins; 3 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From mullan at openjdk.org Thu Sep 25 13:14:23 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 25 Sep 2025 13:14:23 GMT Subject: RFR: 8367096: jdk/open/test/jdk/sun/security/pkcs11/ rsa, ec, config, secmod and sslecc tests are skipping but showing as pass [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 10:57:38 GMT, Mikhail Yankelevich wrote: >> Tests changed: >> * test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java >> * test/jdk/sun/security/pkcs11/PKCS11Test.java >> * test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java >> * test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java >> * test/jdk/sun/security/pkcs11/Secmod/Crypto.java >> * test/jdk/sun/security/pkcs11/Secmod/GetPrivateKey.java >> * test/jdk/sun/security/pkcs11/Secmod/JksSetPrivateKey.java >> * test/jdk/sun/security/pkcs11/Secmod/LoadKeystore.java >> * test/jdk/sun/security/pkcs11/Secmod/TestNssDbSqlite.java >> * test/jdk/sun/security/pkcs11/Secmod/TrustAnchors.java >> * test/jdk/sun/security/pkcs11/SecmodTest.java >> * test/jdk/sun/security/pkcs11/ec/ReadCertificates.java >> * test/jdk/sun/security/pkcs11/ec/ReadPKCS12.java >> * test/jdk/sun/security/pkcs11/ec/TestKeyFactory.java >> * test/jdk/sun/security/pkcs11/rsa/KeyWrap.java >> * test/jdk/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > Delete accidental file test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java line 65: > 63: > 64: public static void main(String[] args) throws Exception { > 65: initSecmod(); Does `initSecmod` ever return false? Should we change the return type to a void then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27166#discussion_r2379035270 From alanb at openjdk.org Thu Sep 25 13:30:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Sep 2025 13:30:34 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> References: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> Message-ID: On Thu, 25 Sep 2025 13:03:51 GMT, Khalid Boulanouare wrote: >> This PR will consolidate fixes of the following bugs: >> >> https://bugs.openjdk.org/browse/JDK-8361188 >> https://bugs.openjdk.org/browse/JDK-8361189 >> https://bugs.openjdk.org/browse/JDK-8361190 >> https://bugs.openjdk.org/browse/JDK-8361191 >> https://bugs.openjdk.org/browse/JDK-8361192 >> https://bugs.openjdk.org/browse/JDK-8361193 >> https://bugs.openjdk.org/browse/JDK-8361195 >> >> This PR depends on https://github.com/openjdk/jdk/pull/25971 >> >> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 > > Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: > > Resolves confict for when there is a merge with jdk-8158801 What is this about? The PR suggests 500+ commits and 300+ files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334044893 From duke at openjdk.org Thu Sep 25 14:00:10 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 14:00:10 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: References: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> Message-ID: On Thu, 25 Sep 2025 13:26:46 GMT, Alan Bateman wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Resolves confict for when there is a merge with jdk-8158801 > > What is this about? The PR suggests 500+ commits and 300+ files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists. @AlanBateman This PR is created based on PR https://github.com/openjdk/jdk/tree/pr/25971. My branch https://github.com/kboulanou/jdk/tree/jdk-8360498 is only 2 commits behind master. I am waiting for approval for PR https://github.com/openjdk/jdk/tree/pr/25971 for this PR to follow. Please let me know if there is anything I need to do. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334251324 From duke at openjdk.org Thu Sep 25 14:00:08 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 14:00:08 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v17] In-Reply-To: References: Message-ID: > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'openjdk:master' into jdk-8360498 - 8359378: aarch64: crash when using -XX:+UseFPUForSpilling Reviewed-by: aph, rcastanedalo - 8367103: RISC-V: store cpu features in a bitmap Reviewed-by: fyang, luhenry ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26625/files - new: https://git.openjdk.org/jdk/pull/26625/files/8794db9a..69c087a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15-16 Stats: 214 lines in 3 files changed: 142 ins; 4 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From syan at openjdk.org Thu Sep 25 14:35:39 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 25 Sep 2025 14:35:39 GMT Subject: RFR: 8368677: acvp test should throw SkippedException when no ACVP-Server available Message-ID: Hi all, Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available. ------------- Commit messages: - 8368677: acvp test should throw SkippedException when no ACVP-Server available Changes: https://git.openjdk.org/jdk/pull/27491/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27491&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368677 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27491/head:pull/27491 PR: https://git.openjdk.org/jdk/pull/27491 From abarashev at openjdk.org Thu Sep 25 14:47:59 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 25 Sep 2025 14:47:59 GMT Subject: Integrated: 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent In-Reply-To: References: Message-ID: <68IlitSjGVEskR4_gByhnbSDeWBXzGOTCG3nxjk_VNE=.d13affd9-89eb-4e5b-82ff-309ebb8d3ace@github.com> On Thu, 21 Aug 2025 16:02:05 GMT, Artur Barashev wrote: > [JDK-8349583](https://bugs.openjdk.org/browse/JDK-8349583) implementation assumes that OpenJDK client always sends "signature_algorithms_cert" extension together with "signature_algorithms" extension. But we didn't account for `jdk.tls.client.disableExtensions` and `jdk.tls.server.disableExtensions` system properties which can disable producing "signature_algorithms_cert" extension. This is an issue similar to [JDK-8355779](https://bugs.openjdk.org/browse/JDK-8355779) but on the extension producing side. > > Per TLSv1.3 RFC: > >> If no "signature_algorithms_cert" extension is >> present, then the "signature_algorithms" extension also applies to >> signatures appearing in certificates. > > Also making a few cosmetic changes to the existing code. This pull request has now been integrated. Changeset: 569e7808 Author: Artur Barashev URL: https://git.openjdk.org/jdk/commit/569e78080b3c25c95d85e9e194626f95f86b9b10 Stats: 569 lines in 7 files changed: 516 ins; 33 del; 20 mod 8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent Reviewed-by: hchao ------------- PR: https://git.openjdk.org/jdk/pull/26887 From mullan at openjdk.org Thu Sep 25 14:53:10 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 25 Sep 2025 14:53:10 GMT Subject: RFR: 8367096: jdk/open/test/jdk/sun/security/pkcs11/ rsa, ec, config, secmod and sslecc tests are skipping but showing as pass [v3] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 13:10:34 GMT, Sean Mullan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Delete accidental file > > test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java line 65: > >> 63: >> 64: public static void main(String[] args) throws Exception { >> 65: initSecmod(); > > Does `initSecmod` ever return false? Should we change the return type to a void then? Never mind, I see you made that change already! I had not scrolled down that far yet :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27166#discussion_r2379438255 From djelinski at openjdk.org Thu Sep 25 15:04:11 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 15:04:11 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers [v2] In-Reply-To: References: Message-ID: > Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. > > I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. > > Tier1-3 tests continue to pass. Daniel Jeli?ski has updated the pull request incrementally with four additional commits since the last revision: - Add explanation for getOutputSize - Remove references to TLS 1.2 from class names and paths - Explain why stateless resumption needs to be disabled with TLS 1.2 - Update test comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27463/files - new: https://git.openjdk.org/jdk/pull/27463/files/b70000f1..664b4df7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27463&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27463&range=00-01 Stats: 12 lines in 10 files changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27463.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27463/head:pull/27463 PR: https://git.openjdk.org/jdk/pull/27463 From djelinski at openjdk.org Thu Sep 25 15:04:19 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 15:04:19 GMT Subject: RFR: 8328046: Need to keep leading zeros in TlsPremasterSecret of TLS1.3 DHKeyAgreement In-Reply-To: References: Message-ID: <1962hdcL8wA1jBicqKvPFFQkKysGlx1zCFPA3W1y65M=.2b3bc54f-0645-43d0-885c-3bdadcfaefed@github.com> On Wed, 17 Sep 2025 12:15:10 GMT, Daniel Jeli?ski wrote: > TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved. > > Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved. > > This PR changes the TLS 1.3 handshake to use the new algorithm name. It also fixes a bug in PKCS11 Generic key derivation, and updates the existing tests to verify that the Generic algorithm doesn't strip leading zeroes. > > I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details. > > Tier1-3 tests continue to pass. The `TestLeadingZeroesP11.java` test fails before the `P11KeyAgreement.java` changes, passes after. On second thought, I'll move the PKCS11 changes to a separate issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27343#issuecomment-3334619347 From djelinski at openjdk.org Thu Sep 25 15:04:14 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 15:04:14 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 08:08:11 GMT, Daniel Jeli?ski wrote: > Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. > > I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. > > Tier1-3 tests continue to pass. Thanks @artur-oracle @valeriepeng for the reviews. I added more comments and renamed the test to stop referring to TLS 1.2. Let me know if that addresses your concerns. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27463#issuecomment-3334606865 From djelinski at openjdk.org Thu Sep 25 15:08:31 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 15:08:31 GMT Subject: RFR: 8328046: Need to keep leading zeros in TlsPremasterSecret of TLS1.3 DHKeyAgreement [v2] In-Reply-To: References: Message-ID: <_B985ebMZsq7a3Uo0ettuVbYlGeHHOTAFh_tX2DcGYg=.9f22e1dd-4417-4ee6-abeb-685d2931ab53@github.com> > TLS 1.3 changed the way it generates the FFDHE shared secret. In TLS 1.2, the leading zeroes in the shared secret were stripped, and in TLS 1.3 the leading zeroes are preserved. > > Thanks to the recent work in [JDK-8189441](https://bugs.openjdk.org/browse/JDK-8189441), we now have a new algorithm name `Generic` that can be used to generate a shared secret with the leading zeroes preserved. > > This PR changes the TLS 1.3 handshake to use the new algorithm name. It also fixes a bug in PKCS11 Generic key derivation, and updates the existing tests to verify that the Generic algorithm doesn't strip leading zeroes. > > I didn't add any tests to verify the correctness of the handshake. This can be verified using tlsfuzzer, see JBS for details. > > Tier1-3 tests continue to pass. The `TestLeadingZeroesP11.java` test fails before the `P11KeyAgreement.java` changes, passes after. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Revert PKCS11 changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27343/files - new: https://git.openjdk.org/jdk/pull/27343/files/7c39df58..7104ae3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27343&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27343&range=00-01 Stats: 84 lines in 3 files changed: 23 ins; 51 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27343.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27343/head:pull/27343 PR: https://git.openjdk.org/jdk/pull/27343 From myankelevich at openjdk.org Thu Sep 25 15:14:36 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 25 Sep 2025 15:14:36 GMT Subject: RFR: 8367096: jdk/open/test/jdk/sun/security/pkcs11/ rsa, ec, config, secmod and sslecc tests are skipping but showing as pass [v3] In-Reply-To: References: Message-ID: <6EOYyPPMkPukSmmccG8FCNWvNyy0UYGu7bJq22toYJM=.613e1850-5a35-445b-848c-049d4b3cfc20@github.com> On Thu, 25 Sep 2025 14:49:57 GMT, Sean Mullan wrote: >> test/jdk/sun/security/pkcs11/Secmod/AddPrivateKey.java line 65: >> >>> 63: >>> 64: public static void main(String[] args) throws Exception { >>> 65: initSecmod(); >> >> Does `initSecmod` ever return false? Should we change the return type to a void then? > > Never mind, I see you made that change already! I had not scrolled down that far yet :) Glad I could help :D ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27166#discussion_r2379504202 From jnimeh at openjdk.org Thu Sep 25 15:27:34 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Thu, 25 Sep 2025 15:27:34 GMT Subject: RFR: 8367133: DTLS: fragmentation of Finished message results in handshake failure In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 06:49:06 GMT, Daniel Jeli?ski wrote: > The DTLSReassembler may release a Finished message before assembling all necessary fragments. > > The newly added test fails without the DTLSReassembler changes, passes with the changes. Other tier1-3 tests continue to pass. Marked as reviewed by jnimeh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27284#pullrequestreview-3268327780 From abarashev at openjdk.org Thu Sep 25 16:14:31 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 25 Sep 2025 16:14:31 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:04:11 GMT, Daniel Jeli?ski wrote: >> Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. >> >> I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with four additional commits since the last revision: > > - Add explanation for getOutputSize > - Remove references to TLS 1.2 from class names and paths > - Explain why stateless resumption needs to be disabled with TLS 1.2 > - Update test comment LGTM ------------- Marked as reviewed by abarashev (Committer). PR Review: https://git.openjdk.org/jdk/pull/27463#pullrequestreview-3268532684 From abarashev at openjdk.org Thu Sep 25 16:17:42 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 25 Sep 2025 16:17:42 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers [v2] In-Reply-To: References: Message-ID: <33nIe1-QRExmvuTzGq5A4_wHDt8iO_XGNSdS76Ctcg8=.5b594b5a-6ad8-49ff-b4f8-2d2d830e5134@github.com> On Thu, 25 Sep 2025 16:11:56 GMT, Artur Barashev wrote: >> Daniel Jeli?ski has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add explanation for getOutputSize >> - Remove references to TLS 1.2 from class names and paths >> - Explain why stateless resumption needs to be disabled with TLS 1.2 >> - Update test comment > > LGTM > Thanks @artur-oracle @valeriepeng for the reviews. I added more comments and renamed the test to stop referring to TLS 1.2. Let me know if that addresses your concerns. Thanks for adding more comments and filing JDK-8368669! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27463#issuecomment-3334928316 From weijun at openjdk.org Thu Sep 25 16:49:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 25 Sep 2025 16:49:18 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v6] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: add a warning for non-console interactive UI ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/d57f56c4..9504e8e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=04-05 Stats: 67 lines in 2 files changed: 57 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From djelinski at openjdk.org Thu Sep 25 18:06:08 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 18:06:08 GMT Subject: RFR: 8368694: PKCS11-NSS generic keys generated by DH have leading zeroes stripped Message-ID: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com> The DiffieHellman KeyAgreement supports 2 key algorithms: TlsPremasterSecret and Generic. The Generic algorithm is supposed to generate keys of a constant length, keeping leading zeroes as appropriate. This PR changes the SunPKCS11 implementation to pass a CKA_VALUE_LEN attribute when a fixed length is needed; when the attribute is absent, the PKCS11 provider strips the leading zeroes. Added a check to the existing test cases to verify the fix. The check passes with the fix, fails without it. Other tier1-3 tests continue to pass. ------------- Commit messages: - Fix leading zero handling - Add tests for leading zero handling Changes: https://git.openjdk.org/jdk/pull/27494/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27494&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368694 Stats: 71 lines in 3 files changed: 50 ins; 13 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27494.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27494/head:pull/27494 PR: https://git.openjdk.org/jdk/pull/27494 From valeriep at openjdk.org Thu Sep 25 18:14:24 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 Sep 2025 18:14:24 GMT Subject: Integrated: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 23:39:54 GMT, Valerie Peng wrote: > This PR is for clarifying the `NoSuchAlgorithmException` and `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, Provider provider)` and `Cipher.getInstance(String transformation, String provider)` methods. > > As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to register their implementations through various sub-transformations. As a result, depending on how the providers register the implementation, it may lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" as the valid input for setting mode and padding). Calling `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This javadoc update hope to make it clear. > > Thanks in advance for the review~ > Valerie This pull request has now been integrated. Changeset: 5c596e2a Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/5c596e2a9599e1e0eb9ec845f1b6e0e7b59f186a Stats: 56 lines in 2 files changed: 13 ins; 2 del; 41 mod 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/26489 From djelinski at openjdk.org Thu Sep 25 18:19:39 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 18:19:39 GMT Subject: RFR: 8367133: DTLS: fragmentation of Finished message results in handshake failure In-Reply-To: References: Message-ID: <3ykbGtZHMjwVUSIxEeCE2s3wKog0oy63rMP7UDjDkQc=.b1c56b44-5aa0-4db8-a655-358d9d9f5963@github.com> On Tue, 16 Sep 2025 14:12:43 GMT, Nibedita Jena wrote: >> The DTLSReassembler may release a Finished message before assembling all necessary fragments. >> >> The newly added test fails without the DTLSReassembler changes, passes with the changes. Other tier1-3 tests continue to pass. > > I applied the changes and verified them against both failure and success scenarios. The results look good. Thanks @djelinski Thanks @nibjen @ragkale @jnimeh for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27284#issuecomment-3335341116 From djelinski at openjdk.org Thu Sep 25 18:19:41 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 18:19:41 GMT Subject: Integrated: 8367133: DTLS: fragmentation of Finished message results in handshake failure In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 06:49:06 GMT, Daniel Jeli?ski wrote: > The DTLSReassembler may release a Finished message before assembling all necessary fragments. > > The newly added test fails without the DTLSReassembler changes, passes with the changes. Other tier1-3 tests continue to pass. This pull request has now been integrated. Changeset: 80cb0ead Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/80cb0ead502ae439660f2a3bbab42df4da39d9d6 Stats: 78 lines in 2 files changed: 75 ins; 0 del; 3 mod 8367133: DTLS: fragmentation of Finished message results in handshake failure Reviewed-by: jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/27284 From valeriep at openjdk.org Thu Sep 25 18:20:36 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 Sep 2025 18:20:36 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:04:11 GMT, Daniel Jeli?ski wrote: >> Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. >> >> I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with four additional commits since the last revision: > > - Add explanation for getOutputSize > - Remove references to TLS 1.2 from class names and paths > - Explain why stateless resumption needs to be disabled with TLS 1.2 > - Update test comment Changes look good. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27463#pullrequestreview-3268947987 From djelinski at openjdk.org Thu Sep 25 18:50:48 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 18:50:48 GMT Subject: RFR: 8368514: TLS stateless session ticket decryption fails on some providers [v2] In-Reply-To: <33nIe1-QRExmvuTzGq5A4_wHDt8iO_XGNSdS76Ctcg8=.5b594b5a-6ad8-49ff-b4f8-2d2d830e5134@github.com> References: <33nIe1-QRExmvuTzGq5A4_wHDt8iO_XGNSdS76Ctcg8=.5b594b5a-6ad8-49ff-b4f8-2d2d830e5134@github.com> Message-ID: <5brLGU4Hqoa6Bm1jYh7PE-V1mD1_SaRt1ANxnKWaW3M=.3dad5a25-f28f-4c86-9953-8fdd1cc79779@github.com> On Thu, 25 Sep 2025 16:14:57 GMT, Artur Barashev wrote: >> LGTM > >> Thanks @artur-oracle @valeriepeng for the reviews. I added more comments and renamed the test to stop referring to TLS 1.2. Let me know if that addresses your concerns. > > Thanks for adding more comments and filing JDK-8368669! Thanks @artur-oracle @valeriepeng for the re-reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27463#issuecomment-3335515294 From djelinski at openjdk.org Thu Sep 25 18:50:49 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 18:50:49 GMT Subject: Integrated: 8368514: TLS stateless session ticket decryption fails on some providers In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 08:08:11 GMT, Daniel Jeli?ski wrote: > Please review this trivial patch that fixes stateless session resumption with JCE providers that require extra space for AES/GCM decryption. > > I modified the existing FipsModeTLS12 test to additionally verify that session resumption works. The TLS 1.3 test resumes the session using a stateless ticket; the TLS 1.2 test uses stateful sessions, because stateless ticket creation fails for other reasons. > > Tier1-3 tests continue to pass. This pull request has now been integrated. Changeset: 3c9fd768 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/3c9fd7688f4d73067db9b128c329ca7603a60578 Stats: 40 lines in 10 files changed: 20 ins; 8 del; 12 mod 8368514: TLS stateless session ticket decryption fails on some providers Reviewed-by: valeriep, abarashev ------------- PR: https://git.openjdk.org/jdk/pull/27463 From djelinski at openjdk.org Thu Sep 25 20:19:19 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 25 Sep 2025 20:19:19 GMT Subject: RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider Message-ID: Change SunJSSE to use `TlsUpdateNplus1` instead of `AES` as the key algorithm when deriving the next application traffic secret. SunPKCS11 provider checks the key length when creating an `AES` key, and since 384 bits is not a valid AES key length, the key creation fails. `TlsUpdateNplus1` is [already recognized](https://github.com/openjdk/jdk/blob/3c9fd7688f4d73067db9b128c329ca7603a60578/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L287) as a standard TLS generic key by SunPKCS11. Key update is now exercised by the FipsModeTLS test. The test passes with the changes, fails without them. Other tier1-3 tests continue to pass. ------------- Commit messages: - Fix key update Changes: https://git.openjdk.org/jdk/pull/27498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27498&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368520 Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27498/head:pull/27498 PR: https://git.openjdk.org/jdk/pull/27498 From ascarpino at openjdk.org Thu Sep 25 22:44:03 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 25 Sep 2025 22:44:03 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v3] In-Reply-To: References: Message-ID: > Hi > > Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: > > - Renamed the name of `PEMRecord` class to `PEM`. > - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. > - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. > > thanks > > Tony Anthony Scarpino 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 12 additional commits since the last revision: - review comments and bug fixes - Merge branch 'master' into pem26 - rework test & commented out code. - fix test - simplify - doc and code updates - Merge branch 'master' into pem26 - doc and code updates - Merge branch 'master' into pem26 - Initial - ... and 2 more: https://git.openjdk.org/jdk/compare/09bce958...24be35c1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27147/files - new: https://git.openjdk.org/jdk/pull/27147/files/b2d0defd..24be35c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=01-02 Stats: 164401 lines in 1844 files changed: 133947 ins; 19113 del; 11341 mod Patch: https://git.openjdk.org/jdk/pull/27147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147 PR: https://git.openjdk.org/jdk/pull/27147 From ascarpino at openjdk.org Thu Sep 25 22:44:06 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 25 Sep 2025 22:44:06 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v2] In-Reply-To: <9lDol2Hy2zxBd_cuOV9dYhdBvE2osDrtOAg-F5obVJA=.c68e75e1-c3e2-4978-83cd-ee31d0d96b09@github.com> References: <9lDol2Hy2zxBd_cuOV9dYhdBvE2osDrtOAg-F5obVJA=.c68e75e1-c3e2-4978-83cd-ee31d0d96b09@github.com> Message-ID: On Thu, 18 Sep 2025 14:25:14 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> rework test & commented out code. > > src/java.base/share/classes/java/security/PEM.java line 63: > >> 61: * PRIVATE KEY, ENCRYPTED PRIVATE KEY, RSA PRIVATE KEY, or PUBLIC KEY. >> 62: * >> 63: *

    {@code leadingData} may be null if no non-PEM data preceded PEM header > > Suggest rewording as "... if there was no data preceding the PEM header ..." > > Why do you allow null when there is a ctor that does not have a `leadingData` parameter - is there a reason for this? I thought it was more friendly to specify a constructor when `leadingData` was known to be not needed. The other constructor is used by PEMDecoder decoding is not known until decoding the stream occurs. > src/java.base/share/classes/java/security/PEMEncoder.java line 265: > >> 263: * uses the default encryption parameters of the provider that is selected. >> 264: * For greater flexibility with encryption options and parameters, use >> 265: * {@link EncryptedPrivateKeyInfo#encryptKey(DEREncodable, Key, > > Line 256, did you mean to say "encoded" instead of "encrypted"? i.e.: "Only {@link PrivateKey} objects can be encoded with this newly ..." > > It makes more sense when you read the following sentence. Also the result is an encoding, the encryption is an intermediate step. I agree that "encoded" makes more sense here given the following sentences says encoded. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2377020526 PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2377570024 From ascarpino at openjdk.org Thu Sep 25 22:44:08 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 25 Sep 2025 22:44:08 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v3] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 21:49:05 GMT, Weijun Wang wrote: >> This only checks if one is available in the private key material. If there is none, null is fine. >> >> The domain parameters are kept as part of private key SEC1v2 encoding and can be read when generating a private key with a KeyFactory. Translating the encoding could be error-prone, and maybe incompatible. > > Oh, I meant if both [0] and [1] are there you can skip [0] and read [1]. Currently you just check for [1]. Oh yes, I didn't add a skip. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2380410583 From ascarpino at openjdk.org Thu Sep 25 23:03:11 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 25 Sep 2025 23:03:11 GMT Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic Objects (Second Preview) [v4] In-Reply-To: References: Message-ID: > Hi > > Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API. The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are: > > - Renamed the name of `PEMRecord` class to `PEM`. > - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted. > - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects. > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: missed some decoder comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27147/files - new: https://git.openjdk.org/jdk/pull/27147/files/24be35c1..e13bff47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=02-03 Stats: 14 lines in 1 file changed: 3 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147 PR: https://git.openjdk.org/jdk/pull/27147 From iklam at openjdk.org Fri Sep 26 00:53:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 26 Sep 2025 00:53:16 GMT Subject: RFR: 8357691: File blocked.certs contains bad content when boot jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing In-Reply-To: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com> References: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com> Message-ID: On Thu, 25 Sep 2025 09:10:40 GMT, Matthias Baesken wrote: > When using boot JDK 25 we end up with bad content in lib/security/blocked.certs because cds related warning output shows up there. > > The problem is with extra lines in the generated `blocked.certs` file, at the start of the file there is something like this > > >> [0.010s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details. >> [0.010s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time >> [0.010s][error][cds] Disabling optimized module handling Marked as reviewed by iklam (Reviewer). The fix looks OK to me. Background: when using the default CDS archive, such warnings are disabled. The reason is -- we assume the default archive is general purpose and can be used for different sets of command-lines. We don't print warnings as it's not "wrong" for the app to specify ` --add-exports`. $ ${JAVA_HOME}/bin/java --add-exports=java.base/sun.security.util=ALL-UNNAMED --version java 26-internal 2026-03-17 Java(TM) SE Runtime Environment (build 26-internal-adhoc.iklam.rum) JavaHotSpot(TM) 64-Bit Server VM (build 26-internal-adhoc.iklam.rum, mixed mode, sharing) But when you are using `-XX:SharedArchiveFile` to specify a CDS archive, we assume that the archive has been tailored to the specific application that you're using, so the warnings are printed more eagerly, as you might have unintentionally given an incompatible VM option: $ cp ${JAVA_HOME}/lib/server/classes.jsa foo.jsa $ ${JAVA_HOME}/bin/java -XX:SharedArchiveFile=foo.jsa --add-exports=java.base/sun.security.util=ALL-UNNAMED --version [0.026s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details. [0.026s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time [0.026s][error][cds] Disabling optimized module handling java 26-internal 2026-03-17 Java(TM) SE Runtime Environment (build 26-internal-adhoc.iklam.rum) JavaHotSpot(TM) 64-Bit Server VM (build 26-internal-adhoc.iklam.rum, mixed mode, sharing) In this case, I think the JDK build system creates its own CDS archive with the BOOT JDK, so it falls under the second scenario. Using `-Xlog:cds=off` is appropriate. ------------- PR Review: https://git.openjdk.org/jdk/pull/27485#pullrequestreview-3269822895 PR Comment: https://git.openjdk.org/jdk/pull/27485#issuecomment-3336409510 From mbaesken at openjdk.org Fri Sep 26 07:59:51 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 Sep 2025 07:59:51 GMT Subject: RFR: 8357691: File blocked.certs contains bad content when boot jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing In-Reply-To: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com> References: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com> Message-ID: On Thu, 25 Sep 2025 09:10:40 GMT, Matthias Baesken wrote: > When using boot JDK 25 we end up with bad content in lib/security/blocked.certs because cds related warning output shows up there. > > The problem is with extra lines in the generated `blocked.certs` file, at the start of the file there is something like this > > >> [0.010s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details. >> [0.010s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time >> [0.010s][error][cds] Disabling optimized module handling Hi Ioi , thanks for the detailed explanation, why this happens. And thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27485#issuecomment-3337221857 From mbaesken at openjdk.org Fri Sep 26 07:59:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 Sep 2025 07:59:52 GMT Subject: Integrated: 8357691: File blocked.certs contains bad content when boot jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing In-Reply-To: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com> References: <2HJ2xrOwSIaauzZ9siL_OaVhFEMtKzcChn3c_4fkGqI=.ca3cdf1b-2403-4379-a798-e943eb4ae98b@github.com> Message-ID: <_eurWb9v-Pzr0kciLOuvhvWhoYiwvYbtYEpv6I9Dd4Y=.6b4f8de5-f277-4597-855d-9d4d9172cfdd@github.com> On Thu, 25 Sep 2025 09:10:40 GMT, Matthias Baesken wrote: > When using boot JDK 25 we end up with bad content in lib/security/blocked.certs because cds related warning output shows up there. > > The problem is with extra lines in the generated `blocked.certs` file, at the start of the file there is something like this > > >> [0.010s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details. >> [0.010s][error][cds] Mismatched values for property jdk.module.addexports: java.base/sun.security.util=ALL-UNNAMED specified during runtime but not during dump time >> [0.010s][error][cds] Disabling optimized module handling This pull request has now been integrated. Changeset: a80ba626 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/a80ba6260effdca7a7703c6903f273401b861793 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8357691: File blocked.certs contains bad content when boot jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing Reviewed-by: erikj, iklam ------------- PR: https://git.openjdk.org/jdk/pull/27485 From fandreuzzi at openjdk.org Fri Sep 26 09:49:24 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 26 Sep 2025 09:49:24 GMT Subject: RFR: 8368756: Skip sun/security/provider/acvp/Launcher.java when ACVP-Server artifact isn't found Message-ID: I propose to skip the test when the ACVP-Server artifact isn't found, instead of throwing the following exception: java.io.IOException: Cannot find the artifact ACVP-Server at jdk.test.lib.artifacts.ArtifactResolver.fetchOne(ArtifactResolver.java:100) at Launcher.main(Launcher.java:117) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) at java.base/java.lang.Thread.run(Thread.java:1474) Caused by: jdk.test.lib.artifacts.ArtifactResolverException: Couldn't automatically resolve dependency for ACVP-Server Please specify the location using jdk.test.lib.artifacts.ACVP-Server at jdk.test.lib.artifacts.DefaultArtifactManager.resolve(DefaultArtifactManager.java:39) at jdk.test.lib.artifacts.DefaultArtifactManager.resolve(DefaultArtifactManager.java:32) at jdk.test.lib.artifacts.ArtifactResolver.resolve(ArtifactResolver.java:61) at jdk.test.lib.artifacts.ArtifactResolver.fetchOne(ArtifactResolver.java:96) ... 5 more ------------- Commit messages: - order - skip Changes: https://git.openjdk.org/jdk/pull/27518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27518&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368756 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27518/head:pull/27518 PR: https://git.openjdk.org/jdk/pull/27518 From mullan at openjdk.org Fri Sep 26 13:50:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 26 Sep 2025 13:50:53 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v6] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 16:49:18 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > add a warning for non-console interactive UI src/java.base/share/classes/sun/security/util/Password.java line 77: > 75: // will be silently consumed without echoing to the screen. > 76: System.err.print("[Warning: Console not available." + > 77: " The entered password might be echoed.] "); s/might/may/ I wonder if "echoed" is generally understood by most users. Should we be more clear and say something like " The password entered may be visible on the screen"? Also, consider putting "Warning" in all caps to make it more significant. Also consider breaking into 2 lines, so the second part is not at the end of a long line, ex: WARNING: Console not available WARNING: The password entered may be visible on the screen ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2382485258 From duke at openjdk.org Fri Sep 26 15:42:59 2025 From: duke at openjdk.org (Michael Osipov) Date: Fri, 26 Sep 2025 15:42:59 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: <4j7FblbRNFadK0m_4pdjQuRp_EHkPbR75Ahb8_VRbHU=.0f8f1951-48fb-4703-ad20-d79f47e323ff@github.com> Message-ID: <1_BcJgyg67Y1g91q4m_pmUIDAe6UK9jX2VxSD0-AJIY=.d7f0ec72-45f6-4175-9d74-eb689734b560@github.com> On Wed, 10 Sep 2025 14:21:40 GMT, Michael Osipov wrote: > Yes. I traced the call. GSSKrb5Base::dispose was called after LDAPClient::close got call and context got closed. > > BTW, I will be out of office for two weeks starting next Monday. I will check review comment after coming backing. Were you able to check it meanwhile? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3339243498 From abarashev at openjdk.org Fri Sep 26 15:45:21 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 26 Sep 2025 15:45:21 GMT Subject: RFR: 8366244: TLS1.3 ChangeCipherSpec message received after the client's Finished message should trigger a connection abort with "unexpected message" Message-ID: According to the TLS specification, RFC 8446 section 5, An implementation may receive an unencrypted record of type change_cipher_spec consisting of the single byte value 0x01 at any time after the first ClientHello message has been sent or received and before the peer's Finished message has been received and MUST simply drop it without further processing. Note that this record may appear at a point at the handshake where the implementation is expecting protected records, and so it is necessary to detect this condition prior to attempting to deprotect the record. An implementation which receives any other change_cipher_spec value or which receives a protected change_cipher_spec record MUST abort the handshake with an "unexpected_message" alert. If an implementation detects a change_cipher_spec record received before the first ClientHello message or after the peer's Finished message, it MUST be treated as an unexpected record type (though stateless servers may not be able to distinguish these cases from allowed cases). However the TLS implementation ignores a CCS message received after the client's Finished, instead of sending an alert(fatal, unexpected_message) and aborting the connection. ------------- Commit messages: - Add unit test - 8366244: TLS1.3 ChangeCipherSpec message received after the client Finished message should trigger a connection abort with "unexpected message" Changes: https://git.openjdk.org/jdk/pull/27529/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27529&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366244 Stats: 127 lines in 2 files changed: 126 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27529/head:pull/27529 PR: https://git.openjdk.org/jdk/pull/27529 From weijun at openjdk.org Fri Sep 26 16:40:39 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 26 Sep 2025 16:40:39 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v6] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 13:47:36 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> add a warning for non-console interactive UI > > src/java.base/share/classes/sun/security/util/Password.java line 77: > >> 75: // will be silently consumed without echoing to the screen. >> 76: System.err.print("[Warning: Console not available." + >> 77: " The entered password might be echoed.] "); > > s/might/may/ > > I wonder if "echoed" is generally understood by most users. Should we be more clear and say something like " The password entered may be visible on the screen"? > > Also, consider putting "Warning" in all caps to make it more significant. Also consider breaking into 2 lines, so the second part is not at the end of a long line, ex: > > WARNING: Console not available > WARNING: The password entered may be visible on the screen This text appears after the prompt (which is printed by the caller) and I deliberately make it short so everything is still on the same line. Enter keystore password: [Warning: Console not available. The entered password might be echoed.] password Shall I just change "echoed" to "visible"? I'm OK with "WARNING". *Update*: Maybe there is no need to say "Console not available"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2382906867 From mullan at openjdk.org Fri Sep 26 16:53:19 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 26 Sep 2025 16:53:19 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v6] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 16:36:05 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/Password.java line 77: >> >>> 75: // will be silently consumed without echoing to the screen. >>> 76: System.err.print("[Warning: Console not available." + >>> 77: " The entered password might be echoed.] "); >> >> s/might/may/ >> >> I wonder if "echoed" is generally understood by most users. Should we be more clear and say something like " The password entered may be visible on the screen"? >> >> Also, consider putting "Warning" in all caps to make it more significant. Also consider breaking into 2 lines, so the second part is not at the end of a long line, ex: >> >> WARNING: Console not available >> WARNING: The password entered may be visible on the screen > > This text appears after the prompt (which is printed by the caller) and I deliberately make it short so everything is still on the same line. > > Enter keystore password: [Warning: Console not available. The entered password might be echoed.] password > > Shall I just change "echoed" to "visible"? I'm OK with "WARNING". > > *Update*: Maybe there is no need to say "Console not available"? Also no need to duplicate "password": > > Enter keystore password: [WARNING: Input may be visible on screen] password Last line looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2382933352 From weijun at openjdk.org Fri Sep 26 17:33:42 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 26 Sep 2025 17:33:42 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v7] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: even shorter warning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/9504e8e7..cbc89df1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From weijun at openjdk.org Fri Sep 26 19:10:14 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 26 Sep 2025 19:10:14 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v8] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: localization of the warning text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/cbc89df1..1e24c583 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=06-07 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From weijun at openjdk.org Fri Sep 26 19:17:36 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 26 Sep 2025 19:17:36 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v9] In-Reply-To: References: Message-ID: <-PH7qiXF__DXwfIaodZpEpmiLRn0PZp45wFfchiHRr0=.56b221d0-dd3e-4a6d-8a13-8b6b9ef13b05@github.com> > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update test on the new resource string only in patch2: unchanged: ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/1e24c583..7b844916 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=07-08 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From naoto at openjdk.org Fri Sep 26 20:40:19 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 26 Sep 2025 20:40:19 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v9] In-Reply-To: <-PH7qiXF__DXwfIaodZpEpmiLRn0PZp45wFfchiHRr0=.56b221d0-dd3e-4a6d-8a13-8b6b9ef13b05@github.com> References: <-PH7qiXF__DXwfIaodZpEpmiLRn0PZp45wFfchiHRr0=.56b221d0-dd3e-4a6d-8a13-8b6b9ef13b05@github.com> Message-ID: On Fri, 26 Sep 2025 19:17:36 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update test on the new resource string > > only in patch2: > unchanged: test/jdk/sun/security/util/Resources/Usages.java line 143: > 141: List.of(LOC_GETNONLOC, NEW_LOC)), > 142: new Pair("java.base/share/classes/sun/security/util/Password.java", > 143: List.of(MGR_GETSTRING)), Needs a bug id in the test comment for this addition? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2383450528 From ascarpino at openjdk.org Fri Sep 26 22:18:24 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 26 Sep 2025 22:18:24 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v2] In-Reply-To: References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: On Thu, 11 Sep 2025 10:02:07 GMT, Mikhail Yankelevich wrote: >> Tests changed in this PR: >> 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java >> 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java >> 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java >> 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java >> 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java >> 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java >> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java >> 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java >> 12. test/jdk/sun/security/rsa/InvalidBitString.java >> 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java >> 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java >> 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java >> >> PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > Francesco's comment > > Co-authored-by: Francesco Andreuzzi test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java line 45: > 43: import java.security.PEMDecoder; > 44: import java.security.Security; > 45: import java.security.cert.CertPathBuilder; Did you intentionally list every `java.security.cert` class used or did the IDE do that? The changes was made with a number of tests and other import paths, but I'm only mentioning it here. Just a suggestion that `*` looks cleaner. test/jdk/javax/net/ssl/interop/ClientHelloBufferUnderflowException.java line 33: > 31: * @bug 8215790 8219389 > 32: * @summary Verify exception > 33: * @enablePreview There doesn't look to be any PEM usage in this test test/jdk/javax/net/ssl/interop/ClientHelloChromeInterOp.java line 33: > 31: * @bug 8169362 > 32: * @summary Interop automated testing with Chrome > 33: * @enablePreview Appears not to need PEM test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java line 296: > 294: > 295: // generate the private key. > 296: String keyMaterialStrPEMFormat = new PEMRecord("PRIVATE KEY", keyMaterialKeys[i]).toString(); Should this one be done with [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) instead of this PR? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27194#discussion_r2383109895 PR Review Comment: https://git.openjdk.org/jdk/pull/27194#discussion_r2383557564 PR Review Comment: https://git.openjdk.org/jdk/pull/27194#discussion_r2383589810 PR Review Comment: https://git.openjdk.org/jdk/pull/27194#discussion_r2383590927 From weijun at openjdk.org Fri Sep 26 22:59:32 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 26 Sep 2025 22:59:32 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v10] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update bug list in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/7b844916..15e76512 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From mpowers at openjdk.org Sat Sep 27 02:42:10 2025 From: mpowers at openjdk.org (Mark Powers) Date: Sat, 27 Sep 2025 02:42:10 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v9] In-Reply-To: References: Message-ID: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: move algorithm-specific code into MacData and no change to SunJCE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24429/files - new: https://git.openjdk.org/jdk/pull/24429/files/069ef254..76ccce74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=07-08 Stats: 366 lines in 4 files changed: 175 ins; 159 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/24429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429 PR: https://git.openjdk.org/jdk/pull/24429 From mpowers at openjdk.org Mon Sep 29 03:45:38 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 29 Sep 2025 03:45:38 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v10] In-Reply-To: References: Message-ID: > [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) Mark Powers has updated the pull request incrementally with one additional commit since the last revision: another day another iteration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24429/files - new: https://git.openjdk.org/jdk/pull/24429/files/76ccce74..21eca48e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=08-09 Stats: 145 lines in 3 files changed: 23 ins; 66 del; 56 mod Patch: https://git.openjdk.org/jdk/pull/24429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429 PR: https://git.openjdk.org/jdk/pull/24429 From myankelevich at openjdk.org Mon Sep 29 09:52:56 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 29 Sep 2025 09:52:56 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v2] In-Reply-To: References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: On Fri, 26 Sep 2025 21:47:19 GMT, Anthony Scarpino wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Francesco's comment >> >> Co-authored-by: Francesco Andreuzzi > > test/jdk/javax/net/ssl/interop/ClientHelloBufferUnderflowException.java line 33: > >> 31: * @bug 8215790 8219389 >> 32: * @summary Verify exception >> 33: * @enablePreview > > There doesn't look to be any PEM usage in this test This class extends `ClientHelloInterOp`, so needs an updated tag. > test/jdk/javax/net/ssl/interop/ClientHelloChromeInterOp.java line 33: > >> 31: * @bug 8169362 >> 32: * @summary Interop automated testing with Chrome >> 33: * @enablePreview > > Appears not to need PEM This class extends `ClientHelloInterOp`, so needs an updated tag. > test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java line 296: > >> 294: >> 295: // generate the private key. >> 296: String keyMaterialStrPEMFormat = new PEMRecord("PRIVATE KEY", keyMaterialKeys[i]).toString(); > > Should this one be done with [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) instead of this PR? Yes, you're right, I must have missed this one when removing `PEMRecord` classes from this PR. I'll change it to not use PEMRecord or move it to JDK-8367326 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27194#discussion_r2387342488 PR Review Comment: https://git.openjdk.org/jdk/pull/27194#discussion_r2387342957 PR Review Comment: https://git.openjdk.org/jdk/pull/27194#discussion_r2387348814 From myankelevich at openjdk.org Mon Sep 29 09:58:37 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 29 Sep 2025 09:58:37 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v2] In-Reply-To: References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: On Fri, 26 Sep 2025 17:59:09 GMT, Anthony Scarpino wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Francesco's comment >> >> Co-authored-by: Francesco Andreuzzi > > test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java line 45: > >> 43: import java.security.PEMDecoder; >> 44: import java.security.Security; >> 45: import java.security.cert.CertPathBuilder; > > Did you intentionally list every `java.security.cert` class used or did the IDE do that? The changes was made with a number of tests and other import paths, but I'm only mentioning it here. Just a suggestion that `*` looks cleaner. Just removing all wildcard imports, when I touch the file. Was asked to remove several times before and in general wildcard is not the best practice, as this affect compile time, which is important for `jtreg` tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27194#discussion_r2387367113 From myankelevich at openjdk.org Mon Sep 29 10:28:19 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 29 Sep 2025 10:28:19 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v3] In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: > Tests changed in this PR: > 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java > 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java > 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java > 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java > 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java > 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java > 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java > 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java > 12. test/jdk/sun/security/rsa/InvalidBitString.java > 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java > 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java > 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java > > PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) Mikhail Yankelevich has updated the pull request incrementally with 364 additional commits since the last revision: - removed pemrecord usage - 8365190: Remove LockingMode related code from share Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo - 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp Reviewed-by: aboldtch, tschatzl, jwaters - 8360219: [AIX] assert(locals_base >= l2) failed: bad placement Reviewed-by: dlong, mdoerr - 8366864: Sort os/linux includes Reviewed-by: ayang, dholmes - 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages Reviewed-by: ayang, shade, stefank, tschatzl - 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR) Reviewed-by: vromero - 8365776: Convert JShell tests to use JUnit instead of TestNG Reviewed-by: vromero - 8354871: Replace stack map frame type magics with constants Reviewed-by: liach - 8361533: Apply java.io.Serial annotations in java.logging Reviewed-by: rriggs - ... and 354 more: https://git.openjdk.org/jdk/compare/d44cb277...e0be5eaa ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27194/files - new: https://git.openjdk.org/jdk/pull/27194/files/d44cb277..e0be5eaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=01-02 Stats: 53711 lines in 1891 files changed: 31453 ins; 14034 del; 8224 mod Patch: https://git.openjdk.org/jdk/pull/27194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194 PR: https://git.openjdk.org/jdk/pull/27194 From myankelevich at openjdk.org Mon Sep 29 10:35:53 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 29 Sep 2025 10:35:53 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v4] In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: > Tests changed in this PR: > 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java > 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java > 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java > 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java > 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java > 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java > 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java > 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java > 12. test/jdk/sun/security/rsa/InvalidBitString.java > 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java > 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java > 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java > > PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) Mikhail Yankelevich has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: removed pemrecord usage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27194/files - new: https://git.openjdk.org/jdk/pull/27194/files/e0be5eaa..a3323da7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=02-03 Stats: 53741 lines in 1890 files changed: 14074 ins; 31491 del; 8176 mod Patch: https://git.openjdk.org/jdk/pull/27194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194 PR: https://git.openjdk.org/jdk/pull/27194 From duke at openjdk.org Mon Sep 29 13:34:47 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Mon, 29 Sep 2025 13:34:47 GMT Subject: RFR: 8366244: TLS1.3 ChangeCipherSpec message received after the client's Finished message should trigger a connection abort with "unexpected message" In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 15:38:20 GMT, Artur Barashev wrote: > According to the TLS specification, RFC 8446 section 5, > > An implementation may receive an unencrypted record of type > change_cipher_spec consisting of the single byte value 0x01 at any > time after the first ClientHello message has been sent or received > and before the peer's Finished message has been received and MUST > simply drop it without further processing. Note that this record may > appear at a point at the handshake where the implementation is > expecting protected records, and so it is necessary to detect this > condition prior to attempting to deprotect the record. An > implementation which receives any other change_cipher_spec value or > which receives a protected change_cipher_spec record MUST abort the > handshake with an "unexpected_message" alert. If an implementation > detects a change_cipher_spec record received before the first > ClientHello message or after the peer's Finished message, it MUST be > treated as an unexpected record type (though stateless servers may > not be able to distinguish these cases from allowed cases). > > > However the TLS implementation ignores a CCS message received after the client's Finished, instead of sending an alert(fatal, unexpected_message) and aborting the connection. test/jdk/sun/security/ssl/SSLEngineImpl/TLS13ChangeCipherSpecAfterFinished.java line 122: > 120: ex -> { > 121: assertTrue(ex instanceof SSLProtocolException); > 122: assertEquals(ex.getMessage(), exMsg); nitpick: expected goes on the left hand side, [see here](https://github.com/openjdk/jdk/blob/fdbba049a2491c591fc1a866e4707bf9aac50f17/test/lib/jdk/test/lib/Asserts.java#L206-L210) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27529#discussion_r2387985209 From abarashev at openjdk.org Mon Sep 29 13:44:27 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 29 Sep 2025 13:44:27 GMT Subject: RFR: 8366244: TLS1.3 ChangeCipherSpec message received after the client's Finished message should trigger a connection abort with "unexpected message" In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 13:31:56 GMT, Alice Pellegrini wrote: >> According to the TLS specification, RFC 8446 section 5, >> >> An implementation may receive an unencrypted record of type >> change_cipher_spec consisting of the single byte value 0x01 at any >> time after the first ClientHello message has been sent or received >> and before the peer's Finished message has been received and MUST >> simply drop it without further processing. Note that this record may >> appear at a point at the handshake where the implementation is >> expecting protected records, and so it is necessary to detect this >> condition prior to attempting to deprotect the record. An >> implementation which receives any other change_cipher_spec value or >> which receives a protected change_cipher_spec record MUST abort the >> handshake with an "unexpected_message" alert. If an implementation >> detects a change_cipher_spec record received before the first >> ClientHello message or after the peer's Finished message, it MUST be >> treated as an unexpected record type (though stateless servers may >> not be able to distinguish these cases from allowed cases). >> >> >> However the TLS implementation ignores a CCS message received after the client's Finished, instead of sending an alert(fatal, unexpected_message) and aborting the connection. > > test/jdk/sun/security/ssl/SSLEngineImpl/TLS13ChangeCipherSpecAfterFinished.java line 122: > >> 120: ex -> { >> 121: assertTrue(ex instanceof SSLProtocolException); >> 122: assertEquals(ex.getMessage(), exMsg); > > nitpick: expected goes on the left hand side, [see here](https://github.com/openjdk/jdk/blob/fdbba049a2491c591fc1a866e4707bf9aac50f17/test/lib/jdk/test/lib/Asserts.java#L206-L210) Thanks! Yes, I know but I keep writing tests this way for some reason. Will fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27529#discussion_r2388036113 From mpowers at openjdk.org Mon Sep 29 15:05:28 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 29 Sep 2025 15:05:28 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> Message-ID: On Wed, 24 Sep 2025 16:53:17 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1493: >> >>> 1491: if (!(kdfHmac.equals("HmacSHA512") || >>> 1492: kdfHmac.equals("HmacSHA256"))) { >>> 1493: kdfHmac = pbmac1Hmac; // use value associated with keystore >> >> `pbmac1Hmac` is probably null now. If you decide to reject other algorithms (which I don't find necessary), error out. > > Why is `pbmac1Hmac` necessary? Do we want to support writing with different PRF and HMAC? Writing with different PRF and HMAC **is** supported. Test vector #2 in the RFC passes. `pbmac1Hmac` is gone. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2388313026 From wxiao at openjdk.org Mon Sep 29 15:13:50 2025 From: wxiao at openjdk.org (Weibing Xiao) Date: Mon, 29 Sep 2025 15:13:50 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao wrote: >> [webrev.zip](https://github.com/user-attachments/files/21517501/webrev.zip) >> NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory. >> >> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message and SaslOuput Stream is writing the content of the buffer; and at the time GSSContext is disposed and it is null. That's the reason to throw NPE. >> >> 1) Check if the context is null or not; then wrap the NPE. The change is done in GssKrb5Base.java >> >> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached webrev for the reference. > > Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused code > - removed the commented out code Not quite sure what you like me to check. I confirmed the context was disposed. With my testing code, I got same error as what you got. Certainly there is no more NPE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3347560177 From mpowers at openjdk.org Mon Sep 29 15:05:26 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 29 Sep 2025 15:05:26 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v8] In-Reply-To: References: <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com> Message-ID: On Wed, 24 Sep 2025 19:28:12 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> fix behavior with keytool > > src/java.base/share/classes/sun/security/pkcs12/MacData.java line 94: > >> 92: pbeSpec = >> 93: this.digestAlgorithmParams.getParameterSpec( >> 94: PBEParameterSpec.class); > > I think you may already be working on this, so mainly registering this as a comment. This code should be replaced with an internal method that calls `AlgorithmId.getEncodedParams()` and decodes the parameters, reusing much of the code you have already written in `PBMAC1Parameters.engineInit()`. This will avoid having to create an `AlgorithmParameters` implementation as part of this feature, which isn't strictly needed. We can consider adding that on a follow-on Enhancement. Done. > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1953: > >> 1951: private void processMacData(AlgorithmParameterSpec params, >> 1952: MacData macData, char[] password, byte[] data, String macAlgorithm) >> 1953: throws Exception { > > Try just throwing the exceptions that can be thrown by code in this method, rather than `Exception` for everything. I know there is a "try/catch (Exception)" block in `engineLoad` when calling this method, but I think it is cleaner to only declare the exceptions that can be thrown here. Agreed. I'll fix this. > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2214: > >> 2212: new PBEParameterSpec(salt, ic); >> 2213: processMacData(params, macData, password, authSafeData, >> 2214: macAlgorithm); > > These 4 lines can be moved below after the if/else block since they are the same for both conditions. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2388311568 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2388312083 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2388312524 From mpowers at openjdk.org Mon Sep 29 15:05:31 2025 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 29 Sep 2025 15:05:31 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: <-faEDvXY3byz0308qDR_faSreg9DkQYtg-txROBLYL0=.0229eabd-d5a3-40a6-82b0-d9f9791110a0@github.com> References: <-faEDvXY3byz0308qDR_faSreg9DkQYtg-txROBLYL0=.0229eabd-d5a3-40a6-82b0-d9f9791110a0@github.com> Message-ID: On Tue, 23 Sep 2025 19:41:31 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> default salt length and one other comment from Weijun > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2208: > >> 2206: } else { >> 2207: >> 2208: // Change SHA-1 to SHA1 > > While you are in this code, can you update this comment? It's not only SHA-1, it's any message digest with a "-" in it, so suggest changing it to something like: > > `// Remove "-" from digest algorithm names` will fix as suggested ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2388313888 From duke at openjdk.org Mon Sep 29 15:32:42 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Mon, 29 Sep 2025 15:32:42 GMT Subject: RFR: 8366453: TLS 1.3 KeyUpdate record is not rejected if not on a record boundary In-Reply-To: References: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> Message-ID: On Thu, 25 Sep 2025 12:31:28 GMT, Mikhail Yankelevich wrote: >> According to RFC 8446 section 5.1 >>> Handshake messages MUST NOT span key changes. Implementations >>> MUST verify that all messages immediately preceding a key change >>> align with a record boundary; if not, then they MUST terminate the >>> connection with an "unexpected_message" alert. Because the >>> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate >>> messages can immediately precede a key change, implementations >>> MUST send these messages in alignment with a record boundary. >> >> The TLS implementation does not fail with alert(fatal, unexpected_message) when a KeyUpdate record is not on a record boundary, but this is required by the specification (as a key change happens immediately after a key update record) >> >> >> Since the data on whether a message aligns with a record boundary is only known in the implementations of `InputRecord` (as even incomplete parts of other handshake messages, if coming after one of the mentioned handshakes records, would require a failure, making checking that said message is the last complete one of that record insufficient), and the fact that, **if the negotiated protocol is TLS13** _(or even DTLS13 in the future)_, knowing that any of the mentioned messages did not align with the record boundary is enough to fail the connection, I am proposing to add this as a method of `InputRecord`; >> >> In addition, even if the handshake context was accessible from within `InputRecord`, for both ServerHello and ClientHello the negotiated protocol version is not known when the input record is decoded. >> >> The change mentions the name of the message currently being consumed in the exception because (since the messages are consumed in the order in which they appear in the record's body, and the groups of messages contained in each record are consumed in the order in which said records were delivered) it can be shown that if that flag is set, the first consumer that calls `tls13keyChangeHsExceedsRecordBoundary` will correspond to the first message to violate the boundary requirement, among the messages in the record it was found in. >> >>

    >> >> I would appreciate suggestions on how to make the code better, especially in terms of where and how to store the fact that the violation might (if the negotiated protocol is or will be TLS13) have happened, and where to put the comments mentioning the specification RFC8446, for example in the `InputRecord` base class or the TLS13 Cons... > > src/java.base/share/classes/sun/security/ssl/InputRecord.java line 161: > >> 159: } >> 160: >> 161: protected final void setT13keyChangeHsExceedsRecordBoundary() { > > How about making this `markT13keyChangeHsExceedsRecordBoundary`, as it's not a setter. Or may be there is a better name. > > Also, I'd think about explicitly calling tls13 in the name, as it is going to be called in `SSLSocketInputRecord.java` for tls1.2 and older. Mb just name it in a generic way. But I don't mind to leave it as it is. Renamed to `markT13keyChangeHsExceedsRecordBoundary`, not sure about not mentioning tls13 in its name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2379414290 From myankelevich at openjdk.org Mon Sep 29 15:32:41 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 29 Sep 2025 15:32:41 GMT Subject: RFR: 8366453: TLS 1.3 KeyUpdate record is not rejected if not on a record boundary In-Reply-To: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> References: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> Message-ID: On Mon, 22 Sep 2025 19:48:20 GMT, Alice Pellegrini wrote: > According to RFC 8446 section 5.1 >> Handshake messages MUST NOT span key changes. Implementations >> MUST verify that all messages immediately preceding a key change >> align with a record boundary; if not, then they MUST terminate the >> connection with an "unexpected_message" alert. Because the >> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate >> messages can immediately precede a key change, implementations >> MUST send these messages in alignment with a record boundary. > > The TLS implementation does not fail with alert(fatal, unexpected_message) when a KeyUpdate record is not on a record boundary, but this is required by the specification (as a key change happens immediately after a key update record) > > > Since the data on whether a message aligns with a record boundary is only known in the implementations of `InputRecord` (as even incomplete parts of other handshake messages, if coming after one of the mentioned handshakes records, would require a failure, making checking that said message is the last complete one of that record insufficient), and the fact that, **if the negotiated protocol is TLS13** _(or even DTLS13 in the future)_, knowing that any of the mentioned messages did not align with the record boundary is enough to fail the connection, I am proposing to add this as a method of `InputRecord`; > > In addition, even if the handshake context was accessible from within `InputRecord`, for both ServerHello and ClientHello the negotiated protocol version is not known when the input record is decoded. > > The change mentions the name of the message currently being consumed in the exception because (since the messages are consumed in the order in which they appear in the record's body, and the groups of messages contained in each record are consumed in the order in which said records were delivered) it can be shown that if that flag is set, the first consumer that calls `tls13keyChangeHsExceedsRecordBoundary` will correspond to the first message to violate the boundary requirement, among the messages in the record it was found in. > >

    > > I would appreciate suggestions on how to make the code better, especially in terms of where and how to store the fact that the violation might (if the negotiated protocol is or will be TLS13) have happened, and where to put the comments mentioning the specification RFC8446, for example in the `InputRecord` base class or the TLS13 Consumers that were modified. Just a few minor comments. Also tests :) src/java.base/share/classes/sun/security/ssl/Finished.java line 932: > 930: } > 931: > 932: if (chc.conContext.inputRecord.t13keyChangeHsExceedsRecordBoundary()) { Do you think there might be a way to not repeat the same logic. Mb moving it to the `InputRecord` itself. This way you will also be able to remove `t13keyChangeHsExceedsRecordBoundary` which should streamline the code and reduce operations. If you think that this is better, it's fine with me src/java.base/share/classes/sun/security/ssl/InputRecord.java line 161: > 159: } > 160: > 161: protected final void setT13keyChangeHsExceedsRecordBoundary() { How about making this `markT13keyChangeHsExceedsRecordBoundary`, as it's not a setter. Or may be there is a better name. Also, I'd think about explicitly calling tls13 in the name, as it is going to be called in `SSLSocketInputRecord.java` for tls1.2 and older. Mb just name it in a generic way. But I don't mind to leave it as it is. src/java.base/share/classes/sun/security/ssl/KeyUpdate.java line 194: > 192: PostHandshakeContext hc = (PostHandshakeContext)context; > 193: > 194: if (hc.negotiatedProtocol.useTLS13PlusSpec() && hc.conContext.inputRecord.t13keyChangeHsExceedsRecordBoundary()) { Suggestion: if (hc.negotiatedProtocol.useTLS13PlusSpec() && hc.conContext.inputRecord.t13keyChangeHsExceedsRecordBoundary()) { src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java line 349: > 347: // MUST send these messages in alignment with a record boundary." > 348: // > 349: // this check must be done here, as the handshakeBuffer is not accessible to the outer scope, nit: 80 characters src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java line 376: > 374: // MUST send these messages in alignment with a record boundary." > 375: // > 376: // this check must be done here, as the handshakeBuffer is not accessible to the outer scope, nit: 80 characters ------------- PR Review: https://git.openjdk.org/jdk/pull/27437#pullrequestreview-3267402523 PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2378913282 PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2378928358 PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2378918372 PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2378915832 PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2378915303 From duke at openjdk.org Mon Sep 29 15:32:37 2025 From: duke at openjdk.org (Alice Pellegrini) Date: Mon, 29 Sep 2025 15:32:37 GMT Subject: RFR: 8366453: TLS 1.3 KeyUpdate record is not rejected if not on a record boundary Message-ID: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> According to RFC 8446 section 5.1 > Handshake messages MUST NOT span key changes. Implementations > MUST verify that all messages immediately preceding a key change > align with a record boundary; if not, then they MUST terminate the > connection with an "unexpected_message" alert. Because the > ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate > messages can immediately precede a key change, implementations > MUST send these messages in alignment with a record boundary. The TLS implementation does not fail with alert(fatal, unexpected_message) when a KeyUpdate record is not on a record boundary, but this is required by the specification (as a key change happens immediately after a key update record) Since the data on whether a message aligns with a record boundary is only known in the implementations of `InputRecord` (as even incomplete parts of other handshake messages, if coming after one of the mentioned handshakes records, would require a failure, making checking that said message is the last complete one of that record insufficient), and the fact that, **if the negotiated protocol is TLS13** _(or even DTLS13 in the future)_, knowing that any of the mentioned messages did not align with the record boundary is enough to fail the connection, I am proposing to add this as a method of `InputRecord`; In addition, even if the handshake context was accessible from within `InputRecord`, for both ServerHello and ClientHello the negotiated protocol version is not known when the input record is decoded. The change mentions the name of the message currently being consumed in the exception because (since the messages are consumed in the order in which they appear in the record's body, and the groups of messages contained in each record are consumed in the order in which said records were delivered) it can be shown that if that flag is set, the first consumer that calls `tls13keyChangeHsExceedsRecordBoundary` will correspond to the first message to violate the boundary requirement, among the messages in the record it was found in.

    I would appreciate suggestions on how to make the code better, especially in terms of where and how to store the fact that the violation might (if the negotiated protocol is or will be TLS13) have happened, and where to put the comments mentioning the specification RFC8446, for example in the `InputRecord` base class or the TLS13 Consumers that were modified. ------------- Commit messages: - fix typo in comments - modifiers fixes - added explanation for additional wrap in test - implement test - Stylistic and naming changes - Fail with fatal without logging the `Consuming` message - Inheritance and comments cleanup - First draft of more correct check of tls version - add check that spec is tls13plus - 8366453: TLS 1.3 KeyUpdate record is not rejected if not on a record boundary Changes: https://git.openjdk.org/jdk/pull/27437/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27437&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366453 Stats: 241 lines in 9 files changed: 238 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27437.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27437/head:pull/27437 PR: https://git.openjdk.org/jdk/pull/27437 From duke at openjdk.org Mon Sep 29 15:53:06 2025 From: duke at openjdk.org (Michael Osipov) Date: Mon, 29 Sep 2025 15:53:06 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: Message-ID: <8QzyKoTrmihlwPo9lJc5I4XhldT6E6FvV7ILVb8vHKc=.ada1b034-03a0-4142-b1ae-b5aface63b17@github.com> On Mon, 29 Sep 2025 15:11:01 GMT, Weibing Xiao wrote: > Not quite sure what you like me to check. I confirmed the context was disposed. With my testing code, I got same error as what you got. Certainly there is no more NPE. Good. I am fine with the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3347784225 From abarashev at openjdk.org Mon Sep 29 16:43:13 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 29 Sep 2025 16:43:13 GMT Subject: RFR: 8366244: TLS1.3 ChangeCipherSpec message received after the client's Finished message should trigger a connection abort with "unexpected message" [v2] In-Reply-To: References: Message-ID: > According to the TLS specification, RFC 8446 section 5, > > An implementation may receive an unencrypted record of type > change_cipher_spec consisting of the single byte value 0x01 at any > time after the first ClientHello message has been sent or received > and before the peer's Finished message has been received and MUST > simply drop it without further processing. Note that this record may > appear at a point at the handshake where the implementation is > expecting protected records, and so it is necessary to detect this > condition prior to attempting to deprotect the record. An > implementation which receives any other change_cipher_spec value or > which receives a protected change_cipher_spec record MUST abort the > handshake with an "unexpected_message" alert. If an implementation > detects a change_cipher_spec record received before the first > ClientHello message or after the peer's Finished message, it MUST be > treated as an unexpected record type (though stateless servers may > not be able to distinguish these cases from allowed cases). > > > However the TLS implementation ignores a CCS message received after the client's Finished, instead of sending an alert(fatal, unexpected_message) and aborting the connection. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27529/files - new: https://git.openjdk.org/jdk/pull/27529/files/a05ae5ff..98bc45e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27529&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27529&range=00-01 Stats: 16 lines in 1 file changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27529/head:pull/27529 PR: https://git.openjdk.org/jdk/pull/27529 From valeriep at openjdk.org Mon Sep 29 16:57:34 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 29 Sep 2025 16:57:34 GMT Subject: RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 19:45:48 GMT, Daniel Jeli?ski wrote: > Change SunJSSE to use `TlsUpdateNplus1` instead of `AES` as the key algorithm when deriving the next application traffic secret. > > SunPKCS11 provider checks the key length when creating an `AES` key, and since 384 bits is not a valid AES key length, the key creation fails. > > `TlsUpdateNplus1` is [already recognized](https://github.com/openjdk/jdk/blob/3c9fd7688f4d73067db9b128c329ca7603a60578/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L287) as a standard TLS generic key by SunPKCS11. > > Key update is now exercised by the FipsModeTLS test. The test passes with the changes, fails without them. Other tier1-3 tests continue to pass. src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 215: > 213: if (this == TlsKey) > 214: return cs.bulkCipher.algorithm; > 215: return algorithm; nit: how about just `return (this == TlsKey ? cs.bulkCipher.algorithm : algorithm);` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27498#discussion_r2388628833 From valeriep at openjdk.org Mon Sep 29 17:03:06 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 29 Sep 2025 17:03:06 GMT Subject: RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 16:54:41 GMT, Valerie Peng wrote: >> Change SunJSSE to use `TlsUpdateNplus1` instead of `AES` as the key algorithm when deriving the next application traffic secret. >> >> SunPKCS11 provider checks the key length when creating an `AES` key, and since 384 bits is not a valid AES key length, the key creation fails. >> >> `TlsUpdateNplus1` is [already recognized](https://github.com/openjdk/jdk/blob/3c9fd7688f4d73067db9b128c329ca7603a60578/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L287) as a standard TLS generic key by SunPKCS11. >> >> Key update is now exercised by the FipsModeTLS test. The test passes with the changes, fails without them. Other tier1-3 tests continue to pass. > > src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 215: > >> 213: if (this == TlsKey) >> 214: return cs.bulkCipher.algorithm; >> 215: return algorithm; > > nit: how about just `return (this == TlsKey ? cs.bulkCipher.algorithm : algorithm);` In addition, looking at the KeySchedule enum, only `TlsIv` is of iv type, so overall we don't really need the `isIv` field. If we change the `getKeyLength(CipherSuite cs)` method as below, then we can remove the `isIv` field. + return switch (this) { + case TlsUpdateNplus1->cs.hashAlg.hashLength; + case TlsIv->cs.bulkCipher.ivSize; + case TlsKey->cs.bulkCipher.keySize; + default->throw new RuntimeException("Unexpected exception"); + }; What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27498#discussion_r2388638214 From duke at openjdk.org Mon Sep 29 18:13:32 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Mon, 29 Sep 2025 18:13:32 GMT Subject: RFR: 8365069: Refactor tests to use PEM API (Phase 1) Message-ID: The following tests have been identified as candidates for phase 1 of this change. 2. test/jdk/javax/net/ssl/TLSCommon/TLSTest.java 3. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java 4. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilderWithMD5.java 5. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java 9. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java 11. test/jdk/sun/security/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java 13. test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java 16. test/jdk/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java 17. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java 18. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java 20. test/jdk/java/security/KeyStore/PKCS12/WriteP12Test.java 21. test/jdk/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java 22. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java 23. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java 24. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java 25. test/jdk/java/security/cert/CertPathValidator/trustAnchor/ValWithAnchorByName.java 30. test/jdk/java/security/KeyStore/TestKeyStoreBasic.java ------------- Commit messages: - 8365069: Refactor tests to use PEM API (Phase 1) - 8365069: Refactor tests to use PEM API (Phase 1) - 8365069: Refactor tests to use PEM API (Phase 1) Changes: https://git.openjdk.org/jdk/pull/27267/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27267&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365069 Stats: 514 lines in 18 files changed: 104 ins; 190 del; 220 mod Patch: https://git.openjdk.org/jdk/pull/27267.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27267/head:pull/27267 PR: https://git.openjdk.org/jdk/pull/27267 From naoto at openjdk.org Mon Sep 29 19:31:21 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 29 Sep 2025 19:31:21 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v10] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 22:59:32 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update bug list in test LGTM from the Console view. I am still quite not sure about the usage of `System.in.available()`, so leave it to someone else to approve ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3281457647 From fitzsim at openjdk.org Mon Sep 29 20:49:10 2025 From: fitzsim at openjdk.org (Thomas Fitzsimmons) Date: Mon, 29 Sep 2025 20:49:10 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v10] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 03:45:38 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > another day another iteration (This more of a usage report than a review.) I have been following along as this patch evolves, testing it against `SunPKCS11`. I have been configuring `java.security` with: security.provider.1=SunPKCS11 /tmp/nss.txt security.provider.2=SUN security.provider.3=SunRsaSign security.provider.4=SunEC security.provider.5=SunJSSE security.provider.6=SunJCE security.provider.7=SunJGSS security.provider.8=SunSASL security.provider.9=XMLDSig security.provider.10=SunPCSC security.provider.11=JdkLDAP security.provider.12=JdkSASL then running: keytool -J-Djava.security.debug=all -list -keystore rfc-9579-a.1.p12 -storepass 1234 -v As of commit https://github.com/openjdk/jdk/pull/24429/commits/ecda43f557b4f96c9f54287b13e7cf7056fb8e94, the patch requested `Mac.PBEWithHmacSHA256` directly. `SunPKCS11` does not claim to implement that algorithm name. So even though (in `java.security`) `SunPKCS11` took priority over `SunJCE`, `SunJCE`'s `HMAC-SHA256` algorithm was being used: 3236:Provider[0x3|main|KeyStore.java:822|2025-09-23 16:09:08.499]: KeyStore.PKCS12 type from: SUN 3240:Provider[0x3|main|Cipher.java:1606|2025-09-23 16:09:08.614]: Cipher.PBEWithHmacSHA256AndAES_256, mode: decryption, algorithm from: SunPKCS11-NSS [Start of SunJCE HMAC-SHA256 load messages] 3243:Provider[0x3|main|MessageDigest.java:200|2025-09-23 16:09:08.735]: MessageDigest.SHA-256 algorithm from: SunPKCS11-NSS 3244:Provider[0x3|main|MessageDigest.java:200|2025-09-23 16:09:08.739]: MessageDigest.SHA-256 algorithm from: SunPKCS11-NSS 3245:Provider[0x3|main|Mac.java:446|2025-09-23 16:09:08.740]: Mac.HmacSHA256 algorithm from: SunJCE 7342:Provider[0x3|main|Mac.java:473|2025-09-23 16:09:09.129]: Mac.PBEWithHmacSHA256 algorithm from: SunJCE [End of SunJCE HMAC-SHA256 load messages] 7346:Provider[0x3|main|Signature.java:545|2025-09-23 16:09:09.200]: Signature.SHA256withRSA verification algorithm from: SunPKCS11-NSS 7373:Provider[0x3|main|MessageDigest.java:200|2025-09-23 16:09:09.422]: MessageDigest.SHA-1 algorithm from: SunPKCS11-NSS 7375:Provider[0x3|main|MessageDigest.java:200|2025-09-23 16:09:09.422]: MessageDigest.SHA-256 algorithm from: SunPKCS11-NSS 7455:Provider[0x3|main|KeyStore.java:822|2025-09-23 16:09:09.466]: KeyStore.PKCS12 type from: SUN 7457:Provider[0x3|main|Cipher.java:1606|2025-09-23 16:09:09.466]: Cipher.PBEWithHmacSHA256AndAES_256, mode: decryption, algorithm from: SunPKCS11-NSS [Start of SunJCE HMAC-SHA256 load messages] 7460:Provider[0x3|main|MessageDigest.java:200|2025-09-23 16:09:09.468]: MessageDigest.SHA-256 algorithm from: SunPKCS11-NSS 7461:Provider[0x3|main|MessageDigest.java:200|2025-09-23 16:09:09.468]: MessageDigest.SHA-256 algorithm from: SunPKCS11-NSS 7462:Provider[0x3|main|Mac.java:446|2025-09-23 16:09:09.468]: Mac.HmacSHA256 algorithm from: SunJCE 11559:Provider[0x3|main|Mac.java:473|2025-09-23 16:09:09.831]: Mac.PBEWithHmacSHA256 algorithm from: SunJCE [End of SunJCE HMAC-SHA256 load messages] Commit https://github.com/openjdk/jdk/pull/24429/commits/7a010df9b6c75ac151c53979febcda56ec563ab8 fixed this issue by removing the "PBEWith" from the name: private void processMacData(AlgorithmParameterSpec params, MacData macData, char[] password, byte[] data, String macAlgorithm) throws Exception { final String kdfHmac; String tmp; tmp = macAlgorithm.replace("PBEWith", ""); if (!(tmp.equals("HmacSHA512") || tmp.equals("HmacSHA256"))) { kdfHmac = macAlgorithm; } else { kdfHmac = tmp; } Now `SunPKCS11`'s `HMAC-SHA256` is used, so my testing is satisfied: 3236:Provider[0x3|main|KeyStore.java:822|2025-09-23 15:58:07.252]: KeyStore.PKCS12 type from: SUN 3240:Provider[0x3|main|Cipher.java:1606|2025-09-23 15:58:07.396]: Cipher.PBEWithHmacSHA256AndAES_256, mode: decryption, algorithm from: SunPKCS11-NSS [Start SunPKCS11 HMAC-SHA256 load messages] 3243:Provider[0x3|main|Mac.java:446|2025-09-23 15:58:07.521]: Mac.HmacSHA256 algorithm from: SunPKCS11-NSS [End SunPKCS11 HMAC-SHA256 load messages] 3245:Provider[0x3|main|Signature.java:545|2025-09-23 15:58:07.591]: Signature.SHA256withRSA verification algorithm from: SunPKCS11-NSS 3272:Provider[0x3|main|MessageDigest.java:200|2025-09-23 15:58:07.813]: MessageDigest.SHA-1 algorithm from: SunPKCS11-NSS 3274:Provider[0x3|main|MessageDigest.java:200|2025-09-23 15:58:07.821]: MessageDigest.SHA-256 algorithm from: SunPKCS11-NSS 3354:Provider[0x3|main|KeyStore.java:822|2025-09-23 15:58:07.861]: KeyStore.PKCS12 type from: SUN 3356:Provider[0x3|main|Cipher.java:1606|2025-09-23 15:58:07.862]: Cipher.PBEWithHmacSHA256AndAES_256, mode: decryption, algorithm from: SunPKCS11-NSS [Start SunPKCS11 HMAC-SHA256 load messages] 3359:Provider[0x3|main|Mac.java:446|2025-09-23 15:58:07.864]: Mac.HmacSHA256 algorithm from: SunPKCS11-NSS [End SunPKCS11 HMAC-SHA256 load messages] I didn't see this explicitly discussed in the review comments, so I thought I would mention it. I wonder if it might make sense in a follow up PR to "future proof" `SunPKCS11` by having it declare support for `Mac.PBEWithHmacSHA256` by name, in case `PKCS12KeyStore.java` ever wanted to request that directly. ------------- PR Review: https://git.openjdk.org/jdk/pull/24429#pullrequestreview-3281733011 From weijun at openjdk.org Mon Sep 29 21:11:10 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 29 Sep 2025 21:11:10 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v10] In-Reply-To: References: Message-ID: <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com> On Mon, 29 Sep 2025 03:45:38 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > another day another iteration Some comments. src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 69: > 67: private String pbmac1AlgorithmName = null; > 68: > 69: private byte[] salt = null; Instead of including so many PBKDF2 components, can we just put one `PBKDF2Parameters` field here? We can also remove the `getPrf`, `getSalt`, and `getIterations` methods. IMO it's not awkward to call `pbmac1Params.getKdfParams().getPrf()` etc. src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 84: > 82: private int keyLength = -1; > 83: > 84: protected void Init(AlgorithmParameterSpec paramSpec) Method names should start with a lowercase letter. If it's not used, remove it. That said, in a different comment, I was hoping we can also construct a `PBMAC1Parameters` object using its components. src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 184: > 182: * Returns a formatted string describing the parameters. > 183: */ > 184: public String engineToString() { Useless now. Therefore, `pbmac1AlgorithmName` is also useless. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 190: > 188: var skf = SecretKeyFactory.getInstance( > 189: kdfHmac.equals("HmacSHA512") ? > 190: "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256"); The calculation of mac can be consolidated in one method, which is then called by both `processMacData` and `calculateMac`. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 234: > 232: String Hmac = null; > 233: > 234: if (newKeystore) { What could happen if `newKeystore` is different? Is the only difference about the `And` in `macAlgorithm`? Can we just treat it in a consistent way no matter if a new keystore is created? src/java.base/share/classes/sun/security/pkcs12/MacData.java line 250: > 248: } > 249: } > 250: // Fall back to old way of computing MAC This is not a fallback. There are 2 different kinds of algorithms. If it starts with "PBEWith", PBMAC1 is used. If it starts with "HmacPBE", the old algorithm is used. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 260: > 258: > 259: var skf = SecretKeyFactory.getInstance(kdfHmac.equals("HmacSHA512") ? > 260: "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256"); Why not just use `"PBKDF2With" + kdfHmac`? What if `kdfHmac` is "HmacSHA384"? src/java.base/share/classes/sun/security/pkcs12/MacData.java line 262: > 260: "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256"); > 261: try { > 262: int keyLength = Hmac.equals("HmacSHA512") ? 64*8 : 32*8; Use `Mac.getInstance(Hmac).getMacLength()`. There are other algorithms. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 287: > 285: return mData; > 286: } > 287: For all methods below, unless one is used outside of this class, there is no need to create a getter method. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 322: > 320: * ASN.1 encoding. > 321: */ > 322: public byte[] getEncoded() throws NoSuchAlgorithmException, IOException { Since you have moved the decoding of PBKDF2-Params into its own class, are you going to move the encoding there as well? Ideally, a `PBKDF2Parameters` object can be either created using a `DerValue` or its components (salt, ic, keyLen), and then it has a `getEncoded()` method. Same with the new `PBMAC1Parameters` class. ------------- PR Review: https://git.openjdk.org/jdk/pull/24429#pullrequestreview-3281720001 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389276133 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389255889 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389268119 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389262830 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389223743 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389227816 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389230206 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389232306 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389237089 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389248160 From weijun at openjdk.org Mon Sep 29 21:11:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 29 Sep 2025 21:11:11 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v10] In-Reply-To: <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com> References: <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com> Message-ID: On Mon, 29 Sep 2025 20:44:29 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> another day another iteration > > src/java.base/share/classes/sun/security/pkcs12/MacData.java line 260: > >> 258: >> 259: var skf = SecretKeyFactory.getInstance(kdfHmac.equals("HmacSHA512") ? >> 260: "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256"); > > Why not just use `"PBKDF2With" + kdfHmac`? What if `kdfHmac` is "HmacSHA384"? Also, for old algorithms, this `SecretKeyFactory` should not be used, even if the final result can also be used. Use the old `getPBEKey` code here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389234712 From weijun at openjdk.org Mon Sep 29 21:28:26 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 29 Sep 2025 21:28:26 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v10] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 20:46:13 GMT, Thomas Fitzsimmons wrote: > Now `SunPKCS11`'s `HMAC-SHA256` is used, so my testing is satisfied: Thanks for trying this out with a PKCS #11 provider. `Mac.PBEWithHmacSHA256` is not used because inside its SunJCE implementation the PBKDF2 key length is hardcoded to the Hmac's _block_ length. On the other hand, in PKCS12's PBMAC1, the key length SHOULD be the _output_ length of Hmac. Without a more flexible `AlgorithmParameterSpec` to supply the full parameters, we don't intend to add `Mac.PBEWithHmacSHA256` to SunPKCS11 very soon. The current recommended approach way to use PBMAC1 is exactly what is shown in this PR: `SecretKeyFactory.PBKDF2With` and then a raw Hmac. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24429#issuecomment-3349110613 From mpowers at openjdk.org Tue Sep 30 04:00:53 2025 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 30 Sep 2025 04:00:53 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: <_o21Ka_ZkI3a5noqBvHjwynh4ceOQ1gIIdJC2xlJkUk=.4ed60c3f-5ea9-4fdf-9f8e-576349544c77@github.com> References: <_o21Ka_ZkI3a5noqBvHjwynh4ceOQ1gIIdJC2xlJkUk=.4ed60c3f-5ea9-4fdf-9f8e-576349544c77@github.com> Message-ID: On Tue, 23 Sep 2025 11:40:03 GMT, Matthew Donovan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> default salt length and one other comment from Weijun > > test/jdk/sun/security/pkcs12/PBMAC1Encoding.java line 39: > >> 37: public class PBMAC1Encoding { >> 38: // A.1. Valid PKCS #12 File with SHA-256 HMAC and PRF >> 39: static final String A1 = > > Can you add a comment explaining how to create these Strings? I added a comment that these tests are from RFC 9879. The RFC doesn't mention how the strings were created. They are base64 encoded PKCS12 keystores. > test/jdk/sun/security/pkcs12/PBMAC1Encoding.java line 423: > >> 421: ks = KeyStore.getInstance("PKCS12"); >> 422: ks.load(new ByteArrayInputStream(Base64.getDecoder().decode(A2)), >> 423: password.toCharArray()); > > Throw an exception after `ks.load()`. Otherwise, if `load()` doesn't throw anything, the test will pass when it shouldn't. A2 should pass now. `load()` shouldn't throw anything. > test/jdk/sun/security/pkcs12/PBMAC1Encoding.java line 445: > >> 443: ks = KeyStore.getInstance("PKCS12"); >> 444: ks.load(new ByteArrayInputStream(Base64.getDecoder().decode(A4)), >> 445: password.toCharArray()); > > throw an exception after `ks.load()` here and for A.5 and A.6 test cases. A4-A6 are expected to throw an exception. That's why I catch the exception and print "pass". Am I missing something? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389780036 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389780245 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2389780637 From fandreuzzi at openjdk.org Tue Sep 30 07:58:55 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 30 Sep 2025 07:58:55 GMT Subject: Withdrawn: 8368756: Skip sun/security/provider/acvp/Launcher.java when ACVP-Server artifact isn't found In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 09:42:36 GMT, Francesco Andreuzzi wrote: > I propose to skip the test when the ACVP-Server artifact isn't found, instead of throwing the following exception: > > java.io.IOException: Cannot find the artifact ACVP-Server > at jdk.test.lib.artifacts.ArtifactResolver.fetchOne(ArtifactResolver.java:100) > at Launcher.main(Launcher.java:117) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1474) > Caused by: jdk.test.lib.artifacts.ArtifactResolverException: Couldn't automatically resolve dependency for ACVP-Server > Please specify the location using jdk.test.lib.artifacts.ACVP-Server > at jdk.test.lib.artifacts.DefaultArtifactManager.resolve(DefaultArtifactManager.java:39) > at jdk.test.lib.artifacts.DefaultArtifactManager.resolve(DefaultArtifactManager.java:32) > at jdk.test.lib.artifacts.ArtifactResolver.resolve(ArtifactResolver.java:61) > at jdk.test.lib.artifacts.ArtifactResolver.fetchOne(ArtifactResolver.java:96) > ... 5 more This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27518 From fandreuzzi at openjdk.org Tue Sep 30 07:58:54 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 30 Sep 2025 07:58:54 GMT Subject: RFR: 8368756: Skip sun/security/provider/acvp/Launcher.java when ACVP-Server artifact isn't found In-Reply-To: References: Message-ID: <86zguKN_M1vLSeeB2__kyIqL_GI3xVrC6feUwycnHTU=.141de00d-fa0a-4efd-a1df-54d66dba765f@github.com> On Fri, 26 Sep 2025 09:42:36 GMT, Francesco Andreuzzi wrote: > I propose to skip the test when the ACVP-Server artifact isn't found, instead of throwing the following exception: > > java.io.IOException: Cannot find the artifact ACVP-Server > at jdk.test.lib.artifacts.ArtifactResolver.fetchOne(ArtifactResolver.java:100) > at Launcher.main(Launcher.java:117) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335) > at java.base/java.lang.Thread.run(Thread.java:1474) > Caused by: jdk.test.lib.artifacts.ArtifactResolverException: Couldn't automatically resolve dependency for ACVP-Server > Please specify the location using jdk.test.lib.artifacts.ACVP-Server > at jdk.test.lib.artifacts.DefaultArtifactManager.resolve(DefaultArtifactManager.java:39) > at jdk.test.lib.artifacts.DefaultArtifactManager.resolve(DefaultArtifactManager.java:32) > at jdk.test.lib.artifacts.ArtifactResolver.resolve(ArtifactResolver.java:61) > at jdk.test.lib.artifacts.ArtifactResolver.fetchOne(ArtifactResolver.java:96) > ... 5 more Closing, duplicate of #27491 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27518#issuecomment-3350492334 From djelinski at openjdk.org Tue Sep 30 08:14:13 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 30 Sep 2025 08:14:13 GMT Subject: RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider [v2] In-Reply-To: References: Message-ID: <44icvjzKcQKQluE3bn9tbleAnD5kqDt4sXBs2vaVHAY=.1042d1b0-53dd-4bcc-bb2d-1d8b170a3c3a@github.com> > Change SunJSSE to use `TlsUpdateNplus1` instead of `AES` as the key algorithm when deriving the next application traffic secret. > > SunPKCS11 provider checks the key length when creating an `AES` key, and since 384 bits is not a valid AES key length, the key creation fails. > > `TlsUpdateNplus1` is [already recognized](https://github.com/openjdk/jdk/blob/3c9fd7688f4d73067db9b128c329ca7603a60578/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L287) as a standard TLS generic key by SunPKCS11. > > Key update is now exercised by the FipsModeTLS test. The test passes with the changes, fails without them. Other tier1-3 tests continue to pass. Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: - Remove isIv - Replace if/else with ternary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27498/files - new: https://git.openjdk.org/jdk/pull/27498/files/53e0d97d..aae20d41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27498&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27498&range=00-01 Stats: 16 lines in 1 file changed: 2 ins; 6 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27498/head:pull/27498 PR: https://git.openjdk.org/jdk/pull/27498 From djelinski at openjdk.org Tue Sep 30 08:20:53 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 30 Sep 2025 08:20:53 GMT Subject: RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider [v2] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 16:59:01 GMT, Valerie Peng wrote: >> src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 215: >> >>> 213: if (this == TlsKey) >>> 214: return cs.bulkCipher.algorithm; >>> 215: return algorithm; >> >> nit: how about just `return (this == TlsKey ? cs.bulkCipher.algorithm : algorithm);` > > In addition, looking at the KeySchedule enum, only `TlsIv` is of iv type, so overall we don't really need the `isIv` field. If we change the `getKeyLength(CipherSuite cs)` method as below, then we can remove the `isIv` field. > > + return switch (this) { > + case TlsUpdateNplus1->cs.hashAlg.hashLength; > + case TlsIv->cs.bulkCipher.ivSize; > + case TlsKey->cs.bulkCipher.keySize; > + default->throw new RuntimeException("Unexpected exception"); > + }; > > What do you think? Yes, that's a good cleanup, thanks for the suggestions. I applied the changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27498#discussion_r2390287221 From mdonovan at openjdk.org Tue Sep 30 11:31:40 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 30 Sep 2025 11:31:40 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v7] In-Reply-To: References: <_o21Ka_ZkI3a5noqBvHjwynh4ceOQ1gIIdJC2xlJkUk=.4ed60c3f-5ea9-4fdf-9f8e-576349544c77@github.com> Message-ID: On Tue, 30 Sep 2025 03:58:25 GMT, Mark Powers wrote: >> test/jdk/sun/security/pkcs12/PBMAC1Encoding.java line 445: >> >>> 443: ks = KeyStore.getInstance("PKCS12"); >>> 444: ks.load(new ByteArrayInputStream(Base64.getDecoder().decode(A4)), >>> 445: password.toCharArray()); >> >> throw an exception after `ks.load()` here and for A.5 and A.6 test cases. > > A4-A6 are expected to throw an exception. That's why I catch the exception and print "pass". > Am I missing something? As you say, `load()` is expected to throw an exception so if it doesn't, the test should fail. Without throwing an explicit exception after `ks.load()`, the test will still pass. Suggestion: try { ks = KeyStore.getInstance("PKCS12"); ks.load(...); throw new Exception("The expected exception was not thrown."); } catch (Exception expected) { System.out.println("PASS"); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2391025458 From fitzsim at openjdk.org Tue Sep 30 16:09:53 2025 From: fitzsim at openjdk.org (Thomas Fitzsimmons) Date: Tue, 30 Sep 2025 16:09:53 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v10] In-Reply-To: References: Message-ID: <-2jdw-e_EhETF-aBRjLvbHeREppOQKUD62VvuQPMlyo=.a3e7492f-f1e5-410d-8715-a871471856d5@github.com> On Mon, 29 Sep 2025 21:25:42 GMT, Weijun Wang wrote: > `Mac.PBEWithHmacSHA256` is not used because inside its SunJCE implementation the PBKDF2 key length is hardcoded to the Hmac's _block_ length. On the other hand, in PKCS12's PBMAC1, the key length SHOULD be the _output_ length of Hmac. Makes sense, thanks for the explanation; I rechecked the code and found the two differing `PBEKeySpec` constructions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24429#issuecomment-3352890070 From mullan at openjdk.org Tue Sep 30 16:57:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 30 Sep 2025 16:57:57 GMT Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory [v3] In-Reply-To: References: Message-ID: <4TSVM7Qal6DH3FrVDp1M5yg8aA7EwbqIkAbj-4oLGPE=.10a028b3-1f7d-4fc0-b17d-04aa0a977800@github.com> On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao wrote: >> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip) >> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory. >> >> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE. >> >> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java. >> >> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference. > > Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused code > - removed the commented out code Since the fix is in the `java.naming` code, someone from the Core Libraries group should also review this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3353046686 From mullan at openjdk.org Tue Sep 30 18:50:10 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 30 Sep 2025 18:50:10 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v10] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 03:45:38 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > another day another iteration src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 71: > 69: * > 70: */ > 71: final public class PBKDF2Parameters { `public` should be before `final`. For reference, see the last sentence of https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.1.1 src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 151: > 149: */ > 150: public byte[] getSalt() { > 151: return this.salt.clone(); I don't think you need to return a clone here as you are just using it internally and not mutating it or exposing it to applications that could modify it. I'll double-check as I review the rest of the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392478165 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392519199 From mullan at openjdk.org Tue Sep 30 18:50:13 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 30 Sep 2025 18:50:13 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v10] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 22:55:28 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 81: >> >>> 79: // the pseudorandom function (default is HmacSHA1) >>> 80: private ObjectIdentifier kdfAlgo_OID = >>> 81: ObjectIdentifier.of(KnownOIDs.HmacSHA1); >> >> This field is not really used? This can just be a local variable when parsing the DER encoding. > > It's now referenced by PBMAC1Parameters because of an earlier comment so I can't remove it. I don't see it referenced, also it is private. I agree with Valerie that it looks like it can be a local variable inside the constructor on line 125. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392491941 From mullan at openjdk.org Tue Sep 30 20:11:48 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 30 Sep 2025 20:11:48 GMT Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v10] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 03:45:38 GMT, Mark Powers wrote: >> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232) > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > another day another iteration src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 26: > 24: */ > 25: > 26: package com.sun.crypto.provider; This class can be moved to the `sun/security/pkcs12` package and made package-private as it is only referenced by `PKCS12KeyStore`. We can always move it again later if necessary. src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 58: > 56: * -- PBKDF2 > 57: * > 58: * {@link PBKDF2Parameters} I don't think this link works since `PBKDF2Parameters` is in another package. Note: javadoc is not generated by default for internal classes. While it is still helpful to write class/method comments in the javadoc format, for something like the above, it might be more useful to say something like "See sun.security.util.PBKDF2Parameters for ..." so it is more readable as a comment. src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 84: > 82: private int keyLength = -1; > 83: > 84: protected void Init(AlgorithmParameterSpec paramSpec) I don't think you need a separate method. Put this code in the constructor. Same for the other `Init` method. Then you can also make the fields final. src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 86: > 84: protected void Init(AlgorithmParameterSpec paramSpec) > 85: throws InvalidParameterSpecException { > 86: if (!(paramSpec instanceof PBEParameterSpec)) { Use the instanceof pattern (see JEP 394) to avoid the need to cast on lines 90 and 91. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 51: > 49: * @author Sharon Liu > 50: */ > 51: It would be useful to add the ASN.1 definition here for reference. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 174: > 172: } > 173: > 174: void processMacData(AlgorithmParameterSpec params, Can be static? src/java.base/share/classes/sun/security/pkcs12/MacData.java line 178: > 176: throws Exception { > 177: final String kdfHmac; > 178: final String Hmac; Use lower-case as first letter of variable names, s/Hmac/hmac src/java.base/share/classes/sun/security/pkcs12/MacData.java line 186: > 184: kdfHmac = macAlgorithm; > 185: Hmac = macAlgorithm; > 186: } Did you consider adding another kdfHmac parameter to the method and passing in the correct values? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392601034 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392616902 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392624684 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392641323 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392648607 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392679324 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392669962 PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2392695506 From abarashev at openjdk.org Tue Sep 30 20:21:18 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 30 Sep 2025 20:21:18 GMT Subject: RFR: 8366453: TLS 1.3 KeyUpdate record is not rejected if not on a record boundary In-Reply-To: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> References: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> Message-ID: On Mon, 22 Sep 2025 19:48:20 GMT, Alice Pellegrini wrote: > According to RFC 8446 section 5.1 >> Handshake messages MUST NOT span key changes. Implementations >> MUST verify that all messages immediately preceding a key change >> align with a record boundary; if not, then they MUST terminate the >> connection with an "unexpected_message" alert. Because the >> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate >> messages can immediately precede a key change, implementations >> MUST send these messages in alignment with a record boundary. > > The TLS implementation does not fail with alert(fatal, unexpected_message) when a KeyUpdate record is not on a record boundary, but this is required by the specification (as a key change happens immediately after a key update record) > > > Since the data on whether a message aligns with a record boundary is only known in the implementations of `InputRecord` (as even incomplete parts of other handshake messages, if coming after one of the mentioned handshakes records, would require a failure, making checking that said message is the last complete one of that record insufficient), and the fact that, **if the negotiated protocol is TLS13** _(or even DTLS13 in the future)_, knowing that any of the mentioned messages did not align with the record boundary is enough to fail the connection, I am proposing to add this as a method of `InputRecord`; > > In addition, even if the handshake context was accessible from within `InputRecord`, for both ServerHello and ClientHello the negotiated protocol version is not known when the input record is decoded. > > The change mentions the name of the message currently being consumed in the exception because (since the messages are consumed in the order in which they appear in the record's body, and the groups of messages contained in each record are consumed in the order in which said records were delivered) it can be shown that if that flag is set, the first consumer that calls `tls13keyChangeHsExceedsRecordBoundary` will correspond to the first message to violate the boundary requirement, among the messages in the record it was found in. > >

    > > I would appreciate suggestions on how to make the code better, especially in terms of where and how to store the fact that the violation might (if the negotiated protocol is or will be TLS13) have happened, and where to put the comments mentioning the specification RFC8446, for example in the `InputRecord` base class or the TLS13 Consumers that were modified. General comment: lines should not exceed 80 characters. There are many lines throughout this PR that are too long. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27437#issuecomment-3353664011 From abarashev at openjdk.org Tue Sep 30 20:29:19 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 30 Sep 2025 20:29:19 GMT Subject: RFR: 8366453: TLS 1.3 KeyUpdate record is not rejected if not on a record boundary In-Reply-To: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> References: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> Message-ID: On Mon, 22 Sep 2025 19:48:20 GMT, Alice Pellegrini wrote: > According to RFC 8446 section 5.1 >> Handshake messages MUST NOT span key changes. Implementations >> MUST verify that all messages immediately preceding a key change >> align with a record boundary; if not, then they MUST terminate the >> connection with an "unexpected_message" alert. Because the >> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate >> messages can immediately precede a key change, implementations >> MUST send these messages in alignment with a record boundary. > > The TLS implementation does not fail with alert(fatal, unexpected_message) when a KeyUpdate record is not on a record boundary, but this is required by the specification (as a key change happens immediately after a key update record) > > > Since the data on whether a message aligns with a record boundary is only known in the implementations of `InputRecord` (as even incomplete parts of other handshake messages, if coming after one of the mentioned handshakes records, would require a failure, making checking that said message is the last complete one of that record insufficient), and the fact that, **if the negotiated protocol is TLS13** _(or even DTLS13 in the future)_, knowing that any of the mentioned messages did not align with the record boundary is enough to fail the connection, I am proposing to add this as a method of `InputRecord`; > > In addition, even if the handshake context was accessible from within `InputRecord`, for both ServerHello and ClientHello the negotiated protocol version is not known when the input record is decoded. > > The change mentions the name of the message currently being consumed in the exception because (since the messages are consumed in the order in which they appear in the record's body, and the groups of messages contained in each record are consumed in the order in which said records were delivered) it can be shown that if that flag is set, the first consumer that calls `tls13keyChangeHsExceedsRecordBoundary` will correspond to the first message to violate the boundary requirement, among the messages in the record it was found in. > >

    > > I would appreciate suggestions on how to make the code better, especially in terms of where and how to store the fact that the violation might (if the negotiated protocol is or will be TLS13) have happened, and where to put the comments mentioning the specification RFC8446, for example in the `InputRecord` base class or the TLS13 Consumers that were modified. src/java.base/share/classes/sun/security/ssl/KeyUpdate.java line 197: > 195: && hc.conContext.inputRecord.t13keyChangeHsExceedsRecordBoundary()) { > 196: throw hc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, > 197: "KEYUPDATE messages must align with a record boundary"); s/KEYUPDATE/KEY_UPDATE/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2392755373 From abarashev at openjdk.org Tue Sep 30 20:32:18 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 30 Sep 2025 20:32:18 GMT Subject: RFR: 8366453: TLS 1.3 KeyUpdate record is not rejected if not on a record boundary In-Reply-To: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> References: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> Message-ID: On Mon, 22 Sep 2025 19:48:20 GMT, Alice Pellegrini wrote: > According to RFC 8446 section 5.1 >> Handshake messages MUST NOT span key changes. Implementations >> MUST verify that all messages immediately preceding a key change >> align with a record boundary; if not, then they MUST terminate the >> connection with an "unexpected_message" alert. Because the >> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate >> messages can immediately precede a key change, implementations >> MUST send these messages in alignment with a record boundary. > > The TLS implementation does not fail with alert(fatal, unexpected_message) when a KeyUpdate record is not on a record boundary, but this is required by the specification (as a key change happens immediately after a key update record) > > > Since the data on whether a message aligns with a record boundary is only known in the implementations of `InputRecord` (as even incomplete parts of other handshake messages, if coming after one of the mentioned handshakes records, would require a failure, making checking that said message is the last complete one of that record insufficient), and the fact that, **if the negotiated protocol is TLS13** _(or even DTLS13 in the future)_, knowing that any of the mentioned messages did not align with the record boundary is enough to fail the connection, I am proposing to add this as a method of `InputRecord`; > > In addition, even if the handshake context was accessible from within `InputRecord`, for both ServerHello and ClientHello the negotiated protocol version is not known when the input record is decoded. > > The change mentions the name of the message currently being consumed in the exception because (since the messages are consumed in the order in which they appear in the record's body, and the groups of messages contained in each record are consumed in the order in which said records were delivered) it can be shown that if that flag is set, the first consumer that calls `tls13keyChangeHsExceedsRecordBoundary` will correspond to the first message to violate the boundary requirement, among the messages in the record it was found in. > >

    > > I would appreciate suggestions on how to make the code better, especially in terms of where and how to store the fact that the violation might (if the negotiated protocol is or will be TLS13) have happened, and where to put the comments mentioning the specification RFC8446, for example in the `InputRecord` base class or the TLS13 Consumers that were modified. src/java.base/share/classes/sun/security/ssl/KeyUpdate.java line 194: > 192: PostHandshakeContext hc = (PostHandshakeContext)context; > 193: > 194: if (hc.negotiatedProtocol.useTLS13PlusSpec() Do we need this check? KeyUpdate is not available in versions prior to TLSv1.3. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2392761376 From abarashev at openjdk.org Tue Sep 30 20:42:29 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 30 Sep 2025 20:42:29 GMT Subject: RFR: 8366453: TLS 1.3 KeyUpdate record is not rejected if not on a record boundary In-Reply-To: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> References: <4BwaSdlSpv526OIeLN6pr7RFgbxeMOwiGoQkJx2LeNE=.2dc842d9-9aad-44ea-ac37-ed91980ba742@github.com> Message-ID: On Mon, 22 Sep 2025 19:48:20 GMT, Alice Pellegrini wrote: > According to RFC 8446 section 5.1 >> Handshake messages MUST NOT span key changes. Implementations >> MUST verify that all messages immediately preceding a key change >> align with a record boundary; if not, then they MUST terminate the >> connection with an "unexpected_message" alert. Because the >> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate >> messages can immediately precede a key change, implementations >> MUST send these messages in alignment with a record boundary. > > The TLS implementation does not fail with alert(fatal, unexpected_message) when a KeyUpdate record is not on a record boundary, but this is required by the specification (as a key change happens immediately after a key update record) > > > Since the data on whether a message aligns with a record boundary is only known in the implementations of `InputRecord` (as even incomplete parts of other handshake messages, if coming after one of the mentioned handshakes records, would require a failure, making checking that said message is the last complete one of that record insufficient), and the fact that, **if the negotiated protocol is TLS13** _(or even DTLS13 in the future)_, knowing that any of the mentioned messages did not align with the record boundary is enough to fail the connection, I am proposing to add this as a method of `InputRecord`; > > In addition, even if the handshake context was accessible from within `InputRecord`, for both ServerHello and ClientHello the negotiated protocol version is not known when the input record is decoded. > > The change mentions the name of the message currently being consumed in the exception because (since the messages are consumed in the order in which they appear in the record's body, and the groups of messages contained in each record are consumed in the order in which said records were delivered) it can be shown that if that flag is set, the first consumer that calls `tls13keyChangeHsExceedsRecordBoundary` will correspond to the first message to violate the boundary requirement, among the messages in the record it was found in. > >

    > > I would appreciate suggestions on how to make the code better, especially in terms of where and how to store the fact that the violation might (if the negotiated protocol is or will be TLS13) have happened, and where to put the comments mentioning the specification RFC8446, for example in the `InputRecord` base class or the TLS13 Consumers that were modified. test/jdk/sun/security/ssl/SSLEngineImpl/TLS13UnalignedKeyChangeHSMessage.java line 67: > 65: > 66: private ContextParameters getContextParameters() { > 67: return new ContextParameters("TLSv1.3", "PKIX", "SunX509"); Would be helpful to have a run of this test using TLSv1.2 protocol to verify nothing fails there. test/jdk/sun/security/ssl/SSLEngineImpl/TLS13UnalignedKeyChangeHSMessage.java line 95: > 93: if (sTOc.remaining() > 5 > 94: && (serverHelloMsg = > 95: extractHandshakeMsg(sTOc, SERVER_HELLO_ID, false) It would be nice to also test other messages like KeyUpdate and ClientHello. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2392783194 PR Review Comment: https://git.openjdk.org/jdk/pull/27437#discussion_r2392780458