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