From ascarpino at openjdk.org Thu May 1 00:20:56 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 1 May 2025 00:20:56 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: <9mfjkYfNkAF1AcivrGWStoKBvYU7upfrujgMo5r6muI=.7e655046-04ae-4e76-9598-76b77dfb478f@github.com> On Fri, 25 Apr 2025 12:41:34 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: >> >> - javadoc updates >> - code review comments > > src/java.base/share/classes/sun/security/ec/ECKeyFactory.java line 225: > >> 223: throws GeneralSecurityException { >> 224: if (keySpec instanceof X509EncodedKeySpec) { >> 225: return new ECPublicKeyImpl(((X509EncodedKeySpec)keySpec).getEncoded()); > > We can also use `instanceof` pattern matching here. Same on line 246. If left it because there were other `instanceof` if-else matching that I didn't want two different styles in the file. I dunno I'll think about it. > src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 157: > >> 155: } >> 156: >> 157: public byte[] getArrayS() { > > Why remove `getArrayS0`? Not worth saving those bytes? I just couldn't figure out why it needed to be S0 and not just S. There is no S1 and it uses the existing arrayS. Is there some spec that calls it S0? > src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 191: > >> 189: DerValue value = data.getDerValue(); >> 190: if (value.isContextSpecific((byte) 0)) { >> 191: attributes = value.getDataBytes(); // Save DER sequence > > At [0], it's `ECDomainParameters`. I don't think it's the same as `attributes` inside `OneAsymmetricKey`. The variable name should be different, but I'm not too concerned about since we've never supported them anyway. It's probably something that should be added, but probably in the future. > src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 195: > >> 193: return; >> 194: } >> 195: value = data.getDerValue(); > > The original code does not care about whether [0] comes before [1] or if there are duplicates. You modified code ensures only [1] can be after [0] but still allows duplicates (For example, [0], [1], [1]). The `while` on line 188 can be changed to `if` and we ensure `data.available() == 0` at the end. Sure > src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 201: > >> 199: BitArray bitArray = bits.data.getUnalignedBitString(); >> 200: pubKeyEncoded = new X509Key(algid, >> 201: bitArray).getEncoded(); > > We could have 2 copies of the public key, one here and one inside `OneAsymmetricKey`. Do you want to compare them? Have we seen such a DER? I'm sure is possible, but that sounds invalid to have two binary formats in one bytestream. If we are seriously concerned about that we should thrown an error rather than try to allow it. > src/java.base/share/classes/sun/security/util/DerValue.java line 195: > >> 193: >> 194: /** >> 195: * Returns true if the CONTEXT SPECIFIC bit is set in the type tag. > > `iff` was used to mean `if and only if`. It's more precise than a simple `if`. Ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2068976363 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2068971300 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2069653731 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2069653877 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2069393674 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2069678187 From ascarpino at openjdk.org Thu May 1 03:57:05 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 1 May 2025 03:57:05 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: On Mon, 28 Apr 2025 17:18:05 GMT, Weijun Wang wrote: >> I view this as an advanced feature for experienced users. The list is large and algorithm-dependent. For example an EC private key PEM could be PrivateKey.class, ECPrivateKey.class, PEMRecord.class, PKCS8EncodedKeySpec.class. I don't think it's realistic to list everything. > > I see. Maybe at least point out `PEMRecord` is always a valid option? This gives people a chance to read arbitrary (even invalid) PEMs. That is documented in the next paragraph. >> This is a private method that just converts the `pem` and `type` into a properly formatted PEM. Leading data is not applicable here. > > Yes, this method is private. But you allow `PEMEncoder().of().encode(PEMRecord)`. People might wonder why their leading data is lost. Then they can call PEMRecord.leadingData(). >> I'm not sure what you mean by "final" as it contains whatever the stream contains before the dashes. The point is not to parse the non-PEM data and store it as is. > > I meant the newline char at the end (before the "------BEGIN" chars). I just tried out your implementation, and noticed if there is nothing there, then `leadingData` is null; and if there is a line of text, `leadingData` contains the newline char at the end. > > I still think this is worth mentioning. Suppose someone wants to rewrite the PEM file with the leading data, they need to know they should not use `println`. > > BTW, I prefer trimming that newline char. Just my opinion. I see your point now, but `leadingData` is a byte array. If an app wrote the `leadingData` in a `ByteArrayInputStream`, followed by the PEM text, it would not be the same data written as the newline would be gone. Correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2069702691 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2069704157 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2069737448 From rhalade at openjdk.org Thu May 1 04:14:49 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 May 2025 04:14:49 GMT Subject: RFR: 8277424: javax/net/ssl/TLSCommon/TLSTest.java fails with connection refused In-Reply-To: <0gF7Q35dOatmUWSzREUx4gTAdWVGcS2D2NYIqzRaNQk=.a53bcfa1-9b71-4532-930a-5e2521d40d77@github.com> References: <0gF7Q35dOatmUWSzREUx4gTAdWVGcS2D2NYIqzRaNQk=.a53bcfa1-9b71-4532-930a-5e2521d40d77@github.com> Message-ID: On Wed, 23 Apr 2025 10:19:51 GMT, Mikhail Yankelevich wrote: > I could not replicate the issue after more than 64000 runs. However, I have done the following to increase stability and added logs in case this happens again. > > Changes: > * Specifically binding the client to the loopback address > * Added additional debug logging Marked as reviewed by rhalade (Reviewer). This bug could be closed as cannot reproduce but the enhancement you did is also good one to have. LGTM. ------------- PR Review: https://git.openjdk.org/jdk/pull/24823#pullrequestreview-2809122643 PR Comment: https://git.openjdk.org/jdk/pull/24823#issuecomment-2844041593 From rhalade at openjdk.org Thu May 1 04:26:44 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 May 2025 04:26:44 GMT Subject: RFR: 8354235: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java failed with java.net.SocketException: An established connection was aborted by the software in your host machine In-Reply-To: References: Message-ID: On Mon, 21 Apr 2025 18:42:55 GMT, Matthew Donovan wrote: > In this PR, I updated the default `serverAddress` field to use the loopback interface. I also removed some unnecessary logic around creating the server interface and the client connecting code. Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24776#pullrequestreview-2809139015 From rhalade at openjdk.org Thu May 1 05:26:48 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 May 2025 05:26:48 GMT Subject: RFR: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java In-Reply-To: <3Tyz1fAexWwXPNzndFkG4SLcl46kKtAk4uZJymFoSz8=.0c429e07-5dfb-45d6-8a06-fdc99fad50a2@github.com> References: <3Tyz1fAexWwXPNzndFkG4SLcl46kKtAk4uZJymFoSz8=.0c429e07-5dfb-45d6-8a06-fdc99fad50a2@github.com> Message-ID: <4tKSerxNo__zxrEn0srDR-FCdxvQyvDl8njw-_mC2NA=.709fb25e-93f0-4889-91a9-ef13dae9d72b@github.com> On Mon, 17 Mar 2025 13:19:55 GMT, Fernando Guallini wrote: > The test `javax/net/ssl/DTLS/PacketLossRetransmission` takes about ~2 to complete. The reason is that, in multiple scenarios, the server/client socket times out after 10 seconds waiting to receive a DatagramPacket that has been removed (to simulate a packet loss). > After reducing the time out only for such scenarios, the total test execution is completed within ~20 seconds on average. Other scenarios do not throw SocketTimeOut, no need to update. test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java line 91: > 89: > 90: PacketLossRetransmission testCase = new PacketLossRetransmission(); > 91: if (args.length >= 4 && "shortTimeOut".equals(args[3])) { Update this to `equalsIgnoreCase`. How do you decide which test to use `shortTimeOut` on? Please add some verbiage as a guidance. Side note - how is `args[2]` used in this test? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24079#discussion_r2069865085 From rhalade at openjdk.org Thu May 1 05:02:47 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 May 2025 05:02:47 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java In-Reply-To: References: Message-ID: <41kpRB4UcONEHH7utWw3B1mOjrnafSwm7ThOOsJHppQ=.c9f58537-e92e-4da0-a503-54c1942b1820@github.com> On Thu, 17 Apr 2025 09:51:40 GMT, Mikhail Yankelevich wrote: > * Changed the test to use scratch directory > * Cleaned up the imports test/jdk/sun/security/pkcs12/P12SecretKey.java line 68: > 66: > 67: // temporary files are created in scratch directory > 68: final File ksFile = File.createTempFile("test", ".test", new File(".")); Instead, update test to use `createTempFile` from https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L815. It is designed as an replacement that doesn't leave files behind in `tmp`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24718#discussion_r2069852784 From vyazici at openjdk.org Thu May 1 05:38:27 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 1 May 2025 05:38:27 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods Message-ID: Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. ------------- Commit messages: - Improve `JavaLangAccess` documentation Changes: https://git.openjdk.org/jdk/pull/24982/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353197 Stats: 41 lines in 1 file changed: 22 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982 PR: https://git.openjdk.org/jdk/pull/24982 From myankelevich at openjdk.org Thu May 1 08:48:48 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 1 May 2025 08:48:48 GMT Subject: RFR: 8277424: javax/net/ssl/TLSCommon/TLSTest.java fails with connection refused In-Reply-To: References: <0gF7Q35dOatmUWSzREUx4gTAdWVGcS2D2NYIqzRaNQk=.a53bcfa1-9b71-4532-930a-5e2521d40d77@github.com> Message-ID: <_PqtbMaoGi6jcAnF3F_4LKkiTNvnBDy-pq-0DoOIlGY=.b19333c5-3b92-4513-a3e3-8ec5ac41e83c@github.com> On Thu, 1 May 2025 04:12:10 GMT, Rajan Halade wrote: >> I could not replicate the issue after more than 64000 runs. However, I have done the following to increase stability and added logs in case this happens again. >> >> Changes: >> * Specifically binding the client to the loopback address >> * Added additional debug logging > > This bug could be closed as cannot reproduce but the enhancement you did is also good one to have. LGTM. @rhalade thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24823#issuecomment-2844394120 From dfuchs at openjdk.org Thu May 1 08:47:46 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 1 May 2025 08:47:46 GMT Subject: RFR: 8349910: Implement HTTP/3 for the HTTP Client API [v4] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976). > > The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 412 commits: - merge latest changes from master branch - merge latest changes from master branch - http3: jep review feedback: rename HttpRequest.HttpRequestOption into top-level HttpOption. Http3DiscoveryMode is now an inner class in HttpOption. Improved protocol selection documentation in HttpClient class-level apiNote. Add links from Builder.version methods. - merge latest changes from master branch - http3: add missing

separator to Http3DiscoveryMode.ALT_SVC API documentation - http3: improve documentation for Http3DiscoveryMode.ALT_SVC - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test - http3: minor improvement to log message - http3: Artur's review - remove commented out code from test - ... and 402 more: https://git.openjdk.org/jdk/compare/526951db...9156a51e ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=03 Stats: 102846 lines in 472 files changed: 100217 ins; 1120 del; 1509 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 duke at openjdk.org Thu May 1 08:48:49 2025 From: duke at openjdk.org (duke) Date: Thu, 1 May 2025 08:48:49 GMT Subject: RFR: 8277424: javax/net/ssl/TLSCommon/TLSTest.java fails with connection refused In-Reply-To: <0gF7Q35dOatmUWSzREUx4gTAdWVGcS2D2NYIqzRaNQk=.a53bcfa1-9b71-4532-930a-5e2521d40d77@github.com> References: <0gF7Q35dOatmUWSzREUx4gTAdWVGcS2D2NYIqzRaNQk=.a53bcfa1-9b71-4532-930a-5e2521d40d77@github.com> Message-ID: On Wed, 23 Apr 2025 10:19:51 GMT, Mikhail Yankelevich wrote: > I could not replicate the issue after more than 64000 runs. However, I have done the following to increase stability and added logs in case this happens again. > > Changes: > * Specifically binding the client to the loopback address > * Added additional debug logging @myankelev Your change (at version a00505caa9e52fc64b6a4e09ff969f1e1daab937) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24823#issuecomment-2844395937 From myankelevich at openjdk.org Thu May 1 10:31:20 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 1 May 2025 10:31:20 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v2] In-Reply-To: References: Message-ID: > * Changed the test to use scratch directory > * Cleaned up the imports Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: changed file creation to use Utils.createTempFile ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24718/files - new: https://git.openjdk.org/jdk/pull/24718/files/6496e9d7..44b39103 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24718&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24718&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24718.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24718/head:pull/24718 PR: https://git.openjdk.org/jdk/pull/24718 From alanb at openjdk.org Thu May 1 10:38:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 1 May 2025 10:38:44 GMT Subject: RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions In-Reply-To: References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com> Message-ID: <45gEnigXd-WxofLVYu0K6QDbLq72YZvzroUWy-owk6M=.d25d1075-2488-4982-906f-5cc431429823@github.com> On Tue, 15 Apr 2025 07:46:52 GMT, Alan Bateman wrote: >> Hi, this is a proposal to fix 8352728. >> >> The main idea is to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The rationale behind this decision is the following: >> >> 1. In _Windows_, `File::getCanonicalPath` handles restricted permissions in parent directories. Contrarily, `Path::toRealPath` fails with `AccessDeniedException`. >> 2. In _Linux_, `File::getCanonicalPath` handles non-regular files (e.g. `/dev/stdin`). Contrarily, `Path::toRealPath` fails with `NoSuchFileException`. >> >> #### Windows Case >> >> @martinuy and I tracked down the `File::getCanonicalPath` vs `Path::toRealPath` behaviour differences in _Windows_. Both methods end up calling the [`FindFirstFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew) API inside a loop for each parent directory in the path, until they include the leaf: >> >> * [`File::getCanonicalPath`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/java/io/File.java#L618 "src/java.base/share/classes/java/io/File.java:618") goes through the following stack into `FindFirstFileW`: >> * [`WinNTFileSystem::canonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/classes/java/io/WinNTFileSystem.java#L473 "src/java.base/windows/classes/java/io/WinNTFileSystem.java:473") >> * [`WinNTFileSystem::canonicalize0`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/WinNTFileSystem_md.c#L288 "src/java.base/windows/native/libjava/WinNTFileSystem_md.c:288") >> * [`wcanonicalize`](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L233 "src/java.base/windows/native/libjava/canonicalize_md.c:233") (here is the loop) >> * If `FindFirstFileW` fails with `ERROR_ACCESS_DENIED`, `lastErrorReportable` is consulted, the error is [considered non-reportable](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L139 "src/java.base/windows/native/libjava/canonicalize_md.c:139") and the iteration is stopped [here](https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/windows/native/libjava/canonicalize_md.c#L246-L250 "src/ja... > >> File::getCanonicalPath seems to take the best-effort approach (both in Linux and Windows), whereas Path::toRealPath is stricter. > > Path::toRealPath is doing the right thing, and consistent with realpath(2). The issue with File::getCanonicalXXX is that it is specified to return a canonical file even if it doesn't exist, so this is why you see a lot more code to compute a result. > > Maybe the recursive include check them maybe it should use the file key instead. > @AlanBateman are you ok with letting the original [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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-2844618754 From myankelevich at openjdk.org Thu May 1 10:31:20 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 1 May 2025 10:31:20 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v2] In-Reply-To: <41kpRB4UcONEHH7utWw3B1mOjrnafSwm7ThOOsJHppQ=.c9f58537-e92e-4da0-a503-54c1942b1820@github.com> References: <41kpRB4UcONEHH7utWw3B1mOjrnafSwm7ThOOsJHppQ=.c9f58537-e92e-4da0-a503-54c1942b1820@github.com> Message-ID: On Thu, 1 May 2025 05:00:13 GMT, Rajan Halade wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> changed file creation to use Utils.createTempFile > > test/jdk/sun/security/pkcs12/P12SecretKey.java line 68: > >> 66: >> 67: // temporary files are created in scratch directory >> 68: final File ksFile = File.createTempFile("test", ".test", new File(".")); > > Instead, update test to use `createTempFile` from https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/Utils.java#L815. It is designed as an replacement that doesn't leave files behind in `tmp`. Changed in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24718#discussion_r2070133623 From mdonovan at openjdk.org Thu May 1 11:07:49 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 1 May 2025 11:07:49 GMT Subject: Integrated: 8354235: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java failed with java.net.SocketException: An established connection was aborted by the software in your host machine In-Reply-To: References: Message-ID: On Mon, 21 Apr 2025 18:42:55 GMT, Matthew Donovan wrote: > In this PR, I updated the default `serverAddress` field to use the loopback interface. I also removed some unnecessary logic around creating the server interface and the client connecting code. This pull request has now been integrated. Changeset: 7b317623 Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/7b317623756d3e21d029bcded8a5e15de070a0c9 Stats: 12 lines in 1 file changed: 0 ins; 7 del; 5 mod 8354235: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java failed with java.net.SocketException: An established connection was aborted by the software in your host machine Reviewed-by: rhalade ------------- PR: https://git.openjdk.org/jdk/pull/24776 From weijun at openjdk.org Thu May 1 11:53:45 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 11:53:45 GMT Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 21:57:39 GMT, Mark Powers wrote: >> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded. >> >> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input. > > src/java.base/share/classes/sun/security/util/KeyUtil.java line 511: > >> 509: } >> 510: case "expandedkey" -> { >> 511: if (expanded == null) expanded = expand.apply(pname, seed); > > This looks good to me, but the style guideline is > > if (expanded == null) { > expanded = expand.apply(pname, seed); > } I'll fix them. Thanks. > test/jdk/sun/security/provider/named/NamedEdDSA.java line 1: > >> 1: /* > > I didn't expect an EdDSA test in this PQC bug fix. This is an existing test. It just demonstrates how the `NamedXyz` classes can be used to implement any algorithm that can be configured with a parameter set name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2070185948 PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2070185664 From weijun at openjdk.org Thu May 1 11:57:45 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 11:57:45 GMT Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 22:33:24 GMT, Mark Powers wrote: >> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded. >> >> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input. > > src/java.base/share/classes/sun/security/util/KeyUtil.java line 506: > >> 504: if (seed == null) return null; >> 505: skOctets = new byte[seed.length + 2]; >> 506: skOctets[0] = (byte)0x80; > > Is there any value in using the DerValue class to put a name on these constants? I think what you have is easy enough to read. You mean I can use `DerValue.TAG_CONTEXT + 0` instead of 0x80? I can, but yes it's no more readable than the number itself. It's probably all about consistency. If I use `TAG_CONTEXT` here, I might also need to use `tag_OctetString`, `tag_Sequence`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2070188958 From weijun at openjdk.org Thu May 1 13:01:38 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 13:01:38 GMT Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v2] In-Reply-To: References: Message-ID: > The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded. > > Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: safer privKeyToPubKey; updated desciptions for the properties; adding braces to if blocks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24969/files - new: https://git.openjdk.org/jdk/pull/24969/files/67e9752a..1adbad42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=00-01 Stats: 61 lines in 5 files changed: 33 ins; 1 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/24969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24969/head:pull/24969 PR: https://git.openjdk.org/jdk/pull/24969 From liach at openjdk.org Thu May 1 13:04:47 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 13:04:47 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods In-Reply-To: References: Message-ID: On Thu, 1 May 2025 05:33:29 GMT, Volkan Yazici wrote: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 315: > 313: * WARNING: The caller of this method shall relinquish and transfer the > 314: * ownership of the byte array to the callee, since the later will not > 315: * make a copy. I think we should add a note on why no copy is made - there may be multiple reads to the input array for decoding, so the input array must not be accessible by untrusted code, which can racily modify it. A side effect is that this array is simply reused if it's eligible to be the string content array, which is unfortunately abused in a few places in the JDK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2070244058 From mpowers at openjdk.org Thu May 1 13:22:47 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 1 May 2025 13:22:47 GMT Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 11:55:20 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/KeyUtil.java line 506: >> >>> 504: if (seed == null) return null; >>> 505: skOctets = new byte[seed.length + 2]; >>> 506: skOctets[0] = (byte)0x80; >> >> Is there any value in using the DerValue class to put a name on these constants? I think what you have is easy enough to read. > > You mean I can use `DerValue.TAG_CONTEXT + 0` instead of 0x80? I can, but yes it's no more readable than the number itself. It's probably all about consistency. If I use `TAG_CONTEXT` here, I might also need to use `tag_OctetString`, `tag_Sequence`. I agree. Leave it the way you have it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2070260625 From mullan at openjdk.org Thu May 1 13:13:46 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 1 May 2025 13:13:46 GMT Subject: RFR: 8353001: Remove leftover Security Manager parsing code in sun.security.util.Debug [v3] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 15:19:10 GMT, Koushik Muthukrishnan Thirupattur wrote: >> The private marshal() method in sun.security.util.Debug still contains code to parse "permission=" and "codebase=" options. These sub-options were part of the "access" option which was removed in JDK 24 as part of JEP 486, so this code can be removed. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8353001:Remove leftover Security Manager parsing code in sun.security.util.Debug Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24731#pullrequestreview-2809762066 From abarashev at openjdk.org Thu May 1 13:11:52 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 1 May 2025 13:11:52 GMT Subject: Integrated: 8355779: When no "signature_algorithms_cert" extension is present we do not apply certificate scope constraints to algorithms in "signature_algorithms" extension In-Reply-To: <7ccBNaPfuKqjmuPa4PaCMz4eTslkQZNZSycYSI03C0g=.0833fdd3-ffb2-4a83-bc83-52e4ef76554f@github.com> References: <7ccBNaPfuKqjmuPa4PaCMz4eTslkQZNZSycYSI03C0g=.0833fdd3-ffb2-4a83-bc83-52e4ef76554f@github.com> Message-ID: On Mon, 28 Apr 2025 21:31:49 GMT, Artur Barashev wrote: > Per TLSv1.3 RFC: > > > If no "signature_algorithms_cert" extension is > present, then the "signature_algorithms" extension also applies to > signatures appearing in certificates. > > > When no "signature_algorithms_cert" extension is present in ClientHello we simply copy "signature_algorithms" extension algorithms already filtered with HANDSHAKE_SCOPE to `peerRequestedCertSignSchemes`. Instead we should filter "signature_algorithms" extension algorithms with CERTIFICATE_SCOPE as certain algorithms are allowed to be used in certificate signatures but not in handshake signatures. This pull request has now been integrated. Changeset: 34807df7 Author: Artur Barashev Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/34807df7627b067f750578987c941213a5f8336a Stats: 95 lines in 1 file changed: 47 ins; 44 del; 4 mod 8355779: When no "signature_algorithms_cert" extension is present we do not apply certificate scope constraints to algorithms in "signature_algorithms" extension Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/24939 From weijun at openjdk.org Thu May 1 14:03:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 14:03:51 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v6] In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 21:04:51 GMT, Valerie Peng wrote: >> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings. >> >> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > address review comments from Mark A tiny comment. Otherwise, LGTM. test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java line 46: > 44: * @summary test key derivation on a SunPKCS11 SecretKeyFactory service > 45: * @library /test/lib .. > 46: * @modules java.base/com.sun.crypto.provider:open This `:open` line is useless now. No more reflection code. ------------- PR Review: https://git.openjdk.org/jdk/pull/24068#pullrequestreview-2809825973 PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2070293015 From weijun at openjdk.org Thu May 1 14:50:31 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 14:50:31 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: > Finalize the KDF API. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - merge - add a positive debug log and update exception message - enhancing exception messages and debug outputs - update @since tags as required by JEP 12 - add enum back - the change ------------- Changes: https://git.openjdk.org/jdk/pull/24520/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=04 Stats: 206 lines in 17 files changed: 158 ins; 29 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24520.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520 PR: https://git.openjdk.org/jdk/pull/24520 From mullan at openjdk.org Thu May 1 15:18:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 1 May 2025 15:18:53 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v18] In-Reply-To: References: Message-ID: <9YxbGEH3FSwiE4Inp69buCoObFthqTwhtLCKidTU9sE=.f6f98bfb-274d-4baf-8b34-94cd02739ff5@github.com> On Thu, 24 Apr 2025 21:24:49 GMT, Weijun Wang wrote: >> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >> ![HPKEParameterSpec ? 11 54 ? 04-21](https://github.com/user-attachments/assets/da309585-db51-40d6-b291-3d38040d6292) > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > engineGetBlockSize and engineGetOutputSize returns 0 when not initialized src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 46: > 44: senderCipher.init(Cipher.ENCRYPT_MODE, kp.getPublic(), ps); > 45: > 46: // Retrieve the actual parameters used from the sender. "from the sender" sound like it is being retrieved from the sender side over the network. Suggest replacing this with "from the senderCipher". src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 50: > 48: .getParameterSpec(HPKEParameterSpec.class); > 49: > 50: // Retrieve the key encapsulation message (the KEM output) from the sender. Same comment as above about "from the sender". src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 51: > 49: > 50: // Retrieve the key encapsulation message (the KEM output) from the sender. > 51: // It can also be retrieved using sender.getIV(). s/sender/senderCipher/ src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 54: > 52: byte[] kemEncap = actual.encapsulation(); > 53: > 54: // The HPKE recipient side is initialized with its own private key, This is a question, not a comment. How does the recipient know what algorithm identifiers to use? Would these be exchanged as part of a protocol that used HPKE? src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 60: > 58: HPKEParameterSpec pr = HPKEParameterSpec > 59: .of(actual.kem_id(), actual.kdf_id(), actual.aead_id()) > 60: .info("app_info".getBytes(StandardCharsets.UTF_8)) Question, not necessarily a comment. Why is info also needed for decryption? Isn't it only needed on the encryption side when deriving the key? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070378295 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070378786 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070381394 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070382844 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070394105 From weijun at openjdk.org Thu May 1 15:21:46 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 15:21:46 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 23:38:03 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Moved too fast src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1691: > 1689: // ...now the final expand. > 1690: SecretKey key = hkdf.expand(derivedSecret, hkdfInfo, length, > 1691: "label"); Are you using "label" as the algorithm name for the output? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070397219 From weijun at openjdk.org Thu May 1 15:28:47 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 15:28:47 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 10:31:20 GMT, Mikhail Yankelevich wrote: >> * Changed the test to use scratch directory >> * Cleaned up the imports > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > changed file creation to use Utils.createTempFile LGTM. Or, you can just create files named `algName-keySize.ks`. There is no need to be random here. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24718#pullrequestreview-2810033523 From rhalade at openjdk.org Thu May 1 15:39:47 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 May 2025 15:39:47 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 15:25:46 GMT, Weijun Wang wrote: > LGTM. Or, you can just create files named `algName-keySize.ks`. There is no need to be random here. +1. This would be a good enhancement to include. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24718#issuecomment-2845087042 From weijun at openjdk.org Thu May 1 15:38:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 15:38:51 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v18] In-Reply-To: <9YxbGEH3FSwiE4Inp69buCoObFthqTwhtLCKidTU9sE=.f6f98bfb-274d-4baf-8b34-94cd02739ff5@github.com> References: <9YxbGEH3FSwiE4Inp69buCoObFthqTwhtLCKidTU9sE=.f6f98bfb-274d-4baf-8b34-94cd02739ff5@github.com> Message-ID: On Thu, 1 May 2025 15:02:11 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> engineGetBlockSize and engineGetOutputSize returns 0 when not initialized > > src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 46: > >> 44: senderCipher.init(Cipher.ENCRYPT_MODE, kp.getPublic(), ps); >> 45: >> 46: // Retrieve the actual parameters used from the sender. > > "from the sender" sound like it is being retrieved from the sender side over the network. Suggest replacing this with "from the senderCipher". How about "Extracts the actual parameters from `senderCipher`"? > src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 50: > >> 48: .getParameterSpec(HPKEParameterSpec.class); >> 49: >> 50: // Retrieve the key encapsulation message (the KEM output) from the sender. > > Same comment as above about "from the sender". How about "Extracts the key encapsulation message (the KEM output) from `senderCipher`"? > src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 51: > >> 49: >> 50: // Retrieve the key encapsulation message (the KEM output) from the sender. >> 51: // It can also be retrieved using sender.getIV(). > > s/sender/senderCipher/ Correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070417472 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070418278 PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070419002 From rhalade at openjdk.org Thu May 1 15:36:48 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 May 2025 15:36:48 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 10:31:20 GMT, Mikhail Yankelevich wrote: >> * Changed the test to use scratch directory >> * Cleaned up the imports > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > changed file creation to use Utils.createTempFile test/jdk/sun/security/pkcs12/P12SecretKey.java line 88: > 86: " keystore"); > 87: } else { > 88: System.err.println("ERROR: keys are NOT equal after storing in " Test should fail here, throw RuntimeException. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24718#discussion_r2070416780 From weijun at openjdk.org Thu May 1 16:27:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 16:27:51 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v18] In-Reply-To: <9YxbGEH3FSwiE4Inp69buCoObFthqTwhtLCKidTU9sE=.f6f98bfb-274d-4baf-8b34-94cd02739ff5@github.com> References: <9YxbGEH3FSwiE4Inp69buCoObFthqTwhtLCKidTU9sE=.f6f98bfb-274d-4baf-8b34-94cd02739ff5@github.com> Message-ID: On Thu, 1 May 2025 15:06:11 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> engineGetBlockSize and engineGetOutputSize returns 0 when not initialized > > src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 54: > >> 52: byte[] kemEncap = actual.encapsulation(); >> 53: >> 54: // The HPKE recipient side is initialized with its own private key, > > This is a question, not a comment. How does the recipient know what algorithm identifiers to use? Would these be exchanged as part of a protocol that used HPKE? I've looked at several protocols that uses HPKE: 1. For (Oblivious DNS over HTTPS)[https://datatracker.ietf.org/doc/html/rfc9230#name-configuration-and-public-ke], server advertises its public keys each in a `ObliviousDoHConfig ` structure with supported algorithm identifiers. 2. For (TLS Encrypted Client Hello)[https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-24#name-encrypted-clienthello-confi], the server advertises its public keys, each with a `kem_id` and a set of supported `kdf_id` and `aead_id`, identified by a `config_id`, in an `ECHConfig` structure. Client will tell server which `config_id` it uses. So it seems each side chooses the exact algorithm identifiers and even the sender does not require default values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070476759 From myankelevich at openjdk.org Thu May 1 16:18:52 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 1 May 2025 16:18:52 GMT Subject: Integrated: 8277424: javax/net/ssl/TLSCommon/TLSTest.java fails with connection refused In-Reply-To: <0gF7Q35dOatmUWSzREUx4gTAdWVGcS2D2NYIqzRaNQk=.a53bcfa1-9b71-4532-930a-5e2521d40d77@github.com> References: <0gF7Q35dOatmUWSzREUx4gTAdWVGcS2D2NYIqzRaNQk=.a53bcfa1-9b71-4532-930a-5e2521d40d77@github.com> Message-ID: On Wed, 23 Apr 2025 10:19:51 GMT, Mikhail Yankelevich wrote: > I could not replicate the issue after more than 64000 runs. However, I have done the following to increase stability and added logs in case this happens again. > > Changes: > * Specifically binding the client to the loopback address > * Added additional debug logging This pull request has now been integrated. Changeset: 6b553acb Author: Mikhail Yankelevich Committer: Rajan Halade URL: https://git.openjdk.org/jdk/commit/6b553acbaace0a61203305f36f70bb74d14a234f Stats: 58 lines in 1 file changed: 0 ins; 0 del; 58 mod 8277424: javax/net/ssl/TLSCommon/TLSTest.java fails with connection refused Reviewed-by: rhalade ------------- PR: https://git.openjdk.org/jdk/pull/24823 From weijun at openjdk.org Thu May 1 16:38:50 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 16:38:50 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v18] In-Reply-To: <9YxbGEH3FSwiE4Inp69buCoObFthqTwhtLCKidTU9sE=.f6f98bfb-274d-4baf-8b34-94cd02739ff5@github.com> References: <9YxbGEH3FSwiE4Inp69buCoObFthqTwhtLCKidTU9sE=.f6f98bfb-274d-4baf-8b34-94cd02739ff5@github.com> Message-ID: On Thu, 1 May 2025 15:15:51 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> engineGetBlockSize and engineGetOutputSize returns 0 when not initialized > > src/java.base/share/classes/javax/crypto/spec/snippet-files/PackageSnippets.java line 60: > >> 58: HPKEParameterSpec pr = HPKEParameterSpec >> 59: .of(actual.kem_id(), actual.kdf_id(), actual.aead_id()) >> 60: .info("app_info".getBytes(StandardCharsets.UTF_8)) > > Question, not necessarily a comment. Why is info also needed for decryption? Isn't it only needed on the encryption side when deriving the key? Both side uses `info` to [create the key schedule](https://github.com/openjdk/jdk/blob/a4f59e388f951d84f8eb28048e3af04a53291806/src/java.base/share/classes/com/sun/crypto/provider/HPKE.java#L463-L466). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2070488856 From weijun at openjdk.org Thu May 1 17:50:57 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 17:50:57 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: On Thu, 1 May 2025 00:25:38 GMT, Anthony Scarpino wrote: >> Yes, this method is private. But you allow `PEMEncoder().of().encode(PEMRecord)`. People might wonder why their leading data is lost. > > Then they can call PEMRecord.leadingData(). They can. Just tell them. >> I meant the newline char at the end (before the "------BEGIN" chars). I just tried out your implementation, and noticed if there is nothing there, then `leadingData` is null; and if there is a line of text, `leadingData` contains the newline char at the end. >> >> I still think this is worth mentioning. Suppose someone wants to rewrite the PEM file with the leading data, they need to know they should not use `println`. >> >> BTW, I prefer trimming that newline char. Just my opinion. > > I see your point now, but `leadingData` is a byte array. If an app wrote the `leadingData` in a `ByteArrayInputStream`, followed by the PEM text, it would not be the same data written as the newline would be gone. Correct? Why would it be gone? It's a 0x10 at the end of the byte array. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2070577038 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2070576217 From duke at openjdk.org Thu May 1 17:29:58 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Thu, 1 May 2025 17:29:58 GMT Subject: Integrated: 8328914: Document the java.security.debug property in javadoc In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 19:16:01 GMT, Koushik Muthukrishnan Thirupattur wrote: > java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc. > > image > > > > NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page. This pull request has now been integrated. Changeset: 394961c8 Author: Koushik Thirupattur Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/394961c8fe87da7376cc7522580cd4ac104c3cf5 Stats: 200 lines in 2 files changed: 199 ins; 0 del; 1 mod 8328914: Document the java.security.debug property in javadoc Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/23569 From myankelevich at openjdk.org Thu May 1 18:08:40 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 1 May 2025 18:08:40 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v3] In-Reply-To: References: Message-ID: > * Changed the test to use scratch directory > * Cleaned up the imports Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: changed file format and throwing an exception in case of the failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24718/files - new: https://git.openjdk.org/jdk/pull/24718/files/44b39103..64d0bd8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24718&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24718&range=01-02 Stats: 12 lines in 1 file changed: 7 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24718.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24718/head:pull/24718 PR: https://git.openjdk.org/jdk/pull/24718 From abarashev at openjdk.org Thu May 1 18:28:47 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 1 May 2025 18:28:47 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 23:38:03 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Moved too fast test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 277: > 275: private static void runExporterTests( > 276: ExtendedSSLSession cessls, > 277: ExtendedSSLSession sessls) throws Exception { Replace with `clientSession` and `serverSession` for readability? test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 296: > 294: // Inputs exactly equal. Use exportKeyMaterialKey() > 295: clientBytes = cessls.exportKeyMaterialKey("hello", > 296: bytes, 128).getEncoded(); Should we add tests with EKM material length other than 128? test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 324: > 322: serverBytes = sessls.exportKeyMaterialData("goodbye", > 323: bytes, 128); > 324: if (Arrays.equals(clientBytes, serverBytes)) { Replace with `assertEquals/assertNotEquals` this and other test cases? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070621428 PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070623132 PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070624936 From duke at openjdk.org Thu May 1 18:15:50 2025 From: duke at openjdk.org (duke) Date: Thu, 1 May 2025 18:15:50 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v3] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 18:08:40 GMT, Mikhail Yankelevich wrote: >> * Changed the test to use scratch directory >> * Cleaned up the imports > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > changed file format and throwing an exception in case of the failure @myankelev Your change (at version 64d0bd8f93e287374c2bbd089765e660f6cb8fc8) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24718#issuecomment-2845397144 From valeriep at openjdk.org Thu May 1 19:51:55 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 1 May 2025 19:51:55 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v6] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 13:51:14 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments from Mark > > test/jdk/sun/security/pkcs11/SecretKeyFactory/TestPBKD.java line 46: > >> 44: * @summary test key derivation on a SunPKCS11 SecretKeyFactory service >> 45: * @library /test/lib .. >> 46: * @modules java.base/com.sun.crypto.provider:open > > This `:open` line is useless now. No more reflection code. Yes, will remove. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2070719568 From myankelevich at openjdk.org Thu May 1 18:08:42 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 1 May 2025 18:08:42 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 15:34:11 GMT, Rajan Halade wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> changed file creation to use Utils.createTempFile > > test/jdk/sun/security/pkcs12/P12SecretKey.java line 88: > >> 86: " keystore"); >> 87: } else { >> 88: System.err.println("ERROR: keys are NOT equal after storing in " > > Test should fail here, throw RuntimeException. Done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24718#discussion_r2070594467 From valeriep at openjdk.org Thu May 1 20:15:29 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 1 May 2025 20:15:29 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v7] In-Reply-To: References: Message-ID: > As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings. > > Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility. Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Address review comments from Weijun. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24068/files - new: https://git.openjdk.org/jdk/pull/24068/files/5c73f744..8217e728 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24068/head:pull/24068 PR: https://git.openjdk.org/jdk/pull/24068 From valeriep at openjdk.org Thu May 1 18:52:51 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 1 May 2025 18:52:51 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v6] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 22:37:54 GMT, Bradford Wetmore wrote: > Missing test plan in the PR Description. (i.e. tier1/tier2/JCK?) I always run tier 1-3 tests for all of my PRs. Don't anticipate that this would affect JCK, but will give it a try just in case. Thanks for the suggestion~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/24393#issuecomment-2845480941 From valeriep at openjdk.org Thu May 1 18:49:33 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 1 May 2025 18:49:33 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v7] In-Reply-To: References: Message-ID: > This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. > > This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. > > Thanks in advance for the review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Address review comments from Sean. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24393/files - new: https://git.openjdk.org/jdk/pull/24393/files/cc7fd3a0..825aa221 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24393&range=05-06 Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24393/head:pull/24393 PR: https://git.openjdk.org/jdk/pull/24393 From wetmore at openjdk.org Thu May 1 19:34:45 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 1 May 2025 19:34:45 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 15:18:43 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved too fast > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1691: > >> 1689: // ...now the final expand. >> 1690: SecretKey key = hkdf.expand(derivedSecret, hkdfInfo, length, >> 1691: "label"); > > Are you using "label" as the algorithm name for the output? Egads...should be the label variable. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070703242 From wetmore at openjdk.org Thu May 1 19:39:45 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 1 May 2025 19:39:45 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 18:24:19 GMT, Artur Barashev wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved too fast > > test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 296: > >> 294: // Inputs exactly equal. Use exportKeyMaterialKey() >> 295: clientBytes = cessls.exportKeyMaterialKey("hello", >> 296: bytes, 128).getEncoded(); > > Should we add tests with EKM material length other than 128? I have a difference test with 127 vs 128, but can add another equal key size for matching. Say 40? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070707740 From wetmore at openjdk.org Thu May 1 20:04:46 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 1 May 2025 20:04:46 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 18:26:03 GMT, Artur Barashev wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved too fast > > test/jdk/javax/net/ssl/ExtendedSSLSession/TLSKeyExporters.java line 324: > >> 322: serverBytes = sessls.exportKeyMaterialData("goodbye", >> 323: bytes, 128); >> 324: if (Arrays.equals(clientBytes, serverBytes)) { > > Replace with `assertEquals/assertNotEquals` this and other test cases? I am used to writing standalone tests (old days before `test/lib`), but this is not a bad idea. I used `assertEqualsByteArray`/`assertNotEqualsByteArray` for `byte[]` and `assertEquals` for `ints`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070734034 From wetmore at openjdk.org Thu May 1 20:18:28 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 1 May 2025 20:18:28 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v4] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Codereview comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/a0332f8e..bdd16052 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=02-03 Stats: 70 lines in 2 files changed: 9 ins; 14 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From weijun at openjdk.org Thu May 1 20:27:49 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 20:27:49 GMT Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings [v7] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 20:15:29 GMT, Valerie Peng wrote: >> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings. >> >> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility. > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments from Weijun. Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24068#pullrequestreview-2810651684 From weijun at openjdk.org Thu May 1 20:30:57 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 20:30:57 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: <9mfjkYfNkAF1AcivrGWStoKBvYU7upfrujgMo5r6muI=.7e655046-04ae-4e76-9598-76b77dfb478f@github.com> References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> <9mfjkYfNkAF1AcivrGWStoKBvYU7upfrujgMo5r6muI=.7e655046-04ae-4e76-9598-76b77dfb478f@github.com> Message-ID: On Wed, 30 Apr 2025 15:50:31 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 157: >> >>> 155: } >>> 156: >>> 157: public byte[] getArrayS() { >> >> Why remove `getArrayS0`? Not worth saving those bytes? > > I just couldn't figure out why it needed to be S0 and not just S. There is no S1 and it uses the existing arrayS. Is there some spec that calls it S0? `getArrayS0` does not clone. It's only safe to use it internally. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2070765384 From mullan at openjdk.org Thu May 1 21:04:48 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 1 May 2025 21:04:48 GMT Subject: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms [v3] In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 14:48:34 GMT, Weijun Wang wrote: >> Add 2 `MessageDigest` algorithms. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > test alias usage Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24576#pullrequestreview-2810724420 From myankelevich at openjdk.org Thu May 1 18:08:41 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 1 May 2025 18:08:41 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v2] In-Reply-To: References: Message-ID: <7MLcXmmZ-UeuFrOyhP94s5aNT_aXW0CjMKyhsH5eTQ0=.ad8e3cfb-1dd5-414a-9c05-fa61f9406212@github.com> On Thu, 1 May 2025 10:31:20 GMT, Mikhail Yankelevich wrote: >> * Changed the test to use scratch directory >> * Cleaned up the imports > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > changed file creation to use Utils.createTempFile Changed the format of the file name ------------- PR Comment: https://git.openjdk.org/jdk/pull/24718#issuecomment-2845381015 From ecaspole at openjdk.org Thu May 1 18:06:45 2025 From: ecaspole at openjdk.org (Eric Caspole) Date: Thu, 1 May 2025 18:06:45 GMT Subject: RFR: 8355559: Benchmark modification/extension shouldn't affect the behavior of other benchmarks [v2] In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 15:25:11 GMT, Sergey Kuksenko wrote: >> Benchmark modification/extension shouldn't affect the behavior of other benchmarks. >> Precisely: [JDK-8344144](https://bugs.openjdk.org/browse/JDK-8344144) modified AESBench in that way, which caused significant changes in the behavior of other benchmarks that extend AESBench. > > Sergey Kuksenko has updated the pull request incrementally with one additional commit since the last revision: > > Update AESExtraBench.java Good. ------------- Marked as reviewed by ecaspole (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24863#pullrequestreview-2810358513 From skuksenko at openjdk.org Thu May 1 18:47:53 2025 From: skuksenko at openjdk.org (Sergey Kuksenko) Date: Thu, 1 May 2025 18:47:53 GMT Subject: Integrated: 8355559: Benchmark modification/extension shouldn't affect the behavior of other benchmarks In-Reply-To: References: Message-ID: On Thu, 24 Apr 2025 23:23:50 GMT, Sergey Kuksenko wrote: > Benchmark modification/extension shouldn't affect the behavior of other benchmarks. > Precisely: [JDK-8344144](https://bugs.openjdk.org/browse/JDK-8344144) modified AESBench in that way, which caused significant changes in the behavior of other benchmarks that extend AESBench. This pull request has now been integrated. Changeset: c116b18b Author: Sergey Kuksenko URL: https://git.openjdk.org/jdk/commit/c116b18b89950362d899448a36a4693f733067b1 Stats: 102 lines in 2 files changed: 78 ins; 21 del; 3 mod 8355559: Benchmark modification/extension shouldn't affect the behavior of other benchmarks Reviewed-by: ecaspole ------------- PR: https://git.openjdk.org/jdk/pull/24863 From weijun at openjdk.org Thu May 1 21:33:47 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 21:33:47 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v3] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 19:32:03 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1691: >> >>> 1689: // ...now the final expand. >>> 1690: SecretKey key = hkdf.expand(derivedSecret, hkdfInfo, length, >>> 1691: "label"); >> >> Are you using "label" as the algorithm name for the output? > > Egads...should be the label variable. Thanks. I don't know whether label is always a legal algorithm name. PKCS #11 is especially picky at new names. The KDF `deriveKey` method contains the algorithm as an argument. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2070833436 From duke at openjdk.org Thu May 1 17:03:54 2025 From: duke at openjdk.org (duke) Date: Thu, 1 May 2025 17:03:54 GMT Subject: RFR: 8328914: Document the java.security.debug property in javadoc [v18] In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 18:02:43 GMT, Koushik Muthukrishnan Thirupattur wrote: >> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc. >> >> image >> >> >> >> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8328914: Document the java.security.debug property in javadoc @koushikthirupattur Your change (at version f53973f74585d799ce03925d8619c29a9533c5ca) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23569#issuecomment-2845254335 From rhalade at openjdk.org Thu May 1 18:15:50 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 1 May 2025 18:15:50 GMT Subject: RFR: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java [v3] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 18:08:40 GMT, Mikhail Yankelevich wrote: >> * Changed the test to use scratch directory >> * Cleaned up the imports > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > changed file format and throwing an exception in case of the failure Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24718#pullrequestreview-2810375894 From valeriep at openjdk.org Thu May 1 23:10:55 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 1 May 2025 23:10:55 GMT Subject: Integrated: 8348732: SunJCE and SunPKCS11 have different PBE key encodings In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 21:58:47 GMT, Valerie Peng wrote: > As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings. > > Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility. This pull request has now been integrated. Changeset: 6536430a Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/6536430a3bdedcf5e0636e0eb27bde5e0d7b40fd Stats: 472 lines in 12 files changed: 38 ins; 240 del; 194 mod 8348732: SunJCE and SunPKCS11 have different PBE key encodings Reviewed-by: weijun, fferrari ------------- PR: https://git.openjdk.org/jdk/pull/24068 From weijun at openjdk.org Thu May 1 23:39:53 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 1 May 2025 23:39:53 GMT Subject: Integrated: 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 15:30:28 GMT, Weijun Wang wrote: > Add 2 `MessageDigest` algorithms. This pull request has now been integrated. Changeset: 494ef6cb Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/494ef6cb8cff7f29a7346364e7620eebcec48d3b Stats: 98 lines in 5 files changed: 93 ins; 0 del; 5 mod 8354305: SHAKE128 and SHAKE256 MessageDigest algorithms Reviewed-by: valeriep, mullan ------------- PR: https://git.openjdk.org/jdk/pull/24576 From weijun at openjdk.org Fri May 2 00:22:16 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 2 May 2025 00:22:16 GMT Subject: RFR: 8356051: Update SignatureUtil.java with the new KnownOIDs Message-ID: Fix the build error. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/24993/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24993&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356051 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24993.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24993/head:pull/24993 PR: https://git.openjdk.org/jdk/pull/24993 From rhalade at openjdk.org Fri May 2 00:27:50 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 2 May 2025 00:27:50 GMT Subject: RFR: 8356051: Update SignatureUtil.java with the new KnownOIDs In-Reply-To: References: Message-ID: <3siwPGh-gfFCaaTisE-WBlcDF_NfUDk5NYulbQqqHIA=.01b09af9-0a53-4e48-901f-dd1aa05e2557@github.com> On Fri, 2 May 2025 00:17:29 GMT, Weijun Wang wrote: > Fix the build error. Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24993#pullrequestreview-2810976171 From weijun at openjdk.org Fri May 2 00:27:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 2 May 2025 00:27:51 GMT Subject: Integrated: 8356051: Update SignatureUtil.java with the new KnownOIDs In-Reply-To: References: Message-ID: On Fri, 2 May 2025 00:17:29 GMT, Weijun Wang wrote: > Fix the build error. This pull request has now been integrated. Changeset: c514f135 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/c514f135ccf08c3be016a32ae8f2c055fb941857 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8356051: Update SignatureUtil.java with the new KnownOIDs Reviewed-by: rhalade ------------- PR: https://git.openjdk.org/jdk/pull/24993 From ascarpino at openjdk.org Fri May 2 06:04:47 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 2 May 2025 06:04:47 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v3] In-Reply-To: References: Message-ID: On Mon, 14 Apr 2025 12:54:31 GMT, Nibedita Jena wrote: >> Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). >> While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. >> >> Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. >> According to RFC 3546, the host_name limit allowed is 255. >> With a sample testcase when the host_name length is > 127, exception is thrown: >> javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 >> javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( >> "throwable" : { >> java.lang.NegativeArraySizeException: -1 >> at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) >> at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) >> >> e.g. >> int l = buf.get(); >> b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 >> >> For TLSv1.3, its not an issue until length > 255. >> >> According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. >> Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. > > Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: > > Updated SSLSessionImpl constructor with Record interface methods The changes look good. When stateless was integrated, I remember seeing a problem with `Record`, but at least from your changes I don't see that problem here. I'm assuming you have tested this change with jdk_security1, 2, 3, and 4? ------------- Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24535#pullrequestreview-2811233087 From ascarpino at openjdk.org Fri May 2 06:09:52 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 2 May 2025 06:09:52 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: References: Message-ID: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> > Hi all, > > I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. > > Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). > > Thanks > > Tony Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: - major code review comments update - Merge branch 'master' into pem - Merge branch 'master' into pem - javadoc updates - code review comments - merge with master - better comment and remove commented out code - Merge branch 'master' into pem - Merge branch 'pem-merge' into pem - merge - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 ------------- Changes: https://git.openjdk.org/jdk/pull/17543/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=14 Stats: 3492 lines in 40 files changed: 3120 ins; 154 del; 218 mod Patch: https://git.openjdk.org/jdk/pull/17543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543 PR: https://git.openjdk.org/jdk/pull/17543 From mullan at openjdk.org Fri May 2 12:56:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 2 May 2025 12:56:50 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 14:50:31 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - merge > - add a positive debug log and update exception message > - enhancing exception messages and debug outputs > - update @since tags as required by JEP 12 > - add enum back > - the change src/java.base/share/classes/javax/crypto/KDF.java line 481: > 479: > 480: // Rethrows the IAPE thrown by an implementation, adding an explanation > 481: // on in which situation it fails. suggest rewording as "for the situation in which it fails." src/java.base/share/classes/javax/crypto/KDF.java line 491: > 489: + "using the supplied derivation " > 490: + "inputs, using the " + source + " " > 491: + theOne.provider().getName() Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071561925 PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071567362 From rriggs at openjdk.org Fri May 2 14:42:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 May 2025 14:42:46 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods In-Reply-To: References: Message-ID: On Thu, 1 May 2025 05:33:29 GMT, Volkan Yazici wrote: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 314: > 312: *

> 313: * WARNING: The caller of this method shall relinquish and transfer the > 314: * ownership of the byte array to the callee, since the later will not Typo: "later" -> "latter". (pre-existing) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2071714828 From mullan at openjdk.org Fri May 2 15:22:00 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 2 May 2025 15:22:00 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: <2x89BP_eUOByQWctCa3_3BSwBw7lbMjA3Zl0ZYSCjDQ=.829fbfff-d28e-452b-af46-bd7c50532712@github.com> On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: > > - major code review comments update > - Merge branch 'master' into pem > - Merge branch 'master' into pem > - javadoc updates > - code review comments > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 src/java.base/share/classes/java/security/spec/EncodedKeySpec.java line 63: > 61: * This constructor extracts the algorithm name from the encoded bytes, > 62: * which may be an OID if no standard algorithm name is defined. If the > 63: * algorithm name cannot be extracted, it is set to null. Hmm, I think this is leaking details about DER encoding into this abstract class which does not make any assumptions about the type of encoding used. Have you considered only parsing the encoding in the `X509EncodedKeySpec` and `PKCS8EncodedKeySpec` subclasses which are DER specific? src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java line 41: > 39: * privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, > 40: * privateKey PrivateKey, > 41: * attributes [0] IMPLICIT Attributes OPTIONAL, IMPLICIT has been removed in RFC 5958. Also to be consistent with 5958, I think you should change `PrivateKeyInfo` to `OneAsymmetricKey` and add an addtional line with `PrivateKeyInfo ::= OneAsymmetricKey`. src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 345: > 343: } else { > 344: throw new InvalidKeySpecException("Only RSAPublicKeySpec " > 345: + "and X509EncodedKeySpec supported for RSA public keys"); Update exception message to `keySpec.getClass().getName() + " not supported."` as you did in `EdDSAKeyFactory`. src/java.base/share/conf/security/java.security line 1557: > 1555: # > 1556: # This property defines default Public-based Encryption algorithm for > 1557: # java.security.PEMEncoder is configured for encryption with `withEncryption()`. Suggested rewording: This property defines the default password-based encryption algorithm for java.security.PEMEncoder when configured for encryption with the withEncryption method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2071707250 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2071753380 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2071746127 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2071660229 From liach at openjdk.org Fri May 2 15:49:52 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 15:49:52 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 14:50:31 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - merge > - add a positive debug log and update exception message > - enhancing exception messages and debug outputs > - update @since tags as required by JEP 12 > - add enum back > - the change The changes to finalize this preview feature look good. I did not review the extra security-specific changes in KDF.java and KDFDelayedProviderException.java. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2812347049 From duke at openjdk.org Fri May 2 17:30:58 2025 From: duke at openjdk.org (Johannes Graham) Date: Fri, 2 May 2025 17:30:58 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: <7xRghGPDJJfAL9SN13lILnPY_pZQE375vsxIJjMKt7U=.1a624bdd-93e3-4876-a8f3-3485a3437bcd@github.com> References: <6khizncuzjbXtuD0HkQrFfh3j6KpRfHHPb504b7A1v8=.8b4c2296-d00a-4a2e-85b7-1f2fab76142a@github.com> <7xRghGPDJJfAL9SN13lILnPY_pZQE375vsxIJjMKt7U=.1a624bdd-93e3-4876-a8f3-3485a3437bcd@github.com> Message-ID: On Sat, 8 Feb 2025 09:26:29 GMT, Shaojin Wen wrote: >>> The reproducer you provided doesn't try to load KnownOIDs on my machine. What am I missing? >>> >>> Other than that, the change looks reasonable to me. >> >> Me neither and I'm using linux. Are you sure the Startup.java is right? >> Just curious, do you have a percentage on how much performance difference you observe with this? How about differences in memory usage, is there any? > >> > The reproducer you provided doesn't try to load KnownOIDs on my machine. What am I missing? >> > Other than that, the change looks reasonable to me. >> >> Me neither and I'm using linux. Are you sure the Startup.java is right? Just curious, do you have a percentage on how much performance difference you observe with this? How about differences in memory usage, is there any? > > You are right. Class KnownOIDs are loaded during startup because it is started in IntelliJ IDE and there is an agent. > > > git/jdk/build/macosx-aarch64-server-fastdebug/images/jdk/bin/java -verbose:class -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=58735:/Applications/IntelliJ IDEA.app/Contents/bin > > > Therefore, this is not a problem with the default JVM startup parameters, but a problem with the Agent scenario. @wenshao Are you interested in re-opening this ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23411#issuecomment-2847738889 From mullan at openjdk.org Fri May 2 17:56:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 2 May 2025 17:56:57 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> <9mfjkYfNkAF1AcivrGWStoKBvYU7upfrujgMo5r6muI=.7e655046-04ae-4e76-9598-76b77dfb478f@github.com> Message-ID: On Thu, 1 May 2025 20:28:32 GMT, Weijun Wang wrote: >> I just couldn't figure out why it needed to be S0 and not just S. There is no S1 and it uses the existing arrayS. Is there some spec that calls it S0? > > `getArrayS0` does not clone. It's only safe to use it internally. It was previously called by `calculatePublicKey` - I think those bytes are never exposed externally, so safe to not clone. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2071956000 From mullan at openjdk.org Fri May 2 17:57:02 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 2 May 2025 17:57:02 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: > > - major code review comments update > - Merge branch 'master' into pem > - Merge branch 'master' into pem > - javadoc updates > - code review comments > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line 362: > 360: * @throws InvalidKeyException on decoding failure > 361: */ > 362: nit: remove blank line src/java.base/share/classes/sun/security/x509/X509Key.java line 354: > 352: } catch (NoSuchAlgorithmException | InvalidKeySpecException e) { > 353: // Ignore and return raw key > 354: throw new IOException("error with encoding"); How about also including the cause? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2071878794 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2071885225 From weijun at openjdk.org Fri May 2 18:31:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 2 May 2025 18:31:52 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 12:50:41 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - merge >> - add a positive debug log and update exception message >> - enhancing exception messages and debug outputs >> - update @since tags as required by JEP 12 >> - add enum back >> - the change > > src/java.base/share/classes/javax/crypto/KDF.java line 491: > >> 489: + "using the supplied derivation " >> 490: + "inputs, using the " + source + " " >> 491: + theOne.provider().getName() > > Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider." The exception message following uses `"The " + source + " provider " + theOne.provider.getName()`. Shall I also switch to `"The " + source + " " + theOne.provider.getName() + " provider"`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071997676 From mullan at openjdk.org Fri May 2 18:39:47 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 2 May 2025 18:39:47 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:29:14 GMT, Weijun Wang wrote: >> src/java.base/share/classes/javax/crypto/KDF.java line 491: >> >>> 489: + "using the supplied derivation " >>> 490: + "inputs, using the " + source + " " >>> 491: + theOne.provider().getName() >> >> Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider." > > The exception message following uses `"The " + source + " provider " + theOne.provider.getName()`. Shall I also switch to `"The " + source + " " + theOne.provider.getName() + " provider"`? Yes, good to make it consistent. I think it reads slightly better if the name of the provider comes before "provider". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2072005947 From weijun at openjdk.org Fri May 2 18:49:34 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 2 May 2025 18:49:34 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6] In-Reply-To: References: Message-ID: > Finalize the KDF API. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: fine tuning debug log and exception message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24520/files - new: https://git.openjdk.org/jdk/pull/24520/files/323b046b..f44dc9bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=04-05 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24520.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520 PR: https://git.openjdk.org/jdk/pull/24520 From myankelevich at openjdk.org Fri May 2 23:17:50 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 2 May 2025 23:17:50 GMT Subject: Integrated: 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 09:51:40 GMT, Mikhail Yankelevich wrote: > * Changed the test to use scratch directory > * Cleaned up the imports This pull request has now been integrated. Changeset: 03f0ec4a Author: Mikhail Yankelevich Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/03f0ec4a35855b59c8faaf4be2e7569a12b4d5db Stats: 33 lines in 1 file changed: 9 ins; 6 del; 18 mod 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java Reviewed-by: rhalade, weijun ------------- PR: https://git.openjdk.org/jdk/pull/24718 From djelinski at openjdk.org Mon May 5 08:52:50 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 5 May 2025 08:52:50 GMT Subject: RFR: 8272875: Change the default key manager to PKIX [v3] In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 21:51:00 GMT, Artur Barashev wrote: >> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust. >> >> Compatibility considerations: >> >> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file. >> >> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake: >> >> **SUNX509** >> Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units >> SSLHandshake.doHandshake true TLSv1.2 thrpt 15 19758.012 ? 758.237 ops/s >> SSLHandshake.doHandshake true TLS thrpt 15 1861.695 ? 14.681 ops/s >> SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **1186.962** ? 12.085 ops/s >> SSLHandshake.doHandshake false TLS thrpt 15 **1056.288** ? 7.197 ops/s >> Finished running test 'micro:java.security.SSLHandshake' >> >> **PKIX** >> Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units >> SSLHandshake.doHandshake true TLSv1.2 thrpt 15 19724.887 ? 393.636 ops/s >> SSLHandshake.doHandshake true TLS thrpt 15 1848.927 ? 22.946 ops/s >> SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **511.684** ? 5.405 ops/s >> SSLHandshake.doHandshake false TLS thrpt 15 **490.698** ? 6.453 ops/s >> Finished running test 'micro:java.security.SSLHandshake' > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Well, technically the current 1ms takes into account both the client side and the server side of the handshake. Last time I checked, they were more or less evenly split. The 1ms slowdown will happen entirely on the server side, so it's more of a 3x slowdown. Most of the time an extra millisecond doesn't matter, but it can be a factor in the server startup time on a busy server. We currently invalidate all session resumption tickets during server restart. Re your point 3: what's the observable difference? If the certificate we can offer doesn't meet the peer's expectations, will we fail the handshake on the server side instead of failing on the client side, or is it something else? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2850325489 From mullan at openjdk.org Mon May 5 13:40:03 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 5 May 2025 13:40:03 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: <3b0GceQv3oN1AhtY8RT5YRve_5tfw5GHGV0uWywRFB0=.30147e51-e3c7-4bf8-b23d-f4dbe4fb980b@github.com> On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: > > - major code review comments update > - Merge branch 'master' into pem > - Merge branch 'master' into pem > - javadoc updates > - code review comments > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 src/java.base/share/classes/java/security/PEMRecord.java line 46: > 44: *

{@code PEMRecord} may have a null {@code type} and {@code pem} when > 45: * {@code PEMDecoder.decode()} methods encounter only non-PEM data and has > 46: * reached the end of the stream. If there is PEM data, {@code type} and Is this use case important? It seems unusual to call this a DEREncodable if it only contains non-PEM data. I think it might be better to simply ignore trailing non-PEM data at the end of a stream which is not attached to any subsequent PEM objects. src/java.base/share/classes/java/security/PEMRecord.java line 53: > 51: * {@code type} or {@code pem}. > 52: * > 53: * @param type The type identifier in the PEM header. For a public key, parameter descriptions should not start with a capital letter. Same comment for the params in the ctors. src/java.base/share/classes/java/security/PEMRecord.java line 67: > 65: > 66: /** > 67: * Return a PEMRecord instance with the given parameters. s/Return/Creates/ (same comment for all ctors) PEMRecord should be in code font. src/java.base/share/classes/java/security/PEMRecord.java line 71: > 69: *

When {@code type} is given a properly formatted PEM header, only the > 70: * identifier will be set (ie: {@code PUBLIC KEY}). Otherwise, {@code type} > 71: * will be set to what was passed in. Put PUBLIC KEY in double quotes so it is clear this is a String. I'm not sure I understand this paragraph - will the dashes be included if the type is not understood? If not, why do we need this paragraph at all? src/java.base/share/classes/java/security/PEMRecord.java line 75: > 73: *

When {@code type} is given a correctly formatted PEM header, only the > 74: * identifier is set (for example, {@code PUBLIC KEY}). Otherwise, > 75: * {@code type} is set to the value that was passed in. Duplicate paragaraph as first. src/java.base/share/classes/java/security/PEMRecord.java line 78: > 76: * > 77: * @param type The type identifier in the PEM header and footer. > 78: * If there is no PEM data, this value will be {@code null}. Suggest rewording as "the type identifier in the PEM header and footer, or {@code null} if there is no PEM data." Same comment for other ctors. src/java.base/share/classes/java/security/PEMRecord.java line 137: > 135: /** > 136: * Returns the binary encoding from the Base64 data contained in > 137: * {@code pem}. Should say that it returns a new copy each time it is called. src/java.base/share/classes/java/security/PEMRecord.java line 139: > 137: * {@code pem}. > 138: * > 139: * @throws IllegalArgumentException if {@code pem} could not be decoded. s/could not/cannot/ src/java.base/share/classes/java/security/PEMRecord.java line 140: > 138: * > 139: * @throws IllegalArgumentException if {@code pem} could not be decoded. > 140: * @return binary encoding or null if {@code pem} is null. s/binary/the binary/ src/java.base/share/classes/sun/security/ec/ECKeyFactory.java line 245: > 243: throw new InvalidKeySpecException("Only ECPrivateKeySpec " + > 244: "and PKCS8EncodedKeySpec supported for EC private keys. " + > 245: keySpec.getClass().getName() + " provided."); How about using the message "keySpec.getClass().getName() + " not supported." as on lines 223-224? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073424234 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073377746 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073380371 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073456846 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073441921 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073442784 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073386293 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073388519 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073387689 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2071975085 From abarashev at openjdk.org Mon May 5 13:42:50 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 5 May 2025 13:42:50 GMT Subject: RFR: 8272875: Change the default key manager to PKIX [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 08:50:07 GMT, Daniel Jeli?ski wrote: > Well, technically the current 1ms takes into account both the client side and the server side of the handshake. Last time I checked, they were more or less evenly split. The 1ms slowdown will happen entirely on the server side, so it's more of a 3x slowdown. Yes, good point, thanks! > > Most of the time an extra millisecond doesn't matter, but it can be a factor in the server startup time on a busy server. We currently invalidate all session resumption tickets during server restart. I see. But at the same time my understanding is that PKIX KeyManager's boot-up should be faster because it doesn't cache the whole KeyStore. > > Re your point 3: what's the observable difference? If the certificate we can offer doesn't meet the peer's expectations, will we fail the handshake on the server side instead of failing on the client side, or is it something else? Yes, we fail on the server side if we can't offer a certificate passing peer-supported algorithms in "signature_algorithms_cert" extension. I put together a prototype of yet another KeyManager which can be a compromise solution: it's basically a `SunX509` with algorithm constraints: #25016 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24756#issuecomment-2851050257 From mullan at openjdk.org Mon May 5 15:14:07 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 5 May 2025 15:14:07 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: > > - major code review comments update > - Merge branch 'master' into pem > - Merge branch 'master' into pem > - javadoc updates > - code review comments > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 src/java.base/share/classes/java/security/PEMEncoder.java line 57: > 55: * that implement {@link DEREncodable} and support > 56: * {@linkplain PKCS8EncodedKeySpec PKCS#8} or > 57: * {@linkplain X509EncodedKeySpec X509} formats. The "and" in "and support {@linkplain PKCS8EncodedKeySpec PKCS#8} or {@linkplain X509EncodedKeySpec X509} formats" is too strong, ex - X509Certificate & X509CRL do not support those keyspecs. I would suggest deleting this part about "and support" as it is doesn't seem necessary. src/java.base/share/classes/java/security/PEMEncoder.java line 64: > 62: * > 63: *

PKCS8 2.0 allows OneAsymmetricKey encoding, which may contain both private > 64: * and public keys in the same PEM.This is supported by using the Add space before "This". src/java.base/share/classes/java/security/PEMEncoder.java line 118: > 116: > 117: /** > 118: * Returns a new instance of PEMEncoder. put code around PEMEncoder. src/java.base/share/classes/java/security/PEMEncoder.java line 118: > 116: > 117: /** > 118: * Returns a new instance of PEMEncoder. This could be interpreted as a new instance is returned every time. Suggest removing the word "new". src/java.base/share/classes/java/security/PEMEncoder.java line 120: > 118: * Returns a new instance of PEMEncoder. > 119: * > 120: * @return PEMEncoder instance s/PEMEncoder/a PEMEncoder/ Use code font for PEMEncoder, also in method description. src/java.base/share/classes/java/security/PEMEncoder.java line 122: > 120: * @return PEMEncoder instance > 121: */ > 122: static public PEMEncoder of() { "public" should be before "static". src/java.base/share/classes/java/security/PEMEncoder.java line 133: > 131: * {@code DEREncodable}. > 132: * @return PEM encoding in a String > 133: * @throws IllegalArgumentException when the passed object returns a null When would a DEREncodable return a null encoding? I think it should never return this under normal circumstances. I think we should not specifically mention this case, and be more general like "if the object cannot be encoded for some reason". src/java.base/share/classes/java/security/PEMEncoder.java line 199: > 197: > 198: /** > 199: * Encodes a given {@code DEREncodable} into PEM. Suggest: s/a given/the specified/ src/java.base/share/classes/java/security/PEMEncoder.java line 207: > 205: * configured for encryption while encoding a {@code DEREncodable} that does > 206: * not support encryption. > 207: * @throws NullPointerException when object passed is null. Wording suggestion: "if {@code de} is {@code null}" src/java.base/share/classes/java/security/PEMEncoder.java line 215: > 213: > 214: /** > 215: * Returns a new immutable PEMEncoder instance configured to the default I don't think you need to say "immutable" as the first sentence of the class description already says PEMEncoder objects are immutable. s/configured to/configured with/ src/java.base/share/classes/java/security/PEMEncoder.java line 216: > 214: /** > 215: * Returns a new immutable PEMEncoder instance configured to the default > 216: * encryption algorithm and a given password. s/a given/the specified/ src/java.base/share/classes/java/security/PEMEncoder.java line 218: > 216: * encryption algorithm and a given password. > 217: * > 218: *

Only {@link PrivateKey} will be encrypted with this newly configured s/will/objects will/ Also suggest saying "can be" instead of "will be". src/java.base/share/classes/java/security/PEMEncoder.java line 220: > 218: *

Only {@link PrivateKey} will be encrypted with this newly configured > 219: * instance. Other {@link DEREncodable} classes that do not support > 220: * encrypted PEM will cause encode() to throw an IllegalArgumentException. This sentence sounds like it is possible for classes other than PrivateKey to support encrypted PEM. Is that true? If not, I would be more specific and just say objects other than PrivateKey. Put code font around IllegalArgumentException. src/java.base/share/classes/java/security/PEMEncoder.java line 222: > 220: * encrypted PEM will cause encode() to throw an IllegalArgumentException. > 221: * > 222: * @implNote Default algorithm defined by Security Property {@code First sentence is incomplete. src/java.base/share/classes/java/security/PEMEncoder.java line 229: > 227: * > 228: * @param password sets the encryption password. The array is cloned and > 229: * stored in the new instance. {@code null} is a valid entry. s/entry/value/ src/java.base/share/classes/java/security/PEMEncoder.java line 230: > 228: * @param password sets the encryption password. The array is cloned and > 229: * stored in the new instance. {@code null} is a valid entry. > 230: * @return a new PEMEncoder Put code around PEMEncoder. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073567927 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073570896 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073574066 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073639928 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073579896 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073574516 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073625588 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073620495 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073620596 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073583887 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073585281 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073587422 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073597828 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073598651 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073604425 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073605917 From weijun at openjdk.org Mon May 5 15:14:08 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 May 2025 15:14:08 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: > > - major code review comments update > - Merge branch 'master' into pem > - Merge branch 'master' into pem > - javadoc updates > - code review comments > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 src/java.base/share/classes/java/security/PEMEncoder.java line 141: > 139: */ > 140: public String encodeToString(DEREncodable de) { > 141: Objects.requireNonNull(de); Do you need to check if `getFormat` of the key is "PKCS#8" or "X.509" before passing the encoding to `buildKey`? For example, we actually allows RSA key having "PKCS#1" format ML-KEM/ML-DSA allows keys in "RAW" format. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073636749 From mullan at openjdk.org Mon May 5 15:31:57 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 5 May 2025 15:31:57 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v12] In-Reply-To: <_1S31GZs4ShW0QTVMadton7NC0v6FW4X60bfv3770EM=.9f73f136-f955-4028-8c9c-70d2071a7852@github.com> References: <_1S31GZs4ShW0QTVMadton7NC0v6FW4X60bfv3770EM=.9f73f136-f955-4028-8c9c-70d2071a7852@github.com> Message-ID: On Thu, 17 Apr 2025 21:39:31 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/java/security/PEMDecoder.java line 377: >> >>> 375: * {@code provider} will occur during decoding. >>> 376: * >>> 377: *

If {@code params} is {@code null}, a new instance is returned with >> >> There is no variable named `params` - do you mean `provider`? Also, why not throw an NPE and not allow a `null` provider, since it would be the same as calling `of()`? > > It was meant to be `provider`. > I didn't think checking for null and throwing an exception is necessary when it is the default operation. This shows up when coding with a provider variable with unknown value. In this case, the app doesn't have to check if `provider == null` so that it can call `of()`. Unfortunately this situation is common with `getInstance()` which result in a lot of if-else statements. I think that case is arguably an issue that the caller should know about, by throwing an exception. If the caller has some code where it thinks it is trying to use a provider, and the API is not doing what the caller thinks it should, then I think this API here should throw an exception. The caller can easily work around this, by calling `of()` when provider is null. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2073671278 From valeriep at openjdk.org Mon May 5 20:07:52 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 5 May 2025 20:07:52 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fine tuning debug log and exception message test/jdk/com/sun/crypto/provider/KDF/HKDFSaltIKMTest.java line 26: > 24: /* > 25: * @test > 26: * @bug 8331008 Should we add 8353888 to all the tests? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2074112296 From weijun at openjdk.org Mon May 5 21:03:48 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 May 2025 21:03:48 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 20:04:46 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fine tuning debug log and exception message > > test/jdk/com/sun/crypto/provider/KDF/HKDFSaltIKMTest.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 8331008 > > Should we add 8353888 to all the tests? The Virtual Threads JEP didn't. https://github.com/openjdk/jdk/commit/2586f36120317cd206464b1e79d3906f711487cb#diff-35150e3bfd3304405ec403aa29cbea7aaa05c7bab3e28ac92e8162683114746a. I assume we don't either. Bug ids should match changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2074195043 From valeriep at openjdk.org Mon May 5 23:10:21 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 5 May 2025 23:10:21 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fine tuning debug log and exception message Looks good. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2816353093 From wetmore at openjdk.org Tue May 6 05:14:16 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 6 May 2025 05:14:16 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v7] In-Reply-To: References: Message-ID: <_HccQ4L2NE5PBsBoRUrw1bsPJQgoGGS0LlcICS1jArM=.4546df85-abb5-48be-8657-3502b1842744@github.com> On Thu, 1 May 2025 18:49:33 GMT, Valerie Peng wrote: >> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. >> >> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. >> >> Thanks in advance for the review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments from Sean. Just a few comments to think about, and one copyright nit. src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 409: > 407: HKDFParameterSpec spec = > 408: HKDFParameterSpec.ofExtract().addIKM(s).extractOnly(); > 409: return hkdf.deriveKey("Generic", spec); I haven't done much with DHKEM yet, but should the returned key have algorithm name of "Generic," or something more descriptive like the previous "HKDF-PRK"? src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 1: > 1: /* Copyright update. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 1222: > 1220: CipherSuite.HashAlg hashAlg = hc.negotiatedCipherSuite.hashAlg; > 1221: KDF hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm); > 1222: SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret", I'm a little worried that the proper number of salt zeros are now expected to be known in the KDF deriveKey code instead of specified specifically here (and in other similar places). Should we consider specifying them here and the other places instead to play it safe? ------------- PR Review: https://git.openjdk.org/jdk/pull/24393#pullrequestreview-2816859138 PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2074723921 PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2074724316 PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2074735247 From myankelevich at openjdk.org Tue May 6 10:32:20 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 6 May 2025 10:32:20 GMT Subject: RFR: 8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 15:54:47 GMT, Mikhail Yankelevich wrote: >> * fully automated the test >> * removed the race condition >> * client on a thread and server on a thread options are now run together automatically > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > minor comment changes Still needs a security libraries approval ------------- PR Comment: https://git.openjdk.org/jdk/pull/23469#issuecomment-2854061886 From weijun at openjdk.org Tue May 6 15:03:21 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 6 May 2025 15:03:21 GMT Subject: RFR: 8347606: Optimize Java implementation of ML-DSA In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:43:32 GMT, Ben Perez wrote: > It turns out that initializing a multidimensional array with `int[][] a = new int[rows][cols]` is slower than allocating each column in a loop. Since we do a lot of large multidimensional array allocations in ML-DSA, the optimized initialization improves performance by roughly 10%. Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23642#pullrequestreview-2818621296 From duke at openjdk.org Tue May 6 17:01:35 2025 From: duke at openjdk.org (duke) Date: Tue, 6 May 2025 17:01:35 GMT Subject: RFR: 8353001: Remove leftover Security Manager parsing code in sun.security.util.Debug [v3] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 15:19:10 GMT, Koushik Muthukrishnan Thirupattur wrote: >> The private marshal() method in sun.security.util.Debug still contains code to parse "permission=" and "codebase=" options. These sub-options were part of the "access" option which was removed in JDK 24 as part of JEP 486, so this code can be removed. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8353001:Remove leftover Security Manager parsing code in sun.security.util.Debug @koushikthirupattur Your change (at version 4b28c48c69a4bf6b2912b5014655ff79160d3688) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24731#issuecomment-2855297943 From mullan at openjdk.org Tue May 6 18:11:36 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 6 May 2025 18:11:36 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: > > - major code review comments update > - Merge branch 'master' into pem > - Merge branch 'master' into pem > - javadoc updates > - code review comments > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 79: > 77: > 78: /* PKCS8 version of the PEM */ > 79: protected int version; Do these need to be protected? It doesn't seem like any subclasses need them. src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 193: > 191: * > 192: * @param encoded the DER-encoded SubjectPublicKeyInfo value > 193: * @exception IOException on data format errors Change to `InvalidKeyException`. src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 243: > 241: } > 242: > 243: public byte[] getPrivKeyMaterial() { Do we really need this method, esp since it is the private key? I can't find any code that calls this. src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 305: > 303: } catch (IOException e) { > 304: // encodedKey is still null > 305: throw new SecurityException(e); Should return null instead since that is what `getEncoded()` specifies. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2075978714 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2075985424 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2075990253 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2075998393 From duke at openjdk.org Tue May 6 18:13:20 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 6 May 2025 18:13:20 GMT Subject: Integrated: 8353001: Remove leftover Security Manager parsing code in sun.security.util.Debug In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 17:32:03 GMT, Koushik Muthukrishnan Thirupattur wrote: > The private marshal() method in sun.security.util.Debug still contains code to parse "permission=" and "codebase=" options. These sub-options were part of the "access" option which was removed in JDK 24 as part of JEP 486, so this code can be removed. This pull request has now been integrated. Changeset: 5d17a28c Author: Koushik Thirupattur Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/5d17a28c4edc097162cb078ebb72ad84d925fff4 Stats: 125 lines in 2 files changed: 0 ins; 124 del; 1 mod 8353001: Remove leftover Security Manager parsing code in sun.security.util.Debug Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/24731 From bperez at openjdk.org Tue May 6 20:19:31 2025 From: bperez at openjdk.org (Ben Perez) Date: Tue, 6 May 2025 20:19:31 GMT Subject: RFR: 8347606: Optimize Java implementation of ML-DSA [v2] In-Reply-To: References: Message-ID: > It turns out that initializing a multidimensional array with `int[][] a = new int[rows][cols]` is slower than allocating each column in a loop. Since we do a lot of large multidimensional array allocations in ML-DSA, the optimized initialization improves performance by roughly 10%. Ben Perez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into JDK-8347606 - Changed copyright, removed unnecessary comment - Added optimized boolean matrix allocs - Created optimized matrixAllocate method for 2d arrays ------------- Changes: https://git.openjdk.org/jdk/pull/23642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23642&range=01 Stats: 54 lines in 1 file changed: 23 ins; 1 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/23642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23642/head:pull/23642 PR: https://git.openjdk.org/jdk/pull/23642 From weijun at openjdk.org Tue May 6 21:29:29 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 6 May 2025 21:29:29 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: > > - major code review comments update > - Merge branch 'master' into pem > - Merge branch 'master' into pem > - javadoc updates > - code review comments > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 Comments on the `PEMEncoder` API. src/java.base/share/classes/java/security/PEMEncoder.java line 48: > 46: /** > 47: * PEMEncoder is an immutable class for Privacy-Enhanced Mail (PEM) > 48: * data. PEM is a textual encoding used to store and transfer security "An immutable class .. for ... data" sounds like it is the data itself. What about "for encoding data into...". The first word `PEMEncoder` should be in ``. src/java.base/share/classes/java/security/PEMEncoder.java line 54: > 52: * and footer. > 53: * > 54: *

Encoding may be performed on Java Cryptographic Extension (JCE) objects Is "JCE objects" a formal term? We used to say "JCA and JCE". How do we call them now? src/java.base/share/classes/java/security/PEMEncoder.java line 59: > 57: * {@linkplain X509EncodedKeySpec X509} formats. > 58: * > 59: *

Encrypted private key PEM data can be built by calling the encode methods I understand "encode methods" here mean `encode` and `encodeToString`, but at this early place in the specification no one knows about those methods yet. Does it make sense to append several sentences at the end of the previous paragraph saying something similar to "call encode to encode, call encodeToString to encode to string". src/java.base/share/classes/java/security/PEMEncoder.java line 63: > 61: * by passing an {@link EncryptedPrivateKeyInfo} object into the encode methods. > 62: * > 63: *

PKCS8 2.0 allows OneAsymmetricKey encoding, which may contain both private It's "PKCS #8". Enclose `OneAsymmetricKey` in ``. src/java.base/share/classes/java/security/PEMEncoder.java line 70: > 68: * {@linkplain PEMRecord#pem()} with a generated the PEM header and footer > 69: * from {@linkplain PEMRecord#type()}. It will not check the validity of > 70: * the data. Since you mention `PEMRecord` specifically, I'd see the clarification that the `leadingData` there will not be encoded. Otherwise, you cannot guarantee on the encoding. src/java.base/share/classes/java/security/PEMEncoder.java line 75: > 73: * {@link java.nio.charset.StandardCharsets#ISO_8859_1 ISO-8859-1}. > 74: * > 75: * @apiNote Why is this an `apiNote`. Can't we put an example directly into the spec. Also, please add an example on encrypting a private key. src/java.base/share/classes/java/security/PEMEncoder.java line 83: > 81: * > 82: * @see PKCS8EncodedKeySpec > 83: * @see X509EncodedKeySpec I cannot see how these 2 deserve this place. I'd rather link to `PEMRecord` and `PEMDecoder`. src/java.base/share/classes/java/security/PEMEncoder.java line 88: > 86: * RFC 1421: Privacy Enhancement for Internet Electronic Mail > 87: * @spec https://www.rfc-editor.org/info/rfc7468 > 88: * RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures You mentioned PKCS #8 2.0. Is it worth adding it here? src/java.base/share/classes/java/security/PEMEncoder.java line 127: > 125: > 126: /** > 127: * Encoded a given {@code DEREncodable} and return the PEM encoding in a Typo: `Encodes`. src/java.base/share/classes/java/security/PEMEncoder.java line 128: > 126: /** > 127: * Encoded a given {@code DEREncodable} and return the PEM encoding in a > 128: * String Either `String` or `string`. src/java.base/share/classes/java/security/PEMEncoder.java line 130: > 128: * String > 129: * > 130: * @param de a cryptographic object to be PEM encoded that implements `@param de` for the 2 methods should be the same. ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2819604929 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076258346 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076262106 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076267314 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076270426 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076273132 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076281319 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076282886 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076284962 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076288529 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076291290 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076299229 From weijun at openjdk.org Tue May 6 21:29:30 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 6 May 2025 21:29:30 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: On Thu, 24 Apr 2025 20:12:50 GMT, Mark Reinhold wrote: >> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: >> >> - javadoc updates >> - code review comments > > src/java.base/share/classes/java/security/PEMEncoder.java line 74: > >> 72: * >> 73: *

{@code String} values returned by this class use character set >> 74: * {@link java.nio.charset.StandardCharsets#ISO_8859_1 ISO-8859-1}. > > As above, did you mean to write something like, "Byte arrays returned by methods in this class represent characters encoded using the ISO-8859-1 charset" ? Yes, only `byte[]` has an encoding. BTW, please be specific this is about the `encode` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076276493 From weijun at openjdk.org Tue May 6 21:29:32 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 6 May 2025 21:29:32 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: On Mon, 5 May 2025 14:41:01 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: >> >> - major code review comments update >> - Merge branch 'master' into pem >> - Merge branch 'master' into pem >> - javadoc updates >> - code review comments >> - merge with master >> - better comment and remove commented out code >> - Merge branch 'master' into pem >> - Merge branch 'pem-merge' into pem >> - merge >> - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 > > src/java.base/share/classes/java/security/PEMEncoder.java line 218: > >> 216: * encryption algorithm and a given password. >> 217: * >> 218: *

Only {@link PrivateKey} will be encrypted with this newly configured > > s/will/objects will/ > > Also suggest saying "can be" instead of "will be". Shall we say "be encrypted" or "be encoded"? > src/java.base/share/classes/java/security/PEMEncoder.java line 220: > >> 218: *

Only {@link PrivateKey} will be encrypted with this newly configured >> 219: * instance. Other {@link DEREncodable} classes that do not support >> 220: * encrypted PEM will cause encode() to throw an IllegalArgumentException. > > This sentence sounds like it is possible for classes other than PrivateKey to support encrypted PEM. Is that true? If not, I would be more specific and just say objects other than PrivateKey. > > Put code font around IllegalArgumentException. Since this covers `encodeToString` as well I suggest rewriting to "Encoding other ... will throw ...". > src/java.base/share/classes/java/security/PEMEncoder.java line 222: > >> 220: * encrypted PEM will cause encode() to throw an IllegalArgumentException. >> 221: * >> 222: * @implNote Default algorithm defined by Security Property {@code > > First sentence is incomplete. You might want to be more clear that this implementation uses the PBE cipher algorithm using default parameters from the most preferred provider. Otherwise, users might be clueless about what encryption options they can configure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076308529 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076310733 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2076314921 From duke at openjdk.org Wed May 7 03:50:51 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Wed, 7 May 2025 03:50:51 GMT Subject: RFR: 8310003: Improve logging when default truststore is inaccessible Message-ID: If the truststore is unavailable, JDK does not log information for 'trustStore provider is:'. We are now adding 'unspecified' instead of keeping empty. ------------- Commit messages: - 8310003: Improve logging when default truststore is inaccessible Changes: https://git.openjdk.org/jdk/pull/25077/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25077&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310003 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25077.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25077/head:pull/25077 PR: https://git.openjdk.org/jdk/pull/25077 From wetmore at openjdk.org Wed May 7 04:25:05 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 7 May 2025 04:25:05 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v5] In-Reply-To: References: Message-ID: <4w6IRPy7N721Ygbl6G52VIhCLavhmiCeNnPrIQ8nODE=.6cd04cf5-eacf-43ee-b9be-f334b45f6fb9@github.com> > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - More codereview/CSR comments - Merge branch 'master' into JDK-8341346 - Codereview comments. - Moved too fast - Tweak API to be more KDF like in unextractable case. - 8341346: Add support for exporting TLS Keying Material ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/bdd16052..64d46d9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=03-04 Stats: 10841 lines in 390 files changed: 7457 ins; 2245 del; 1139 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From wetmore at openjdk.org Wed May 7 04:30:16 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 7 May 2025 04:30:16 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v7] In-Reply-To: <_HccQ4L2NE5PBsBoRUrw1bsPJQgoGGS0LlcICS1jArM=.4546df85-abb5-48be-8657-3502b1842744@github.com> References: <_HccQ4L2NE5PBsBoRUrw1bsPJQgoGGS0LlcICS1jArM=.4546df85-abb5-48be-8657-3502b1842744@github.com> Message-ID: On Tue, 6 May 2025 04:58:41 GMT, Bradford Wetmore wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments from Sean. > > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 1222: > >> 1220: CipherSuite.HashAlg hashAlg = hc.negotiatedCipherSuite.hashAlg; >> 1221: KDF hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm); >> 1222: SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret", > > I'm a little worried that the proper number of salt zeros are now expected to be known in the KDF deriveKey code instead of specified specifically here (and in other similar places). Should we consider specifying them here and the other places instead to play it safe? I just found that we had talked about this previously. What was your reasoning for pulling it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2076762302 From wetmore at openjdk.org Wed May 7 05:03:15 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 7 May 2025 05:03:15 GMT Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v4] In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 18:23:14 GMT, Valerie Peng wrote: >> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 260: >> >>> 258: if (eae_prk instanceof SecretKeySpec s) { >>> 259: SharedSecrets.getJavaxCryptoSpecAccess() >>> 260: .clearSecretKeySpec(s); >> >> I wish we could use `s.destroy()` here instead. > > Yes, it'd be nice. I reopened https://bugs.openjdk.org/browse/JDK-8160206 and we can address this separately. Or in the meantime: } finally { // Best effort if (eae_prk instanceof SecretKeySpec) { SharedSecrets.getJavaxCryptoSpecAccess() .clearSecretKeySpec(eae_prk); } else { try { eae_prk.destroy(); } catch (DestroyFailedException e) { // swallow } } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2076790901 From wetmore at openjdk.org Wed May 7 05:08:00 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 7 May 2025 05:08:00 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v6] In-Reply-To: References: Message-ID: <-Lq3gSKL61DrTHJMeowgZ-a_sDof776MuXk63TvswC8=.fcea32f2-002e-4390-9a97-b3e299837a79@github.com> > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Add in the SharedSecrets SecretKeySpec clearing mechanism ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/64d46d9a..92f45f7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=04-05 Stats: 50 lines in 1 file changed: 27 ins; 19 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From wetmore at openjdk.org Wed May 7 05:47:30 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 7 May 2025 05:47:30 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/92f45f7f..c6baa83b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=05-06 Stats: 12 lines in 2 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From vyazici at openjdk.org Wed May 7 07:29:55 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 07:29:55 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Fix typo in pre-existing JavaDoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24982/files - new: https://git.openjdk.org/jdk/pull/24982/files/ef88b10a..f0623258 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24982&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982 PR: https://git.openjdk.org/jdk/pull/24982 From vyazici at openjdk.org Wed May 7 07:29:55 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 07:29:55 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:26:56 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 314: > 312: *

> 313: * WARNING: The caller of this method shall relinquish and transfer the > 314: * ownership of the byte array to the callee, since the later will not Suggestion: * ownership of the byte array to the callee, since the latter will not ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076979439 From vyazici at openjdk.org Wed May 7 07:29:55 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 07:29:55 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:39:55 GMT, Roger Riggs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in pre-existing JavaDoc > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 314: > >> 312: *

>> 313: * WARNING: The caller of this method shall relinquish and transfer the >> 314: * ownership of the byte array to the callee, since the later will not > > Typo: "later" -> "latter". (pre-existing) Fixed in f0623258e0506c68a274a1e094039bd6d76e3fa6. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076980772 From vyazici at openjdk.org Wed May 7 07:33:14 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 07:33:14 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: <7Tq127ca8kJ6NdghXUbeFL5cT4HC7dEe9-0ySUirpy8=.999f9f7c-2118-4d4a-83c1-d67fb006a2e4@github.com> On Thu, 1 May 2025 13:00:37 GMT, Chen Liang wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in pre-existing JavaDoc > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 315: > >> 313: * WARNING: The caller of this method shall relinquish and transfer the >> 314: * ownership of the byte array to the callee, since the later will not >> 315: * make a copy. > > I think we should add a note on why no copy is made - there may be multiple reads to the input array for decoding, so the input array must not be accessible by untrusted code, which can racily modify it. A side effect is that this array is simply reused if it's eligible to be the string content array, which is unfortunately abused in a few places in the JDK. @liach, thank you so much for the review and the feedback. We internally discussed this and decided leave the change as is. Resolving this conversation. Please let me know if you think otherwise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076985931 From alanb at openjdk.org Wed May 7 07:40:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 07:40:14 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302: > 300: * WARNING: This method does not perform any bound checks. > 301: */ > 302: int countPositives(byte[] ba, int off, int len); Maybe we should change countPositives to do a bounds check and have a private method in StringCoding be the `@IntrinsicCandidate`. This would make it easier to audit. Right now it's hard to audit because there are usages of JLA.countPositives in faraway classes. I'm not suggested we do this as part of this PR of course but it would mean the warning comment could be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2076997921 From alanb at openjdk.org Wed May 7 07:55:16 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 07:55:16 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 332: > 330: *

> 331: * This method throws {@code CharacterCodingException} instead of replacing > 332: * when malformed input or unmappable characters are encountered. Do we have a JBS issue to track renaming the "no replacement" methods? The naming has confused several people as not everyone is familiar with coding error actions. Here, "no replacement" actually means that coding errors are reported. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077022991 From jpai at openjdk.org Wed May 7 08:05:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 May 2025 08:05:14 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc Hello Volkan, I checked with others on how to make it prominent, when reading code and when reviewing changes to code, that the usage of these methods needs extra careful attention. In addition to updating the javadoc of these methods, we came to an agreement that each of these methods should be updated to have `unchecked` as the prefix in their method names. For example, renaming `countPositives(...)` to `uncheckedCountPositives(...)`. Even though it means a few additional characters to the method names, this should help catch attention wherever these methods get used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2857500353 From alanb at openjdk.org Wed May 7 08:05:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 May 2025 08:05:15 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com> On Wed, 7 May 2025 07:29:55 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in pre-existing JavaDoc src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355: > 353: * UTF-16 representation. > 354: *

> 355: * WARNING: This method does not perform any bound checks. Maybe not this PR but this method is begging to be renamed. It's really hard to audit usage when the method is accessible to faraway code via shared secrets. So maybe not this PR but I think we need an issue in JBS to track renaming, I think Stuart suggested prefixing with "unchecked". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077039719 From duke at openjdk.org Wed May 7 11:16:17 2025 From: duke at openjdk.org (Nibedita Jena) Date: Wed, 7 May 2025 11:16:17 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v3] In-Reply-To: References: Message-ID: On Wed, 23 Apr 2025 20:16:17 GMT, Anthony Scarpino wrote: >> Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated SSLSessionImpl constructor with Record interface methods > > I will look at this.. At the time I wrote this I avoided using Record for a reason, but I don't remember why right now. Thanks @ascarpino. Yes I have run/verified for all tiers explicitly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24535#issuecomment-2858165747 From vyazici at openjdk.org Wed May 7 11:20:26 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 May 2025 11:20:26 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:37:48 GMT, Alan Bateman wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in pre-existing JavaDoc > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302: > >> 300: * WARNING: This method does not perform any bound checks. >> 301: */ >> 302: int countPositives(byte[] ba, int off, int len); > > Maybe we should change countPositives to do a bounds check and have a private method in StringCoding be the `@IntrinsicCandidate`. This would make it easier to audit. Right now it's hard to audit because there are usages of JLA.countPositives in faraway classes. I'm not suggested we do this as part of this PR of course but it would mean the warning comment could be removed. Submitted [8356380](https://bugs.openjdk.org/browse/JDK-8356380) to address this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077399743 From rgiulietti at openjdk.org Wed May 7 13:25:18 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 7 May 2025 13:25:18 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v2] In-Reply-To: <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com> References: <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com> Message-ID: On Wed, 7 May 2025 08:02:28 GMT, Alan Bateman wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in pre-existing JavaDoc > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355: > >> 353: * UTF-16 representation. >> 354: *

>> 355: * WARNING: This method does not perform any bound checks. > > Maybe not this PR but this method is begging to be renamed. It's really hard to audit usage when the method is accessible to faraway code via shared secrets. So maybe not this PR but I think we need an issue in JBS to track renaming, I think Stuart suggested prefixing with "unchecked". As mentioned by Alan and Jaikiran, at some point it is advisable to prefix the names with "unchecked". For the "noRepl" names, perhaps the mouthful but clearer "noReplacementChar" might help. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2077617931 From duke at openjdk.org Wed May 7 14:19:17 2025 From: duke at openjdk.org (duke) Date: Wed, 7 May 2025 14:19:17 GMT Subject: RFR: 8350830: Values converted incorrectly when reading TLS session tickets [v3] In-Reply-To: References: Message-ID: <71E0JEjkvvCtY1ukmzLhpuqXe95sb4iMjY9OuQiQ4pQ=.4cae9a75-ea20-466a-93cc-a4a072387e5d@github.com> On Mon, 14 Apr 2025 12:54:31 GMT, Nibedita Jena wrote: >> Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018). >> While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions. >> >> Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127. >> According to RFC 3546, the host_name limit allowed is 255. >> With a sample testcase when the host_name length is > 127, exception is thrown: >> javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2 >> javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception ( >> "throwable" : { >> java.lang.NegativeArraySizeException: -1 >> at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399) >> at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468) >> >> e.g. >> int l = buf.get(); >> b = new byte[l]; <-------------------- NegativeArraySizeException thrown here when > 127 >> >> For TLSv1.3, its not an issue until length > 255. >> >> According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change. >> Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue. > > Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: > > Updated SSLSessionImpl constructor with Record interface methods @nibjen Your change (at version 9e0e0bc980cb9f05dcb0942f707484dfe246263e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24535#issuecomment-2858770359 From weijun at openjdk.org Wed May 7 16:24:25 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 7 May 2025 16:24:25 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 05:47:30 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation) src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 169: > 167: > 168: /** > 169: * Generate Exported Key Material (EKM) calculated according to the s/Key/Keying/ src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1808: > 1806: String label, byte[] context, int length) throws SSLKeyException { > 1807: byte[] bytes = > 1808: exportKeyingMaterialKey(label, context, length).getEncoded(); In PKCS #11, calling `deriveKey(...).getEncoded()` is not equivalent to `deriveData()`. It's quite likely that `deriveKey` returns an un-extractable key, but `deriveData` using the exact same input returns the keying material. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2078023812 PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2078022859 From weijun at openjdk.org Wed May 7 16:31:14 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 7 May 2025 16:31:14 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 05:47:30 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation) src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1694: > 1692: > 1693: // ...now the final expand. > 1694: SecretKey key = hkdf.deriveKey(label, PKCS #11 is picky about key algorithm names and I'm not sure if `label` is always accepted. The KDF API has the algorithm in the method arguments so it's left to user to specify one. I'm not sure how the export keying material will be used. If it is used in encryption, the algorithm may need to be something like "AES". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2078033799 From mullan at openjdk.org Wed May 7 16:49:33 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 7 May 2025 16:49:33 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: <4uTUo63ZDnlnrDUgEeMpENDC0lVN4UlyRkqcDGp1_iQ=.15281bf4-ce58-4b80-b168-0c5a7f3644bd@github.com> On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: > > - major code review comments update > - Merge branch 'master' into pem > - Merge branch 'master' into pem > - javadoc updates > - code review comments > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 src/java.base/share/classes/sun/security/util/Pem.java line 56: > 54: private static ObjectIdentifier PBES2OID; > 55: > 56: // Lazy initialize singleton encoder. s/initialize/initialized/ src/java.base/share/classes/sun/security/util/Pem.java line 301: > 299: * @return the string > 300: */ > 301: public static String pemEncoded(String type, byte[] data) { You could refactor the common code in these two methods into a separate method and call that with the type and data. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078032525 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078057428 From mullan at openjdk.org Wed May 7 16:49:34 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 7 May 2025 16:49:34 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 21:06:06 GMT, Anthony Scarpino wrote: >> I'm afraid that someone will overwrite the java.security file and remove that property. Then wonder what will happen and if the error message is clear. > > I added the exception `SecretKeyFactory.getInstance()` will throw `NullPointerException` if the property is undefined. You would need to add a try/catch block for NPE specifically, which you don't have right now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078043760 From weijun at openjdk.org Wed May 7 16:54:30 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 7 May 2025 16:54:30 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: <1NPCoy9RfTm6v7k1Nu3bjU-ntKn78gU3_mfDH7tFntg=.bf0a52ed-4f5d-4ab5-858b-dd1fbb635fbe@github.com> On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: > > - major code review comments update > - Merge branch 'master' into pem > - Merge branch 'master' into pem > - javadoc updates > - code review comments > - merge with master > - better comment and remove commented out code > - Merge branch 'master' into pem > - Merge branch 'pem-merge' into pem > - merge > - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 Comments for the `PEMDecoder` API. src/java.base/share/classes/java/security/PEMDecoder.java line 60: > 58: * > 59: * > 60: * A specified return class must implement {@link DEREncodable} and be an The `decode(data, Class)` method already requires the class be a `DEREncodable` otherwise it won't compile. So this is no longer a requirement for the caller and there is no need to say `must implement DEREncodable`. src/java.base/share/classes/java/security/PEMDecoder.java line 85: > 83: * 

> 84:  *     PEMDecoder pd = PEMDecoder.of();
> 85:  *     PrivateKey priKey = pd.decode(priKeyPEM);

`decode` does not return a `PrivateKey`. Either cast or specify the class.

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

> 116:     /**
> 117:      * Returns an instance of {@code PEMDecoder}.  This instance may be repeatedly used
> 118:      * to decode different PEM text.

Not only repeatable, but also thread safe I assume? Maybe we need to talk about this in the class spec. Immutable does not automatic implies thread-safe, if the immutability is only observed on the API level.

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

> 226:      * 
This method will read the {@code InputStream} until PEM data is
> 227:      * found or until the end of the stream.  Non-PEM data in the
> 228:      * {@code InputStream} before the PEM header will be ignored by the decoder.

1. This is not precise because you might put the leading data into a `PEMRecord`.

Also, I think it's very important to point out the pointer position of the input stream after this method is successfully called. Otherwise, the method cannot be reliably used in extracting multiple PEMs from a single stream.

Also, I'm not exactly sure what happens when there is nothing more to read.

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

> 382:     /**
> 383:      * Configures and returns a new {@code PEMDecoder} instance from the
> 384:      * current instance that will use KeyFactory and CertificateFactory classes

Put `KeyFactory` and `CertificateFactory` into ``.

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

> 389:      * the default provider configuration.
> 390:      *
> 391:      * @param provider the Factory provider.

s/Factory/factory/

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

PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2822474346
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078047551
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078051030
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078055947
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078060563
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078066545
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078067455

From mullan at openjdk.org  Wed May  7 17:06:17 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 7 May 2025 17:06:17 GMT
Subject: RFR: 8310003: Improve logging when default truststore is
 inaccessible
In-Reply-To: 
References: 
Message-ID: <6tyVLcd9Sy7t1bPAXAp-VxhiYDXYTOP8_VMZJGTiOeA=.c7b666b8-234d-4c4b-a742-8e71c3120fde@github.com>

On Wed, 7 May 2025 03:45:06 GMT, Koushik Muthukrishnan Thirupattur  wrote:

> If the truststore is unavailable, JDK does not log information for 'trustStore provider is:'. We are now adding 'unspecified' instead of keeping empty.

src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java line 133:

> 131:                     KeyStore.getDefaultType());
> 132:             String storePropProvider = System.getProperty(
> 133:                     "javax.net.ssl.trustStoreProvider", "unspecified");

We only want "unspecified" to show up in the log message. This code will set the provider to "unspecified" (if not set) when later instantiating a `TrustManager`, which is not what we want to happen.

Only line 115 should probably be changed. You can do something like:

> "trustStore provider is: " + (storeProvider == null ? "unspecified" : storeProvider) + "\n" +

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25077#discussion_r2078088008

From duke at openjdk.org  Wed May  7 17:13:51 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 7 May 2025 17:13:51 GMT
Subject: RFR: 8310003: Improve logging when default truststore is
 inaccessible [v2]
In-Reply-To: 
References: 
Message-ID: 

> If the truststore is unavailable, JDK does not log information for 'trustStore provider is:'. We are now adding 'unspecified' instead of keeping empty.

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

  8310003: Improve logging when default truststore is inaccessible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25077/files
  - new: https://git.openjdk.org/jdk/pull/25077/files/b422bbb7..c41c7a8f

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

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

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

From duke at openjdk.org  Wed May  7 17:13:52 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 7 May 2025 17:13:52 GMT
Subject: RFR: 8310003: Improve logging when default truststore is
 inaccessible [v2]
In-Reply-To: <6tyVLcd9Sy7t1bPAXAp-VxhiYDXYTOP8_VMZJGTiOeA=.c7b666b8-234d-4c4b-a742-8e71c3120fde@github.com>
References: 
 <6tyVLcd9Sy7t1bPAXAp-VxhiYDXYTOP8_VMZJGTiOeA=.c7b666b8-234d-4c4b-a742-8e71c3120fde@github.com>
Message-ID: 

On Wed, 7 May 2025 17:02:26 GMT, Sean Mullan  wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8310003: Improve logging when default truststore is inaccessible
>
> src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java line 133:
> 
>> 131:                     KeyStore.getDefaultType());
>> 132:             String storePropProvider = System.getProperty(
>> 133:                     "javax.net.ssl.trustStoreProvider", "unspecified");
> 
> We only want "unspecified" to show up in the log message. This code will set the provider to "unspecified" (if not set) when later instantiating a `TrustManager`, which is not what we want to happen.
> 
> Only line 115 should probably be changed. You can do something like:
> 
>> "trustStore provider is: " + (storeProvider == null ? "unspecified" : storeProvider) + "\n" +

I see, I misunderstood our conversation. Changed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25077#discussion_r2078102147

From vyazici at openjdk.org  Wed May  7 18:33:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 18:33:11 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Prefix touched methods with `unchecked`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/f0623258..4d237efa

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

  Stats: 66 lines in 21 files changed: 0 ins; 3 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/24982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982

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

From vyazici at openjdk.org  Wed May  7 18:33:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 18:33:12 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: 
References: 
 
 <9IfMW-HLFSI8eeAfs6m3jZyfpzGRhnutoTgYFripC4U=.f84019f8-30d4-43ce-857a-6f3d71bfd713@github.com>
 
Message-ID: 

On Wed, 7 May 2025 13:22:11 GMT, Raffaello Giulietti  wrote:

>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 355:
>> 
>>> 353:      * UTF-16 representation.
>>> 354:      * 

>>> 355:      * WARNING: This method does not perform any bound checks.
>> 
>> Maybe not this PR but this method is begging to be renamed. It's really hard to audit usage when the method is accessible to faraway code via shared secrets. So maybe not this PR but I think we need an issue in JBS to track renaming, I think Stuart suggested prefixing with "unchecked".
>
> As mentioned by Alan and Jaikiran, at some point it is advisable to prefix the names with "unchecked".
> 
> For the "noRepl" names, perhaps the mouthful but clearer "noReplacementChar" might help.

@jaikiran, @AlanBateman, implemented `unchecked` method prefix in 4d237efa053.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2078253548

From vyazici at openjdk.org  Wed May  7 18:39:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 May 2025 18:39:42 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 7 May 2025 07:52:37 GMT, Alan Bateman  wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in pre-existing JavaDoc
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 332:
> 
>> 330:      * 

>> 331:      * This method throws {@code CharacterCodingException} instead of replacing
>> 332:      * when malformed input or unmappable characters are encountered.
> 
> Do we have a JBS issue to track renaming the "no replacement" methods? The naming has confused several people as not everyone is familiar with coding error actions.  Here, "no replacement" actually means that coding errors are reported.

Created [JDK-8356439](https://bugs.openjdk.org/browse/JDK-8356439) for this purpose.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2078269984

From mullan at openjdk.org  Wed May  7 19:43:12 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 7 May 2025 19:43:12 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <1NPCoy9RfTm6v7k1Nu3bjU-ntKn78gU3_mfDH7tFntg=.bf0a52ed-4f5d-4ab5-858b-dd1fbb635fbe@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 <1NPCoy9RfTm6v7k1Nu3bjU-ntKn78gU3_mfDH7tFntg=.bf0a52ed-4f5d-4ab5-858b-dd1fbb635fbe@github.com>
Message-ID: <3zW-bAWD-IWkS_6VzPhThNpGybzvnOJQddZSmpCPZbQ=.af9efc29-b8b1-4860-8128-9a8f3088803d@github.com>

On Wed, 7 May 2025 16:42:20 GMT, Weijun Wang  wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
>> 
>>  - major code review comments update
>>  - Merge branch 'master' into pem
>>  - Merge branch 'master' into pem
>>  - javadoc updates
>>  - code review comments
>>  - merge with master
>>  - better comment and remove commented out code
>>  - Merge branch 'master' into pem
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 118:
> 
>> 116:     /**
>> 117:      * Returns an instance of {@code PEMDecoder}.  This instance may be repeatedly used
>> 118:      * to decode different PEM text.
> 
> Not only repeatable, but also thread safe I assume? Maybe we need to talk about this in the class spec. Immutable does not automatic implies thread-safe, if the immutability is only observed on the API level.

Usually there is a sentence at the end of the class description, ex- "This class is immutable and thread-safe." Once you state that, you don't need to say anything more in the methods like the sentence above about repeatability.

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

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

From mullan at openjdk.org  Wed May  7 19:43:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 7 May 2025 19:43:11 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
Message-ID: 

On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino  wrote:

>> Hi all,
>> 
>> I need a code review of the PEM API.  Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates.  It will be integrated into JDK24 as a Preview Feature.  Preview features does not permanently define the API and it is subject to change in future releases until it is finalized.
>> 
>> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
> 
>  - major code review comments update
>  - Merge branch 'master' into pem
>  - Merge branch 'master' into pem
>  - javadoc updates
>  - code review comments
>  - merge with master
>  - better comment and remove commented out code
>  - Merge branch 'master' into pem
>  - Merge branch 'pem-merge' into pem
>  - merge
>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327

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

> 66:  * class is specified.
> 67:  *
> 68:  * 
 A new immutable {@code PEMDecoder} instance is created when configured

no need to say "immutable" as first sentence says all PEMDecoders are immutable.

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

> 69:  * with {@linkplain #withFactory} and/or {@linkplain #withDecryption}.
> 70:  * Configuring an instance for decryption does not prevent decoding with
> 71:  * unencrypted PEM. Any encrypted PEM that does not use the configured password

I found the last 3 sentences a bit jumping too quickly into details. I suggest having 2 sentences after the first one, where each sentence explains what the `withDecryption` and `withFactory` methods do, respectively.

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

> 90:  * @spec https://www.rfc-editor.org/info/rfc7468
> 91:  *       RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures
> 92:  *

Might be useful to add an `@see PEMEncoder` (and vice-versa).

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

> 224:      * {@code InputStream}.
> 225:      *
> 226:      * 
This method will read the {@code InputStream} until PEM data is

Use present tense:

s/will read/reads/

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

> 226:      * 
This method will read the {@code InputStream} until PEM data is
> 227:      * found or until the end of the stream.  Non-PEM data in the
> 228:      * {@code InputStream} before the PEM header will be ignored by the decoder.

s/will be/is/

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

> 228:      * {@code InputStream} before the PEM header will be ignored by the decoder.
> 229:      * If only non-PEM data is found a {@link PEMRecord} is returned with that
> 230:      * data.

Why? Shouldn't this be an exception as it isn't PEM?

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

> 250:      * 

> 251:      * {@code tClass} can be used to change the return type instance:
> 252:      * 
    

This list feels more like programming advice. I would suggest either removing this, or putting it in the class description but not as a bulleted list, instead use complete sentences.

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

> 397: 
> 398:     /**
> 399:      * Returns a new {@code PEMDecoder} instance from the current instance

I find the words "a new instance from a current instance" a little unusual.

It might be simpler and clearer to say "Returns a copy of this PEMDecoder that will decrypt encrypted PEM data such as encrypted private keys with the specified password."

(I don't feel it is necessary to mention that it still also decodes unencrypted PEM - that seems implied to me).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078271620
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078305808
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078267302
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078316191
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078316388
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078318044
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078332711
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078358673

From weibing.xiao at oracle.com  Wed May  7 19:59:15 2025
From: weibing.xiao at oracle.com (Weibing Xiao)
Date: Wed, 7 May 2025 19:59:15 +0000
Subject: [Bug] NPE thrown from SASL GSSAPI impl on Java 11+ when  TLS is
 used with QOP auth-int against Active Directory
In-Reply-To: 
References: 
Message-ID: 

Hi Michael,

Please share a working copy of the code to duplicate the failure scenario of NPE related to Connection.java. BTW, I checked the stack trace posted on April 28 it did not clearly show Connection::cleanup got called. Was there something missed?

Thank you,
Weibing

From: security-dev  on behalf of security-dev-request at openjdk.org 
Date: Tuesday, April 29, 2025 at 4:54?AM
To: security-dev at openjdk.org 
Subject: security-dev Digest, Vol 214, Issue 151
Send security-dev mailing list submissions to
        security-dev at openjdk.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://mail.openjdk.org/mailman/listinfo/security-dev
or, via email, send a message with subject or body 'help' to
        security-dev-request at openjdk.org

You can reach the person managing the list at
        security-dev-owner at openjdk.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of security-dev digest..."


Today's Topics:

   1. Re: RFR: 8350498: Remove two Camerfirma root CA certificates
      (Mark Powers)
   2. Re: RFR: 8354305: SHAKE128 and SHAKE256 MessageDigest
      algorithms [v3] (Valerie Peng)
   3. Re: [Bug] NPE thrown from SASL GSSAPI impl on Java 11+ when
      TLS is used with QOP auth-int against Active Directory
      (Osipov, Michael (IN IT IN))


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

Message: 1
Date: Tue, 29 Apr 2025 01:21:44 GMT
From: Mark Powers 
To: 
Subject: Re: RFR: 8350498: Remove two Camerfirma root CA certificates
Message-ID:
        

Content-Type: text/plain; charset=utf-8

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

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

This looks good to me.

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

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


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

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

Content-Type: text/plain; charset=utf-8

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

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

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

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

Marked as reviewed by valeriep (Reviewer).

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


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

Message: 3
Date: Tue, 29 Apr 2025 10:54:31 +0200
From: "Osipov, Michael (IN IT IN)" 
To: security-dev at openjdk.org
Cc: andrewlu at openjdk.org
Subject: Re: [Bug] NPE thrown from SASL GSSAPI impl on Java 11+ when
        TLS is used with QOP auth-int against Active Directory
Message-ID: <9baba8d6-066a-42cd-9649-e16033108ee7 at siemens.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

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

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

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

Andrew,

can you log a bug here?

Michael


End of security-dev Digest, Vol 214, Issue 151
**********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wetmore at openjdk.org  Wed May  7 21:24:12 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 7 May 2025 21:24:12 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v8]
In-Reply-To: 
References: 
Message-ID: 

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  More Codereview comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/c6baa83b..2e5f5342

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=06-07

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

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

From valeriep at openjdk.org  Wed May  7 22:29:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 May 2025 22:29:03 GMT
Subject: RFR: 8356087: Problematic KeyInfo check using key algorithm in
 P11SecretKeyFactory class
Message-ID: 

In the PR for JDK-8348732 "SunJCE and SunPKCS11 have different PBE key encodings", the `P11SecretKeyFactory.convertKey(...)` method is refactored to call `getKeyInfo(keyAlgo)` and check that it's not `null`. However, this leads to problems for the `P11Mac` object when it's initialized with a key whose algorithm is not recognized by SunPKCS11 provider. It fails with an unexpected `InvalidKeyException`. Thus, reverting back to the pre-JDK8348732 code and calls `getKeyInfo(keyAlgo)` only when needed.

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

Commit messages:
 - reuse si if keyAlgo == svcAlgo
 - 8356087: Problematic KeyInfo check using key algorithm in P11SecretKeyFactory class

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

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

From valeriep at openjdk.org  Wed May  7 22:43:10 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 7 May 2025 22:43:10 GMT
Subject: RFR: 8356087: Problematic KeyInfo check using key algorithm in
 P11SecretKeyFactory class [v2]
In-Reply-To: 
References: 
Message-ID: 

> In the PR for JDK-8348732 "SunJCE and SunPKCS11 have different PBE key encodings", the `P11SecretKeyFactory.convertKey(...)` method is refactored to call `getKeyInfo(keyAlgo)` and check that it's not `null`. However, this leads to problems for the `P11Mac` object when it's initialized with a key whose algorithm is not recognized by SunPKCS11 provider. It fails with an unexpected `InvalidKeyException`. Thus, reverting back to the pre-JDK8348732 code and calls `getKeyInfo(keyAlgo)` only when needed.

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

  minor wording changes for test summary.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25108/files
  - new: https://git.openjdk.org/jdk/pull/25108/files/a4419f5d..0c37d587

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

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

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

From rhalade at openjdk.org  Thu May  8 05:08:57 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 May 2025 05:08:57 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v4]
In-Reply-To: 
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 
Message-ID: 

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

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

Fix looks good to me.

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

Marked as reviewed by rhalade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23898#pullrequestreview-2823814506

From rhalade at openjdk.org  Thu May  8 05:33:01 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 May 2025 05:33:01 GMT
Subject: RFR: 8349151: Refactor
 test/java/security/cert/CertificateFactory/slowstream.sh to java test [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 3 Feb 2025 19:12:30 GMT, Mikhail Yankelevich  wrote:

>> Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

Changes requested by rhalade (Reviewer).

test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 32:

> 30: 
> 31: import java.io.*;
> 32: import java.security.cert.*;

Suggestion:

import java.io.File;
import java.io.FileInputStream;
import java.io.PipedInputStream;
import java.io.PipedOutputStream;
import java.security.cert.CertificateFactory;

test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 55:

> 53:                         outputStream.write(buffer, 0, len);
> 54:                     }
> 55:                     Thread.sleep(2000);

Suggestion:

                    try(final var fin = new FileInputStream(new File(new File(
                            System.getProperty("test.src", "."), "openssl"), "pem"))) {
                        final byte[] buffer = new byte[4096];
                        while (true) {
                            int len = fin.read(buffer);
                            if (len < 0) {
                                break;
                            }
                            outputStream.write(buffer, 0, len);
                        }
                        Thread.sleep(2000);
                    }

test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 94:

> 92:         }
> 93:     }
> 94: }

Suggestion:

}

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

PR Review: https://git.openjdk.org/jdk/pull/23394#pullrequestreview-2823835159
PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2078904169
PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2078910272
PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2078908630

From rhalade at openjdk.org  Thu May  8 05:57:52 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 8 May 2025 05:57:52 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 6 Feb 2025 15:54:47 GMT, Mikhail Yankelevich  wrote:

>> * fully automated the test
>> * removed the race condition
>> * client on a thread and server on a thread options are now run together automatically
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment changes

I understand this is a old test and it is not in scope of this bug to update existing code. But there are few issues in this test that should be addressed, for instance, use of deprecated URL, old style threads, old code styles, typos etc. Can you please check the complete test code as if you are to rewrite?

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

PR Comment: https://git.openjdk.org/jdk/pull/23469#issuecomment-2861858937

From wetmore at openjdk.org  Thu May  8 06:05:52 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 8 May 2025 06:05:52 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 7 May 2025 16:28:27 GMT, Weijun Wang  wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1694:
> 
>> 1692: 
>> 1693:                     // ...now the final expand.
>> 1694:                     SecretKey key = hkdf.deriveKey(label,
> 
> PKCS #11 is picky about key algorithm names and I'm not sure if `label` is always accepted. The KDF API has the algorithm in the method arguments so it's left to user to specify one. I'm not sure how the export keying material will be used. If it is used in encryption, the algorithm may need to be something like "AES".

IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be.  They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed.  This is just doing a quick read of some of the IANA definitions which link to some of the known use cases:

    https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels 

Thus the type needs to be something generic.  The label sounded good initially, but there is no specific prohibition against non-null/empty label in the TLS Exporters, but KDF prohibits null/empty labels.

Maybe a label like "ExportKeyingMaterial"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2078948256

From duke at openjdk.org  Thu May  8 09:09:02 2025
From: duke at openjdk.org (Nibedita Jena)
Date: Thu, 8 May 2025 09:09:02 GMT
Subject: Integrated: 8350830: Values converted incorrectly when reading TLS
 session tickets
In-Reply-To: 
References: 
Message-ID: <7YowGAhoW-le7RPkyy1z2xHrjqPiAnD377paAlnoMQo=.ea8900e6-79c3-40c3-8770-15f57699e952@github.com>

On Wed, 9 Apr 2025 03:28:40 GMT, Nibedita Jena  wrote:

> Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018).
> While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions.
> 
> Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127.
> According to RFC 3546, the host_name limit allowed is 255.
> With a sample testcase when the host_name length is > 127, exception is thrown:
> javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2
> javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception (
> "throwable" : {
>   java.lang.NegativeArraySizeException: -1
>         at java.base/sun.security.ssl.SSLSessionImpl.(SSLSessionImpl.java:399)
>         at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468)
> 
> e.g.
> int l = buf.get();
> b = new byte[l];  <-------------------- NegativeArraySizeException thrown here when > 127
> 
> For TLSv1.3, its not an issue until length > 255.
> 
> According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change.
> Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue.

This pull request has now been integrated.

Changeset: 2c1eb339
Author:    nibjen 
Committer: Daniel Jeli?ski 
URL:       https://git.openjdk.org/jdk/commit/2c1eb339d6c9b6cc6fa4a8780b0e0b8d4d9a5f01
Stats:     435 lines in 2 files changed: 370 ins; 33 del; 32 mod

8350830: Values converted incorrectly when reading TLS session tickets

Reviewed-by: djelinski, ascarpino

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

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

From myankelevich at openjdk.org  Thu May  8 10:16:57 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 8 May 2025 10:16:57 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <74ZtTS-NMZ0PRMZbT46BSJtaMkeIfYvGJxtKovQ6wlU=.8d61b0aa-8819-4ba4-bc08-753912910c1d@github.com>

On Thu, 8 May 2025 05:54:58 GMT, Rajan Halade  wrote:

> I understand this is a old test and it is not in scope of this bug to update existing code. But there are few issues in this test that should be addressed, for instance, use of deprecated URL, old style threads, old code styles, typos etc. Can you please check the complete test code as if you are to rewrite?

Updated the code

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

PR Comment: https://git.openjdk.org/jdk/pull/23469#issuecomment-2862510391

From myankelevich at openjdk.org  Thu May  8 10:16:56 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 8 May 2025 10:16:56 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v4]
In-Reply-To: 
References: 
Message-ID: 

> * fully automated the test
> * removed the race condition
> * client on a thread and server on a thread options are now run together automatically

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

  cleanup and update of the code to the current style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23469/files
  - new: https://git.openjdk.org/jdk/pull/23469/files/68c52a37..2bff4a34

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

  Stats: 68 lines in 1 file changed: 13 ins; 5 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/23469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23469/head:pull/23469

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

From myankelevich at openjdk.org  Thu May  8 10:28:41 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 8 May 2025 10:28:41 GMT
Subject: RFR: 8349151: Refactor
 test/java/security/cert/CertificateFactory/slowstream.sh to java test [v3]
In-Reply-To: 
References: 
Message-ID: <9rReYxqW4qnmKvsXfs5dEjS-5Gt42Hu81rcCWpAVxWw=.a3570973-c6c5-45ce-b27d-70776f3d1fa6@github.com>

> Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test

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

  Rajan's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23394/files
  - new: https://git.openjdk.org/jdk/pull/23394/files/396844a4..520fcde6

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

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

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

From myankelevich at openjdk.org  Thu May  8 10:28:42 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 8 May 2025 10:28:42 GMT
Subject: RFR: 8349151: Refactor
 test/java/security/cert/CertificateFactory/slowstream.sh to java test [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 8 May 2025 05:20:19 GMT, Rajan Halade  wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 32:
> 
>> 30: 
>> 31: import java.io.*;
>> 32: import java.security.cert.*;
> 
> Suggestion:
> 
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.PipedInputStream;
> import java.io.PipedOutputStream;
> import java.security.cert.CertificateFactory;

Implemented in the next commit. Thank you

> test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 55:
> 
>> 53:                         outputStream.write(buffer, 0, len);
>> 54:                     }
>> 55:                     Thread.sleep(2000);
> 
> Suggestion:
> 
>                     try(final var fin = new FileInputStream(new File(new File(
>                             System.getProperty("test.src", "."), "openssl"), "pem"))) {
>                         final byte[] buffer = new byte[4096];
>                         while (true) {
>                             int len = fin.read(buffer);
>                             if (len < 0) {
>                                 break;
>                             }
>                             outputStream.write(buffer, 0, len);
>                         }
>                         Thread.sleep(2000);
>                     }

Implemented in the next commit. Thank you

> test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 94:
> 
>> 92:         }
>> 93:     }
>> 94: }
> 
> Suggestion:
> 
> }

Implemented in the next commit. Thank you

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2079443877
PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2079444089
PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2079443984

From weijun at openjdk.org  Thu May  8 11:41:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 May 2025 11:41:57 GMT
Subject: RFR: 8349151: Refactor
 test/java/security/cert/CertificateFactory/slowstream.sh to java test [v3]
In-Reply-To: <9rReYxqW4qnmKvsXfs5dEjS-5Gt42Hu81rcCWpAVxWw=.a3570973-c6c5-45ce-b27d-70776f3d1fa6@github.com>
References: 
 <9rReYxqW4qnmKvsXfs5dEjS-5Gt42Hu81rcCWpAVxWw=.a3570973-c6c5-45ce-b27d-70776f3d1fa6@github.com>
Message-ID: 

On Thu, 8 May 2025 10:28:41 GMT, Mikhail Yankelevich  wrote:

>> Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rajan's comments

test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 28:

> 26:  * @bug 6813340
> 27:  * @summary X509Factory should not depend on is.available()==0
> 28:  * @run main/othervm SlowStream

Why `othervm`?

test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 53:

> 51:                             "pem"))) {
> 52: 
> 53:                         final byte[] buffer = new byte[4096];

This test was probably written very log ago where there was no NIO or `InputStream::readAllBytes`. The file itself is quite small and there is no need to read in blocks. You can use modern methods like `Files::readAllBytes` or `InputStream::transferTo`.

test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 75:

> 73:             try {
> 74:                 final var factory = CertificateFactory.getInstance("X.509");
> 75:                 final var factorySize = factory.generateCertificates(inputStream).size();

Please change the variable name to something like `numOfCerts`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2079548084
PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2079545423
PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2079535807

From pminborg at openjdk.org  Thu May  8 13:28:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 May 2025 13:28:56 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <59OdbQo1ngGTIk-vHURu151vFfblIVyHRATwhTGqFY0=.e5a6c409-e23d-435c-a86c-4847ac392ef1@github.com>

On Wed, 7 May 2025 18:33:11 GMT, Volkan Yazici  wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefix touched methods with `unchecked`

LGTM

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2825136323

From mullan at openjdk.org  Thu May  8 13:53:13 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 8 May 2025 13:53:13 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v9]
In-Reply-To: 
References: 
 <1Xr2sRYmmOuRi9pjhKAQkutceCumCtQgNPIsbqSeiB8=.340ab740-dd04-4b63-8baa-68d0a0783013@github.com>
 
 
 
Message-ID: <58P6Ust-hFGF3J9wXgAfBqwn5_fr6tzXnPldwP9Qw4I=.d5c33503-5487-4bd3-80d1-446d48564a86@github.com>

On Thu, 31 Oct 2024 01:44:32 GMT, Weijun Wang  wrote:

>> I'm not sure if it was exclusively a Security Manager exception, but @seanjmullan had said previously that `SecurityException` was used elsewhere.
>
> It was used when `JarInputStream::read` encountered a wrong hash or signature. But, it was mainly used for permission violation.

We should not be using `SecurityException` for any new APIs right now until its fate is decided.

I think we should throw a checked exception here (whatever the underlying Cipher throws), as it would be more consistent with the other methods in this API.

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

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

From mullan at openjdk.org  Thu May  8 13:53:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 8 May 2025 13:53:11 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
Message-ID: 

On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino  wrote:

>> Hi all,
>> 
>> I need a code review of the PEM API.  Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates.  It will be integrated into JDK24 as a Preview Feature.  Preview features does not permanently define the API and it is subject to change in future releases until it is finalized.
>> 
>> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
> 
>  - major code review comments update
>  - Merge branch 'master' into pem
>  - Merge branch 'master' into pem
>  - javadoc updates
>  - code review comments
>  - merge with master
>  - better comment and remove commented out code
>  - Merge branch 'master' into pem
>  - Merge branch 'pem-merge' into pem
>  - merge
>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 63:

> 61:  */
> 62: 
> 63: public final class EncryptedPrivateKeyInfo implements DEREncodable {

Make this non-sealed instead of final, per CSR feedback.

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

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

From mullan at openjdk.org  Thu May  8 13:53:13 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 8 May 2025 13:53:13 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
Message-ID: 

On Sat, 26 Apr 2025 08:39:50 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 83:
>> 
>>> 81:      * Constructs an {@code EncryptedPrivateKeyInfo} from a given Encrypted
>>> 82:      * PKCS#8 ASN.1 encoding.
>>> 83:      * @param encoded the ASN.1 encoding which is cloned and then parsed.
>> 
>> Somehow I prefer the original "The contents of the array...". We've used this style in a lot of places.
>
> I didn't change the rest of them because I didn't want to make too many unnecessary edits.  I understand you like it, but it is not a concise description. 
> 
> The one word "cloned" is a lot simpler and means the same as:
> "The contents of {@code encryptedData} are copied to protect against subsequent modification when constructing this object."

The words "to protect against subsequent modification" are important and if I recall was something we added a long time ago to many of our APIs. I would restore the original text. Also, the other constructor is still using those words.

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

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

From liach at openjdk.org  Thu May  8 14:55:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 14:55:07 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 7 May 2025 18:33:11 GMT, Volkan Yazici  wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prefix touched methods with `unchecked`

Reviewed missing copyright updates. Only files with comments need copyright year updates.

Let's re-approve after copyright fix.

src/java.base/share/classes/java/io/DataInputStream.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/java/io/ObjectInputStream.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/java/util/HexFormat.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/java/util/zip/ZipCoder.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/CESU_8.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/DoubleByte.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/SingleByte.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/US_ASCII.java line 1:

> 1: /*

Copyright year

src/java.base/share/classes/sun/nio/cs/UTF_8.java line 1:

> 1: /*

Copyright year

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 1:

> 1: /*

Copyright year

src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 1:

> 1: /*

Copyright year

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2825397502
Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2825413999
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079869063
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079869753
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079870851
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079871207
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079873366
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079874098
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079874388
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079874760
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079875143
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079875444
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079875789
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079876056
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079876669
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2079877098

From lkorinth at openjdk.org  Thu May  8 15:02:42 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 15:02:42 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for change
 of default timeout factor
Message-ID: 

This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).

The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).

My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
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

Sometime in the future I will also fix:
8260555: Change the default TIMEOUT_FACTOR from 4 to 1

for which I am awaiting:
CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1

*After the review I will revert the two first commits, and update the copyrights*

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

Commit messages:
 - 8356171: Increase timeout for testcases as preparation for change of default timeout factor
 - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER
 - 8260555

Changes: https://git.openjdk.org/jdk/pull/25122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356171
  Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/25122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122

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

From stefank at openjdk.org  Thu May  8 16:09:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion.

I made a cursory look through some GC files and I think that looked good.

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

Maybe
Suggestion:

interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

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

PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242
PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720

From dfuchs at openjdk.org  Thu May  8 16:10:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:10:18 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

Daniel Fuchs has updated the pull request 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:

 - Merge branch 'master' into deprecate-net-perms-8353642
 - Revert changes to SocketPermission and CodeSource
 - Review feedback. Deprecate getPermission for removal.
 - Missing white spaces
 - 8353642: Deprecate networking permission classes for removal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24592/files
  - new: https://git.openjdk.org/jdk/pull/24592/files/d47a31d1..2807f3f6

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

  Stats: 268511 lines in 2569 files changed: 76630 ins; 182086 del; 9795 mod
  Patch: https://git.openjdk.org/jdk/pull/24592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592

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

From dfuchs at openjdk.org  Thu May  8 16:14:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:14:54 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs  wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request 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:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

After discussion with @seanjmullan we decided to revert the changes to `SocketPermission` and `CodeSource` from this PR. Deprecation of `SocketPermission` will be the object of another RFE ([JDK-8356557](https://bugs.openjdk.org/browse/JDK-8356557)) - once we have decided what to do with `CodeSource::implies`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2863592195

From dfuchs at openjdk.org  Thu May  8 16:28:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:28:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

@lkorinth have you run all the tiers where the old default timeout factor of 4 applied?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579

From lkorinth at openjdk.org  Thu May  8 16:45:56 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 16:45:56 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Before this version, I had run tiers 1-8, with 11 fails.

** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700
** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 03 tools/javac/util/IteratorsTest.java 480
** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480
** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER
** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER
** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480
** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER
** DONE 10 java/foreign/TestMismatch.java 480
** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER

Six of those seems not related to my changes (marked `OTHER`),  five  I have updated for this run with new timeout.

I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time.

After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496
PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379

From lkorinth at openjdk.org  Thu May  8 17:06:02 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 17:06:02 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
References: 
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
Message-ID: 

On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson  wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
>> 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
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> Maybe
> Suggestion:
> 
> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016

From weijun at openjdk.org  Thu May  8 17:14:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 May 2025 17:14:09 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
Message-ID: 

On Fri, 2 May 2025 06:09:52 GMT, Anthony Scarpino  wrote:

>> Hi all,
>> 
>> I need a code review of the PEM API.  Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates.  It will be integrated into JDK24 as a Preview Feature.  Preview features does not permanently define the API and it is subject to change in future releases until it is finalized.
>> 
>> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
> 
>  - major code review comments update
>  - Merge branch 'master' into pem
>  - Merge branch 'master' into pem
>  - javadoc updates
>  - code review comments
>  - merge with master
>  - better comment and remove commented out code
>  - Merge branch 'master' into pem
>  - Merge branch 'pem-merge' into pem
>  - merge
>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327

Comments on `EncryptedPrivateKeyInfo`.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 374:

> 372:             SecretKeyFactory factory;
> 373:             if (provider == null) {
> 374:                 factory = SecretKeyFactory.getInstance(algorithm);

`algorithm` might be null.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 397:

> 395:      * arguments passed to the method.
> 396:      * @throws SecurityException on a encryption errors.
> 397:      * @throws NullPointerException when the password is null.

and when `key` is `null`.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 408:

> 406:     public static EncryptedPrivateKeyInfo encryptKey(PrivateKey key,
> 407:         char[] password) {
> 408:         char[] pass = password.clone();

No need to clone password here. It will be cloned into a `PBEKeySpec` later.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 458:

> 456:         }
> 457: 
> 458:         if (Pem.DEFAULT_ALGO == null || Pem.DEFAULT_ALGO.length() == 0) {

Is this required if `algorithm` is already specified?

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 573:

> 571:      *                 {@code SecretKeyFactory}, and the {@code PrivateKey},
> 572:      *                 {@code KeyFactory}.  A {@code null} value will use the
> 573:      *                 default provider configuration.

There is no `SecretKeyFactory` in this method, but there is `Cipher`.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 577:

> 575:      * @throws InvalidKeyException if an error occurs during parsing of the
> 576:      * encrypted data or creation of the key object.
> 577:      * @throws NullPointerException if {@code key} is null.

s/key/decryptKey/.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 582:

> 580:      */
> 581:     @PreviewFeature(feature = PreviewFeature.Feature.PEM_API)
> 582:     public PrivateKey getKey(Key decryptKey, Provider provider)

This method goes one step further than the existing `getKeySpec(dk, p)`. It should only throw more types of exception than the existing one. Now you put everything into a `InvalidKeyException`. Is that good?

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

PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2825666685
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080069229
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080040299
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080032269
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080067182
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080114399
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080114811
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080127359

From dfuchs at openjdk.org  Thu May  8 17:43:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 17:43:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
Tests have not finished running - but I already see one intermittent failure:
`java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
It would be good to flush out any such intermittent failures before this PR is integrated.
This might require multiple runs before we can get confidence.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648

From valeriep at openjdk.org  Thu May  8 18:07:58 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 8 May 2025 18:07:58 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <3BoHY6DlJxRc-uP6TgIXuo7ceJ7wkA-kmZnl1-OqM_8=.ca9cdc36-bc61-4df8-973c-60d82dd6c0ca@github.com>

On Wed, 7 May 2025 05:00:57 GMT, Bradford Wetmore  wrote:

>> Yes, it'd be nice. I reopened https://bugs.openjdk.org/browse/JDK-8160206 and we can address this separately.
>
> Or in the meantime:
> 
>     } finally {
>         // Best effort
>         if (eae_prk instanceof SecretKeySpec s) {
>             SharedSecrets.getJavaxCryptoSpecAccess()
>                     .clearSecretKeySpec(s);
>         } else {
>             try {
>                 eae_prk.destroy();
>             } catch (DestroyFailedException e) {
>                 // swallow
>             }
>         }
>     }

Sounds good, thanks for the suggestion.

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

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

From djelinski at openjdk.org  Thu May  8 18:11:56 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 8 May 2025 18:11:56 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs  wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request 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:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2825963973

From valeriep at openjdk.org  Thu May  8 18:49:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 8 May 2025 18:49:55 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v7]
In-Reply-To: <_HccQ4L2NE5PBsBoRUrw1bsPJQgoGGS0LlcICS1jArM=.4546df85-abb5-48be-8657-3502b1842744@github.com>
References: 
 
 <_HccQ4L2NE5PBsBoRUrw1bsPJQgoGGS0LlcICS1jArM=.4546df85-abb5-48be-8657-3502b1842744@github.com>
Message-ID: 

On Tue, 6 May 2025 04:40:02 GMT, Bradford Wetmore  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments from Sean.
>
> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 409:
> 
>> 407:             HKDFParameterSpec spec =
>> 408:                     HKDFParameterSpec.ofExtract().addIKM(s).extractOnly();
>> 409:             return hkdf.deriveKey("Generic", spec);
> 
> I haven't done much with DHKEM yet, but should the returned key have algorithm name of "Generic," or something more descriptive like the previous "HKDF-PRK"?

Me neither. However, given `HKDF-PRK` is not a standard algorithm and also not recognized by the `SunPKCS11` provider, I changed it to `Generic`. Existing `HKDF` impl in the `SunPKCS11` provider is quite strict about the derived key algorithms and it will error out unless we add `HKDF-PRK` to be a recognized key algorithm for key derivation. Given these reasons, it seems `Generic` is the better choice here.

> src/java.base/share/classes/sun/security/ssl/CipherSuite.java line 1:
> 
>> 1: /*
> 
> Copyright update.

Will fix.

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

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

From valeriep at openjdk.org  Thu May  8 18:52:54 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 8 May 2025 18:52:54 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v7]
In-Reply-To: 
References: 
 
 <_HccQ4L2NE5PBsBoRUrw1bsPJQgoGGS0LlcICS1jArM=.4546df85-abb5-48be-8657-3502b1842744@github.com>
 
Message-ID: 

On Wed, 7 May 2025 04:27:10 GMT, Bradford Wetmore  wrote:

>> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 1222:
>> 
>>> 1220:             CipherSuite.HashAlg hashAlg = hc.negotiatedCipherSuite.hashAlg;
>>> 1221:             KDF hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm);
>>> 1222:             SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret",
>> 
>> I'm a little worried that the proper number of salt zeros are now expected to be known in the KDF deriveKey code instead of specified specifically here (and in other similar places).  Should we consider specifying them here and the other places instead to play it safe?
>
> I just found that we had talked about this previously.  What was your reasoning for pulling it?  
> 
> Call me paranoid, but I'm not seeing where the [JDK 24 javadocs](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/javax/crypto/spec/HKDFParameterSpec.Builder.html#addSalt(byte%5B%5D)) discuss what happens if salt is not supplied.  [RFC 8446/Section 7.1](https://www.rfc-editor.org/rfc/rfc8446.html#section-7.1) states:
> 
>      -  "0" indicates a string of Hash.length bytes set to zero.

Ok, I will add it back just to be safe.

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

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

From prr at openjdk.org  Thu May  8 20:02:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:02:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

test/jdk/java/awt/font/NumericShaper/MTTest.java

- * @run main/timeout=300/othervm MTTest
+ * @run main/timeout=1200/othervm MTTest

I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.

https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java

So 300 was fine, and 1200 isn't needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534

From iris at openjdk.org  Thu May  8 20:28:57 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 8 May 2025 20:28:57 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs  wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request 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:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2826287061

From ascarpino at openjdk.org  Thu May  8 20:40:28 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 8 May 2025 20:40:28 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
Message-ID: 

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

Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:

 - comments
 - toString update
 - non-sealed
   Better X509 KeyPair parsing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17543/files
  - new: https://git.openjdk.org/jdk/pull/17543/files/0c540327..ae43835d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=14-15

  Stats: 207 lines in 11 files changed: 129 ins; 32 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/17543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543

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

From ascarpino at openjdk.org  Thu May  8 20:47:10 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 8 May 2025 20:47:10 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <1NPCoy9RfTm6v7k1Nu3bjU-ntKn78gU3_mfDH7tFntg=.bf0a52ed-4f5d-4ab5-858b-dd1fbb635fbe@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 <1NPCoy9RfTm6v7k1Nu3bjU-ntKn78gU3_mfDH7tFntg=.bf0a52ed-4f5d-4ab5-858b-dd1fbb635fbe@github.com>
Message-ID: 

On Wed, 7 May 2025 16:37:00 GMT, Weijun Wang  wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
>> 
>>  - major code review comments update
>>  - Merge branch 'master' into pem
>>  - Merge branch 'master' into pem
>>  - javadoc updates
>>  - code review comments
>>  - merge with master
>>  - better comment and remove commented out code
>>  - Merge branch 'master' into pem
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 60:
> 
>> 58:  *
>> 59: * >> 60: * A specified return class must implement {@link DEREncodable} and be an > > The `decode(data, Class)` method already requires the class be a `DEREncodable` otherwise it won't compile. So this is no longer a requirement for the caller and there is no need to say `must implement DEREncodable`. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 85: > >> 83: * 
>> 84:  *     PEMDecoder pd = PEMDecoder.of();
>> 85:  *     PrivateKey priKey = pd.decode(priKeyPEM);
> 
> `decode` does not return a `PrivateKey`. Either cast or specify the class.

I think I originally had that as 'var'. That allows it to compile for the sake of the example.  I wanted to show a simple example without getting into specifying a class.

> src/java.base/share/classes/java/security/PEMDecoder.java line 228:
> 
>> 226:      * 
This method will read the {@code InputStream} until PEM data is
>> 227:      * found or until the end of the stream.  Non-PEM data in the
>> 228:      * {@code InputStream} before the PEM header will be ignored by the decoder.
> 
> This is not precise because you might put the leading data into a `PEMRecord`.
> 
> Also, I think it's very important to point out the pointer position of the input stream after this method is successfully called. Otherwise, the method cannot be reliably used in extracting multiple PEMs from a single stream.
> 
> Also, I'm not exactly sure what happens when there is nothing more to read.

There is an inconsistency with PEMRecord here.  These methods should not allow leadingData if it is not available elsewhere.  I will redo that.  leadingData can be reserved for the decode methods that take a class.

I tried not to mention the pointer position.  My opinion is these methods should not have to describe the InputStream functionality.  I already state it returns a value after it finds PEM and I think one can figure this out.

> src/java.base/share/classes/java/security/PEMDecoder.java line 384:
> 
>> 382:     /**
>> 383:      * Configures and returns a new {@code PEMDecoder} instance from the
>> 384:      * current instance that will use KeyFactory and CertificateFactory classes
> 
> Put `KeyFactory` and `CertificateFactory` into ``.

probably should be a link, but yes.

> src/java.base/share/classes/java/security/PEMDecoder.java line 391:
> 
>> 389:      * the default provider configuration.
>> 390:      *
>> 391:      * @param provider the Factory provider.
> 
> s/Factory/factory/

yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078839155
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078854096
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078876015
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078960107
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078960615

From ascarpino at openjdk.org  Thu May  8 20:47:13 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 8 May 2025 20:47:13 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
Message-ID: 

On Wed, 7 May 2025 18:38:31 GMT, Sean Mullan  wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
>> 
>>  - major code review comments update
>>  - Merge branch 'master' into pem
>>  - Merge branch 'master' into pem
>>  - javadoc updates
>>  - code review comments
>>  - merge with master
>>  - better comment and remove commented out code
>>  - Merge branch 'master' into pem
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 68:
> 
>> 66:  * class is specified.
>> 67:  *
>> 68:  * 
 A new immutable {@code PEMDecoder} instance is created when configured
> 
> no need to say "immutable" as first sentence says all PEMDecoders are immutable.

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 71:
> 
>> 69:  * with {@linkplain #withFactory} and/or {@linkplain #withDecryption}.
>> 70:  * Configuring an instance for decryption does not prevent decoding with
>> 71:  * unencrypted PEM. Any encrypted PEM that does not use the configured password
> 
> I found the last 3 sentences a bit jumping too quickly into details. I suggest having 2 sentences after the first one, where each sentence explains what the `withDecryption` and `withFactory` methods do, respectively.

I split them and reworded it, HTH.

> src/java.base/share/classes/java/security/PEMDecoder.java line 92:
> 
>> 90:  * @spec https://www.rfc-editor.org/info/rfc7468
>> 91:  *       RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures
>> 92:  *
> 
> Might be useful to add an `@see PEMEncoder` (and vice-versa).

ok. I added a link

> src/java.base/share/classes/java/security/PEMDecoder.java line 228:
> 
>> 226:      * 
This method will read the {@code InputStream} until PEM data is
>> 227:      * found or until the end of the stream.  Non-PEM data in the
>> 228:      * {@code InputStream} before the PEM header will be ignored by the decoder.
> 
> s/will be/is/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 230:
> 
>> 228:      * {@code InputStream} before the PEM header will be ignored by the decoder.
>> 229:      * If only non-PEM data is found a {@link PEMRecord} is returned with that
>> 230:      * data.
> 
> Why? Shouldn't this be an exception as it isn't PEM?

I think you're right.

> src/java.base/share/classes/java/security/PEMDecoder.java line 252:
> 
>> 250:      * 

>> 251:      * {@code tClass} can be used to change the return type instance:
>> 252:      * 
    
> 
> This list feels more like programming advice. I would suggest either removing this, or putting it in the class description but not as a bulleted list, instead use complete sentences.

Rewriting sounds fine.

> src/java.base/share/classes/java/security/PEMDecoder.java line 399:
> 
>> 397: 
>> 398:     /**
>> 399:      * Returns a new {@code PEMDecoder} instance from the current instance
> 
> I find the words "a new instance from a current instance" a little unusual.
> 
> It might be simpler and clearer to say "Returns a copy of this PEMDecoder that will decrypt encrypted PEM data such as encrypted private keys with the specified password."
> 
> (I don't feel it is necessary to mention that it still also decodes unencrypted PEM - that seems implied to me).

The rewrite looks good, but I want to keep the comment about unencrypted PEM.  PEMEncoder only encrypts PrivateKey and rejects any other DEREncodable.  I think it's worth mentioning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078839633
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078849405
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078855537
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078876102
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078948310
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080055983
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2078969843

From ascarpino at openjdk.org  Thu May  8 20:47:14 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 8 May 2025 20:47:14 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <3zW-bAWD-IWkS_6VzPhThNpGybzvnOJQddZSmpCPZbQ=.af9efc29-b8b1-4860-8128-9a8f3088803d@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 <1NPCoy9RfTm6v7k1Nu3bjU-ntKn78gU3_mfDH7tFntg=.bf0a52ed-4f5d-4ab5-858b-dd1fbb635fbe@github.com>
 <3zW-bAWD-IWkS_6VzPhThNpGybzvnOJQddZSmpCPZbQ=.af9efc29-b8b1-4860-8128-9a8f3088803d@github.com>
Message-ID: 

On Wed, 7 May 2025 19:02:47 GMT, Sean Mullan  wrote:

>> src/java.base/share/classes/java/security/PEMDecoder.java line 118:
>> 
>>> 116:     /**
>>> 117:      * Returns an instance of {@code PEMDecoder}.  This instance may be repeatedly used
>>> 118:      * to decode different PEM text.
>> 
>> Not only repeatable, but also thread safe I assume? Maybe we need to talk about this in the class spec. Immutable does not automatic implies thread-safe, if the immutability is only observed on the API level.
>
> Usually there is a sentence at the end of the class description, ex- "This class is immutable and thread-safe." Once you state that, you don't need to say anything more in the methods like the sentence above about repeatability.

I added a line in the class doc and removed the line about repeatedly.

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

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

From mbalao at openjdk.org  Thu May  8 20:50:17 2025
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 8 May 2025 20:50:17 GMT
Subject: RFR: 8315487: Security Providers Filter [v23]
In-Reply-To: 
References: 
Message-ID: 

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 1268 commits:

 - 8315487: Security Providers Filter
   
   Co-authored-by: Francisco Ferrari Bihurriet 
   Co-authored-by: Martin Balao 
 - 8356126: Duplication handling and optimization of CaptureCallState
   
   Reviewed-by: jvernee
 - 8332934: Do loop with continue with subsequent switch leads to incorrect stack maps
   
   Reviewed-by: vromero
 - 8354461: Update tests to disable streaming output for attach tools
   
   Reviewed-by: sspitsyn, cjplummer
 - 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty
   
   Reviewed-by: ccheung, shade, kvn
 - 8356318: Unexpected VerifyError in AOT training run
   
   Reviewed-by: shade, kvn
 - 8356025: Provide a PrintVMInfoAtExit diagnostic switch
   
   Reviewed-by: mbaesken, jsikstro
 - 8347004: vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java fails with CDS disabled
   
   Reviewed-by: coleenp
 - 8354443: [Graal] crash after deopt in TestG1BarrierGeneration.java
   
   Reviewed-by: dnsimon, yzheng
 - 8355775: Improve symbolic sharing in dynamic constant pool entries
   
   Reviewed-by: asotona
 - ... and 1258 more: https://git.openjdk.org/jdk/compare/8c09d40d...37d3f23a

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

Changes: https://git.openjdk.org/jdk/pull/15539/files
  Webrev: Webrev is not available because diff is too large
  Stats: 506323 lines in 6824 files changed: 190010 ins; 280150 del; 36163 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

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

From fferrari at openjdk.org  Thu May  8 20:52:54 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 8 May 2025 20:52:54 GMT
Subject: RFR: 8315487: Security Providers Filter [v23]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:50:17 GMT, Martin Balao  wrote:

>> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
>> 
>> ## ProvidersFilter
>> 
>> ### Filter construction (parser)
>> 
>> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
>> 
>> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
>> 
>> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
>> 
>> ### Filter (structure and behavior)
>> 
>> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an all...
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 1268 commits:
> 
>  - 8315487: Security Providers Filter
>    
>    Co-authored-by: Francisco Ferrari Bihurriet 
>    Co-authored-by: Martin Balao 
>  - 8356126: Duplication handling and optimization of CaptureCallState
>    
>    Reviewed-by: jvernee
>  - 8332934: Do loop with continue with subsequent switch leads to incorrect stack maps
>    
>    Reviewed-by: vromero
>  - 8354461: Update tests to disable streaming output for attach tools
>    
>    Reviewed-by: sspitsyn, cjplummer
>  - 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty
>    
>    Reviewed-by: ccheung, shade, kvn
>  - 8356318: Unexpected VerifyError in AOT training run
>    
>    Reviewed-by: shade, kvn
>  - 8356025: Provide a PrintVMInfoAtExit diagnostic switch
>    
>    Reviewed-by: mbaesken, jsikstro
>  - 8347004: vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java fails with CDS disabled
>    
>    Reviewed-by: coleenp
>  - 8354443: [Graal] crash after deopt in TestG1BarrierGeneration.java
>    
>    Reviewed-by: dnsimon, yzheng
>  - 8355775: Improve symbolic sharing in dynamic constant pool entries
>    
>    Reviewed-by: asotona
>  - ... and 1258 more: https://git.openjdk.org/jdk/compare/8c09d40d...37d3f23a

New version pushed, independent from #22613.


    
Regression run of JDK-8315487 @ 37d3f23a3d6ef729ea715d86048f5c864456cd83 against master @ 8c1b915c7ef2b3a6e65705b91f4eb464caaec4e7


diff --git a/master at 8c1b915/report/text/summary.txt b/JDK-8315487 at 37d3f23/report/text/summary.txt
index fcbe7f8..7592229 100644
--- a/master at 8c1b915/report/text/summary.txt
+++ b/JDK-8315487 at 37d3f23/report/text/summary.txt
@@ -1,1202 +1,1203 @@
 com/sun/crypto/provider/AlgorithmParameters/EC/CurveGetParameterSpec.java                   Passed. Execution successful
 com/sun/crypto/provider/AlgorithmParameters/OAEPOrder.java                                  Passed. Execution successful
 com/sun/crypto/provider/CICO/CICOChainingTest.java                                          Passed. Execution successful
 com/sun/crypto/provider/CICO/CICODESFuncTest.java                                           Passed. Execution successful
 com/sun/crypto/provider/CICO/CICOSkipTest.java                                              Passed. Execution successful
 com/sun/crypto/provider/CICO/PBEFunc/CICOPBEFuncTest.java                                   Passed. Execution successful
 com/sun/crypto/provider/CICO/PBEFunc/CipherNCFuncTest.java                                  Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/AEADBufferTest.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/Encrypt.java                                            Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/GCMIncrementByte4.java                                  Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/GCMIncrementDirect4.java                                Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/GCMLargeDataKAT.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/GCMParameterSpecTest.java                               Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/GCMShortInput.java                                      Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/KeyWrapper.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/OverlapByteBuffer.java                                  Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/ReadWriteSkip.java                                      Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/SameBuffer.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/SealedObjectTest.java                                   Passed. Execution successful
 com/sun/crypto/provider/Cipher/AEAD/WrongAAD.java                                           Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/CICO.java                                                Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/CTR.java                                                 Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/Padding.java                                             Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/Test4511676.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/Test4512524.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/Test4512704.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/Test4513830.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/Test4517355.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/Test4626070.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestAESCipher.java                                       Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithDefaultProvider.java           Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithProviderChange.java            Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java         Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestCICOWithGCM.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestCICOWithGCMAndAAD.java                               Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestCopySafe.java                                        Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestGCMKeyAndIvCheck.java                                Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestGHASH.java                                           Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestISO10126Padding.java                                 Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestKATForECB_IV.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestKATForECB_VK.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestKATForECB_VT.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestKATForGCM.java                                       Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestNoPaddingModes.java                                  Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestNonexpanding.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestSameBuffer.java                                      Passed. Execution successful
 com/sun/crypto/provider/Cipher/AES/TestShortBuffer.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/Blowfish/BlowfishTestVector.java                             Passed. Execution successful
 com/sun/crypto/provider/Cipher/Blowfish/TestCipherBlowfish.java                             Passed. Execution successful
 com/sun/crypto/provider/Cipher/CTR/CounterMode.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/CTS/CTSMode.java                                             Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20KAT.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20KeyGeneratorTest.java                       Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20NoReuse.java                                Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20Poly1305ParamTest.java                      Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/OutputSizeTest.java                                 Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java                Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20Poly1305ParametersUnitTest.java    Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/unittest/Poly1305UnitTestDriver.java#id0            Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/unittest/Poly1305UnitTestDriver.java#id1            Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/unittest/Poly1305UnitTestDriver.java#id2            Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/unittest/Poly1305UnitTestDriver.java#id3            Passed. Execution successful
 com/sun/crypto/provider/Cipher/ChaCha20/unittest/Poly1305UnitTestDriver.java#id4            Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/DESKeyCleanupTest.java                                   Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/DESSecretKeySpec.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/DesAPITest.java                                          Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/DoFinalReturnLen.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/FlushBug.java                                            Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/KeyWrapping.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/PaddingTest.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/PerformanceTest.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/Sealtest.java                                            Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/TestCipherDES.java                                       Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/TestCipherDESede.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/DES/TextPKCS5PaddingTest.java                                Passed. Execution successful
 com/sun/crypto/provider/Cipher/JCE/Bugs/4686632/Empty.java                                  Passed. Execution successful
 com/sun/crypto/provider/Cipher/KeyWrap/NISTWrapKAT.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/KeyWrap/TestCipherKeyWrapperTest.java                        Passed. Execution successful
 com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/KeyWrap/TestKeySizeCheck.java                                Passed. Execution successful
 com/sun/crypto/provider/Cipher/KeyWrap/XMLEncKAT.java                                       Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/CheckPBEKeySize.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/DecryptWithoutParameters.java                            Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/NegativeLength.java                                      Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBEInvalidParamsTest.java                                Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBEKeyCleanupTest.java                                   Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBEKeyTest.java                                          Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBEKeysAlgorithmNames.java                               Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBEParametersTest.java                                   Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBES2Test.java                                           Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBESameBuffer/PBESameBuffer.java                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBESealedObject.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBKDF2Translate.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBMacBuffer.java                                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PBMacDoFinalVsUpdate.java                                Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PKCS12Cipher.java                                        Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PKCS12CipherKAT.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/PKCS12Oid.java                                           Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/TestCipherKeyWrapperPBEKey.java                          Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/TestCipherPBE.java                                       Passed. Execution successful
 com/sun/crypto/provider/Cipher/PBE/TestCipherPBECons.java                                   Passed. Execution successful
 com/sun/crypto/provider/Cipher/RC2ArcFour/CipherKAT.java                                    Passed. Execution successful
 com/sun/crypto/provider/Cipher/RSA/TestOAEP.java                                            Passed. Execution successful
 com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java                                     Passed. Execution successful
 com/sun/crypto/provider/Cipher/RSA/TestOAEPParameterSpec.java                               Passed. Execution successful
 com/sun/crypto/provider/Cipher/RSA/TestOAEPWithParams.java                                  Passed. Execution successful
 com/sun/crypto/provider/Cipher/RSA/TestOAEP_KAT.java                                        Passed. Execution successful
 com/sun/crypto/provider/Cipher/RSA/TestRSA.java                                             Passed. Execution successful
 com/sun/crypto/provider/Cipher/Test4958071.java                                             Passed. Execution successful
 com/sun/crypto/provider/Cipher/TextLength/SameBufferOverwrite.java                          Passed. Execution successful
 com/sun/crypto/provider/Cipher/TextLength/TestCipherTextLength.java                         Passed. Execution successful
 com/sun/crypto/provider/Cipher/UTIL/StrongOrUnlimited.java                                  Passed. Execution successful
 com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java                                  Passed. Execution successful
 com/sun/crypto/provider/DHKEM/Compliance.java                                               Passed. Execution successful
 com/sun/crypto/provider/DHKEM/NameSensitiveness.java                                        Passed. Execution successful
 com/sun/crypto/provider/KDF/HKDFBasicFunctionsTest.java                                     Passed. Execution successful
 com/sun/crypto/provider/KDF/HKDFDelayedPRK.java                                             Passed. Execution successful
 com/sun/crypto/provider/KDF/HKDFExhaustiveTest.java                                         Passed. Execution successful
 com/sun/crypto/provider/KDF/HKDFKnownAnswerTests.java                                       Passed. Execution successful
 com/sun/crypto/provider/KDF/HKDFSaltIKMTest.java                                            Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/DHGenSharedSecret.java                                 Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/DHKeyAgreement2.java                                   Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/DHKeyAgreement3.java                                   Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/DHKeyAgreementPadding.java                             Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/DHKeyFactory.java                                      Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/DHKeyGenSpeed.java                                     Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/ECKeyCheck.java                                        Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/SameDHKeyStressTest.java                               Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/SupportedDHKeys.java                                   Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java                              Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/SupportedDHParamGensLongKey.java                       Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/TestExponentSize.java                                  Passed. Execution successful
 com/sun/crypto/provider/KeyAgreement/UnsupportedDHKeys.java                                 Passed. Execution successful
 com/sun/crypto/provider/KeyFactory/PBEKeyDestroyTest.java                                   Passed. Execution successful
 com/sun/crypto/provider/KeyFactory/PBKDF2HmacSHA1FactoryTest.java                           Passed. Execution successful
 com/sun/crypto/provider/KeyFactory/TestProviderLeak.java                                    Passed. Execution successful
 com/sun/crypto/provider/KeyGenerator/Test4628062.java                                       Passed. Execution successful
 com/sun/crypto/provider/KeyGenerator/Test6227536.java                                       Passed. Execution successful
 com/sun/crypto/provider/KeyGenerator/TestExplicitKeyLength.java                             Passed. Execution successful
 com/sun/crypto/provider/KeyProtector/IterationCount.java                                    Passed. Execution successful
 com/sun/crypto/provider/Mac/DigestCloneabilityTest.java                                     Passed. Execution successful
 com/sun/crypto/provider/Mac/EmptyByteBufferTest.java                                        Passed. Execution successful
 com/sun/crypto/provider/Mac/HmacMD5.java                                                    Passed. Execution successful
 com/sun/crypto/provider/Mac/HmacPBESHA1.java                                                Passed. Execution successful
 com/sun/crypto/provider/Mac/HmacSHA512.java                                                 Passed. Execution successful
 com/sun/crypto/provider/Mac/HmacSaltLengths.java                                            Passed. Execution successful
 com/sun/crypto/provider/Mac/LargeByteBufferTest.java                                        Passed. Execution successful
 com/sun/crypto/provider/Mac/MacClone.java                                                   Passed. Execution successful
 com/sun/crypto/provider/Mac/MacKAT.java                                                     Passed. Execution successful
 com/sun/crypto/provider/Mac/MacSameTest.java                                                Passed. Execution successful
 com/sun/crypto/provider/Mac/NullByteBufferTest.java                                         Passed. Execution successful
 com/sun/crypto/provider/Mac/Test6205692.java                                                Passed. Execution successful
 com/sun/crypto/provider/NSASuiteB/TestAESOids.java                                          Passed. Execution successful
 com/sun/crypto/provider/NSASuiteB/TestAESWrapOids.java                                      Passed. Execution successful
 com/sun/crypto/provider/NSASuiteB/TestHmacSHAOids.java                                      Passed. Execution successful
 com/sun/crypto/provider/TLS/TestKeyMaterial.java                                            Passed. Execution successful
 com/sun/crypto/provider/TLS/TestLeadingZeroes.java                                          Passed. Execution successful
 com/sun/crypto/provider/TLS/TestMasterSecret.java                                           Passed. Execution successful
 com/sun/crypto/provider/TLS/TestPRF.java                                                    Passed. Execution successful
 com/sun/crypto/provider/TLS/TestPRF12.java                                                  Passed. Execution successful
 com/sun/crypto/provider/TLS/TestPremaster.java                                              Passed. Execution successful
 java/security/AccessControlContext/CheckCtor.java                                           Passed. Execution successful
 java/security/AccessControlContext/NullCombinerEquals.java                                  Passed. Execution successful
 java/security/AccessController/PreserveCombiner.java                                        Passed. Execution successful
 java/security/AsymmetricKey/GetParams.java                                                  Passed. Execution successful
 java/security/BasicPermission/BasicPermissionCollection.java                                Passed. Execution successful
 java/security/BasicPermission/EqualsImplies.java                                            Passed. Execution successful
 java/security/BasicPermission/ExitVMEquals.java                                             Passed. Execution successful
 java/security/BasicPermission/Homogeneity.java                                              Passed. Execution successful
 java/security/BasicPermission/MixedBasicPermissions.java                                    Passed. Execution successful
 java/security/BasicPermission/NullOrEmptyName.java                                          Passed. Execution successful
 java/security/BasicPermission/PermClass.java                                                Passed. Execution successful
 java/security/BasicPermission/SerialVersion.java                                            Passed. Execution successful
 java/security/BasicPermission/Wildcard.java                                                 Passed. Execution successful
 java/security/CodeSigner/Serialize.java                                                     Passed. Execution successful
 java/security/CodeSource/CertsMatch.java                                                    Passed. Execution successful
 java/security/CodeSource/Implies.java                                                       Passed. Execution successful
 java/security/DigestInputStream/TestSkipAndReset.java                                       Passed. Execution successful
 java/security/Exceptions/ChainingConstructors.java                                          Passed. Execution successful
 java/security/Identity/EqualsHashCodeContract.java                                          Passed. Execution successful
 java/security/IdentityScope/NoDefaultSystemScope.java                                       Passed. Execution successful
 java/security/KeyAgreement/Generic.java                                                     Passed. Execution successful
 java/security/KeyAgreement/KeyAgreementTest.java                                            Passed. Execution successful
 java/security/KeyAgreement/KeySizeTest.java                                                 Passed. Execution successful
 java/security/KeyAgreement/KeySpecTest.java                                                 Passed. Execution successful
 java/security/KeyAgreement/MultiThreadTest.java                                             Passed. Execution successful
 java/security/KeyAgreement/NegativeTest.java                                                Passed. Execution successful
 java/security/KeyFactory/Failover.java                                                      Passed. Execution successful
 java/security/KeyFactory/GenerateRSAPrivateCrtKey.java                                      Passed. Execution successful
 java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java                            Passed. Execution successful
 java/security/KeyPairGenerator/Failover.java                                                Passed. Execution successful
 java/security/KeyPairGenerator/FinalizeHalf.java                                            Passed. Execution successful
 java/security/KeyPairGenerator/GenerateKeypair.java                                         Passed. Execution successful
 java/security/KeyPairGenerator/GenerateRSAKeyPair.java                                      Passed. Execution successful
 java/security/KeyRep/Serial.java                                                            Passed. Execution successful
 java/security/KeyRep/SerialDSAPubKey.java                                                   Passed. Execution successful
 java/security/KeyRep/SerialOld.java                                                         Passed. Execution successful
 java/security/KeyStore/CheckInputStream.java                                                Passed. Execution successful
 java/security/KeyStore/DefaultEntryType.java                                                Passed. Execution successful
 java/security/KeyStore/EntryMethods.java                                                    Passed. Execution successful
 java/security/KeyStore/KeyStoreBuilder.java                                                 Passed. Execution successful
 java/security/KeyStore/OneProbeOneNot.java                                                  Passed. Execution successful
 java/security/KeyStore/PBETest.java                                                         Passed. Execution successful
 java/security/KeyStore/PKCS12/CheckDefaults.java                                            Passed. Execution successful
 java/security/KeyStore/PKCS12/CheckNullDefault.java                                         Passed. Execution successful
 java/security/KeyStore/PKCS12/ConvertP12Test.java                                           Passed. Execution successful
 java/security/KeyStore/PKCS12/EntryProtectionTest.java                                      Passed. Execution successful
 java/security/KeyStore/PKCS12/KeytoolReaderP12Test.java                                     Passed. Execution successful
 java/security/KeyStore/PKCS12/KeytoolWriteP12Test.java                                      Passed. Execution successful
 java/security/KeyStore/PKCS12/MetadataEmptyTest.java                                        Passed. Execution successful
 java/security/KeyStore/PKCS12/MetadataStoreLoadTest.java                                    Passed. Execution successful
 java/security/KeyStore/PKCS12/ReadP12Test.java                                              Passed. Execution successful
 java/security/KeyStore/PKCS12/StoreTrustedCertAPITest.java                                  Passed. Execution successful
 java/security/KeyStore/PKCS12/StoreTrustedCertKeytool.java                                  Passed. Execution successful
 java/security/KeyStore/PKCS12/UnmodifiableAttributes.java                                   Passed. Execution successful
 java/security/KeyStore/PKCS12/WriteP12Test.java                                             Passed. Execution successful
 java/security/KeyStore/ProbeKeystores.java                                                  Passed. Execution successful
 java/security/KeyStore/TestKeyStoreBasic.java                                               Passed. Execution successful
 java/security/KeyStore/TestKeyStoreEntry.java                                               Passed. Execution successful
 java/security/MessageDigest/ArgumentSanity.java                                             Passed. Execution successful
 java/security/MessageDigest/ByteBuffers.java                                                Passed. Execution successful
 java/security/MessageDigest/TestCloneable.java                                              Passed. Execution successful
 java/security/MessageDigest/TestDigestIOStream.java                                         Passed. Execution successful
 java/security/MessageDigest/TestSameLength.java                                             Passed. Execution successful
 java/security/MessageDigest/TestSameValue.java                                              Passed. Execution successful
 java/security/MessageDigest/ThreadSafetyTest.java                                           Passed. Execution successful
 java/security/PKCS12Attribute/HashCode.java                                                 Passed. Execution successful
 java/security/Permission/NullName.java                                                      Passed. Execution successful
 java/security/Permission/ToString.java                                                      Passed. Execution successful
 java/security/PermissionCollection/AddToReadOnlyPermissionCollection.java                   Passed. Execution successful
 java/security/PermissionCollection/Concurrent.java                                          Passed. Execution successful
 java/security/PermissionCollection/PermissionCollectionStreamTest.java                      Passed. Execution successful
 java/security/Permissions/DeserializeInvalidPermissions.java                                Passed. Execution successful
 java/security/Principal/Implies.java                                                        Passed. Execution successful
 java/security/PrivilegedActionException/PrintWrappedException.java                          Passed. Execution successful
 java/security/ProtectionDomain/CheckWhatYouGet.java                                         Passed. Execution successful
 java/security/ProtectionDomain/NullPerms.java                                               Passed. Execution successful
 java/security/Provider/CaseSensitiveServices.java                                           Passed. Execution successful
 java/security/Provider/CertStoreConstructorParam.java                                       Passed. Execution successful
 java/security/Provider/ChangeProviders.java                                                 Passed. Execution successful
 java/security/Provider/DefaultProviderList.java                                             Passed. Execution successful
 java/security/Provider/Equals.java                                                          Passed. Execution successful
 java/security/Provider/GetInstance.java                                                     Passed. Execution successful
 java/security/Provider/GetServiceRace.java                                                  Passed. Execution successful
 java/security/Provider/InvalidServiceTest.java                                              Passed. Execution successful
 java/security/Provider/NewInstance.java                                                     Passed. Execution successful
 java/security/Provider/ProviderInfoCheck.java                                               Passed. Execution successful
 java/security/Provider/ProviderVersionCheck.java                                            Passed. Execution successful
 java/security/Provider/RemoveProvider.java                                                  Passed. Execution successful
 java/security/Provider/SecurityProviderModularTest.java                                     Passed. Execution successful
 java/security/Provider/SupportsParameter.java                                               Passed. Execution successful
 java/security/Provider/Turkish.java                                                         Passed. Execution successful
 java/security/SecureClassLoader/DefineClassByteBuffer.java                                  Passed. Execution successful
 java/security/SecureRandom/ApiTest.java                                                     Passed. Execution successful
 java/security/SecureRandom/DefaultAlgo.java                                                 Passed. Execution successful
 java/security/SecureRandom/DefaultProvider.java                                             Passed. Execution successful
 java/security/SecureRandom/DrbgParametersSpec.java                                          Passed. Execution successful
 java/security/SecureRandom/EnoughSeedTest.java                                              Passed. Execution successful
 java/security/SecureRandom/GetAlgorithm.java                                                Passed. Execution successful
 java/security/SecureRandom/GetInstanceTest.java                                             Passed. Execution successful
 java/security/SecureRandom/MultiThreadTest.java                                             Passed. Execution successful
 java/security/SecureRandom/NextBytesNull.java                                               Passed. Execution successful
 java/security/SecureRandom/NoSync.java                                                      Passed. Execution successful
 java/security/SecureRandom/Serialize.java                                                   Passed. Execution successful
 java/security/SecureRandom/SerializedSeedTest.java                                          Passed. Execution successful
 java/security/SecureRandom/ThreadSafe.java                                                  Passed. Execution successful
 java/security/Security/CaseInsensitiveAlgNames.java                                         Passed. Execution successful
 java/security/Security/ClassLoader/DeprivilegedModuleLoaderTest.java                        Passed. Execution successful
 java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java                         Passed. Execution successful
 java/security/Security/ClassLoaderDeadlock/Deadlock.java                                    Passed. Execution successful
 java/security/Security/ConfigFileTest.java                                                  Passed. Execution successful
 java/security/Security/NoInstalledProviders.java                                            Passed. Execution successful
 java/security/Security/Nulls.java                                                           Passed. Execution successful
 java/security/Security/ProviderFiltering.java                                               Passed. Execution successful
 java/security/Security/SecurityPropFile/SecurityPropFile.java                               Passed. Execution successful
 java/security/Security/SynchronizedAccess.java                                              Passed. Execution successful
 java/security/Security/removing/RemoveProviderByIdentity.java                               Passed. Execution successful
 java/security/Security/removing/RemoveProviders.java                                        Passed. Execution successful
 java/security/Security/removing/RemoveStaticProvider.java                                   Passed. Execution successful
 java/security/Security/signedfirst/DynStatic.java                                           Passed. Execution successful
 java/security/Signature/ByteBuffers.java                                                    Passed. Execution successful
 java/security/Signature/NONEwithRSA.java                                                    Passed. Execution successful
 java/security/Signature/NoProvider.java                                                     Passed. Execution successful
 java/security/Signature/Offsets.java                                                        Passed. Execution successful
 java/security/Signature/ResetAfterException.java                                            Passed. Execution successful
 java/security/Signature/SignWithOutputBuffer.java                                           Passed. Execution successful
 java/security/Signature/SignatureGetAlgorithm.java                                          Passed. Execution successful
 java/security/Signature/SignatureGetInstance.java                                           Passed. Execution successful
 java/security/Signature/SignatureLength.java                                                Passed. Execution successful
 java/security/Signature/TestCloneable.java                                                  Passed. Execution successful
 java/security/Signature/TestInitSignWithMyOwnRandom.java                                    Passed. Execution successful
 java/security/Signature/VerifyRangeCheckOverflow.java                                       Passed. Execution successful
 java/security/SignedJar/SignedJarWithCustomClassLoader.java                                 Passed. Execution successful
 java/security/SignedJar/spi-calendar-provider/TestSPISigned.java                            Passed. Execution successful
 java/security/SignedObject/Chain.java                                                       Passed. Execution successful
 java/security/SignedObject/Copy.java                                                        Passed. Execution successful
 java/security/SignedObject/Correctness.java                                                 Passed. Execution successful
 java/security/UnresolvedPermission/AccessorMethods.java                                     Passed. Execution successful
 java/security/cert/CertPath/Serialize.java                                                  Passed. Execution successful
 java/security/cert/CertPathBuilder/GetInstance.java                                         Passed. Execution successful
 java/security/cert/CertPathBuilder/NoExtensions.java                                        Passed. Execution successful
 java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java                              Passed. Execution successful
 java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java                        Passed. Execution successful
 java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java                          Passed. Execution successful
 java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java                     Passed. Execution successful
 java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java           Passed. Execution successful
 java/security/cert/CertPathBuilder/targetConstraints/BuildOddSel.java                       Passed. Execution successful
 java/security/cert/CertPathBuilder/zeroLengthPath/ZeroLengthPath.java                       Passed. Execution successful
 java/security/cert/CertPathEncodingTest.java                                                Passed. Execution successful
 java/security/cert/CertPathValidator/OCSP/AIACheck.java                                     Passed. Execution successful
 java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java                                Passed. Execution successful
 java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java                              Passed. Execution successful
 java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java                                  Passed. Execution successful
 java/security/cert/CertPathValidator/crlDP/CheckAllCRLs.java                                Passed. Execution successful
 java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java                   Passed. Execution successful
 java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java            Passed. Execution successful
 java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java                   Passed. Execution successful
 java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java            Passed. Execution successful
 java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java            Passed. Execution successful
 java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java  Passed. Execution successful
 java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java         Passed. Execution successful
 java/security/cert/CertPathValidator/nameConstraintsRFC822/ValidateCertPath.java            Passed. Execution successful
 java/security/cert/CertPathValidator/targetConstraints/ValidateTargetConstraints.java       Passed. Execution successful
 java/security/cert/CertPathValidator/trustAnchor/ValWithAnchorByName.java                   Passed. Execution successful
 java/security/cert/CertPathValidator/trustAnchor/ValidateNC.java                            Passed. Execution successful
 java/security/cert/CertPathValidatorException/GetMessage.java                               Passed. Execution successful
 java/security/cert/CertPathValidatorException/ReasonTest.java                               Passed. Execution successful
 java/security/cert/CertPathValidatorException/Serial.java                                   Passed. Execution successful
 java/security/cert/CertStore/NoLDAP.java                                                    Passed. Execution successful
 java/security/cert/CertificateFactory/BadX509CertData.java                                  Passed. Execution successful
 java/security/cert/CertificateFactory/GenerateCertificatesEmptyCollection.java              Passed. Execution successful
 java/security/cert/CertificateFactory/ReturnStream.java                                     Passed. Execution successful
 java/security/cert/CertificateFactory/invalidEncodedCerts/DetectInvalidEncoding.java        Passed. Execution successful
 java/security/cert/CertificateFactory/openssl/BadFooter.java                                Passed. Execution successful
 java/security/cert/CertificateFactory/openssl/OpenSSLCert.java                              Passed. Execution successful
 java/security/cert/CertificateFactory/slowstream.sh                                         Passed. Execution successful
 java/security/cert/CertificateRevokedException/Basic.java                                   Passed. Execution successful
 java/security/cert/GetInstance.java                                                         Passed. Execution successful
 java/security/cert/PKIXBuilderParameters/InvalidParameters.java                             Passed. Execution successful
 java/security/cert/PKIXParameters/InvalidParameters.java                                    Passed. Execution successful
 java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java                              Passed. Execution successful
 java/security/cert/PKIXRevocationChecker/UnitTest.java                                      Passed. Execution successful
 java/security/cert/PolicyNode/GetPolicyQualifiers.java                                      Passed. Execution successful
 java/security/cert/URICertStoreParameters/TestBasic.java                                    Passed. Execution successful
 java/security/cert/X509CRL/VerifyDefault.java                                               Passed. Execution successful
 java/security/cert/X509CRLSelector/CRLNumberMissing.java                                    Passed. Execution successful
 java/security/cert/X509CertSelector/SetNameConstraintsEmptySequence.java                    Passed. Execution successful
 java/security/cert/X509CertSelectorTest.java                                                Passed. Execution successful
 java/security/cert/X509Certificate/EmptySubject.java                                        Passed. Execution successful
 java/security/cert/X509Certificate/ExtKeyUsage.java                                         Passed. Execution successful
 java/security/cert/X509Certificate/GetSigAlgParams.java                                     Passed. Execution successful
 java/security/cert/X509Certificate/GetUnparseableExtensions.java                            Passed. Execution successful
 java/security/cert/X509Certificate/VerifyDefault.java                                       Passed. Execution successful
 java/security/cert/X509Certificate/X509BadCertificate.java                                  Passed. Execution successful
 java/security/cert/pkix/nameConstraintsMinMax/VerifyNameConstraints.java                    Passed. Execution successful
 java/security/cert/pkix/policyChanges/TestPolicy.java                                       Passed. Execution successful
 java/security/misc/GetInstanceNullsEmpties.java                                             Passed. Execution successful
 java/security/misc/TestDefaultRandom.java                                                   Passed. Execution successful
 java/security/misc/Versions.java                                                            Passed. Execution successful
 java/security/spec/ECCBasic.java                                                            Passed. Execution successful
 java/security/spec/EllipticCurveMatch.java                                                  Passed. Execution successful
 java/security/spec/IsAssignableFromOrder.java                                               Passed. Execution successful
 java/security/spec/PKCS8EncodedKeySpec/Algorithm.java                                       Passed. Execution successful
 java/security/spec/RC2ParameterSpec/InvalidArrayIndex.java                                  Passed. Execution successful
 java/security/spec/TestNamedParameterSpec.java                                              Passed. Execution successful
 sun/security/ec/ECDHKeyAgreementParamValidation.java                                        Passed. Execution successful
 sun/security/ec/ECDHPrimitive.java                                                          Passed. Execution successful
 sun/security/ec/ECDSAPrimitive.java                                                         Passed. Execution successful
 sun/security/ec/ECDSAPrvGreaterThanOrder.java                                               Passed. Execution successful
 sun/security/ec/InvalidCurve.java                                                           Passed. Execution successful
 sun/security/ec/NSASuiteB/TestSHAwithECDSASignatureOids.java                                Passed. Execution successful
 sun/security/ec/OidInstance.java                                                            Passed. Execution successful
 sun/security/ec/SignatureDigestTruncate.java                                                Passed. Execution successful
 sun/security/ec/SignatureKAT.java                                                           Passed. Execution successful
 sun/security/ec/SignatureOffsets.java                                                       Passed. Execution successful
 sun/security/ec/SignatureParameters.java                                                    Passed. Execution successful
 sun/security/ec/SignedObjectChain.java                                                      Passed. Execution successful
 sun/security/ec/TestEC.java                                                                 Passed. Execution successful
 sun/security/ec/ecModuleCheck.java                                                          Passed. Execution successful
 sun/security/ec/ed/EdCRLSign.java                                                           Passed. Execution successful
 sun/security/ec/ed/EdDSAKeyCompatibility.java                                               Passed. Execution successful
 sun/security/ec/ed/EdDSAKeySize.java                                                        Passed. Execution successful
 sun/security/ec/ed/EdDSANegativeTest.java                                                   Passed. Execution successful
 sun/security/ec/ed/EdDSAParamSpec.java                                                      Passed. Execution successful
 sun/security/ec/ed/EdDSAReuseTest.java                                                      Passed. Execution successful
 sun/security/ec/ed/EdDSATest.java                                                           Passed. Execution successful
 sun/security/ec/ed/EdECKeyFormat.java                                                       Passed. Execution successful
 sun/security/ec/ed/EmptyMessage.java                                                        Passed. Execution successful
 sun/security/ec/ed/TestEdDSA.java                                                           Passed. Execution successful
 sun/security/ec/ed/TestEdOps.java                                                           Passed. Execution successful
 sun/security/ec/xec/TestXDH.java                                                            Passed. Execution successful
 sun/security/ec/xec/TestXECOps.java                                                         Passed. Execution successful
 sun/security/ec/xec/XECIterative.java                                                       Passed. Execution successful
 sun/security/ec/xec/XECKeyFormat.java                                                       Passed. Execution successful
 sun/security/jca/NullPreferredList.java                                                     Passed. Execution successful
 sun/security/jca/PreferredProviderNegativeTest.java                                         Passed. Execution successful
 sun/security/jca/PreferredProviderTest.java                                                 Passed. Execution successful
 sun/security/jgss/CtorTests2.java                                                           Passed. Execution successful
 sun/security/jgss/DefaultGssConfig.java                                                     Passed. Execution successful
 sun/security/jgss/GssContextCleanup.java                                                    Passed. Execution successful
 sun/security/jgss/GssMemoryIssues.java                                                      Passed. Execution successful
 sun/security/jgss/GssNPE.java                                                               Passed. Execution successful
 sun/security/jgss/GssNameCleanup.java                                                       Passed. Execution successful
 sun/security/jgss/spnego/MSOID.java                                                         Passed. Execution successful
 sun/security/jgss/spnego/MechTokenMissing.java                                              Passed. Execution successful
 sun/security/jgss/spnego/NegTokenTargFields.java                                            Passed. Execution failed as expected
 sun/security/jgss/spnego/NoSpnegoAsDefMech.java                                             Passed. Execution successful
 sun/security/jgss/spnego/NotPreferredMech.java                                              Passed. Execution successful
 sun/security/krb5/BadKdcDefaultValue.java                                                   Passed. Execution successful
 sun/security/krb5/ErrorMessages.java                                                        Passed. Execution successful
 sun/security/krb5/IPv6.java                                                                 Passed. Execution successful
 sun/security/krb5/Krb5NameEquals.java                                                       Passed. Execution successful
 sun/security/krb5/KrbCredSubKey.java                                                        Passed. Execution successful
 sun/security/krb5/MicroTime.java                                                            Passed. Execution successful
 sun/security/krb5/NegativeNonce.java                                                        Passed. Execution successful
 sun/security/krb5/NullStringToKey.java                                                      Passed. Execution successful
 sun/security/krb5/OptionPADataInKDCReq.java                                                 Passed. Execution successful
 sun/security/krb5/RFC396xTest.java                                                          Passed. Execution successful
 sun/security/krb5/ServiceCredsCombination.java                                              Passed. Execution successful
 sun/security/krb5/TestPAData.java                                                           Passed. Execution successful
 sun/security/krb5/UnknownCCEntry.java                                                       Passed. Execution successful
 sun/security/krb5/auto/AcceptorSubKey.java                                                  Passed. Execution successful
 sun/security/krb5/auto/Addresses.java                                                       Passed. Execution successful
 sun/security/krb5/auto/AddressesAndNameType.java                                            Passed. Execution successful
 sun/security/krb5/auto/AlwaysEncPaReq.java                                                  Passed. Execution successful
 sun/security/krb5/auto/Basic.java                                                           Passed. Execution successful
 sun/security/krb5/auto/BasicKrb5Test.java                                                   Passed. Execution successful
 sun/security/krb5/auto/BasicProc.java                                                       Passed. Execution successful
 sun/security/krb5/auto/BogusKDC.java                                                        Passed. Execution successful
 sun/security/krb5/auto/CaseSensitive.java                                                   Passed. Execution successful
 sun/security/krb5/auto/CleanState.java                                                      Passed. Execution successful
 sun/security/krb5/auto/Cleaners.java                                                        Passed. Execution successful
 sun/security/krb5/auto/CrossRealm.java                                                      Passed. Execution successful
 sun/security/krb5/auto/DiffNameSameKey.java                                                 Passed. Execution successful
 sun/security/krb5/auto/DiffSaltParams.java                                                  Passed. Execution successful
 sun/security/krb5/auto/DnsCanonicalizeHostname.java                                         Passed. Execution successful
 sun/security/krb5/auto/DupEtypes.java                                                       Passed. Execution successful
 sun/security/krb5/auto/DynamicKeytab.java                                                   Passed. Execution successful
 sun/security/krb5/auto/EmptyPassword.java                                                   Passed. Execution successful
 sun/security/krb5/auto/FileKeyTab.java                                                      Passed. Execution successful
 sun/security/krb5/auto/ForwardableCheck.java                                                Passed. Execution successful
 sun/security/krb5/auto/Forwarded.java                                                       Passed. Execution successful
 sun/security/krb5/auto/GSS.java                                                             Passed. Execution successful
 sun/security/krb5/auto/GSSUnbound.java                                                      Passed. Execution successful
 sun/security/krb5/auto/HttpNegotiateServer.java                                             Passed. Execution successful
 sun/security/krb5/auto/HttpsCB.java                                                         Passed. Execution successful
 sun/security/krb5/auto/IgnoreChannelBinding.java                                            Passed. Execution successful
 sun/security/krb5/auto/KPEquals.java                                                        Passed. Execution successful
 sun/security/krb5/auto/KdcPolicy.java                                                       Passed. Execution successful
 sun/security/krb5/auto/KeyTabCompat.java                                                    Passed. Execution successful
 sun/security/krb5/auto/KrbTicket.java                                                       Passed. Execution successful
 sun/security/krb5/auto/KvnoNA.java                                                          Passed. Execution successful
 sun/security/krb5/auto/LifeTimeInSeconds.java                                               Passed. Execution successful
 sun/security/krb5/auto/LoginModuleDebug.java                                                Passed. Execution successful
 sun/security/krb5/auto/LoginModuleOptions.java                                              Passed. Execution successful
 sun/security/krb5/auto/LoginNoPass.java                                                     Passed. Execution successful
 sun/security/krb5/auto/LongLife.java                                                        Passed. Execution successful
 sun/security/krb5/auto/MSOID2.java                                                          Passed. Execution successful
 sun/security/krb5/auto/ModuleName.java                                                      Passed. Execution successful
 sun/security/krb5/auto/MoreKvno.java                                                        Passed. Execution successful
 sun/security/krb5/auto/NewInquireTypes.java                                                 Passed. Execution successful
 sun/security/krb5/auto/NewSalt.java                                                         Passed. Execution successful
 sun/security/krb5/auto/NoAddresses.java                                                     Passed. Execution failed as expected
 sun/security/krb5/auto/NoInitNoKeytab.java                                                  Passed. Execution successful
 sun/security/krb5/auto/NonAscii.java                                                        Passed. Execution failed as expected
 sun/security/krb5/auto/NonMutualSpnego.java                                                 Passed. Execution successful
 sun/security/krb5/auto/NoneReplayCacheTest.java                                             Passed. Execution successful
 sun/security/krb5/auto/NullRenewUntil.java                                                  Passed. Execution successful
 sun/security/krb5/auto/OkAsDelegate.java                                                    Passed. Execution successful
 sun/security/krb5/auto/OkAsDelegateXRealm.java                                              Passed. Execution successful
 sun/security/krb5/auto/OnlyDesLogin.java                                                    Passed. Execution successful
 sun/security/krb5/auto/PrincipalNameEquals.java                                             Passed. Execution successful
 sun/security/krb5/auto/RRC.java                                                             Passed. Execution successful
 sun/security/krb5/auto/RealmSpecificValues.java                                             Passed. Execution successful
 sun/security/krb5/auto/ReferralsTest.java                                                   Passed. Execution successful
 sun/security/krb5/auto/RefreshKrb5Config.java                                               Passed. Execution successful
 sun/security/krb5/auto/Renew.java                                                           Passed. Execution successful
 sun/security/krb5/auto/Renewal.java                                                         Passed. Execution successful
 sun/security/krb5/auto/ReplayCacheExpunge.java                                              Passed. Execution failed as expected
 sun/security/krb5/auto/ReplayCachePrecise.java                                              Passed. Execution successful
 sun/security/krb5/auto/ReplayCacheTest.java                                                 Passed. Execution successful
 sun/security/krb5/auto/ReplayCacheTestProc.java                                             Passed. Execution successful
 sun/security/krb5/auto/ReplayCacheTestProcWithMD5.java                                      Passed. Execution successful
 sun/security/krb5/auto/S4U2proxy.java                                                       Passed. Execution successful
 sun/security/krb5/auto/S4U2proxyGSS.java                                                    Passed. Execution successful
 sun/security/krb5/auto/S4U2self.java                                                        Passed. Execution successful
 sun/security/krb5/auto/S4U2selfAsServer.java                                                Passed. Execution successful
 sun/security/krb5/auto/S4U2selfAsServerGSS.java                                             Passed. Execution successful
 sun/security/krb5/auto/S4U2selfGSS.java                                                     Passed. Execution successful
 sun/security/krb5/auto/S4U2selfNotF.java                                                    Passed. Execution successful
 sun/security/krb5/auto/SPNEGO.java                                                          Passed. Execution successful
 sun/security/krb5/auto/SaslBasic.java                                                       Passed. Execution successful
 sun/security/krb5/auto/SaslMutual.java                                                      Passed. Execution successful
 sun/security/krb5/auto/SaslUnbound.java                                                     Passed. Execution failed as expected
 sun/security/krb5/auto/SpnegoLifeTime.java                                                  Passed. Execution successful
 sun/security/krb5/auto/SpnegoReqFlags.java                                                  Passed. Execution successful
 sun/security/krb5/auto/SpnegoUnknownMech.java                                               Passed. Execution failed as expected
 sun/security/krb5/auto/Test5653.java                                                        Passed. Execution successful
 sun/security/krb5/auto/TicketSName.java                                                     Passed. Execution successful
 sun/security/krb5/auto/TwoOrThree.java                                                      Passed. Execution failed as expected
 sun/security/krb5/auto/TwoPrinces.java                                                      Passed. Execution successful
 sun/security/krb5/auto/TwoTab.java                                                          Passed. Execution successful
 sun/security/krb5/auto/Unavailable.java                                                     Passed. Execution successful
 sun/security/krb5/auto/UnboundService.java                                                  Passed. Execution failed as expected
 sun/security/krb5/auto/Unreachable.java                                                     Passed. Execution successful
 sun/security/krb5/auto/UseCacheAndStoreKey.java                                             Passed. Execution successful
 sun/security/krb5/auto/W83.java                                                             Passed. Execution successful
 sun/security/krb5/auto/principalProperty/PrincipalSystemPropTest.java                       Passed. Execution successful
 sun/security/krb5/canonicalize/Test.java                                                    Passed. Execution successful
 sun/security/krb5/ccache/CorruptedCC.java                                                   Passed. Execution successful
 sun/security/krb5/ccache/DefaultFile.java                                                   Passed. Execution successful
 sun/security/krb5/ccache/EmptyCC.java                                                       Passed. Execution successful
 sun/security/krb5/ccache/EmptyRealmCC.java                                                  Passed. Execution successful
 sun/security/krb5/ccache/Refresh.java                                                       Passed. Execution successful
 sun/security/krb5/ccache/TimeInCCache.java                                                  Passed. Execution successful
 sun/security/krb5/ccache/TwoFiles.java                                                      Passed. Execution successful
 sun/security/krb5/config/ConfPlusProp.java                                                  Passed. Execution successful
 sun/security/krb5/config/ConfigWithQuotations.java                                          Passed. Execution successful
 sun/security/krb5/config/DNS.java                                                           Passed. Execution successful
 sun/security/krb5/config/DefUdpLimit.java                                                   Passed. Execution successful
 sun/security/krb5/config/DnsFallback.java                                                   Passed. Execution successful
 sun/security/krb5/config/Duplicates.java                                                    Passed. Execution successful
 sun/security/krb5/config/Duration.java                                                      Passed. Execution successful
 sun/security/krb5/config/ExtraLines.java                                                    Passed. Execution successful
 sun/security/krb5/config/Include.java                                                       Passed. Execution successful
 sun/security/krb5/config/IncludeDirOrder.java                                               Passed. Execution successful
 sun/security/krb5/config/KdcDefaultOptions.java                                             Passed. Execution successful
 sun/security/krb5/config/ParseCAPaths.java                                                  Passed. Execution successful
 sun/security/krb5/config/ParseConfig.java                                                   Passed. Execution successful
 sun/security/krb5/config/Semicolon.java                                                     Passed. Execution successful
 sun/security/krb5/config/YesNo.java                                                         Passed. Execution successful
 sun/security/krb5/etype/ETypeOrder.java                                                     Passed. Execution successful
 sun/security/krb5/etype/KerberosAesSha2.java                                                Passed. Execution successful
 sun/security/krb5/etype/Permitted.java                                                      Passed. Execution successful
 sun/security/krb5/etype/UnsupportedKeyType.java                                             Passed. Execution successful
 sun/security/krb5/etype/WeakCrypto.java                                                     Passed. Execution successful
 sun/security/krb5/ktab/BufferBoundary.java                                                  Passed. Execution successful
 sun/security/krb5/ktab/FileKeyTab.java                                                      Passed. Execution successful
 sun/security/krb5/ktab/HighestKvno.java                                                     Passed. Execution successful
 sun/security/krb5/ktab/KeyString.java                                                       Passed. Execution successful
 sun/security/krb5/ktab/KeyTabIndex.java                                                     Passed. Execution successful
 sun/security/krb5/name/Constructors.java                                                    Passed. Execution successful
 sun/security/krb5/name/Immutable.java                                                       Passed. Execution successful
 sun/security/lib/CheckBlockedCerts.java                                                     Passed. Execution successful
 sun/security/lib/cacerts/VerifyCACerts.java                                                 Passed. Execution successful
 sun/security/pkcs/EncryptedPrivateKeyInfo/EncryptedPKInfoEqualsHashCode.java                Passed. Execution successful
 sun/security/pkcs/pkcs10/PKCS10AttrEncoding.java                                            Passed. Execution successful
 sun/security/pkcs/pkcs10/PKCS10AttributeReader.java                                         Passed. Execution successful
 sun/security/pkcs/pkcs7/NewSigAlg.java                                                      Passed. Execution successful
 sun/security/pkcs/pkcs7/PKCS7VerifyTest.java                                                Passed. Execution successful
 sun/security/pkcs/pkcs7/SignerOrder.java                                                    Passed. Execution successful
 sun/security/pkcs/pkcs7/TwoHash.java                                                        Passed. Execution successful
 sun/security/pkcs/pkcs8/LongPKCS8orX509KeySpec.java                                         Passed. Execution successful
 sun/security/pkcs/pkcs8/PKCS8Test.java                                                      Passed. Execution successful
 sun/security/pkcs/pkcs8/TestLeadingZeros.java                                               Passed. Execution successful
 sun/security/pkcs/pkcs9/ChallengePassStringFmt.java                                         Passed. Execution successful
 sun/security/pkcs/pkcs9/EncodeDecode.java                                                   Passed. Execution successful
 sun/security/pkcs/pkcs9/PKCS9AttrTypeTests.java                                             Passed. Execution successful
 sun/security/pkcs/pkcs9/UnknownAttribute.java                                               Passed. Execution successful
 sun/security/pkcs/pkcs9/UnstructuredName.java                                               Passed. Execution successful
 sun/security/pkcs11/Cipher/CancelMultipart.java                                             Passed. Execution successful
 sun/security/pkcs11/Cipher/EncryptionPadding.java                                           Passed. Execution successful
 sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java                                         Passed. Execution successful
 sun/security/pkcs11/Cipher/KeyWrap/TestCipherKeyWrapperTest.java                            Passed. Execution successful
 sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java                                         Passed. Execution successful
 sun/security/pkcs11/Cipher/KeyWrap/TestKeySizeCheck.java                                    Passed. Execution successful
 sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java                                           Passed. Execution successful
 sun/security/pkcs11/Cipher/PBECipher.java                                                   Passed. Execution successful
 sun/security/pkcs11/Cipher/ReinitCipher.java                                                Passed. Execution successful
 sun/security/pkcs11/Cipher/Test4512704.java                                                 Passed. Execution successful
 sun/security/pkcs11/Cipher/TestCICOWithGCM.java                                             Passed. Execution successful
 sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java                                       Passed. Execution successful
 sun/security/pkcs11/Cipher/TestChaChaPoly.java                                              Passed. Execution successful
 sun/security/pkcs11/Cipher/TestChaChaPolyKAT.java                                           Passed. Execution successful
 sun/security/pkcs11/Cipher/TestChaChaPolyNoReuse.java                                       Passed. Execution successful
 sun/security/pkcs11/Cipher/TestChaChaPolyOutputSize.java                                    Passed. Execution successful
 sun/security/pkcs11/Cipher/TestCipherMode.java                                              Passed. Execution successful
 sun/security/pkcs11/Cipher/TestCipherTextStealingMultipart.java                             Passed. Execution successful
 sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java                                        Passed. Execution successful
 sun/security/pkcs11/Cipher/TestKATForGCM.java                                               Passed. Execution successful
 sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java                                       Passed. Execution successful
 sun/security/pkcs11/Cipher/TestPaddingOOB.java                                              Passed. Execution successful
 sun/security/pkcs11/Cipher/TestRSACipher.java                                               Passed. Execution successful
 sun/security/pkcs11/Cipher/TestRSACipherWrap.java                                           Passed. Execution successful
 sun/security/pkcs11/Cipher/TestRawRSACipher.java                                            Passed. Execution successful
 sun/security/pkcs11/Cipher/TestSymmCiphers.java                                             Passed. Execution successful
 sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java                                        Passed. Execution successful
 sun/security/pkcs11/Config/ReadConfInUTF16Env.java                                          Passed. Execution successful
 sun/security/pkcs11/KDF/TestHKDF.java                                                       Passed. Execution successful
 sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java                                       Passed. Execution successful
 sun/security/pkcs11/KeyAgreement/TestDH.java                                                Passed. Execution successful
 sun/security/pkcs11/KeyAgreement/TestInterop.java                                           Passed. Execution successful
 sun/security/pkcs11/KeyAgreement/TestShort.java                                             Passed. Execution successful
 sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java                                     Passed. Execution successful
 sun/security/pkcs11/KeyGenerator/DESParity.java                                             Passed. Execution successful
 sun/security/pkcs11/KeyGenerator/HmacDefKeySizeTest.java                                    Passed. Execution successful
 sun/security/pkcs11/KeyGenerator/TestAES.java                                               Passed. Execution successful
 sun/security/pkcs11/KeyGenerator/TestChaCha20.java                                          Passed. Execution successful
 sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java                                      Passed. Execution successful
 sun/security/pkcs11/KeyPairGenerator/TestDH2048.java                                        Passed. Execution successful
 sun/security/pkcs11/KeyPairGenerator/TestDefaultDHPrivateExpSize.java                       Passed. Execution successful
 sun/security/pkcs11/KeyPairGenerator/TestDefaultSize.java                                   Passed. Execution successful
 sun/security/pkcs11/KeyStore/Basic.java                                                     Passed. Execution successful
 sun/security/pkcs11/KeyStore/CertChainRemoval.java                                          Passed. Execution successful
 sun/security/pkcs11/KeyStore/ClientAuth.java                                                Passed. Execution successful
 sun/security/pkcs11/KeyStore/ImportKeyToP12.java                                            Passed. Execution successful
 sun/security/pkcs11/KeyStore/SecretKeysBasic.java                                           Passed. Execution successful
 sun/security/pkcs11/Mac/MacKAT.java                                                         Passed. Execution successful
 sun/security/pkcs11/Mac/MacSameTest.java                                                    Passed. Execution successful
 sun/security/pkcs11/Mac/PBAMac.java                                                         Passed. Execution successful
 sun/security/pkcs11/Mac/ReinitMac.java                                                      Passed. Execution successful
 sun/security/pkcs11/Mac/TestLargeSecretKeys.java                                            Passed. Execution successful
 sun/security/pkcs11/MessageDigest/ByteBuffers.java                                          Passed. Execution successful
 sun/security/pkcs11/MessageDigest/DigestKAT.java                                            Passed. Execution successful
 sun/security/pkcs11/MessageDigest/ReinitDigest.java                                         Passed. Execution successful
 sun/security/pkcs11/MessageDigest/TestCloning.java                                          Passed. Execution successful
 sun/security/pkcs11/Provider/Absolute.java                                                  Passed. Execution successful
 sun/security/pkcs11/Provider/CheckRegistration.java                                         Passed. Execution successful
 sun/security/pkcs11/Provider/ConfigQuotedString.java                                        Passed. Execution successful
 sun/security/pkcs11/Provider/ConfigShortPath.java                                           Passed. Execution successful
 sun/security/pkcs11/Provider/Login.java                                                     Passed. Execution successful
 sun/security/pkcs11/Provider/LoginISE.java                                                  Passed. Execution successful
 sun/security/pkcs11/Provider/MultipleLogins.sh                                              Passed. Execution successful
 sun/security/pkcs11/Provider/RequiredMechCheck.java                                         Passed. Execution successful
 sun/security/pkcs11/SampleTest.java                                                         Passed. Execution successful
 sun/security/pkcs11/Secmod/AddPrivateKey.java                                               Passed. Execution successful
 sun/security/pkcs11/Secmod/AddTrustedCert.java                                              Passed. Execution successful
 sun/security/pkcs11/Secmod/Crypto.java                                                      Passed. Execution successful
 sun/security/pkcs11/Secmod/GetPrivateKey.java                                               Passed. Execution successful
 sun/security/pkcs11/Secmod/JksSetPrivateKey.java                                            Passed. Execution successful
 sun/security/pkcs11/Secmod/LoadKeystore.java                                                Passed. Execution successful
 sun/security/pkcs11/Secmod/TestNssDbSqlite.java                                             Passed. Execution successful
 sun/security/pkcs11/Secmod/TrustAnchors.java                                                Passed. Execution successful
 sun/security/pkcs11/SecretKeyFactory/TestGeneral.java                                       Passed. Execution successful
 sun/security/pkcs11/SecretKeyFactory/TestPBKD.java                                          Passed. Execution successful
 sun/security/pkcs11/SecureRandom/Basic.java                                                 Passed. Execution successful
 sun/security/pkcs11/SecureRandom/TestDeserialization.java                                   Passed. Execution successful
 sun/security/pkcs11/Serialize/SerializeProvider.java                                        Passed. Execution successful
 sun/security/pkcs11/Signature/ByteBuffers.java                                              Passed. Execution successful
 sun/security/pkcs11/Signature/InitAgainPSS.java                                             Passed. Execution successful
 sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java                                   Passed. Execution successful
 sun/security/pkcs11/Signature/LargeDSAKey.java                                              Passed. Execution successful
 sun/security/pkcs11/Signature/ReinitSignature.java                                          Passed. Execution successful
 sun/security/pkcs11/Signature/SigInteropPSS.java                                            Passed. Execution successful
 sun/security/pkcs11/Signature/SigInteropPSS2.java                                           Passed. Execution successful
 sun/security/pkcs11/Signature/SignatureTestPSS.java                                         Passed. Execution successful
 sun/security/pkcs11/Signature/SignatureTestPSS2.java                                        Passed. Execution successful
 sun/security/pkcs11/Signature/TestDSA.java                                                  Passed. Execution successful
 sun/security/pkcs11/Signature/TestDSA2.java                                                 Passed. Execution successful
 sun/security/pkcs11/Signature/TestDSAKeyLength.java                                         Failed. Execution failed: `main' threw exception: java.lang.Exception: Test Failed - expected IKE not thrown
 sun/security/pkcs11/Signature/TestRSAKeyLength.java                                         Passed. Execution successful
 sun/security/pkcs11/ec/ReadCertificates.java                                                Passed. Execution successful
 sun/security/pkcs11/ec/ReadPKCS12.java                                                      Passed. Execution successful
 sun/security/pkcs11/ec/TestCurves.java                                                      Passed. Execution successful
 sun/security/pkcs11/ec/TestECDH.java                                                        Passed. Execution successful
 sun/security/pkcs11/ec/TestECDH2.java                                                       Passed. Execution successful
 sun/security/pkcs11/ec/TestECDSA.java                                                       Passed. Execution successful
 sun/security/pkcs11/ec/TestECDSA2.java                                                      Passed. Execution successful
 sun/security/pkcs11/ec/TestECGenSpec.java                                                   Passed. Execution successful
 sun/security/pkcs11/ec/TestKeyFactory.java                                                  Passed. Execution successful
 sun/security/pkcs11/rsa/KeyWrap.java                                                        Passed. Execution successful
 sun/security/pkcs11/rsa/TestCACerts.java                                                    Passed. Execution successful
 sun/security/pkcs11/rsa/TestKeyFactory.java                                                 Passed. Execution successful
 sun/security/pkcs11/rsa/TestKeyPairGenerator.java                                           Passed. Execution successful
 sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java                                 Passed. Execution successful
 sun/security/pkcs11/rsa/TestSignatures.java                                                 Passed. Execution successful
 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java                                        Passed. Execution successful
 sun/security/pkcs11/tls/TestKeyMaterial.java                                                Passed. Execution successful
 sun/security/pkcs11/tls/TestKeyMaterialChaCha20.java                                        Passed. Execution successful
 sun/security/pkcs11/tls/TestKeyMaterialMisuse.java                                          Passed. Execution successful
 sun/security/pkcs11/tls/TestLeadingZeroesP11.java                                           Passed. Execution successful
 sun/security/pkcs11/tls/TestMasterSecret.java                                               Passed. Execution successful
 sun/security/pkcs11/tls/TestPRF.java                                                        Passed. Execution successful
 sun/security/pkcs11/tls/TestPremaster.java                                                  Passed. Execution successful
 sun/security/pkcs11/tls/tls12/FipsModeTLS12.java                                            Passed. Execution successful
 sun/security/pkcs12/AttributesCorrectness.java                                              Passed. Execution successful
 sun/security/pkcs12/AttributesMultiThread.java                                              Passed. Execution successful
 sun/security/pkcs12/Bug6415637.java                                                         Passed. Execution successful
 sun/security/pkcs12/EmptyAlias.java                                                         Passed. Execution successful
 sun/security/pkcs12/EmptyPassword.java                                                      Passed. Execution successful
 sun/security/pkcs12/GetAttributes.java                                                      Passed. Execution successful
 sun/security/pkcs12/GetSetEntryTest.java                                                    Passed. Execution successful
 sun/security/pkcs12/ImportPassKeyAlg.java                                                   Passed. Execution successful
 sun/security/pkcs12/KeytoolOpensslInteropTest.java#GenerateOpensslPKCS12                    Passed. Skipped: jtreg.SkippedException: Cannot find the artifact openssl-linux_x64
 sun/security/pkcs12/KeytoolOpensslInteropTest.java#UseExistingPKCS12                        Passed. Execution successful
 sun/security/pkcs12/MixedcaseAlias.java                                                     Passed. Execution successful
 sun/security/pkcs12/P12SecretKey.java                                                       Passed. Execution successful
 sun/security/pkcs12/PBES2Encoding.java                                                      Passed. Execution successful
 sun/security/pkcs12/PKCS12SameKeyId.java                                                    Passed. Execution successful
 sun/security/pkcs12/ParamsPreferences.java                                                  Passed. Execution successful
 sun/security/pkcs12/ProbeBER.java                                                           Passed. Execution successful
 sun/security/pkcs12/ProbeLargeKeystore.java                                                 Passed. Execution successful
 sun/security/pkcs12/SameDN.java                                                             Passed. Execution successful
 sun/security/pkcs12/SecretKeyAlgorithms.java                                                Passed. Execution successful
 sun/security/pkcs12/StorePasswordTest.java                                                  Passed. Execution successful
 sun/security/pkcs12/StoreSecretKeyTest.java                                                 Passed. Execution successful
 sun/security/pkcs12/StoreTrustedCertTest.java                                               Passed. Execution successful
 sun/security/pkcs12/WrongPBES2.java                                                         Passed. Execution successful
 sun/security/provider/DSA/SecureRandomReset.java                                            Passed. Execution successful
 sun/security/provider/DSA/SupportedDSAParamGen.java                                         Passed. Execution successful
 sun/security/provider/DSA/SupportedDSAParamGenLongKey.java                                  Passed. Execution successful
 sun/security/provider/DSA/TestAlgParameterGenerator.java                                    Passed. Execution successful
 sun/security/provider/DSA/TestDSA.java                                                      Passed. Execution successful
 sun/security/provider/DSA/TestDSA2.java                                                     Passed. Execution successful
 sun/security/provider/DSA/TestKeyPairGenerator.java                                         Passed. Execution successful
 sun/security/provider/DSA/TestLegacyDSAKeyPairGenerator.java                                Passed. Execution successful
 sun/security/provider/DSA/TestMaxLengthDER.java                                             Passed. Execution successful
 sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java                      Passed. Execution successful
 sun/security/provider/KeyStore/CaseSensitiveAliases.java                                    Passed. Execution successful
 sun/security/provider/KeyStore/DKSTest.java                                                 Passed. Execution successful
 sun/security/provider/KeyStore/DksWithEmptyKeystore.java                                    Passed. Execution successful
 sun/security/provider/KeyStore/TestJKSWithSecretKey.java                                    Passed. Execution successful
 sun/security/provider/KeyStore/WrongPassword.java                                           Passed. Execution successful
 sun/security/provider/KeyStore/WrongStoreType.java                                          Passed. Execution successful
 sun/security/provider/MessageDigest/DigestKAT.java                                          Passed. Execution successful
 sun/security/provider/MessageDigest/Offsets.java                                            Passed. Execution successful
 sun/security/provider/MessageDigest/SHA3.java                                               Passed. Execution successful
 sun/security/provider/MessageDigest/SHA512.java                                             Passed. Execution successful
 sun/security/provider/MessageDigest/SHAKEhash.java                                          Passed. Execution successful
 sun/security/provider/MessageDigest/SHAKEsqueeze.java                                       Passed. Execution successful
 sun/security/provider/MessageDigest/TestSHAClone.java                                       Passed. Execution successful
 sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java                                Passed. Execution successful
 sun/security/provider/NSASuiteB/TestDSAGenParameterSpecLongKey.java                         Passed. Execution successful
 sun/security/provider/NSASuiteB/TestSHAOids.java                                            Passed. Execution successful
 sun/security/provider/NSASuiteB/TestSHAwithDSASignatureOids.java                            Passed. Execution successful
 sun/security/provider/NamedEdDSA.java                                                       Passed. Execution successful
 sun/security/provider/NamedKeyFactoryTest.java                                              Passed. Execution successful
 sun/security/provider/PolicyFile/CanonPath.java                                             Passed. Execution successful
 sun/security/provider/PolicyFile/NullCodeSource.java                                        Passed. Execution successful
 sun/security/provider/PolicyFile/nullDomain.java                                            Passed. Execution successful
+sun/security/provider/ProvidersFilterTest.java                                              Passed. Execution successful
 sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java                               Passed. Execution successful
 sun/security/provider/SecureRandom/AutoReseed.java                                          Passed. Execution successful
 sun/security/provider/SecureRandom/CommonSeeder.java                                        Passed. Execution successful
 sun/security/provider/SecureRandom/DRBGAlg.java                                             Passed. Execution successful
 sun/security/provider/SecureRandom/DRBGS11n.java                                            Passed. Execution successful
 sun/security/provider/SecureRandom/SHA1PRNGReseed.java                                      Passed. Execution successful
 sun/security/provider/SecureRandom/StrongSecureRandom.java                                  Passed. Execution successful
 sun/security/provider/SecureRandom/StrongSeedReader.java                                    Passed. Execution successful
 sun/security/provider/SeedGenerator/Awt_Hang_Test.java                                      Passed. Execution successful
 sun/security/provider/SeedGenerator/Priority_Inversion.java                                 Passed. Execution successful
 sun/security/provider/SeedGenerator/SeedGeneratorChoice.java                                Passed. Execution successful
 sun/security/provider/X509Factory/BadPem.java                                               Passed. Execution successful
 sun/security/provider/X509Factory/BigCRL.java                                               Passed. Execution successful
 sun/security/provider/acvp/Launcher.java#id0                                                Passed. Skipped: jtreg.SkippedException: Cannot find the artifact ACVP-Server
 sun/security/provider/acvp/Launcher.java#id1                                                Passed. Skipped: jtreg.SkippedException: Cannot find the artifact ACVP-Server
 sun/security/provider/all/Deterministic.java                                                Passed. Execution successful
 sun/security/provider/certpath/CertId/CheckCertId.java                                      Passed. Execution successful
 sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java                            Passed. Execution successful
 sun/security/provider/certpath/DisabledAlgorithms/CPBuilderWithMD5.java                     Passed. Execution successful
 sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java                 Passed. Execution successful
 sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java              Passed. Execution successful
 sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java               Passed. Execution successful
 sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java                      Passed. Execution successful
 sun/security/provider/certpath/OCSP/OCSPNoContentLength.java                                Passed. Execution successful
 sun/security/provider/certpath/OCSP/OCSPReadTimeoutDefault.java                             Passed. Execution successful
 sun/security/provider/certpath/OCSP/OCSPSingleExtensions.java                               Passed. Execution successful
 sun/security/provider/certpath/PKIXCertComparator/Order.java                                Passed. Execution successful
 sun/security/provider/certpath/PKIXCertPathValidator/Validity.java                          Passed. Execution successful
 sun/security/provider/certpath/ResponderId/ResponderIdTests.java                            Passed. Execution successful
 sun/security/provider/certpath/SunCertPathBuilderExceptionTest.java                         Passed. Execution successful
 sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java                        Passed. Execution successful
 sun/security/provider/hss/TestHSS.java                                                      Passed. Execution successful
 sun/security/rsa/BrokenRSAPrivateCrtKey.java                                                Passed. Execution successful
 sun/security/rsa/InvalidBitString.java                                                      Passed. Execution successful
 sun/security/rsa/KeySizeTest.java                                                           Passed. Execution successful
 sun/security/rsa/PrivateKeyEqualityTest.java                                                Passed. Execution successful
 sun/security/rsa/RSAPaddingCheck.java                                                       Passed. Execution successful
 sun/security/rsa/SignatureOffsets.java                                                      Passed. Execution successful
 sun/security/rsa/SignatureTest.java                                                         Passed. Execution successful
 sun/security/rsa/SignedObjectChain.java                                                     Passed. Execution successful
 sun/security/rsa/SpecTest.java                                                              Passed. Execution successful
 sun/security/rsa/TestCACerts.java                                                           Passed. Execution successful
 sun/security/rsa/TestKeyFactory.java                                                        Passed. Execution successful
 sun/security/rsa/TestKeyPairGenerator.java                                                  Passed. Execution successful
 sun/security/rsa/TestKeyPairGeneratorExponent.java                                          Passed. Execution successful
 sun/security/rsa/TestKeyPairGeneratorInit.java                                              Passed. Execution successful
 sun/security/rsa/TestKeyPairGeneratorLength.java                                            Passed. Execution successful
 sun/security/rsa/TestRSAOidSupport.java                                                     Passed. Execution successful
 sun/security/rsa/TestSigGen15.java                                                          Passed. Execution successful
 sun/security/rsa/TestSignatures.java                                                        Passed. Execution successful
 sun/security/rsa/WithoutNULL.java                                                           Passed. Execution successful
 sun/security/rsa/pss/DefaultParamSpec.java                                                  Passed. Execution successful
 sun/security/rsa/pss/InitAgain.java                                                         Passed. Execution successful
 sun/security/rsa/pss/PSSKeyCompatibility.java                                               Passed. Execution successful
 sun/security/rsa/pss/PSSParametersTest.java                                                 Passed. Execution successful
 sun/security/rsa/pss/SerializedPSSKey.java                                                  Passed. Execution successful
 sun/security/rsa/pss/SignatureTest2.java                                                    Passed. Execution successful
 sun/security/rsa/pss/SignatureTestPSS.java                                                  Passed. Execution successful
 sun/security/rsa/pss/TestPSSKeySupport.java                                                 Passed. Execution successful
 sun/security/rsa/pss/TestSigGenPSS.java                                                     Passed. Execution successful
 sun/security/smartcardio/TestChannel.java                                                   Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/smartcardio/TestConnect.java                                                   Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/smartcardio/TestConnectAgain.java                                              Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/smartcardio/TestControl.java                                                   Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/smartcardio/TestDefault.java                                                   Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/smartcardio/TestDirect.java                                                    Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/smartcardio/TestExclusive.java                                                 Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/smartcardio/TestMultiplePresent.java                                           Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/smartcardio/TestPresent.java                                                   Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/smartcardio/TestTransmit.java                                                  Failed. Execution failed: `main' threw exception: javax.smartcardio.CardException: list() failed
 sun/security/ssl/ALPN/AlpnGreaseTest.java                                                   Passed. Execution successful
 sun/security/ssl/AppInputStream/ReadBlocksClose.java                                        Passed. Execution successful
 sun/security/ssl/AppInputStream/ReadHandshake.java                                          Passed. Execution successful
 sun/security/ssl/AppInputStream/ReadZeroBytes.java                                          Passed. Execution successful
 sun/security/ssl/AppInputStream/RemoveMarkReset.java                                        Passed. Execution successful
 sun/security/ssl/AppOutputStream/NoExceptionOnClose.java                                    Passed. Execution successful
 sun/security/ssl/CertPathRestrictions/TLSRestrictions.java                                  Passed. Execution successful
 sun/security/ssl/CipherSuite/DisabledCurve.java                                             Passed. Execution successful
 sun/security/ssl/CipherSuite/LegacyConstraints.java                                         Passed. Execution successful
 sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java                                Passed. Execution successful
 sun/security/ssl/CipherSuite/NoDesRC4DesEdeCiphSuite.java                                   Passed. Execution successful
 sun/security/ssl/CipherSuite/RestrictNamedGroup.java                                        Passed. Execution successful
 sun/security/ssl/CipherSuite/RestrictSignatureScheme.java                                   Passed. Execution successful
 sun/security/ssl/CipherSuite/SSL_NULL.java                                                  Passed. Execution successful
 sun/security/ssl/CipherSuite/SupportedGroups.java                                           Passed. Execution successful
 sun/security/ssl/CipherSuite/TLSCipherSuiteWildCardMatchingDisablePartsOfCipherSuite.java   Passed. Execution successful
 sun/security/ssl/CipherSuite/TLSCipherSuiteWildCardMatchingIllegalArgument.java             Passed. Execution successful
 sun/security/ssl/ClientHandshaker/CipherSuiteOrder.java                                     Passed. Execution successful
 sun/security/ssl/ClientHandshaker/LengthCheckTest.java                                      Passed. Execution successful
 sun/security/ssl/ClientHandshaker/RSAExport.java                                            Passed. Execution successful
 sun/security/ssl/DHKeyExchange/DHEKeySizing.java                                            Passed. Execution successful
 sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java                                    Passed. Execution successful
 sun/security/ssl/DHKeyExchange/UseStrongDHSizes.java                                        Passed. Execution successful
 sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.java                                   Passed. Execution successful
 sun/security/ssl/GenSSLConfigs/main.java                                                    Passed. Execution successful
 sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java                            Passed. Execution successful
 sun/security/ssl/HandshakeOutStream/NullCerts.java                                          Passed. Execution successful
 sun/security/ssl/InputRecord/ClientHelloRead.java                                           Passed. Execution successful
 sun/security/ssl/InputRecord/SSLSocketTimeoutNulls.java                                     Passed. Execution successful
 sun/security/ssl/ProtocolVersion/HttpsProtocols.java                                        Passed. Execution successful
 sun/security/ssl/SSLCipher/ReadOnlyEngine.java                                              Passed. Execution successful
 sun/security/ssl/SSLCipher/SSLEngineNoServerHelloClientShutdown.java                        Passed. Execution successful
 sun/security/ssl/SSLCipher/SSLSocketNoServerHelloClientShutdown.java                        Passed. Execution successful
 sun/security/ssl/SSLContextImpl/BadKSProvider.java                                          Passed. Execution successful
 sun/security/ssl/SSLContextImpl/BadTSProvider.java                                          Passed. Execution successful
 sun/security/ssl/SSLContextImpl/CustomizedCipherSuites.java                                 Passed. Execution successful
 sun/security/ssl/SSLContextImpl/CustomizedDTLSDefaultProtocols.java                         Passed. Execution successful
 sun/security/ssl/SSLContextImpl/CustomizedDTLSServerDefaultProtocols.java                   Passed. Execution successful
 sun/security/ssl/SSLContextImpl/CustomizedDefaultProtocols.java                             Passed. Execution successful
 sun/security/ssl/SSLContextImpl/CustomizedServerDefaultProtocols.java                       Passed. Execution successful
 sun/security/ssl/SSLContextImpl/DefaultCipherSuitePreference.java                           Passed. Execution successful
 sun/security/ssl/SSLContextImpl/DefaultDTLSEnabledProtocols.java                            Passed. Execution successful
 sun/security/ssl/SSLContextImpl/DefaultEnabledProtocols.java                                Passed. Execution successful
 sun/security/ssl/SSLContextImpl/GoodProvider.java                                           Passed. Execution successful
 sun/security/ssl/SSLContextImpl/IllegalProtocolProperty.java                                Passed. Execution successful
 sun/security/ssl/SSLContextImpl/MD2InTrustAnchor.java                                       Passed. Execution successful
 sun/security/ssl/SSLContextImpl/MultipleChooseAlias.java                                    Passed. Execution successful
 sun/security/ssl/SSLContextImpl/NoOldVersionContext.java                                    Passed. Execution successful
 sun/security/ssl/SSLContextImpl/NullGetAcceptedIssuers.java                                 Passed. Execution successful
 sun/security/ssl/SSLContextImpl/SSLContextDefault.java                                      Passed. Execution successful
 sun/security/ssl/SSLContextImpl/SSLContextVersion.java                                      Passed. Execution successful
 sun/security/ssl/SSLContextImpl/TrustTrustedCert.java                                       Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/CloseEngineException.java                                    Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/CloseStart.java                                              Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/DelegatedTaskWrongException.java                             Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/EmptyExtensionData.java                                      Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java                              Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/RehandshakeFinished.java                                     Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java                           Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/SSLEngineDeadlock.java                                       Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/SSLEngineDecodeBadPoint.java                                 Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/SSLEngineEmptyFragments.java                                 Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/SSLEngineFailedALPN.java                                     Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/SSLEngineKeyLimit.java                                       Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/TLS13BeginHandshake.java                                     Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java                                      Passed. Execution successful
 sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java                                    Passed. Execution successful
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java                                     Passed. Execution successful
 sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java                                     Passed. Execution successful
 sun/security/ssl/SSLLogger/LoggingFormatConsistency.java                                    Passed. Execution successful
 sun/security/ssl/SSLSessionContextImpl/DefautlCacheSize.java                                Passed. Execution successful
 sun/security/ssl/SSLSessionContextImpl/Timeout.java                                         Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/HashCodeMissing.java                                        Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/InvalidateSession.java                                      Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/MultiNSTClient.java                                         Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/MultiNSTNoSessionCreation.java                              Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/MultiNSTParallel.java                                       Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/MultiNSTSequence.java                                       Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java                            Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/ResumeChecksClient.java                                     Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/ResumeChecksClientStateless.java                            Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java                                     Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/ResumeChecksServerStateless.java                            Passed. Execution successful
 sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java                            Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java                                     Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/BlockedAsyncClose.java                                       Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/CheckMethods.java                                            Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/ClientModeClientAuth.java                                    Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/ClientSocketCloseHang.java                                   Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/ClientTimeout.java                                           Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/CloseSocket.java                                             Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/CloseSocketException.java                                    Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/DisableExtensions.java                                       Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/IgnorableExceptionMessages.java                              Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java                      Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/LargePacketAfterHandshakeTest.java                           Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/LoopbackSSLSocket.java                                       Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/NewSocketMethods.java                                        Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/NoImpactServerRenego.java                                    Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/NonAutoClose.java                                            Error. Test ignored: this test does not work any more as the TLS spec changes the behaviors of close_notify.
 sun/security/ssl/SSLSocketImpl/RejectClientRenego.java                                      Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/ReuseAddr.java                                               Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java                                       Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketBruteForceClose.java                                Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketClose.java                                          Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketCloseHang.java                                      Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketEmptyFragments.java                                 Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java                      Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketKeyLimit.java                                       Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java                                           Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketReset.java                                          Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java                          Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SSLSocketShouldThrowSocketException.java                     Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/ServerRenegoWithTwoVersions.java                             Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/ServerTimeout.java                                           Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SetClientMode.java                                           Error. Test ignored: this test does not grant to work. The handshake may have completed when getSession() return. Please update or remove this test case.
 sun/security/ssl/SSLSocketImpl/SetSoTimeout.java                                            Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/SocketExceptionForSocketIssues.java                          Passed. Execution successful
 sun/security/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java                        Passed. Execution successful
 sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java                         Passed. Execution successful
 sun/security/ssl/ServerHandshaker/GetPeerHost.java                                          Passed. Execution successful
 sun/security/ssl/ServerHandshaker/HelloExtensionsTest.java                                  Passed. Execution successful
 sun/security/ssl/SignatureScheme/CustomizedClientSchemes.java                               Passed. Execution successful
 sun/security/ssl/SignatureScheme/CustomizedServerSchemes.java                               Passed. Execution successful
 sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureDTLS12.java                 Passed. Execution successful
 sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS12.java                  Passed. Execution successful
 sun/security/ssl/SignatureScheme/DisableSHA1inHandshakeSignatureTLS13.java                  Passed. Execution successful
 sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeDTLS12.java                  Passed. Execution successful
 sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS12.java                   Passed. Execution successful
 sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS13.java                   Passed. Execution successful
 sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java              Passed. Execution successful
 sun/security/ssl/SignatureScheme/MixingTLSUsageConstraintsWithNonTLS.java                   Passed. Execution successful
 sun/security/ssl/SignatureScheme/SigAlgosExtTestWithTLS12.java                              Passed. Execution successful
 sun/security/ssl/SignatureScheme/SigAlgosExtTestWithTLS13.java                              Passed. Execution successful
 sun/security/ssl/SignatureScheme/SigSchemePropOrdering.java                                 Passed. Execution successful
 sun/security/ssl/SignatureScheme/Tls13NamedGroups.java                                      Passed. Execution successful
 sun/security/ssl/SocketCreation/SocketCreation.java                                         Passed. Execution successful
 sun/security/ssl/Stapling/StatusResponseManager.java                                        Passed. Execution successful
 sun/security/ssl/X509KeyManager/CertificateAuthorities.java                                 Passed. Execution successful
 sun/security/ssl/X509KeyManager/NoGoodKey.java                                              Passed. Execution successful
 sun/security/ssl/X509KeyManager/NullCases.java                                              Passed. Execution successful
 sun/security/ssl/X509KeyManager/PreferredKey.java                                           Passed. Execution successful
 sun/security/ssl/X509KeyManager/SelectOneKeyOutOfMany.java                                  Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java                                 Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/BasicConstraints12.java                               Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/CacertsLimit.java                                     Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/CertRequestOverflow.java                              Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/CheckNullEntity.java                                  Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java                                     Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java                                   Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/SelfIssuedCert.java                                   Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java                                Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/TooManyCAs.java                                       Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java                            Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/distrust/Camerfirma.java                              Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/distrust/Entrust.java                                 Passed. Execution successful
 sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java                                Passed. Execution successful
 sun/security/ssl/internal/TestRun.java                                                      Passed. Execution successful
 sun/security/ssl/rsa/CheckProviderEntries.java                                              Passed. Execution successful
 sun/security/ssl/rsa/SignatureOffsets.java                                                  Passed. Execution successful
 sun/security/ssl/rsa/SignedObjectChain.java                                                 Passed. Execution successful
 sun/security/ssl/spi/ProviderInit.java                                                      Passed. Execution successful
 sun/security/tools/jarsigner/AlgOptions.java                                                Passed. Execution successful
 sun/security/tools/jarsigner/AltProvider.java                                               Passed. Execution successful
 sun/security/tools/jarsigner/AutoKeyStore.java                                              Passed. Execution successful
 sun/security/tools/jarsigner/CertChainUnclosed.java                                         Passed. Execution successful
 sun/security/tools/jarsigner/CertPolicy.java                                                Passed. Execution successful
 sun/security/tools/jarsigner/CheckAlgParams.java                                            Passed. Execution successful
 sun/security/tools/jarsigner/CheckSignerCertChain.java                                      Passed. Execution successful
 sun/security/tools/jarsigner/CheckUsage.java                                                Passed. Execution successful
 sun/security/tools/jarsigner/Collator.java                                                  Passed. Execution successful
 sun/security/tools/jarsigner/ConciseJarsigner.java                                          Passed. Execution successful
 sun/security/tools/jarsigner/Crl.java                                                       Passed. Execution successful
 sun/security/tools/jarsigner/DefaultOptions.java                                            Passed. Execution successful
 sun/security/tools/jarsigner/DefaultSigalg.java                                             Passed. Execution successful
 sun/security/tools/jarsigner/DiffEnd.java                                                   Passed. Execution successful
 sun/security/tools/jarsigner/DigestDontIgnoreCase.java                                      Passed. Execution successful
 sun/security/tools/jarsigner/DisableCurveTest.java                                          Passed. Execution successful
 sun/security/tools/jarsigner/EC.java                                                        Passed. Execution successful
 sun/security/tools/jarsigner/EmptyIndividualSectionName.java                                Passed. Execution successful
 sun/security/tools/jarsigner/EmptyJar.java                                                  Passed. Execution successful
 sun/security/tools/jarsigner/EmptyManifest.java                                             Passed. Execution successful
 sun/security/tools/jarsigner/EnableRevocation.java                                          Passed. Execution successful
 sun/security/tools/jarsigner/EntriesOrder.java                                              Passed. Execution successful
 sun/security/tools/jarsigner/ExitOrNot.java                                                 Passed. Execution successful
 sun/security/tools/jarsigner/FailedSigning.java                                             Passed. Execution successful
 sun/security/tools/jarsigner/FindHeaderEndVsManifestDigesterFindFirstSection.java           Passed. Execution successful
 sun/security/tools/jarsigner/InsufficientSectionDelimiter.java                              Passed. Execution successful
 sun/security/tools/jarsigner/JarSigningNonAscii.java                                        Passed. Execution successful
 sun/security/tools/jarsigner/JavaKeyStoreAliasCaseInsensitive.java                          Passed. Execution successful
 sun/security/tools/jarsigner/JvIndex.java                                                   Passed. Execution successful
 sun/security/tools/jarsigner/LargeJarEntry.java                                             Passed. Execution successful
 sun/security/tools/jarsigner/LineBrokenMultiByteCharacter.java                              Passed. Execution successful
 sun/security/tools/jarsigner/MainAttributesConfused.java                                    Passed. Execution successful
 sun/security/tools/jarsigner/MultiManifest.java                                             Passed. Execution successful
 sun/security/tools/jarsigner/NameClash.java                                                 Passed. Execution successful
 sun/security/tools/jarsigner/NewSize7.java                                                  Passed. Execution successful
 sun/security/tools/jarsigner/OldSig.java                                                    Passed. Execution successful
 sun/security/tools/jarsigner/OnlyManifest.java                                              Passed. Execution successful
 sun/security/tools/jarsigner/Options.java                                                   Passed. Execution successful
 sun/security/tools/jarsigner/PassType.java                                                  Passed. Execution successful
 sun/security/tools/jarsigner/PercentSign.java                                               Passed. Execution successful
 sun/security/tools/jarsigner/PosixPermissionsTest.java                                      Passed. Execution successful
 sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java                         Passed. Execution successful
 sun/security/tools/jarsigner/RemoveDifferentKeyAlgBlockFile.java                            Passed. Execution successful
 sun/security/tools/jarsigner/RemovedFiles.java                                              Passed. Execution successful
 sun/security/tools/jarsigner/RestrictedAlgo.java                                            Passed. Execution successful
 sun/security/tools/jarsigner/SameName.java                                                  Passed. Execution successful
 sun/security/tools/jarsigner/SectionNameContinuedVsLineBreak.java                           Passed. Execution successful
 sun/security/tools/jarsigner/SectionsOnly.java                                              Passed. Execution successful
 sun/security/tools/jarsigner/SignedAgain.java                                               Passed. Execution successful
 sun/security/tools/jarsigner/SymLinkTest.java                                               Passed. Execution successful
 sun/security/tools/jarsigner/Test4431684.java                                               Passed. Execution successful
 sun/security/tools/jarsigner/TimestampCheck.java                                            Passed. Execution successful
 sun/security/tools/jarsigner/TsacertOptionTest.java                                         Passed. Execution successful
 sun/security/tools/jarsigner/VerifyHSSSignedJar.java                                        Passed. Execution successful
 sun/security/tools/jarsigner/VerifyJarEntryName.java                                        Passed. Execution successful
 sun/security/tools/jarsigner/VersionTest.java                                               Passed. Execution successful
 sun/security/tools/jarsigner/Warning.java                                                   Passed. Execution successful
 sun/security/tools/jarsigner/WasSignedByOtherSigner.java                                    Passed. Execution successful
 sun/security/tools/jarsigner/WeakSize.java                                                  Passed. Execution successful
 sun/security/tools/jarsigner/compatibility/Compatibility.java                               Failed. Execution failed: Execution failed
 sun/security/tools/jarsigner/compatibility/SignTwice.java                                   Passed. Execution successful
 sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java                             Passed. Execution successful
 sun/security/tools/jarsigner/warnings/AliasNotInStoreTest.java                              Passed. Execution successful
 sun/security/tools/jarsigner/warnings/AliasNotInStoreTest2.java                             Passed. Execution successful
 sun/security/tools/jarsigner/warnings/BadExtendedKeyUsageTest.java                          Passed. Execution successful
 sun/security/tools/jarsigner/warnings/BadNetscapeCertTypeTest.java                          Passed. Execution successful
 sun/security/tools/jarsigner/warnings/ChainNotValidatedTest.java                            Passed. Execution successful
 sun/security/tools/jarsigner/warnings/HasExpiredCertTest.java                               Passed. Execution successful
 sun/security/tools/jarsigner/warnings/HasExpiringCertTest.java                              Passed. Execution successful
 sun/security/tools/jarsigner/warnings/HasUnsignedEntryTest.java                             Passed. Execution successful
 sun/security/tools/jarsigner/warnings/LowerCaseManifest.java                                Passed. Execution successful
 sun/security/tools/jarsigner/warnings/MultipleWarningsTest.java                             Passed. Execution successful
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java                                  Passed. Execution successful
 sun/security/tools/jarsigner/warnings/NotSignedByAliasTest.java                             Passed. Execution successful
 sun/security/tools/jarsigner/warnings/NotYetValidCertTest.java                              Passed. Execution successful
 sun/security/tools/keytool/CacertsOption.java                                               Passed. Execution successful
 sun/security/tools/keytool/CheckCertAKID.java                                               Passed. Execution successful
 sun/security/tools/keytool/CloneKeyAskPassword.java                                         Passed. Execution successful
 sun/security/tools/keytool/CloseFile.java                                                   Passed. Execution successful
 sun/security/tools/keytool/DefaultOptions.java                                              Passed. Execution successful
 sun/security/tools/keytool/DupCommands.java                                                 Passed. Execution successful
 sun/security/tools/keytool/DupImport.java                                                   Passed. Execution successful
 sun/security/tools/keytool/EmptyField.java                                                  Passed. Execution successful
 sun/security/tools/keytool/EmptySubject.java                                                Passed. Execution successful
 sun/security/tools/keytool/ExtOptionCamelCase.java                                          Passed. Execution successful
 sun/security/tools/keytool/FileInHelp.java                                                  Passed. Execution successful
 sun/security/tools/keytool/GenKeyPairSigner.java                                            Passed. Execution successful
 sun/security/tools/keytool/GenerateAll.java                                                 Passed. Execution successful
 sun/security/tools/keytool/GroupName.java                                                   Passed. Execution successful
 sun/security/tools/keytool/HasSrcStoretypeOption.java                                       Passed. Execution successful
 sun/security/tools/keytool/ImportPrompt.java                                                Passed. Execution successful
 sun/security/tools/keytool/ImportReadAll.java                                               Passed. Execution successful
 sun/security/tools/keytool/ImportToPwordlessPK12.java                                       Passed. Execution successful
 sun/security/tools/keytool/JKStoPKCS12.java                                                 Passed. Execution successful
 sun/security/tools/keytool/KeyAlg.java                                                      Passed. Execution successful
 sun/security/tools/keytool/KeyToolTest.java                                                 Passed. Execution successful
 sun/security/tools/keytool/LineEndings.java                                                 Passed. Execution successful
 sun/security/tools/keytool/ListOrder.java                                                   Passed. Execution successful
 sun/security/tools/keytool/NewHelp.java                                                     Passed. Execution successful
 sun/security/tools/keytool/NewSize7.java                                                    Passed. Execution successful
 sun/security/tools/keytool/NoExtNPE.java                                                    Passed. Execution successful
 sun/security/tools/keytool/NssTest.java                                                     Passed. Execution successful
 sun/security/tools/keytool/PKCS12Passwd.java                                                Passed. Execution successful
 sun/security/tools/keytool/PrintSSL.java                                                    Passed. Execution successful
 sun/security/tools/keytool/ProbingFailure.java                                              Passed. Execution successful
 sun/security/tools/keytool/ReadJar.java                                                     Passed. Execution successful
 sun/security/tools/keytool/RealType.java                                                    Passed. Execution successful
 sun/security/tools/keytool/RemoveKeyAlgDefault.java                                         Passed. Execution successful
 sun/security/tools/keytool/Resource.java                                                    Passed. Execution successful
 sun/security/tools/keytool/SecretKeyKS.java                                                 Passed. Execution successful
 sun/security/tools/keytool/SecurityToolsTest.java                                           Passed. Execution successful
 sun/security/tools/keytool/SelfIssued.java                                                  Passed. Execution successful
 sun/security/tools/keytool/Serial64.java                                                    Passed. Execution successful
 sun/security/tools/keytool/StandardAlgName.java                                             Passed. Execution successful
 sun/security/tools/keytool/StartDateTest.java                                               Passed. Execution successful
 sun/security/tools/keytool/StorePasswords.java                                              Passed. Execution successful
 sun/security/tools/keytool/TestImportPass.java                                              Passed. Execution successful
 sun/security/tools/keytool/TestSha1Usage.java                                               Passed. Execution successful
 sun/security/tools/keytool/TryStore.java                                                    Passed. Execution successful
 sun/security/tools/keytool/UnknownAndUnparseable.java                                       Passed. Execution successful
 sun/security/tools/keytool/VersionTest.java                                                 Passed. Execution successful
 sun/security/tools/keytool/WeakAlg.java                                                     Passed. Execution successful
 sun/security/tools/keytool/WeakSecretKeyTest.java                                           Passed. Execution successful
 sun/security/tools/keytool/fakecacerts/MyOwnCacerts.java                                    Passed. Execution successful
 sun/security/tools/keytool/fakecacerts/TrustedCRL.java                                      Passed. Execution successful
 sun/security/tools/keytool/fakecacerts/TrustedCert.java                                     Passed. Execution successful
 sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java                           Passed. Execution successful
 sun/security/tools/keytool/fakegen/PSS.java                                                 Passed. Execution successful
 sun/security/tools/keytool/i18n.java#id0                                                    Passed. Execution successful
 sun/security/tools/keytool/i18n.java#id1                                                    Passed. Execution successful
 sun/security/tools/keytool/i18n.java#id2                                                    Passed. Execution successful
 sun/security/tools/keytool/i18n.java#id3                                                    Passed. Execution successful
 sun/security/util/AlgorithmConstraints/DecomposeAlgorithms.java                             Passed. Execution successful
 sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java                        Passed. Execution successful
 sun/security/util/BitArray/EmptyBitArray.java                                               Passed. Execution successful
 sun/security/util/BitArray/NamedBitList.java                                                Passed. Execution successful
 sun/security/util/Cache/EbaHash.java                                                        Passed. Execution successful
 sun/security/util/Debug/DebugOptions.java                                                   Passed. Execution successful
 sun/security/util/DerInputBuffer/B8336667/PoC.java                                          Passed. Execution successful
 sun/security/util/DerInputBuffer/B8336667/Reproducer.java                                   Passed. Execution successful
 sun/security/util/DerInputBuffer/BigInteger0.java                                           Passed. Execution successful
 sun/security/util/DerInputBuffer/PaddedBitString.java                                       Passed. Execution successful
 sun/security/util/DerInputBuffer/TimeParsing.java                                           Passed. Execution successful
 sun/security/util/DerOutputStream/DerTimeEncoding.java                                      Passed. Execution successful
 sun/security/util/DerOutputStream/LocaleInTime.java                                         Passed. Execution successful
 sun/security/util/DerValue/BadValue.java                                                    Passed. Execution successful
 sun/security/util/DerValue/DeepOctets.java                                                  Passed. Execution successful
 sun/security/util/DerValue/DerValueEqualsHashCode.java                                      Passed. Execution successful
 sun/security/util/DerValue/EmptyValue.java                                                  Passed. Execution successful
 sun/security/util/DerValue/Indefinite.java                                                  Passed. Execution successful
 sun/security/util/DerValue/NegInt.java                                                      Passed. Execution successful
 sun/security/util/DerValue/WideTag.java                                                     Passed. Execution successful
 sun/security/util/HexDumpEncoderTests.java                                                  Passed. Execution successful
 sun/security/util/HostnameChecker/NullHostnameCheck.java                                    Passed. Execution successful
 sun/security/util/HostnameChecker/TestHostnameChecker.java                                  Passed. Execution successful
 sun/security/util/InternalPrivateKey/Correctness.java                                       Passed. Execution successful
 sun/security/util/ManifestDigester/DigestInput.java                                         Passed. Execution successful
 sun/security/util/ManifestDigester/FindSection.java                                         Passed. Execution successful
 sun/security/util/ManifestDigester/FindSections.java                                        Passed. Execution successful
 sun/security/util/ManifestDigester/LineBreaks.java                                          Passed. Execution successful
 sun/security/util/ManifestDigester/ReproduceRaw.java                                        Passed. Execution successful
 sun/security/util/Oid/OidEquals.java                                                        Passed. Execution successful
 sun/security/util/Oid/OidFormat.java                                                        Passed. Execution successful
 sun/security/util/Oid/S11N.java                                                             Passed. Execution successful
 sun/security/util/Pem/PemEncoding.java                                                      Passed. Execution successful
 sun/security/util/PropertyExpander/ExpandAndEncode.java                                     Passed. Execution successful
 sun/security/util/RegisteredDomain/ParseNames.java                                          Passed. Execution successful
 sun/security/util/Resources/Format.java                                                     Passed. Execution successful
 sun/security/util/Resources/Usages.java                                                     Passed. Execution successful
 sun/security/util/Resources/customSysClassLoader/BootMessages.java                          Passed. Execution successful
 sun/security/util/Resources/customSysClassLoader/MessageFormatting.java                     Passed. Execution successful
 sun/security/util/asn1StringTypes/StringTypes.java                                          Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#Curve25519OrderField                         Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#Curve448OrderField                           Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#IntegerPolynomial1305                        Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#IntegerPolynomial25519                       Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#IntegerPolynomial448                         Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#IntegerPolynomialP256                        Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#IntegerPolynomialP384                        Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#IntegerPolynomialP521                        Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#P256OrderField                               Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#P384OrderField                               Passed. Execution successful
 sun/security/util/math/TestIntegerModuloP.java#P521OrderField                               Passed. Execution successful
 sun/security/util/misc/SetNullSigParams.java                                                Passed. Execution successful
 sun/security/validator/CertReplace.java#certreplace                                         Passed. Execution successful
 sun/security/validator/CertReplace.java#samedn                                              Passed. Execution successful
 sun/security/validator/ConstructorTest.java                                                 Passed. Execution successful
 sun/security/validator/EndEntityExtensionCheck.java                                         Passed. Execution successful
 sun/security/validator/PKIXValAndRevCheckTests.java                                         Passed. Execution successful
 sun/security/x509/AVA/AVAEqualsHashCode.java                                                Passed. Execution successful
 sun/security/x509/AVA/BadName.java                                                          Passed. Execution successful
 sun/security/x509/AVA/DomainComponentEncoding.java                                          Passed. Execution successful
 sun/security/x509/AVA/EmailAddressEncoding.java                                             Passed. Execution successful
 sun/security/x509/AVA/EmptyValue.java                                                       Passed. Execution successful
 sun/security/x509/AlgorithmId/AlgorithmIdEqualsHashCode.java                                Passed. Execution successful
 sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java                                    Passed. Execution successful
 sun/security/x509/AlgorithmId/NonStandardNames.java                                         Passed. Execution successful
 sun/security/x509/AlgorithmId/NullParams.java                                               Passed. Execution successful
 sun/security/x509/AlgorithmId/OidTableInit.java                                             Passed. Execution successful
 sun/security/x509/AlgorithmId/OmitAlgIdParam.java                                           Passed. Execution successful
 sun/security/x509/AlgorithmId/PBES2.java                                                    Passed. Execution successful
 sun/security/x509/AlgorithmId/SHA256withECDSA.java                                          Passed. Execution successful
 sun/security/x509/AlgorithmId/TurkishRegion.java                                            Passed. Execution successful
 sun/security/x509/AlgorithmId/Uninitialized.java                                            Passed. Execution successful
 sun/security/x509/AlgorithmId/Uppercase.java                                                Passed. Execution successful
 sun/security/x509/CertificateValidity/NullName.java                                         Passed. Execution successful
 sun/security/x509/DNSName/LeadingPeriod.java                                                Passed. Execution successful
 sun/security/x509/EDIPartyName/NullName.java                                                Passed. Execution successful
 sun/security/x509/Extensions/BCNull.java                                                    Passed. Execution successful
 sun/security/x509/Extensions/DefaultCriticality.java                                        Passed. Execution successful
 sun/security/x509/Extensions/IllegalExtensions.java                                         Passed. Execution successful
 sun/security/x509/Extensions/IssuingDistributionPointExtensionEncoding.java                 Passed. Execution successful
 sun/security/x509/GeneralName/DNSNameTest.java                                              Passed. Execution successful
 sun/security/x509/GeneralName/Encode.java                                                   Passed. Execution successful
 sun/security/x509/GeneralName/X400Address.java                                              Passed. Execution successful
 sun/security/x509/IPAddressName/ConstrainsTest.java                                         Passed. Execution successful
 sun/security/x509/OtherName/Parse.java                                                      Passed. Execution successful
 sun/security/x509/URICertStore/AIACertTimeout.java                                          Passed. Execution successful
 sun/security/x509/URICertStore/CRLReadTimeout.java                                          Passed. Execution successful
 sun/security/x509/URICertStore/ExtensionsWithLDAP.java                                      Passed. Execution successful
 sun/security/x509/URIName/Parse.java                                                        Passed. Execution successful
 sun/security/x509/X500Name/AllAttribs.java                                                  Passed. Execution successful
 sun/security/x509/X500Name/DerValueConstructor.java                                         Passed. Execution successful
 sun/security/x509/X500Name/EmailKeyword.java                                                Passed. Execution successful
 sun/security/x509/X500Name/NullX500Name.java                                                Passed. Execution successful
 sun/security/x509/X500Name/PrintX500PrincipalInDebugModeWithAvaOption.java                  Passed. Execution successful
 sun/security/x509/X500Name/RDNwithMultipleAVAs.java                                         Passed. Execution successful
 sun/security/x509/X509CRLImpl/OrderAndDup.java                                              Passed. Execution successful
 sun/security/x509/X509CRLImpl/UnexpectedCCE.java                                            Passed. Execution successful
 sun/security/x509/X509CRLImpl/UnexpectedNPE.java                                            Passed. Execution successful
 sun/security/x509/X509CRLImpl/Verify.java                                                   Passed. Execution successful
 sun/security/x509/X509CertImpl/CertExtensions.java                                          Passed. Execution successful
 sun/security/x509/X509CertImpl/CertificateValidation.java                                   Passed. Execution successful
 sun/security/x509/X509CertImpl/ECSigParamsVerifyWithCert.java                               Passed. Execution successful
 sun/security/x509/X509CertImpl/GetFingerprintError.java                                     Passed. Execution successful
 sun/security/x509/X509CertImpl/V3Certificate.java                                           Passed. Execution successful
 sun/security/x509/X509CertImpl/Verify.java                                                  Passed. Execution successful
 sun/security/x509/equalNames/AltNamesEqualsTest.java                                        Passed. Execution successful
 tools/launcher/Settings.java                                                                Passed. Execution successful


    

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

PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2864282855

From ascarpino at openjdk.org  Thu May  8 21:01:16 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 8 May 2025 21:01:16 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
Message-ID: 

On Tue, 6 May 2025 20:52:14 GMT, Weijun Wang  wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
>> 
>>  - major code review comments update
>>  - Merge branch 'master' into pem
>>  - Merge branch 'master' into pem
>>  - javadoc updates
>>  - code review comments
>>  - merge with master
>>  - better comment and remove commented out code
>>  - Merge branch 'master' into pem
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327
>
> src/java.base/share/classes/java/security/PEMEncoder.java line 54:
> 
>> 52:  * and footer.
>> 53:  *
>> 54:  * 
     Encoding may be performed on Java Cryptographic Extension (JCE) objects
> 
> Is "JCE objects" a formal term? We used to say "JCA and JCE". How do we call them now?

I'd like to keep the JCA/JCE nuisances out.  I'd rather just leave it as is, or use the alternative I've used elsewhere, Java API cryptographic object.

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

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

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

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

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

  Address review feedbacks from Brad.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24393/files
  - new: https://git.openjdk.org/jdk/pull/24393/files/825aa221..5693ede4

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

  Stats: 73 lines in 7 files changed: 22 ins; 35 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24393/head:pull/24393

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

From weijun at openjdk.org  Thu May  8 21:31:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 May 2025 21:31:06 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

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

> 144: 
> 145:         try {
> 146:             return switch (pem.type()) {

Do you still allow `type` being null?

`PEMDecoder.of().decode("s")` throws an NPE.

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

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

From weijun at openjdk.org  Thu May  8 21:35:02 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 May 2025 21:35:02 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 <1NPCoy9RfTm6v7k1Nu3bjU-ntKn78gU3_mfDH7tFntg=.bf0a52ed-4f5d-4ab5-858b-dd1fbb635fbe@github.com>
 
Message-ID: 

On Thu, 8 May 2025 04:46:31 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMDecoder.java line 228:
>> 
>>> 226:      * 
    This method will read the {@code InputStream} until PEM data is
>>> 227:      * found or until the end of the stream.  Non-PEM data in the
>>> 228:      * {@code InputStream} before the PEM header will be ignored by the decoder.
>> 
>> This is not precise because you might put the leading data into a `PEMRecord`.
>> 
>> Also, I think it's very important to point out the pointer position of the input stream after this method is successfully called. Otherwise, the method cannot be reliably used in extracting multiple PEMs from a single stream.
>> 
>> Also, I'm not exactly sure what happens when there is nothing more to read.
>
> There is an inconsistency with PEMRecord here.  These methods should not allow leadingData if it is not available elsewhere.  I will redo that.  leadingData can be reserved for the decode methods that take a class.
> 
> I tried not to mention the pointer position.  My opinion is these methods should not have to describe the InputStream functionality.  I already state it returns a value after it finds PEM and I think one can figure this out.

See https://github.com/openjdk/jdk/blob/002679ac9fe4de8150b7dd4c9aeb44eeef1257d6/src/java.base/share/classes/java/security/cert/CertificateFactory.java#L338-L347

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

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

From jwaters at openjdk.org  Thu May  8 21:43:02 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 May 2025 21:43:02 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: 
References: 
 
Message-ID: <3JOhI_-acxlyIreUPgbY5reRbuy4o0Rdh99q9JDgkfw=.0d792d1c-b156-46e2-aa80-3c07d3c183fe@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters  wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Keep open

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2864379663

From lmesnik at openjdk.org  Thu May  8 23:12:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 23:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
 
Message-ID: 

On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth  wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> Maybe
>> Suggestion:
>> 
>> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)
>
> Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853

From lmesnik at openjdk.org  Fri May  9 00:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:55:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 
Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth  wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
>> 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
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990

From duke at openjdk.org  Fri May  9 03:17:43 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 9 May 2025 03:17:43 GMT
Subject: RFR: 8310003: Improve logging when default truststore is
 inaccessible [v3]
In-Reply-To: 
References: 
Message-ID: <_SiroGvbfmV3MbRpohDsHKK6H0Pk65qZk3m5VZfBdII=.df0ac16c-dc69-4c08-a925-ee4e61053234@github.com>

> If the truststore is unavailable, JDK does not log information for 'trustStore provider is:'. We are now adding 'unspecified' instead of keeping empty.

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

  8310003: Improve logging when default truststore is inaccessible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25077/files
  - new: https://git.openjdk.org/jdk/pull/25077/files/c41c7a8f..9b950de0

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

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

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

From dholmes at openjdk.org  Fri May  9 04:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 04:57:50 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in.

** though another option would be to update the jtreg default timeout instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247

From wetmore at openjdk.org  Fri May  9 05:12:30 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 9 May 2025 05:12:30 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v9]
In-Reply-To: 
References: 
Message-ID: <9IX-GFMX9JOE-brPukm4qw0mmMqg0kpCizxzVw5shUM=.ffebf952-0da5-4c37-98a7-ac6f5080317d@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/2e5f5342..598fc579

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=07-08

  Stats: 275 lines in 3 files changed: 188 ins; 19 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From dfuchs at openjdk.org  Fri May  9 07:18:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 07:18:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs  wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
> It would be good to flush out any such intermittent failures before this PR is integrated.
> This might require multiple runs before we can get confidence.

Results came back - another intermittent timeout failure (much more frequent) observed in:
`java/net/httpclient/CancelledResponse.java` on macOS x64

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003

From cstein at openjdk.org  Fri May  9 07:36:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 07:36:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 May 2025 04:54:52 GMT, David Holmes  wrote:

> [...]
> ** though another option would be to update the jtreg default timeout instead.

And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908

From alanb at openjdk.org  Fri May  9 08:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth  wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
>> 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
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ?  If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927

From vyazici at openjdk.org  Fri May  9 08:31:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 9 May 2025 08:31:35 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/4d237efa..121005ee

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

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

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

From vyazici at openjdk.org  Fri May  9 08:31:38 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 9 May 2025 08:31:38 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 8 May 2025 14:46:29 GMT, Chen Liang  wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prefix touched methods with `unchecked`
>
> src/java.base/share/classes/java/io/DataInputStream.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/java/io/ObjectInputStream.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/java/util/HexFormat.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/java/util/zip/ZipCoder.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/jdk/internal/math/ToDecimal.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/CESU_8.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/DoubleByte.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/SingleByte.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/US_ASCII.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/share/classes/sun/nio/cs/UTF_8.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

> src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 1:
> 
>> 1: /*
> 
> Copyright year

Fixed in 121005eed50.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190069
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190301
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190552
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190701
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190811
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081190928
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191033
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191280
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191511
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191686
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081191903
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081192125
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081192310
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2081192487

From lkorinth at openjdk.org  Fri May  9 08:32:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:32:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966

From vyazici at openjdk.org  Fri May  9 08:33:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 9 May 2025 08:33:58 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 8 May 2025 14:51:48 GMT, Chen Liang  wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prefix touched methods with `unchecked`
>
> Let's re-approve after copyright fix.

@liach, @minborg, I've fixed the copyright years. I'd appreciate it if you can approve one last time.

This last copyright year fiasco made me do this:


alias git-license-year-violations='git diff --name-only upstream/master...HEAD | { y=$(date +%Y); while read f; do grep -qE "Copyright \(c\)( [0-9]{4},)? $y, Oracle" $f || echo $f; done; }'

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

PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2865648371

From lkorinth at openjdk.org  Fri May  9 08:42:58 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:42:58 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs  wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence.

My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. 

The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066

From stefank at openjdk.org  Fri May  9 08:48:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 08:48:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 
 
 
Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth  wrote:

> My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.

Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701

From lkorinth at openjdk.org  Fri May  9 09:02:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:02:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 
Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>

On Thu, 8 May 2025 20:00:21 GMT, Phil Race  wrote:

> test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
>     * * @run main/timeout=300/othervm MTTest
> 
> 
>     * * @run main/timeout=1200/othervm MTTest
> 
> 
> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
> So 300 was fine, and 1200 isn't needed.

I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871

From lkorinth at openjdk.org  Fri May  9 09:12:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:12:19 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: 
 
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth  wrote:

>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> - * @run main/timeout=300/othervm MTTest
>> + * @run main/timeout=1200/othervm MTTest
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
>
>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>>     * * @run main/timeout=300/othervm MTTest
>> 
>> 
>>     * * @run main/timeout=1200/othervm MTTest
>> 
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

> @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times?

At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064

From cstein at openjdk.org  Fri May  9 09:15:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:15:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
References: 
 
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
 <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
Message-ID: 

On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth  wrote:

> At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork.

Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769

From lkorinth at openjdk.org  Fri May  9 09:15:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:15:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
References: 
 
 
 
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
Message-ID: 

On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson  wrote:

> > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> 
> Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195

From stefank at openjdk.org  Fri May  9 09:19:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 09:19:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 
 
 
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
 
Message-ID: 

On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth  wrote:

> > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> > 
> > 
> > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?
> 
> I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474

From dfuchs at openjdk.org  Fri May  9 09:33:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 09:33:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth  wrote:

> The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069

From myankelevich at openjdk.org  Fri May  9 10:31:19 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 9 May 2025 10:31:19 GMT
Subject: RFR: 8349151: Refactor
 test/java/security/cert/CertificateFactory/slowstream.sh to java test [v4]
In-Reply-To: 
References: 
Message-ID: <5ZmMOpXoDcEZoB1o8Vsaj8ji-daZtT2lu36CO1dMhWM=.198199d6-086f-43d7-946b-5f8e87233c42@github.com>

> Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test

Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - further cleanup
 - Merge branch 'master' into JDK-8349151
 - Rajan's comments
 - cleanup
 - JDK-8349151: Refactor test/java/security//cert/CertificateFactory/slowstream.sh to java test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23394/files
  - new: https://git.openjdk.org/jdk/pull/23394/files/520fcde6..763b07c8

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

  Stats: 221560 lines in 5040 files changed: 100237 ins; 92140 del; 29183 mod
  Patch: https://git.openjdk.org/jdk/pull/23394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23394/head:pull/23394

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

From myankelevich at openjdk.org  Fri May  9 10:31:19 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 9 May 2025 10:31:19 GMT
Subject: RFR: 8349151: Refactor
 test/java/security/cert/CertificateFactory/slowstream.sh to java test [v3]
In-Reply-To: 
References: 
 <9rReYxqW4qnmKvsXfs5dEjS-5Gt42Hu81rcCWpAVxWw=.a3570973-c6c5-45ce-b27d-70776f3d1fa6@github.com>
 
Message-ID: <0nBUV4FVbgZLppIn8WPpzc2e-qskB_yXNu_5kfOqOWQ=.2b2b860a-8158-428c-981d-dbf9a0acccaa@github.com>

On Thu, 8 May 2025 11:38:55 GMT, Weijun Wang  wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rajan's comments
>
> test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 28:
> 
>> 26:  * @bug 6813340
>> 27:  * @summary X509Factory should not depend on is.available()==0
>> 28:  * @run main/othervm SlowStream
> 
> Why `othervm`?

Removed in the next commit

> test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 53:
> 
>> 51:                             "pem"))) {
>> 52: 
>> 53:                         final byte[] buffer = new byte[4096];
> 
> This test was probably written very log ago where there was no NIO or `InputStream::readAllBytes`. The file itself is quite small and there is no need to read in blocks. You can use modern methods like `Files::readAllBytes` or `InputStream::transferTo`.

changed in the next commit

> test/jdk/java/security/cert/CertificateFactory/SlowStream.java line 75:
> 
>> 73:             try {
>> 74:                 final var factory = CertificateFactory.getInstance("X.509");
>> 75:                 final var factorySize = factory.generateCertificates(inputStream).size();
> 
> Please change the variable name to something like `numOfCerts`.

Changed in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2081399746
PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2081399549
PR Review Comment: https://git.openjdk.org/jdk/pull/23394#discussion_r2081399274

From dholmes at openjdk.org  Fri May  9 12:21:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 12:21:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479

From lkorinth at openjdk.org  Fri May  9 12:51:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers.  I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937.

Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573

From lkorinth at openjdk.org  Fri May  9 13:06:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 13:06:01 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth  wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Changing the timeout factor might be preferable to do after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008

From mullan at openjdk.org  Fri May  9 13:26:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 13:26:53 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang  wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tuning debug log and exception message

We should also update the comments and info string of `com/sun/crypto/provider/SunJCE.java` with the HKDF algorithms.

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

PR Comment: https://git.openjdk.org/jdk/pull/24520#issuecomment-2866532132

From mullan at openjdk.org  Fri May  9 14:03:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 14:03:07 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

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

> 68:  * the returned key object from a PEM containing a public and private key.
> 69:  * If only the private key is required, {@code PrivateKey.class} can be used.
> 70:  * {@class PEMRecord.class} is used for returning PEM text. If {@code tClass}

This causes a javadoc error, I think you meant `@code` instead of `@class`.

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

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

From dfuchs at openjdk.org  Fri May  9 14:39:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 14:39:53 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
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 422 commits:

 - merge latest changes from master branch
 - Undo whitespace change
 - Remove unnecessary import
 - Merge remote-tracking branch 'origin/master' into http3
 - Fix test license
 - Remove leftover file (test was moved to parent directory)
 - Remove unnecessary import
 - Update throws clauses
 - Merge remote-tracking branch 'origin/master' into http3
 - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
 - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=04
  Stats: 103018 lines in 469 files changed: 100164 ins; 1347 del; 1507 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From mullan at openjdk.org  Fri May  9 15:30:10 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 15:30:10 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: <7dEojWauO8Can1PEp7tJYCmHiaVSK80JDJmU4y1W7dY=.479f02c5-92b7-4ade-8391-65cbb1a349db@github.com>

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

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

> 42: 
> 43: /**
> 44:  * {@code PEMDecoder} is used for decoding Privacy-Enhanced Mail (PEM) data.

"is used" doesn't sound right. I would suggest changing "is used" to "implements a decoder" which is consistent with the `Base64.Decoder` class.

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

> 49:  * and footer.
> 50:  *
> 51:  * 
     Decoding methods return an instance of a class that matches the data

You should say the specific decode methods that return `DEREncodable` objects, as you are not talking about the decode methods that take Class params here. Suggest: "The {@linkplain #decode(String)} and {@linkplain #decode(InputStream)} methods ..."

Also I think you can remove "unless otherwise specified" because the next sentence says what happens if the PEM does not have an API for it. So that is the only other case.

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

> 60:  * 
     If the PEM does not have a JCE object representation, it returns a
> 61:  * {@link PEMRecord}. Any PEM can be decoded into a {@code PEMRecord} if the
> 62:  * class is specified.

I would move the second sentence to later after you descibe the `decode` methods that take a `Class` param.

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

> 62:  * class is specified.
> 63:  *
> 64:  * For decode methods that accept a {@code Class tClass} as input, they can

Start a new paragraph. Suggest rewording the beginning as "The `{@linkplain #decode(String, Class) }` and `{@linkplain #decode(InputStream, Class)}` methods take a `Class` parameter which determines the type of `DerEncodable` that is returned. These methods are useful when ..."

Then you can insert the sentence above somewhere towards the end of this paragraph: "Any type of PEM data can be decoded into a `{@code PEMRecord}` by specifying `{@code PEMRecord.class}` as a parameter."

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

> 77:  * Configuring an instance for decryption does not prevent decoding with
> 78:  * unencrypted PEM. Any encrypted PEM that does not use the configured password
> 79:  * will throw an {@link RuntimeException}.

s/an/a/

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

> 91: 
> 92:  * @apiNote
> 93:  * Here is an example of decoding a PrivateKey object:

Put `@code` around PrivateKey.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081858947
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081897903
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081903041
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081903359
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081921762
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081926584

From mullan at openjdk.org  Fri May  9 15:30:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 15:30:11 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
Message-ID: <7kM3yKgy3cBOoO35MiqVW2IKIv7WptRRPWTf5vXOZMA=.b0c57b98-07c5-4c4c-8a53-b39c2e4923b3@github.com>

On Thu, 8 May 2025 04:09:02 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMDecoder.java line 71:
>> 
>>> 69:  * with {@linkplain #withFactory} and/or {@linkplain #withDecryption}.
>>> 70:  * Configuring an instance for decryption does not prevent decoding with
>>> 71:  * unencrypted PEM. Any encrypted PEM that does not use the configured password
>> 
>> I found the last 3 sentences a bit jumping too quickly into details. I suggest having 2 sentences after the first one, where each sentence explains what the `withDecryption` and `withFactory` methods do, respectively.
>
> I split them and reworded it, HTH.

What I was suggesting was to have an additional sentence first describing what each of these methods is for. I'll suggest something later.

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

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

From bperez at openjdk.org  Fri May  9 15:42:03 2025
From: bperez at openjdk.org (Ben Perez)
Date: Fri, 9 May 2025 15:42:03 GMT
Subject: RFR: 8347608: Optimize Java implementation of ML-KEM
Message-ID: <6iw4o72iY3dxyq3RoqAekbps7PRooru3W6Fn2mu4NKk=.a13667bc-454b-4cb3-a06e-5c7b137d3c6d@github.com>

Added custom multi array allocation function to improve performance

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

Commit messages:
 - changed multiarray allocation to improve performance

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

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

From alanb at openjdk.org  Fri May  9 15:50:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 15:50:52 GMT
Subject: RFR: 8347608: Optimize Java implementation of ML-KEM
In-Reply-To: <6iw4o72iY3dxyq3RoqAekbps7PRooru3W6Fn2mu4NKk=.a13667bc-454b-4cb3-a06e-5c7b137d3c6d@github.com>
References: <6iw4o72iY3dxyq3RoqAekbps7PRooru3W6Fn2mu4NKk=.a13667bc-454b-4cb3-a06e-5c7b137d3c6d@github.com>
Message-ID: 

On Fri, 9 May 2025 15:37:44 GMT, Ben Perez  wrote:

> Added custom multi array allocation function to improve performance

Are you planning to include a micro and sample results?

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

PR Comment: https://git.openjdk.org/jdk/pull/25151#issuecomment-2867062412

From mullan at openjdk.org  Fri May  9 16:45:08 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 16:45:08 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs  wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request 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:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

src/java.base/share/classes/java/net/HttpURLConnection.java line 615:

> 613:      */
> 614:     @Deprecated(since = "25", forRemoval = true)
> 615:     @SuppressWarnings("removal")

Do you still need this annotation now that `SocketPermission` is not deprecated for removal?

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 214:

> 212:      */
> 213:     @Override
> 214:     @Deprecated(since = "25", forRemoval = true)

Is this annotation required or more as a reminder that the superclass method is deprecated?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2082086475
PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2082050913

From weijun at openjdk.org  Fri May  9 18:00:05 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 May 2025 18:00:05 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/java/security/PEMRecord.java line 87:

> 85:      */
> 86:     public PEMRecord(String type, String pem, byte[] leadingData) {
> 87:         this.leadingData = (leadingData == null ? null : leadingData.clone());

Not sure we should do the cloning at creation and in the getter. A record is _known_ to be only shallowly immutable and users should be prepared for this, for example, do not pass it to an untrusted method if they want to reuse it. I'd rather change this back to a normal class if you believe array cloning is necessary.

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

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

From mullan at openjdk.org  Fri May  9 18:03:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 18:03:06 GMT
Subject: RFR: 8310003: Improve logging when default truststore is
 inaccessible [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 May 2025 18:00:14 GMT, Koushik Muthukrishnan Thirupattur  wrote:

>> If the truststore is unavailable, JDK does not log information for 'trustStore provider is:'. We are now adding 'unspecified' instead of keeping empty.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8310003: Improve logging when default truststore is inaccessible

Please add a noreg label to the bug since there is no test.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25077#pullrequestreview-2829288649

From duke at openjdk.org  Fri May  9 18:03:06 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 9 May 2025 18:03:06 GMT
Subject: RFR: 8310003: Improve logging when default truststore is
 inaccessible [v4]
In-Reply-To: 
References: 
Message-ID: 

> If the truststore is unavailable, JDK does not log information for 'trustStore provider is:'. We are now adding 'unspecified' instead of keeping empty.

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

  8310003: Improve logging when default truststore is inaccessible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25077/files
  - new: https://git.openjdk.org/jdk/pull/25077/files/9b950de0..73992c88

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

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

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

From duke at openjdk.org  Fri May  9 18:06:54 2025
From: duke at openjdk.org (duke)
Date: Fri, 9 May 2025 18:06:54 GMT
Subject: RFR: 8310003: Improve logging when default truststore is
 inaccessible [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 May 2025 18:03:06 GMT, Koushik Muthukrishnan Thirupattur  wrote:

>> If the truststore is unavailable, JDK does not log information for 'trustStore provider is:'. We are now adding 'unspecified' instead of keeping empty.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8310003: Improve logging when default truststore is inaccessible

@koushikthirupattur 
Your change (at version 73992c882033ca099cc92164b654b8b6259f9e39) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25077#issuecomment-2867508743

From weijun at openjdk.org  Fri May  9 18:09:05 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 May 2025 18:09:05 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

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

> 64:  * For decode methods that accept a {@code Class tClass} as input, they can
> 65:  * modify the return type to a specific {@code DEREncodable} subclass.
> 66:  * For example, {@code ECPublicKey.class} can be used to cast a

The "modify" and "cast" words seem to reveal some implementation detail. It's just "parsing the input as the specified type".

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

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

From weijun at openjdk.org  Fri May  9 18:19:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 May 2025 18:19:06 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

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

> 405:      * the default provider configuration.
> 406:      *
> 407:      * @param provider the factory provider.

This is a little awkward because the argument of `withFactory` is a provider. Shall we rename it?

Also, can we add some more description on how this method is used? For example, suppose a provider named `P1` extends `ECPublicKey` to `P1ECPublicKey`, then users should call `withFactory(p1).decode(pem, P1ECPublicKey.class)`. I assume we are not ready to do some kind of "delayed provider selection" trick to make it possible with the "original" decoder.

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

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

From mullan at openjdk.org  Fri May  9 18:32:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 18:32:07 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

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

> 89:  *
> 90:  * 
    This class is immutable and thread-safe.
> 91: 

Missing `*`.

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

> 129:      * Returns an instance of {@code PEMDecoder}.
> 130:      *
> 131:      * @return returns a {@code PEMDecoder}

you don't need to say "returns", just say "a `PEMDecoder`"

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

> 188:                         getKey(password.getPassword());
> 189:                 }
> 190:                 case Pem.CERTIFICATE, Pem.X509_CERTIFICATE -> {

What about the "X.509 CERTIFICATE" header which is also mentioned in RFC 7468?

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

> 189:                 }
> 190:                 case Pem.CERTIFICATE, Pem.X509_CERTIFICATE -> {
> 191:                     CertificateFactory cf = getCertFactory("X509");

Use "X.509". "X509" is an alias and may not be supported by other JDK implementations. Same comment on line 196.

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

> 198:                         new ByteArrayInputStream(decoder.decode(pem.pem())));
> 199:                 }
> 200:                 case Pem.RSA_PRIVATE_KEY -> {

Is it necessary to support this? It is not mentioned in RFC 7468.

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

> 218:      * the decoder.
> 219:      *
> 220:      * @param str a String containing PEM data.

General style comment throughout APIs: no period necessary at end when `@param`, `@return`, or `@throws` starts with a non-capital letter and no sentence follows.

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

> 221:      * @return a {@code DEREncodable} generated from the PEM data.
> 222:      * @throws IllegalArgumentException on error in decoding or if the PEM is
> 223:      * unsupported.

If the PEM is unsupported, you return a `PEMRecord` now, so you can remove those words. Same comment on lines 248-249.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082244005
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082246420
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082255980
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082251527
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082258814
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082307742
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082312862

From dfuchs at openjdk.org  Fri May  9 19:21:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 19:21:56 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 9 May 2025 16:42:31 GMT, Sean Mullan  wrote:

>> Daniel Fuchs 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:
>> 
>>  - Merge branch 'master' into deprecate-net-perms-8353642
>>  - Revert changes to SocketPermission and CodeSource
>>  - Review feedback. Deprecate getPermission for removal.
>>  - Missing white spaces
>>  - 8353642: Deprecate networking permission classes for removal
>
> src/java.base/share/classes/java/net/HttpURLConnection.java line 615:
> 
>> 613:      */
>> 614:     @Deprecated(since = "25", forRemoval = true)
>> 615:     @SuppressWarnings("removal")
> 
> Do you still need this annotation now that `SocketPermission` is not deprecated for removal?

Ah - good point - I will double check.

> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 214:
> 
>> 212:      */
>> 213:     @Override
>> 214:     @Deprecated(since = "25", forRemoval = true)
> 
> Is this annotation required or more as a reminder that the superclass method is deprecated?

I think it's needed because the superclass method is deprecated for removal. Will double check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2082374190
PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2082374078

From duke at openjdk.org  Fri May  9 19:23:01 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 9 May 2025 19:23:01 GMT
Subject: Integrated: 8310003: Improve logging when default truststore is
 inaccessible
In-Reply-To: 
References: 
Message-ID: 

On Wed, 7 May 2025 03:45:06 GMT, Koushik Muthukrishnan Thirupattur  wrote:

> If the truststore is unavailable, JDK does not log information for 'trustStore provider is:'. We are now adding 'unspecified' instead of keeping empty.

This pull request has now been integrated.

Changeset: 68a11850
Author:    Koushik Thirupattur 
Committer: Sean Mullan 
URL:       https://git.openjdk.org/jdk/commit/68a118509a562334eb8c099129d79520041b10cf
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310003: Improve logging when default truststore is inaccessible

Reviewed-by: mullan

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

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

From prr at openjdk.org  Fri May  9 19:24:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 19:24:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: 
 
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: 

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth  wrote:

> > test/jdk/java/awt/font/NumericShaper/MTTest.java
> > ```
> > * * @run main/timeout=300/othervm MTTest
> > 
> > 
> > * * @run main/timeout=1200/othervm MTTest
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> > So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176

From weijun at openjdk.org  Fri May  9 20:05:10 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 May 2025 20:05:10 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]
In-Reply-To: 
References: 
Message-ID: 

> Finalize the KDF API.

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

  new algorithms in SunJCE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/f44dc9bd..aeb82ccf

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

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

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

From weijun at openjdk.org  Fri May  9 20:21:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 May 2025 20:21:04 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/java/security/PEMRecord.java line 69:

> 67:  * @see PEMEncoder
> 68:  */
> 69: public record PEMRecord(String type, String pem, byte[] leadingData)

Add `@PreviewFeature`.

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

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

From wetmore at openjdk.org  Fri May  9 21:38:07 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 9 May 2025 21:38:07 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: 
References: 
Message-ID: 

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into JDK-8341346
 - Adjustments made for JDK-8350830
 - Merge branch 'master' into JDK-8341346
 - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
 - More Codereview comments
 - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
 - Add in the SharedSecrets SecretKeySpec clearing mechanism
 - More codereview/CSR comments
 - Merge branch 'master' into JDK-8341346
 - Codereview comments.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=09
  Stats: 1096 lines in 8 files changed: 1076 ins; 3 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From weijun at openjdk.org  Fri May  9 23:49:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 May 2025 23:49:04 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/java/security/PEMRecord.java line 51:

> 49:  * reached the end of the stream. If there is PEM data, {@code type} and
> 50:  * {@code pem} will both be non-null. {@code leadingData} may be null if the
> 51:  * input data only contains PEM data. All values can never be null.

It feels like the 2 paragraphs above should be in the spec of `Decoder::decode`. Here we only need to say what fields can be null.

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

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

From ascarpino at openjdk.org  Sat May 10 02:15:14 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 10 May 2025 02:15:14 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
Message-ID: 

On Mon, 5 May 2025 14:30:12 GMT, Sean Mullan  wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
>> 
>>  - major code review comments update
>>  - Merge branch 'master' into pem
>>  - Merge branch 'master' into pem
>>  - javadoc updates
>>  - code review comments
>>  - merge with master
>>  - better comment and remove commented out code
>>  - Merge branch 'master' into pem
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327
>
> src/java.base/share/classes/java/security/PEMEncoder.java line 57:
> 
>> 55:  * that implement {@link DEREncodable} and support
>> 56:  * {@linkplain PKCS8EncodedKeySpec PKCS#8} or
>> 57:  * {@linkplain X509EncodedKeySpec X509} formats.
> 
> The "and" in "and support {@linkplain PKCS8EncodedKeySpec PKCS#8} or {@linkplain X509EncodedKeySpec X509} formats" is too strong, ex - X509Certificate & X509CRL do not support those keyspecs. I would suggest deleting this part about "and support" as it is doesn't seem necessary.

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 64:
> 
>> 62:  *
>> 63:  * 
     PKCS8 2.0 allows OneAsymmetricKey encoding, which may contain both private
>> 64:  * and public keys in the same PEM.This is supported by using the
> 
> Add space before "This".

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 118:
> 
>> 116: 
>> 117:     /**
>> 118:      * Returns a new instance of PEMEncoder.
> 
> put code around PEMEncoder.

Yes

> src/java.base/share/classes/java/security/PEMEncoder.java line 120:
> 
>> 118:      * Returns a new instance of PEMEncoder.
>> 119:      *
>> 120:      * @return PEMEncoder instance
> 
> s/PEMEncoder/a PEMEncoder/
> 
> Use code font for PEMEncoder, also in method description.

yes

> src/java.base/share/classes/java/security/PEMEncoder.java line 122:
> 
>> 120:      * @return PEMEncoder instance
>> 121:      */
>> 122:     static public PEMEncoder of() {
> 
> "public" should be before "static".

yes

> src/java.base/share/classes/java/security/PEMEncoder.java line 133:
> 
>> 131:      *           {@code DEREncodable}.
>> 132:      * @return PEM encoding in a String
>> 133:      * @throws IllegalArgumentException when the passed object returns a null
> 
> When would a DEREncodable return a null encoding? I think it should never return this under normal circumstances. I think we should not specifically mention this case, and be more general like "if the object cannot be encoded for some reason".

Yeah.  It took me a bit to realize it meant `getEncoded()` is null.
I also think the part about encryption is unnecessary.

> src/java.base/share/classes/java/security/PEMEncoder.java line 199:
> 
>> 197: 
>> 198:     /**
>> 199:      * Encodes a given {@code DEREncodable} into PEM.
> 
> Suggest: 
> 
> s/a given/the specified/

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 207:
> 
>> 205:      * configured for encryption while encoding a {@code DEREncodable} that does
>> 206:      * not support encryption.
>> 207:      * @throws NullPointerException when object passed is null.
> 
> Wording suggestion: "if {@code de} is {@code null}"

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 215:
> 
>> 213: 
>> 214:     /**
>> 215:      * Returns a new immutable PEMEncoder instance configured to the default
> 
> I don't think you need to say "immutable" as the first sentence of the class description already says PEMEncoder objects are immutable.
> 
> s/configured to/configured with/

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 216:
> 
>> 214:     /**
>> 215:      * Returns a new immutable PEMEncoder instance configured to the default
>> 216:      * encryption algorithm and a given password.
> 
> s/a given/the specified/

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 229:
> 
>> 227:      *
>> 228:      * @param password sets the encryption password.  The array is cloned and
>> 229:      *                stored in the new instance. {@code null} is a valid entry.
> 
> s/entry/value/

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 230:
> 
>> 228:      * @param password sets the encryption password.  The array is cloned and
>> 229:      *                stored in the new instance. {@code null} is a valid entry.
>> 230:      * @return a new PEMEncoder
> 
> Put code around PEMEncoder.

ok

> src/java.base/share/classes/java/security/PEMRecord.java line 53:
> 
>> 51:  * {@code type} or {@code pem}.
>> 52:  *
>> 53:  * @param type The type identifier in the PEM header.  For a public key,
> 
> parameter descriptions should not start with a capital letter. Same comment for the params in the ctors.

ok

> src/java.base/share/classes/java/security/PEMRecord.java line 67:
> 
>> 65: 
>> 66:     /**
>> 67:      * Return a PEMRecord instance with the given parameters.
> 
> s/Return/Creates/    (same comment for all ctors)
> PEMRecord should be in code font.

ok

> src/java.base/share/classes/java/security/PEMRecord.java line 71:
> 
>> 69:      * 
     When {@code type} is given a properly formatted PEM header, only the
>> 70:      * identifier will be set (ie: {@code PUBLIC KEY}).  Otherwise, {@code type}
>> 71:      * will be set to what was passed in.
> 
> Put PUBLIC KEY in double quotes so it is clear this is a String.
> 
> I'm not sure I understand this paragraph - will the dashes be included if the type is not understood? If not, why do we need this paragraph at all?

That paragraph needs to be removed, it was functionality that was removed during code review.

> src/java.base/share/classes/java/security/PEMRecord.java line 75:
> 
>> 73:      * 
     When {@code type} is given a correctly formatted PEM header, only the
>> 74:      * identifier is set (for example, {@code PUBLIC KEY}). Otherwise,
>> 75:      * {@code type} is set to the value that was passed in.
> 
> Duplicate paragaraph as first.

Yeah.  I guess I was editing it and didn't go back

> src/java.base/share/classes/java/security/PEMRecord.java line 78:
> 
>> 76:      *
>> 77:      * @param type The type identifier in the PEM header and footer.
>> 78:      *             If there is no PEM data, this value will be {@code null}.
> 
> Suggest rewording as "the type identifier in the PEM header and footer, or {@code null} if there is no PEM data." Same comment for other ctors.

ok

> src/java.base/share/classes/java/security/PEMRecord.java line 137:
> 
>> 135:     /**
>> 136:      * Returns the binary encoding from the Base64 data contained in
>> 137:      * {@code pem}.
> 
> Should say that it returns a new copy each time it is called.

ok

> src/java.base/share/classes/java/security/PEMRecord.java line 139:
> 
>> 137:      * {@code pem}.
>> 138:      *
>> 139:      * @throws IllegalArgumentException if {@code pem} could not be decoded.
> 
> s/could not/cannot/

ok

> src/java.base/share/classes/java/security/PEMRecord.java line 140:
> 
>> 138:      *
>> 139:      * @throws IllegalArgumentException if {@code pem} could not be decoded.
>> 140:      * @return binary encoding or null if {@code pem} is null.
> 
> s/binary/the binary/

ok

> src/java.base/share/classes/java/security/spec/EncodedKeySpec.java line 63:
> 
>> 61:      * This constructor extracts the algorithm name from the encoded bytes,
>> 62:      * which may be an OID if no standard algorithm name is defined. If the
>> 63:      * algorithm name cannot be extracted, it is set to null.
> 
> Hmm, I think this is leaking details about DER encoding into this abstract class which does not make any assumptions about the type of encoding used. Have you considered only parsing the encoding in the `X509EncodedKeySpec` and `PKCS8EncodedKeySpec` subclasses which are DER specific?

Well, [JEP 513](https://openjdk.org/jeps/513) will make it possible to limit it to those two EPSs when it integrates.  Right now P8EPS and X509EPS are dependent on super() call and would require duplicating the static final variables and overriding all the methods.

What I can do right now is document it in P8EPS and X509EPS, but leave the code in EPS until the JEP integrates.

> src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java line 41:
> 
>> 39:  *   privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
>> 40:  *   privateKey PrivateKey,
>> 41:  *   attributes       [0] IMPLICIT Attributes OPTIONAL,
> 
> IMPLICIT has been removed in RFC 5958. Also to be consistent with 5958, I think you should change `PrivateKeyInfo` to `OneAsymmetricKey` and add an addtional line with `PrivateKeyInfo ::= OneAsymmetricKey`.

Ok.

Whats the reason `PrivateKeyInfo` have @code on it. It's not a class or a method.  It's just a term.

> src/java.base/share/classes/sun/security/ec/ECKeyFactory.java line 245:
> 
>> 243:                 throw new InvalidKeySpecException("Only ECPrivateKeySpec " +
>> 244:                     "and PKCS8EncodedKeySpec supported for EC private keys. " +
>> 245:                     keySpec.getClass().getName() + " provided.");
> 
> How about using the message "keySpec.getClass().getName() + " not supported." as on lines 223-224?

Less specific.. interesting.  I'm ok with that.

> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 79:
> 
>> 77: 
>> 78:     /* PKCS8 version of the PEM */
>> 79:     protected int version;
> 
> Do these need to be protected? It doesn't seem like any subclasses need them.

I think I wanted to use it in the subclasses, but later realized the subclasses needed to parse it again anyway for algorithms-specific values.  I can make it private.

> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 193:
> 
>> 191:      *
>> 192:      * @param encoded the DER-encoded SubjectPublicKeyInfo value
>> 193:      * @exception IOException on data format errors
> 
> Change to `InvalidKeyException`.

ok

> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 243:
> 
>> 241:     }
>> 242: 
>> 243:     public byte[] getPrivKeyMaterial() {
> 
> Do we really need this method, esp since it is the private key? I can't find any code that calls this.

It certainly was used in previous changesets.  I guess it's not needed anymore.

> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 305:
> 
>> 303:             } catch (IOException e) {
>> 304:                 // encodedKey is still null
>> 305:                 throw new SecurityException(e);
> 
> Should return null instead since that is what `getEncoded()` specifies.

Sure.  I think some of the internal exception usage could be better.  There is a lot of IOException that I may have when the API was throwing IOE.  But that can be done at a later date.

> src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java line 345:
> 
>> 343:         } else {
>> 344:             throw new InvalidKeySpecException("Only RSAPublicKeySpec "
>> 345:                 + "and X509EncodedKeySpec supported for RSA public keys");
> 
> Update exception message to `keySpec.getClass().getName() + " not supported."` as you did in `EdDSAKeyFactory`.

ok

> src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line 362:
> 
>> 360:      * @throws InvalidKeyException on decoding failure
>> 361:      */
>> 362: 
> 
> nit: remove blank line

ok

> src/java.base/share/classes/sun/security/util/Pem.java line 56:
> 
>> 54:     private static ObjectIdentifier PBES2OID;
>> 55: 
>> 56:     // Lazy initialize singleton encoder.
> 
> s/initialize/initialized/

ok

> src/java.base/share/classes/sun/security/util/Pem.java line 301:
> 
>> 299:      * @return the string
>> 300:      */
>> 301:     public static String pemEncoded(String type, byte[] data) {
> 
> You could refactor the common code in these two methods into a separate method and call that with the type and data.

ok

> src/java.base/share/classes/sun/security/x509/X509Key.java line 354:
> 
>> 352:         } catch (NoSuchAlgorithmException | InvalidKeySpecException e) {
>> 353:             // Ignore and return raw key
>> 354:             throw new IOException("error with encoding");
> 
> How about also including the cause?

Actually that was commented out code.  I think from recent change from another comment.

> src/java.base/share/conf/security/java.security line 1557:
> 
>> 1555: #
>> 1556: # This property defines default Public-based Encryption algorithm for
>> 1557: # java.security.PEMEncoder is configured for encryption with `withEncryption()`.
> 
> Suggested rewording:
> 
> This property defines the default password-based encryption algorithm for
> java.security.PEMEncoder when configured for encryption with the withEncryption method.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080475124
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080496453
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081992933
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081993198
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081994443
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082020210
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082026290
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082027354
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082028812
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082029044
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082371118
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082371947
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082382671
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082389619
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082394217
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082394464
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082421165
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082460595
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082460532
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082462341
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082469178
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082559879
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082722909
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082740293
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082741382
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082744160
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082751861
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082752247
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082752463
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082752768
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082759301
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082760120
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082760765

From ascarpino at openjdk.org  Sat May 10 02:15:15 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 10 May 2025 02:15:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
Message-ID: 

On Tue, 6 May 2025 20:56:32 GMT, Weijun Wang  wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
>> 
>>  - major code review comments update
>>  - Merge branch 'master' into pem
>>  - Merge branch 'master' into pem
>>  - javadoc updates
>>  - code review comments
>>  - merge with master
>>  - better comment and remove commented out code
>>  - Merge branch 'master' into pem
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327
>
> src/java.base/share/classes/java/security/PEMEncoder.java line 59:
> 
>> 57:  * {@linkplain X509EncodedKeySpec X509} formats.
>> 58:  *
>> 59:  * 
     Encrypted private key PEM data can be built by calling the encode methods
> 
> I understand "encode methods" here mean `encode` and `encodeToString`, but at this early place in the specification no one knows about those methods yet. Does it make sense to append several sentences at the end of the previous paragraph saying something similar to "call encode to encode, call encodeToString to encode to string".

The paragraph focus is about EKPI, not the encoding methods. I can just remove the references to the methods.

> src/java.base/share/classes/java/security/PEMEncoder.java line 63:
> 
>> 61:  * by passing an {@link EncryptedPrivateKeyInfo} object into the encode methods.
>> 62:  *
>> 63:  * 
     PKCS8 2.0 allows OneAsymmetricKey encoding, which may contain both private
> 
> It's "PKCS #8". Enclose `OneAsymmetricKey` in ``.

Sure on the #8, but I don't think the enclosing is appropriate since it's not a class or field.  It's just a format.  Like I don't enclose "PEM"

> src/java.base/share/classes/java/security/PEMEncoder.java line 70:
> 
>> 68:  * {@linkplain PEMRecord#pem()} with a generated the PEM header and footer
>> 69:  * from {@linkplain PEMRecord#type()}.  It will not check the validity of
>> 70:  * the data.
> 
> Since you mention `PEMRecord` specifically, I'd see the clarification that the `leadingData` there will not be encoded. Otherwise, you cannot guarantee on the encoding.

I think specifying the fields that are encoded makes it clear what is not in the encoding.

> src/java.base/share/classes/java/security/PEMEncoder.java line 75:
> 
>> 73:  * {@link java.nio.charset.StandardCharsets#ISO_8859_1 ISO-8859-1}.
>> 74:  *
>> 75:  * @apiNote
> 
> Why is this an `apiNote`. Can't we put an example directly into the spec. Also, please add an example on encrypting a private key.

It was a review comment back in early `24.  I don't know who asked for the change

> src/java.base/share/classes/java/security/PEMEncoder.java line 83:
> 
>> 81:  *
>> 82:  * @see PKCS8EncodedKeySpec
>> 83:  * @see X509EncodedKeySpec
> 
> I cannot see how these 2 deserve this place. I'd rather link to `PEMRecord` and `PEMDecoder`.

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 88:
> 
>> 86:  *       RFC 1421: Privacy Enhancement for Internet Electronic Mail
>> 87:  * @spec https://www.rfc-editor.org/info/rfc7468
>> 88:  *       RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures
> 
> You mentioned PKCS #8 2.0. Is it worth adding it here?

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 127:
> 
>> 125: 
>> 126:     /**
>> 127:      * Encoded a given {@code DEREncodable} and return the PEM encoding in a
> 
> Typo: `Encodes`.

yes

> src/java.base/share/classes/java/security/PEMEncoder.java line 128:
> 
>> 126:     /**
>> 127:      * Encoded a given {@code DEREncodable} and return the PEM encoding in a
>> 128:      * String
> 
> Either `String` or `string`.

string it is

> src/java.base/share/classes/java/security/PEMEncoder.java line 130:
> 
>> 128:      * String
>> 129:      *
>> 130:      * @param de a cryptographic object to be PEM encoded that implements
> 
> `@param de` for the 2 methods should be the same.

yes

> src/java.base/share/classes/java/security/PEMEncoder.java line 141:
> 
>> 139:      */
>> 140:     public String encodeToString(DEREncodable de) {
>> 141:         Objects.requireNonNull(de);
> 
> Do you need to check if `getFormat` of the key is "PKCS#8" or "X.509" before passing the encoding to `buildKey`? For example, we actually allows RSA key having "PKCS#1" format and ML-KEM/ML-DSA allows keys in "RAW" format.

The format is not checked.

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 374:
> 
>> 372:             SecretKeyFactory factory;
>> 373:             if (provider == null) {
>> 374:                 factory = SecretKeyFactory.getInstance(algorithm);
> 
> `algorithm` might be null.

yep

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 408:
> 
>> 406:     public static EncryptedPrivateKeyInfo encryptKey(PrivateKey key,
>> 407:         char[] password) {
>> 408:         char[] pass = password.clone();
> 
> No need to clone password here. It will be cloned into a `PBEKeySpec` later.

ok

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 458:
> 
>> 456:         }
>> 457: 
>> 458:         if (Pem.DEFAULT_ALGO == null || Pem.DEFAULT_ALGO.length() == 0) {
> 
> Is this required if `algorithm` is already specified?

Yes it should

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 573:
> 
>> 571:      *                 {@code SecretKeyFactory}, and the {@code PrivateKey},
>> 572:      *                 {@code KeyFactory}.  A {@code null} value will use the
>> 573:      *                 default provider configuration.
> 
> There is no `SecretKeyFactory` in this method, but there is `Cipher`.

Yeah, that needs rewording.

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 577:
> 
>> 575:      * @throws InvalidKeyException if an error occurs during parsing of the
>> 576:      * encrypted data or creation of the key object.
>> 577:      * @throws NullPointerException if {@code key} is null.
> 
> s/key/decryptKey/.

ok

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 582:
> 
>> 580:      */
>> 581:     @PreviewFeature(feature = PreviewFeature.Feature.PEM_API)
>> 582:     public PrivateKey getKey(Key decryptKey, Provider provider)
> 
> This method goes one step further than the existing `getKeySpec(dk, p)`. It should only throw more types of exception than the existing one. Now you put everything into a `InvalidKeyException`. Is that good?

It's a questions of how many exceptions we really need to throw for a method that other than the provider, takes a Key object the user can't modify.
I suspect I kept InvalidKeyException for consistency with the getKeySpec methods.  The way I've been doing these newer APIs, I should throw an IllegalArgumentException as they are all a result of bad arguments.
But my least favorite solution is throwing all 3 checked exceptions

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080475015
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080493004
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080501357
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080542968
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080607764
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2080607872
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081995021
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2081996525
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082000919
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082024183
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082569786
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082583428
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082590414
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082607937
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082612879
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082720137

From ascarpino at openjdk.org  Sat May 10 02:15:15 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 10 May 2025 02:15:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
Message-ID: <7x_BcZRlOPm58pfnXDAQ75p9d0u_Vv6V5P2-97vefjU=.68f27563-6951-4f8b-bce1-a00cea88c80c@github.com>

On Tue, 6 May 2025 21:19:04 GMT, Weijun Wang  wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 218:
>> 
>>> 216:      * encryption algorithm and a given password.
>>> 217:      *
>>> 218:      * 
     Only {@link PrivateKey} will be encrypted with this newly configured
>> 
>> s/will/objects will/
>> 
>> Also suggest saying "can be" instead of "will be".
>
> Shall we say "be encrypted" or "be encoded"?

ok.

This is talking about encryption, not encoding.

>> src/java.base/share/classes/java/security/PEMEncoder.java line 220:
>> 
>>> 218:      * 
     Only {@link PrivateKey} will be encrypted with this newly configured
>>> 219:      * instance.  Other {@link DEREncodable} classes that do not support
>>> 220:      * encrypted PEM will cause encode() to throw an IllegalArgumentException.
>> 
>> This sentence sounds like it is possible for classes other than PrivateKey to support encrypted PEM. Is that true? If not, I would be more specific and just say objects other than PrivateKey.
>> 
>> Put code font around IllegalArgumentException.
>
> Since this covers `encodeToString` as well I suggest rewriting to "Encoding other ... will throw ...".

ok

>> src/java.base/share/classes/java/security/PEMEncoder.java line 222:
>> 
>>> 220:      * encrypted PEM will cause encode() to throw an IllegalArgumentException.
>>> 221:      *
>>> 222:      * @implNote Default algorithm defined by Security Property {@code
>> 
>> First sentence is incomplete.
>
> You might want to be more clear that this implementation uses the PBE cipher algorithm using default parameters from the most preferred provider. Otherwise, users might be clueless about what encryption options they can configure.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082195327
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082211758
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082370577

From ascarpino at openjdk.org  Sat May 10 02:15:15 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 10 May 2025 02:15:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
 
Message-ID: 

On Mon, 28 Apr 2025 16:23:44 GMT, Weijun Wang  wrote:

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

offline discussion resulted in a switch to `RuntimeException`

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

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

From ascarpino at openjdk.org  Sat May 10 02:15:15 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 10 May 2025 02:15:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
 
 
 
Message-ID: 

On Thu, 1 May 2025 17:47:03 GMT, Weijun Wang  wrote:

>> I see your point now, but `leadingData` is a byte array.  If an app wrote the `leadingData` in a `ByteArrayInputStream`, followed by the PEM text, it would not be the same data written as the newline would be gone.  Correct?
>
> Why would it be gone? It's a 0x10 at the end of the byte array.

So I wouldn't want to remove or parse any of the `leadingData` as it could be binary data in front of them PEM.  
Since this is a byte[] from an InputStream, I think there is an expectation that every byte will be there.  If it was a Reader, it maybe different.  Also if the app is reading `leadingData` by converting into a String, I think that trailing newline is removed.

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

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

From ascarpino at openjdk.org  Sat May 10 02:15:16 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 10 May 2025 02:15:16 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 
 
Message-ID: 

On Thu, 8 May 2025 13:41:10 GMT, Sean Mullan  wrote:

>> I didn't change the rest of them because I didn't want to make too many unnecessary edits.  I understand you like it, but it is not a concise description. 
>> 
>> The one word "cloned" is a lot simpler and means the same as:
>> "The contents of {@code encryptedData} are copied to protect against subsequent modification when constructing this object."
>
> The words "to protect against subsequent modification" are important and if I recall was something we added a long time ago to many of our APIs. I would restore the original text. Also, the other constructor is still using those words.

ok

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

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

From ascarpino at openjdk.org  Sat May 10 02:15:16 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 10 May 2025 02:15:16 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 <9mfjkYfNkAF1AcivrGWStoKBvYU7upfrujgMo5r6muI=.7e655046-04ae-4e76-9598-76b77dfb478f@github.com>
 
 
Message-ID: 

On Fri, 2 May 2025 17:50:22 GMT, Sean Mullan  wrote:

>> `getArrayS0` does not clone. It's only safe to use it internally.
>
> It was previously called by `calculatePublicKey` - I think those bytes are never exposed externally, so safe to not clone.

I'm assuming there is no more issues here.

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

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

From wetmore at openjdk.org  Sat May 10 02:30:04 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 10 May 2025 02:30:04 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
Message-ID: <5peOVntgfyoPfIfPa_BjgMQMlz5BCKfHaDDaEoi8TqY=.5c2fc43e-bb66-4ca1-a3c8-83c05ad0ad16@github.com>

On Thu, 8 May 2025 21:19:10 GMT, Valerie Peng  wrote:

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

Marked as reviewed by wetmore (Reviewer).

You're probably good to go, but might check with Weijun/Sean/DJ in case there's anything last minute.

src/java.base/share/classes/sun/security/util/KeyUtil.java line 451:

> 449:                 || alg.equalsIgnoreCase("Generic");
> 450:     }
> 451: 

As you know, I've been working on the [TLS Exporters change]( https://github.com/openjdk/jdk/pull/24976) which will use the same KDF APIs.  I've already updated that to use your style.  

Looks like I've now got one more thing to change!  ;)

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

PR Review: https://git.openjdk.org/jdk/pull/24393#pullrequestreview-2830088116
PR Comment: https://git.openjdk.org/jdk/pull/24393#issuecomment-2868234417
PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2082762131

From wetmore at openjdk.org  Sat May 10 02:30:04 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 10 May 2025 02:30:04 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v4]
In-Reply-To: <3BoHY6DlJxRc-uP6TgIXuo7ceJ7wkA-kmZnl1-OqM_8=.ca9cdc36-bc61-4df8-973c-60d82dd6c0ca@github.com>
References: 
 
 
 
 
 <3BoHY6DlJxRc-uP6TgIXuo7ceJ7wkA-kmZnl1-OqM_8=.ca9cdc36-bc61-4df8-973c-60d82dd6c0ca@github.com>
Message-ID: 

On Thu, 8 May 2025 18:04:58 GMT, Valerie Peng  wrote:

>> Or in the meantime:
>> 
>>     } finally {
>>         // Best effort
>>         if (eae_prk instanceof SecretKeySpec s) {
>>             SharedSecrets.getJavaxCryptoSpecAccess()
>>                     .clearSecretKeySpec(s);
>>         } else {
>>             try {
>>                 eae_prk.destroy();
>>             } catch (DestroyFailedException e) {
>>                 // swallow
>>             }
>>         }
>>     }
>
> Sounds good, thanks for the suggestion.

This is what I did in my Exporter code.  Assuming you go in first, I'll update mine to use your Util method.

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

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

From wetmore at openjdk.org  Sat May 10 02:30:04 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 10 May 2025 02:30:04 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v7]
In-Reply-To: 
References: 
 
 <_HccQ4L2NE5PBsBoRUrw1bsPJQgoGGS0LlcICS1jArM=.4546df85-abb5-48be-8657-3502b1842744@github.com>
 
Message-ID: 

On Thu, 8 May 2025 18:44:27 GMT, Valerie Peng  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 409:
>> 
>>> 407:             HKDFParameterSpec spec =
>>> 408:                     HKDFParameterSpec.ofExtract().addIKM(s).extractOnly();
>>> 409:             return hkdf.deriveKey("Generic", spec);
>> 
>> I haven't done much with DHKEM yet, but should the returned key have algorithm name of "Generic," or something more descriptive like the previous "HKDF-PRK"?
>
> Me neither. However, given `HKDF-PRK` is not a standard algorithm and also not recognized by the `SunPKCS11` provider, I changed it to `Generic`. Existing `HKDF` impl in the `SunPKCS11` provider is quite strict about the derived key algorithms and it will error out unless we add `HKDF-PRK` to be a recognized key algorithm for key derivation. Given these reasons, it seems `Generic` is the better choice here.

Is any specific salt needed here like in TLS?

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

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

From wetmore at openjdk.org  Sat May 10 02:30:04 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 10 May 2025 02:30:04 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v7]
In-Reply-To: 
References: 
 
 <_HccQ4L2NE5PBsBoRUrw1bsPJQgoGGS0LlcICS1jArM=.4546df85-abb5-48be-8657-3502b1842744@github.com>
 
 
Message-ID: 

On Sat, 10 May 2025 02:06:43 GMT, Bradford Wetmore  wrote:

>> Me neither. However, given `HKDF-PRK` is not a standard algorithm and also not recognized by the `SunPKCS11` provider, I changed it to `Generic`. Existing `HKDF` impl in the `SunPKCS11` provider is quite strict about the derived key algorithms and it will error out unless we add `HKDF-PRK` to be a recognized key algorithm for key derivation. Given these reasons, it seems `Generic` is the better choice here.
>
> Is any specific salt needed here like in TLS?

We should chat next week about an issue Weijun raised and the algorithm names in the Exporters.

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

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

From wetmore at openjdk.org  Sat May 10 02:30:04 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 10 May 2025 02:30:04 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v7]
In-Reply-To: 
References: 
 
 <_HccQ4L2NE5PBsBoRUrw1bsPJQgoGGS0LlcICS1jArM=.4546df85-abb5-48be-8657-3502b1842744@github.com>
 
 
Message-ID: 

On Thu, 8 May 2025 18:50:16 GMT, Valerie Peng  wrote:

>> I just found that we had talked about this previously.  What was your reasoning for pulling it?  
>> 
>> Call me paranoid, but I'm not seeing where the [JDK 24 javadocs](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/javax/crypto/spec/HKDFParameterSpec.Builder.html#addSalt(byte%5B%5D)) discuss what happens if salt is not supplied.  [RFC 8446/Section 7.1](https://www.rfc-editor.org/rfc/rfc8446.html#section-7.1) states:
>> 
>>      -  "0" indicates a string of Hash.length bytes set to zero.
>
> Ok, I will add it back just to be safe.

I thought there were other locations, but maybe I was just imagining it!  ;)

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

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

From weijun at openjdk.org  Sat May 10 13:50:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 10 May 2025 13:50:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 May 2025 21:38:07 GMT, Bradford Wetmore  wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into JDK-8341346
>  - Adjustments made for JDK-8350830
>  - Merge branch 'master' into JDK-8341346
>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>  - More Codereview comments
>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>  - More codereview/CSR comments
>  - Merge branch 'master' into JDK-8341346
>  - Codereview comments.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8

Register your new algorithm "TlsExporterMasterSecret" at https://github.com/openjdk/jdk/blob/6536430a3bdedcf5e0636e0eb27bde5e0d7b40fd/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L272.

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

PR Comment: https://git.openjdk.org/jdk/pull/24976#issuecomment-2868873399

From weijun at openjdk.org  Sat May 10 14:32:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 10 May 2025 14:32:58 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: <5peOVntgfyoPfIfPa_BjgMQMlz5BCKfHaDDaEoi8TqY=.5c2fc43e-bb66-4ca1-a3c8-83c05ad0ad16@github.com>
References: 
 
 <5peOVntgfyoPfIfPa_BjgMQMlz5BCKfHaDDaEoi8TqY=.5c2fc43e-bb66-4ca1-a3c8-83c05ad0ad16@github.com>
Message-ID: 

On Sat, 10 May 2025 02:10:14 GMT, Bradford Wetmore  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedbacks from Brad.
>
> src/java.base/share/classes/sun/security/util/KeyUtil.java line 451:
> 
>> 449:                 || alg.equalsIgnoreCase("Generic");
>> 450:     }
>> 451: 
> 
> As you know, I've been working on the [TLS Exporters change]( https://github.com/openjdk/jdk/pull/24976) which will use the same KDF APIs.  I've already updated that to use your style.  
> 
> Looks like I've now got one more thing to change!  ;)

This is a reply to the comment above. I don't know why GitHub does not show a reply box there.

> Is any specific salt needed here like in TLS?

In DHKEM, the salt used is always empty.

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

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

From ascarpino at openjdk.org  Sun May 11 19:02:55 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sun, 11 May 2025 19:02:55 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: 
References: 
Message-ID: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>

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

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  comments on the 11th

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17543/files
  - new: https://git.openjdk.org/jdk/pull/17543/files/ae43835d..2c7f2411

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

  Stats: 331 lines in 14 files changed: 100 ins; 87 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/17543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543

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

From ascarpino at openjdk.org  Sun May 11 19:03:01 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sun, 11 May 2025 19:03:01 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
 
Message-ID: <5WmXrTOyYXVn5RSvb-3P5FHOyhFZfNilAW6ha2Nh6eg=.453a3020-1c67-45ea-9639-241766e2cb14@github.com>

On Fri, 9 May 2025 18:06:10 GMT, Weijun Wang  wrote:

>> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - comments
>>  - toString update
>>  - non-sealed
>>    Better X509 KeyPair parsing
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 66:
> 
>> 64:  * For decode methods that accept a {@code Class tClass} as input, they can
>> 65:  * modify the return type to a specific {@code DEREncodable} subclass.
>> 66:  * For example, {@code ECPublicKey.class} can be used to cast a
> 
> The "modify" and "cast" words seem to reveal some implementation detail. It's just "parsing the input as the specified type".

If the cast is wrong, it throws a CastClassException.  I don't see why we need to hide this from the user.

> src/java.base/share/classes/java/security/PEMDecoder.java line 146:
> 
>> 144: 
>> 145:         try {
>> 146:             return switch (pem.type()) {
> 
> Do you still allow `type` being null?
> 
> `PEMDecoder.of().decode("s")` throws an NPE.

Hmm... I'm surprised it wouldn't trigger the default case or allow a case `null`

> src/java.base/share/classes/java/security/PEMDecoder.java line 407:
> 
>> 405:      * the default provider configuration.
>> 406:      *
>> 407:      * @param provider the factory provider.
> 
> This is a little awkward because the argument of `withFactory` is a provider. Shall we rename it?
> 
> Also, can we add some more description on how this method is used? For example, suppose a provider named `P1` extends `ECPublicKey` to `P1ECPublicKey`, then users should call `withFactory(p1).decode(pem, P1ECPublicKey.class)`. I assume we are not ready to do some kind of "delayed provider selection" trick to make it possible with the "original" decoder.

I think the javadoc explains the name clearly with links to what these factories do.

The class javadoc has details about using the decode class parameter and I don't think the javadoc should explaining how to use a 3rd party provider with 3rd party classes. 

I would wish this API to never use a delayed provider solution.

> src/java.base/share/classes/java/security/PEMRecord.java line 69:
> 
>> 67:  * @see PEMEncoder
>> 68:  */
>> 69: public record PEMRecord(String type, String pem, byte[] leadingData)
> 
> Add `@PreviewFeature`.

yep

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083274944
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083401700
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083389219
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083279739

From ascarpino at openjdk.org  Sun May 11 19:03:01 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sun, 11 May 2025 19:03:01 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <7kM3yKgy3cBOoO35MiqVW2IKIv7WptRRPWTf5vXOZMA=.b0c57b98-07c5-4c4c-8a53-b39c2e4923b3@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
 <7kM3yKgy3cBOoO35MiqVW2IKIv7WptRRPWTf5vXOZMA=.b0c57b98-07c5-4c4c-8a53-b39c2e4923b3@github.com>
Message-ID: 

On Fri, 9 May 2025 15:26:42 GMT, Sean Mullan  wrote:

>> I split them and reworded it, HTH.
>
> What I was suggesting was to have an additional sentence first describing what each of these methods is for. I'll suggest something later.

ok

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

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

From ascarpino at openjdk.org  Sun May 11 19:03:02 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sun, 11 May 2025 19:03:02 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 9 May 2025 17:57:30 GMT, Weijun Wang  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments on the 11th
>
> src/java.base/share/classes/java/security/PEMRecord.java line 87:
> 
>> 85:      */
>> 86:     public PEMRecord(String type, String pem, byte[] leadingData) {
>> 87:         this.leadingData = (leadingData == null ? null : leadingData.clone());
> 
> Not sure we should do the cloning at creation and in the getter. A record is _known_ to be only shallowly immutable and users should be prepared for this, for example, do not pass it to an untrusted method if they want to reuse it. I'd rather change this back to a normal class if you believe array cloning is necessary.

I'm ok uncloning it.

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

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

From ascarpino at openjdk.org  Sun May 11 19:02:59 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sun, 11 May 2025 19:02:59 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: <7dEojWauO8Can1PEp7tJYCmHiaVSK80JDJmU4y1W7dY=.479f02c5-92b7-4ade-8391-65cbb1a349db@github.com>
References: 
 
 <7dEojWauO8Can1PEp7tJYCmHiaVSK80JDJmU4y1W7dY=.479f02c5-92b7-4ade-8391-65cbb1a349db@github.com>
Message-ID: 

On Fri, 9 May 2025 15:13:29 GMT, Sean Mullan  wrote:

>> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - comments
>>  - toString update
>>  - non-sealed
>>    Better X509 KeyPair parsing
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 64:
> 
>> 62:  * class is specified.
>> 63:  *
>> 64:  * For decode methods that accept a {@code Class tClass} as input, they can
> 
> Start a new paragraph. Suggest rewording the beginning as "The `{@linkplain #decode(String, Class) }` and `{@linkplain #decode(InputStream, Class)}` methods take a `Class` parameter which determines the type of `DerEncodable` that is returned. These methods are useful when ..."
> 
> Then you can insert the sentence above somewhere towards the end of this paragraph: "Any type of PEM data can be decoded into a `{@code PEMRecord}` by specifying `{@code PEMRecord.class}` as a parameter."

Ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 70:
> 
>> 68:  * the returned key object from a PEM containing a public and private key.
>> 69:  * If only the private key is required, {@code PrivateKey.class} can be used.
>> 70:  * {@class PEMRecord.class} is used for returning PEM text. If {@code tClass}
> 
> This causes a javadoc error, I think you meant `@code` instead of `@class`.

yeah, saw that after the push

> src/java.base/share/classes/java/security/PEMDecoder.java line 79:
> 
>> 77:  * Configuring an instance for decryption does not prevent decoding with
>> 78:  * unencrypted PEM. Any encrypted PEM that does not use the configured password
>> 79:  * will throw an {@link RuntimeException}.
> 
> s/an/a/

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 91:
> 
>> 89:  *
>> 90:  * 
    This class is immutable and thread-safe.
>> 91: 
> 
> Missing `*`.

yeah, cleaned that up

> src/java.base/share/classes/java/security/PEMDecoder.java line 93:
> 
>> 91: 
>> 92:  * @apiNote
>> 93:  * Here is an example of decoding a PrivateKey object:
> 
> Put `@code` around PrivateKey.

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 131:
> 
>> 129:      * Returns an instance of {@code PEMDecoder}.
>> 130:      *
>> 131:      * @return returns a {@code PEMDecoder}
> 
> you don't need to say "returns", just say "a `PEMDecoder`"

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 190:
> 
>> 188:                         getKey(password.getPassword());
>> 189:                 }
>> 190:                 case Pem.CERTIFICATE, Pem.X509_CERTIFICATE -> {
> 
> What about the "X.509 CERTIFICATE" header which is also mentioned in RFC 7468?

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 191:
> 
>> 189:                 }
>> 190:                 case Pem.CERTIFICATE, Pem.X509_CERTIFICATE -> {
>> 191:                     CertificateFactory cf = getCertFactory("X509");
> 
> Use "X.509". "X509" is an alias and may not be supported by other JDK implementations. Same comment on line 196.

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 200:
> 
>> 198:                         new ByteArrayInputStream(decoder.decode(pem.pem())));
>> 199:                 }
>> 200:                 case Pem.RSA_PRIVATE_KEY -> {
> 
> Is it necessary to support this? It is not mentioned in RFC 7468.

Very much so, it's has been seen elsewhere than the PKCS#1 format is still used.  Our RSA has supported it for a long time.

> src/java.base/share/classes/java/security/PEMDecoder.java line 220:
> 
>> 218:      * the decoder.
>> 219:      *
>> 220:      * @param str a String containing PEM data.
> 
> General style comment throughout APIs: no period necessary at end when `@param`, `@return`, or `@throws` starts with a non-capital letter and no sentence follows.

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 223:
> 
>> 221:      * @return a {@code DEREncodable} generated from the PEM data.
>> 222:      * @throws IllegalArgumentException on error in decoding or if the PEM is
>> 223:      * unsupported.
> 
> If the PEM is unsupported, you return a `PEMRecord` now, so you can remove those words. Same comment on lines 248-249.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083274773
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083274961
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083275316
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083275184
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083275285
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083275393
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083276015
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083276024
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083276160
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083595650
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2083278879

From ascarpino at openjdk.org  Sun May 11 19:03:05 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sun, 11 May 2025 19:03:05 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
Message-ID: 

On Thu, 8 May 2025 16:12:07 GMT, Weijun Wang  wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:
>> 
>>  - major code review comments update
>>  - Merge branch 'master' into pem
>>  - Merge branch 'master' into pem
>>  - javadoc updates
>>  - code review comments
>>  - merge with master
>>  - better comment and remove commented out code
>>  - Merge branch 'master' into pem
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 397:
> 
>> 395:      * arguments passed to the method.
>> 396:      * @throws SecurityException on a encryption errors.
>> 397:      * @throws NullPointerException when the password is null.
> 
> and when `key` is `null`.

ok

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

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

From pminborg at openjdk.org  Mon May 12 08:27:00 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 May 2025 08:27:00 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 May 2025 08:31:35 GMT, Volkan Yazici  wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright years

Latest changes look good.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2832285086

From jpai at openjdk.org  Mon May 12 08:51:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 08:51:53 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 May 2025 08:31:35 GMT, Volkan Yazici  wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright years

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Hello Volkan, this should be `2024, 2025, `

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084166104

From jpai at openjdk.org  Mon May 12 08:54:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 08:54:54 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 May 2025 08:31:35 GMT, Volkan Yazici  wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright years

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 461:

> 459:      * make a copy.
> 460:      */
> 461:     Object stringConcat1(String[] constants);

Is this missing the `unchecked` prefix to the method name?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084172186

From duke at openjdk.org  Mon May 12 08:57:36 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 12 May 2025 08:57:36 GMT
Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v3]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Eliminating some instructions from generate_kyber12To16_avx512() + fixing a comment.

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

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

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

  Stats: 75 lines in 1 file changed: 31 ins; 32 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24953/head:pull/24953

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

From duke at openjdk.org  Mon May 12 09:05:10 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 12 May 2025 09:05:10 GMT
Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v4]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Restoring copyright notice on ML_KEM.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24953/files
  - new: https://git.openjdk.org/jdk/pull/24953/files/43455de2..215b346f

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

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

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

From vyazici at openjdk.org  Mon May 12 10:17:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 10:17:48 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 12 May 2025 08:52:00 GMT, Jaikiran Pai  wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright years
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 461:
> 
>> 459:      * make a copy.
>> 460:      */
>> 461:     Object stringConcat1(String[] constants);
> 
> Is this missing the `unchecked` prefix to the method name?

Fixed in 5da9465ce7f.

> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Hello Volkan, this should be `2024, 2025, `

Fixed in f94af95d8d0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084345953
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2084345343

From vyazici at openjdk.org  Mon May 12 10:17:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 10:17:46 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
 - Fix `HexDigits` copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/121005ee..5da9465c

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

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

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

From mullan at openjdk.org  Mon May 12 12:19:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 12:19:56 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 May 2025 20:05:10 GMT, Weijun Wang  wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new algorithms in SunJCE

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2833006989

From mullan at openjdk.org  Mon May 12 12:45:57 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 12:45:57 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 21:19:10 GMT, Valerie Peng  wrote:

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

Marked as reviewed by mullan (Reviewer).

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

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

From mullan at openjdk.org  Mon May 12 15:09:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 15:09:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: 
References: 
 
Message-ID: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>

On Fri, 9 May 2025 21:38:07 GMT, Bradford Wetmore  wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into JDK-8341346
>  - Adjustments made for JDK-8350830
>  - Merge branch 'master' into JDK-8341346
>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>  - More Codereview comments
>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>  - More codereview/CSR comments
>  - Merge branch 'master' into JDK-8341346
>  - Codereview comments.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 172:

> 170:      * algorithms defined in RFCs 5705/8446.
> 171:      * 
    
> 172:      * Note RFC 5705 (for (D)TLSv1.2 and earlier) calculates different EKM

s/Note/Note that/

(or just remove "Note" - don't think it is really necessary).

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 187:

> 185:      *
> 186:      * @implSpec The default implementation throws
> 187:      *           {@code UnsupportedOperationException}

Missing period at end of sentence.

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 192:

> 190:      *                {@code label} will be converted to a {@code byte[]}
> 191:      *                before the operation begins
> 192:      * @param context the context bytes used in the EKM calculation

Add something that says `null` is acceptable. i.e. ", or `null` ..."

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 195:

> 193:      * @param length  the number of bytes of EKM material needed
> 194:      *
> 195:      * @throws SSLKeyException if the key could not be generated

I prefer "cannot" (present tense).

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 204:

> 202:      *
> 203:      * @return a {@code SecretKey} that contains {@code length} bytes of the
> 204:      *         EKM material.

no period necessary.

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 225:

> 223:      * character encoding.
> 224:      * 
    
> 225:      * Depending on the chosen underlying key derivation mechanism, the

This reads like it should maybe be an `@apiNote`.

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 254:

> 252:      *
> 253:      * @return a byte array of size {@code length} that contains the EKM
> 254:      *         material, or null if the derived key material does not support

For "or null if the derived key material does not support encoding" why wouldn't an implementation throw UOE instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084853417
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084889527
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084879618
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084887858
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084891743
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084895438
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2084899365

From dfuchs at openjdk.org  Mon May 12 15:18:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 May 2025 15:18:53 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 9 May 2025 19:18:58 GMT, Daniel Fuchs  wrote:

>> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 214:
>> 
>>> 212:      */
>>> 213:     @Override
>>> 214:     @Deprecated(since = "25", forRemoval = true)
>> 
>> Is this annotation required or more as a reminder that the superclass method is deprecated?
>
> I think it's needed because the superclass method is deprecated for removal. Will double check.

Yes - it is needed. If you override a deprecated method you need to carry the deprecation annotation over. Here is what I got when I tried to remove the annotation on `HttpURLConnection::getPermission()` (the same error occurred on any subclass where I attempted to remove the annotation):

java/net/HttpURLConnection.java:615: warning: [dep-ann] deprecated item is not annotated with @Deprecated
    public Permission getPermission() throws IOException {
                      ^
error: warnings found and -Werror specified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2084915172

From dfuchs at openjdk.org  Mon May 12 15:24:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 May 2025 15:24:52 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 9 May 2025 19:19:03 GMT, Daniel Fuchs  wrote:

>> src/java.base/share/classes/java/net/HttpURLConnection.java line 615:
>> 
>>> 613:      */
>>> 614:     @Deprecated(since = "25", forRemoval = true)
>>> 615:     @SuppressWarnings("removal")
>> 
>> Do you still need this annotation now that `SocketPermission` is not deprecated for removal?
>
> Ah - good point - I will double check.

Yes - it is needed as well. Apparently if you override a deprecated method you need both `@Deprecated` and `@SuppressWarning`:


src/java.base/share/classes/java/net/HttpURLConnection.java:615: warning: [removal] getPermission() in URLConnection has been deprecated and marked for removal
    public Permission getPermission() throws IOException {
                      ^
error: warnings found and -Werror specified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2084927109

From abarashev at openjdk.org  Mon May 12 16:12:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 12 May 2025 16:12:04 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are not
 being checked with default SunX509 key manager
Message-ID: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>

When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3

X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

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

Commit messages:
 - Add unit test
 - Code refactoring
 - Fix open unit tests
 - Adding a system property to skip the constraints checking. Remove SunX509c.
 - Fix constraints check
 - Revert SSLHandshake.java. Set SunX509c as default. Update copyright.
 - 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager
 - Address review comments
 - Skip explicit KeyPair initialization and let the provider default set it
 - Rework unit tests
 - ... and 3 more: https://git.openjdk.org/jdk/compare/cd8adf13...75528109

Changes: https://git.openjdk.org/jdk/pull/25016/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353113
  Stats: 1168 lines in 15 files changed: 769 ins; 333 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From mullan at openjdk.org  Mon May 12 16:22:59 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 16:22:59 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 12 May 2025 15:21:46 GMT, Daniel Fuchs  wrote:

>> Ah - good point - I will double check.
>
> Yes - it is needed as well. Apparently if you override a deprecated method you need both `@Deprecated` and `@SuppressWarning`:
> 
> 
> src/java.base/share/classes/java/net/HttpURLConnection.java:615: warning: [removal] getPermission() in URLConnection has been deprecated and marked for removal
>     public Permission getPermission() throws IOException {
>                       ^
> error: warnings found and -Werror specified

Ok, but seems redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2085033749

From mullan at openjdk.org  Mon May 12 16:27:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 16:27:54 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs  wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request 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:
> 
>  - Merge branch 'master' into deprecate-net-perms-8353642
>  - Revert changes to SocketPermission and CodeSource
>  - Review feedback. Deprecate getPermission for removal.
>  - Missing white spaces
>  - 8353642: Deprecate networking permission classes for removal

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2833821389

From mullan at openjdk.org  Mon May 12 16:50:15 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 16:50:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 20:40:28 GMT, Anthony Scarpino  wrote:

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

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

> 244:      *
> 245:      * @param is InputStream containing PEM data.
> 246:      * @return an {@code DEREncodable} generated from the data read.

s/an/a/

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

> 269: 
> 270:     /**
> 271:      * Decodes and returns the specified class for the given PEM string.

Suggest slight rewording: "Decodes and returns a {@code DEREncodable} of the specified class from the given PEM string."

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

> 272:      * {@code tClass} must extend {@link DEREncodable} and be an appropriate
> 273:      * class for the PEM type.
> 274:      *

Probably should say something about non-PEM data, ex: "For classes other than `PEMRecord`, non-PEM data before the PEM header is ignored."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082403746
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082400586
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2082403073

From mullan at openjdk.org  Mon May 12 16:50:16 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 16:50:16 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
Message-ID: 

On Fri, 9 May 2025 20:46:49 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/spec/EncodedKeySpec.java line 63:
>> 
>>> 61:      * This constructor extracts the algorithm name from the encoded bytes,
>>> 62:      * which may be an OID if no standard algorithm name is defined. If the
>>> 63:      * algorithm name cannot be extracted, it is set to null.
>> 
>> Hmm, I think this is leaking details about DER encoding into this abstract class which does not make any assumptions about the type of encoding used. Have you considered only parsing the encoding in the `X509EncodedKeySpec` and `PKCS8EncodedKeySpec` subclasses which are DER specific?
>
> Well, [JEP 513](https://openjdk.org/jeps/513) will make it possible to limit it to those two EPSs when it integrates.  Right now P8EPS and X509EPS are dependent on super() call and would require duplicating the static final variables and overriding all the methods.
> 
> What I can do right now is document it in P8EPS and X509EPS, but leave the code in EPS until the JEP integrates.

Ok. JEP 513 is Integrated now.

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

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

From mullan at openjdk.org  Mon May 12 16:50:19 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 16:50:19 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
References: 
 <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
Message-ID: 

On Sun, 11 May 2025 19:02:55 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line 72:

> 70:     private BigInteger coeff;   // CRT coefficient
> 71: 
> 72:     // RSA or RSS-PSS KeyType

Typo: s/RSS-PSS/RSA-PSS/

src/java.base/share/classes/sun/security/x509/X509Key.java line 147:

> 145:      * X509Key.  Useful for PKCS8v2.
> 146:      */
> 147:     public static X509Key parse(byte[] encoded) throws IOException

Isn't this the same as `X509Key.parse(byte[])`?

src/java.base/share/classes/sun/security/x509/X509Key.java line 150:

> 148:     {
> 149:         DerValue in = new DerValue(encoded);
> 150:         AlgorithmId algorithm;

Can move to line 155.

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

> 1558: # withEncryption method.
> 1559: #
> 1560: jdk.epkcs8.defaultAlgorithm=PBEWithHmacSHA256AndAES_128

What about naming this `jdk.pem.pbeAlgorithm`? The `withEncryption` method never mentions PKCS#8, so maybe don't need to expose this in the property name. Also having "pem" in the property name makes it more clear what API this property is used for.

test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java line 3:

> 1: /*
> 2:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
> 3:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Not necessary anymore since file is not changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085063839
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085071940
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085068341
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2084832539
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2084756079

From kdriver at openjdk.org  Mon May 12 16:51:54 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 12 May 2025 16:51:54 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 21:19:10 GMT, Valerie Peng  wrote:

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

I'll be looking too, but don't hold up integration to wait for my review.

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

PR Comment: https://git.openjdk.org/jdk/pull/24393#issuecomment-2873280133

From dfuchs at openjdk.org  Mon May 12 16:52:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 May 2025 16:52:57 GMT
Subject: Integrated: 8353642: Deprecate URL::getPermission method and
 networking permission classes for removal
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Apr 2025 09:00:05 GMT, Daniel Fuchs  wrote:

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

This pull request has now been integrated.

Changeset: 45dfc2c6
Author:    Daniel Fuchs 
URL:       https://git.openjdk.org/jdk/commit/45dfc2c6d6d6b2b0749347b0150bb22d49f12767
Stats:     41 lines in 11 files changed: 25 ins; 4 del; 12 mod

8353642: Deprecate URL::getPermission method and networking permission classes for removal

Reviewed-by: djelinski, iris, mullan, michaelm

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

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

From rriggs at openjdk.org  Mon May 12 17:20:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 May 2025 17:20:03 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 12 May 2025 10:17:46 GMT, Volkan Yazici  wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 328:

> 326:      * {@linkplain java.nio.charset.Charset charset}.
> 327:      * 
    
> 328:      * WARNING: This method return the {@code byte[]} backing the provided

Suggestion:

     * WARNING: This method returns the {@code byte[]} backing the provided

Should this more explicitly say the returned byte array must not be modified?

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 413:

> 411: 
> 412:     /**
> 413:      * Encodes ASCII codepoints as possible from the source array into

Suggestion:

     * Encodes as many ASCII codepoints as possible from the source array into

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2085106836
PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2085112564

From djelinski at openjdk.org  Mon May 12 18:03:02 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 12 May 2025 18:03:02 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
Message-ID: <8PilPU20GgABxqXQDkYdaTVuDgHhAzGzRfOlpZE7-aQ=.14078b56-924a-43e7-b67d-63760359fc98@github.com>

On Thu, 8 May 2025 21:19:10 GMT, Valerie Peng  wrote:

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

Marked as reviewed by djelinski (Reviewer).

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

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

From abarashev at openjdk.org  Mon May 12 18:45:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 12 May 2025 18:45:10 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v2]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <1Gpnwbv3_IexuWpsDF0ebvnlgcVpRzY_t3NTR639sMA=.c69a02d9-8139-4068-bfba-23ba8424b5f7@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

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

  Add PeerConstraintsCheck unit test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/75528109..88cd4016

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

  Stats: 284 lines in 3 files changed: 277 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From mullan at openjdk.org  Mon May 12 18:52:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 18:52:07 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
Message-ID: 

On Fri, 9 May 2025 22:08:00 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java line 41:
>> 
>>> 39:  *   privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
>>> 40:  *   privateKey PrivateKey,
>>> 41:  *   attributes       [0] IMPLICIT Attributes OPTIONAL,
>> 
>> IMPLICIT has been removed in RFC 5958. Also to be consistent with 5958, I think you should change `PrivateKeyInfo` to `OneAsymmetricKey` and add an addtional line with `PrivateKeyInfo ::= OneAsymmetricKey`.
>
> Ok.
> 
> Whats the reason `PrivateKeyInfo` have @code on it. It's not a class or a method.  It's just a term.

It is already in a pre-formatted block, so it is fine as-is w/o specifically putting @code around it.

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

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

From vyazici at openjdk.org  Mon May 12 19:13:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 19:13:29 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Roger Riggs 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/5da9465c..0ac2101a

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

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

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

From mullan at openjdk.org  Mon May 12 19:22:05 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 19:22:05 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 <9mfjkYfNkAF1AcivrGWStoKBvYU7upfrujgMo5r6muI=.7e655046-04ae-4e76-9598-76b77dfb478f@github.com>
 
 
 
Message-ID: 

On Sat, 10 May 2025 01:19:06 GMT, Anthony Scarpino  wrote:

>> It was previously called by `calculatePublicKey` - I think those bytes are never exposed externally, so safe to not clone.
>
> I'm assuming there is no more issues here.

There is still a small issue. On line 228, a clone of the array is now being done when it doesn't have to. The previous code called the internal `getArrayS0` method which did not do a clone.

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

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

From kdriver at openjdk.org  Mon May 12 19:35:54 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 12 May 2025 19:35:54 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 21:19:10 GMT, Valerie Peng  wrote:

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

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

> 126: 
> 127:             // derive handshake secret
> 128:             // NOTE: do not reuse the HKDF object for "TlsEarlySecret" for

Nit: There is no longer an "HKDF object". Might be worth updating this comment.

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

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

From kdriver at openjdk.org  Mon May 12 19:41:57 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 12 May 2025 19:41:57 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
Message-ID: <2p3JqYQPMqDaFfjFX9nRE_acOH3Bdwrs2Y78TCV92ag=.2e08a367-3f19-4343-b2fc-4192bf0d908a@github.com>

On Thu, 8 May 2025 21:19:10 GMT, Valerie Peng  wrote:

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

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

> 47:         this.secret = secret;
> 48:         this.hkdfInfo = createHkdfInfo(label, context, hashAlg.hashLength);
> 49:         this.keyLen = hashAlg.hashLength;

Very minor nit: might be worth accessing this field once and passing `this.keyLen` to `createHkdfInfo` instead.

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

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

From vyazici at openjdk.org  Mon May 12 19:42:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 19:42:15 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: 
References: 
Message-ID: 

> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into jla
 - Improve `uncheckedGetBytesNoRepl` docs
 - Apply suggestions from code review
   
   Co-authored-by: Roger Riggs 
 - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
 - Fix `HexDigits` copyright year
 - Fix copyright years
 - Prefix touched methods with `unchecked`
 - Fix typo in pre-existing JavaDoc
 - Improve `JavaLangAccess` documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24982/files
  - new: https://git.openjdk.org/jdk/pull/24982/files/0ac2101a..0e06ce1d

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

  Stats: 38505 lines in 1296 files changed: 26044 ins; 7087 del; 5374 mod
  Patch: https://git.openjdk.org/jdk/pull/24982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24982/head:pull/24982

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

From vyazici at openjdk.org  Mon May 12 19:42:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 12 May 2025 19:42:15 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 12 May 2025 17:07:57 GMT, Roger Riggs  wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>>  - Fix `HexDigits` copyright year
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 328:
> 
>> 326:      * {@linkplain java.nio.charset.Charset charset}.
>> 327:      * 
    
>> 328:      * WARNING: This method return the {@code byte[]} backing the provided
> 
> Suggestion:
> 
>      * WARNING: This method returns the {@code byte[]} backing the provided
> 
> Should this more explicitly say the returned byte array must not be modified?

Improved as suggested in cd156fbab46.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2085329577

From kdriver at openjdk.org  Mon May 12 19:48:53 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 12 May 2025 19:48:53 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 21:19:10 GMT, Valerie Peng  wrote:

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

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

> 55:             KDF hkdf = KDF.getInstance(hkdfAlg);
> 56:             return hkdf.deriveKey(type,
> 57:                     HKDFParameterSpec.expandOnly(secret, hkdfInfo, keyLen));

I noticed we have done away with the `AlgorithmParameterSpec` parameter to this method. While the new implementation makes sense in light of the new parameter set, I wonder whether there was a deliberate use-case lost here... 

In the previous implementation, presumably, if the `keySpec`'s length was shorter than the expanded value, only a portion of the value would be used. With the new implementation, the hash algorithm's length of bytes is always used. 

I'm not sure how relevant this is, but it could be worth noting. If we had kept the old parameter, I suppose we could have used `deriveData` and truncated the result to `((SecretSizeSpec)keySpec).length` before returning a `SecretKey`.

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

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

From kdriver at openjdk.org  Mon May 12 19:54:53 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 12 May 2025 19:54:53 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 21:19:10 GMT, Valerie Peng  wrote:

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

See inline.

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

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

From abarashev at openjdk.org  Mon May 12 20:05:18 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 12 May 2025 20:05:18 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.

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

  Make sure the exception happens during KeyManager's algorithm check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/88cd4016..5c137c14

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

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

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

From liach at openjdk.org  Mon May 12 20:25:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 May 2025 20:25:57 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici  wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into jla
>  - Improve `uncheckedGetBytesNoRepl` docs
>  - Apply suggestions from code review
>    
>    Co-authored-by: Roger Riggs 
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year
>  - Fix copyright years
>  - Prefix touched methods with `unchecked`
>  - Fix typo in pre-existing JavaDoc
>  - Improve `JavaLangAccess` documentation

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2834380249

From mullan at openjdk.org  Mon May 12 20:46:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 20:46:47 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
References: 
 <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
Message-ID: <9CXNHFwKxLcTFdoS6EkHvVw8R384pj3QmM6K8RFNsy8=.85aafda0-d9f0-4778-a36b-ae628edf15f2@github.com>

On Sun, 11 May 2025 19:02:55 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/java/security/PEMRecord.java line 116:

> 114:      *
> 115:      * @param type the type identifier in the PEM header and footer, or {@code null} if there is no PEM data.
> 116:      * @param pem The data between the PEM header and footer.

s/The/the/

src/java.base/share/classes/java/security/PEMRecord.java line 116:

> 114:      *
> 115:      * @param type the type identifier in the PEM header and footer, or {@code null} if there is no PEM data.
> 116:      * @param pem The data between the PEM header and footer.

This should say "the base64-encoded data ..."

src/java.base/share/classes/java/security/PEMRecord.java line 129:

> 127:      *
> 128:      * @param type the type identifier in the PEM header and footer, or {@code null} if there is no PEM data.
> 129:      * @param pem the data between the PEM header and footer.

I thought the bytes were the DER encoded data. Wouldn't that be useful, if you were trying to PEM encode a certificate with extra leading data, for example?

src/java.base/share/classes/java/security/PEMRecord.java line 142:

> 140:      *
> 141:      * @throws IllegalArgumentException if {@code pem} cannot be decoded.
> 142:      * @return Returns a new array of the binary encoding each time this

Remove "Returns".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085418309
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085421719
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085423396
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085412731

From mullan at openjdk.org  Mon May 12 21:41:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 21:41:07 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
Message-ID: 

On Sat, 10 May 2025 01:24:28 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 79:
>> 
>>> 77: 
>>> 78:     /* PKCS8 version of the PEM */
>>> 79:     protected int version;
>> 
>> Do these need to be protected? It doesn't seem like any subclasses need them.
>
> I think I wanted to use it in the subclasses, but later realized the subclasses needed to parse it again anyway for algorithms-specific values.  I can make it private.

These are still protected.

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

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

From valeriep at openjdk.org  Mon May 12 22:31:54 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 12 May 2025 22:31:54 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
 
Message-ID: <8BcbuuH3Kie20gZ612gDY9GDQuxKbcugIFwE_86q0vY=.2f5e4212-35a5-4daa-ab7d-e9cde4fa655a@github.com>

On Mon, 12 May 2025 19:33:09 GMT, Kevin Driver  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedbacks from Brad.
>
> src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 128:
> 
>> 126: 
>> 127:             // derive handshake secret
>> 128:             // NOTE: do not reuse the HKDF object for "TlsEarlySecret" for
> 
> Nit: There is no longer an "HKDF object". Might be worth updating this comment.

It actually means the "KDF object w/ HKDF algorithm", I can see how that may look confusing. I will change it to "KDF object".

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

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

From valeriep at openjdk.org  Mon May 12 22:36:54 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 12 May 2025 22:36:54 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: <2p3JqYQPMqDaFfjFX9nRE_acOH3Bdwrs2Y78TCV92ag=.2e08a367-3f19-4343-b2fc-4192bf0d908a@github.com>
References: 
 
 <2p3JqYQPMqDaFfjFX9nRE_acOH3Bdwrs2Y78TCV92ag=.2e08a367-3f19-4343-b2fc-4192bf0d908a@github.com>
Message-ID: 

On Mon, 12 May 2025 19:38:59 GMT, Kevin Driver  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedbacks from Brad.
>
> src/java.base/share/classes/sun/security/ssl/SSLBasicKeyDerivation.java line 49:
> 
>> 47:         this.secret = secret;
>> 48:         this.hkdfInfo = createHkdfInfo(label, context, hashAlg.hashLength);
>> 49:         this.keyLen = hashAlg.hashLength;
> 
> Very minor nit: might be worth accessing this field once and passing `this.keyLen` to `createHkdfInfo` instead.

Hmm, I like to match the ordering in the constructor with the ordering of fields. Since this is relatively minor, I am inclined to leave it as is...

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

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

From valeriep at openjdk.org  Mon May 12 22:41:57 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 12 May 2025 22:41:57 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
 <5peOVntgfyoPfIfPa_BjgMQMlz5BCKfHaDDaEoi8TqY=.5c2fc43e-bb66-4ca1-a3c8-83c05ad0ad16@github.com>
 
Message-ID: 

On Sat, 10 May 2025 14:30:16 GMT, Weijun Wang  wrote:

>> src/java.base/share/classes/sun/security/util/KeyUtil.java line 451:
>> 
>>> 449:                 || alg.equalsIgnoreCase("Generic");
>>> 450:     }
>>> 451: 
>> 
>> As you know, I've been working on the [TLS Exporters change]( https://github.com/openjdk/jdk/pull/24976) which will use the same KDF APIs.  I've already updated that to use your style.  
>> 
>> Looks like I've now got one more thing to change!  ;)
>
> This is a reply to the comment above. I don't know why GitHub does not show a reply box there.
> 
>> Is any specific salt needed here like in TLS?
> 
> In DHKEM, the salt used is always empty.

So, no need to explicitly set it I assume? As this is a refactoring, I prefer to minimize changes unless consensus is different.

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

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

From mullan at openjdk.org  Mon May 12 22:46:14 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 22:46:14 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
References: 
 <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
Message-ID: 

On Sun, 11 May 2025 19:02:55 GMT, Anthony Scarpino  wrote:

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

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

> 45: 
> 46: /**
> 47:  * {@code PEMEncoder} is used for encoding Privacy-Enhanced Mail (PEM) data.

suggest changing "is used" to "implements an encoder" - then it will be consistent with PEMDecoder.

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

> 57:  * 
     Encrypted private key PEM data can be built by encoding with a
> 58:  * {@code PEMEncoder} instance returned by {@linkplain #withEncryption(char[])}
> 59:  * or by encoding an {@link EncryptedPrivateKeyInfo} .

Suggest rewording as: "Private keys can be encrypted and encoded by configuring a `PEMEncoder` with the `withEncryption` method, which takes a password and returns a new `PEMEncoder` instance configured to encrypt the key with that password. Alternatively, a private key encrypted as an `EncryptedKeyInfo` object can be encoded directly to PEM by passing it to the `encode` method."

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

> 59:  * or by encoding an {@link EncryptedPrivateKeyInfo} .
> 60:  *
> 61:  * 
     PKCS #8 2.0 allows OneAsymmetricKey encoding, which may contain both

s/allows .../defines the ASN.1 OneAsymmetricKey structure/

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

> 60:  *
> 61:  * 
     PKCS #8 2.0 allows OneAsymmetricKey encoding, which may contain both
> 62:  * private and public keys in the same PEM. This is supported by using the

PKCS #8 doesn't define PEM. Suggest  removing "in the same PEM".

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

> 61:  * 
     PKCS #8 2.0 allows OneAsymmetricKey encoding, which may contain both
> 62:  * private and public keys in the same PEM. This is supported by using the
> 63:  * {@link KeyPair} class with the encode methods.

Suggest rewording 2nd sentence as: "`KeyPair` objects passed to the `encode` methods are encoded as a OneAsymmetricKey structure using the "PRIVATE KEY" type."

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

> 68:  * the data.
> 69:  *
> 70:  * 
    {@code String} values encoded use character set

Why does this need to be mentioned if it is an RFC PEM requirement?

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

> 79:  * }
> 80:  *
> 81:  * 
    To make the {@code PEMEncoder} encrypt the above private key, only the

Suggest rewording as "Here is an example that encrypts and encodes a private key using the specified password."

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

> 93:  *       RFC 1421: Privacy Enhancement for Internet Electronic Mail
> 94:  * @spec https://www.rfc-editor.org/info/rfc5958
> 95:  *       RFC 5958: Asymmetric Key Packages

Do we really need to add RFC 5958 here? This class is just doing the PEM encoding, it doesn't implement RFC 5958.

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

> 127:      * Returns a new instance of {@code PEMEncoder}.
> 128:      *
> 129:      * @return new {@code PEMEncoder} instance

"new" sounds like it is a new instance each time this method is called. Suggest just saying "Returns a `PEMDecoder`"

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

> 134: 
> 135:     /**
> 136:      * Encode the specified {@code DEREncodable} and return the PEM encoding in a

s/Encode/Encodes/

s/return/returns/

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

> 138:      *
> 139:      * @param de the {@code DEREncodable} to be encoded.
> 140:      * @return PEM encoding in a string

Suggest: "a PEM encoded string"

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

> 139:      * @param de the {@code DEREncodable} to be encoded.
> 140:      * @return PEM encoding in a string
> 141:      * @throws IllegalArgumentException when encoding the {@code DEREncodable}

Suggest: "if the `DEREncodable` cannot be encoded`

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

> 203: 
> 204:     /**
> 205:      * Encodes the specified {@code DEREncodable} into PEM.

Make description consistent with other encode method: "Encodes the specified {@code DEREncodable} and returns the PEM encoding in a byte array."

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

> 206:      *
> 207:      * @param de the {@code DEREncodable} to be encoded.
> 208:      * @return PEM encoded byte array

Suggest: "a byte array containing the PEM encoded data"

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

> 207:      * @param de the {@code DEREncodable} to be encoded.
> 208:      * @return PEM encoded byte array
> 209:      * @throws IllegalArgumentException when encoding the {@code DEREncodable}

"If the `DEREncodable` cannot be encoded"

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

> 212:      * @see #withEncryption(char[])
> 213:      */
> 214:     public byte[] encode(DEREncodable de) {

Is this method that useful? Caller can just do what line 215 is doing.

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

> 222:      * 
     Only {@link PrivateKey} objects can be encrypted with this newly
> 223:      * configured instance.  Encoding other {@link DEREncodable} objects will
> 224:      * throw an{@code IllegalArgumentException}.

space after "an"

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

> 226:      * @implNote The default algorithm is defined by Security Property {@code
> 227:      * jdk.epkcs8.defaultAlgorithm} using default password-based encryption
> 228:      * parameters by the supporting provider.  To configure all the encryption

Maybe reword as "If you need more control over the encryption algorithm and parameters, use the ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085589104
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085605635
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085606515
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085610213
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085614212
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085617629
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085622259
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085623589
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085626881
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085627060
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085628121
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085628841
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085630670
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085631422
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085631103
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085632879
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085633317
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085634539

From mullan at openjdk.org  Mon May 12 22:46:15 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 22:46:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
Message-ID: <7fB-mt4sW6w4IQxouj04Kks7wqoghJle2cAhZ64B5E0=.ff372d12-7b60-417a-817e-a8fb0dd2bbb9@github.com>

On Thu, 8 May 2025 20:58:41 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 54:
>> 
>>> 52:  * and footer.
>>> 53:  *
>>> 54:  * 
     Encoding may be performed on Java Cryptographic Extension (JCE) objects
>> 
>> Is "JCE objects" a formal term? We used to say "JCA and JCE". How do we call them now?
>
> I'd like to keep the JCA/JCE nuance out.  I'd rather just leave it as is, or use the alternative I've used elsewhere, Java API cryptographic object.

I would probably just say "cryptographic objects that implement `DEREncodable`"

>> src/java.base/share/classes/java/security/PEMEncoder.java line 70:
>> 
>>> 68:  * {@linkplain PEMRecord#pem()} with a generated the PEM header and footer
>>> 69:  * from {@linkplain PEMRecord#type()}.  It will not check the validity of
>>> 70:  * the data.
>> 
>> Since you mention `PEMRecord` specifically, I'd see the clarification that the `leadingData` there will not be encoded. Otherwise, you cannot guarantee on the encoding.
>
> I think specifying the fields that are encoded makes it clear what is not in the encoding.

I would have expected the leading data to be encoded. Why is the leading data not encoded?

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

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

From mullan at openjdk.org  Mon May 12 22:46:15 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 22:46:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <7fB-mt4sW6w4IQxouj04Kks7wqoghJle2cAhZ64B5E0=.ff372d12-7b60-417a-817e-a8fb0dd2bbb9@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
 <7fB-mt4sW6w4IQxouj04Kks7wqoghJle2cAhZ64B5E0=.ff372d12-7b60-417a-817e-a8fb0dd2bbb9@github.com>
Message-ID: <8jSOTOGnJ31njp76FduOxwLz067ac61VvLxdKiRbVhQ=.6eddfc0a-bfcd-4e14-bfc5-c0d0e60c925e@github.com>

On Mon, 12 May 2025 21:55:46 GMT, Sean Mullan  wrote:

>> I'd like to keep the JCA/JCE nuance out.  I'd rather just leave it as is, or use the alternative I've used elsewhere, Java API cryptographic object.
>
> I would probably just say "cryptographic objects that implement `DEREncodable`"

Also change "may" to "can". "May" sounds like it is optional.

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

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

From valeriep at openjdk.org  Mon May 12 23:02:56 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 12 May 2025 23:02:56 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 12 May 2025 19:45:47 GMT, Kevin Driver  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedbacks from Brad.
>
> src/java.base/share/classes/sun/security/ssl/SSLBasicKeyDerivation.java line 57:
> 
>> 55:             KDF hkdf = KDF.getInstance(hkdfAlg);
>> 56:             return hkdf.deriveKey(type,
>> 57:                     HKDFParameterSpec.expandOnly(secret, hkdfInfo, keyLen));
> 
> I noticed we have done away with the `AlgorithmParameterSpec` parameter to this method. While the new implementation makes sense in light of the new parameter set, I wonder whether there was a deliberate use-case lost here... 
> 
> In the previous implementation, presumably, if the `keySpec`'s length was shorter than the expanded value, only a portion of the value would be used. With the new implementation, the hash algorithm's length of bytes is always used. 
> 
> I'm not sure how relevant this is, but it could be worth noting. If we had kept the old parameter, I suppose we could have used `deriveData` and truncated the result to `((SecretSizeSpec)keySpec).length` before returning a `SecretKey`.

Searching among the JSSE code base, it looks that `SSLBasicKeyDerivation` class is only used in `Finished` class and the particular `SecretSizeSpec` value is always same as the current `keyLen` field. There is no other usage as far as I can tell. If we ended up using `SSLBasicKeyDerivation` class with a shorter key length, we can add an explicit `keyLen` argument to the `SSLBasicKeyDerivation` constructor. I see no need for the `SecretSizeSpec` class given the code flow in `Finished` class.

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

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

From weijun at openjdk.org  Tue May 13 00:14:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 00:14:50 GMT
Subject: RFR: 8356087: Problematic KeyInfo check using key algorithm in
 P11SecretKeyFactory class [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 7 May 2025 22:43:10 GMT, Valerie Peng  wrote:

>> In the PR for JDK-8348732 "SunJCE and SunPKCS11 have different PBE key encodings", the `P11SecretKeyFactory.convertKey(...)` method is refactored to call `getKeyInfo(keyAlgo)` and check that it's not `null`. However, this leads to problems for the `P11Mac` object when it's initialized with a key whose algorithm is not recognized by SunPKCS11 provider. It fails with an unexpected `InvalidKeyException`. Thus, reverting back to the pre-JDK8348732 code and calls `getKeyInfo(keyAlgo)` only when needed.
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor wording changes for test summary.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25108#pullrequestreview-2834967673

From valeriep at openjdk.org  Tue May 13 03:50:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 13 May 2025 03:50:03 GMT
Subject: Integrated: 8356087: Problematic KeyInfo check using key algorithm in
 P11SecretKeyFactory class
In-Reply-To: 
References: 
Message-ID: 

On Wed, 7 May 2025 22:24:50 GMT, Valerie Peng  wrote:

> In the PR for JDK-8348732 "SunJCE and SunPKCS11 have different PBE key encodings", the `P11SecretKeyFactory.convertKey(...)` method is refactored to call `getKeyInfo(keyAlgo)` and check that it's not `null`. However, this leads to problems for the `P11Mac` object when it's initialized with a key whose algorithm is not recognized by SunPKCS11 provider. It fails with an unexpected `InvalidKeyException`. Thus, reverting back to the pre-JDK8348732 code and calls `getKeyInfo(keyAlgo)` only when needed.

This pull request has now been integrated.

Changeset: 4fc10a1e
Author:    Valerie Peng 
URL:       https://git.openjdk.org/jdk/commit/4fc10a1e7e9483ecddbaaa9fb52c4db52de86cc8
Stats:     83 lines in 2 files changed: 67 ins; 8 del; 8 mod

8356087: Problematic KeyInfo check using key algorithm in P11SecretKeyFactory class

Reviewed-by: weijun

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

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

From hchao at openjdk.org  Tue May 13 03:58:53 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 13 May 2025 03:58:53 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
Message-ID: <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>

On Mon, 12 May 2025 20:05:18 GMT, Artur Barashev  wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure the exception happens during KeyManager's algorithm check

It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. When setting this property to true, it will disable the existing RFC compliant algorithm constraints checking even in `X509KeyManagerImpl`, and we?d want to avoid that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2874984309

From wetmore at openjdk.org  Tue May 13 04:57:54 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 04:57:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 10 May 2025 13:48:05 GMT, Weijun Wang  wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> Register your new algorithm "TlsExporterMasterSecret" at https://github.com/openjdk/jdk/blob/6536430a3bdedcf5e0636e0eb27bde5e0d7b40fd/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L272.

@wangweij 

> Register your new algorithm "TlsExporterMasterSecret" at
> 
> https://github.com/openjdk/jdk/blob/6536430a3bdedcf5e0636e0eb27bde5e0d7b40fd/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L272
> .

I registered both `TlsExporterMasterSecret` and `TlsExporterKeyingMaterial` in `P11SecretKeyFactory` and tweaked the creation call sites.  I'll test this out tomorrow with some of the PKCS11 tests in mach5.

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

PR Comment: https://git.openjdk.org/jdk/pull/24976#issuecomment-2875046444

From wetmore at openjdk.org  Tue May 13 04:57:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 04:57:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
References: 
 
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
Message-ID: 

On Mon, 12 May 2025 14:45:36 GMT, Sean Mullan  wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 172:
> 
>> 170:      * algorithms defined in RFCs 5705/8446.
>> 171:      * 
    
>> 172:      * Note RFC 5705 (for (D)TLSv1.2 and earlier) calculates different EKM
> 
> s/Note/Note that/
> 
> (or just remove "Note" - don't think it is really necessary).

Removed "Note"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085917566

From wetmore at openjdk.org  Tue May 13 05:06:55 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:06:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
References: 
 
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
Message-ID: 

On Mon, 12 May 2025 15:02:31 GMT, Sean Mullan  wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 187:
> 
>> 185:      *
>> 186:      * @implSpec The default implementation throws
>> 187:      *           {@code UnsupportedOperationException}
> 
> Missing period at end of sentence.

Added.  I also readded:

     *           Classes derived from ExtendedSSLSession must implement
     *           this method.

which is also used in an earlier method (`getStatusResponses`) in this class.

> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 195:
> 
>> 193:      * @param length  the number of bytes of EKM material needed
>> 194:      *
>> 195:      * @throws SSLKeyException if the key could not be generated
> 
> I prefer "cannot" (present tense).

Done

> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 204:
> 
>> 202:      *
>> 203:      * @return a {@code SecretKey} that contains {@code length} bytes of the
>> 204:      *         EKM material.
> 
> no period necessary.

Corrected.  

Even when you look 10 times at something, you still miss something obvious like this!  ;)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085923797
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085924241
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085924913

From wetmore at openjdk.org  Tue May 13 05:18:08 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:18:08 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
References: 
 
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
Message-ID: 

On Mon, 12 May 2025 15:07:20 GMT, Sean Mullan  wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 254:
> 
>> 252:      *
>> 253:      * @return a byte array of size {@code length} that contains the EKM
>> 254:      *         material, or null if the derived key material does not support
> 
> For "or null if the derived key material does not support encoding" why wouldn't an implementation throw UOE instead?

I was following the SecretKey.getEncoded() style.  I see now that KDF.deriveData() does do UOE.  

I could go either way on this.  I realize I need to make this consistent, I have TLSv1.3 using KDF style, and TLSv1-TLSv1.2 using the null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085932412

From wetmore at openjdk.org  Tue May 13 05:18:07 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:18:07 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v11]
In-Reply-To: 
References: 
Message-ID: <1jREDk0Rw6H4WBRbAnFw1HtGPoddkcsYjabS9FfQAlI=.b2a5daaf-bc1f-4d70-9233-5fc0e50df0d8@github.com>

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  More codereview comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/bd227aa8..b21a42d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=09-10

  Stats: 15 lines in 3 files changed: 6 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From wetmore at openjdk.org  Tue May 13 05:32:34 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:32:34 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: 
References: 
Message-ID: 

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  Missed one review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24976/files
  - new: https://git.openjdk.org/jdk/pull/24976/files/b21a42d0..0da8f6f8

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

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

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

From wetmore at openjdk.org  Tue May 13 05:32:36 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 05:32:36 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
References: 
 
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
Message-ID: 

On Mon, 12 May 2025 14:58:07 GMT, Sean Mullan  wrote:

>> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Merge branch 'master' into JDK-8341346
>>  - Adjustments made for JDK-8350830
>>  - Merge branch 'master' into JDK-8341346
>>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>>  - More Codereview comments
>>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>>  - More codereview/CSR comments
>>  - Merge branch 'master' into JDK-8341346
>>  - Codereview comments.
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/68a11850...bd227aa8
>
> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 192:
> 
>> 190:      *                {@code label} will be converted to a {@code byte[]}
>> 191:      *                before the operation begins
>> 192:      * @param context the context bytes used in the EKM calculation
> 
> Add something that says `null` is acceptable. i.e. ", or `null` ..."

Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2085945713

From ascarpino at openjdk.org  Tue May 13 09:27:37 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 13 May 2025 09:27:37 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18]
In-Reply-To: 
References: 
Message-ID: 

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

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  comments on the 11th

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17543/files
  - new: https://git.openjdk.org/jdk/pull/17543/files/2c7f2411..727e9962

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

  Stats: 194 lines in 10 files changed: 78 ins; 41 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/17543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543

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

From ascarpino at openjdk.org  Tue May 13 09:27:37 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 13 May 2025 09:27:37 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: <7dEojWauO8Can1PEp7tJYCmHiaVSK80JDJmU4y1W7dY=.479f02c5-92b7-4ade-8391-65cbb1a349db@github.com>
References: 
 
 <7dEojWauO8Can1PEp7tJYCmHiaVSK80JDJmU4y1W7dY=.479f02c5-92b7-4ade-8391-65cbb1a349db@github.com>
Message-ID: 

On Fri, 9 May 2025 15:13:18 GMT, Sean Mullan  wrote:

>> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - comments
>>  - toString update
>>  - non-sealed
>>    Better X509 KeyPair parsing
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 62:
> 
>> 60:  * 
     If the PEM does not have a JCE object representation, it returns a
>> 61:  * {@link PEMRecord}. Any PEM can be decoded into a {@code PEMRecord} if the
>> 62:  * class is specified.
> 
> I would move the second sentence to later after you descibe the `decode` methods that take a `Class` param.

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 271:
> 
>> 269: 
>> 270:     /**
>> 271:      * Decodes and returns the specified class for the given PEM string.
> 
> Suggest slight rewording: "Decodes and returns a {@code DEREncodable} of the specified class from the given PEM string."

ok

> src/java.base/share/classes/java/security/PEMDecoder.java line 274:
> 
>> 272:      * {@code tClass} must extend {@link DEREncodable} and be an appropriate
>> 273:      * class for the PEM type.
>> 274:      *
> 
> Probably should say something about non-PEM data, ex: "For classes other than `PEMRecord`, non-PEM data before the PEM header is ignored."

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085360976
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085757494
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085769233

From ascarpino at openjdk.org  Tue May 13 09:27:38 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 13 May 2025 09:27:38 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <8jSOTOGnJ31njp76FduOxwLz067ac61VvLxdKiRbVhQ=.6eddfc0a-bfcd-4e14-bfc5-c0d0e60c925e@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
 <7fB-mt4sW6w4IQxouj04Kks7wqoghJle2cAhZ64B5E0=.ff372d12-7b60-417a-817e-a8fb0dd2bbb9@github.com>
 <8jSOTOGnJ31njp76FduOxwLz067ac61VvLxdKiRbVhQ=.6eddfc0a-bfcd-4e14-bfc5-c0d0e60c925e@github.com>
Message-ID: 

On Mon, 12 May 2025 22:03:47 GMT, Sean Mullan  wrote:

>> I would probably just say "cryptographic objects that implement `DEREncodable`"
>
> Also change "may" to "can". "May" sounds like it is optional.

ok

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

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

From ascarpino at openjdk.org  Tue May 13 09:27:40 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 13 May 2025 09:27:40 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: <7fB-mt4sW6w4IQxouj04Kks7wqoghJle2cAhZ64B5E0=.ff372d12-7b60-417a-817e-a8fb0dd2bbb9@github.com>
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
 <7fB-mt4sW6w4IQxouj04Kks7wqoghJle2cAhZ64B5E0=.ff372d12-7b60-417a-817e-a8fb0dd2bbb9@github.com>
Message-ID: 

On Mon, 12 May 2025 22:20:23 GMT, Sean Mullan  wrote:

>> I think specifying the fields that are encoded makes it clear what is not in the encoding.
>
> I would have expected the leading data to be encoded. Why is the leading data not encoded?

Ok.  I added a comment to explicitly say no.
I documented in `PEMRecord` that `leadingData` is for reading metadata.

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

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

From ascarpino at openjdk.org  Tue May 13 09:27:40 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 13 May 2025 09:27:40 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14]
In-Reply-To: 
References: 
 <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com>
 
 <9mfjkYfNkAF1AcivrGWStoKBvYU7upfrujgMo5r6muI=.7e655046-04ae-4e76-9598-76b77dfb478f@github.com>
 
 
 
 
Message-ID: 

On Mon, 12 May 2025 19:19:32 GMT, Sean Mullan  wrote:

>> I'm assuming there is no more issues here.
>
> There is still a small issue. On line 228, a clone of the array is now being done when it doesn't have to. The previous code called the internal `getArrayS0` method which did not do a clone.

ok

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

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

From ascarpino at openjdk.org  Tue May 13 09:27:40 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 13 May 2025 09:27:40 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: 
References: 
 <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
 
Message-ID: 

On Mon, 12 May 2025 22:09:14 GMT, Sean Mullan  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments on the 11th
>
> src/java.base/share/classes/java/security/PEMEncoder.java line 61:
> 
>> 59:  * or by encoding an {@link EncryptedPrivateKeyInfo} .
>> 60:  *
>> 61:  * 
     PKCS #8 2.0 allows OneAsymmetricKey encoding, which may contain both
> 
> s/allows .../defines the ASN.1 OneAsymmetricKey structure/

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 62:
> 
>> 60:  *
>> 61:  * 
     PKCS #8 2.0 allows OneAsymmetricKey encoding, which may contain both
>> 62:  * private and public keys in the same PEM. This is supported by using the
> 
> PKCS #8 doesn't define PEM. Suggest  removing "in the same PEM".

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 63:
> 
>> 61:  * 
     PKCS #8 2.0 allows OneAsymmetricKey encoding, which may contain both
>> 62:  * private and public keys in the same PEM. This is supported by using the
>> 63:  * {@link KeyPair} class with the encode methods.
> 
> Suggest rewording 2nd sentence as: "`KeyPair` objects passed to the `encode` methods are encoded as a OneAsymmetricKey structure using the "PRIVATE KEY" type."

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 70:
> 
>> 68:  * the data.
>> 69:  *
>> 70:  * 
    {@code String} values encoded use character set
> 
> Why does this need to be mentioned if it is an RFC PEM requirement?

It was documented with `PEMDecoder` I thought I should put it here as well, but I can remove it.

> src/java.base/share/classes/java/security/PEMEncoder.java line 95:
> 
>> 93:  *       RFC 1421: Privacy Enhancement for Internet Electronic Mail
>> 94:  * @spec https://www.rfc-editor.org/info/rfc5958
>> 95:  *       RFC 5958: Asymmetric Key Packages
> 
> Do we really need to add RFC 5958 here? This class is just doing the PEM encoding, it doesn't implement RFC 5958.

@wangweij asked for it. If you disagree I can remove it.

> src/java.base/share/classes/java/security/PEMEncoder.java line 129:
> 
>> 127:      * Returns a new instance of {@code PEMEncoder}.
>> 128:      *
>> 129:      * @return new {@code PEMEncoder} instance
> 
> "new" sounds like it is a new instance each time this method is called. Suggest just saying "Returns a `PEMEncoder`"

Ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 136:
> 
>> 134: 
>> 135:     /**
>> 136:      * Encode the specified {@code DEREncodable} and return the PEM encoding in a
> 
> s/Encode/Encodes/
> 
> s/return/returns/

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 140:
> 
>> 138:      *
>> 139:      * @param de the {@code DEREncodable} to be encoded.
>> 140:      * @return PEM encoding in a string
> 
> Suggest: "a PEM encoded string"

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 141:
> 
>> 139:      * @param de the {@code DEREncodable} to be encoded.
>> 140:      * @return PEM encoding in a string
>> 141:      * @throws IllegalArgumentException when encoding the {@code DEREncodable}
> 
> Suggest: "if the `DEREncodable` cannot be encoded`

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 205:
> 
>> 203: 
>> 204:     /**
>> 205:      * Encodes the specified {@code DEREncodable} into PEM.
> 
> Make description consistent with other encode method: "Encodes the specified {@code DEREncodable} and returns the PEM encoding in a byte array."

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 208:
> 
>> 206:      *
>> 207:      * @param de the {@code DEREncodable} to be encoded.
>> 208:      * @return PEM encoded byte array
> 
> Suggest: "a byte array containing the PEM encoded data"

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 209:
> 
>> 207:      * @param de the {@code DEREncodable} to be encoded.
>> 208:      * @return PEM encoded byte array
>> 209:      * @throws IllegalArgumentException when encoding the {@code DEREncodable}
> 
> "If the `DEREncodable` cannot be encoded"

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 214:
> 
>> 212:      * @see #withEncryption(char[])
>> 213:      */
>> 214:     public byte[] encode(DEREncodable de) {
> 
> Is this method that useful? Caller can just do what line 215 is doing.

I think it's user friendly to when writing to a byte[] or OutputStream.  Base64.Encoder has byte[], ByteBuffer, and String.

> src/java.base/share/classes/java/security/PEMEncoder.java line 224:
> 
>> 222:      * 
     Only {@link PrivateKey} objects can be encrypted with this newly
>> 223:      * configured instance.  Encoding other {@link DEREncodable} objects will
>> 224:      * throw an{@code IllegalArgumentException}.
> 
> space after "an"

ok

> src/java.base/share/classes/java/security/PEMEncoder.java line 228:
> 
>> 226:      * @implNote The default algorithm is defined by Security Property {@code
>> 227:      * jdk.epkcs8.defaultAlgorithm} using default password-based encryption
>> 228:      * parameters by the supporting provider.  To configure all the encryption
> 
> Maybe reword as "If you need more control over the encryption algorithm and parameters, use the ..."

ok

> src/java.base/share/classes/java/security/PEMRecord.java line 116:
> 
>> 114:      *
>> 115:      * @param type the type identifier in the PEM header and footer, or {@code null} if there is no PEM data.
>> 116:      * @param pem The data between the PEM header and footer.
> 
> s/The/the/

ok

> src/java.base/share/classes/java/security/PEMRecord.java line 142:
> 
>> 140:      *
>> 141:      * @throws IllegalArgumentException if {@code pem} cannot be decoded.
>> 142:      * @return Returns a new array of the binary encoding each time this
> 
> Remove "Returns".

ok

> src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java line 72:
> 
>> 70:     private BigInteger coeff;   // CRT coefficient
>> 71: 
>> 72:     // RSA or RSS-PSS KeyType
> 
> Typo: s/RSS-PSS/RSA-PSS/

ok

> src/java.base/share/classes/sun/security/x509/X509Key.java line 147:
> 
>> 145:      * X509Key.  Useful for PKCS8v2.
>> 146:      */
>> 147:     public static X509Key parse(byte[] encoded) throws IOException
> 
> Isn't this the same as `X509Key.parse(byte[])`?

I'm assuming you mean `X509Key.decode()`?   It looks like that can be used instead of this method.

> src/java.base/share/classes/sun/security/x509/X509Key.java line 150:
> 
>> 148:     {
>> 149:         DerValue in = new DerValue(encoded);
>> 150:         AlgorithmId algorithm;
> 
> Can move to line 155.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085776593
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085777165
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085778467
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085803421
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085805970
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085806427
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085821485
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085822116
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085828381
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085846397
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085846463
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085846510
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2085850233
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086091768
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086100143
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086265099
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086270777
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086279737
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086340191
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086340372

From ascarpino at openjdk.org  Tue May 13 09:27:40 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 13 May 2025 09:27:40 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 9 May 2025 23:46:27 GMT, Weijun Wang  wrote:

>> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - comments
>>  - toString update
>>  - non-sealed
>>    Better X509 KeyPair parsing
>
> src/java.base/share/classes/java/security/PEMRecord.java line 51:
> 
>> 49:  * reached the end of the stream. If there is PEM data, {@code type} and
>> 50:  * {@code pem} will both be non-null. {@code leadingData} may be null if the
>> 51:  * input data only contains PEM data. All values can never be null.
> 
> It feels like the 2 paragraphs above should be in the spec of `Decoder::decode`. Here we only need to say what fields can be null.

ok

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

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

From mullan at openjdk.org  Tue May 13 12:32:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 12:32:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore  wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one review comment

src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 189:

> 187:      *           {@code UnsupportedOperationException}.
> 188:      *           Classes derived from ExtendedSSLSession must implement
> 189:      *           this method.

That statement is too strong, even though `getStatusResponses` has that text, unfortunately. For one, existing provider implementations of this class are binary compatible if they upgrade to JDK 25 because they don't have to implement this method right away since it has a default implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086679927

From mullan at openjdk.org  Tue May 13 12:32:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 12:32:55 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: 
References: 
 
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
 
Message-ID: <3tAuzjsCrqDcSi1mdrcdVDEnssuhzgibL4LNDxYUhBo=.979cf9e5-103c-45d0-8b13-153f03354ba8@github.com>

On Tue, 13 May 2025 05:13:42 GMT, Bradford Wetmore  wrote:

>> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 254:
>> 
>>> 252:      *
>>> 253:      * @return a byte array of size {@code length} that contains the EKM
>>> 254:      *         material, or null if the derived key material does not support
>> 
>> For "or null if the derived key material does not support encoding" why wouldn't an implementation throw UOE instead?
>
> I was following the SecretKey.getEncoded() style.  I see now that KDF.deriveData() does do UOE.  
> 
> I could go either way on this.  I do need to make this consistent, I have TLSv1.3 using KDF style, and TLSv1-TLSv1.2 using the null.

It seems like it should be an exception, whatever you decide to do. The caller is asking for the keying material data, and the provider cannot fulfill that request, so I think explaining why it could not be done would be best represented in an exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086700249

From weijun at openjdk.org  Tue May 13 13:09:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 13:09:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10]
In-Reply-To: <3tAuzjsCrqDcSi1mdrcdVDEnssuhzgibL4LNDxYUhBo=.979cf9e5-103c-45d0-8b13-153f03354ba8@github.com>
References: 
 
 <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com>
 
 <3tAuzjsCrqDcSi1mdrcdVDEnssuhzgibL4LNDxYUhBo=.979cf9e5-103c-45d0-8b13-153f03354ba8@github.com>
Message-ID: <0aTy62Fv0rHWbxxCZb_coUAIyenl0f0EMXnJHwzAj7M=.d0652548-7e5e-490f-b3c2-e660bc7ff4b9@github.com>

On Tue, 13 May 2025 12:26:54 GMT, Sean Mullan  wrote:

>> I was following the SecretKey.getEncoded() style.  I see now that KDF.deriveData() does do UOE.  
>> 
>> I could go either way on this.  I do need to make this consistent, I have TLSv1.3 using KDF style, and TLSv1-TLSv1.2 using the null.
>
> It seems like it should be an exception, whatever you decide to do. The caller is asking for the keying material data, and the provider cannot fulfill that request, so I think explaining why it could not be done would be best represented in an exception.

+1 for UOE. It's not that we got a key and found it un-extractable. It's that we asked for data but were refused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086786782

From weijun at openjdk.org  Tue May 13 13:27:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 13:27:54 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore  wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one review comment

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1598:

> 1596:             //     L    length of output keying material in octets
> 1597:             //          (<= 255*HashLen)
> 1598:             if (length >= (255 * cipherSuite.hashAlg.hashLength )) {

The opposite of `<=` is `>`.

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1650:

> 1648:                     emptyHash = md.digest();
> 1649:                 } catch (NoSuchAlgorithmException nsae) {
> 1650:                     throw new RuntimeException(

We usually throw a `ProviderException` here, when some weird configuration removes a basic hash algorithm.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086821812
PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086826499

From weijun at openjdk.org  Tue May 13 13:39:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 13:39:57 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore  wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one review comment

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1682:

> 1680:                     // ...now the final expand.
> 1681:                     return (deriveKey ?
> 1682:                             hkdf.deriveKey("TlsExporterKeyingMaterial",

Using a registered algorithm will make this method work, but I'm not sure if the resulting key can be used further. Do you know any typical use cases for the EKM?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2086854025

From abarashev at openjdk.org  Tue May 13 14:03:57 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 May 2025 14:03:57 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
Message-ID: 

On Tue, 13 May 2025 03:56:25 GMT, Hai-May Chao  wrote:

> It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).

@haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it's disabled system-wide.
Making this toggle SunX509-specific is a trivial change if we have a consensus on this.

@seanjmullan What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2876654496

From kdriver at openjdk.org  Tue May 13 15:05:55 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 13 May 2025 15:05:55 GMT
Subject: RFR: 8353578: Refactor existing usage of internal HKDF impl to use
 the KDF API [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 May 2025 21:19:10 GMT, Valerie Peng  wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> JPRT Tier1-3 result: https://mach5.us.oracle.com/mdash/jobs/vpeng-jdkOh3-20250512-2316-27739411 
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks from Brad.

Approving based on above discussion.

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

Marked as reviewed by kdriver (Committer).

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

From mullan at openjdk.org  Tue May 13 15:26:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 15:26:11 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v16]
In-Reply-To: 
References: 
 
 <7dEojWauO8Can1PEp7tJYCmHiaVSK80JDJmU4y1W7dY=.479f02c5-92b7-4ade-8391-65cbb1a349db@github.com>
 
Message-ID: 

On Sat, 10 May 2025 19:39:14 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMDecoder.java line 191:
>> 
>>> 189:                 }
>>> 190:                 case Pem.CERTIFICATE, Pem.X509_CERTIFICATE -> {
>>> 191:                     CertificateFactory cf = getCertFactory("X509");
>> 
>> Use "X.509". "X509" is an alias and may not be supported by other JDK implementations. Same comment on line 196.
>
> ok

This issue still needs to be fixed. Change `getCertFactory("X509")` to `getCertFactory("X.509")`

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

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

From duke at openjdk.org  Tue May 13 15:26:13 2025
From: duke at openjdk.org (Krushna948)
Date: Tue, 13 May 2025 15:26:13 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
References: 
 <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
Message-ID: 

On Sun, 11 May 2025 19:02:55 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 369:

> 367:         PBEKeySpec keySpec = new PBEKeySpec(password);
> 368:         SecretKey skey;
> 369:         Objects.requireNonNull(key);

@throws NullPointerException if the key or password are null.
But when password null case looks not handled?

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 451:

> 449:      * @throws RuntimeException on an encryption errors.  The cause may include
> 450:      * IllegalBlockSizeException, BadPaddingException, or InvalidKeyException.
> 451:      * @throws NullPointerException if the key or password are null. Also, if

@throws NullPointerException if the key or password are null.
Here it supposed to be -  throws NullPointerException if the key or enckey are null.?

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 548:

> 546:      * @throws InvalidKeyException if an error occurs during parsing of the
> 547:      * encrypted data or creation of the key object.
> 548:      *

Do we need to specify the RuntimeException cases in this documentation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086134022
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086145774
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2086163702

From mullan at openjdk.org  Tue May 13 15:26:15 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 15:26:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 09:27:37 GMT, Anthony Scarpino  wrote:

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

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

> 226:         ECOperations ops = ECOperations.forParameters(ecParams)
> 227:                 .orElseThrow(ProviderException::new);
> 228:         MutablePoint pub = ops.multiply(ecParams.getGenerator(), arrayS);

Can `arrayS` ever be `null` here?

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

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

From mullan at openjdk.org  Tue May 13 15:26:16 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 15:26:16 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 7 May 2025 16:34:24 GMT, Sean Mullan  wrote:

>> I added the exception
>
> `SecretKeyFactory.getInstance()` will throw `NullPointerException` if the property is undefined. You would need to add a try/catch block for NPE specifically, which you don't have right now.

This is still an issue. In `EncryptedKeyInfo.encryptKey`, SecretKeyFactory.getInstance() will throw NullPointerException if the property is undefined.

I think a reasonable workaround would be to also hardcode a default of PBEWithHmacSHA256AndAES_128 if the property is undefined.

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

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

From mullan at openjdk.org  Tue May 13 15:26:16 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 15:26:16 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: 
References: 
 <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
 
 
Message-ID: <1wUfnsSICJ_VXlMy8sFxi5RWtCvbihsgK6cPXnIwvGQ=.1bf02cfd-276f-43a0-a9ab-14b9fcbed86b@github.com>

On Tue, 13 May 2025 09:20:07 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/sun/security/x509/X509Key.java line 147:
>> 
>>> 145:      * X509Key.  Useful for PKCS8v2.
>>> 146:      */
>>> 147:     public static X509Key parse(byte[] encoded) throws IOException
>> 
>> Isn't this the same as `X509Key.parse(byte[])`?
>
> I'm assuming you mean `X509Key.decode()`?   It looks like that can be used instead of this method.

Maybe, but never mind, I thought I saw a duplicate `parse` method when I reviewed this earlier.

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

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

From alanb at openjdk.org  Tue May 13 15:53:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 May 2025 15:53:58 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici  wrote:

>> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into jla
>  - Improve `uncheckedGetBytesNoRepl` docs
>  - Apply suggestions from code review
>    
>    Co-authored-by: Roger Riggs 
>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>  - Fix `HexDigits` copyright year
>  - Fix copyright years
>  - Prefix touched methods with `unchecked`
>  - Fix typo in pre-existing JavaDoc
>  - Improve `JavaLangAccess` documentation

src/java.base/share/classes/java/lang/System.java line 2113:

> 2111: 
> 2112:             public int uncheckedCountPositives(byte[] bytes, int offset, int length) {
> 2113:                 return StringCoding.countPositives(bytes, offset, length);

The prefix means the method is uncheckedXXX when outside of java.lang, and XXX when in java.lang. Okay for this PR but I think we should follow-up and rename the methods in java.lang to uncheckedXXX, then introduce checked versions that do the bounds check.  In this case, we could have countPositives exposed via JLA, its implementation would do the bounds check before calling the unchecked version.  It would mean that "far away" callers in DIS, OIS, ZipCoder, ... would have a bounds check but it would make things easier to audit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2087154008

From bperez at openjdk.org  Tue May 13 16:49:36 2025
From: bperez at openjdk.org (Ben Perez)
Date: Tue, 13 May 2025 16:49:36 GMT
Subject: RFR: 8347606: Optimize Java implementation of ML-DSA [v3]
In-Reply-To: 
References: 
Message-ID: 

> It turns out that initializing a multidimensional array with `int[][] a = new int[rows][cols]` is slower than allocating each column in a loop. Since we do a lot of large multidimensional array allocations in ML-DSA, the optimized initialization improves performance by roughly 10%.

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  remove trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23642/files
  - new: https://git.openjdk.org/jdk/pull/23642/files/7ed6dbc4..886cc263

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

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

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

From weijun at openjdk.org  Tue May 13 17:04:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 17:04:53 GMT
Subject: RFR: 8347606: Optimize Java implementation of ML-DSA [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 16:49:36 GMT, Ben Perez  wrote:

>> It turns out that initializing a multidimensional array with `int[][] a = new int[rows][cols]` is slower than allocating each column in a loop. Since we do a lot of large multidimensional array allocations in ML-DSA, the optimized initialization improves performance by roughly 10%.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing whitespace

Looks good. You might need to add a `noreg-perf` label to the JBS bug and create a comment saying how much you gained from the change. https://openjdk.org/guide/#jbs-label-dictionary requires "the bug should describe how to verify the fix". Maybe you can just say what and what tests are run.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23642#pullrequestreview-2837524239

From abarashev at openjdk.org  Tue May 13 17:15:53 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 May 2025 17:15:53 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore  wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one review comment

test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 62:

> 60:  * produced.
> 61:  */
> 62: public class ExportKeyingMaterialTests extends SSLContextTemplate {

What's the reason we don't use `SSLEngineTemplate` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2087293357

From mullan at openjdk.org  Tue May 13 17:29:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 17:29:11 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 09:27:37 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/java/security/DEREncodable.java line 37:

> 35: 
> 36: /**
> 37:  * This is a top-level interface for security classes that contain cryptographic

Wording suggestion (taken from JEP): "This interface is implemented by security API classes that contain binary-encodable key or certificate material."

src/java.base/share/classes/java/security/DEREncodable.java line 40:

> 38:  * data which may not be related or have a common class hierarchy.  These
> 39:  * security objects provide standard binary encoding, like ASN.1, and possible
> 40:  * type formats, like X.509 and PKCS#8.

Wording suggestion (taken from JEP): "These APIs or their subclasses typically provide methods to convert their instances to and from byte arrays in the [Distinguished Encoding Rules (DER)](https://en.wikipedia.org/wiki/X.690#DER_encoding) format."

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

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

From wetmore at openjdk.org  Tue May 13 17:41:32 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 13 May 2025 17:41:32 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v13]
In-Reply-To: 
References: 
Message-ID: 

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
> 
> CSR is underway.
> 
> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)

Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into JDK-8341346
 - Missed one review comment
 - More codereview comments
 - Merge branch 'master' into JDK-8341346
 - Adjustments made for JDK-8350830
 - Merge branch 'master' into JDK-8341346
 - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
 - More Codereview comments
 - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
 - Add in the SharedSecrets SecretKeySpec clearing mechanism
 - ... and 6 more: https://git.openjdk.org/jdk/compare/d1543429...87ad9ead

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

Changes: https://git.openjdk.org/jdk/pull/24976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=12
  Stats: 1102 lines in 9 files changed: 1082 ins; 3 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976

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

From mullan at openjdk.org  Tue May 13 18:38:16 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 18:38:16 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: 
References: 
 <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
 
 
Message-ID: <0Z7fEhDCNlS5qwVW3B_vZMb3n8V0LbUfAsmQA-g_cNE=.7faa6787-eea1-4e12-af73-f125e3867026@github.com>

On Tue, 13 May 2025 02:21:57 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 129:
>> 
>>> 127:      * Returns a new instance of {@code PEMEncoder}.
>>> 128:      *
>>> 129:      * @return new {@code PEMEncoder} instance
>> 
>> "new" sounds like it is a new instance each time this method is called. Suggest just saying "Returns a `PEMEncoder`"
>
> Ok

Still has the "new" word.

>> src/java.base/share/classes/java/security/PEMEncoder.java line 214:
>> 
>>> 212:      * @see #withEncryption(char[])
>>> 213:      */
>>> 214:     public byte[] encode(DEREncodable de) {
>> 
>> Is this method that useful? Caller can just do what line 215 is doing.
>
> I think it's user friendly to when writing to a byte[] or OutputStream.  Base64.Encoder has byte[], ByteBuffer, and String.

Ok.

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

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

From mullan at openjdk.org  Tue May 13 18:38:17 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 18:38:17 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15]
In-Reply-To: 
References: 
 <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com>
 
 
Message-ID: <56rcFdOt7VTfuFYrq-mhkywjD9Dv5vYkBFNd_0JDbNA=.286f5ab8-9977-4713-8db4-eaa964659307@github.com>

On Fri, 9 May 2025 16:24:39 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 216:
>> 
>>> 214:     /**
>>> 215:      * Returns a new immutable PEMEncoder instance configured to the default
>>> 216:      * encryption algorithm and a given password.
>> 
>> s/a given/the specified/
>
> ok

Still unresolved.

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

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

From mullan at openjdk.org  Tue May 13 18:38:15 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 18:38:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 09:27:37 GMT, Anthony Scarpino  wrote:

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

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

> 53:  *
> 54:  * 
     Encoding may be performed on cryptographic objects that implement
> 55:  * {@link DEREncodable}.

Suggest adding another sentence after this: "The {@link encode(DEREncodable)} and {@link encodeToString(DEREncodable)} methods encode a `DEREncodable` into PEM and return the data in a byte array or String."

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

> 60:  * configured to encrypt the key with that password. Alternatively, a
> 61:  * private key encrypted as an {@code EncryptedKeyInfo} object can be encoded
> 62:  * directly to PEM by passing it to the encode method

s/encode method/`encode` or `encodeToString` methods./

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

> 64:  * 
     PKCS #8 2.0 defines the ASN.1 OneAsymmetricKey structure, which may
> 65:  * contain both private and public keys.
> 66:  * {@link KeyPair} objects passed to the {@code encode} methods are encoded as a

s/{@code encode}/{@code encode} or {@code encodeToString}/

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

> 68:  *
> 69:  * 
     When encoding a {@link PEMRecord}, the API surrounds the
> 70:  * {@linkplain PEMRecord#pem()} with a generated the PEM header and footer

delete "a generated".

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

> 70:  * {@linkplain PEMRecord#pem()} with a generated the PEM header and footer
> 71:  * from {@linkplain PEMRecord#type()}. {@linkplain PEMRecord#leadingData()} is
> 72:  * not included in the encoding.  {@code PEMRecord} will not preform

s/preform/perform/

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

> 82:  *
> 83:  * 
     Here is an example that encrypts and encodes a private key using the
> 84:  * specified password.

s/./:/

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

> 139:      * string.
> 140:      *
> 141:      * @param de the {@code DEREncodable} to be encoded.

Nit: no need for period.

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

> 140:      *
> 141:      * @param de the {@code DEREncodable} to be encoded.
> 142:      * @return a byte array containing the PEM encoded data

s/a byte array/a String/

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

> 141:      * @param de the {@code DEREncodable} to be encoded.
> 142:      * @return a byte array containing the PEM encoded data
> 143:      * @throws IllegalArgumentException If the DEREncodable cannot be encoded

s/If/if/

Put code around DEREncodable.

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

> 142:      * @return a byte array containing the PEM encoded data
> 143:      * @throws IllegalArgumentException If the DEREncodable cannot be encoded
> 144:      * @throws NullPointerException if {@code de} is {@code null}.

Nit: no need for period.

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

> 207:      * in a byte array.
> 208:      *
> 209:      * @param de the {@code DEREncodable} to be encoded.

Nit: no need for period.

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

> 209:      * @param de the {@code DEREncodable} to be encoded.
> 210:      * @return PEM encoded byte array
> 211:      * @throws IllegalArgumentException if the DEREncodable cannot be encoded

Put code around DEREncodable.

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

> 210:      * @return PEM encoded byte array
> 211:      * @throws IllegalArgumentException if the DEREncodable cannot be encoded
> 212:      * @throws NullPointerException if {@code de} is {@code null}.

Nit: no need for period.

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

> 214:      */
> 215:     public byte[] encode(DEREncodable de) {
> 216:         return encodeToString(de).getBytes(StandardCharsets.ISO_8859_1);

Side comment, can look at this later. Since `Base64.Encoder.encodeToString()` first encodes to bytes and then converts it to a String, it might be more efficient to do the same here.

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

> 218: 
> 219:     /**
> 220:      * Returns a new {@code PEMEncoder} instance configured with the default

s/configured/configured for encryption/

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

> 226:      *
> 227:      * @implNote The default algorithm is defined by Security Property {@code
> 228:      * jdk.epkcs8.defaultAlgorithm} using default password-based encryption

Wording suggestion: "The default password-based encryption algorithm is defined by the `jdk.epkcs8.defaultAlgorithm` security property and uses the default encryption parameters of the provider that is selected."

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

> 233:      * returned object with {@link #encode(DEREncodable)}.
> 234:      *
> 235:      * @param password sets the encryption password.  The array is cloned and

No need to say "sets".

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

> 235:      * @param password sets the encryption password.  The array is cloned and
> 236:      *                stored in the new instance. {@code null} is a valid value.
> 237:      * @return new configured {@code PEMEncoder} instance

Suggest: "a new {@code PEMEncoder} instance configured for encryption"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087411805
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087416237
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087417397
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087419002
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087419886
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087420308
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087358392
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087359029
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087360161
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087358550
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087345856
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087346460
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087346007
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087357208
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087398280
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087373659
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087389673
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087398501

From jrose at openjdk.org  Tue May 13 19:31:54 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 13 May 2025 19:31:54 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 7 May 2025 11:17:19 GMT, Volkan Yazici  wrote:

>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 302:
>> 
>>> 300:      * WARNING: This method does not perform any bound checks.
>>> 301:      */
>>> 302:     int countPositives(byte[] ba, int off, int len);
>> 
>> Maybe we should change countPositives to do a bounds check and have a private method in StringCoding be the `@IntrinsicCandidate`. This would make it easier to audit. Right now it's hard to audit because there are usages of JLA.countPositives in faraway classes. I'm not suggested we do this as part of this PR of course but it would mean the warning comment could be removed.
>
> Submitted [8356380](https://bugs.openjdk.org/browse/JDK-8356380) to address this.

See also pending PR https://github.com/openjdk/jdk/pull/24777

It documents the expectations of how an intrinsic method must be kept private.

An intrinsic is a private "back door" in the VM, and must not be accessed (except perhaps in carefully documented unusual circumstances) outside of its own source file.  There should be a non-private "front door" in the same source file which applies all relevant checks before calling the intrinsic.

Such checks need to be at least as strong as the built-in JVM range checks, null checks, and type checks that would be performed, if the intrinsic were implemented in 100% pure Java bytecodes.

In performance evaluations, such checks may appear to be redundant.  But they must not be removed.  Instead, whatever other checks are redundant with them (there must be some!) should be brought into the same C2 compilation task as the "front door" checks.  This requires making the two sets of checks (if there are two) look similar enough that C2 (or another JIT) can recognize their redundance.  Bringing the checks into the same task might require a ForceInline annotation (which is allowed only inside the JDK).  Recognizing the checks as redundant might require a C2 bug fix or RFE.

(The javadoc for IntrinsicCandidate says stuff like this.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2087493446

From vyazici at openjdk.org  Tue May 13 19:34:57 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 13 May 2025 19:34:57 GMT
Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods
 [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 13 May 2025 15:51:12 GMT, Alan Bateman  wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into jla
>>  - Improve `uncheckedGetBytesNoRepl` docs
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Roger Riggs 
>>  - Prefixed `JavaLangAccess::stringConcat1` with `unchecked`
>>  - Fix `HexDigits` copyright year
>>  - Fix copyright years
>>  - Prefix touched methods with `unchecked`
>>  - Fix typo in pre-existing JavaDoc
>>  - Improve `JavaLangAccess` documentation
>
> src/java.base/share/classes/java/lang/System.java line 2113:
> 
>> 2111: 
>> 2112:             public int uncheckedCountPositives(byte[] bytes, int offset, int length) {
>> 2113:                 return StringCoding.countPositives(bytes, offset, length);
> 
> The prefix means the method is uncheckedXXX when outside of java.lang, and XXX when in java.lang. Okay for this PR but I think we should follow-up and rename the methods in java.lang to uncheckedXXX, then introduce checked versions that do the bounds check.  In this case, we could have countPositives exposed via JLA, its implementation would do the bounds check before calling the unchecked version.  It would mean that "far away" callers in DIS, OIS, ZipCoder, ... would have a bounds check but it would make things easier to audit.

[8356380: Check bounds for JavaLangAccess::countPositives](https://bugs.openjdk.org/browse/JDK-8356380) will address this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24982#discussion_r2087497657

From mullan at openjdk.org  Tue May 13 20:58:12 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 20:58:12 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 09:27:37 GMT, Anthony Scarpino  wrote:

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

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

> 52:  * methods return an instance of a class that matches the data
> 53:  * type and implements {@link DEREncodable}. The
> 54:  * following types are decoded into Java Cryptographic Extensions (JCE) object

Lets make the wording consistent with PEMEncoder: "... into cryptographic objects that implement {@link DEREncodable}"

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

> 131:      * Returns an instance of {@code PEMDecoder}.
> 132:      *
> 133:      * @return new {@code PEMDecoder} instance

s/new/a/

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

> 222:      *
> 223:      * 
    This method reads the {@code String} until the first PEM data is found
> 224:      * or the end the {@code String} is reached.  Non-PEM data before the PEM

s/end/end of/

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

> 456: 
> 457:     /**
> 458:      * Configures and returns a new {@code PEMDecoder} instance from the

Change the wording to be consistent with `withDecryption`: "Returns a copy of this `PEMDecoder` that will use ..."

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

> 457:     /**
> 458:      * Configures and returns a new {@code PEMDecoder} instance from the
> 459:      * current instance that will use {@link KeyFactory} and

s/will use/uses/

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

> 458:      * Configures and returns a new {@code PEMDecoder} instance from the
> 459:      * current instance that will use {@link KeyFactory} and
> 460:      * {@link CertificateFactory} classes from the specified {@link Provider}.

Suggest saying what they are used for: 

s/from the specified {@link Provider}/from the specified {@link Provider} to produce cryptographic objects./

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

> 458:      * Configures and returns a new {@code PEMDecoder} instance from the
> 459:      * current instance that will use {@link KeyFactory} and
> 460:      * {@link CertificateFactory} classes from the specified {@link Provider}.

"classes" should probably be "implementations".

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

> 462:      *
> 463:      * 
    If {@code provider} is {@code null}, a new instance is returned with
> 464:      * the default provider configuration.

IMHO, I think this is working around a bug in the calling code and an NPE should be thrown instead.

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

> 465:      *
> 466:      * @param provider the factory provider
> 467:      * @return new configured {@code PEMDecoder} instance

Suggest: "a new `PEMDecoder` instance configured with the specified provider"

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

> 472: 
> 473:     /**
> 474:      * Returns a copy of this PEMDecoder that will decrypt encrypted PEM data

Put code around PEMDecoder.

s/will decrypt/decrypts/

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

> 473:     /**
> 474:      * Returns a copy of this PEMDecoder that will decrypt encrypted PEM data
> 475:      * such as encrypted private keys with the specified password.

"such as" sounds like it may support others but there is only private keys. Suggest being more specific: "Returns a copy of this `PEMDecoder` that decodes and decrypts encrypted private keys using the specified password."

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

> 474:      * Returns a copy of this PEMDecoder that will decrypt encrypted PEM data
> 475:      * such as encrypted private keys with the specified password.
> 476:      * Non-encrypted PEM may still be decoded from this instance.

"may" sounds like it is optional to support, suggest using "can". Maybe say "PEM types that are not encrypted can also be decoded from this instance."

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

> 478:      * @param password the password to decrypt encrypted PEM data.  This array
> 479:      *                 is cloned and stored in the new instance.
> 480:      * @return new configured {@code PEMDecoder} instance

Suggest: "a new `PEMEncoder` instance configured for decryption"

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

> 234:      *
> 235:      * @param password sets the encryption password.  The array is cloned and
> 236:      *                stored in the new instance. {@code null} is a valid value.

Why allow `null` here but not in `PEMDecoder.withDecryption`. I think we should probably disallow null. Even though PBEKeySpec allows it, I think it is for a corner case that might not be relevant here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087619323
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087506523
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087559801
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087512679
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087513847
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087515197
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087525022
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087518920
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087526437
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087529029
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087539558
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087543007
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087547542
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087551104

From ascarpino at openjdk.org  Tue May 13 21:45:32 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 13 May 2025 21:45:32 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v19]
In-Reply-To: 
References: 
Message-ID: 

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

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17543/files
  - new: https://git.openjdk.org/jdk/pull/17543/files/727e9962..0eef6606

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

  Stats: 175 lines in 6 files changed: 32 ins; 36 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/17543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543

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

From abarashev at openjdk.org  Tue May 13 21:46:56 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 13 May 2025 21:46:56 GMT
Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 17:41:32 GMT, Bradford Wetmore  wrote:

>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively.
>> 
>> CSR is underway.
>> 
>> Tests include new unit tests for TLSv1-1.3.  Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto)
>
> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into JDK-8341346
>  - Missed one review comment
>  - More codereview comments
>  - Merge branch 'master' into JDK-8341346
>  - Adjustments made for JDK-8350830
>  - Merge branch 'master' into JDK-8341346
>  - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing
>  - More Codereview comments
>  - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation)
>  - Add in the SharedSecrets SecretKeySpec clearing mechanism
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/d1543429...87ad9ead

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1583:

> 1581:         // Calculations are primarily based on protocol version.
> 1582:         switch (protocolVersion) {
> 1583:         case TLS13:  // HKDF-based

Should we also handle `TLS13Plus` versions here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2087679309

From mullan at openjdk.org  Tue May 13 21:55:12 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 May 2025 21:55:12 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18]
In-Reply-To: 
References: 
 
Message-ID: <3Xf8vEzR4xxXSCY3kq13KNKAoSxSY76jMtSgEMjGJMw=.67af6542-6b14-441a-b757-7ac7c76b5a14@github.com>

On Tue, 13 May 2025 09:27:37 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/java/security/PEMRecord.java line 42:

> 40:  * {@code DEREncodable} for the type.
> 41:  *
> 42:  * 
    {@code PEMRecord} may have a null {@code type} and {@code pem} when

I think this sentence can be removed now that non-PEM data is considered an error.

src/java.base/share/classes/java/security/PEMRecord.java line 48:

> 46:  *
> 47:  * 
     During the instantiation of this record, there is no validation for the
> 48:  * {@code type} or {@code pem}.

The ctors throw `IllegalArgumentException` though. I think you need to be more specific about what type of validation you mean here.

src/java.base/share/classes/java/security/PEMRecord.java line 76:

> 74:      *             {@code null} if there is no PEM data.
> 75:      * @param pem the data between the PEM header and footer.
> 76:      * @param leadingData Any non-PEM data read during the decoding process

s/Any/any/

src/java.base/share/classes/java/security/PEMRecord.java line 77:

> 75:      * @param pem the data between the PEM header and footer.
> 76:      * @param leadingData Any non-PEM data read during the decoding process
> 77:      *                    before the PEM header.  This value maybe {@code null}.

s/maybe/may be/

src/java.base/share/classes/java/security/PEMRecord.java line 87:

> 85:         if (type == null && pem != null || type != null && pem == null) {
> 86:             throw new IllegalArgumentException("\"type\" and \"pem\" must be" +
> 87:                 " both null or non-null");

If type and pem can be both null, and leadingData is also null (which is allowed per spec) then that should not be an error?

This check may need to be updated now that non-PEM data is an error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087677034
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087681167
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087680087
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087680232
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087684345

From weijun at openjdk.org  Tue May 13 22:05:11 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 22:05:11 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v19]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 21:45:32 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/java/security/PEMRecord.java line 50:

> 48:  * 
     During the instantiation of this record, there is no validation
> 49:  * for the {@code type} or {@code pem}. {@code leadingData} is not
> 50:  * defensively copied.

Not only instantiation, but the data is also not defensively copied when someone calls `leadingData`. Do we need to mention this as well?

src/java.base/share/classes/java/security/PEMRecord.java line 76:

> 74:      *                    before the PEM header.  This value maybe {@code null}.
> 75:      * @throws IllegalArgumentException if the {@code type} is incorrectly
> 76:      * formatted.

Is there a place defining what is a correctly formatted `type`?

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

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

From weijun at openjdk.org  Tue May 13 22:05:13 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 22:05:13 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17]
In-Reply-To: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
References: 
 <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com>
Message-ID: 

On Sun, 11 May 2025 19:02:55 GMT, Anthony Scarpino  wrote:

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

src/java.base/share/classes/java/security/PEMRecord.java line 101:

> 99:         // including lowercase.  The onus is on the caller.
> 100:         if (type != null && (type.startsWith("-") || type.contains("BEGIN") ||
> 101:             type.contains("END") || type.endsWith("-"))) {

How about checking for `startsWith("BEGIN?")` and `startsWith("END?")`. Maybe some day there will be a type named "ENDPOINT" or "BACKEND NAME".

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

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

From weijun at openjdk.org  Tue May 13 22:32:15 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 May 2025 22:32:15 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v19]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 May 2025 21:45:32 GMT, Anthony Scarpino  wrote:

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

Quickly going through public APIs.

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

> 59:  *
> 60: * > 61: *

If the PEM does not have a JCE object representation, it returns a Not "it", but the two methods. src/java.base/share/classes/java/security/PEMDecoder.java line 69: > 67: * methods are useful when extracting or changing the return class. > 68: * The Class parameter can specify the returned > 69: * key object from a PEM containing a public and private key. If only Not always "key". If this is meant to be an example, prepend with "For example". src/java.base/share/classes/java/security/PEMDecoder.java line 89: > 87: * decoder not configured for decryption, an {@link EncryptedPrivateKeyInfo} > 88: * object is returned. {@code EncryptedPrivateKeyInfo} methods must be used to > 89: * retrieve the {@link PrivateKey}. Do we need this last sentence? "EncryptedPrivateKeyInfo methods must be used to...". src/java.base/share/classes/java/security/PEMDecoder.java line 97: > 95: * PEMDecoder pd = PEMDecoder.of(); > 96: * PrivateKey priKey = pd.decode(priKeyPEM, PrivateKey.class); > 97: * } Add examples on `withFactory` and `withDecryption`. src/java.base/share/classes/java/security/PEMDecoder.java line 133: > 131: * Returns an instance of {@code PEMDecoder}. > 132: * > 133: * @return a new {@code PEMDecoder} instance Not always new. src/java.base/share/classes/java/security/PEMDecoder.java line 234: > 232: * {@code leadingData}. > 233: * > 234: *

If no PEM data is found, an {@code IllegalArgumentException} is Duplicated sentence. Or do you mean to say the same exception is thrown if decoding fails? src/java.base/share/classes/java/security/PEMDecoder.java line 281: > 279: * @param is InputStream containing PEM data > 280: * @return a {@code DEREncodable} > 281: * @throws IOException on IO error with the {@code InputStream} Since IOE is not purely IO error and contains format errors that are not recoverable. Do you want to say more? src/java.base/share/classes/java/security/PEMDecoder.java line 283: > 281: * @throws IOException on IO error with the {@code InputStream} > 282: * @throws EOFException the end of {@code InputStream} has been > 283: * unexpectedly reached. Not really "unexpected". It looks like every program that tries to read multiple PEM blocks will encounter this. src/java.base/share/classes/java/security/PEMDecoder.java line 285: > 283: * unexpectedly reached. > 284: * @throws IllegalArgumentException on error in decoding or no PEM data > 285: * found "no PEM data found". Isn't that EOFException? src/java.base/share/classes/java/security/PEMDecoder.java line 312: > 310: * {@link java.nio.charset.StandardCharsets#UTF_8 UTF-8}. > 311: * > 312: *

For all other class parameters, {@code IllegalArgumentException} is "For all other class parameters", you mean not `PEMRecord`? There is a paragraph in between (UTF-8 thingy) and users have forgotten what "other" means. src/java.base/share/classes/java/security/PEMDecoder.java line 325: > 323: * @throws NullPointerException when any input values are null. > 324: * > 325: * @see PEMDecoder for how {@code tClass} can be used. Since it's a `@see`, let's make the title a little more formal. Maybe add a header (`

`) in the spec. src/java.base/share/classes/java/security/PEMEncoder.java line 127: > 125: > 126: /** > 127: * Returns a new instance of {@code PEMEncoder}. Not always new. ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2838231399 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087706506 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087707481 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087708948 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087709526 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087709760 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087711953 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087714476 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087713003 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087713801 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087716326 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087717780 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087702103 From weijun at openjdk.org Tue May 13 22:32:16 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 13 May 2025 22:32:16 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 19:46:27 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments on the 11th > > src/java.base/share/classes/java/security/PEMDecoder.java line 464: > >> 462: * >> 463: *

If {@code provider} is {@code null}, a new instance is returned with >> 464: * the default provider configuration. > > IMHO, I think this is working around a bug in the calling code and an NPE should be thrown instead. Yes, it's not worth calling `withFactory(null)` to remove preferred provider configuration. We already have `PEMDecoder.of()`. > src/java.base/share/classes/java/security/PEMEncoder.java line 62: > >> 60: * configured to encrypt the key with that password. Alternatively, a >> 61: * private key encrypted as an {@code EncryptedKeyInfo} object can be encoded >> 62: * directly to PEM by passing it to the encode method > > s/encode method/`encode` or `encodeToString` methods./ Add a period at the end. Do we need to say `of a normal PEMEncoder` since encryption is done elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087720438 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087698926 From bperez at openjdk.org Tue May 13 22:35:00 2025 From: bperez at openjdk.org (Ben Perez) Date: Tue, 13 May 2025 22:35:00 GMT Subject: Integrated: 8347606: Optimize Java implementation of ML-DSA In-Reply-To: References: Message-ID: On Fri, 14 Feb 2025 16:43:32 GMT, Ben Perez wrote: > It turns out that initializing a multidimensional array with `int[][] a = new int[rows][cols]` is slower than allocating each column in a loop. Since we do a lot of large multidimensional array allocations in ML-DSA, the optimized initialization improves performance by roughly 10%. This pull request has now been integrated. Changeset: 10dcdf1b Author: Ben Perez URL: https://git.openjdk.org/jdk/commit/10dcdf1b4738efc6b4deaf96f4d123aff4dab832 Stats: 54 lines in 1 file changed: 23 ins; 1 del; 30 mod 8347606: Optimize Java implementation of ML-DSA Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/23642 From valeriep at openjdk.org Tue May 13 22:46:56 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 13 May 2025 22:46:56 GMT Subject: Integrated: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API In-Reply-To: References: Message-ID: <-RXSFZSKuTQ4g_b87-nDHz791zDNbV9_DpMLf2viYc0=.a8843054-75fc-4681-8f4e-b4d5044935ea@github.com> On Wed, 2 Apr 2025 21:43:19 GMT, Valerie Peng wrote: > This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers. > > This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider. > > JPRT Tier1-3 result: https://mach5.us.oracle.com/mdash/jobs/vpeng-jdkOh3-20250512-2316-27739411 > > Thanks in advance for the review~ This pull request has now been integrated. Changeset: 4c0a0ab6 Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/4c0a0ab6bc765c46d2c4b8320418d30abee24a91 Stats: 938 lines in 24 files changed: 157 ins; 571 del; 210 mod 8353578: Refactor existing usage of internal HKDF impl to use the KDF API Co-authored-by: Kevin Driver Reviewed-by: djelinski, wetmore, mullan, kdriver, weijun ------------- PR: https://git.openjdk.org/jdk/pull/24393 From wetmore at openjdk.org Wed May 14 00:31:13 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 14 May 2025 00:31:13 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v14] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge - Merge branch 'master' into JDK-8341346 - Missed one review comment - More codereview comments - Merge branch 'master' into JDK-8341346 - Adjustments made for JDK-8350830 - Merge branch 'master' into JDK-8341346 - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing - More Codereview comments - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation) - ... and 7 more: https://git.openjdk.org/jdk/compare/a96424b2...cc265d68 ------------- Changes: https://git.openjdk.org/jdk/pull/24976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=13 Stats: 1094 lines in 8 files changed: 1080 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From sviswanathan at openjdk.org Wed May 14 00:41:56 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 14 May 2025 00:41:56 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v4] In-Reply-To: References: Message-ID: <-L1FHPpbVOvHTxMFUPMGIY9g8UFAFmJDgNRkoFONKnI=.ddef5354-e00f-4c2a-80c3-b48325fe51d2@github.com> On Mon, 12 May 2025 09:05:10 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Restoring copyright notice on ML_KEM.java Only reviewed three intrinsics so far, more review to do. src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 693: > 691: // a (short[256]) = c_rarg1 > 692: // b (short[256]) = c_rarg2 > 693: // kyberConsts (short[40]) = c_rarg3 kyberConsts is not one of the arguments passed in. src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 696: > 694: address generate_kyberAddPoly_2_avx512(StubGenerator *stubgen, > 695: MacroAssembler *_masm) { > 696: The Java code for "implKyberAddPoly(short[] result, short[] a, short[] b)" does BarrettReduction but the intrinsic code here does not. Is that intentional and how is the reduction handled? src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 742: > 740: // b (short[256]) = c_rarg2 > 741: // c (short[256]) = c_rarg3 > 742: // kyberConsts (short[40]) = c_rarg4 kyberConsts is not one of the arguments passed in. src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 799: > 797: // parsedLength (int) = c_rarg3 > 798: address generate_kyber12To16_avx512(StubGenerator *stubgen, > 799: MacroAssembler *_masm) { If AVX512_VBMI and AVX512_VBMI2 is available, it looks to me that the loop body of this algorithm can be implemented using more efficient instructions in simple 5 steps: Step 1: Load 0-47, 48-95, 96-143, 144-191 condensed bytes into xmm0, xmm1, xmm2, xmm3 respectively using masked load. Step 2: Use vpermb to arrange xmm0 such that bytes 1, 4, 7, ... are duplicated xmm0 before b47, b46, ..., b0 where each b is a byte xmm0 after b47 b46 b46 b45, ......., b5 b4 b4 b3 b2 b1 b1 b0 Repeat this for xmm1, xmm2, xmm3 Step 3: Use vpshldvw to shift every word (16 bits) in the xmm0 appropriately with variable shift Shift word 31 by 4, word 30 by 0, ... word 3 by 4, word 2 by 0, word 1 by 4, word 0 by 0 Repeat this for xmm1, xmm2, xmm3 Step 4: Use vpand to "and" each word element in xmm0 by 0xfff. Repeat this for xmm1, xmm2, xmm3 Step 5: Store xmm0 into parsed Store xmm1 into parsed + 64 Store xmm2 into parsed +128 Store xmm3 into parsed + 192 If you think there is not sufficient time, we could look into it after the merge of this PR as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/24953#pullrequestreview-2837616051 PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2087361991 PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2087377640 PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2087331798 PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2087834072 From wetmore at openjdk.org Wed May 14 04:03:44 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 14 May 2025 04:03:44 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Merged with changes for JDK-8353578 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/cc265d68..513c8032 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=13-14 Stats: 14 lines in 2 files changed: 1 ins; 10 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From ascarpino at openjdk.org Wed May 14 08:25:41 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 14 May 2025 08:25:41 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: > Hi all, > > I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. > > Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17543/files - new: https://git.openjdk.org/jdk/pull/17543/files/0eef6606..2d83925e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=18-19 Stats: 206 lines in 7 files changed: 28 ins; 85 del; 93 mod Patch: https://git.openjdk.org/jdk/pull/17543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543 PR: https://git.openjdk.org/jdk/pull/17543 From ascarpino at openjdk.org Wed May 14 08:25:45 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 14 May 2025 08:25:45 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 17:15:39 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments on the 11th > > src/java.base/share/classes/java/security/DEREncodable.java line 37: > >> 35: >> 36: /** >> 37: * This is a top-level interface for security classes that contain cryptographic > > Wording suggestion (taken from JEP): "This interface is implemented by security API classes that contain binary-encodable key or certificate material." ok > src/java.base/share/classes/java/security/DEREncodable.java line 40: > >> 38: * data which may not be related or have a common class hierarchy. These >> 39: * security objects provide standard binary encoding, like ASN.1, and possible >> 40: * type formats, like X.509 and PKCS#8. > > Wording suggestion (taken from JEP): "These APIs or their subclasses typically provide methods to convert their instances to and from byte arrays in the [Distinguished Encoding Rules (DER)](https://en.wikipedia.org/wiki/X.690#DER_encoding) format." I changed the text, I didn't add a link as the one you included was wikipedia, which I don't know if that's stable enough for javadoc. The other link I found was to a PDF, which I don't think is allowed either. What I can do is put the spec in there "ITU X.690" > src/java.base/share/classes/java/security/PEMDecoder.java line 54: > >> 52: * methods return an instance of a class that matches the data >> 53: * type and implements {@link DEREncodable}. The >> 54: * following types are decoded into Java Cryptographic Extensions (JCE) object > > Lets make the wording consistent with PEMEncoder: "... into cryptographic objects that implement {@link DEREncodable}" ok > src/java.base/share/classes/java/security/PEMDecoder.java line 133: > >> 131: * Returns an instance of {@code PEMDecoder}. >> 132: * >> 133: * @return new {@code PEMDecoder} instance > > s/new/a/ ok > src/java.base/share/classes/java/security/PEMDecoder.java line 224: > >> 222: * >> 223: *

This method reads the {@code String} until the first PEM data is found >> 224: * or the end the {@code String} is reached. Non-PEM data before the PEM > > s/end/end of/ ok > src/java.base/share/classes/java/security/PEMDecoder.java line 458: > >> 456: >> 457: /** >> 458: * Configures and returns a new {@code PEMDecoder} instance from the > > Change the wording to be consistent with `withDecryption`: "Returns a copy of this `PEMDecoder` that will use ..." ok > src/java.base/share/classes/java/security/PEMDecoder.java line 459: > >> 457: /** >> 458: * Configures and returns a new {@code PEMDecoder} instance from the >> 459: * current instance that will use {@link KeyFactory} and > > s/will use/uses/ ok > src/java.base/share/classes/java/security/PEMDecoder.java line 460: > >> 458: * Configures and returns a new {@code PEMDecoder} instance from the >> 459: * current instance that will use {@link KeyFactory} and >> 460: * {@link CertificateFactory} classes from the specified {@link Provider}. > > Suggest saying what they are used for: > > s/from the specified {@link Provider}/from the specified {@link Provider} to produce cryptographic objects./ ok > src/java.base/share/classes/java/security/PEMDecoder.java line 474: > >> 472: >> 473: /** >> 474: * Returns a copy of this PEMDecoder that will decrypt encrypted PEM data > > Put code around PEMDecoder. > > s/will decrypt/decrypts/ ok > src/java.base/share/classes/java/security/PEMDecoder.java line 475: > >> 473: /** >> 474: * Returns a copy of this PEMDecoder that will decrypt encrypted PEM data >> 475: * such as encrypted private keys with the specified password. > > "such as" sounds like it may support others but there is only private keys. Suggest being more specific: "Returns a copy of this `PEMDecoder` that decodes and decrypts encrypted private keys using the specified password." ok > src/java.base/share/classes/java/security/PEMDecoder.java line 476: > >> 474: * Returns a copy of this PEMDecoder that will decrypt encrypted PEM data >> 475: * such as encrypted private keys with the specified password. >> 476: * Non-encrypted PEM may still be decoded from this instance. > > "may" sounds like it is optional to support, suggest using "can". Maybe say "PEM types that are not encrypted can also be decoded from this instance." ok > src/java.base/share/classes/java/security/PEMEncoder.java line 66: > >> 64: *

PKCS #8 2.0 defines the ASN.1 OneAsymmetricKey structure, which may >> 65: * contain both private and public keys. >> 66: * {@link KeyPair} objects passed to the {@code encode} methods are encoded as a > > s/{@code encode}/{@code encode} or {@code encodeToString}/ ok > src/java.base/share/classes/java/security/PEMEncoder.java line 70: > >> 68: * >> 69: *

When encoding a {@link PEMRecord}, the API surrounds the >> 70: * {@linkplain PEMRecord#pem()} with a generated the PEM header and footer > > delete "a generated". ok > src/java.base/share/classes/java/security/PEMEncoder.java line 72: > >> 70: * {@linkplain PEMRecord#pem()} with a generated the PEM header and footer >> 71: * from {@linkplain PEMRecord#type()}. {@linkplain PEMRecord#leadingData()} is >> 72: * not included in the encoding. {@code PEMRecord} will not preform > > s/preform/perform/ ok > src/java.base/share/classes/java/security/PEMEncoder.java line 84: > >> 82: * >> 83: *

Here is an example that encrypts and encodes a private key using the >> 84: * specified password. > > s/./:/ ok > src/java.base/share/classes/java/security/PEMEncoder.java line 141: > >> 139: * string. >> 140: * >> 141: * @param de the {@code DEREncodable} to be encoded. > > Nit: no need for period. ok > src/java.base/share/classes/java/security/PEMEncoder.java line 142: > >> 140: * >> 141: * @param de the {@code DEREncodable} to be encoded. >> 142: * @return a byte array containing the PEM encoded data > > s/a byte array/a String/ oops > src/java.base/share/classes/java/security/PEMEncoder.java line 143: > >> 141: * @param de the {@code DEREncodable} to be encoded. >> 142: * @return a byte array containing the PEM encoded data >> 143: * @throws IllegalArgumentException If the DEREncodable cannot be encoded > > s/If/if/ > > Put code around DEREncodable. ok > src/java.base/share/classes/java/security/PEMEncoder.java line 144: > >> 142: * @return a byte array containing the PEM encoded data >> 143: * @throws IllegalArgumentException If the DEREncodable cannot be encoded >> 144: * @throws NullPointerException if {@code de} is {@code null}. > > Nit: no need for period. ok > src/java.base/share/classes/java/security/PEMEncoder.java line 209: > >> 207: * in a byte array. >> 208: * >> 209: * @param de the {@code DEREncodable} to be encoded. > > Nit: no need for period. ok > src/java.base/share/classes/java/security/PEMEncoder.java line 211: > >> 209: * @param de the {@code DEREncodable} to be encoded. >> 210: * @return PEM encoded byte array >> 211: * @throws IllegalArgumentException if the DEREncodable cannot be encoded > > Put code around DEREncodable. ok > src/java.base/share/classes/java/security/PEMEncoder.java line 212: > >> 210: * @return PEM encoded byte array >> 211: * @throws IllegalArgumentException if the DEREncodable cannot be encoded >> 212: * @throws NullPointerException if {@code de} is {@code null}. > > Nit: no need for period. ok > src/java.base/share/classes/java/security/PEMEncoder.java line 216: > >> 214: */ >> 215: public byte[] encode(DEREncodable de) { >> 216: return encodeToString(de).getBytes(StandardCharsets.ISO_8859_1); > > Side comment, can look at this later. Since `Base64.Encoder.encodeToString()` first encodes to bytes and then converts it to a String, it might be more efficient to do the same here. noted > src/java.base/share/classes/java/security/PEMEncoder.java line 220: > >> 218: >> 219: /** >> 220: * Returns a new {@code PEMEncoder} instance configured with the default > > s/configured/configured for encryption/ ok > src/java.base/share/classes/java/security/PEMEncoder.java line 228: > >> 226: * >> 227: * @implNote The default algorithm is defined by Security Property {@code >> 228: * jdk.epkcs8.defaultAlgorithm} using default password-based encryption > > Wording suggestion: "The default password-based encryption algorithm is defined by the `jdk.epkcs8.defaultAlgorithm` security property and uses the default encryption parameters of the provider that is selected." ok > src/java.base/share/classes/java/security/PEMEncoder.java line 235: > >> 233: * returned object with {@link #encode(DEREncodable)}. >> 234: * >> 235: * @param password sets the encryption password. The array is cloned and > > No need to say "sets". ok > src/java.base/share/classes/java/security/PEMEncoder.java line 236: > >> 234: * >> 235: * @param password sets the encryption password. The array is cloned and >> 236: * stored in the new instance. {@code null} is a valid value. > > Why allow `null` here but not in `PEMDecoder.withDecryption`. I think we should probably disallow null. Even though PBEKeySpec allows it, I think it is for a corner case that might not be relevant here. I was supporting what PBEKeySpec allowed. Maybe with EPKI methods available to allow null, maybe this method could be more restrictive. > src/java.base/share/classes/java/security/PEMRecord.java line 76: > >> 74: * {@code null} if there is no PEM data. >> 75: * @param pem the data between the PEM header and footer. >> 76: * @param leadingData Any non-PEM data read during the decoding process > > s/Any/any/ ok > src/java.base/share/classes/java/security/PEMRecord.java line 77: > >> 75: * @param pem the data between the PEM header and footer. >> 76: * @param leadingData Any non-PEM data read during the decoding process >> 77: * before the PEM header. This value maybe {@code null}. > > s/maybe/may be/ ok > src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 228: > >> 226: ECOperations ops = ECOperations.forParameters(ecParams) >> 227: .orElseThrow(ProviderException::new); >> 228: MutablePoint pub = ops.multiply(ecParams.getGenerator(), arrayS); > > Can `arrayS` ever be `null` here? Looks like it's possible ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087623623 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087624162 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087628211 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087641064 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087641806 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087726601 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087783466 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087783562 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087792527 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087794079 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087796063 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087800696 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087806171 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087807018 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087807683 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087815513 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087815610 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087817444 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087817932 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087818027 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087818069 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087818128 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087821133 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087822205 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087826110 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087826224 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087827313 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087832770 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087833098 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088103430 From ascarpino at openjdk.org Wed May 14 08:25:51 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 14 May 2025 08:25:51 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v19] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 22:13:13 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments > > src/java.base/share/classes/java/security/PEMDecoder.java line 61: > >> 59: * >> 60: * >> 61: *

If the PEM does not have a JCE object representation, it returns a > > Not "it", but the two methods. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 69: > >> 67: * methods are useful when extracting or changing the return class. >> 68: * The Class parameter can specify the returned >> 69: * key object from a PEM containing a public and private key. If only > > Not always "key". If this is meant to be an example, prepend with "For example". ok > src/java.base/share/classes/java/security/PEMDecoder.java line 89: > >> 87: * decoder not configured for decryption, an {@link EncryptedPrivateKeyInfo} >> 88: * object is returned. {@code EncryptedPrivateKeyInfo} methods must be used to >> 89: * retrieve the {@link PrivateKey}. > > Do we need this last sentence? "EncryptedPrivateKeyInfo methods must be used to...". maybe not > src/java.base/share/classes/java/security/PEMDecoder.java line 97: > >> 95: * PEMDecoder pd = PEMDecoder.of(); >> 96: * PrivateKey priKey = pd.decode(priKeyPEM, PrivateKey.class); >> 97: * } > > Add examples on `withFactory` and `withDecryption`. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 133: > >> 131: * Returns an instance of {@code PEMDecoder}. >> 132: * >> 133: * @return a new {@code PEMDecoder} instance > > Not always new. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 234: > >> 232: * {@code leadingData}. >> 233: * >> 234: *

If no PEM data is found, an {@code IllegalArgumentException} is > > Duplicated sentence. Or do you mean to say the same exception is thrown if decoding fails? no > src/java.base/share/classes/java/security/PEMDecoder.java line 281: > >> 279: * @param is InputStream containing PEM data >> 280: * @return a {@code DEREncodable} >> 281: * @throws IOException on IO error with the {@code InputStream} > > Since IOE is not purely IO error and contains format errors that are not recoverable. Do you want to say more? ok > src/java.base/share/classes/java/security/PEMDecoder.java line 283: > >> 281: * @throws IOException on IO error with the {@code InputStream} >> 282: * @throws EOFException the end of {@code InputStream} has been >> 283: * unexpectedly reached. > > Not really "unexpected". It looks like every program that tries to read multiple PEM blocks will encounter this. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 285: > >> 283: * unexpectedly reached. >> 284: * @throws IllegalArgumentException on error in decoding or no PEM data >> 285: * found > > "no PEM data found". Isn't that EOFException? ok > src/java.base/share/classes/java/security/PEMDecoder.java line 312: > >> 310: * {@link java.nio.charset.StandardCharsets#UTF_8 UTF-8}. >> 311: * >> 312: *

For all other class parameters, {@code IllegalArgumentException} is > > "For all other class parameters", you mean not `PEMRecord`? There is a paragraph in between (UTF-8 thingy) and users have forgotten what "other" means. paragraph is unnecessary > src/java.base/share/classes/java/security/PEMDecoder.java line 325: > >> 323: * @throws NullPointerException when any input values are null. >> 324: * >> 325: * @see PEMDecoder for how {@code tClass} can be used. > > Since it's a `@see`, let's make the title a little more formal. Maybe add a header (`

`) in the spec. actually I don't think this like is necessary > src/java.base/share/classes/java/security/PEMEncoder.java line 127: > >> 125: >> 126: /** >> 127: * Returns a new instance of {@code PEMEncoder}. > > Not always new. ok > src/java.base/share/classes/java/security/PEMRecord.java line 50: > >> 48: *

During the instantiation of this record, there is no validation >> 49: * for the {@code type} or {@code pem}. {@code leadingData} is not >> 50: * defensively copied. > > Not only instantiation, but the data is also not defensively copied when someone calls `leadingData`. Do we need to mention this as well? ok > src/java.base/share/classes/java/security/PEMRecord.java line 76: > >> 74: * before the PEM header. This value maybe {@code null}. >> 75: * @throws IllegalArgumentException if the {@code type} is incorrectly >> 76: * formatted. > > Is there a place defining what is a correctly formatted `type`? The class definition for `type` given an example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088189751 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088192299 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088202146 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088358703 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088209096 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088209735 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088232122 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088251848 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088281449 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088296864 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088290091 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088299845 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087829601 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087834756 From ascarpino at openjdk.org Wed May 14 08:25:53 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 14 May 2025 08:25:53 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 22:28:48 GMT, Weijun Wang wrote: >> src/java.base/share/classes/java/security/PEMDecoder.java line 464: >> >>> 462: * >>> 463: *

If {@code provider} is {@code null}, a new instance is returned with >>> 464: * the default provider configuration. >> >> IMHO, I think this is working around a bug in the calling code and an NPE should be thrown instead. > > Yes, it's not worth calling `withFactory(null)` to remove preferred provider configuration. We already have `PEMDecoder.of()`. I like null, but I guess I see your point. >> src/java.base/share/classes/java/security/PEMEncoder.java line 62: >> >>> 60: * configured to encrypt the key with that password. Alternatively, a >>> 61: * private key encrypted as an {@code EncryptedKeyInfo} object can be encoded >>> 62: * directly to PEM by passing it to the encode method >> >> s/encode method/`encode` or `encodeToString` methods./ > > Add a period at the end. Do we need to say `of a normal PEMEncoder` since encryption is done elsewhere. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087786189 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087800378 From ascarpino at openjdk.org Wed May 14 08:25:57 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 14 May 2025 08:25:57 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> Message-ID: On Tue, 6 May 2025 20:49:10 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: >> >> - major code review comments update >> - Merge branch 'master' into pem >> - Merge branch 'master' into pem >> - javadoc updates >> - code review comments >> - merge with master >> - better comment and remove commented out code >> - Merge branch 'master' into pem >> - Merge branch 'pem-merge' into pem >> - merge >> - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 > > src/java.base/share/classes/java/security/PEMEncoder.java line 48: > >> 46: /** >> 47: * PEMEncoder is an immutable class for Privacy-Enhanced Mail (PEM) >> 48: * data. PEM is a textual encoding used to store and transfer security > > "An immutable class .. for ... data" sounds like it is the data itself. What about "for encoding data into...". > > The first word `PEMEncoder` should be in ``. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087139518 From ascarpino at openjdk.org Wed May 14 08:25:58 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 14 May 2025 08:25:58 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17] In-Reply-To: References: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com> Message-ID: On Tue, 13 May 2025 02:21:16 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/java/security/PEMEncoder.java line 95: >> >>> 93: * RFC 1421: Privacy Enhancement for Internet Electronic Mail >>> 94: * @spec https://www.rfc-editor.org/info/rfc5958 >>> 95: * RFC 5958: Asymmetric Key Packages >> >> Do we really need to add RFC 5958 here? This class is just doing the PEM encoding, it doesn't implement RFC 5958. > > @wangweij asked for it. If you disagree I can remove it. will be removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2087138859 From ascarpino at openjdk.org Wed May 14 08:26:00 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 14 May 2025 08:26:00 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17] In-Reply-To: References: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com> Message-ID: On Tue, 13 May 2025 07:37:06 GMT, Krushna948 wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments on the 11th > > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 369: > >> 367: PBEKeySpec keySpec = new PBEKeySpec(password); >> 368: SecretKey skey; >> 369: Objects.requireNonNull(key); > > @throws NullPointerException if the key or password are null. > But when password null case looks not handled? password should not allow null. I will fix the code. > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 451: > >> 449: * @throws RuntimeException on an encryption errors. The cause may include >> 450: * IllegalBlockSizeException, BadPaddingException, or InvalidKeyException. >> 451: * @throws NullPointerException if the key or password are null. Also, if > > @throws NullPointerException if the key or password are null. > Here it supposed to be - throws NullPointerException if the key or enckey are null.? Yes, comment is wrong. > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 548: > >> 546: * @throws InvalidKeyException if an error occurs during parsing of the >> 547: * encrypted data or creation of the key object. >> 548: * > > Do we need to specify the RuntimeException cases in this documentation? The exceptions should be specified ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088065544 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088069516 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088100411 From ascarpino at openjdk.org Wed May 14 08:26:01 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 14 May 2025 08:26:01 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17] In-Reply-To: References: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com> Message-ID: On Mon, 12 May 2025 14:35:45 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments on the 11th > > src/java.base/share/conf/security/java.security line 1560: > >> 1558: # withEncryption method. >> 1559: # >> 1560: jdk.epkcs8.defaultAlgorithm=PBEWithHmacSHA256AndAES_128 > > What about naming this `jdk.pem.pbeAlgorithm`? The `withEncryption` method never mentions PKCS#8, so maybe don't need to expose this in the property name. Also having "pem" in the property name makes it more clear what API this property is used for. The security property is not just PEMEncoder/PEMDecoder, it also affects EKPI. So slightly less PEM specific. I'm open to change it if we need to ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088115825 From fguallini at openjdk.org Wed May 14 08:42:06 2025 From: fguallini at openjdk.org (Fernando Guallini) Date: Wed, 14 May 2025 08:42:06 GMT Subject: Integrated: 8249825: Tests sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked with @ignore In-Reply-To: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com> References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com> Message-ID: On Tue, 4 Mar 2025 13:07:37 GMT, Fernando Guallini wrote: > The following tests are marked with @ignore (not running): > > - sun/security/ssl/SSLSocketImpl/SetClientMode.java: it checks that setting the clientMode after the handshake has begun is not permitted, but this was failing intermittently due to a race condition, it was possible that SetClientMode was called before the client socket was updated with handshake isNegotiated = true. The fix is to introduce a latch to sync between client and main threads. Included additional refactoring to ensure test stability. > > - sun/security/ssl/SSLSocketImpl/NonAutoClose.java: This test should only run in TLS <= 1.2, as TLSv1.3 changes the behaviour of close_notify. Included additional refactoring to ensure test stability. > > Executed both tests 10K times, no test flakiness found This pull request has now been integrated. Changeset: 86f39ab5 Author: Fernando Guallini URL: https://git.openjdk.org/jdk/commit/86f39ab5bb58a1d1e720badd7261365398134151 Stats: 391 lines in 2 files changed: 26 ins; 231 del; 134 mod 8249825: Tests sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked with @ignore Reviewed-by: abarashev, rhalade ------------- PR: https://git.openjdk.org/jdk/pull/23898 From weijun at openjdk.org Wed May 14 11:36:16 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 May 2025 11:36:16 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:25:41 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > comments src/java.base/share/classes/java/security/PEMRecord.java line 83: > 81: public PEMRecord(String type, String pem, byte[] leadingData) { > 82: Objects.requireNonNull(type, "\"type\" cannot be null."); > 83: Objects.requireNonNull(type, "\"pem\" cannot be null."); Typo, should check `pem`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088725370 From duke at openjdk.org Wed May 14 11:43:58 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 14 May 2025 11:43:58 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v4] In-Reply-To: <-L1FHPpbVOvHTxMFUPMGIY9g8UFAFmJDgNRkoFONKnI=.ddef5354-e00f-4c2a-80c3-b48325fe51d2@github.com> References: <-L1FHPpbVOvHTxMFUPMGIY9g8UFAFmJDgNRkoFONKnI=.ddef5354-e00f-4c2a-80c3-b48325fe51d2@github.com> Message-ID: On Tue, 13 May 2025 17:53:50 GMT, Sandhya Viswanathan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Restoring copyright notice on ML_KEM.java > > src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 693: > >> 691: // a (short[256]) = c_rarg1 >> 692: // b (short[256]) = c_rarg2 >> 693: // kyberConsts (short[40]) = c_rarg3 > > kyberConsts is not one of the arguments passed in. Fixed. > src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 696: > >> 694: address generate_kyberAddPoly_2_avx512(StubGenerator *stubgen, >> 695: MacroAssembler *_masm) { >> 696: > > The Java code for "implKyberAddPoly(short[] result, short[] a, short[] b)" does BarrettReduction but the intrinsic code here does not. Is that intentional and how is the reduction handled? Actually, the Java version is the one that is too cautious. There is Barrett reduction after at most 4 consecutive uses of mlKemAddPoly(), so doing the reduction in implKyberAddPoly() is not necessary. Thanks for discovering this! > src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 742: > >> 740: // b (short[256]) = c_rarg2 >> 741: // c (short[256]) = c_rarg3 >> 742: // kyberConsts (short[40]) = c_rarg4 > > kyberConsts is not one of the arguments passed in. Fixed. > src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 799: > >> 797: // parsedLength (int) = c_rarg3 >> 798: address generate_kyber12To16_avx512(StubGenerator *stubgen, >> 799: MacroAssembler *_masm) { > > If AVX512_VBMI and AVX512_VBMI2 is available, it looks to me that the loop body of this algorithm can be implemented using more efficient instructions in simple 5 steps: > > Step 1: > Load 0-47, 48-95, 96-143, 144-191 condensed bytes into xmm0, xmm1, xmm2, xmm3 respectively using masked load. > > Step 2: > Use vpermb to arrange xmm0 such that bytes 1, 4, 7, ... are duplicated > xmm0 before b47, b46, ..., b0 where each b is a byte > xmm0 after b47 b46 b46 b45, ......., b5 b4 b4 b3 b2 b1 b1 b0 > Repeat this for xmm1, xmm2, xmm3 > > Step 3: > Use vpshldvw to shift every word (16 bits) in the xmm0 appropriately with variable shift > Shift word 31 by 4, word 30 by 0, ... word 3 by 4, word 2 by 0, word 1 by 4, word 0 by 0 > Repeat this for xmm1, xmm2, xmm3 > > Step 4: > Use vpand to "and" each word element in xmm0 by 0xfff. > Repeat this for xmm1, xmm2, xmm3 > > Step 5: > Store xmm0 into parsed > Store xmm1 into parsed + 64 > Store xmm2 into parsed +128 > Store xmm3 into parsed + 192 > > If you think there is not sufficient time, we could look into it after the merge of this PR as well. Yes, that way we can speed this up a little (well, in itself it might be significant), but with the current intrinsics, the contribution of this function to the overall running time is about 1.5%, so it would not matter that much, while on the other hand not all AVX-512 capable processors have vbmi. So I would rather not do it in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2088738946 PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2088738841 PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2088738704 PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2088738615 From duke at openjdk.org Wed May 14 11:49:11 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 14 May 2025 11:49:11 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v5] In-Reply-To: References: Message-ID: > By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Responding to comments by Sandhya. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24953/files - new: https://git.openjdk.org/jdk/pull/24953/files/215b346f..32571f39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24953&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24953&range=03-04 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24953/head:pull/24953 PR: https://git.openjdk.org/jdk/pull/24953 From weijun at openjdk.org Wed May 14 13:13:23 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 May 2025 13:13:23 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:25:41 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > comments More comments on API. src/java.base/share/classes/java/security/PEMRecord.java line 45: > 43: *

{@code type} and {@code pem} may not be {@code null}. > 44: * {@code leadingData} may be null if no non-PEM data preceded PEM header > 45: * during decoding. {@code leadingData} may be be useful for reading metadata double "be". src/java.base/share/classes/java/security/PEMRecord.java line 119: > 117: > 118: * @param type the PEM type identifier > 119: * @param pem the Base64-encoded data encapsulated by the PEM header and Since internal `pem` is a string, you need to mention the charset of `pem` argument here. Does it make sense to choose another argument name? Like `pemBytes`. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 335: > 333: * > 334: * @param key the {@code PrivateKey} to be encrypted > 335: * @param password the password used during encryption. In the other `encryptKey`, you mentioned password is cloned. Be consistent. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 337: > 335: * @param password the password used during encryption. > 336: * @param algorithm the PBE encryption algorithm. The default algorithm is > 337: * will be used if {@code null}. However, {@code null} is Choose one of "is" and "will be". src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 342: > 340: * encryption. The provider default will be used if > 341: * {@code null}. > 342: * @param provider the {@code Provider} is used for PBE Change "is used" to "to be used" to be consistent with the one above. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 346: > 344: * encryption operations. The default provider list will be > 345: * used if {@code null}. > 346: * @return a {@code EncryptedPrivateKeyInfo} s/a/an/ src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 354: > 352: * IllegalBlockSizeException, BadPaddingException, or InvalidKeyException. > 353: * @throws NullPointerException if the key or password are null. If > 354: * {@code params} is non-null when {@code algorithm} is {@code null}. A lot of names above should be in `{@code}`. Same with the other `encryptKey`s. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 357: > 355: * > 356: * @implNote The encryption uses the algorithm set by > 357: * `jdk.epkcs8.defaultAlgorithm` Security Property Not markdown here, use `{@code}`. Same with the other `encryptKey`s. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 358: > 356: * @implNote The encryption uses the algorithm set by > 357: * `jdk.epkcs8.defaultAlgorithm` Security Property > 358: * and default the {@code AlgorithmParameterSpec} of that provider. You meant "the default"? In fact, since `params` is an argument, you can override the default. Maybe just remove "and...". src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 464: > 462: @PreviewFeature(feature = PreviewFeature.Feature.PEM_API) > 463: public static EncryptedPrivateKeyInfo encryptKey(PrivateKey key, Key encKey, > 464: String algorithm, AlgorithmParameterSpec params, Provider provider, How useful is this method? Do users really want to create a PBE key instead of providing the password directly. Note that with Valerie's recent fix, there is no more PKCS11 PBE `SecretKeyFactory`s. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 521: > 519: > 520: /** > 521: * Returns a {@code PrivateKey} from the encrypted data in this instance. Follow existing `get` methods, "Extract the enclosed PrivateKey object from the encrypted data and return it." Same with the other `getKey` method. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 523: > 521: * Returns a {@code PrivateKey} from the encrypted data in this instance. > 522: * > 523: * @param password this array is cloned and used for PBE decryption. Be consistent with other ones, "the password used in the PBE decryption. This array is cloned before being used." src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 547: > 545: * using the given provider. > 546: * > 547: * @param decryptKey this is the decryption key and cannot be {@code null}. Remove "this is". src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 548: > 546: * > 547: * @param decryptKey this is the decryption key and cannot be {@code null}. > 548: * @param provider the {@code Provider} is used for Cipher decryption and Remove "is". ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2839835945 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088728318 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088731294 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088752934 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088745307 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088746291 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088746740 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088750354 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088738810 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088740381 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088757629 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088903324 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088899916 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088905109 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088905519 From weijun at openjdk.org Wed May 14 13:13:23 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 May 2025 13:13:23 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 11:36:46 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments > > src/java.base/share/classes/java/security/PEMRecord.java line 119: > >> 117: >> 118: * @param type the PEM type identifier >> 119: * @param pem the Base64-encoded data encapsulated by the PEM header and > > Since internal `pem` is a string, you need to mention the charset of `pem` argument here. Does it make sense to choose another argument name? Like `pemBytes`. Also, how useful is this method? I'd rather reserve the constructor to provide binary data (before Base64). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088733615 From weijun at openjdk.org Wed May 14 13:34:19 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 May 2025 13:34:19 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:25:41 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > comments Last API comments. src/java.base/share/classes/java/security/PEMDecoder.java line 61: > 59: * > 60: * > 61: *

>If the PEM does not have a cryptographic object representation, Extra `>`. src/java.base/share/classes/java/security/PEMDecoder.java line 86: > 84: * encrypted private key PEM data using the given password. > 85: * Configuring an instance for decryption does not prevent decoding with > 86: * unencrypted PEM. Any encrypted PEM that does not use the configured password You mean when decryption fails? "Does not use the configured password" sounds strange to me, src/java.base/share/classes/java/security/PEMDecoder.java line 87: > 85: * Configuring an instance for decryption does not prevent decoding with > 86: * unencrypted PEM. Any encrypted PEM that does not use the configured password > 87: * will throw a {@link RuntimeException}. When encrypted PEM is used with a Add "an" before "encrypted PEM". src/java.base/share/classes/java/security/PEMDecoder.java line 100: > 98: * > 99: *

Here is an example that decryption with a factory provider: > 100: * specified password: "with a factory provider and a specified password". src/java.base/share/classes/java/security/PEMDecoder.java line 237: > 235: * such as a {@code PrivateKey}, if the PEM type is supported. > 236: * Any non-PEM data preceding the PEM header is ignored by the decoder. > 237: * If no cryptographic object is found, a {@link PEMRecord} will be Just say "otherwise". Same for other methods. src/java.base/share/classes/java/security/PEMDecoder.java line 290: > 288: * @throws EOFException at the end of the {@code InputStream}. > 289: * @throws IllegalArgumentException on error in decoding > 290: * @throws NullPointerException when {@code is} is null. Some still have periods at the end when the description is not a complete sentence. Please go through the whole file. src/java.base/share/classes/java/security/PEMDecoder.java line 456: > 454: > 455: /** > 456: * Returns a copy of this {@code PEMDecoder} instance that uses Why use "a copy"? Do you mean the password is kept? ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2840153891 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088919847 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088931083 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088929195 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088932273 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088935412 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088952541 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2088957451 From ihse at openjdk.org Wed May 14 14:28:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 14:28:10 GMT Subject: RFR: 8356977: UTF-8 cleanups Message-ID: I found a few other places in the code that can be cleaned up after the conversion to UTF-8. ------------- Commit messages: - Replace uncessary unicode characters with ASCII in instructions, and fix typo - Seems like typos in the comments - Fix unicode sequences in comments (previously missed) Changes: https://git.openjdk.org/jdk/pull/25228/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356977 Stats: 21 lines in 16 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/25228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228 PR: https://git.openjdk.org/jdk/pull/25228 From ihse at openjdk.org Wed May 14 15:16:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 15:16:18 GMT Subject: RFR: 8356980: Better handling of non-breaking space Message-ID: Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences. I have checked: * U+00A0 NO-BREAK SPACE (NBSP) * U+202F NARROW NO-BREAK SPACE (NNBSP) * U+2007 FIGURE SPACE * U+2060 WORD JOINER In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences. ------------- Commit messages: - Use sequences for valid nbsp usage - Remove mistaken nbsp Changes: https://git.openjdk.org/jdk/pull/25234/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25234&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356980 Stats: 36 lines in 8 files changed: 0 ins; 2 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/25234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25234/head:pull/25234 PR: https://git.openjdk.org/jdk/pull/25234 From weijun at openjdk.org Wed May 14 15:41:16 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 May 2025 15:41:16 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:25:41 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > comments The code at https://github.com/openjdk/jdk/blob/ddf04617887dc389cd7667e820da7ac91eea9e8c/src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java#L449 is old. It does not cover the public key case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17543#issuecomment-2880701666 From mullan at openjdk.org Wed May 14 15:55:13 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 14 May 2025 15:55:13 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:25:41 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > comments src/java.base/share/classes/java/security/DEREncodable.java line 41: > 39: * These APIs or their subclasses typically provide methods to convert > 40: * their instances to and from byte arrays in the Distinguished > 41: * Encoding Rules (DER) format (ITU X.690). You can probably leave out the reference to X.690 - DER is used in many of our APIs, and typically the DER format for that specific API will be specified by an RFC like 5280. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089263532 From sviswanathan at openjdk.org Wed May 14 16:03:52 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 14 May 2025 16:03:52 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v4] In-Reply-To: References: <-L1FHPpbVOvHTxMFUPMGIY9g8UFAFmJDgNRkoFONKnI=.ddef5354-e00f-4c2a-80c3-b48325fe51d2@github.com> Message-ID: On Wed, 14 May 2025 11:41:30 GMT, Ferenc Rakoczi wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 696: >> >>> 694: address generate_kyberAddPoly_2_avx512(StubGenerator *stubgen, >>> 695: MacroAssembler *_masm) { >>> 696: >> >> The Java code for "implKyberAddPoly(short[] result, short[] a, short[] b)" does BarrettReduction but the intrinsic code here does not. Is that intentional and how is the reduction handled? > > Actually, the Java version is the one that is too cautious. There is Barrett reduction after at most 4 consecutive uses of mlKemAddPoly(), so doing the reduction in implKyberAddPoly() is not necessary. Thanks for discovering this! Thanks. I have another question, is there a reason that the Java versions of AddPoly (both for 2 and 3 input) return 1, whereas the corresponding intrinsics return 0? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2089278218 From duke at openjdk.org Wed May 14 16:30:54 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 14 May 2025 16:30:54 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v4] In-Reply-To: References: <-L1FHPpbVOvHTxMFUPMGIY9g8UFAFmJDgNRkoFONKnI=.ddef5354-e00f-4c2a-80c3-b48325fe51d2@github.com> Message-ID: On Wed, 14 May 2025 16:00:55 GMT, Sandhya Viswanathan wrote: >> Actually, the Java version is the one that is too cautious. There is Barrett reduction after at most 4 consecutive uses of mlKemAddPoly(), so doing the reduction in implKyberAddPoly() is not necessary. Thanks for discovering this! > > Thanks. I have another question, is there a reason that the Java versions of AddPoly (both for 2 and 3 input) return 1, whereas the corresponding intrinsics return 0? I use that for debugging. E.g. it is fairly easy to change the Java code to call both the intrinsic and Java version and compare the results. I don't see any harm in leaving that in the production version, since it is always ignored. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2089322079 From prr at openjdk.org Wed May 14 17:01:55 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 14 May 2025 17:01:55 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: Message-ID: On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie wrote: > Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences. > > I have checked: > * U+00A0 NO-BREAK SPACE (NBSP) > * U+202F NARROW NO-BREAK SPACE (NNBSP) > * U+2007 FIGURE SPACE > * U+2060 WORD JOINER > > In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences. src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39: > 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte : > 38: > 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0: So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991 But I think you know that .. since you commented on the PR The fix was done by @justin-curtis-lu and reviewed by @naotoj so I think I'd like to get their opinion on this ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089371921 From weijun at openjdk.org Wed May 14 17:17:15 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 May 2025 17:17:15 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: <0VNiKklf43Z2oaIyatRgBMeaWjty1ve1i3L-dIC31MU=.9748a744-964a-4626-b2bd-d336a0cbd5b7@github.com> On Wed, 14 May 2025 08:25:41 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > comments src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 561: > 559: public PrivateKey getKey(Key decryptKey, Provider provider) > 560: throws GeneralSecurityException { > 561: Objects.requireNonNull("decryptKey cannot be null."); Add `decryptKey` into `requireNonNull` call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089392816 From jlu at openjdk.org Wed May 14 17:21:54 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 14 May 2025 17:21:54 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: Message-ID: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> On Wed, 14 May 2025 16:59:23 GMT, Phil Race wrote: >> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences. >> >> I have checked: >> * U+00A0 NO-BREAK SPACE (NBSP) >> * U+202F NARROW NO-BREAK SPACE (NNBSP) >> * U+2007 FIGURE SPACE >> * U+2060 WORD JOINER >> >> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences. > > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39: > >> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte : >> 38: >> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0: > > So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991 > But I think you know that .. since you commented on the PR > > The fix was done by @justin-curtis-lu and reviewed by > @naotoj so I think I'd like to get their opinion on this For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089399946 From weijun at openjdk.org Wed May 14 17:26:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 14 May 2025 17:26:52 GMT Subject: RFR: 8347608: Optimize Java implementation of ML-KEM In-Reply-To: <6iw4o72iY3dxyq3RoqAekbps7PRooru3W6Fn2mu4NKk=.a13667bc-454b-4cb3-a06e-5c7b137d3c6d@github.com> References: <6iw4o72iY3dxyq3RoqAekbps7PRooru3W6Fn2mu4NKk=.a13667bc-454b-4cb3-a06e-5c7b137d3c6d@github.com> Message-ID: On Fri, 9 May 2025 15:37:44 GMT, Ben Perez wrote: > Added custom multi array allocation function to improve performance Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25151#pullrequestreview-2840966660 From naoto at openjdk.org Wed May 14 17:36:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 May 2025 17:36:51 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Wed, 14 May 2025 17:18:35 GMT, Justin Lu wrote: >> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39: >> >>> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte : >>> 38: >>> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0: >> >> So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991 >> But I think you know that .. since you commented on the PR >> >> The fix was done by @justin-curtis-lu and reviewed by >> @naotoj so I think I'd like to get their opinion on this > > For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.) I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089424644 From abarashev at openjdk.org Wed May 14 18:16:13 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 14 May 2025 18:16:13 GMT Subject: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v4] In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> Message-ID: > When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3 > > X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Make the test run on TLSv1.3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25016/files - new: https://git.openjdk.org/jdk/pull/25016/files/5c137c14..451e1efd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=02-03 Stats: 25 lines in 2 files changed: 5 ins; 7 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/25016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016 PR: https://git.openjdk.org/jdk/pull/25016 From djelinski at openjdk.org Wed May 14 19:19:54 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 14 May 2025 19:19:54 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: References: Message-ID: <9N6b56GTLQ7GUHe8elAgEG_tHnlBaKQCzRYxjEOojrk=.619b4617-2e40-40a4-8478-6053d1bbaf25@github.com> On Wed, 14 May 2025 04:03:44 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Merged with changes for JDK-8353578 src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 329: > 327: */ > 328: > 329: SSLSessionImpl(HandshakeContext hc, ByteBuffer buf) throws IOException { this constructor is used for session resumption using deserialized stateless session tickets. AFAICT the resumed session uses a new set of exporter secrets (exporterMasterSecret is overwritten during processing of the Finished message, not sure about the randoms). Does it make any sense to store the original exporter secrets in the stateless ticket? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089580932 From bperez at openjdk.org Wed May 14 19:42:05 2025 From: bperez at openjdk.org (Ben Perez) Date: Wed, 14 May 2025 19:42:05 GMT Subject: Integrated: 8347608: Optimize Java implementation of ML-KEM In-Reply-To: <6iw4o72iY3dxyq3RoqAekbps7PRooru3W6Fn2mu4NKk=.a13667bc-454b-4cb3-a06e-5c7b137d3c6d@github.com> References: <6iw4o72iY3dxyq3RoqAekbps7PRooru3W6Fn2mu4NKk=.a13667bc-454b-4cb3-a06e-5c7b137d3c6d@github.com> Message-ID: <-uVBTTtUk8TQe-awVOp1-huIsZdYgWqjipLfesHxrdQ=.1667c6d0-e5f5-489b-8155-06ed4390b0f6@github.com> On Fri, 9 May 2025 15:37:44 GMT, Ben Perez wrote: > Added custom multi array allocation function to improve performance This pull request has now been integrated. Changeset: ecabea6c Author: Ben Perez URL: https://git.openjdk.org/jdk/commit/ecabea6cd315eaf08571ef61ff267318140d147b Stats: 20 lines in 1 file changed: 18 ins; 0 del; 2 mod 8347608: Optimize Java implementation of ML-KEM Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/25151 From mullan at openjdk.org Wed May 14 20:09:14 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 14 May 2025 20:09:14 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:25:41 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > comments A few remaining very minor comments. This is looking really good now. src/java.base/share/classes/java/security/PEMDecoder.java line 271: > 269: * on the {@code InputStream} to decode additional PEM data. > 270: * The {@code InputStream} read pointer will remain at the end of > 271: * the PEM footer unless an IOException occurs. Put code font around IOException. src/java.base/share/classes/java/security/PEMEncoder.java line 129: > 127: > 128: /** > 129: * Returns a instance of {@code PEMEncoder}. s/a/an/ src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 398: > 396: * used. > 397: * > 398: * @param key The {@code PrivateKey} to be encrypted s/The/the/ src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 544: > 542: > 543: /** > 544: * Returns a {@code PrivateKey} from the encrypted data in this instance. Remove '.' ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2840745733 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089565932 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089272910 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089639029 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089633768 From wetmore at openjdk.org Wed May 14 21:44:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 14 May 2025 21:44:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: <9N6b56GTLQ7GUHe8elAgEG_tHnlBaKQCzRYxjEOojrk=.619b4617-2e40-40a4-8478-6053d1bbaf25@github.com> References: <9N6b56GTLQ7GUHe8elAgEG_tHnlBaKQCzRYxjEOojrk=.619b4617-2e40-40a4-8478-6053d1bbaf25@github.com> Message-ID: <_U-BO0RzhhrJ7k3B4H_-ittme7TIi1fj9zRIhE8g9aw=.8208d4f5-d8b6-49c6-8a01-4e526678f49d@github.com> On Wed, 14 May 2025 19:17:15 GMT, Daniel Jeli?ski wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Merged with changes for JDK-8353578 > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 329: > >> 327: */ >> 328: >> 329: SSLSessionImpl(HandshakeContext hc, ByteBuffer buf) throws IOException { > > this constructor is used for session resumption using deserialized stateless session tickets. AFAICT the resumed session uses a new set of exporter secrets (exporterMasterSecret is overwritten during processing of the Finished message, not sure about the randoms). Does it make any sense to store the original exporter secrets in the stateless ticket? Good catch, I am 99% convinced neither is not needed. I'll be removing these changes. For TLS 1.3, the exporter is recalculated at the end of the handshake for the new session. For 1-1.2, the Session is indeed pulled from the serialized form, but the new session's Hello Random values are used with the existing MasterSecret to load the `TlsKeyMaterialParameterSpec` and obtain all of the keying material. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089796579 From wetmore at openjdk.org Wed May 14 23:57:56 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 14 May 2025 23:57:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 12:16:37 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed one review comment > > src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 189: > >> 187: * {@code UnsupportedOperationException}. >> 188: * Classes derived from ExtendedSSLSession must implement >> 189: * this method. > > That statement is too strong, even though `getStatusResponses` has that text, unfortunately. For one, existing provider implementations of this class are binary compatible if they upgrade to JDK 25 because they don't have to implement this method right away since it has a default implementation. Ok, removed in both places ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089918402 From wetmore at openjdk.org Thu May 15 00:00:58 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 15 May 2025 00:00:58 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: <_U-BO0RzhhrJ7k3B4H_-ittme7TIi1fj9zRIhE8g9aw=.8208d4f5-d8b6-49c6-8a01-4e526678f49d@github.com> References: <9N6b56GTLQ7GUHe8elAgEG_tHnlBaKQCzRYxjEOojrk=.619b4617-2e40-40a4-8478-6053d1bbaf25@github.com> <_U-BO0RzhhrJ7k3B4H_-ittme7TIi1fj9zRIhE8g9aw=.8208d4f5-d8b6-49c6-8a01-4e526678f49d@github.com> Message-ID: On Wed, 14 May 2025 21:42:06 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 329: >> >>> 327: */ >>> 328: >>> 329: SSLSessionImpl(HandshakeContext hc, ByteBuffer buf) throws IOException { >> >> this constructor is used for session resumption using deserialized stateless session tickets. AFAICT the resumed session uses a new set of exporter secrets (exporterMasterSecret is overwritten during processing of the Finished message, not sure about the randoms). Does it make any sense to store the original exporter secrets in the stateless ticket? > > Good catch, I am 99% convinced neither is not needed. I'll be removing these changes. > > For TLS 1.3, the exporter is recalculated at the end of the handshake for the new session. > > For 1-1.2, the Session is indeed pulled from the serialized form, but the new session's Hello Random values are used with the existing MasterSecret to load the `TlsKeyMaterialParameterSpec` and obtain all of the keying material. Update, will push soon. Had to move the random capture locations, as they need to capture the new client/server randoms instead of when the PMS is calculated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089922075 From wetmore at openjdk.org Thu May 15 00:29:54 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 15 May 2025 00:29:54 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v13] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 21:44:21 GMT, Artur Barashev wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Missed one review comment >> - More codereview comments >> - Merge branch 'master' into JDK-8341346 >> - Adjustments made for JDK-8350830 >> - Merge branch 'master' into JDK-8341346 >> - Rework to avoid PKCS11 data extraction problems, and enhanced input verification and unit testing >> - More Codereview comments >> - Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation) >> - Add in the SharedSecrets SecretKeySpec clearing mechanism >> - ... and 6 more: https://git.openjdk.org/jdk/compare/d1543429...87ad9ead > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1583: > >> 1581: // Calculations are primarily based on protocol version. >> 1582: switch (protocolVersion) { >> 1583: case TLS13: // HKDF-based > > Should we also handle `TLS13Plus` versions here? I like the enumeration as it's possible there could be new behavior with TLS14Plus, but this might save a few minutes down the road, so I've changed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089938492 From wetmore at openjdk.org Thu May 15 00:29:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 15 May 2025 00:29:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 13:23:16 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed one review comment > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1598: > >> 1596: // L length of output keying material in octets >> 1597: // (<= 255*HashLen) >> 1598: if (length >= (255 * cipherSuite.hashAlg.hashLength )) { > > The opposite of `<=` is `>`. Good catch. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089940408 From wetmore at openjdk.org Thu May 15 00:29:56 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 15 May 2025 00:29:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 20:13:36 GMT, Artur Barashev wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Merged with changes for JDK-8353578 > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1727: > >> 1725: >> 1726: // context length must fit in 2 unsigned bytes. >> 1727: if ((context != null) && context.length >= 65536) { > > Nit: `context.length > 0xFFFF` would be more readable IMO Sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089941085 From sviswanathan at openjdk.org Thu May 15 00:38:54 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 15 May 2025 00:38:54 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v5] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 11:49:11 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Responding to comments by Sandhya. Another minor comment. Rest of the PR looks good to me. src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 893: > 891: // > 892: // coeffs (short[256]) = c_rarg0 > 893: // kyberConsts (short[40]) = c_rarg1 kyberConsts is not an input parameter to implKyberBarrettReduce. ------------- PR Review: https://git.openjdk.org/jdk/pull/24953#pullrequestreview-2840763895 PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2089284332 From abarashev at openjdk.org Thu May 15 00:40:53 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 15 May 2025 00:40:53 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v13] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 00:23:56 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1583: >> >>> 1581: // Calculations are primarily based on protocol version. >>> 1582: switch (protocolVersion) { >>> 1583: case TLS13: // HKDF-based >> >> Should we also handle `TLS13Plus` versions here? > > I like the enumeration as it's possible there could be new behavior with TLS14Plus, but this might save a few minutes down the road, so I've changed it. Yes, the general approach in SSL code is to use `if (protocolVersion.useTLS13PlusSpec()) {} else {}` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2089949997 From ascarpino at openjdk.org Thu May 15 01:31:14 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 01:31:14 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 15:52:34 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments > > src/java.base/share/classes/java/security/DEREncodable.java line 41: > >> 39: * These APIs or their subclasses typically provide methods to convert >> 40: * their instances to and from byte arrays in the Distinguished >> 41: * Encoding Rules (DER) format (ITU X.690). > > You can probably leave out the reference to X.690 - DER is used in many of our APIs, and typically the DER format for that specific API will be specified by an RFC like 5280. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 271: > >> 269: * on the {@code InputStream} to decode additional PEM data. >> 270: * The {@code InputStream} read pointer will remain at the end of >> 271: * the PEM footer unless an IOException occurs. > > Put code font around IOException. ok > src/java.base/share/classes/java/security/PEMEncoder.java line 129: > >> 127: >> 128: /** >> 129: * Returns a instance of {@code PEMEncoder}. > > s/a/an/ ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 398: > >> 396: * used. >> 397: * >> 398: * @param key The {@code PrivateKey} to be encrypted > > s/The/the/ ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 544: > >> 542: >> 543: /** >> 544: * Returns a {@code PrivateKey} from the encrypted data in this instance. > > Remove '.' address by other change ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089691659 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089695970 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089698078 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089699784 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089702862 From ascarpino at openjdk.org Thu May 15 01:31:21 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 01:31:21 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 13:16:17 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments > > src/java.base/share/classes/java/security/PEMDecoder.java line 61: > >> 59: * >> 60: * >> 61: *

>If the PEM does not have a cryptographic object representation, > > Extra `>`. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 86: > >> 84: * encrypted private key PEM data using the given password. >> 85: * Configuring an instance for decryption does not prevent decoding with >> 86: * unencrypted PEM. Any encrypted PEM that does not use the configured password > > You mean when decryption fails? "Does not use the configured password" sounds strange to me, I can tweak it > src/java.base/share/classes/java/security/PEMDecoder.java line 87: > >> 85: * Configuring an instance for decryption does not prevent decoding with >> 86: * unencrypted PEM. Any encrypted PEM that does not use the configured password >> 87: * will throw a {@link RuntimeException}. When encrypted PEM is used with a > > Add "an" before "encrypted PEM". ok > src/java.base/share/classes/java/security/PEMDecoder.java line 100: > >> 98: * >> 99: *

Here is an example that decryption with a factory provider: >> 100: * specified password: > > "with a factory provider and a specified password". ok > src/java.base/share/classes/java/security/PEMDecoder.java line 237: > >> 235: * such as a {@code PrivateKey}, if the PEM type is supported. >> 236: * Any non-PEM data preceding the PEM header is ignored by the decoder. >> 237: * If no cryptographic object is found, a {@link PEMRecord} will be > > Just say "otherwise". Same for other methods. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 290: > >> 288: * @throws EOFException at the end of the {@code InputStream}. >> 289: * @throws IllegalArgumentException on error in decoding >> 290: * @throws NullPointerException when {@code is} is null. > > Some still have periods at the end when the description is not a complete sentence. Please go through the whole file. ok > src/java.base/share/classes/java/security/PEMDecoder.java line 456: > >> 454: >> 455: /** >> 456: * Returns a copy of this {@code PEMDecoder} instance that uses > > Why use "a copy"? Do you mean the password is kept? If this instance was configured with decryption, this method will return a new instance configured with decryption and the factory provider. I use "a copy" so the user knows they are adding a new configuration and this instance is staying the same > src/java.base/share/classes/java/security/PEMRecord.java line 45: > >> 43: *

{@code type} and {@code pem} may not be {@code null}. >> 44: * {@code leadingData} may be null if no non-PEM data preceded PEM header >> 45: * during decoding. {@code leadingData} may be be useful for reading metadata > > double "be". ok > src/java.base/share/classes/java/security/PEMRecord.java line 83: > >> 81: public PEMRecord(String type, String pem, byte[] leadingData) { >> 82: Objects.requireNonNull(type, "\"type\" cannot be null."); >> 83: Objects.requireNonNull(type, "\"pem\" cannot be null."); > > Typo, should check `pem`. ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 335: > >> 333: * >> 334: * @param key the {@code PrivateKey} to be encrypted >> 335: * @param password the password used during encryption. > > In the other `encryptKey`, you mentioned password is cloned. Be consistent. ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 337: > >> 335: * @param password the password used during encryption. >> 336: * @param algorithm the PBE encryption algorithm. The default algorithm is >> 337: * will be used if {@code null}. However, {@code null} is > > Choose one of "is" and "will be". ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 342: > >> 340: * encryption. The provider default will be used if >> 341: * {@code null}. >> 342: * @param provider the {@code Provider} is used for PBE > > Change "is used" to "to be used" to be consistent with the one above. ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 346: > >> 344: * encryption operations. The default provider list will be >> 345: * used if {@code null}. >> 346: * @return a {@code EncryptedPrivateKeyInfo} > > s/a/an/ ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 354: > >> 352: * IllegalBlockSizeException, BadPaddingException, or InvalidKeyException. >> 353: * @throws NullPointerException if the key or password are null. If >> 354: * {@code params} is non-null when {@code algorithm} is {@code null}. > > A lot of names above should be in `{@code}`. Same with the other `encryptKey`s. ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 357: > >> 355: * >> 356: * @implNote The encryption uses the algorithm set by >> 357: * `jdk.epkcs8.defaultAlgorithm` Security Property > > Not markdown here, use `{@code}`. Same with the other `encryptKey`s. yes > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 358: > >> 356: * @implNote The encryption uses the algorithm set by >> 357: * `jdk.epkcs8.defaultAlgorithm` Security Property >> 358: * and default the {@code AlgorithmParameterSpec} of that provider. > > You meant "the default"? In fact, since `params` is an argument, you can override the default. Maybe just remove "and...". This one looks like an older version that what I've used in other places. I'll replace this. > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 464: > >> 462: @PreviewFeature(feature = PreviewFeature.Feature.PEM_API) >> 463: public static EncryptedPrivateKeyInfo encryptKey(PrivateKey key, Key encKey, >> 464: String algorithm, AlgorithmParameterSpec params, Provider provider, > > How useful is this method? Do users really want to create a PBE key instead of providing the password directly. Note that with Valerie's recent fix, there is no more PKCS11 PBE `SecretKeyFactory`s. This is the advanced users method allows everything to be set. It allows the `encKey` to be generated separately from the `provider` that does the encryption. I think this is an important method so we don't need additional methods to cover the many parameters. For example, two `Provider` options for KeyFactory and Cipher. > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 521: > >> 519: >> 520: /** >> 521: * Returns a {@code PrivateKey} from the encrypted data in this instance. > > Follow existing `get` methods, "Extract the enclosed PrivateKey object from the encrypted data and return it." Same with the other `getKey` method. ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 523: > >> 521: * Returns a {@code PrivateKey} from the encrypted data in this instance. >> 522: * >> 523: * @param password this array is cloned and used for PBE decryption. > > Be consistent with other ones, "the password used in the PBE decryption. This array is cloned before being used." ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 547: > >> 545: * using the given provider. >> 546: * >> 547: * @param decryptKey this is the decryption key and cannot be {@code null}. > > Remove "this is". ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 548: > >> 546: * >> 547: * @param decryptKey this is the decryption key and cannot be {@code null}. >> 548: * @param provider the {@code Provider} is used for Cipher decryption and > > Remove "is". ok > src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 561: > >> 559: public PrivateKey getKey(Key decryptKey, Provider provider) >> 560: throws GeneralSecurityException { >> 561: Objects.requireNonNull("decryptKey cannot be null."); > > Add `decryptKey` into `requireNonNull` call. wow.. yeah ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089694492 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089385166 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089385510 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089387259 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089408885 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089409481 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089275573 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089270437 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089270150 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089423787 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089432207 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089445666 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089477795 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089478251 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089478503 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089482436 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089491575 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089680989 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089686768 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089688705 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089689794 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089703680 From ascarpino at openjdk.org Thu May 15 01:31:22 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 01:31:22 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v14] In-Reply-To: References: <3lV5iDSUFhmawsDpSLOaTjgkizT-6NKVKAbrR7vuD6w=.e616ce3b-9f68-4893-9924-cd3f83394c8e@github.com> Message-ID: <7wuzRXeZAM3k1LYdG40qVqsYlqEbNTnQljgd1cf4azY=.9acbe216-b1d7-4ab3-89cb-ad81de07e741@github.com> On Sun, 27 Apr 2025 19:10:31 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/java/security/PEMDecoder.java line 213: >> >>> 211: Objects.requireNonNull(str); >>> 212: try { >>> 213: return decode(new ByteArrayInputStream(str.getBytes())); >> >> `str.getBytes()` will return a byte array encoded in the default charset, which these days is likely to be UTF-8, but might be something completely bizarre. You probably want `str.getBytes(StandardCharsets.ISO_8859_1)`. >> >> It could be worth running your unit tests in several different locales in order to catch similar issues. > > What about the other decode methods that read from InputStream? I thought it would be inconsistent to read `decode(String)` as a ISO 8859-1, but `decode(InputStream)` as a different charset. I believe this has been addressed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089788429 From ascarpino at openjdk.org Thu May 15 01:31:22 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 01:31:22 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> <1NPCoy9RfTm6v7k1Nu3bjU-ntKn78gU3_mfDH7tFntg=.bf0a52ed-4f5d-4ab5-858b-dd1fbb635fbe@github.com> Message-ID: On Thu, 8 May 2025 21:32:13 GMT, Weijun Wang wrote: >> There is an inconsistency with PEMRecord here. These methods should not allow leadingData if it is not available elsewhere. I will redo that. leadingData can be reserved for the decode methods that take a class. >> >> I tried not to mention the pointer position. My opinion is these methods should not have to describe the InputStream functionality. I already state it returns a value after it finds PEM and I think one can figure this out. > > See https://github.com/openjdk/jdk/blob/002679ac9fe4de8150b7dd4c9aeb44eeef1257d6/src/java.base/share/classes/java/security/cert/CertificateFactory.java#L338-L347 IO focuses more on the read position now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089792916 From ascarpino at openjdk.org Thu May 15 01:31:27 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 01:31:27 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v18] In-Reply-To: <3Xf8vEzR4xxXSCY3kq13KNKAoSxSY76jMtSgEMjGJMw=.67af6542-6b14-441a-b757-7ac7c76b5a14@github.com> References: <3Xf8vEzR4xxXSCY3kq13KNKAoSxSY76jMtSgEMjGJMw=.67af6542-6b14-441a-b757-7ac7c76b5a14@github.com> Message-ID: On Tue, 13 May 2025 21:46:26 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments on the 11th > > src/java.base/share/classes/java/security/PEMRecord.java line 48: > >> 46: * >> 47: *

During the instantiation of this record, there is no validation for the >> 48: * {@code type} or {@code pem}. > > The ctors throw `IllegalArgumentException` though. I think you need to be more specific about what type of validation you mean here. Much more detailed now > src/java.base/share/classes/java/security/PEMRecord.java line 87: > >> 85: if (type == null && pem != null || type != null && pem == null) { >> 86: throw new IllegalArgumentException("\"type\" and \"pem\" must be" + >> 87: " both null or non-null"); > > If type and pem can be both null, and leadingData is also null (which is allowed per spec) then that should not be an error? > > This check may need to be updated now that non-PEM data is an error. code has been changed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089975958 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089976358 From ascarpino at openjdk.org Thu May 15 01:31:27 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 01:31:27 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v15] In-Reply-To: <3b0GceQv3oN1AhtY8RT5YRve_5tfw5GHGV0uWywRFB0=.30147e51-e3c7-4bf8-b23d-f4dbe4fb980b@github.com> References: <8tX0X_ZTRCrPVNUof2uGW78EsWAftwS6HD3Z1g_KijI=.7458ec70-f42a-4f9b-9428-779df1b13277@github.com> <3b0GceQv3oN1AhtY8RT5YRve_5tfw5GHGV0uWywRFB0=.30147e51-e3c7-4bf8-b23d-f4dbe4fb980b@github.com> Message-ID: On Mon, 5 May 2025 13:12:11 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: >> >> - major code review comments update >> - Merge branch 'master' into pem >> - Merge branch 'master' into pem >> - javadoc updates >> - code review comments >> - merge with master >> - better comment and remove commented out code >> - Merge branch 'master' into pem >> - Merge branch 'pem-merge' into pem >> - merge >> - ... and 56 more: https://git.openjdk.org/jdk/compare/e2ae50d8...0c540327 > > src/java.base/share/classes/java/security/PEMRecord.java line 46: > >> 44: *

{@code PEMRecord} may have a null {@code type} and {@code pem} when >> 45: * {@code PEMDecoder.decode()} methods encounter only non-PEM data and has >> 46: * reached the end of the stream. If there is PEM data, {@code type} and > > Is this use case important? It seems unusual to call this a DEREncodable if it only contains non-PEM data. I think it might be better to simply ignore trailing non-PEM data at the end of a stream which is not attached to any subsequent PEM objects. This has been address ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089791059 From ascarpino at openjdk.org Thu May 15 01:31:27 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 01:31:27 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17] In-Reply-To: References: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com> Message-ID: On Mon, 12 May 2025 18:49:56 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments on the 11th > > src/java.base/share/classes/java/security/PEMRecord.java line 101: > >> 99: // including lowercase. The onus is on the caller. >> 100: if (type != null && (type.startsWith("-") || type.contains("BEGIN") || >> 101: type.contains("END") || type.endsWith("-"))) { > > How about checking for `startsWith("BEGIN?")` and `startsWith("END?")`. Maybe some day there will be a type named "ENDPOINT" or "BACKEND NAME". Well I can't change the calls to `startsWith()` because there are more likely dashes. It's just a non-fool proof check that someone didn't put the whole header or footer in the String. If there is a conflict, we will have time to address it as it will involve the RFC process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089994122 From ascarpino at openjdk.org Thu May 15 01:31:28 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 01:31:28 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 11:38:15 GMT, Weijun Wang wrote: >> src/java.base/share/classes/java/security/PEMRecord.java line 119: >> >>> 117: >>> 118: * @param type the PEM type identifier >>> 119: * @param pem the Base64-encoded data encapsulated by the PEM header and >> >> Since internal `pem` is a string, you need to mention the charset of `pem` argument here. Does it make sense to choose another argument name? Like `pemBytes`. > > Also, how useful is this method? I'd rather reserve the constructor to provide binary data (before Base64). I can remove this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089420535 From ascarpino at openjdk.org Thu May 15 01:31:28 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 01:31:28 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v17] In-Reply-To: <9CXNHFwKxLcTFdoS6EkHvVw8R384pj3QmM6K8RFNsy8=.85aafda0-d9f0-4778-a36b-ae628edf15f2@github.com> References: <2Wpd3msrb6TXY4J1Fu2tYIszXws0qDfrURthu7-crro=.5a89a2b7-dc85-4e56-b36d-65f5e53bfd4b@github.com> <9CXNHFwKxLcTFdoS6EkHvVw8R384pj3QmM6K8RFNsy8=.85aafda0-d9f0-4778-a36b-ae628edf15f2@github.com> Message-ID: On Mon, 12 May 2025 20:36:40 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments on the 11th > > src/java.base/share/classes/java/security/PEMRecord.java line 129: > >> 127: * >> 128: * @param type the type identifier in the PEM header and footer, or {@code null} if there is no PEM data. >> 129: * @param pem the data between the PEM header and footer. > > I thought the bytes were the DER encoded data. Wouldn't that be useful, if you were trying to PEM encode a certificate with extra leading data, for example? I tried to have something similar, but because of `record` it didn't flow right. I would prefer a more clear way to say your providing DER vs PEM.. something like `fromDER()`. But the more options that were allowed it became less it's intent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2089846646 From wetmore at openjdk.org Thu May 15 02:03:02 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 15 May 2025 02:03:02 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 17:13:03 GMT, Artur Barashev wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed one review comment > > test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 62: > >> 60: * produced. >> 61: */ >> 62: public class ExportKeyingMaterialTests extends SSLContextTemplate { > > What's the reason we don't use `SSLEngineTemplate` here? There's a bug in `SSLEngine`/`SSLSocket` that prevents configuration callbacks from working as originally imagined. I hate working around it. The subclass constructor now calls `super()`, which then calls back to the `configure*()` methods, but you can't pass any parameters. One of these days this should be fixed. I find it easier to just copy `SSLEngineTemplate.java` instead of `extends`. I've worked around it to remind myself this needs to be fixed someday. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2090057949 From serb at openjdk.org Thu May 15 02:27:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 15 May 2025 02:27:50 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Wed, 14 May 2025 17:34:45 GMT, Naoto Sato wrote: >> For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.) > > I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them. maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090083320 From naoto at openjdk.org Thu May 15 03:20:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 May 2025 03:20:51 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Thu, 15 May 2025 02:25:30 GMT, Sergey Bylokhov wrote: >> I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them. > > maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090140891 From ascarpino at openjdk.org Thu May 15 03:37:57 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 15 May 2025 03:37:57 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v21] In-Reply-To: References: Message-ID: > Hi all, > > I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. > > Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). > > Thanks > > Tony Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: - merge in JEP 513 - Merge branch 'master' into pem - comments - comments - comments - comments on the 11th - comments on the 11th - comments - toString update - non-sealed Better X509 KeyPair parsing - ... and 66 more: https://git.openjdk.org/jdk/compare/5e50a584...8bf36d6b ------------- Changes: https://git.openjdk.org/jdk/pull/17543/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=20 Stats: 3617 lines in 40 files changed: 3226 ins; 166 del; 225 mod Patch: https://git.openjdk.org/jdk/pull/17543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543 PR: https://git.openjdk.org/jdk/pull/17543 From wetmore at openjdk.org Thu May 15 04:24:52 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 15 May 2025 04:24:52 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 13:25:21 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed one review comment > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1650: > >> 1648: emptyHash = md.digest(); >> 1649: } catch (NoSuchAlgorithmException nsae) { >> 1650: throw new RuntimeException( > > We usually throw a `ProviderException` here, when some weird configuration removes a basic hash algorithm. I can do a `ProviderException` if you like, but our JSSE code is all over the place. Sometimes it's a `RuntimeException`, other times we wrap it into into a `SSLException`, and sometimes we directly do a `fatal()`. I'd say we do `RuntimeException` a little more often than `ProviderException`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2090205280 From wetmore at openjdk.org Thu May 15 04:28:52 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 15 May 2025 04:28:52 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: Message-ID: <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com> On Tue, 13 May 2025 13:37:18 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed one review comment > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1682: > >> 1680: // ...now the final expand. >> 1681: return (deriveKey ? >> 1682: hkdf.deriveKey("TlsExporterKeyingMaterial", > > Using a registered algorithm will make this method work, but I'm not sure if the resulting key can be used further. Do you know any typical use cases for the EKM? >From a previous comment: IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be. They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed. This is just doing a quick read of some of the IANA definitions which link to some of the known use cases: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2090208168 From ihse at openjdk.org Thu May 15 09:19:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 15 May 2025 09:19:53 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Thu, 15 May 2025 03:18:30 GMT, Naoto Sato wrote: >> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? > > Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not. > So, this exactly reverses what was done in the fix for JDK-8301991 No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090692617 From ihse at openjdk.org Thu May 15 09:19:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 15 May 2025 09:19:53 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: On Thu, 15 May 2025 09:16:10 GMT, Magnus Ihse Bursie wrote: >> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not. > >> So, this exactly reverses what was done in the fix for JDK-8301991 > > No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. > > This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. > > Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence. > maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090695445 From lkorinth at openjdk.org Thu May 15 09:20:03 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 15 May 2025 09:20:03 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases: > 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 > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* After an offline discussion, we agreed to wait a bit with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218 From lkorinth at openjdk.org Thu May 15 09:20:03 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 15 May 2025 09:20:03 GMT Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases: > 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 > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25122 From pminborg at openjdk.org Thu May 15 10:01:57 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 15 May 2025 10:01:57 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation So, I think we are ready to go with the latest version. ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24982#pullrequestreview-2843068669 From rgiulietti at openjdk.org Thu May 15 12:35:51 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 May 2025 12:35:51 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> Message-ID: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com> On Thu, 15 May 2025 09:17:42 GMT, Magnus Ihse Bursie wrote: >>> So, this exactly reverses what was done in the fix for JDK-8301991 >> >> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. >> >> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. >> >> Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence. > >> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? > > That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case. FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France): - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark. - U+00A0 (No-Break Space NBSP) preceding colon. Similar conventions are used in other French speaking countries. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2091068610 From abarashev at openjdk.org Thu May 15 12:53:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 15 May 2025 12:53:54 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: References: Message-ID: <3vsETo6M0H58jDD60zKWaR7Kl5D6ii96tbnVIHToOwc=.97022a1d-59bd-47b1-91fa-7519913b7f85@github.com> On Thu, 15 May 2025 00:27:31 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1727: >> >>> 1725: >>> 1726: // context length must fit in 2 unsigned bytes. >>> 1727: if ((context != null) && context.length >= 65536) { >> >> Nit: `context.length > 0xFFFF` would be more readable IMO > > Sure. Also, the parentheses are not needed around `context != null` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091102162 From duke at openjdk.org Thu May 15 13:33:42 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 15 May 2025 13:33:42 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v6] In-Reply-To: References: Message-ID: > By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Response to review comment + loading constants with broadcast op. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24953/files - new: https://git.openjdk.org/jdk/pull/24953/files/32571f39..e4f3264e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24953&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24953&range=04-05 Stats: 107 lines in 1 file changed: 39 ins; 39 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/24953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24953/head:pull/24953 PR: https://git.openjdk.org/jdk/pull/24953 From duke at openjdk.org Thu May 15 13:48:56 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 15 May 2025 13:48:56 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v5] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 16:04:31 GMT, Sandhya Viswanathan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Responding to comments by Sandhya. > > src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 893: > >> 891: // >> 892: // coeffs (short[256]) = c_rarg0 >> 893: // kyberConsts (short[40]) = c_rarg1 > > kyberConsts is not an input parameter to implKyberBarrettReduce. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2091216578 From vyazici at openjdk.org Thu May 15 14:01:57 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 15 May 2025 14:01:57 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: <6NeDdpJHPkF7E3zioEtxyeVC1fX4FT2w38VbpJg5BUA=.6c1d39fd-a07b-49b0-8303-36f65aec17f3@github.com> On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation Green `tier1,2` results are attached to ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2883918329 From duke at openjdk.org Thu May 15 14:01:58 2025 From: duke at openjdk.org (duke) Date: Thu, 15 May 2025 14:01:58 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation @vy Your change (at version 0e06ce1d028ce2fef5705e59d9245fcaa93abcd9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2883921694 From duke at openjdk.org Thu May 15 14:06:53 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Thu, 15 May 2025 14:06:53 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v5] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 00:36:26 GMT, Sandhya Viswanathan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Responding to comments by Sandhya. > > Another minor comment. Rest of the PR looks good to me. @sviswa7, thanks a lot for the review! If you agree with my changes to load the constants using broadcasting instructions instead of full AVX register loads, would you be so kind as to approve the PR and sponsor my integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24953#issuecomment-2883937966 From liach at openjdk.org Thu May 15 14:57:05 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 15 May 2025 14:57:05 GMT Subject: RFR: 8353197: Document preconditions for JavaLangAccess methods [v7] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:42:15 GMT, Volkan Yazici wrote: >> Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into jla > - Improve `uncheckedGetBytesNoRepl` docs > - Apply suggestions from code review > > Co-authored-by: Roger Riggs > - Prefixed `JavaLangAccess::stringConcat1` with `unchecked` > - Fix `HexDigits` copyright year > - Fix copyright years > - Prefix touched methods with `unchecked` > - Fix typo in pre-existing JavaDoc > - Improve `JavaLangAccess` documentation Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24982#issuecomment-2884130126 From vyazici at openjdk.org Thu May 15 14:57:05 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 15 May 2025 14:57:05 GMT Subject: Integrated: 8353197: Document preconditions for JavaLangAccess methods In-Reply-To: References: Message-ID: <83yYC2PGBDztvGXa1rA5Jrt561lI1FiaEBk3EaauueM=.a287f882-4ec9-47b0-9e08-67b29982dbb8@github.com> On Thu, 1 May 2025 05:33:29 GMT, Volkan Yazici wrote: > Document preconditions on certain `JavaLangAccess` methods that use operations either unsafe and/or without range checks. This pull request has now been integrated. Changeset: 8fcfddb2 Author: Volkan Yazici Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/8fcfddb2d202cdb61941efdb3fec5807fee98c33 Stats: 124 lines in 22 files changed: 23 ins; 3 del; 98 mod 8353197: Document preconditions for JavaLangAccess methods Reviewed-by: pminborg, liach ------------- PR: https://git.openjdk.org/jdk/pull/24982 From weijun at openjdk.org Thu May 15 15:13:19 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 15 May 2025 15:13:19 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v21] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 03:37:57 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: > > - merge in JEP 513 > - Merge branch 'master' into pem > - comments > - comments > - comments > - comments on the 11th > - comments on the 11th > - comments > - toString update > - non-sealed > Better X509 KeyPair parsing > - ... and 66 more: https://git.openjdk.org/jdk/compare/5e50a584...8bf36d6b src/java.base/share/classes/java/security/PEMDecoder.java line 55: > 53: * type and implements {@link DEREncodable}. > 54: * > 55: * The following lists the supported PEM types and the {@code DEREncodable} The list seems too early before introducing the decode-with-class methods. src/java.base/share/classes/java/security/PEMDecoder.java line 64: > 62: *

  • PRIVATE KEY : {@code PrivateKey}
    • > 63: *
  • PRIVATE KEY : {@code PKCS8EncodedKeySpec} (Only supported when passed as a {@code Class} parameter)
    • > 64: *
  • PRIVATE KEY : {@code KeyPair} (if the encoding also contains a public key)
    • In a later paragraph you talk about reading `PublicKey` from a `PRIVATE KEY` if it is 2.0 and contains the public key. How about merging that info into this list? src/java.base/share/classes/java/security/PEMDecoder.java line 101: > 99: * Configuring an instance for decryption does not prevent decoding with > 100: * unencrypted PEM. Any encrypted PEM that fails decryption > 101: * will throw a {@link RuntimeException}. When an encrypted PEM is used with a Let's be more clear here: `When an encrypted private key PEM is...`. src/java.base/share/classes/java/security/PEMDecoder.java line 119: > 117: * withFactory(provider); > 118: * byte[] pemData = pe.encode(privKey); > 119: * } The example is still encoder. src/java.base/share/classes/java/security/PEMDecoder.java line 121: > 119: * } > 120: * > 121: * @implNote An implementation may support other PEM types and DEREncodables. Have you considered moving the whole decoding list above into this `@implNote`? Same question with the encoder side. src/java.base/share/classes/java/security/PEMDecoder.java line 290: > 288: * the read position in the stream may become inconsistent. > 289: * It is recommended to perform no further decoding operations > 290: * on the {@code InputStream}. I prefer the words in the previous commit. It was more positive -- the read position is here when there is no IOE. src/java.base/share/classes/java/security/PEMEncoder.java line 91: > 89: *
  • {@code KeyPair} : PRIVATE KEY
    • > 90: *
  • {@code EncryptedPrivateKeyInfo} : ENCRYPTED PRIVATE KEY
    • > 91: *
  • {@code PrivateKey} (if configured with encryption): ENCRYPTED PRIVATE KEY
    • Move the two `PrivateKey` lines together. Maybe clearly add `if not configured with encryption` to the other one. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 349: > 347: * @throws IllegalArgumentException on initialization errors based on the > 348: * arguments passed to the method > 349: * @throws RuntimeException on an encryption errors Remove `an` or change to `error`. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 350: > 348: * arguments passed to the method > 349: * @throws RuntimeException on an encryption errors > 350: * @throws NullPointerException if the key or password are null. If `null` in `{@code}`. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 401: > 399: * @throws IllegalArgumentException on initialization errors based on the > 400: * arguments passed to the method > 401: * @throws RuntimeException on an encryption errors Remove `an` or change to `error`. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 402: > 400: * arguments passed to the method > 401: * @throws RuntimeException on an encryption errors > 402: * @throws NullPointerException when the {code key} or {@code password} You forgot the `@` after `{`. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 438: > 436: * @throws IllegalArgumentException on initialization errors based on the > 437: * arguments passed to the method > 438: * @throws RuntimeException on an encryption errors Remove `an` or change to `error`. src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 440: > 438: * @throws RuntimeException on an encryption errors > 439: * @throws NullPointerException if the {@code key} or {@code encKey} are > 440: * null. If {@code params} is non-null, {@code algorithm} cannot be Put `null` in `{@code}`. src/java.base/share/classes/sun/security/util/Pem.java line 63: > 61: DEFAULT_ALGO = (algo == null || algo.isBlank()) ? > 62: "PBEWithHmacSHA256AndAES_128" : algo; > 63: pbePattern = Pattern.compile("^PBEWith.*And.*"); Is the regex check in case-insensitive mode? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091394789 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091399606 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091410536 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091411461 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091413464 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091419078 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091387820 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091268965 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091270129 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091271961 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091273449 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091275819 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091276867 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091282800 From wetmore at openjdk.org Thu May 15 16:56:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 15 May 2025 16:56:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: <3vsETo6M0H58jDD60zKWaR7Kl5D6ii96tbnVIHToOwc=.97022a1d-59bd-47b1-91fa-7519913b7f85@github.com> References: <3vsETo6M0H58jDD60zKWaR7Kl5D6ii96tbnVIHToOwc=.97022a1d-59bd-47b1-91fa-7519913b7f85@github.com> Message-ID: On Thu, 15 May 2025 12:51:16 GMT, Artur Barashev wrote: >> Sure. > > Also, the parentheses are not needed around `context != null` If there's one things to know about me, it's my liberal use of parens. I want my code to match my intent. I plan to update the "missing" parens. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091610748 From abarashev at openjdk.org Thu May 15 17:33:56 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 15 May 2025 17:33:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 01:59:50 GMT, Bradford Wetmore wrote: >> test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 62: >> >>> 60: * produced. >>> 61: */ >>> 62: public class ExportKeyingMaterialTests extends SSLContextTemplate { >> >> What's the reason we don't use `SSLEngineTemplate` here? > > There's a bug in `SSLEngine`/`SSLSocket` that prevents configuration callbacks from working as originally imagined. I hate working around it. > > The subclass constructor now calls `super()`, which then calls back to the `configure*()` methods, but you can't pass any parameters. One of these days this should be fixed. > > I find it easier to just copy `SSLEngineTemplate.java` instead of `extends`. > > I've worked around it to remind myself this needs to be fixed someday. Yes, I had this problem myself. Actually it's specific to `SSLEngineTemplate` because `SSLSocketTemplate` constructor doesn't call any configure methods. `Flexible Constructor Bodies` feature should address this issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091667466 From naoto at openjdk.org Thu May 15 18:32:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 May 2025 18:32:53 GMT Subject: RFR: 8356977: UTF-8 cleanups In-Reply-To: References: Message-ID: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com> On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie wrote: > I found a few other places in the code that can be cleaned up after the conversion to UTF-8. test/jdk/sun/text/resources/LocaleDataTest.java line 106: > 104: * FormatData/fr_FR/MonthNames/0=janvier > 105: * FormatData/fr_FR/MonthNames/1=f?vrier > 106: * LocaleNames/fr_FR/US=?tats-Unis This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2091757029 From mullan at openjdk.org Thu May 15 19:31:54 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 May 2025 19:31:54 GMT Subject: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3] In-Reply-To: References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com> <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com> <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com> Message-ID: On Tue, 13 May 2025 14:01:10 GMT, Artur Barashev wrote: > > It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code). > > @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it to be disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this. > > @seanjmullan What do you think? Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2884859280 From weijun at openjdk.org Thu May 15 19:43:54 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 15 May 2025 19:43:54 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com> References: <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com> Message-ID: On Thu, 15 May 2025 04:26:30 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1682: >> >>> 1680: // ...now the final expand. >>> 1681: return (deriveKey ? >>> 1682: hkdf.deriveKey("TlsExporterKeyingMaterial", >> >> Using a registered algorithm will make this method work, but I'm not sure if the resulting key can be used further. Do you know any typical use cases for the EKM? > > From a previous comment: > > IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be. They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed. This is just doing a quick read of some of the IANA definitions which link to some of the known use cases: > > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels Personally, I would like to give user the chance to specify the algorithm themselves. A "TlsExporterKeyingMaterial" key will not be accepted by an AES cipher. If you are not ready for this, I'd rather only provide the `exportKeyingMaterialData` method now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091851924 From mullan at openjdk.org Thu May 15 20:45:55 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 May 2025 20:45:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 04:03:44 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Merged with changes for JDK-8353578 src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 169: > 167: > 168: /** > 169: * Generate Exported Keying Material (EKM) calculated according to the Suggest saying "Generates". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091930435 From mullan at openjdk.org Thu May 15 20:55:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 May 2025 20:55:53 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 04:03:44 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Merged with changes for JDK-8353578 test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 320: > 318: log("Data: Equal inputs test passed"); > 319: > 320: // Different labels, now use exportKeyMaterialData() for coverage Should update the comment with new method name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2091943734 From valeriep at openjdk.org Thu May 15 23:52:53 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 15 May 2025 23:52:53 GMT Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 20:05:10 GMT, Weijun Wang wrote: >> Finalize the KDF API. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > new algorithms in SunJCE Updates look good. Thanks~ ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2845203782 From sviswanathan at openjdk.org Fri May 16 00:32:51 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 16 May 2025 00:32:51 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v5] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 00:36:26 GMT, Sandhya Viswanathan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Responding to comments by Sandhya. > > Another minor comment. Rest of the PR looks good to me. > @sviswa7, thanks a lot for the review! If you agree with my changes to load the constants using broadcasting instructions instead of full AVX register loads, would you be so kind as to approve the PR and sponsor my integration? The broadcast instructions look good. I only have one query on montMul above that I have wondering about. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24953#issuecomment-2885339535 From sviswanathan at openjdk.org Fri May 16 00:32:53 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 16 May 2025 00:32:53 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v6] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 13:33:42 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Response to review comment + loading constants with broadcast op. src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 250: > 248: static void montmul(int outputRegs[], int inputRegs1[], int inputRegs2[], > 249: int scratchRegs1[], int scratchRegs2[], MacroAssembler *_masm) { > 250: for (int i = 0; i < 4; i++) { In the intrinsic for montMul we are treating as if MONT_R_BITS is 16 and MONT_Q_INV_MOD_R is 0xF301 whereas in the Java code MONT_R_BITS is 20 and MONT_Q_INT_MOD_R is 0x8F301. Are these equivalent? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2092137164 From wetmore at openjdk.org Fri May 16 01:16:13 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 May 2025 01:16:13 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v15] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 20:42:39 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Merged with changes for JDK-8353578 > > src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 169: > >> 167: >> 168: /** >> 169: * Generate Exported Keying Material (EKM) calculated according to the > > Suggest saying "Generates". Done. > test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 320: > >> 318: log("Data: Equal inputs test passed"); >> 319: >> 320: // Different labels, now use exportKeyMaterialData() for coverage > > Should update the comment with new method name. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2092166964 PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2092167873 From wetmore at openjdk.org Fri May 16 01:28:56 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 May 2025 01:28:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v16] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'master' into JDK-8341346 - Minor Codereview comments. - Codereview comments: updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs - Codereview comments: updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs - Codereview: removed serialization of of exporter Secret/randoms, and adjusted TLSv1-1.2 randoms capture locations since mastersecret could be reused - Merged with changes for JDK-8353578 - Merge - Merge branch 'master' into JDK-8341346 - Missed one review comment - More codereview comments - ... and 13 more: https://git.openjdk.org/jdk/compare/f6b0f016...e93e38e4 ------------- Changes: https://git.openjdk.org/jdk/pull/24976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=15 Stats: 947 lines in 6 files changed: 933 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From ascarpino at openjdk.org Fri May 16 08:34:46 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 16 May 2025 08:34:46 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v22] In-Reply-To: References: Message-ID: <2k0yLU-Vny8aqXR1Y81pQKoKUOV8wh7BIa08drUg9CQ=.b1567dde-086e-4999-b27b-a9c76a0b8936@github.com> > Hi all, > > I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. > > Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision: - comments - comments - fix EKS error after JEP 513 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17543/files - new: https://git.openjdk.org/jdk/pull/17543/files/8bf36d6b..397d0cbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=20-21 Stats: 112 lines in 11 files changed: 34 ins; 45 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/17543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543 PR: https://git.openjdk.org/jdk/pull/17543 From dfuchs at openjdk.org Fri May 16 10:45:06 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 16 May 2025 10:45:06 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v5] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:39:53 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 422 commits: > > - merge latest changes from master branch > - Undo whitespace change > - Remove unnecessary import > - Merge remote-tracking branch 'origin/master' into http3 > - Fix test license > - Remove leftover file (test was moved to parent directory) > - Remove unnecessary import > - Update throws clauses > - Merge remote-tracking branch 'origin/master' into http3 > - 8354275: Add HTTP/3 tests to `EmptyAuthenticate` > - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c I spotted some inacuracy in QuicEndpoint. I will take care of these. src/java.net.http/share/classes/jdk/internal/net/http/Http3ClientImpl.java line 158: > 156: quicIdleMillis = h3Millis + 60000; // a minute more than h3 timeout > 157: } > 158: transportParameters.setIntParameter(max_idle_timeout, quicIdleMillis); I understand we don't want the QUIC Idle Timeout to kill idle connections before the HTTP/3 idle timeout has expired. But on the other hand, we should not let the HTTP/3 idle timeout set a quic idle timeout that is less than the default quic timeout. We should take into account the value of the default quic timeout that we use in QuicConnectionImpl here. src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 737: > 735: // channel, and a single selector thread, so we can do > 736: // the reading directly in the selector thread and offload > 737: // the parsing (the readLoop) to the executor. This comment is outdated. We actually stop reading from the channel when the amount of data buffered exceeds a high watermark threshold. src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 822: > 820: if (this.buffered.get() >= MAX_BUFFERED_HIGH) { > 821: pauseReading(); > 822: readLoopScheduler.runOrSchedule(executor); This line should not be needed: we should already have kicked the read loop at line 797. ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-2846207620 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092779174 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092786818 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2092805633 From michaelm at openjdk.org Fri May 16 11:42:08 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 16 May 2025 11:42:08 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v10] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - reduced number of new categories - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Review update - review update - Merge branch 'master' into 8348986-exceptions - update to minimise code changes - Merge branch 'master' into 8348986-exceptions - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0 ------------- Changes: https://git.openjdk.org/jdk/pull/23929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=09 Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From weijun at openjdk.org Fri May 16 12:28:06 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 May 2025 12:28:06 GMT Subject: Integrated: 8353888: Implement JEP 510: Key Derivation Function API In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 18:14:53 GMT, Weijun Wang wrote: > Finalize the KDF API. This pull request has now been integrated. Changeset: 079fccfa Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/079fccfa9a03b890e698c52c689dea0f19f8fbee Stats: 209 lines in 18 files changed: 160 ins; 29 del; 20 mod 8353888: Implement JEP 510: Key Derivation Function API Reviewed-by: valeriep, mullan, liach ------------- PR: https://git.openjdk.org/jdk/pull/24520 From abarashev at openjdk.org Fri May 16 14:18:04 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 16 May 2025 14:18:04 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v5] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:39:53 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 422 commits: > > - merge latest changes from master branch > - Undo whitespace change > - Remove unnecessary import > - Merge remote-tracking branch 'origin/master' into http3 > - Fix test license > - Remove leftover file (test was moved to parent directory) > - Remove unnecessary import > - Update throws clauses > - Merge remote-tracking branch 'origin/master' into http3 > - 8354275: Add HTTP/3 tests to `EmptyAuthenticate` > - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c @seanjmullan @djelinski We should probably re-evaluate the priority of `TLS Certificate Compression` JEP: https://bugs.openjdk.org/browse/JDK-8281710 Certificate compression seems to be [particularly important for QUIC performance](https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study), the work has been started already in #7599 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-2886849963 From mullan at openjdk.org Fri May 16 16:52:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 16 May 2025 16:52:53 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com> Message-ID: On Thu, 15 May 2025 19:41:16 GMT, Weijun Wang wrote: >> From a previous comment: >> >> IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be. They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed. This is just doing a quick read of some of the IANA definitions which link to some of the known use cases: >> >> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels > > Personally, I would like to give user the chance to specify the algorithm themselves. A "TlsExporterKeyingMaterial" key will not be accepted by an AES cipher. If you are not ready for this, I'd rather only provide the `exportKeyingMaterialData` method now. How about adding a `String alg` parameter to `exportKeyingMaterialKey` like in the `KDF.deriveKey` API? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093387401 From wetmore at openjdk.org Fri May 16 17:19:54 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 May 2025 17:19:54 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com> Message-ID: On Fri, 16 May 2025 16:50:22 GMT, Sean Mullan wrote: >> Personally, I would like to give user the chance to specify the algorithm themselves. A "TlsExporterKeyingMaterial" key will not be accepted by an AES cipher. If you are not ready for this, I'd rather only provide the `exportKeyingMaterialData` method now. > > How about adding a `String alg` parameter to `exportKeyingMaterialKey` like in the `KDF.deriveKey` API? As discussed with @seanjmullan / @wangweij , that is the direction I'll try. It's not perfect, but a definite step in the right direction. Thanks for the idea. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093423153 From weijun at openjdk.org Fri May 16 19:59:26 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 May 2025 19:59:26 GMT Subject: RFR: 8357062: Update Public Suffix List to 823beb1 Message-ID: This is a routine update to synchronize with the [Mozilla Public Suffix List](https://github.com/publicsuffix/list) for JDK 25, matching commit 823beb1 from 2025-05-12. The test has been updated to reflect corresponding changes. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/25273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357062 Stats: 3563 lines in 5 files changed: 1500 ins; 1442 del; 621 mod Patch: https://git.openjdk.org/jdk/pull/25273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25273/head:pull/25273 PR: https://git.openjdk.org/jdk/pull/25273 From wetmore at openjdk.org Fri May 16 21:34:52 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 May 2025 21:34:52 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v10] In-Reply-To: <0aTy62Fv0rHWbxxCZb_coUAIyenl0f0EMXnJHwzAj7M=.d0652548-7e5e-490f-b3c2-e660bc7ff4b9@github.com> References: <4zp69eooclrebCzt4w_Co8KvAth4EEgbBSPaJP01Gr8=.f054a240-5e64-4c7b-b050-c7934ce00404@github.com> <3tAuzjsCrqDcSi1mdrcdVDEnssuhzgibL4LNDxYUhBo=.979cf9e5-103c-45d0-8b13-153f03354ba8@github.com> <0aTy62Fv0rHWbxxCZb_coUAIyenl0f0EMXnJHwzAj7M=.d0652548-7e5e-490f-b3c2-e660bc7ff4b9@github.com> Message-ID: On Tue, 13 May 2025 13:07:18 GMT, Weijun Wang wrote: >> It seems like it should be an exception, whatever you decide to do. The caller is asking for the keying material data, and the provider cannot fulfill that request, so I think explaining why it could not be done would be best represented in an exception. > > +1 for UOE. It's not that we got a key and found it un-extractable. It's that we asked for data but were refused. I have updated to return a `UOE`. I'm a little concerned that `UOE` will be returned for both a non-overriden `exportKeyingMaterial*` method, and if there is a problem with the derivation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093696922 From wetmore at openjdk.org Fri May 16 21:34:53 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 May 2025 21:34:53 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 04:22:42 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1650: >> >>> 1648: emptyHash = md.digest(); >>> 1649: } catch (NoSuchAlgorithmException nsae) { >>> 1650: throw new RuntimeException( >> >> We usually throw a `ProviderException` here, when some weird configuration removes a basic hash algorithm. > > I can do a `ProviderException` if you like, but our JSSE code is all over the place. Sometimes it's a `RuntimeException`, other times we wrap it into into a `SSLException`, and sometimes we directly do a `fatal()`. I'd say we do `RuntimeException` a little more often than `ProviderException`. Updated to to `ProviderException` since the point does fit the description of the class better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093697971 From wetmore at openjdk.org Fri May 16 21:34:53 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 May 2025 21:34:53 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v12] In-Reply-To: References: <2SX8AUrGNZyZwiWF_dcB8Bn006PzvVmx1S1vCBbAyOk=.a9f6dfbf-ab00-4f63-a232-c33c67a8091e@github.com> Message-ID: On Fri, 16 May 2025 17:17:04 GMT, Bradford Wetmore wrote: >> How about adding a `String alg` parameter to `exportKeyingMaterialKey` like in the `KDF.deriveKey` API? > > As discussed with @seanjmullan / @wangweij , that is the direction I'll try. It's not perfect, but a definite step in the right direction. Thanks for the idea. Check the latest version, available after my build/test run. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093698471 From wetmore at openjdk.org Fri May 16 21:34:54 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 May 2025 21:34:54 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7] In-Reply-To: References: Message-ID: <0Ax5kSm0HiAI-OAXzbT4AuQGxIelKTGcZLshW0hC3Sk=.32e7ca68-a6ea-41cc-93c7-d526140c0522@github.com> On Thu, 8 May 2025 06:03:03 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1694: >> >>> 1692: >>> 1693: // ...now the final expand. >>> 1694: SecretKey key = hkdf.deriveKey(label, >> >> PKCS #11 is picky about key algorithm names and I'm not sure if `label` is always accepted. The KDF API has the algorithm in the method arguments so it's left to user to specify one. I'm not sure how the export keying material will be used. If it is used in encryption, the algorithm may need to be something like "AES". > > IIUC, the exported keying material can be used for any purpose or algorithm, so we really can't make an good educated guess what it might be. They could be Keys (Ciphers), byte array/value challenges, or even just data that will be signed. This is just doing a quick read of some of the IANA definitions which link to some of the known use cases: > > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels > > Thus the type needs to be something generic. The label sounded good initially, but there is no specific prohibition against non-null/empty label in the TLS Exporters, but KDF prohibits null/empty labels. > > Maybe a label like "ExportKeyingMaterial"? I have adjusted the API to take an `algName` for the `SecretKey`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093695778 From wetmore at openjdk.org Fri May 16 21:34:56 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 May 2025 21:34:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v7] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 16:21:23 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated to use the upcoming KDF (still in preview) + bits of JDK-8353578 for compilation) > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1808: > >> 1806: String label, byte[] context, int length) throws SSLKeyException { >> 1807: byte[] bytes = >> 1808: exportKeyingMaterialKey(label, context, length).getEncoded(); > > In PKCS #11, calling `deriveKey(...).getEncoded()` is not equivalent to `deriveData()`. It's quite likely that `deriveKey` returns an un-extractable key, but `deriveData` using the exact same input returns the keying material. Adjusted for the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2093695000 From wetmore at openjdk.org Fri May 16 21:50:12 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 16 May 2025 21:50:12 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v17] In-Reply-To: References: Message-ID: <1KpbYmAy2y-Dciswnm9jZhYIG7ITQy7mQD-2x6jm1dw=.f4560916-9395-40c2-95cf-14cfedff0e24@github.com> > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into JDK-8341346 - Updated API to include SecretKey type, and a couple minor codereview comments - Merge branch 'master' into JDK-8341346 - Minor Codereview comments. - Codereview comments: updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs - Codereview comments: updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs - Codereview: removed serialization of of exporter Secret/randoms, and adjusted TLSv1-1.2 randoms capture locations since mastersecret could be reused - Merged with changes for JDK-8353578 - Merge - Merge branch 'master' into JDK-8341346 - ... and 15 more: https://git.openjdk.org/jdk/compare/10258dc5...0f08ff2c ------------- Changes: https://git.openjdk.org/jdk/pull/24976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=16 Stats: 1038 lines in 9 files changed: 1020 ins; 2 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From weijun at openjdk.org Fri May 16 21:58:56 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 May 2025 21:58:56 GMT Subject: RFR: 8349151: Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test [v4] In-Reply-To: <5ZmMOpXoDcEZoB1o8Vsaj8ji-daZtT2lu36CO1dMhWM=.198199d6-086f-43d7-946b-5f8e87233c42@github.com> References: <5ZmMOpXoDcEZoB1o8Vsaj8ji-daZtT2lu36CO1dMhWM=.198199d6-086f-43d7-946b-5f8e87233c42@github.com> Message-ID: On Fri, 9 May 2025 10:31:19 GMT, Mikhail Yankelevich wrote: >> Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test > > Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - further cleanup > - Merge branch 'master' into JDK-8349151 > - Rajan's comments > - cleanup > - JDK-8349151: Refactor test/java/security//cert/CertificateFactory/slowstream.sh to java test Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23394#pullrequestreview-2847680393 From duke at openjdk.org Fri May 16 21:58:56 2025 From: duke at openjdk.org (duke) Date: Fri, 16 May 2025 21:58:56 GMT Subject: RFR: 8349151: Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test [v4] In-Reply-To: <5ZmMOpXoDcEZoB1o8Vsaj8ji-daZtT2lu36CO1dMhWM=.198199d6-086f-43d7-946b-5f8e87233c42@github.com> References: <5ZmMOpXoDcEZoB1o8Vsaj8ji-daZtT2lu36CO1dMhWM=.198199d6-086f-43d7-946b-5f8e87233c42@github.com> Message-ID: On Fri, 9 May 2025 10:31:19 GMT, Mikhail Yankelevich wrote: >> Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test > > Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - further cleanup > - Merge branch 'master' into JDK-8349151 > - Rajan's comments > - cleanup > - JDK-8349151: Refactor test/java/security//cert/CertificateFactory/slowstream.sh to java test @myankelev Your change (at version 763b07c865cb28bc9633852c61911432a7418e91) is now ready to be sponsored by a Committer. @myankelev Your change (at version 763b07c865cb28bc9633852c61911432a7418e91) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23394#issuecomment-2887741431 PR Comment: https://git.openjdk.org/jdk/pull/23394#issuecomment-2887741965 From wetmore at openjdk.org Sat May 17 00:03:10 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 17 May 2025 00:03:10 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Updated copyright dates. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/0f08ff2c..638985b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=16-17 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From sebastian.stenzel at gmail.com Mon May 19 10:10:50 2025 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Mon, 19 May 2025 12:10:50 +0200 Subject: Implementing Destroyable Message-ID: <1F903CEA-1572-484E-915F-5CAD55CD4730@gmail.com> Hi all, I noticed that most classes implementing javax.security.auth.Destroyable do not actually overwrite it. After discussing this topic with Christian Stein last week, I decided to add some implementations. First, I?d like to start with trivial cases with keys encapsulating byte[], as done with symmetric keys or Edwards curves. Later, I might move on to other PrivateKeys, that have some BigInteger that can only be mutated via reflection - doing so is probably debatable. Before starting, I?d like to get a better understanding of whether there is a reason why destroy() isn?t used. Instead, I found uses of alternative ways of (eventually) destroying secrets, such as * via jdk.internal.access.SharedSecrets.getJavaSecuritySpecAccess().clearEncodedKeySpec(keySpec); * via jdk.internal.ref.CleanerFactory.cleaner().register(?) Neither exposes a way to let the API consumer erase key data at a deterministic point in time. I am fully aware this doesn?t reliably prohibit memory dumps from containing the keys. Nevertheless I believe such control is desirable as a best effort attempt to keep keys short-lived when possible. Think of ephemeral key pairs for single-shot ECIES, for example. I hope you can either shed some light on the current state or give me the green light for a PR. Best regards, Sebastian From sebastian.stenzel at gmail.com Mon May 19 10:21:34 2025 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Mon, 19 May 2025 12:21:34 +0200 Subject: JEP 510: HKDFParameterSpec.expandOnly(byte[] prk) Message-ID: Hi, I?m using the HKDF extract and expand steps separately for this step [1] in HPKE. In this case I need to pass a byte[] prk to expandOnly(?), however the API only accepts a SecretKey, forcing me to wrap the bytes just for them to be unwrapped by the expand operation again. Probably this has already been discussed, so please feel free to point me to any existing rationale. Otherwise, is it too late to ask you to add a `expandOnly(byte[] prk)` function? Cheers, Sebastian [1] https://www.rfc-editor.org/rfc/rfc9180#section-4-10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.org Mon May 19 11:09:00 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 19 May 2025 11:09:00 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v10] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 11:42:08 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - update to minimise code changes > - Merge branch 'master' into 8348986-exceptions > - ... and 16 more: https://git.openjdk.org/jdk/compare/64a858c7...3b7861b0 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 78: > 76: * controlled. Consider using a unique value for the > 77: * SecurityProperties.includedInExceptions(String value) mechanism > 78: * Current values defined are "socket", "jar", "userInfo" If I am not mistaken the "socket" info is no longer here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2095457460 From djelinski1 at gmail.com Mon May 19 14:06:30 2025 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Mon, 19 May 2025 16:06:30 +0200 Subject: JEP 510: HKDFParameterSpec.expandOnly(byte[] prk) In-Reply-To: References: Message-ID: Hi Sebastian, The PRK argument always comes from a LabeledExtract output in the RFC you cite. You can use extract + thenExpand, or generate key material for expand with deriveKey. Is there any case where you need the prk as a byte array? Note that certain providers (PKCS11) may or may not support externally-supplied byte arrays as PRK, and should always be used with a SecretKey. Regards, Daniel pon., 19 maj 2025 o 12:22 Sebastian Stenzel napisa?(a): > > Hi, > > I?m using the HKDF extract and expand steps separately for this step [1] in HPKE. > > In this case I need to pass a byte[] prk to expandOnly(?), however the API only accepts a SecretKey, forcing me to wrap the bytes just for them to be unwrapped by the expand operation again. Probably this has already been discussed, so please feel free to point me to any existing rationale. > > Otherwise, is it too late to ask you to add a `expandOnly(byte[] prk)` function? > > Cheers, > Sebastian > > [1] https://www.rfc-editor.org/rfc/rfc9180#section-4-10 From myankelevich at openjdk.org Mon May 19 14:36:11 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 19 May 2025 14:36:11 GMT Subject: Integrated: 8349151: Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 15:56:29 GMT, Mikhail Yankelevich wrote: > Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test This pull request has now been integrated. Changeset: fbc12be7 Author: Mikhail Yankelevich Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/fbc12be73217315d66792b6ad3faacab133bb9d5 Stats: 122 lines in 2 files changed: 47 ins; 58 del; 17 mod 8349151: Refactor test/java/security/cert/CertificateFactory/slowstream.sh to java test Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/23394 From hchao at openjdk.org Mon May 19 15:10:55 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Mon, 19 May 2025 15:10:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18] In-Reply-To: References: Message-ID: On Sat, 17 May 2025 00:03:10 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright dates. src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 746: > 744: return serverRandom; > 745: } > 746: It looks like these getters (`getExporterMasterSecret(`), `getClientRandom()`, and `getServerRandom()`) are not used yet outside of this class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2095927197 From hchao at openjdk.org Mon May 19 15:16:55 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Mon, 19 May 2025 15:16:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18] In-Reply-To: References: Message-ID: On Sat, 17 May 2025 00:03:10 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Updated copyright dates. src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1623: > 1621: } finally { > 1622: KeyUtil.destroySecretKeys(derivedSecret); > 1623: } The `derivedSecret` is destroyed and cleared. How about `exporterMasterSecret`? Shall we also destroy it perhaps when the session is invalidated or closed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2095944384 From nbenalla at openjdk.org Mon May 19 16:08:02 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 19 May 2025 16:08:02 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base Message-ID: Please review this patch to fix some `javadoc` bugs in `java.base`. Certain `@link` tags used to refer to private fields instead of public APIs. A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. TIA ------------- Commit messages: - respond to feedback - fix incorrect `@link` tags Changes: https://git.openjdk.org/jdk/pull/25287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356632 Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/25287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25287/head:pull/25287 PR: https://git.openjdk.org/jdk/pull/25287 From liach at openjdk.org Mon May 19 16:08:03 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 May 2025 16:08:03 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893: > 4891: * @return a constant method handle of the given type, which returns a default value of the given return type > 4892: * @throws NullPointerException if the argument is null > 4893: * @see primitiveZero(Wrapper) Just `#zero(Class)` should be sufficient. This is probably changed by intellij during my original work to consolidate zero and constant. src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341: > 1339: * @throws ClassNotFoundException if one of the component classes cannot be resolved > 1340: * @see MethodType.readResolve() > 1341: * @see MethodType.writeObject(ObjectOutputStream s) This is already not generated by the javadoc as this method is private. Why is this check against a private method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094316583 PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094316628 From duke at openjdk.org Mon May 19 16:08:04 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 19 May 2025 16:08:04 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sun, 18 May 2025 02:17:46 GMT, Chen Liang wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4893: > >> 4891: * @return a constant method handle of the given type, which returns a default value of the given return type >> 4892: * @throws NullPointerException if the argument is null >> 4893: * @see primitiveZero(Wrapper) > > Just `#zero(Class)` should be sufficient. This is probably changed by intellij during my original work to consolidate zero and constant. From?: Suggestion: * @see MethodHandles#zero ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2094592478 From nbenalla at openjdk.org Mon May 19 16:08:04 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 19 May 2025 16:08:04 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sun, 18 May 2025 02:18:24 GMT, Chen Liang wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341: > >> 1339: * @throws ClassNotFoundException if one of the component classes cannot be resolved >> 1340: * @see MethodType.readResolve() >> 1341: * @see MethodType.writeObject(ObjectOutputStream s) > > This is already not generated by the javadoc as this method is private. Why is this check against a private method? They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2095501605 From wetmore at openjdk.org Mon May 19 18:08:08 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Mon, 19 May 2025 18:08:08 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v19] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Merge branch 'master' into JDK-8341346 - Updated copyright dates. - Merge branch 'master' into JDK-8341346 - Updated API to include SecretKey type, and a couple minor codereview comments - Merge branch 'master' into JDK-8341346 - Minor Codereview comments. - Codereview comments: updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs - Codereview comments: updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs - Codereview: removed serialization of of exporter Secret/randoms, and adjusted TLSv1-1.2 randoms capture locations since mastersecret could be reused - Merged with changes for JDK-8353578 - ... and 17 more: https://git.openjdk.org/jdk/compare/bd995256...ff494229 ------------- Changes: https://git.openjdk.org/jdk/pull/24976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=18 Stats: 1041 lines in 9 files changed: 1020 ins; 2 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From weijun.wang at oracle.com Mon May 19 18:49:04 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Mon, 19 May 2025 18:49:04 +0000 Subject: JEP 510: HKDFParameterSpec.expandOnly(byte[] prk) In-Reply-To: References: Message-ID: <771A34A6-6AD7-4864-AAD4-0DD0AC940968@oracle.com> Hi Sebastian, Thanks for your interest on the KDF APIs. As the name suggests, the PRK is a key, and we've represented it as a SecretKey. It's always complete, of fixed length, and provided in a single step. This is quite different from the IKM, which may come in various forms, or even a combination of them, such as labeled IKM, which you're likely familiar with from your work on HPKE. To support those cases, we offer multiple addIKM methods. By contrast, providing the PRK as a byte[] seems to offer limited practical benefit. As Daniel pointed out, it might not even be feasible in some contexts. Best wishes, Weijun > On May 19, 2025, at 10:06, Daniel Jeli?ski wrote: > > Hi Sebastian, > The PRK argument always comes from a LabeledExtract output in the RFC > you cite. You can use extract + thenExpand, or generate key material > for expand with deriveKey. Is there any case where you need the prk as > a byte array? > > Note that certain providers (PKCS11) may or may not support > externally-supplied byte arrays as PRK, and should always be used with > a SecretKey. > Regards, > Daniel > > pon., 19 maj 2025 o 12:22 Sebastian Stenzel > napisa?(a): >> >> Hi, >> >> I?m using the HKDF extract and expand steps separately for this step [1] in HPKE. >> >> In this case I need to pass a byte[] prk to expandOnly(?), however the API only accepts a SecretKey, forcing me to wrap the bytes just for them to be unwrapped by the expand operation again. Probably this has already been discussed, so please feel free to point me to any existing rationale. >> >> Otherwise, is it too late to ask you to add a `expandOnly(byte[] prk)` function? >> >> Cheers, >> Sebastian >> >> [1] https://www.rfc-editor.org/rfc/rfc9180#section-4-10 From sean.mullan at oracle.com Mon May 19 19:41:49 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 May 2025 15:41:49 -0400 Subject: Implementing Destroyable In-Reply-To: <1F903CEA-1572-484E-915F-5CAD55CD4730@gmail.com> References: <1F903CEA-1572-484E-915F-5CAD55CD4730@gmail.com> Message-ID: <72406c28-c6cb-4c2b-a6af-d18998fc05aa@oracle.com> Hi Sebastian, Thanks for your interest in the security APIs. This issue is more complex than it looks on the surface. You have alluded to one of the issues, which is that BigInteger is immutable and thus cannot be easily cleared. Rather than trying to have a discussion about this now, I would appreciate if we could delay discussion of this topic for a couple of weeks as we are quite busy meeting the RDP1 deadline for JDK 25. Stay tuned for more details. Thanks, Sean On 5/19/25 6:10 AM, Sebastian Stenzel wrote: > Hi all, > > I noticed that most classes implementing javax.security.auth.Destroyable do not actually overwrite it. After discussing this topic with Christian Stein last week, I decided to add some implementations. > > First, I?d like to start with trivial cases with keys encapsulating byte[], as done with symmetric keys or Edwards curves. Later, I might move on to other PrivateKeys, that have some BigInteger that can only be mutated via reflection - doing so is probably debatable. > > Before starting, I?d like to get a better understanding of whether there is a reason why destroy() isn?t used. Instead, I found uses of alternative ways of (eventually) destroying secrets, such as > * via jdk.internal.access.SharedSecrets.getJavaSecuritySpecAccess().clearEncodedKeySpec(keySpec); > * via jdk.internal.ref.CleanerFactory.cleaner().register(?) > > Neither exposes a way to let the API consumer erase key data at a deterministic point in time. I am fully aware this doesn?t reliably prohibit memory dumps from containing the keys. Nevertheless I believe such control is desirable as a best effort attempt to keep keys short-lived when possible. Think of ephemeral key pairs for single-shot ECIES, for example. > > I hope you can either shed some light on the current state or give me the green light for a PR. > > Best regards, > Sebastian From wetmore at openjdk.org Mon May 19 20:18:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Mon, 19 May 2025 20:18:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 15:06:26 GMT, Hai-May Chao wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyright dates. > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 746: > >> 744: return serverRandom; >> 745: } >> 746: > > It looks like these getters (`getExporterMasterSecret(`), `getClientRandom()`, and `getServerRandom()`) are not used yet outside of this class. Good point, everything is internal now. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2096422333 From wetmore at openjdk.org Mon May 19 20:28:46 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Mon, 19 May 2025 20:28:46 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v20] In-Reply-To: References: Message-ID: <0jPdA80XCzsrPx6Ltk03Dot5MwVjssYtqbgZzdYA66A=.53d94e4b-15c2-49c4-8411-6bf85417d656@github.com> > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: get*() no longer needed, backout error (oops!) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/ff494229..cde5edb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=18-19 Stats: 22 lines in 1 file changed: 0 ins; 21 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From wetmore at openjdk.org Mon May 19 20:28:48 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Mon, 19 May 2025 20:28:48 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v18] In-Reply-To: References: Message-ID: <6C6lGpq5XccWlV_AXIdTSeXKTBGNLaj3b1SORvMcUCg=.c23348c6-6fc4-4b32-9dbf-323355f82fa3@github.com> On Mon, 19 May 2025 15:13:26 GMT, Hai-May Chao wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyright dates. > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1623: > >> 1621: } finally { >> 1622: KeyUtil.destroySecretKeys(derivedSecret); >> 1623: } > > The `derivedSecret` is destroyed and cleared. How about `exporterMasterSecret`? Shall we also destroy it perhaps when the session is invalidated or closed? In RFC 8446/Section 7.1, the "derived" secret and "Master Secret" are temporary variables used to derive the application secrets, the exporter_master_secret, and the resumption_master_secret. These variables are long-lived and don't need to be cleared like these two. When we invalidate a session, that simply marks the session as unresumable, and doesn't destroy the session for active connections. We don't "close" sessions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2096432034 From darcy at openjdk.org Mon May 19 20:43:52 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 19 May 2025 20:43:52 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Mon, 19 May 2025 11:31:23 GMT, Nizar Benalla wrote: >> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1341: >> >>> 1339: * @throws ClassNotFoundException if one of the component classes cannot be resolved >>> 1340: * @see MethodType.readResolve() >>> 1341: * @see MethodType.writeObject(ObjectOutputStream s) >> >> This is already not generated by the javadoc as this method is private. Why is this check against a private method? > > They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) Okay -- if there is some link to the private serial-related methods even in a public javadoc run, I think it would be preferable if links to those methods could be resolved by javadoc. Otherwise, if the links to private methods _from a private method_, would be valid in a private javadoc run, I thinks more refined version of warning would let those be. As it is, if the see tags are going to stay, I don't think `foo` markup should be used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2096456914 From mullan at openjdk.org Mon May 19 20:48:52 2025 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 19 May 2025 20:48:52 GMT Subject: RFR: 8357062: Update Public Suffix List to 823beb1 In-Reply-To: References: Message-ID: On Fri, 16 May 2025 19:53:39 GMT, Weijun Wang wrote: > This is a routine update to synchronize with the [Mozilla Public Suffix List](https://github.com/publicsuffix/list) for JDK 25, matching commit 823beb1 from 2025-05-12. > > The test has been updated to reflect corresponding changes. > > If you are really curious about whether I downloaded the correct file, please run: > ```diff <(curl https://raw.githubusercontent.com/openjdk/jdk/refs/pull/25273/head/src/java.base/share/data/publicsuffixlist/public_suffix_list.dat) <(curl https://raw.githubusercontent.com/publicsuffix/list/823beb1/public_suffix_list.dat)``` > You can see the PR number and the PSL commit ID inside the command. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25273#pullrequestreview-2851959607 From abarashev at openjdk.org Mon May 19 21:29:25 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Mon, 19 May 2025 21:29:25 GMT Subject: RFR: 8357033: Reduce stateless session ticket size Message-ID: The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet Things done in this PR to reduce the ticket size in order of importance: 1. Remove local certificates. 2. Compress tickets with the size 600 bytes or larger. 3. Remove `peerSupportedSignAlgs`. 4. Remove `pskIdentity` 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 6. Remove `statusResponses` Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. ------------- Commit messages: - Remove Status Responses from the session ticket - PreSharedKey is only needed by TLS1.3, masterSecret is only needed by pre-TLS1.3 - Remove pskIdentity from session ticket - Fix compressed ticket compression marker bug - Do not compress small tickets. Remove peerSupportedSignAlgs. - Load local certificates only when present in session ticket - Load local certificates - GZip new session ticket Changes: https://git.openjdk.org/jdk/pull/25310/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357033 Stats: 306 lines in 3 files changed: 92 ins; 110 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From jnimeh at openjdk.org Mon May 19 22:41:57 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Mon, 19 May 2025 22:41:57 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v20] In-Reply-To: <0jPdA80XCzsrPx6Ltk03Dot5MwVjssYtqbgZzdYA66A=.53d94e4b-15c2-49c4-8411-6bf85417d656@github.com> References: <0jPdA80XCzsrPx6Ltk03Dot5MwVjssYtqbgZzdYA66A=.53d94e4b-15c2-49c4-8411-6bf85417d656@github.com> Message-ID: On Mon, 19 May 2025 20:28:46 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > get*() no longer needed, backout error (oops!) src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1672: > 1670: // RFC 5705, "If no context is provided, ..." > 1671: seed[pos++] = (byte) ((context.length >> 8) & 0xFF); > 1672: seed[pos++] = (byte) ((context.length) & 0xFF); Because you're doing a primitive narrowing conversion down to a byte I don't think you need the 0xFF masking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2096561543 From abarashev at openjdk.org Tue May 20 03:01:06 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 03:01:06 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: References: Message-ID: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Log error and return null no compress/decompress failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/5c1af00c..7c1a25c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=00-01 Stats: 13 lines in 1 file changed: 8 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From alanb at openjdk.org Tue May 20 06:50:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 May 2025 06:50:51 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 138: > 136: * {@link #isCompletedAbnormally} is true if a task was either > 137: * cancelled or encountered an exception, in which case {@link > 138: * #getException()} will return either the encountered exception or Looks right too, the private overload of getException was added in JDK 22. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2097113958 From alanb at openjdk.org Tue May 20 06:54:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 May 2025 06:54:58 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: <2ZTFvRUO5p9CkTijR0qS6x9bwgbI3o4C286Wk9HvHVU=.04f8ca7b-cdf9-4a09-9d3d-587a414d51e1@github.com> On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 2023: > 2021: /** > 2022: * Provides a service with one or more implementations. The package for > 2023: * each {@link Provides#providers() provider} (or provider factory) is okay ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2097120353 From sthorger at redhat.com Tue May 20 08:07:45 2025 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 May 2025 10:07:45 +0200 Subject: Status of TLS 1.3 Hybrid Key Exchange (JDK-8314323) Message-ID: Hi, I've been trying to find out when OpenJDK will have support for hybrid key exchange in TLS 1.3. I've found the corresponding issue: https://bugs.openjdk.org/browse/JDK-8314323, but not able to find any information on the status of this work, nor what OpenJDK releases it targets. Is this planned for OpenJDK 25? Are there considerations to back-port to older releases? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.stenzel at gmail.com Tue May 20 08:37:31 2025 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 20 May 2025 10:37:31 +0200 Subject: Implementing Destroyable In-Reply-To: <72406c28-c6cb-4c2b-a6af-d18998fc05aa@oracle.com> References: <1F903CEA-1572-484E-915F-5CAD55CD4730@gmail.com> <72406c28-c6cb-4c2b-a6af-d18998fc05aa@oracle.com> Message-ID: <2B8DC883-7695-4052-BA45-84B880F50AC3@gmail.com> Hi Sean, I was hoping to have the ?trivial? implementations (pure byte[] wrappers such as SecretKeySpec etc) done before RDP1. I expect the second PR to cause more discussions. Cheers! Sebastian > On 19. May 2025, at 21:41, Sean Mullan wrote: > > Hi Sebastian, > > Thanks for your interest in the security APIs. > > This issue is more complex than it looks on the surface. You have alluded to one of the issues, which is that BigInteger is immutable and thus cannot be easily cleared. > > Rather than trying to have a discussion about this now, I would appreciate if we could delay discussion of this topic for a couple of weeks as we are quite busy meeting the RDP1 deadline for JDK 25. Stay tuned for more details. > > Thanks, > Sean > > On 5/19/25 6:10 AM, Sebastian Stenzel wrote: >> Hi all, >> I noticed that most classes implementing javax.security.auth.Destroyable do not actually overwrite it. After discussing this topic with Christian Stein last week, I decided to add some implementations. >> First, I?d like to start with trivial cases with keys encapsulating byte[], as done with symmetric keys or Edwards curves. Later, I might move on to other PrivateKeys, that have some BigInteger that can only be mutated via reflection - doing so is probably debatable. >> Before starting, I?d like to get a better understanding of whether there is a reason why destroy() isn?t used. Instead, I found uses of alternative ways of (eventually) destroying secrets, such as >> * via jdk.internal.access.SharedSecrets.getJavaSecuritySpecAccess().clearEncodedKeySpec(keySpec); >> * via jdk.internal.ref.CleanerFactory.cleaner().register(?) >> Neither exposes a way to let the API consumer erase key data at a deterministic point in time. I am fully aware this doesn?t reliably prohibit memory dumps from containing the keys. Nevertheless I believe such control is desirable as a best effort attempt to keep keys short-lived when possible. Think of ephemeral key pairs for single-shot ECIES, for example. >> I hope you can either shed some light on the current state or give me the green light for a PR. >> Best regards, >> Sebastian > From sebastian.stenzel at gmail.com Tue May 20 09:56:08 2025 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 20 May 2025 11:56:08 +0200 Subject: JEP 510: HKDFParameterSpec.expandOnly(byte[] prk) In-Reply-To: <771A34A6-6AD7-4864-AAD4-0DD0AC940968@oracle.com> References: <771A34A6-6AD7-4864-AAD4-0DD0AC940968@oracle.com> Message-ID: <9F41405F-CD91-4B98-8737-7743AA1BF195@gmail.com> Hi, thank you for your fast replies! * One benefit of using byte[] is that I can nil the PRK after I?m done (while secretKey.destroy() isn?t well supported, see my other post from yesterday on this mailing list) * Another reason is that it feels clunky to specify a key algorithm for the PRK (does it need to be "Hmac-SHAnnn")? * In places where I want to expand both keys and bytes from a single PRK (as with "secret" here [1]), I need quite a bit of code duplication for the `labeledExpand` operations with different return types Neither reason is a real blocker for me, though. That said, please consider that the HKDF RFC specifically mentions the possibility to directly expand a suitable uniformly random IKM, skipping the extract phase [2]. Arguing that some providers won?t accept this is an incomplete implementation of a standard. Best regards, Sebastian [1]: https://www.rfc-editor.org/rfc/rfc9180#section-5.1-10 [2]: https://datatracker.ietf.org/doc/html/rfc5869#section-3.3 > On 19. May 2025, at 20:49, Wei-Jun Wang wrote: > > Hi Sebastian, > > Thanks for your interest on the KDF APIs. > > As the name suggests, the PRK is a key, and we've represented it as a SecretKey. It's always complete, of fixed length, and provided in a single step. This is quite different from the IKM, which may come in various forms, or even a combination of them, such as labeled IKM, which you're likely familiar with from your work on HPKE. To support those cases, we offer multiple addIKM methods. By contrast, providing the PRK as a byte[] seems to offer limited practical benefit. As Daniel pointed out, it might not even be feasible in some contexts. > > Best wishes, > Weijun > > >> On May 19, 2025, at 10:06, Daniel Jeli?ski wrote: >> >> Hi Sebastian, >> The PRK argument always comes from a LabeledExtract output in the RFC >> you cite. You can use extract + thenExpand, or generate key material >> for expand with deriveKey. Is there any case where you need the prk as >> a byte array? >> >> Note that certain providers (PKCS11) may or may not support >> externally-supplied byte arrays as PRK, and should always be used with >> a SecretKey. >> Regards, >> Daniel >> >> pon., 19 maj 2025 o 12:22 Sebastian Stenzel >> napisa?(a): >>> >>> Hi, >>> >>> I?m using the HKDF extract and expand steps separately for this step [1] in HPKE. >>> >>> In this case I need to pass a byte[] prk to expandOnly(?), however the API only accepts a SecretKey, forcing me to wrap the bytes just for them to be unwrapped by the expand operation again. Probably this has already been discussed, so please feel free to point me to any existing rationale. >>> >>> Otherwise, is it too late to ask you to add a `expandOnly(byte[] prk)` function? >>> >>> Cheers, >>> Sebastian >>> >>> [1] https://www.rfc-editor.org/rfc/rfc9180#section-4-10 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski at openjdk.org Tue May 20 11:40:00 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 20 May 2025 11:40:00 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> Message-ID: <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> On Tue, 20 May 2025 03:01:06 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Log error and return null no compress/decompress failure This looks promising. What ticket sizes have you observed when no client certificates were involved? src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 324: > 322: b = Record.getBytes8(buf); > 323: if (b.length > 0) { > 324: String alg = new String(b); Please remove the algorithm names from the session ticket. They were not used, and I don't see any reason to start using them now. src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 421: > 419: > 420: SSLPossession pos = X509Authentication.createPossession( > 421: hc, certAlgs); Are you trying to select the same certificate that was used in the original handshake? That's an interesting approach. Are you confident that this will produce the same possession as the original handshake, assuming that the ClientHello is the same and the KeyManager certificates did not change? I think you only need the certAlg of the first certificate in the chain for createPossession. src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 424: > 422: > 423: if (pos == null) { > 424: throw hc.conContext.fatal(Alert.HANDSHAKE_FAILURE, I don't think using `fatal` is the right choice here; ideally we should fall back to a full handshake instead. Consider setting invalidated=true instead src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 238: > 236: byte compressed = 0; > 237: if (data.length >= MIN_COMPRESS_SIZE) { > 238: data = compress(data); we should probably handle the null return here. src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 250: > 248: result[3] = (byte)(key.num); > 249: System.arraycopy(iv, 0, result, Integer.BYTES, iv.length); > 250: result[Integer.BYTES + iv.length] = compressed; this byte should be authenticated. Either pass it to updateAAD, or to doFinal src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 262: > 260: } > 261: > 262: ByteBuffer decrypt(HandshakeContext hc) throws IOException { does it really throw? src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 336: > 334: int count = 0; > 335: int b; > 336: while ((b = gis.read()) >= 0) { use gis.readAllBytes() ------------- PR Review: https://git.openjdk.org/jdk/pull/25310#pullrequestreview-2853321629 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2097538961 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2097556759 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2097506777 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2097431800 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2097401544 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2097432527 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2097412283 From duke at openjdk.org Tue May 20 11:56:52 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 20 May 2025 11:56:52 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v6] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 00:28:18 GMT, Sandhya Viswanathan wrote: >> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: >> >> Response to review comment + loading constants with broadcast op. > > src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 250: > >> 248: static void montmul(int outputRegs[], int inputRegs1[], int inputRegs2[], >> 249: int scratchRegs1[], int scratchRegs2[], MacroAssembler *_masm) { >> 250: for (int i = 0; i < 4; i++) { > > In the intrinsic for montMul we are treating as if MONT_R_BITS is 16 and MONT_Q_INV_MOD_R is 0xF301 whereas in the Java code MONT_R_BITS is 20 and MONT_Q_INT_MOD_R is 0x8F301. Are these equivalent? As used in this case, they are equivalent. For z = montmul(a,b), z will be between -q and q and congruent to a * b * R^-1 mod q, where R > 2 * q, R is a power of 2, -R/2 * q <= a * b < R/2 * q. For the Java code, we use R = 2^20 and for the intrinsic, R = 2^16. In our computations, b is always c * R mod q, so the montmul() really computes a * c mod q. In the Java code, we use 32-bit numbers for the computations, and we use R = 2^20 because that way the a * b numbers that occur during all computations stay in the required range (the inverse NTT computation is where they can grow the most), so we don't have to do Barrett reductions during that computation. For the intrinsics, we use R = 2^16, because this way we can do twice as much work in parallel, but we have to do Barrett reduction after levels 2 and 4 in the inverse NTT computation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2097757145 From pminborg at openjdk.org Tue May 20 12:06:35 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 20 May 2025 12:06:35 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() Message-ID: This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost. This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. ------------- Commit messages: - Remove import - Remove comment - Use getBufferAddress() rather than address() Changes: https://git.openjdk.org/jdk/pull/25324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357268 Stats: 93 lines in 16 files changed: 32 ins; 0 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From pminborg at openjdk.org Tue May 20 12:06:35 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 20 May 2025 12:06:35 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() In-Reply-To: References: Message-ID: On Tue, 20 May 2025 10:51:13 GMT, Per Minborg wrote: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost. > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 254: > 252: ByteBuffer dst = Util.getTemporaryDirectBuffer(len); > 253: assert dst.position() == 0; > 254: NIO_ACCESS.acquireSession(dst); Not strictly needed, but is proposed for consistency. src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459: > 457: > 458: boolean pending = false; > 459: NIO_ACCESS.acquireSession(buf); Here, we acquire the session *after* we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2097665536 PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2097670174 From alanb at openjdk.org Tue May 20 12:27:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 May 2025 12:27:52 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() In-Reply-To: References: Message-ID: On Tue, 20 May 2025 10:51:13 GMT, Per Minborg wrote: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost. > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. We need to audit the tests for the APIs that take a byte buffer to ensure that we have tests to exercise these APIs with buffers that are views on a memory segment. That would help identify any bugs. The temporary buffer cache is internal so I think better to separate from this JBS issue and PR as these cases cannot be views on a memory segment. Future work to re-implement the temporary buffer cache can re-visit this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2894215287 From pminborg at openjdk.org Tue May 20 12:49:06 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 20 May 2025 12:49:06 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v2] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > In some of the cases, this is not strictly needed as the internal cache in `sun.nio.ch.Util#getTemporaryDirectBuffer` is (currently) only returning Buffers that are not backed by a `MemorySegment`. Also, we now always acquire/release buffer sessions before interacting with memory. Again, this is not always needed for temporary direct buffers but provides a consistent handling of buffers at a minimal cost. > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Revoke changes in classes that is always using DirectBuffer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/6e733a18..9c5a3573 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=00-01 Stats: 25 lines in 5 files changed: 0 ins; 16 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From pminborg at openjdk.org Tue May 20 12:54:06 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 20 May 2025 12:54:06 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v3] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/9c5a3573..f2764bf1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From abarashev at openjdk.org Tue May 20 13:31:55 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 13:31:55 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> Message-ID: On Tue, 20 May 2025 11:37:03 GMT, Daniel Jeli?ski wrote: > This looks promising. What ticket sizes have you observed when no client certificates were involved? Without peer certificates I observed only between 170 and 210 bytes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25310#issuecomment-2894417380 From alanb at openjdk.org Tue May 20 13:40:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 May 2025 13:40:52 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 12:54:06 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Clean up A question for folks onsecurity-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2894448506 From dfuchs at openjdk.org Tue May 20 14:04:51 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 20 May 2025 14:04:51 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA Changes to `java.net.Socket` LGTM ------------- PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2854340236 From nbenalla at openjdk.org Tue May 20 14:27:51 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 20 May 2025 14:27:51 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Mon, 19 May 2025 20:41:13 GMT, Joe Darcy wrote: >> They are documented in [this page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) > > Okay -- if there is some link to the private serial-related methods even in a public javadoc run, I think it would be preferable if links to those methods could be resolved by javadoc. Otherwise, if the links to private methods _from a private method_, would be valid in a private javadoc run, I thinks more refined version of warning would let those be. > > As it is, if the see tags are going to stay, I don't think `foo` markup should be used. I will revert the changes to `MethoType.java` and try to make the links to the private methods resolvable. (In a future patch) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2098123931 From abarashev at openjdk.org Tue May 20 14:51:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 14:51:54 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> Message-ID: <0zUfYaPso06NXaYZFdyw35WIcvDLW9zlkYo7MugIeA8=.5193be86-dc25-4ebb-9d15-044d7e733970@github.com> On Tue, 20 May 2025 10:02:44 GMT, Daniel Jeli?ski wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Log error and return null no compress/decompress failure > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 421: > >> 419: >> 420: SSLPossession pos = X509Authentication.createPossession( >> 421: hc, certAlgs); > > Are you trying to select the same certificate that was used in the original handshake? That's an interesting approach. Are you confident that this will produce the same possession as the original handshake, assuming that the ClientHello is the same and the KeyManager certificates did not change? > > I think you only need the certAlg of the first certificate in the chain for createPossession. If we use the same KeyStore and the same KeyManager then the certificate(s) will be the same most of the time but there is no guarantee of course: 1. We can have different constraints in `java.security` 2. When resuming client doesn't include `signature_algorithms` and `signature_algorithms_cert` extensions with ClientHello which affect how the original certificate was selected. As far as I can tell local certificates are not being used by TLS layer after the handshake but they can be requested by application layers above such as HTTPS. If having the same local certificate(s) for resuming the session is a requirement then I think we can add a few more bytes to the ticket as a certificate's fingerprint (`X509CertImpl.getFingerprint`) and then validate that fingerprint(s) against certificate(s) in the new possession. We then fall back to a full handshake if such validation fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098184133 From weijun at openjdk.org Tue May 20 14:53:56 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 20 May 2025 14:53:56 GMT Subject: Integrated: 8357062: Update Public Suffix List to 823beb1 In-Reply-To: References: Message-ID: On Fri, 16 May 2025 19:53:39 GMT, Weijun Wang wrote: > This is a routine update to synchronize with the [Mozilla Public Suffix List](https://github.com/publicsuffix/list) for JDK 25, matching commit 823beb1 from 2025-05-12. > > The test has been updated to reflect corresponding changes. > > If you are really curious about whether I downloaded the correct file, please run: > ```diff <(curl https://raw.githubusercontent.com/openjdk/jdk/refs/pull/25273/head/src/java.base/share/data/publicsuffixlist/public_suffix_list.dat) <(curl https://raw.githubusercontent.com/publicsuffix/list/823beb1/public_suffix_list.dat)``` > You can see the PR number and the PSL commit ID inside the command. This pull request has now been integrated. Changeset: 6162e2c5 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/6162e2c5213c5dd7c1127fd9616b543efa898962 Stats: 3563 lines in 5 files changed: 1500 ins; 1442 del; 621 mod 8357062: Update Public Suffix List to 823beb1 Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/25273 From weijun at openjdk.org Tue May 20 15:20:43 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 20 May 2025 15:20:43 GMT Subject: RFR: 8325448: Hybrid Public Key Encryption [v19] In-Reply-To: References: Message-ID: <8YMx92MNS38S3h481KIpMf-xOPBtpOxRbk83wN-L8ZM=.dc9b883f-7798-4a2d-8639-dd460fdd04cd@github.com> > Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. > ![HPKEParameterSpec ? 11 54 ? 04-21](https://github.com/user-attachments/assets/da309585-db51-40d6-b291-3d38040d6292) Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - merge - engineGetBlockSize and engineGetOutputSize returns 0 when not initialized - change argument order for exporters, reject null exporter_context - Merge branch 'master' into 8325448 - address Sean's comments - toString, exportData, spec in HPKEParameters must have algorithm identifiers specified - put encapsulation in params from getParameters - receiver must specify all algorithm identifiers - Merge branch 'master' into 8325448 - remove unused imports - ... and 22 more: https://git.openjdk.org/jdk/compare/62d155e8...f819de2e ------------- Changes: https://git.openjdk.org/jdk/pull/18411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=18 Stats: 2168 lines in 12 files changed: 1971 ins; 74 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/18411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411 PR: https://git.openjdk.org/jdk/pull/18411 From alanb at openjdk.org Tue May 20 15:43:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 May 2025 15:43:00 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 12:54:06 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Clean up src/java.base/share/classes/sun/nio/ch/Util.java line 46: > 44: public class Util { > 45: > 46: static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess(); There are methods in IOUtil for the classes in sun.nio.ch. So no need to expose NIO_ACCESS here. src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 671: > 669: > 670: } finally { > 671: NIO_ACCESS.releaseSession(buf); I thin the change to WindowsAsynchronousFileChannel will need more than one reviewer as the I/O operation may complete on a different thread to the one that it was initiated on. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 764: > 762: int outOfs = 0; > 763: if (outBuffer instanceof DirectBuffer) { > 764: outAddr = NIO_ACCESS.getBufferAddress(outBuffer); This looks right. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 1017: > 1015: int outOfs = 0; > 1016: if (outBuffer instanceof DirectBuffer) { > 1017: outAddr = NIO_ACCESS.getBufferAddress(outBuffer); This looks right. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Digest.java line 292: > 290: NIO_ACCESS.acquireSession(byteBuffer); > 291: try { > 292: token.p11.C_DigestUpdate(session.id(), NIO_ACCESS.getBufferAddress(byteBuffer) + ofs, null, 0, len); `long address = NIO_ACCESS.getBufferAddress(byteBuffer);` might be clearer here. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 289: > 287: NIO_ACCESS.acquireSession(byteBuffer); > 288: try { > 289: token.p11.C_SignUpdate(session.id(), NIO_ACCESS.getBufferAddress(byteBuffer) + ofs, null, 0, len); I think I would introduce a long address here too, only to make the line easier to read. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098279301 PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098297686 PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098298906 PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098299247 PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098300469 PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098302426 From pminborg at openjdk.org Tue May 20 15:52:06 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 20 May 2025 15:52:06 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v4] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/f2764bf1..be261f56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=02-03 Stats: 27 lines in 2 files changed: 15 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From abarashev at openjdk.org Tue May 20 15:58:03 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 15:58:03 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> Message-ID: On Tue, 20 May 2025 09:05:28 GMT, Daniel Jeli?ski wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Log error and return null no compress/decompress failure > > src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 238: > >> 236: byte compressed = 0; >> 237: if (data.length >= MIN_COMPRESS_SIZE) { >> 238: data = compress(data); > > we should probably handle the null return here. Good point, thanks! We should return `null` here if compression fails for some reason. > src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 262: > >> 260: } >> 261: >> 262: ByteBuffer decrypt(HandshakeContext hc) throws IOException { > > does it really throw? Removed. It was left here after I moved decompression to a separate method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098327581 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098331444 From pminborg at openjdk.org Tue May 20 16:10:07 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 20 May 2025 16:10:07 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v5] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update after comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/be261f56..6435f777 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=03-04 Stats: 14 lines in 5 files changed: 2 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From djelinski at openjdk.org Tue May 20 16:30:55 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 20 May 2025 16:30:55 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: <0zUfYaPso06NXaYZFdyw35WIcvDLW9zlkYo7MugIeA8=.5193be86-dc25-4ebb-9d15-044d7e733970@github.com> References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> <0zUfYaPso06NXaYZFdyw35WIcvDLW9zlkYo7MugIeA8=.5193be86-dc25-4ebb-9d15-044d7e733970@github.com> Message-ID: On Tue, 20 May 2025 14:49:27 GMT, Artur Barashev wrote: > As far as I can tell local certificates are not being used by TLS layer after the handshake but they can be requested by application layers above such as HTTPS. Right, that matches my observations. > If having the same local certificate(s) for resuming the session is a requirement then I think we can add a few more bytes to the ticket as a certificate's fingerprint (X509CertImpl.getFingerprint) and then validate that fingerprint(s) against certificate(s) in the new possession. We then fall back to a full handshake if such validation fails. I'm not aware of any uses of the local certificates / local principal on the server side, but I'd err on the side of caution. The resumed session should either return the same certificates, or return an obviously wrong value (like null), so that users can detect unexpected values. Checking the fingerprint and falling back to a full handshake sounds reasonable to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098404526 From abarashev at openjdk.org Tue May 20 17:16:51 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 17:16:51 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> Message-ID: On Tue, 20 May 2025 09:53:48 GMT, Daniel Jeli?ski wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Log error and return null no compress/decompress failure > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 324: > >> 322: b = Record.getBytes8(buf); >> 323: if (b.length > 0) { >> 324: String alg = new String(b); > > Please remove the algorithm names from the session ticket. They were not used, and I don't see any reason to start using them now. Hm.. they are being specified everywhere else in SSL code. So I guess we should pass an empty string to `SecretKeySpec` constructor then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098489233 From sviswanathan at openjdk.org Tue May 20 17:17:58 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 20 May 2025 17:17:58 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v6] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 11:51:49 GMT, Ferenc Rakoczi wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp line 250: >> >>> 248: static void montmul(int outputRegs[], int inputRegs1[], int inputRegs2[], >>> 249: int scratchRegs1[], int scratchRegs2[], MacroAssembler *_masm) { >>> 250: for (int i = 0; i < 4; i++) { >> >> In the intrinsic for montMul we are treating as if MONT_R_BITS is 16 and MONT_Q_INV_MOD_R is 0xF301 whereas in the Java code MONT_R_BITS is 20 and MONT_Q_INT_MOD_R is 0x8F301. Are these equivalent? > > As used in this case, they are equivalent. For z = montmul(a,b), z will be between -q and q and congruent to a * b * R^-1 mod q, where R > 2 * q, R is a power of 2, -R/2 * q <= a * b < R/2 * q. For the Java code, we use R = 2^20 and for the intrinsic, R = 2^16. In our computations, b is always c * R mod q, so the montmul() really computes a * c mod q. In the Java code, we use 32-bit numbers for the computations, and we use R = 2^20 because that way the a * b numbers that occur during all computations stay in the required range (the inverse NTT computation is where they can grow the most), so we don't have to do Barrett reductions during that computation. For the intrinsics, we use R = 2^16, because this way we can do twice as much work in parallel, but we have to do Barrett reduction after levels 2 and 4 in the inverse NTT computation. Thanks a lot for the explanation. It would be good to add it as a comment in the stubGenerator_x86_64_kyber.cpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24953#discussion_r2098491524 From abarashev at openjdk.org Tue May 20 17:28:51 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 17:28:51 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> Message-ID: <-f3be8QSOw_WIhntB3XQA4neD-HljrE_vtN0Q5vJsxU=.9c1e1c30-644b-47dc-bfe4-71fbb4af32c4@github.com> On Tue, 20 May 2025 08:51:36 GMT, Daniel Jeli?ski wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Log error and return null no compress/decompress failure > > src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 250: > >> 248: result[3] = (byte)(key.num); >> 249: System.arraycopy(iv, 0, result, Integer.BYTES, iv.length); >> 250: result[Integer.BYTES + iv.length] = compressed; > > this byte should be authenticated. Either pass it to updateAAD, or to doFinal Done, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098511576 From sviswanathan at openjdk.org Tue May 20 17:35:55 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 20 May 2025 17:35:55 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v6] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 13:33:42 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Response to review comment + loading constants with broadcast op. Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24953#pullrequestreview-2855056310 From duke at openjdk.org Tue May 20 17:49:14 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 20 May 2025 17:49:14 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: > By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: Added some comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24953/files - new: https://git.openjdk.org/jdk/pull/24953/files/e4f3264e..ea2152da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24953&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24953&range=05-06 Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24953/head:pull/24953 PR: https://git.openjdk.org/jdk/pull/24953 From sviswanathan at openjdk.org Tue May 20 17:52:55 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 20 May 2025 17:52:55 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Added some comments. Thanks for adding the comment. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24953#pullrequestreview-2855099857 From duke at openjdk.org Tue May 20 18:48:55 2025 From: duke at openjdk.org (duke) Date: Tue, 20 May 2025 18:48:55 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: <3ev08acOQdRUvWRfhksWfQER7TRnpd7gY5mA-OUb8_k=.5b3fe078-dbe9-41ec-b810-f7485280eba8@github.com> On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Added some comments. @ferakocz Your change (at version ea2152dab73080d2b4759526d220f19706d768b6) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24953#issuecomment-2895471350 From djelinski at openjdk.org Tue May 20 19:07:50 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 20 May 2025 19:07:50 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> Message-ID: On Tue, 20 May 2025 17:14:06 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 324: >> >>> 322: b = Record.getBytes8(buf); >>> 323: if (b.length > 0) { >>> 324: String alg = new String(b); >> >> Please remove the algorithm names from the session ticket. They were not used, and I don't see any reason to start using them now. > > Hm.. they are being specified everywhere else in SSL code. So I guess we should pass an empty string to `SecretKeySpec` constructor then? Before this PR we used a hardcoded algorithm name "TlsMasterSecret" for both the PSK and the master secret. I think we can keep it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098676859 From duke at openjdk.org Tue May 20 19:08:59 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Tue, 20 May 2025 19:08:59 GMT Subject: Integrated: 8351412: Add AVX-512 intrinsics for ML-KEM In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 18:49:52 GMT, Ferenc Rakoczi wrote: > By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. This pull request has now been integrated. Changeset: 972f2ebe Author: Ferenc Rakoczi Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/972f2ebe978280d22531a70116e79837632f6ebc Stats: 988 lines in 10 files changed: 977 ins; 2 del; 9 mod 8351412: Add AVX-512 intrinsics for ML-KEM Reviewed-by: sviswanathan ------------- PR: https://git.openjdk.org/jdk/pull/24953 From abarashev at openjdk.org Tue May 20 19:12:52 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 19:12:52 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> Message-ID: On Tue, 20 May 2025 19:05:01 GMT, Daniel Jeli?ski wrote: >> Hm.. they are being specified everywhere else in SSL code. So I guess we should pass an empty string to `SecretKeySpec` constructor then? > > Before this PR we used a hardcoded algorithm name "TlsMasterSecret" for both the PSK and the master secret. I think we can keep it. Oh, right, forgot about it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098684588 From abarashev at openjdk.org Tue May 20 19:12:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 19:12:54 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> Message-ID: On Tue, 20 May 2025 08:56:23 GMT, Daniel Jeli?ski wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Log error and return null no compress/decompress failure > > src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 336: > >> 334: int count = 0; >> 335: int b; >> 336: while ((b = gis.read()) >= 0) { > > use gis.readAllBytes() Indeed, done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098681209 From mullan at openjdk.org Tue May 20 19:13:58 2025 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 20 May 2025 19:13:58 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: <0ZhaH_07oxLDZxz8wVEgbsbYWB50sjuLZxYwyM4ftno=.2adb899d-7768-481d-975b-8e0ee3e6f2c2@github.com> On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Added some comments. Please also write a release note as the performance improvement is significant. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24953#issuecomment-2895525488 From weijun.wang at oracle.com Tue May 20 20:24:30 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Tue, 20 May 2025 20:24:30 +0000 Subject: JEP 510: HKDFParameterSpec.expandOnly(byte[] prk) In-Reply-To: <9F41405F-CD91-4B98-8737-7743AA1BF195@gmail.com> References: <771A34A6-6AD7-4864-AAD4-0DD0AC940968@oracle.com> <9F41405F-CD91-4B98-8737-7743AA1BF195@gmail.com> Message-ID: > On May 20, 2025, at 05:56, Sebastian Stenzel wrote: > > Hi, > > thank you for your fast replies! > > * One benefit of using byte[] is that I can nil the PRK after I?m done (while secretKey.destroy() isn?t well supported, see my other post from yesterday on this mailing list) Yes, this one is complex. > * Another reason is that it feels clunky to specify a key algorithm for the PRK (does it need to be "Hmac-SHAnnn")? The modern algorithm for PRK is "Generic". See the new section for secret key algorithms at https://download.java.net/java/early_access/jdk25/docs/specs/security/standard-names.html#secretkey-algorithms. > * In places where I want to expand both keys and bytes from a single PRK (as with "secret" here [1]), I need quite a bit of code duplication for the `labeledExpand` operations with different return types You can specify "Generic" as the algorithm in the `deriveKey` call at the Extract-Only step to generate the "secret". I think some PKCS #11 library might not allow you to call `deriveData` here. I am not sure if I understand why the type of PRK could make multiple LabeledExpand more complicated. You can call `deriveKey` to generate the "key" and `deriveData` to generate the "base_nonce", but there is only one PRK. The code duplication is mostly at the labeling. > > Neither reason is a real blocker for me, though. Thanks for the understanding. > > That said, please consider that the HKDF RFC specifically mentions the possibility to directly expand a suitable uniformly random IKM, skipping the extract phase [2]. Arguing that some providers won?t accept this is an incomplete implementation of a standard. A new SecretKeyFactory for SunPKCS11 is introduced that is meant to translate a SecretKeySpec to an internal SecretKey. It's up to how the underlying PKCS #11 library supports it. Thanks, Weijun > > Best regards, > Sebastian > > [1]: https://www.rfc-editor.org/rfc/rfc9180#section-5.1-10 > [2]: https://datatracker.ietf.org/doc/html/rfc5869#section-3.3 > > >> On 19. May 2025, at 20:49, Wei-Jun Wang wrote: >> >> Hi Sebastian, >> >> Thanks for your interest on the KDF APIs. >> >> As the name suggests, the PRK is a key, and we've represented it as a SecretKey. It's always complete, of fixed length, and provided in a single step. This is quite different from the IKM, which may come in various forms, or even a combination of them, such as labeled IKM, which you're likely familiar with from your work on HPKE. To support those cases, we offer multiple addIKM methods. By contrast, providing the PRK as a byte[] seems to offer limited practical benefit. As Daniel pointed out, it might not even be feasible in some contexts. >> >> Best wishes, >> Weijun >> >> >>> On May 19, 2025, at 10:06, Daniel Jeli?ski wrote: >>> >>> Hi Sebastian, >>> The PRK argument always comes from a LabeledExtract output in the RFC >>> you cite. You can use extract + thenExpand, or generate key material >>> for expand with deriveKey. Is there any case where you need the prk as >>> a byte array? >>> >>> Note that certain providers (PKCS11) may or may not support >>> externally-supplied byte arrays as PRK, and should always be used with >>> a SecretKey. >>> Regards, >>> Daniel >>> >>> pon., 19 maj 2025 o 12:22 Sebastian Stenzel >>> napisa?(a): >>>> >>>> Hi, >>>> >>>> I?m using the HKDF extract and expand steps separately for this step [1] in HPKE. >>>> >>>> In this case I need to pass a byte[] prk to expandOnly(?), however the API only accepts a SecretKey, forcing me to wrap the bytes just for them to be unwrapped by the expand operation again. Probably this has already been discussed, so please feel free to point me to any existing rationale. >>>> >>>> Otherwise, is it too late to ask you to add a `expandOnly(byte[] prk)` function? >>>> >>>> Cheers, >>>> Sebastian >>>> >>>> [1] https://www.rfc-editor.org/rfc/rfc9180#section-4-10 >> > From wetmore at openjdk.org Tue May 20 21:14:02 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 20 May 2025 21:14:02 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v20] In-Reply-To: References: <0jPdA80XCzsrPx6Ltk03Dot5MwVjssYtqbgZzdYA66A=.53d94e4b-15c2-49c4-8411-6bf85417d656@github.com> Message-ID: On Mon, 19 May 2025 22:24:52 GMT, Jamil Nimeh wrote: >> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: >> >> get*() no longer needed, backout error (oops!) > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1672: > >> 1670: // RFC 5705, "If no context is provided, ..." >> 1671: seed[pos++] = (byte) ((context.length >> 8) & 0xFF); >> 1672: seed[pos++] = (byte) ((context.length) & 0xFF); > > Because you're doing a primitive narrowing conversion down to a byte I don't think you need the 0xFF masking. No, not required. `java.lang.Integer.byteValue()` does exactly this. But I was thinking to leave so the intent was clear. We talked, and will leave for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2098882406 From abarashev at openjdk.org Tue May 20 21:45:53 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 21:45:53 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> <0zUfYaPso06NXaYZFdyw35WIcvDLW9zlkYo7MugIeA8=.5193be86-dc25-4ebb-9d15-044d7e733970@github.com> Message-ID: On Tue, 20 May 2025 16:28:42 GMT, Daniel Jeli?ski wrote: >> If we use the same KeyStore and the same KeyManager then the certificate(s) will be the same most of the time but there is no guarantee of course: >> >> 1. We can have different constraints in `java.security` >> 2. Different `jdk.tls.server.SignatureSchemes` system property. >> >> As far as I can tell local certificates are not being used by TLS layer after the handshake but they can be requested by application layers above such as HTTPS. >> If having the same local certificate(s) for resuming the session is a requirement then I think we can add a few more bytes to the ticket as a certificate's fingerprint (`X509CertImpl.getFingerprint`) and then validate that fingerprint(s) against certificate(s) in the new possession. We then fall back to a full handshake if such validation fails. > >> As far as I can tell local certificates are not being used by TLS layer after the handshake but they can be requested by application layers above such as HTTPS. > > Right, that matches my observations. > >> If having the same local certificate(s) for resuming the session is a requirement then I think we can add a few more bytes to the ticket as a certificate's fingerprint (X509CertImpl.getFingerprint) and then validate that fingerprint(s) against certificate(s) in the new possession. We then fall back to a full handshake if such validation fails. > > I'm not aware of any uses of the local certificates / local principal on the server side, but I'd err on the side of caution. The resumed session should either return the same certificates, or return an obviously wrong value (like null), so that users can detect unexpected values. > > Checking the fingerprint and falling back to a full handshake sounds reasonable to me. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098922120 From abarashev at openjdk.org Tue May 20 21:45:56 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 21:45:56 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v2] In-Reply-To: <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> References: <_ddBFBUva2JTIqIL7Pjf2AOseZWFhMuwIR9Tb0vFYUA=.4020d943-3e7c-468b-b27b-df26e4629de4@github.com> <7Vu4tbsRQ9xlbxSaYIu7iByog6cjzYrGQLH6u8kvI3A=.26c662d1-03a7-44a2-bd72-a2aeff968de0@github.com> Message-ID: On Tue, 20 May 2025 09:39:09 GMT, Daniel Jeli?ski wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Log error and return null no compress/decompress failure > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 424: > >> 422: >> 423: if (pos == null) { >> 424: throw hc.conContext.fatal(Alert.HANDSHAKE_FAILURE, > > I don't think using `fatal` is the right choice here; ideally we should fall back to a full handshake instead. Consider setting invalidated=true instead Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098923061 From wetmore at openjdk.org Tue May 20 22:45:40 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 20 May 2025 22:45:40 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v21] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - Merge branch 'master' into JDK-8341346 - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups - get*() no longer needed, backout error (oops!) - Merge branch 'master' into JDK-8341346 - Updated copyright dates. - Merge branch 'master' into JDK-8341346 - Updated API to include SecretKey type, and a couple minor codereview comments - Merge branch 'master' into JDK-8341346 - Minor Codereview comments. - Codereview comments: updated test to extend from SSLEngineTemplate, API tweaks, couple small bugs - ... and 20 more: https://git.openjdk.org/jdk/compare/cedd1a53...3e28d345 ------------- Changes: https://git.openjdk.org/jdk/pull/24976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=20 Stats: 1018 lines in 9 files changed: 996 ins; 3 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From swen at openjdk.org Tue May 20 22:52:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 22:52:52 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v5] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update after comments src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 952: > 950: // through a byte[] to get to the combined intrinsic > 951: if (NIO_ACCESS.getBufferAddress(src) - srcaddr + src.position() >= > 952: NIO_ACCESS.getBufferAddress(dst) - dstaddr + dst.position()) { Suggestion: if (NIO_ACCESS.getBufferAddress(src) - srcaddr + src.position() >= NIO_ACCESS.getBufferAddress(dst) - dstaddr + dst.position()) { Here you can use the same alignment style as before src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1607: > 1605: Unsafe.getUnsafe().setMemory( > 1606: NIO_ACCESS.getBufferAddress(dst), > 1607: len + dst.position(), (byte) 0); Suggestion: NIO_ACCESS.getBufferAddress(dst), len + dst.position(), (byte) 0); Alignment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098987037 PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098988459 From wetmore at openjdk.org Tue May 20 22:57:22 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 20 May 2025 22:57:22 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v22] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Missed one change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/3e28d345..33baa381 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=20-21 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From swen at openjdk.org Tue May 20 23:02:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 20 May 2025 23:02:52 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v5] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update after comments test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java line 583: > 581: } > 582: default -> throw new InternalError("Should not reach here"); > 583: }; Suggestion: return switch (rand.nextInt(3)) { case 0 -> ByteBuffer.allocateDirect(buf.length) .put(buf) .flip(); case 1 -> ByteBuffer.wrap(buf); case 2 -> Arena.ofAuto() .allocate(buf.length) .asByteBuffer() .put(buf) .flip(); default -> throw new InternalError("Should not reach here"); }; ByteBuffer supports chain programming style, so we can simplify it to this ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2098997233 From sean.mullan at oracle.com Tue May 20 23:10:33 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 20 May 2025 19:10:33 -0400 Subject: Status of TLS 1.3 Hybrid Key Exchange (JDK-8314323) In-Reply-To: References: Message-ID: Hi, Thanks for your message and interest in Java Security. We are currently working on an implementation of Hybrid Key Exchange in TLS 1.3 [1]. It will not be in JDK 25 as the release is entering rampdown phase 1 soon. Although we can't commit to a target release at this time, we hope to deliver it in a timely manner after the RFC has been published. Potential backports will be determined at a later date. --Sean [1] https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ On 5/20/25 4:07 AM, Stian Thorgersen wrote: > Hi, > > I've been trying to find out when OpenJDK will have support for hybrid > key exchange in TLS 1.3. > > I've found the corresponding issue: https://bugs.openjdk.org/browse/ > JDK-8314323 , but not able > to find any information on the status of this work, nor what OpenJDK > releases it targets. > > Is this planned for OpenJDK 25? Are there considerations to back-port to > older releases? From abarashev at openjdk.org Tue May 20 23:41:34 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 20 May 2025 23:41:34 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v3] In-Reply-To: References: Message-ID: <0_Zsb7Xb7ukRn6hoHdMz8G34w-HS0A7scsyx43_CVrU=.8cd22e1a-458e-4518-b463-6abb009781f6@github.com> > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/7c1a25c9..110e601d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=01-02 Stats: 104 lines in 2 files changed: 32 ins; 30 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From wetmore at openjdk.org Tue May 20 23:49:37 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Tue, 20 May 2025 23:49:37 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v23] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Minor bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/33baa381..dae583e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=21-22 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From lmesnik at openjdk.org Tue May 20 23:53:59 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 May 2025 23:53:59 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Added some comments. I haven't find answer an my question about testing. How this fix is tested? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24953#issuecomment-2896080458 From abarashev at openjdk.org Wed May 21 00:18:14 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 21 May 2025 00:18:14 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v4] In-Reply-To: References: Message-ID: <1OkWtPIl7QqILGyzBGsveoilGts6wK24m2iyjmcd39o=.ae3ebf7b-a70d-464e-9015-6dd4cf5cc2d5@github.com> > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: encrypt() should return an empty byte array on failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/110e601d..b27edb95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=02-03 Stats: 37 lines in 1 file changed: 2 ins; 17 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From valeriep at openjdk.org Wed May 21 01:05:52 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 21 May 2025 01:05:52 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v5] In-Reply-To: References: Message-ID: <1EFXzrYvM3fhV_mggScPO3sVnRRfSipz75__819ckZ0=.0c186ff7-e80a-49be-89fd-fe54753ec5a7@github.com> On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update after comments src/java.base/share/classes/sun/nio/ch/Util.java line 2: > 1: /* > 2: * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved. I didn't see src changes in this class? Maybe you meant to update the copyright year for `IOUtil.java`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2099102725 From valeriep at openjdk.org Wed May 21 01:08:55 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 21 May 2025 01:08:55 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v5] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update after comments src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 176: > 174: dst.position(pos + n); > 175: return n; > 176: } finally { nit: extra space before finally? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2099108417 From wetmore at openjdk.org Wed May 21 01:20:35 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 21 May 2025 01:20:35 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v24] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Added PKCS11 testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/dae583e8..c92d1e89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=22-23 Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From duke at openjdk.org Wed May 21 04:43:59 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 21 May 2025 04:43:59 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 23:51:15 GMT, Leonid Mesnik wrote: > I haven't find answer an my question about testing. How this fix is tested? The change in the file test/jdk/sun/security/provider/acvp/Launcher.java in PR https://github.com/openjdk/jdk/pull/23860/files covers this as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24953#issuecomment-2896548094 From valeriep at openjdk.org Wed May 21 05:02:52 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 21 May 2025 05:02:52 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v3] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 13:38:11 GMT, Alan Bateman wrote: > A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment? I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2896582775 From lmesnik at openjdk.org Wed May 21 05:02:58 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 21 May 2025 05:02:58 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v7] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 17:49:14 GMT, Ferenc Rakoczi wrote: >> By using the AVX-512 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled. > > Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision: > > Added some comments. Thanks for pointing to the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24953#issuecomment-2896581694 From djelinski at openjdk.org Wed May 21 06:53:54 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 21 May 2025 06:53:54 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v4] In-Reply-To: <1OkWtPIl7QqILGyzBGsveoilGts6wK24m2iyjmcd39o=.ae3ebf7b-a70d-464e-9015-6dd4cf5cc2d5@github.com> References: <1OkWtPIl7QqILGyzBGsveoilGts6wK24m2iyjmcd39o=.ae3ebf7b-a70d-464e-9015-6dd4cf5cc2d5@github.com> Message-ID: On Wed, 21 May 2025 00:18:14 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > encrypt() should return an empty byte array on failure src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 304: > 302: private static byte[] compress(byte[] input) throws IOException { > 303: ByteArrayOutputStream baos = new ByteArrayOutputStream(); > 304: GZIPOutputStream gos = new GZIPOutputStream(baos); you lost the try-with-resources in your last push; please bring it back. src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 323: > 321: input.get(bytes); > 322: > 323: GZIPInputStream gis = new GZIPInputStream( same here, please restore the try-with-resources ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2099495293 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2099496947 From sthorger at redhat.com Wed May 21 06:56:54 2025 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 May 2025 08:56:54 +0200 Subject: Status of TLS 1.3 Hybrid Key Exchange (JDK-8314323) In-Reply-To: References: Message-ID: Thanks, Are there also plans to add X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 hybrid key agreements from https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/? >From what I know Google, Firefox, CloudFlare, and OpenSSL have all implemented the draft, and there may not be many changes to the RFC once it's been published. Sounds like then potentially we're looking at OpenJDK 26 in march next year? Is there a potential that it would be backported and delivered to OpenJDK 25 earlier than that? On Wed, 21 May 2025 at 01:11, Sean Mullan wrote: > Hi, > > Thanks for your message and interest in Java Security. > > We are currently working on an implementation of Hybrid Key Exchange in > TLS 1.3 [1]. It will not be in JDK 25 as the release is entering > rampdown phase 1 soon. > > Although we can't commit to a target release at this time, we hope to > deliver it in a timely manner after the RFC has been published. > Potential backports will be determined at a later date. > > --Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ > > > On 5/20/25 4:07 AM, Stian Thorgersen wrote: > > Hi, > > > > I've been trying to find out when OpenJDK will have support for hybrid > > key exchange in TLS 1.3. > > > > I've found the corresponding issue: https://bugs.openjdk.org/browse/ > > JDK-8314323 , but not able > > to find any information on the status of this work, nor what OpenJDK > > releases it targets. > > > > Is this planned for OpenJDK 25? Are there considerations to back-port to > > older releases? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Wed May 21 09:14:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 May 2025 09:14:00 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 05:00:16 GMT, Valerie Peng wrote: > > A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment? > > I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed. Thanks for checking. We need to create an issue in JBS for this. It may be a corner case to use these APIs and SPI with buffers that are views on a memory segment but it will happen at some point and would be good to ensure that it is covered by tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2897203363 From pminborg at openjdk.org Wed May 21 13:31:53 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 21 May 2025 13:31:53 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 09:10:57 GMT, Alan Bateman wrote: > > > A question for folks on security-dev. Are there tests for Cipher.doFinal, CipherSpi.engineUpdate, etc. that exercises cases where the ByteBuffer obtained from a memory segment? > > > > > > I don't find any. We'd have to update them to cover the memory segment usage. Judging from the changed sources, general Cipher and SunPKCS11-specific tests update would be needed. > > Thanks for checking. We need to create an issue in JBS for this. It may be a corner case to use these APIs and SPI with buffers that are views on a memory segment but it will happen at some point and would be good to ensure that it is covered by tests. I've created https://bugs.openjdk.org/browse/JDK-8357466. There are some missing fields, I hope someone can fill them in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2897977877 From pminborg at openjdk.org Wed May 21 13:38:12 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 21 May 2025 13:38:12 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v6] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update after comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/6435f777..538147be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=04-05 Stats: 16 lines in 4 files changed: 0 ins; 6 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From sean.mullan at oracle.com Wed May 21 13:40:01 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 21 May 2025 09:40:01 -0400 Subject: Status of TLS 1.3 Hybrid Key Exchange (JDK-8314323) In-Reply-To: References: Message-ID: <5bfc3b93-616d-419f-8ee4-e5ae6ae507d9@oracle.com> On 5/21/25 2:56 AM, Stian Thorgersen wrote: > Thanks, > > Are there also plans to add X25519MLKEM768, SecP256r1MLKEM768, and > SecP384r1MLKEM1024 hybrid key agreements from https:// > datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/>? Yes. > > From what I know Google, Firefox, CloudFlare, and OpenSSL have all > implemented the draft, and there may not be many changes to the RFC once > it's been published. > > Sounds like then potentially we're looking at OpenJDK 26 in march next > year? Is there a potential that it would be backported and delivered to > OpenJDK 25 earlier than that? No, new features like this typically go into a JDK feature release first. --Sean > > On Wed, 21 May 2025 at 01:11, Sean Mullan > wrote: > > Hi, > > Thanks for your message and interest in Java Security. > > We are currently working on an implementation of Hybrid Key Exchange in > TLS 1.3 [1]. It will not be in JDK 25 as the release is entering > rampdown phase 1 soon. > > Although we can't commit to a target release at this time, we hope to > deliver it in a timely manner after the RFC has been published. > Potential backports will be determined at a later date. > > --Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ > > > > On 5/20/25 4:07 AM, Stian Thorgersen wrote: > > Hi, > > > > I've been trying to find out when OpenJDK will have support for > hybrid > > key exchange in TLS 1.3. > > > > I've found the corresponding issue: https://bugs.openjdk.org/ > browse/ > > JDK-8314323 >, but not able > > to find any information on the status of this work, nor what OpenJDK > > releases it targets. > > > > Is this planned for OpenJDK 25? Are there considerations to back- > port to > > older releases? > From pminborg at openjdk.org Wed May 21 13:42:39 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 21 May 2025 13:42:39 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Fix copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/538147be..d6b4233e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From abarashev at openjdk.org Wed May 21 14:40:56 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 21 May 2025 14:40:56 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v4] In-Reply-To: References: <1OkWtPIl7QqILGyzBGsveoilGts6wK24m2iyjmcd39o=.ae3ebf7b-a70d-464e-9015-6dd4cf5cc2d5@github.com> Message-ID: On Wed, 21 May 2025 06:50:28 GMT, Daniel Jeli?ski wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> encrypt() should return an empty byte array on failure > > src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 304: > >> 302: private static byte[] compress(byte[] input) throws IOException { >> 303: ByteArrayOutputStream baos = new ByteArrayOutputStream(); >> 304: GZIPOutputStream gos = new GZIPOutputStream(baos); > > you lost the try-with-resources in your last push; please bring it back. Done, thanks. > src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 323: > >> 321: input.get(bytes); >> 322: >> 323: GZIPInputStream gis = new GZIPInputStream( > > same here, please restore the try-with-resources Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2100468033 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2100468322 From abarashev at openjdk.org Wed May 21 14:48:28 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 21 May 2025 14:48:28 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v5] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Bring back try-with-resources to compress/decompress methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/b27edb95..89ff22c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=03-04 Stats: 27 lines in 1 file changed: 7 ins; 6 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From valeriep at openjdk.org Wed May 21 17:57:53 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 21 May 2025 17:57:53 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 11:01:46 GMT, Per Minborg wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright year > > src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459: > >> 457: >> 458: boolean pending = false; >> 459: NIO_ACCESS.acquireSession(buf); > > Here, we acquire the session *after* we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown. Is there documentation on when sessions should be acquired/released? Is this only for when using MemorySegment? In security area, the bytes are passed to the JNI code which calls the native library to process the bytes and I wonder if sessions should be acquired/released for these. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2100870190 From djelinski at openjdk.org Wed May 21 18:23:55 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 21 May 2025 18:23:55 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v5] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 14:48:28 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Bring back try-with-resources to compress/decompress methods LGTM. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25310#pullrequestreview-2858728538 From vyazici at openjdk.org Wed May 21 21:02:04 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 21 May 2025 21:02:04 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner Message-ID: There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. ### Fixing strategy * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. ### Scanning strategy The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: # Perl is used for multi-line matching find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print git grep -H 'FileDescriptor.in' "*.java" All calls to `InputStreamReader::new` and `Scanner::new` are checked too. ### Problems encountered 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: ``` DOMImplementationRegistry InputRC ListingErrorHandler PandocFilter ``` 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property ------------- Commit messages: - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations Changes: https://git.openjdk.org/jdk/pull/25368/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356893 Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/25368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368 PR: https://git.openjdk.org/jdk/pull/25368 From rriggs at openjdk.org Wed May 21 21:39:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 May 2025 21:39:53 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. > > ### Fixing strategy > > * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. > * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. > * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. > > @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. > > ### Scanning strategy > > The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: > > > # Perl is used for multi-line matching > find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print > git grep -H 'FileDescriptor.in' "*.java" > > > All calls to `InputStreamReader::new` and `Scanner::new` are checked too. > > ### Problems encountered > > 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: > > ``` > DOMImplementationRegistry > InputRC > ListingErrorHandler > PandocFilter > ``` > 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property There too many changes in too many different areas to be in a single PR. Please break it down by review areas. Client, core libs, tools, etc. ------------- PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030 From alanb at openjdk.org Thu May 22 05:54:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 May 2025 05:54:52 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. > > ### Fixing strategy > > * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. > * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. > * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. > > @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. > > ### Scanning strategy > > The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: > > > # Perl is used for multi-line matching > find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print > git grep -H 'FileDescriptor.in' "*.java" > > > All calls to `InputStreamReader::new` and `Scanner::new` are checked too. > > ### Problems encountered > > 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: > > ``` > DOMImplementationRegistry > InputRC > ListingErrorHandler > PandocFilter > ``` > 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property javax.swing.text.DefaultEditorKit.read(InputStream ...) is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`. From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753 From vyazici at openjdk.org Thu May 22 07:59:09 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 22 May 2025 07:59:09 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs wrote: >> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. >> >> ### Fixing strategy >> >> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. >> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. >> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. >> >> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. >> >> ### Scanning strategy >> >> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: >> >> >> # Perl is used for multi-line matching >> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print >> git grep -H 'FileDescriptor.in' "*.java" >> >> >> All calls to `InputStreamReader::new` and `Scanner::new` are checked too. >> >> ### Problems encountered >> >> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: >> >> ``` >> DOMImplementationRegistry >> InputRC >> ListingErrorHandler >> PandocFilter >> ``` >> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property > > There too many changes in too many different areas to be in a single PR. > Please break it down by review areas. Client, core libs, tools, etc. @RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will 1. withdraw this PR, 2. convert certain changes to spec clarifications, 3. and break it down to multiple PRs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422 From vyazici at openjdk.org Thu May 22 07:59:10 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 22 May 2025 07:59:10 GMT Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. > > ### Fixing strategy > > * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. > * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. > * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. > > @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. > > ### Scanning strategy > > The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: > > > # Perl is used for multi-line matching > find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print > git grep -H 'FileDescriptor.in' "*.java" > > > All calls to `InputStreamReader::new` and `Scanner::new` are checked too. > > ### Problems encountered > > 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: > > ``` > DOMImplementationRegistry > InputRC > ListingErrorHandler > PandocFilter > ``` > 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25368 From swen at openjdk.org Thu May 22 09:08:01 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 22 May 2025 09:08:01 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes [v2] In-Reply-To: References: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> Message-ID: On Mon, 14 Apr 2025 14:40:02 GMT, Roger Riggs wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> from @valeriepeng > > Looks ok; but will need to be re-opened. It would seem odd to approve a closed PR. Sorry it took so long to see this, @RogerRiggs @valeriepeng, can you help with re-approval? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23411#issuecomment-2900456856 From aivanov at openjdk.org Thu May 22 10:53:08 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 22 May 2025 10:53:08 GMT Subject: RFR: 8346436: Compilation with clang fails [v2] In-Reply-To: References: <2T1MSOZ5x2Aui8EwMvWvLEXeUGmty5PLl1nuAWSZZ74=.02465712-ad35-48c7-83e9-8e825b92f35a@github.com> Message-ID: On Fri, 3 Jan 2025 09:19:34 GMT, Jan Kratochvil wrote: >> clang-18.1.8-1.fc40.x86_64 >> Fedora 40 x86_64 >> fbd76ca8edd756ff2ebbc9f6477cc1a827df67b0 >> >> >> src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> | ^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:375:9: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 375 | write(splash->controlpipe[1], &code, 1); >> | ^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:713:5: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 713 | pipe(splash->controlpipe); >> | ^~~~ ~~~~~~~~~~~~~~~~~~~ >> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h:45:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined] >> 45 | #define dprintf(s) >> | ^ >> /usr/include/bits/stdio2.h:121:12: note: previous definition is here >> 121 | # define dprintf(fd, ...) \ >> | ^ >> src/java.smartcardio/share/native/libj2pcsc/pcsc.c:48:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined] >> 48 | #define dprintf(s) >> | ^ >> /usr/include/bits/stdio2.h:121:12: note: previous definition is here >> 121 | # define dprintf(fd, ...) \ >> | ^ > > Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use only (void) casts > - Merge branch 'master' into clangbuild > - 8346436: Compilation with clang fails @jankratochvil Seemingly, the same problem is being addressed in #25217 for [JDK-8354316](https://bugs.openjdk.org/browse/JDK-8354316). ------------- PR Comment: https://git.openjdk.org/jdk/pull/22794#issuecomment-2900771105 From myankelevich at openjdk.org Thu May 22 12:27:08 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 22 May 2025 12:27:08 GMT Subject: RFR: 8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase Message-ID: * added an automated mixed case option * using multithreading now * added logs for simpler debug * added missing -Djava.security.auth.debug coverage ------------- Commit messages: - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase Changes: https://git.openjdk.org/jdk/pull/25391/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25391&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357470 Stats: 212 lines in 1 file changed: 130 ins; 4 del; 78 mod Patch: https://git.openjdk.org/jdk/pull/25391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25391/head:pull/25391 PR: https://git.openjdk.org/jdk/pull/25391 From nbenalla at openjdk.org Thu May 22 15:18:43 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 22 May 2025 15:18:43 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v2] In-Reply-To: References: Message-ID: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: revert changes to MethodType.java. foo markup should not be used ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25287/files - new: https://git.openjdk.org/jdk/pull/25287/files/b17b55fa..0653af94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25287/head:pull/25287 PR: https://git.openjdk.org/jdk/pull/25287 From abarashev at openjdk.org Thu May 22 17:21:35 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 22 May 2025 17:21:35 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v6] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Add a unit test. Don't break on checksum mismatch, we may get all the certificates in the end. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/89ff22c8..6c4c8926 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=04-05 Stats: 125 lines in 5 files changed: 41 ins; 18 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From abarashev at openjdk.org Thu May 22 17:52:09 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 22 May 2025 17:52:09 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v7] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Unit test nit: restore original check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/6c4c8926..24d4c523 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From liach at openjdk.org Thu May 22 18:24:51 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 May 2025 18:24:51 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v2] In-Reply-To: References: Message-ID: <2NivjYQr_KiIrdCorX_x68nTNHezBA1qKvhjaDknI1E=.5da267a6-125d-49bf-9de3-4eaf9afbfcd6@github.com> On Thu, 22 May 2025 15:18:43 GMT, Nizar Benalla wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > revert changes to MethodType.java. foo markup should not be used Changes to MethodHandles look good. Please wait for a review from security developers for KEM.java. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2862198182 From abarashev at openjdk.org Thu May 22 18:39:29 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 22 May 2025 18:39:29 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v8] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Unit test: add required module ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/24d4c523..8e4ebeb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=06-07 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From valeriep at openjdk.org Thu May 22 18:57:51 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 22 May 2025 18:57:51 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 13:42:39 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year Security source changes look fine. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25324#pullrequestreview-2862279408 From valeriep at openjdk.org Thu May 22 18:57:52 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 22 May 2025 18:57:52 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 17:55:17 GMT, Valerie Peng wrote: >> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459: >> >>> 457: >>> 458: boolean pending = false; >>> 459: NIO_ACCESS.acquireSession(buf); >> >> Here, we acquire the session *after* we have obtained the address. This is safe as we do not touch the segment before it is acquired. If a segment is deallocated before we try to acquire the session, an exception will be thrown. > > Is there documentation on when sessions should be acquired/released? Is this only for when using MemorySegment? In security area, the bytes are passed to the JNI code which calls the native library to process the bytes and I wonder if sessions should be acquired/released for these. Never mind, I see that there are already acquireSession/releaseSession calls when the ByteBuffer objects are accessed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2103213937 From abarashev at openjdk.org Thu May 22 19:23:22 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 22 May 2025 19:23:22 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v9] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Assume "createPossession" can return more certificates than in the session ticket ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/8e4ebeb6..e724e6da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From wetmore at openjdk.org Thu May 22 20:47:29 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 22 May 2025 20:47:29 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v25] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge branch 'master' into JDK-8341346 - Added PKCS11 testing - Minor bug - Missed one change - Merge branch 'master' into JDK-8341346 - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups - get*() no longer needed, backout error (oops!) - Merge branch 'master' into JDK-8341346 - Updated copyright dates. - Merge branch 'master' into JDK-8341346 - ... and 24 more: https://git.openjdk.org/jdk/compare/139a05d0...e6b563e7 ------------- Changes: https://git.openjdk.org/jdk/pull/24976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=24 Stats: 1023 lines in 9 files changed: 1001 ins; 3 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From abarashev at openjdk.org Thu May 22 20:59:23 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 22 May 2025 20:59:23 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v10] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Make sure we got the exact same cert chain. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/e724e6da..1d99b03e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=08-09 Stats: 18 lines in 1 file changed: 8 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From wetmore at openjdk.org Thu May 22 20:59:23 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 22 May 2025 20:59:23 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v9] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 19:23:22 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Assume "createPossession" can return more certificates than in the session ticket Will have a look at this hopefully later today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25310#issuecomment-2902548217 From prr at openjdk.org Thu May 22 21:28:53 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 22 May 2025 21:28:53 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com> References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com> Message-ID: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com> On Thu, 15 May 2025 12:33:06 GMT, Raffaello Giulietti wrote: >>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files? >> >> That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case. > > FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France): > > - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark. > - U+00A0 (No-Break Space NBSP) preceding colon. > > Similar conventions are used in other French speaking countries. > No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. > This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed the Java unicode escape to UTF-8 for the localised message string. You propose restoring it to Java escape. I wouldn't be surprised if the next message drop reverses what you reversed. I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes since that is very much a Java thing. So you are probably making the translation job harder. So I am suggesting you leave all of the translation files as is. Which might mean withdrawing this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2103421828 From prr at openjdk.org Thu May 22 21:45:52 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 22 May 2025 21:45:52 GMT Subject: RFR: 8356977: UTF-8 cleanups In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie wrote: > I found a few other places in the code that can be cleaned up after the conversion to UTF-8. src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49: > 47: * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by > 48: *

    > 49: * MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false); This is javadoc inJava SE specification. As is the Action case below. I can't think of any actual harm from this change, so OK, but I am not seeing why it is needed. test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63: > 61: > 62: private static final String INSTRUCTIONS = > 63: "A string \u201C" + TEXT + "\u201D is drawn at eight different " I really don't like these tests being changed. It isn't part of the JDK build. People compile these in all sorts of locales. Please revert all the changes in the client tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103439338 PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103431874 From mdonovan at openjdk.org Thu May 22 23:08:24 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 22 May 2025 23:08:24 GMT Subject: RFR: 8357592: Update output parsing in test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java Message-ID: In this PR, I updated the jarsigner compatibility test to handle minor differences in the output of jarsigner between versions. ------------- Commit messages: - 8357592: Update output parsing in test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java Changes: https://git.openjdk.org/jdk/pull/25403/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357592 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25403.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25403/head:pull/25403 PR: https://git.openjdk.org/jdk/pull/25403 From abarashev at openjdk.org Fri May 23 00:03:08 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 23 May 2025 00:03:08 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v11] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Adding a unit test check for certificates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/1d99b03e..52ad4a87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=09-10 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From duke at openjdk.org Fri May 23 04:59:00 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 23 May 2025 04:59:00 GMT Subject: RFR: 8349550: Improve SASL random usage Message-ID: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random ------------- Commit messages: - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random Changes: https://git.openjdk.org/jdk/pull/25241/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25241&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349550 Stats: 24 lines in 2 files changed: 12 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25241/head:pull/25241 PR: https://git.openjdk.org/jdk/pull/25241 From djelinski at openjdk.org Fri May 23 11:17:53 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 23 May 2025 11:17:53 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v11] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 00:03:08 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Adding a unit test check for certificates test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java line 227: > 225: // algorithm to constraints so local certificates > 226: // can't be restored from the session ticket. > 227: params.setAlgorithmConstraints( Isn't this a repeat of the SIGNATURE_SCHEME test above? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2104370447 From myankelevich at openjdk.org Fri May 23 13:02:54 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 23 May 2025 13:02:54 GMT Subject: RFR: 8351566: Consolidate third party artifacts used in tests [v3] In-Reply-To: <_WldHL5Zc68N5B0x4KUpoumcUV2lbgWzSdPZXRBqqYY=.07799f18-3204-4310-8712-c91bd916c165@github.com> References: <_WldHL5Zc68N5B0x4KUpoumcUV2lbgWzSdPZXRBqqYY=.07799f18-3204-4310-8712-c91bd916c165@github.com> Message-ID: <7_ymYowPZ98NCqOmwaAwocqOID5l6b8IdND3ii48J-M=.f542d2ca-114b-4524-aa4d-a95bb52bd4da@github.com> On Thu, 27 Mar 2025 16:55:01 GMT, Mikhail Yankelevich wrote: >> 8351566: Consolidate third party artifacts used in tests > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > Fernando's comments: > > * cleanup still needs a review /keepalive ------------- PR Comment: https://git.openjdk.org/jdk/pull/23988#issuecomment-2904347638 From weijun at openjdk.org Fri May 23 14:31:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 23 May 2025 14:31:52 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v2] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 15:18:43 GMT, Nizar Benalla wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > revert changes to MethodType.java. foo markup should not be used src/java.base/share/classes/javax/crypto/KEM.java line 711: > 709: * with the key encapsulation message so that the receiver is able to create > 710: * a matching decapsulator, it will be included as a byte array in the > 711: * {@link Encapsulated#params()} field inside the encapsulation output. Good catch. The text must have been added before we changed `Encapsulated` from a record to a normal class. Now that `params` is a method instead of a record field, please consider rewriting the sentence to something like it will be included as a byte array returned by the {@link Encapsulated#params()} method within the encapsulation output. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25287#discussion_r2104718909 From nbenalla at openjdk.org Fri May 23 14:59:07 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 23 May 2025 14:59:07 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v3] In-Reply-To: References: Message-ID: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: update javadoc based on feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25287/files - new: https://git.openjdk.org/jdk/pull/25287/files/0653af94..daaed6c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25287&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25287/head:pull/25287 PR: https://git.openjdk.org/jdk/pull/25287 From weijun at openjdk.org Fri May 23 15:06:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 23 May 2025 15:06:52 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 14:59:07 GMT, Nizar Benalla wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > update javadoc based on feedback The `KEM.java` change looks good to me. Thanks. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25287#pullrequestreview-2864755280 From abarashev at openjdk.org Fri May 23 15:57:55 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 23 May 2025 15:57:55 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v11] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 11:15:38 GMT, Daniel Jeli?ski wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding a unit test check for certificates > > test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java line 227: > >> 225: // algorithm to constraints so local certificates >> 226: // can't be restored from the session ticket. >> 227: params.setAlgorithmConstraints( > > Isn't this a repeat of the SIGNATURE_SCHEME test above? Hi Daniel! 1. You can see that I've modified `ResumeChecksServer` SIGNATURE_SCHEME case to block signature scheme names specifically, not algorithm names like before. This test case was created for [this check](https://github.com/openjdk/jdk/blob/48df41b6997cfe2c8aa3bc46ea25eff01f615d31/src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java#L468) which was done as part of [JDK-8206929](https://bugs.openjdk.org/browse/JDK-8206929) and that's the reason I've kept `localSupportedSignAlgs` in the session ticket. 2. About LOCAL_CERTS case I've added: it blocks initial session's certificate signature algorithm specifically so it's not returned with the new possession when we restore the session. You can comment out all the other cases from ResumeChecksServerStateless.java and run just LOCAL_CERTS case with `-Djavax.net.debug=ssl` option and observe `Local certificates can not be restored` message in the logs. I also ran this test under debugger to confirm things. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2104889778 From ascarpino at openjdk.org Fri May 23 16:05:56 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 23 May 2025 16:05:56 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v11] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 00:03:08 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Adding a unit test check for certificates Contingent on @djelinski comment resolution, I think the changes looks good ------------- Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25310#pullrequestreview-2864941967 From rriggs at openjdk.org Fri May 23 16:13:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 23 May 2025 16:13:56 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes [v2] In-Reply-To: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> References: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> Message-ID: <_QHlP9v4XMufZQYHJyTUD7iNo-ZGcHJUymt8NWLjh84=.b752a274-6d6f-40f1-a0de-df2f50f5c3af@github.com> On Sat, 5 Apr 2025 01:30:49 GMT, Shaojin Wen wrote: >> During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10 anonymous classes, which slows down the startup. This PR is to improve KnownOIDs and eliminate unnecessary embedded classes. >> >> >> Here's how to reproduce this: >> >> >> public class Startup { >> public static void main(String[] args) {} >> } >> >> >> >> java -verbose:class Startup >> >> >> >> [0.665s][info][class,load] sun.security.util.KnownOIDs >> [0.666s][info][class,load] sun.security.util.KnownOIDs$1 >> [0.667s][info][class,load] sun.security.util.KnownOIDs$2 >> [0.667s][info][class,load] sun.security.util.KnownOIDs$3 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$4 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$5 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$6 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$7 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$8 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$9 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$10 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @valeriepeng A reasonable change to reduce the number of classes generated independent of any potential to improve startup in some modes. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23411#pullrequestreview-2864968689 From djelinski at openjdk.org Fri May 23 18:00:52 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 23 May 2025 18:00:52 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v11] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 00:03:08 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Adding a unit test check for certificates LGTM. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25310#pullrequestreview-2865302308 From djelinski at openjdk.org Fri May 23 18:00:54 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 23 May 2025 18:00:54 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v11] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 15:54:59 GMT, Artur Barashev wrote: >> test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java line 227: >> >>> 225: // algorithm to constraints so local certificates >>> 226: // can't be restored from the session ticket. >>> 227: params.setAlgorithmConstraints( >> >> Isn't this a repeat of the SIGNATURE_SCHEME test above? > > Hi Daniel! > > 1. You can see that I've modified `ResumeChecksServer` SIGNATURE_SCHEME case to block signature scheme names specifically, not algorithm names like before. This test case was created for [this check](https://github.com/openjdk/jdk/blob/48df41b6997cfe2c8aa3bc46ea25eff01f615d31/src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java#L468) which was done as part of [JDK-8206929](https://bugs.openjdk.org/browse/JDK-8206929) and that's the reason I've kept `localSupportedSignAlgs` in the session ticket. > 2. About LOCAL_CERTS case I've added: it blocks initial session's certificate signature algorithm specifically so it's not returned with the new possession when we restore the session. You can comment out all the other cases from ResumeChecksServerStateless.java and run just LOCAL_CERTS case with `-Djavax.net.debug=ssl` option and observe `Local certificates can not be restored` message in the logs. I also ran this test under debugger to confirm things. Thanks for the explanation! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2105178575 From weijun at openjdk.org Fri May 23 18:49:11 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 23 May 2025 18:49:11 GMT Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid include/includedir directives after sections Message-ID: Several changes are made: 1. The "include" and "includedir" directives can appear everywhere, even inside a section or a sub-section. However, it only means the content is inserted here but the included file still need its own full structure -- from section to subsections. 2. The same file can be included multiple times as long as not recursively. 3. Everything is merged. For duplicated values, `get` returns the first one and `getAll` returns all joining by spaces. Two new tests added. I also separately confirmed that they are parsed in the same way as [MIT krb5](https://github.com/krb5/krb5/blob/master/src/util/profile/test_parse.c). MIT krb5 ignores directory name after "include" but here it's an error. ------------- Commit messages: - remove exe bits - the fix Changes: https://git.openjdk.org/jdk/pull/25421/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25421&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356997 Stats: 434 lines in 3 files changed: 318 ins; 49 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/25421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25421/head:pull/25421 PR: https://git.openjdk.org/jdk/pull/25421 From ascarpino at openjdk.org Fri May 23 19:47:01 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 23 May 2025 19:47:01 GMT Subject: RFR: 8298420: PEM API: Implementation (Preview) [v23] In-Reply-To: References: Message-ID: > Hi all, > > I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK24 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. > > Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision: - test updates - comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17543/files - new: https://git.openjdk.org/jdk/pull/17543/files/397d0cbd..8a07c3c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=21-22 Stats: 253 lines in 10 files changed: 129 ins; 84 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/17543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543 PR: https://git.openjdk.org/jdk/pull/17543 From abarashev at openjdk.org Fri May 23 21:15:06 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 23 May 2025 21:15:06 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v12] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Remove unused imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/52ad4a87..d2367d76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=10-11 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From wetmore at openjdk.org Fri May 23 21:23:04 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 23 May 2025 21:23:04 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v26] In-Reply-To: References: Message-ID: <-dPDZBm7dtwx9glzUlXRPZH9VFjHXYZWCQFVX01goZg=.95c342bb-56c7-4a28-befc-7cdc85460aa0@github.com> > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: - Remove TlsExporterKeyingMaterial for now. Can add later if needed. - Merge branch 'master' into JDK-8341346 - Merge branch 'master' into JDK-8341346 - Added PKCS11 testing - Minor bug - Missed one change - Merge branch 'master' into JDK-8341346 - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups - get*() no longer needed, backout error (oops!) - Merge branch 'master' into JDK-8341346 - ... and 26 more: https://git.openjdk.org/jdk/compare/66747710...67480e99 ------------- Changes: https://git.openjdk.org/jdk/pull/24976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=25 Stats: 1022 lines in 9 files changed: 1000 ins; 3 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From wetmore at openjdk.org Sat May 24 04:48:59 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 24 May 2025 04:48:59 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v12] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 21:15:06 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused imports Still working through this, just one tiny nit so far. I still have to look through `SSLSessionImpl.java` @ascarpino might want a look over this, he did much of this code. ------------- PR Review: https://git.openjdk.org/jdk/pull/25310#pullrequestreview-2865155582 From wetmore at openjdk.org Sat May 24 04:49:00 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Sat, 24 May 2025 04:49:00 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v11] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 00:03:08 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Adding a unit test check for certificates src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 261: > 259: > 260: /** > 261: * Re-assemble new session ticket. One word. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2105078446 From sebastian.stenzel at gmail.com Sat May 24 09:40:11 2025 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Sat, 24 May 2025 11:40:11 +0200 Subject: X-Wing KEM Message-ID: Hi all, For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing. As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs. All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec? Alternatively, can we make the two mentioned APIs public? Cheers! Sebastian [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/ [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07 [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Mon May 26 07:35:18 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 07:35:18 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 13:42:39 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 169: > 167: int rem = (pos <= lim ? lim - pos : 0); > 168: > 169: if (dst instanceof sun.nio.ch.DirectBuffer) { I assume this can be changed to test dst.isDirect() now and avoid the explicit cross package dependency. src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 41: > 39: import jdk.internal.invoke.MhUtil; > 40: > 41: import static sun.nio.ch.Util.NIO_ACCESS; I assume this is left over from a previous iteration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106733233 PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106735489 From ihse at openjdk.org Mon May 26 07:47:02 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 07:47:02 GMT Subject: RFR: 8356977: UTF-8 cleanups In-Reply-To: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com> References: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com> Message-ID: On Thu, 15 May 2025 18:30:28 GMT, Naoto Sato wrote: >> I found a few other places in the code that can be cleaned up after the conversion to UTF-8. > > test/jdk/sun/text/resources/LocaleDataTest.java line 106: > >> 104: * FormatData/fr_FR/MonthNames/0=janvier >> 105: * FormatData/fr_FR/MonthNames/1=f?vrier >> 106: * LocaleNames/fr_FR/US=?tats-Unis > > This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct. ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160 From alanb at openjdk.org Mon May 26 08:16:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 08:16:09 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 13:42:39 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459: > 457: > 458: boolean pending = false; > 459: IOUtil.acquireScope(buf, true); Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true. test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java line 575: > 573: case 2 -> Arena.ofAuto().allocate(buf.length).asByteBuffer() > 574: .put(buf) > 575: .flip(); I wonder if we could extend this to test with a shared arena too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106767298 PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106771546 From ihse at openjdk.org Mon May 26 08:20:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:20:19 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: Message-ID: > I found a few other places in the code that can be cleaned up after the conversion to UTF-8. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Restore MenuShortcut.java - Restore LocaleDataTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25228/files - new: https://git.openjdk.org/jdk/pull/25228/files/9c904992..7184e685 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228 PR: https://git.openjdk.org/jdk/pull/25228 From ihse at openjdk.org Mon May 26 08:20:46 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:20:46 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: Message-ID: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com> On Thu, 22 May 2025 21:43:20 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Restore MenuShortcut.java >> - Restore LocaleDataTest.java > > src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49: > >> 47: * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by >> 48: *

    >> 49: * MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false); > > This is javadoc inJava SE specification. As is the Action case below. > I can't think of any actual harm from this change, so OK, but I am not seeing why it is needed. The resulting Javadoc html files will contain the same character before and after this fix, so there is no specification change. I did this since I thought it increased readability of the source code, but I can just as well revert it. > test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63: > >> 61: >> 62: private static final String INSTRUCTIONS = >> 63: "A string \u201C" + TEXT + "\u201D is drawn at eight different " > > I really don't like these tests being changed. It isn't part of the JDK build. > People compile these in all sorts of locales. > Please revert all the changes in the client tests. Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then. The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it? Let me know if you still want me to revert it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106769659 PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106791184 From ihse at openjdk.org Mon May 26 08:21:16 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:21:16 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: Message-ID: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com> On Mon, 26 May 2025 08:10:19 GMT, Magnus Ihse Bursie wrote: >> I found a few other places in the code that can be cleaned up after the conversion to UTF-8. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Restore MenuShortcut.java > - Restore LocaleDataTest.java test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90: > 88: printKey(e); > 89: int keychar = e.getKeyChar(); > 90: if (keychar == 27) { // Escape character is 27 or \u001b @prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it? test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188: > 186: + "\"After\" lists.\n" > 187: + " Added printers are highlighted with " > 188: + "green color, removed ones \u2014 with " @prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error. Do you still want me to revert it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106774492 PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106778974 From ihse at openjdk.org Mon May 26 08:24:36 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:24:36 GMT Subject: RFR: 8356980: Better handling of non-breaking space In-Reply-To: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com> References: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com> <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com> <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com> Message-ID: On Thu, 22 May 2025 21:26:08 GMT, Phil Race wrote: >> FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France): >> >> - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark. >> - U+00A0 (No-Break Space NBSP) preceding colon. >> >> Similar conventions are used in other French speaking countries. > >> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences. > >> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space. > > > I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed > > the Java unicode escape to UTF-8 for the localised message string. > > You propose restoring it to Java escape. > > > I wouldn't be surprised if the next message drop reverses what you reversed. > > I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes > > since that is very much a Java thing. So you are probably making the translation job harder. > > > So I am suggesting you leave all of the translation files as is. > Which might mean withdrawing this PR. Fair enough. This was meant to be an improvement in readability, not a hindrance for working efficiently. I'll withdraw this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2106804794 From ihse at openjdk.org Mon May 26 08:24:38 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 08:24:38 GMT Subject: Withdrawn: 8356980: Better handling of non-breaking space In-Reply-To: References: Message-ID: On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie wrote: > Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences. > > I have checked: > * U+00A0 NO-BREAK SPACE (NBSP) > * U+202F NARROW NO-BREAK SPACE (NNBSP) > * U+2007 FIGURE SPACE > * U+2060 WORD JOINER > > In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25234 From michaelm at openjdk.org Mon May 26 10:31:39 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 26 May 2025 10:31:39 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Merge branch 'master' into 8348986-exceptions - update - reduced number of new categories - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Review update - review update - Merge branch 'master' into 8348986-exceptions - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 ------------- Changes: https://git.openjdk.org/jdk/pull/23929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=10 Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From dfuchs at openjdk.org Mon May 26 11:33:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 May 2025 11:33:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2868122303 From nbenalla at openjdk.org Mon May 26 12:44:01 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 26 May 2025 12:44:01 GMT Subject: RFR: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base [v3] In-Reply-To: References: Message-ID: On Fri, 23 May 2025 14:59:07 GMT, Nizar Benalla wrote: >> Please review this patch to fix some `javadoc` bugs in `java.base`. >> Certain `@link` tags used to refer to private fields instead of public APIs. >> >> A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: > > update javadoc based on feedback All files have been reviewed. Thanks All! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25287#issuecomment-2909611326 From nbenalla at openjdk.org Mon May 26 12:44:01 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 26 May 2025 12:44:01 GMT Subject: Integrated: 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base In-Reply-To: References: Message-ID: On Sat, 17 May 2025 19:42:39 GMT, Nizar Benalla wrote: > Please review this patch to fix some `javadoc` bugs in `java.base`. > Certain `@link` tags used to refer to private fields instead of public APIs. > > A couple of `@see` tags in the [serialization page](https://download.java.net/java/early_access/jdk25/docs/api/serialized-form.html#java.lang.invoke.MethodType) referred to private methods, I updated the javadoc in a way to not change the way it is displayed to users but also remove `@link` tags to non-included types. > > TIA This pull request has now been integrated. Changeset: bd095896 Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/bd095896dd6e3fccb932f3d9823008766e9ab18d Stats: 12 lines in 5 files changed: 0 ins; 0 del; 12 mod 8356632: Fix remaining {@link/@linkplain} tags with refer to private/protected types in java.base Reviewed-by: weijun, liach ------------- PR: https://git.openjdk.org/jdk/pull/25287 From pminborg at openjdk.org Mon May 26 12:50:54 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 26 May 2025 12:50:54 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 07:51:32 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright year > > src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459: > >> 457: >> 458: boolean pending = false; >> 459: IOUtil.acquireScope(buf, true); > > Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true. WASCI is using acquireScopes (plural) and this delegates to aquireScope(.., async=true). So, looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2107273542 From duke at openjdk.org Mon May 26 13:05:01 2025 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 26 May 2025 13:05:01 GMT Subject: RFR: 8351412: Add AVX-512 intrinsics for ML-KEM [v7] In-Reply-To: <0ZhaH_07oxLDZxz8wVEgbsbYWB50sjuLZxYwyM4ftno=.2adb899d-7768-481d-975b-8e0ee3e6f2c2@github.com> References: <0ZhaH_07oxLDZxz8wVEgbsbYWB50sjuLZxYwyM4ftno=.2adb899d-7768-481d-975b-8e0ee3e6f2c2@github.com> Message-ID: <4Uc0-fOqIFIS5GFYXPTC6xp0WtcKrj9XNn_OEkl1N_I=.0ad95f85-4674-4ca3-a602-a965b97b699c@github.com> On Tue, 20 May 2025 19:10:45 GMT, Sean Mullan wrote: > Please also write a release note as the performance improvement is significant. Thanks! Done. https://bugs.openjdk.org/browse/JDK-8357741 Release Note: ML-KEM Performance Improved ------------- PR Comment: https://git.openjdk.org/jdk/pull/24953#issuecomment-2909684771 From pminborg at openjdk.org Mon May 26 14:22:10 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 26 May 2025 14:22:10 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v8] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/d6b4233e..ec233e0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=06-07 Stats: 10 lines in 3 files changed: 3 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From alanb at openjdk.org Mon May 26 15:53:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 15:53:57 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 12:47:55 GMT, Per Minborg wrote: >> src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459: >> >>> 457: >>> 458: boolean pending = false; >>> 459: IOUtil.acquireScope(buf, true); >> >> Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true. > > WASCI is using acquireScopes (plural) and this delegates to aquireScope(.., async=true). So, looks good. Good, thanks for checking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2107592606 From alanb at openjdk.org Mon May 26 16:07:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 16:07:54 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v8] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 14:22:10 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Address comments src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 669: > 667: > 668: } finally { > 669: IOUtil.releaseScope(buf); I don't think we can release here when there is an I/O pending. I suspect it will need to go into releaseBufferIfSubstituted. TBH, I think the change to Windows implementation of AsynchronousFileChannel are going to take more eyes and significant testing. What would you think about dropping it from this PR and creating a separate JBS issue as this is going to require more cycles that everything else in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2107608913 From msheppar at openjdk.org Mon May 26 17:10:54 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 17:10:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved. new file => copyright ? Copyright (c) 2025, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107664521 From msheppar at openjdk.org Mon May 26 17:31:54 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 17:31:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 130: > 128: public abstract String output(); > 129: > 130: protected String output(boolean enhance) { to help us simple folk getting into a tizzy over a public abstract and a protected method of the same name and overloaded to boot suggest refactor rename this method name to composeFilteredMessageText or composeFilteredText or just compose ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107682303 From msheppar at openjdk.org Mon May 26 17:42:59 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 17:42:59 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 58: > 56: * public static SensitiveInfo filterUserName(String name) > 57: */ > 58: public final class Exceptions { maybe a refactor rename to convey some of the semantics of the class e.g. ExceptionMessageFilter ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107691017 From msheppar at openjdk.org Mon May 26 18:15:56 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 18:15:56 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/java/net/HostPortrange.java line 73: > 71: > 72: // first separate string into two fields: hoststr, portstr > 73: String hoststr = null, portstr = null; you could take the opportunity to update the HostPortrange constructor signature refactor rename the parameter str to hostname ;-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107715671 From msheppar at openjdk.org Mon May 26 19:09:53 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 19:09:53 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253: > 251: return; > 252: enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo"); > 253: enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket") This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket. Consider the following: includeInException specifies the type of information that maybe included in an enhanced exception e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All This defines an information policy developer are familiar with packages, so a second property specified the "domain" of application of an information policy: enhancedException.packages specifies a list of packages where the includeInException information policy will apply an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107759746 From alanb at openjdk.org Mon May 26 19:25:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 May 2025 19:25:00 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> References: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> Message-ID: On Mon, 26 May 2025 19:06:56 GMT, Mark Sheppard wrote: >> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' into 8348986-exceptions >> - update >> - reduced number of new categories >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Review update >> - review update >> - Merge branch 'master' into 8348986-exceptions >> - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 > > src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253: > >> 251: return; >> 252: enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo"); >> 253: enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket") > > This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket. > > Consider the following: > includeInException specifies the type of information that maybe included in an enhanced exception > e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All > This defines an information policy > > developer are familiar with packages, so a second property specified the "domain" of application of an information policy: enhancedException.packages specifies a list of packages where the includeInException information policy will apply > > an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages > This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket. I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo". It does mean repurposing the name but it's a good name going forward. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107784068 From msheppar at openjdk.org Mon May 26 20:42:54 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 20:42:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - review update > - Merge branch 'master' into 8348986-exceptions > - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt a builder pattern for the creation of the filter exceptions, for example FilteredExceptionBuilder / EnhancedExceptionBuilder. It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder. EnhancedExceptionBuilder::class() ::exceptionMessage() ::port() ::hostname() ::userDetails() ::filterPolicy() ------------- PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2910598238 From msheppar at openjdk.org Mon May 26 21:46:52 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 26 May 2025 21:46:52 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> Message-ID: On Mon, 26 May 2025 19:22:39 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253: >> >>> 251: return; >>> 252: enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo"); >>> 253: enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket") >> >> This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket. >> >> Consider the following: >> includeInException specifies the type of information that maybe included in an enhanced exception >> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All >> This defines an information policy >> >> developer are familiar with packages, so a second property specified the "domain" of application of an information policy: enhancedException.packages specifies a list of packages where the includeInException information policy will apply >> >> an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages > >> This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket. > > I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo". It does mean repurposing the name but it's a good name going forward. The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used. But equally the setting hostInfoExclSocket suggests some knowledge of APIs is available, so there is a contradiction in the rationale presented above Also the setting enhancedNonSocketExceptionText is inclusive of the setting enhancedSocketExceptionText, which adds further subtleties to the configuration, which was previously suggested should be avoided. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107873149 From alanb at openjdk.org Tue May 27 06:12:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 May 2025 06:12:53 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: <3XYJkgY0zVwUc9rvAIMj50esBiwiMpH9Gv2NzppmP6c=.2f87e51c-8d0a-4e47-a549-af5f4cc1fbec@github.com> Message-ID: On Mon, 26 May 2025 21:44:32 GMT, Mark Sheppard wrote: > The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used. Right, what is now "hostInfoExclSocket" is a confusing category and not easy to explain to anyone. However it is the long standing default. If you relax the default then security people will complain. If you make it more strict then developers will complain as it makes troubleshooting harder. With the current proposal then nobody has to deal with this confusing named category. Instead, if you want reveal more exceptions then you run with the property set to hostInfo, a category that is much simpler to understand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2108262111 From pminborg at openjdk.org Tue May 27 11:23:55 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 11:23:55 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v8] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 16:05:13 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments > > src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 669: > >> 667: >> 668: } finally { >> 669: IOUtil.releaseScope(buf); > > I don't think we can release here when there is an I/O pending. I suspect it will need to go into releaseBufferIfSubstituted. > > TBH, I think the change to Windows implementation of AsynchronousFileChannel are going to take more eyes and significant testing. What would you think about dropping it from this PR and creating a separate JBS issue as this is going to require more cycles that everything else in this PR. Sounds like a good idea: https://bugs.openjdk.org/browse/JDK-8357847 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2108922601 From pminborg at openjdk.org Tue May 27 11:28:42 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 11:28:42 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v9] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Revert copyright year - Revoke changes in WAFCI ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/ec233e0c..c2a901b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=07-08 Stats: 12 lines in 1 file changed: 0 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From pminborg at openjdk.org Tue May 27 11:50:14 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 11:50:14 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v10] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg 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 13 additional commits since the last revision: - Merge branch 'master' into jdk-segment-access - Revert copyright year - Revoke changes in WAFCI - Address comments - Fix copyright year - Update after comments - Update after comments - Add tests - Clean up - Revoke changes in classes that is always using DirectBuffer - ... and 3 more: https://git.openjdk.org/jdk/compare/ede001e6...1eb284df ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/c2a901b3..1eb284df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=08-09 Stats: 57006 lines in 826 files changed: 38176 ins; 13844 del; 4986 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From alanb at openjdk.org Tue May 27 12:46:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 May 2025 12:46:57 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v10] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 11:50:14 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg 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 13 additional commits since the last revision: > > - Merge branch 'master' into jdk-segment-access > - Revert copyright year > - Revoke changes in WAFCI > - Address comments > - Fix copyright year > - Update after comments > - Update after comments > - Add tests > - Clean up > - Revoke changes in classes that is always using DirectBuffer > - ... and 3 more: https://git.openjdk.org/jdk/compare/5abc863c...1eb284df Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25324#pullrequestreview-2870926691 From pminborg at openjdk.org Tue May 27 12:49:56 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 12:49:56 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v10] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 11:50:14 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg 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 13 additional commits since the last revision: > > - Merge branch 'master' into jdk-segment-access > - Revert copyright year > - Revoke changes in WAFCI > - Address comments > - Fix copyright year > - Update after comments > - Update after comments > - Add tests > - Clean up > - Revoke changes in classes that is always using DirectBuffer > - ... and 3 more: https://git.openjdk.org/jdk/compare/ca90399f...1eb284df I am reverting to 1 reviewer, as we have removed the asynchronous Windows class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25324#issuecomment-2912390902 From pminborg at openjdk.org Tue May 27 13:01:09 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 13:01:09 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v11] In-Reply-To: References: Message-ID: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Revert changes in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25324/files - new: https://git.openjdk.org/jdk/pull/25324/files/1eb284df..dcb67a79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25324&range=09-10 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25324/head:pull/25324 PR: https://git.openjdk.org/jdk/pull/25324 From alanb at openjdk.org Tue May 27 13:09:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 May 2025 13:09:52 GMT Subject: RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v11] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 13:01:09 GMT, Per Minborg wrote: >> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 >> >> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes in test Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25324#pullrequestreview-2871010526 From abarashev at openjdk.org Tue May 27 13:14:53 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 27 May 2025 13:14:53 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v11] In-Reply-To: References: Message-ID: <5uOOmlCzfFX7kk21x95c-JyYrtMkkDbhPXq0G8yai-8=.690ce156-a340-40c5-8f17-94ba11d98b10@github.com> On Fri, 23 May 2025 17:17:23 GMT, Bradford Wetmore wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding a unit test check for certificates > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 261: > >> 259: >> 260: /** >> 261: * Re-assemble new session ticket. > > One word. Done, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2109156892 From abarashev at openjdk.org Tue May 27 14:00:07 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 27 May 2025 14:00:07 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v13] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Update comments. Optimize imports. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/d2367d76..0f745465 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=11-12 Stats: 14 lines in 1 file changed: 5 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From naoto at openjdk.org Tue May 27 16:37:56 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 May 2025 16:37:56 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com> Message-ID: On Mon, 26 May 2025 07:44:30 GMT, Magnus Ihse Bursie wrote: >> test/jdk/sun/text/resources/LocaleDataTest.java line 106: >> >>> 104: * FormatData/fr_FR/MonthNames/0=janvier >>> 105: * FormatData/fr_FR/MonthNames/1=f?vrier >>> 106: * LocaleNames/fr_FR/US=?tats-Unis >> >> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct. > > ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. > > However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8. Thanks. Filed an issue to change the encoding in the test to UTF-8: https://bugs.openjdk.org/browse/JDK-8357882 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2109668481 From ascarpino at openjdk.org Tue May 27 19:13:16 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Tue, 27 May 2025 19:13:16 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v21] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 14:57:53 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits: >> >> - merge in JEP 513 >> - Merge branch 'master' into pem >> - comments >> - comments >> - comments >> - comments on the 11th >> - comments on the 11th >> - comments >> - toString update >> - non-sealed >> Better X509 KeyPair parsing >> - ... and 66 more: https://git.openjdk.org/jdk/compare/5e50a584...8bf36d6b > > src/java.base/share/classes/java/security/PEMDecoder.java line 55: > >> 53: * type and implements {@link DEREncodable}. >> 54: * >> 55: * The following lists the supported PEM types and the {@code DEREncodable} > > The list seems too early before introducing the decode-with-class methods. This is where the other list was that showed the PEM types. This is a good spot when talking about cryptographic objects and how them and PEMRecord relate > src/java.base/share/classes/java/security/PEMDecoder.java line 64: > >> 62: *

  • PRIVATE KEY : {@code PrivateKey}
    • >> 63: *
  • PRIVATE KEY : {@code PKCS8EncodedKeySpec} (Only supported when passed as a {@code Class} parameter)
    • >> 64: *
  • PRIVATE KEY : {@code KeyPair} (if the encoding also contains a public key)
    • > > In a later paragraph you talk about reading `PublicKey` from a `PRIVATE KEY` if it is 2.0 and contains the public key. How about merging that info into this list? I want to keep the table simple. > src/java.base/share/classes/java/security/PEMDecoder.java line 121: > >> 119: * } >> 120: * >> 121: * @implNote An implementation may support other PEM types and DEREncodables. > > Have you considered moving the whole decoding list above into this `@implNote`? Same question with the encoder side. The list is part of the spec and needs to not be in the note ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091770646 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091767753 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2091772197 From pminborg at openjdk.org Tue May 27 19:14:05 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 27 May 2025 19:14:05 GMT Subject: Integrated: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() In-Reply-To: References: Message-ID: On Tue, 20 May 2025 10:51:13 GMT, Per Minborg wrote: > This PR proposes to use `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321 > > This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations. This pull request has now been integrated. Changeset: d4b923d1 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/d4b923d175b07e39ee8ee2c79f04457ea1cfbdd0 Stats: 78 lines in 14 files changed: 17 ins; 0 del; 61 mod 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() Reviewed-by: alanb, valeriep ------------- PR: https://git.openjdk.org/jdk/pull/25324 From ascarpino at openjdk.org Tue May 27 23:00:59 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Tue, 27 May 2025 23:00:59 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v24] In-Reply-To: References: Message-ID: > Hi all, > > I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK25 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. > > Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: PEM reading tweak ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17543/files - new: https://git.openjdk.org/jdk/pull/17543/files/8a07c3c5..fdeaa93f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=22-23 Stats: 27 lines in 3 files changed: 23 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17543.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543 PR: https://git.openjdk.org/jdk/pull/17543 From abarashev at openjdk.org Tue May 27 23:40:54 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 27 May 2025 23:40:54 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v26] In-Reply-To: <-dPDZBm7dtwx9glzUlXRPZH9VFjHXYZWCQFVX01goZg=.95c342bb-56c7-4a28-befc-7cdc85460aa0@github.com> References: <-dPDZBm7dtwx9glzUlXRPZH9VFjHXYZWCQFVX01goZg=.95c342bb-56c7-4a28-befc-7cdc85460aa0@github.com> Message-ID: On Fri, 23 May 2025 21:23:04 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: > > - Remove TlsExporterKeyingMaterial for now. Can add later if needed. > - Merge branch 'master' into JDK-8341346 > - Merge branch 'master' into JDK-8341346 > - Added PKCS11 testing > - Minor bug > - Missed one change > - Merge branch 'master' into JDK-8341346 > - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups > - get*() no longer needed, backout error (oops!) > - Merge branch 'master' into JDK-8341346 > - ... and 26 more: https://git.openjdk.org/jdk/compare/66747710...67480e99 src/java.base/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java line 1: > 1: /* Not related to this PR, but `engineGenerateKey0` method should be `protected` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2110533393 From duke at openjdk.org Wed May 28 03:18:12 2025 From: duke at openjdk.org (Krushna948) Date: Wed, 28 May 2025 03:18:12 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v22] In-Reply-To: <2k0yLU-Vny8aqXR1Y81pQKoKUOV8wh7BIa08drUg9CQ=.b1567dde-086e-4999-b27b-a9c76a0b8936@github.com> References: <2k0yLU-Vny8aqXR1Y81pQKoKUOV8wh7BIa08drUg9CQ=.b1567dde-086e-4999-b27b-a9c76a0b8936@github.com> Message-ID: On Fri, 16 May 2025 08:34:46 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK25 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision: > > - comments > - comments > - fix EKS error after JEP 513 src/java.base/share/classes/java/security/PEMDecoder.java line 90: > 88: * decoded into a {@code PEMRecord} by specifying {@code PEMRecord.class}. > 89: * If the Class parameter doesn't match the PEM content, an > 90: * {@code IllegalArgumentException} will be thrown. Looks a Typo, it supposed to be ClassCastException? src/java.base/share/classes/java/security/PEMDecoder.java line 485: > 483: * Any errors using the {@code Provider} will occur during decoding. > 484: * > 485: *

    If {@code provider} is {@code null}, a new instance is returned with May this needs to be updated as below @throws NullPointerException if {@code provider} is null src/java.base/share/classes/java/security/PEMRecord.java line 56: > 54: * @param type the type identifier in the PEM header without PEM syntax labels. > 55: * For a public key, {@code type} would be "PUBLIC KEY". > 56: * @param pem any data between the PEM header and footer. Here 'pem' - any data between the PEM header and footer. But the constructor description below for both the constructors "pem the Base64-encoded data encapsulated by the PEM header and footer" Observation If I pass the data between PEM header and footer, the PEMRecord created successfully. If I include Header and Footer For eg as pem string, "-----BEGIN PUBLIC KEY-----\n" + "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDGRGrflwdiorIrC02pmr0jAKXI\n" + "qxbBHxMUslLg8bjJiJCbanW7g7j7fR3RwGVU0cWh8rsQ/y4U7Yy0gBAsWCrr/TDS\n" + "Xf3RWiZbQiQo6brZFiFZ5WgWgTpuzxDKpzLjyXCe17FXgbgEYscRPB/Rff6q2OS4\n" + "H6stY3fHctzmU1HmUQIDAQAB\n" + "-----END PUBLIC KEY-----"; PEMRecord creation throws java.lang.IllegalArgumentException: Illegal footer: Looks some inconsistency in documentation/ behavior src/java.base/share/classes/java/security/PEMRecord.java line 111: > 109: * {@code null}. > 110: */ > 111: public PEMRecord(String type, String pem) { Observed that PEMRecord.pem returns a string with out Header and footer and removing all the new line characters from input, do we need to specify that the result string filters out the new line characters? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2102389129 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2102480589 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2099618942 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2099642178 From duke at openjdk.org Wed May 28 03:18:13 2025 From: duke at openjdk.org (Krushna948) Date: Wed, 28 May 2025 03:18:13 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v20] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 15:59:25 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/java/security/PEMDecoder.java line 456: >> >>> 454: >>> 455: /** >>> 456: * Returns a copy of this {@code PEMDecoder} instance that uses >> >> Why use "a copy"? Do you mean the password is kept? > > If this instance was configured with decryption, this method will return a new instance configured with decryption and the factory provider. I use "a copy" so the user knows they are adding a new configuration and this instance is staying the same It's little confusing Returns a copy here, and @return a new PEMEncoder instance configured to the {@code Provider}. Technically it's a new instance by any means ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2102421219 From duke at openjdk.org Wed May 28 04:50:39 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Wed, 28 May 2025 04:50:39 GMT Subject: RFR: 8349550: Improve SASL random usage [v2] In-Reply-To: References: Message-ID: > Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25241/files - new: https://git.openjdk.org/jdk/pull/25241/files/62cdaf01..3fcdc4af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25241&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25241&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25241/head:pull/25241 PR: https://git.openjdk.org/jdk/pull/25241 From michaelm at openjdk.org Wed May 28 11:13:12 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 28 May 2025 11:13:12 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v12] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - update - reduced number of new categories - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Review update - ... and 20 more: https://git.openjdk.org/jdk/compare/0671309d...cf179f7d ------------- Changes: https://git.openjdk.org/jdk/pull/23929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=11 Stats: 912 lines in 42 files changed: 681 ins; 101 del; 130 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From myankelevich at openjdk.org Wed May 28 11:20:53 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 28 May 2025 11:20:53 GMT Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid include/includedir directives after sections In-Reply-To: References: Message-ID: On Fri, 23 May 2025 18:41:17 GMT, Weijun Wang wrote: > Several changes are made: > > 1. The "include" and "includedir" directives can appear everywhere, even inside a section or a sub-section. However, it only means the content is inserted here but the included file still need its own full structure -- from section to subsections. > 2. The same file can be included multiple times as long as not recursively. > 3. Everything is merged. For duplicated values, `get` returns the first one and `getAll` returns all joining by spaces. > > Two new tests added. I also separately confirmed that they are parsed in the same way as [MIT krb5](https://github.com/krb5/krb5/blob/master/src/util/profile/test_parse.c). MIT krb5 ignores directory name after "include" but here it's an error. src/java.security.jgss/share/classes/sun/security/krb5/Config.java line 774: > 772: result.add(previous); > 773: unwritten.forEach(result::add); > 774: unwritten.clear(); I don't think this code is covered by the tests at all. I have found 2 simple ways to test it: 1. change the line 62-66 in IncludeDup from ```java for (var inc : List.of("outside", "beginsec", "insec", "insec2", "insubsec", "endsubsec", "endsec")) { Files.writeString(Path.of(inc), String.format(""" [a] b = { c = %s } """, inc)); } to ``` for (var inc : List.of("outside", "beginsec", "insec", "insec2", "insubsec", "endsubsec", "endsec")) { Files.writeString(Path.of(inc), String.format(""" [a] b = { c = %s } """, inc)); } 2. change `krb5.conf` EXAMPLE_3.COM from ``` java EXAMPLE_3.COM = { kdc = kdc.example.com kdc = kdc2.example.com inner = { aaa = nnn } } to ```java EXAMPLE_3.COM = { kdc = kdc.example.com kdc = kdc2.example.com inner = { aaa = nnn } } ``` There are other ways to cover this as well as writing it's own test case, however I feel that it might be an overkill for this. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25421#discussion_r2111597022 From michaelm at openjdk.org Wed May 28 11:34:58 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 28 May 2025 11:34:58 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:07:45 GMT, Mark Sheppard wrote: >> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' into 8348986-exceptions >> - update >> - reduced number of new categories >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Review update >> - review update >> - Merge branch 'master' into 8348986-exceptions >> - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 > > src/java.base/share/classes/jdk/internal/util/Exceptions.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, 2025, Oracle and/or its affiliates. All rights reserved. > > new file => copyright ? > > Copyright (c) 2025, The file isn't actually new, though webrev doesn't seem to realise that on this occasion (sometimes it does recognise name changes). It was previously named SocketExceptions. I presume we keep the existing header in that case? > src/java.base/share/classes/jdk/internal/util/Exceptions.java line 130: > >> 128: public abstract String output(); >> 129: >> 130: protected String output(boolean enhance) { > > to help us simple folk getting into a tizzy over a public abstract and a protected method of the same name and overloaded to boot > suggest > refactor rename this method name to composeFilteredMessageText or composeFilteredText or just compose Okay, I'll use one of those options, whichever fits best space wise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111618040 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111620553 From michaelm at openjdk.org Wed May 28 11:38:01 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 28 May 2025 11:38:01 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:40:39 GMT, Mark Sheppard wrote: >> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' into 8348986-exceptions >> - update >> - reduced number of new categories >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Merge branch 'master' into 8348986-exceptions >> - Review update >> - review update >> - Merge branch 'master' into 8348986-exceptions >> - ... and 18 more: https://git.openjdk.org/jdk/compare/e961b13c...cc518c19 > > src/java.base/share/classes/jdk/internal/util/Exceptions.java line 58: > >> 56: * public static SensitiveInfo filterUserName(String name) >> 57: */ >> 58: public final class Exceptions { > > maybe a refactor rename to convey some of the semantics of the class e.g. ExceptionMessageFilter I see what you mean, but the class does more than just filter messages. It also generates new Exception objects from existing ones. Given that its original name was `SocketExceptions` and all we've done here is generalize it to work with other exception types, I think `Exceptions` is a reasonable name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2111626402 From weijun at openjdk.org Wed May 28 15:25:40 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 28 May 2025 15:25:40 GMT Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid include/includedir directives after sections [v2] In-Reply-To: References: Message-ID: > Several changes are made: > > 1. The "include" and "includedir" directives can appear everywhere, even inside a section or a sub-section. However, it only means the content is inserted here but the included file still need its own full structure -- from section to subsections. > 2. The same file can be included multiple times as long as not recursively. > 3. Everything is merged. For duplicated values, `get` returns the first one and `getAll` returns all joining by spaces. > > Two new tests added. I also separately confirmed that they are parsed in the same way as [MIT krb5](https://github.com/krb5/krb5/blob/master/src/util/profile/test_parse.c). MIT krb5 ignores directory name after "include" but here it's an error. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more random testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25421/files - new: https://git.openjdk.org/jdk/pull/25421/files/9ab72006..dfabb82a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25421&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25421&range=00-01 Stats: 42 lines in 1 file changed: 23 ins; 4 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/25421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25421/head:pull/25421 PR: https://git.openjdk.org/jdk/pull/25421 From weijun at openjdk.org Wed May 28 15:28:04 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 28 May 2025 15:28:04 GMT Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid include/includedir directives after sections [v2] In-Reply-To: References: Message-ID: <3x5SkIDTrfjuIZpKRDeLMKZ9INQkn8JVDgpq2PxYqXw=.75c242a3-6615-4036-9a79-3131901b4e05@github.com> On Wed, 28 May 2025 11:18:21 GMT, Mikhail Yankelevich wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> more random testing > > src/java.security.jgss/share/classes/sun/security/krb5/Config.java line 774: > >> 772: result.add(previous); >> 773: unwritten.forEach(result::add); >> 774: unwritten.clear(); > > I don't think this code is covered by the tests at all. > I have found 2 simple ways to test it: > 1. change the line 62-66 in IncludeDup from > ```java > for (var inc : List.of("outside", "beginsec", "insec", "insec2", > "insubsec", "endsubsec", "endsec")) { > Files.writeString(Path.of(inc), String.format(""" > [a] > b = { > c = %s > } > """, inc)); > } > > to > ``` > for (var inc : List.of("outside", "beginsec", "insec", "insec2", > "insubsec", "endsubsec", "endsec")) { > Files.writeString(Path.of(inc), String.format(""" > [a] > b = > { c = %s > } > """, inc)); > } > > 2. change `krb5.conf` EXAMPLE_3.COM from > ``` java > > EXAMPLE_3.COM = { > kdc = kdc.example.com > kdc = kdc2.example.com > inner = > { > aaa = nnn > } > } > > to > ```java > > EXAMPLE_3.COM = { > kdc = kdc.example.com > kdc = kdc2.example.com > inner = > { aaa = nnn > } > } > ``` > > There are other ways to cover this as well as writing it's own test case, however I feel that it might be an overkill for this. > What do you think? Good catch. Instead I've enhanced the random test to cover this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25421#discussion_r2112188183 From mr at openjdk.org Wed May 28 16:40:17 2025 From: mr at openjdk.org (Mark Reinhold) Date: Wed, 28 May 2025 16:40:17 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v24] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 23:00:59 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK25 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > PEM reading tweak Marked as reviewed by mr (Lead). ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2875758449 From abarashev at openjdk.org Wed May 28 16:43:15 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 28 May 2025 16:43:15 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v24] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 23:00:59 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK25 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > PEM reading tweak test/jdk/java/security/PEM/PEMDecoderTest.java line 1: > 1: /* Per RFC 7468: `parsers SHOULD ignore whitespace and other non-base64 characters and MUST handle different newline conventions.`. Do we have a coverage for those 2 test cases? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2112331775 From myankelevich at openjdk.org Wed May 28 17:14:52 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 28 May 2025 17:14:52 GMT Subject: RFR: 8230016: re-visit test sun/security/pkcs11/Serialize/SerializeProvider.java [v3] In-Reply-To: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com> References: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com> Message-ID: On Wed, 30 Apr 2025 14:36:02 GMT, Mikhail Yankelevich wrote: >> Provider is now added to the Security before the test > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded check Still needs a review ------------- PR Comment: https://git.openjdk.org/jdk/pull/24750#issuecomment-2917050477 From ascarpino at openjdk.org Wed May 28 17:42:16 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 28 May 2025 17:42:16 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v22] In-Reply-To: References: <2k0yLU-Vny8aqXR1Y81pQKoKUOV8wh7BIa08drUg9CQ=.b1567dde-086e-4999-b27b-a9c76a0b8936@github.com> Message-ID: On Thu, 22 May 2025 12:02:28 GMT, Krushna948 wrote: >> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision: >> >> - comments >> - comments >> - fix EKS error after JEP 513 > > src/java.base/share/classes/java/security/PEMDecoder.java line 90: > >> 88: * decoded into a {@code PEMRecord} by specifying {@code PEMRecord.class}. >> 89: * If the Class parameter doesn't match the PEM content, an >> 90: * {@code IllegalArgumentException} will be thrown. > > Looks a Typo, it supposed to be ClassCastException? Thanks.. I can follow up on this with post integration. > src/java.base/share/classes/java/security/PEMDecoder.java line 485: > >> 483: * Any errors using the {@code Provider} will occur during decoding. >> 484: * >> 485: *

    If {@code provider} is {@code null}, a new instance is returned with > > May this needs to be updated as below @throws NullPointerException if {@code provider} is null yes, this could use some clarification post-integration > src/java.base/share/classes/java/security/PEMRecord.java line 56: > >> 54: * @param type the type identifier in the PEM header without PEM syntax labels. >> 55: * For a public key, {@code type} would be "PUBLIC KEY". >> 56: * @param pem any data between the PEM header and footer. > > Here 'pem' - any data between the PEM header and footer. > But the constructor description below for both the constructors > "pem the Base64-encoded data encapsulated by the PEM header and footer" > > Observation > If I pass the data between PEM header and footer, the PEMRecord created successfully. > If I include Header and Footer > For eg as pem string, > > "-----BEGIN PUBLIC KEY-----\n" + > "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDGRGrflwdiorIrC02pmr0jAKXI\n" + > "qxbBHxMUslLg8bjJiJCbanW7g7j7fR3RwGVU0cWh8rsQ/y4U7Yy0gBAsWCrr/TDS\n" + > "Xf3RWiZbQiQo6brZFiFZ5WgWgTpuzxDKpzLjyXCe17FXgbgEYscRPB/Rff6q2OS4\n" + > "H6stY3fHctzmU1HmUQIDAQAB\n" + > "-----END PUBLIC KEY-----"; > > PEMRecord creation throws java.lang.IllegalArgumentException: Illegal footer: > > Looks some inconsistency in documentation/ behavior The code requires a end of line character. Perhaps the documentation can be clarified later > src/java.base/share/classes/java/security/PEMRecord.java line 111: > >> 109: * {@code null}. >> 110: */ >> 111: public PEMRecord(String type, String pem) { > > Observed that PEMRecord.pem returns a string with out Header and footer and removing all the new line characters from input, do we need to specify that the result string filters out the new line characters? The class level javadoc specifies what the `type` should contain only the type identifier like "PUBLIC KEY". We also say there is no validation on the values entered. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2112388261 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2112390001 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2112390527 PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2112398916 From ascarpino at openjdk.org Wed May 28 17:42:16 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 28 May 2025 17:42:16 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v20] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 12:19:45 GMT, Krushna948 wrote: >> If this instance was configured with decryption, this method will return a new instance configured with decryption and the factory provider. I use "a copy" so the user knows they are adding a new configuration and this instance is staying the same > > It's little confusing Returns a copy here, and @return a new PEMEncoder instance configured to the {@code Provider}. > Technically it's a new instance by any means ? Yes, it's a new instance that copies the configuration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2112426415 From ascarpino at openjdk.org Wed May 28 17:42:18 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 28 May 2025 17:42:18 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v24] In-Reply-To: References: Message-ID: <2Pe_3mcyQYN3LRzw-0YSYPtwTk7W7L-BeUGmRuJ4sVA=.ae5a61e3-18e0-46c9-8e20-a20ee297ed09@github.com> On Wed, 28 May 2025 16:40:44 GMT, Artur Barashev wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> PEM reading tweak > > test/jdk/java/security/PEM/PEMDecoderTest.java line 1: > >> 1: /* > > Per RFC 7468: `parsers SHOULD ignore whitespace and other non-base64 characters and MUST handle different newline conventions.`. Do we have a coverage for those 2 test cases? Base64 parsing is left to the Base64 API, the whitespace is removed during read, and we do have different newlines conventions. I don't believe any new tests are needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2112418296 From duke at openjdk.org Wed May 28 18:03:11 2025 From: duke at openjdk.org (Nibedita Jena) Date: Wed, 28 May 2025 18:03:11 GMT Subject: RFR: 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir Message-ID: Generate intermediate/temporary files into the work directory, not in the test source directory. ------------- Commit messages: - removed whitespace - 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir Changes: https://git.openjdk.org/jdk/pull/25505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25505&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357253 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25505/head:pull/25505 PR: https://git.openjdk.org/jdk/pull/25505 From valeriep at openjdk.org Wed May 28 18:05:59 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 28 May 2025 18:05:59 GMT Subject: RFR: 8349400: Improve startup speed via eliminating nested classes [v2] In-Reply-To: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> References: <069HsiKRHjWB4UoKAZLK3nETTi391rZ9of0jMjHRw6I=.b483a18e-db57-4503-a9db-900dc0e416b3@github.com> Message-ID: <5GRQ2hC-FU0HK8epcq-D0JZe-3peSBY4qpC1DPNr-zQ=.4ddb736c-c9b3-429e-bf38-c93e172fbbb1@github.com> On Sat, 5 Apr 2025 01:30:49 GMT, Shaojin Wen wrote: >> During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10 anonymous classes, which slows down the startup. This PR is to improve KnownOIDs and eliminate unnecessary embedded classes. >> >> >> Here's how to reproduce this: >> >> >> public class Startup { >> public static void main(String[] args) {} >> } >> >> >> >> java -verbose:class Startup >> >> >> >> [0.665s][info][class,load] sun.security.util.KnownOIDs >> [0.666s][info][class,load] sun.security.util.KnownOIDs$1 >> [0.667s][info][class,load] sun.security.util.KnownOIDs$2 >> [0.667s][info][class,load] sun.security.util.KnownOIDs$3 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$4 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$5 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$6 >> [0.668s][info][class,load] sun.security.util.KnownOIDs$7 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$8 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$9 >> [0.669s][info][class,load] sun.security.util.KnownOIDs$10 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @valeriepeng Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23411#pullrequestreview-2875983237 From myankelevich at openjdk.org Wed May 28 18:14:52 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 28 May 2025 18:14:52 GMT Subject: RFR: 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir In-Reply-To: References: Message-ID: On Wed, 28 May 2025 17:52:31 GMT, Nibedita Jena wrote: > Generate intermediate/temporary files into the work directory, not in the test source directory. test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 26: > 24: /* > 25: * @test > 26: * @bug 8350830 8357253 AFAIK there is no need for an `@bug` number for a test bug ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25505#discussion_r2112484425 From duke at openjdk.org Wed May 28 18:41:08 2025 From: duke at openjdk.org (duke) Date: Wed, 28 May 2025 18:41:08 GMT Subject: Withdrawn: 8347067: Load certificates without explicit trust settings in KeyChainStore In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 11:28:01 GMT, Tim Jacomb wrote: > ## The change > > Without this change intermediate certificates that don't have explicit trust settings are ignored not added to the truststore. > > > > ## Reproducer > > See https://github.com/timja/openjdk-intermediate-ca-reproducer > > Without this change the reproducer fails, and with this change it succeeds. > > ## Example failing architecture > > Root CA -> Intermediate 1 -> Intermediate 2 -> Leaf > > Where: > * All certs are in admin domain kSecTrustSettingsDomainAdmin > * Root CA is marked as always trust > * Intermediate 1 and 2 are Unspecified > > Previously Root CA would be found but intermediate 1 and 2 would be skipped when verifying trust settings. > > ## Background reading > > ### Rust > see also Rust Lib that is used throughout Rust ecosystem for this: > https://github.com/rustls/rustls-native-certs/blob/efe7b1d77bf6080851486535664d1dc7ef0dea68/src/macos.rs#L39-L58 > > e.g. in Deno `https://github.com/denoland/deno/pull/11491` where I've verified it is correctly implemented and works in my setup > > ## Python > > I also looked at the Python implementation for inspiration as well (which also works on my system): https://github.com/sethmlarson/truststore/blob/main/src/truststore/_macos.py This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22911 From mullan at openjdk.org Wed May 28 19:32:14 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 28 May 2025 19:32:14 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v24] In-Reply-To: References: Message-ID: <1IZzTSL_Weqei855Mx1YM10HJkO8vUHNB8gAoFu3O5Y=.2dcc4919-cbd9-4f4e-acf8-39147af44eeb@github.com> On Tue, 27 May 2025 23:00:59 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK25 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > PEM reading tweak Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2876209840 From weijun at openjdk.org Wed May 28 19:37:14 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 28 May 2025 19:37:14 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v24] In-Reply-To: References: Message-ID: <1k6eR5EH3fU0gf_Wk2DIpUC1y06E_amVT6vowvXzQ70=.4022aa6e-51c9-4c81-aa77-b15c313ffa9f@github.com> On Tue, 27 May 2025 23:00:59 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK25 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > PEM reading tweak Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2876219519 From jnimeh at openjdk.org Wed May 28 19:42:18 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Wed, 28 May 2025 19:42:18 GMT Subject: RFR: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) [v24] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 23:00:59 GMT, Anthony Scarpino wrote: >> Hi all, >> >> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK25 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. >> >> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > PEM reading tweak Marked as reviewed by jnimeh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17543#pullrequestreview-2876229547 From ascarpino at openjdk.org Wed May 28 19:55:22 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 28 May 2025 19:55:22 GMT Subject: Integrated: 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) In-Reply-To: References: Message-ID: On Wed, 24 Jan 2024 00:01:06 GMT, Anthony Scarpino wrote: > Hi all, > > I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates. It will be integrated into JDK25 as a Preview Feature. Preview features does not permanently define the API and it is subject to change in future releases until it is finalized. > > Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911). > > Thanks > > Tony This pull request has now been integrated. Changeset: bb2c80c0 Author: Anthony Scarpino URL: https://git.openjdk.org/jdk/commit/bb2c80c0e9923385e0b6243c0ebff9afef208470 Stats: 3701 lines in 39 files changed: 3299 ins; 182 del; 220 mod 8298420: Implement JEP 470: PEM Encodings of Cryptographic Objects (Preview) Reviewed-by: weijun, mr, mullan, jnimeh ------------- PR: https://git.openjdk.org/jdk/pull/17543 From mullan at openjdk.org Wed May 28 20:44:53 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 28 May 2025 20:44:53 GMT Subject: RFR: 8349550: Improve SASL random usage [v2] In-Reply-To: References: Message-ID: On Wed, 28 May 2025 04:50:39 GMT, Koushik Muthukrishnan Thirupattur wrote: >> Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random For the bug, the `noreg-self` label is used for test only fixes. I would use something like `noreg-cleanup` probably. src/java.security.sasl/share/classes/com/sun/security/sasl/CramMD5Server.java line 35: > 33: import java.util.logging.Level; > 34: import java.util.Map; > 35: import java.util.Random; You can remove this import. src/java.security.sasl/share/classes/com/sun/security/sasl/CramMD5Server.java line 59: > 57: final class CramMD5Server extends CramMD5Base implements SaslServer { > 58: > 59: /* Secure Random instance to generate nonce */ s/nonce/random digits used in challenge/ src/java.security.sasl/share/classes/com/sun/security/sasl/CramMD5Server.java line 59: > 57: final class CramMD5Server extends CramMD5Base implements SaslServer { > 58: > 59: /* Secure Random instance to generate nonce */ s/Secure Random/SecureRandom/ src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java line 32: > 30: import java.math.BigInteger; > 31: import java.nio.charset.Charset; > 32: import java.security.*; This change seems unnecessary - I would restore the individual imports to be consistent with rest of file. src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java line 132: > 130: protected static final byte[] EMPTY_BYTE_ARRAY = new byte[0]; > 131: > 132: /* Secure Random instance to generate nonce */ s/Secure Random/SecureRandom/ src/java.security.sasl/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java line 273: > 271: * digest challenge or response. > 272: * Using JCAUtil SecureRandom to be more secure and > 273: * achieve comparable performance with Random. I would just remove this sentence as these kind of details can be included in the JBS issue. The previous sentence was more of a note. ------------- PR Review: https://git.openjdk.org/jdk/pull/25241#pullrequestreview-2876347251 PR Review Comment: https://git.openjdk.org/jdk/pull/25241#discussion_r2112697954 PR Review Comment: https://git.openjdk.org/jdk/pull/25241#discussion_r2112703487 PR Review Comment: https://git.openjdk.org/jdk/pull/25241#discussion_r2112712345 PR Review Comment: https://git.openjdk.org/jdk/pull/25241#discussion_r2112705103 PR Review Comment: https://git.openjdk.org/jdk/pull/25241#discussion_r2112712509 PR Review Comment: https://git.openjdk.org/jdk/pull/25241#discussion_r2112711177 From prr at openjdk.org Wed May 28 20:55:03 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 28 May 2025 20:55:03 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com> References: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com> Message-ID: On Mon, 26 May 2025 07:55:52 GMT, Magnus Ihse Bursie wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Restore MenuShortcut.java >> - Restore LocaleDataTest.java > > test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90: > >> 88: printKey(e); >> 89: int keychar = e.getKeyChar(); >> 90: if (keychar == 27) { // Escape character is 27 or \u001b > > @prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it? You are right, that's a typo. Keep your change. And I don't know why the code uses literal 27 instead of KeyEvent.VK_ESCAPE .. but that's not your problem. https://docs.oracle.com/en/java/javase/21/docs/api/constant-values.html#java.awt.event.KeyEvent.VK_ESCAPE > test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188: > >> 186: + "\"After\" lists.\n" >> 187: + " Added printers are highlighted with " >> 188: + "green color, removed ones \u2014 with " > > @prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error. > > Do you still want me to revert it? I agree. Keep your change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112722311 PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112731040 From prr at openjdk.org Wed May 28 20:55:04 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 28 May 2025 20:55:04 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com> References: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com> Message-ID: On Mon, 26 May 2025 08:07:19 GMT, Magnus Ihse Bursie wrote: >> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63: >> >>> 61: >>> 62: private static final String INSTRUCTIONS = >>> 63: "A string \u201C" + TEXT + "\u201D is drawn at eight different " >> >> I really don't like these tests being changed. It isn't part of the JDK build. >> People compile these in all sorts of locales. >> Please revert all the changes in the client tests. > > Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then. > > The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it? > > Let me know if you still want me to revert it. I'd like this reverted. People *build* these tests in their local repos using javac and whatever their locale is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112728971 From duke at openjdk.org Wed May 28 22:55:10 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Wed, 28 May 2025 22:55:10 GMT Subject: RFR: 8349550: Improve SASL random usage [v3] In-Reply-To: References: Message-ID: <6g9uCGCMePXbIGo6n-xr4naaqLJEakxIbS4YDwRFDzo=.bac7e529-99de-43bc-8322-e6dba15ae77b@github.com> > Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random Koushik Muthukrishnan Thirupattur has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - 8349550: Improve SASL random usage - Merge branch 'master' into 8349550 - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25241/files - new: https://git.openjdk.org/jdk/pull/25241/files/3fcdc4af..599aaca2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25241&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25241&range=01-02 Stats: 76194 lines in 1251 files changed: 45494 ins; 23803 del; 6897 mod Patch: https://git.openjdk.org/jdk/pull/25241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25241/head:pull/25241 PR: https://git.openjdk.org/jdk/pull/25241 From msheppar at openjdk.org Wed May 28 23:16:54 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 28 May 2025 23:16:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v12] In-Reply-To: References: Message-ID: On Wed, 28 May 2025 11:13:12 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: > > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Review update > - ... and 20 more: https://git.openjdk.org/jdk/compare/0671309d...cf179f7d her are few file with IOException, UnknownHostException and MalformedURLException, which are worth reviewing form Exception that may have been missed open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java Ln 562 open/src/java.base/share/classes/sun/security/x509/IPAddressName.java open/src/java.base/share/classes/sun/security/x509/URIName.java open/src/java.base/share/classes/sun/security/x509/RDN.java open/src/java.base/share/classes/java/util/jar/JarFile.java UnknownHostException open/src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java open/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java MalformedURLException open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java open/src/java.base/share/classes/java/net/URL.java ? Invalid port open/src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java open/src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java open/src/java.rmi/share/classes/java/rmi/Naming.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2917817454 From wetmore at openjdk.org Thu May 29 00:47:54 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 00:47:54 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v13] In-Reply-To: References: Message-ID: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> On Tue, 27 May 2025 14:00:07 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Update comments. Optimize imports. A few minor suggested nits. src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 289: > 287: * < length in bytes> Peer certificate > 288: * < 1 byte > Number of Local Certificate entries > 289: * < 1 byte > Local Certificate algorithm length Can we add a minor doc note here to say these fields are repeated for each cert (local/peer)? src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 326: > 324: } > 325: > 326: this.useExtendedMasterSecret = false; This is probably not needed, but ok to stay. If you like this style, then you could explicitly add the default `this.preSharedKey = null` for the TLSv1.3+ case around line 340. test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java line 107: > 105: > 106: switch (testMode) { > 107: case BASIC: Minor nit, Oracle Code Style is (was?) to keep case at the same level as the switch. I noticed this was updated in all the different cases here. If you're using IJ, you'll need to set the Settings->Editor->Code Style->Java->switch statement/expression->Indent case branches test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java line 177: > 175: > 176: switch (mode) { > 177: case BASIC: Same indentation issue here. ------------- PR Review: https://git.openjdk.org/jdk/pull/25310#pullrequestreview-2872621088 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2110223363 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2112802016 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2112970553 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2112970801 From wetmore at openjdk.org Thu May 29 00:54:37 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 00:54:37 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is complete/approved. > > Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge branch 'master' into JDK-8341346 - Remove TlsExporterKeyingMaterial for now. Can add later if needed. - Merge branch 'master' into JDK-8341346 - Merge branch 'master' into JDK-8341346 - Added PKCS11 testing - Minor bug - Missed one change - Merge branch 'master' into JDK-8341346 - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups - get*() no longer needed, backout error (oops!) - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 ------------- Changes: https://git.openjdk.org/jdk/pull/24976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=26 Stats: 1022 lines in 9 files changed: 1000 ins; 3 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From abarashev at openjdk.org Thu May 29 02:01:01 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 29 May 2025 02:01:01 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v13] In-Reply-To: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> References: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> Message-ID: On Thu, 29 May 2025 00:39:30 GMT, Bradford Wetmore wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comments. Optimize imports. > > test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java line 107: > >> 105: >> 106: switch (testMode) { >> 107: case BASIC: > > Minor nit, Oracle Code Style is (was?) to keep case at the same level as the switch. I noticed this was updated in all the different cases here. > > If you're using IJ, you'll need to set the Settings->Editor->Code Style->Java->switch statement/expression->Indent case branches Could you please post a link to the guide where it says so? I've found a couple of Oracle examples and both use different switch/case levels: 1. https://docs.oracle.com/javase/tutorial/java/nutsandbolts/switch.html 2. https://docs.oracle.com/en/java/javase/17/language/switch-expressions-and-statements.html Also, I couldn't find a single occurrence of the same switch/case level in our SSL code. `SSLKeyExchange.java` for example has multiple switch/case statement - all indented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2113031202 From wetmore at openjdk.org Thu May 29 03:08:52 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 03:08:52 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v13] In-Reply-To: References: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> Message-ID: On Thu, 29 May 2025 01:58:37 GMT, Artur Barashev wrote: >> test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java line 107: >> >>> 105: >>> 106: switch (testMode) { >>> 107: case BASIC: >> >> Minor nit, Oracle Code Style is (was?) to keep case at the same level as the switch. I noticed this was updated in all the different cases here. >> >> If you're using IJ, you'll need to set the Settings->Editor->Code Style->Java->switch statement/expression->Indent case branches > > Could you please post a link to the guide where it says so? I've found a couple of Oracle examples and both use different switch/case levels: > > 1. https://docs.oracle.com/javase/tutorial/java/nutsandbolts/switch.html > 2. https://docs.oracle.com/en/java/javase/17/language/switch-expressions-and-statements.html > > Also, I couldn't find a single occurrence of the same switch/case level in our SSL code. `SSLKeyExchange.java` for example has multiple switch/case statement - all indented. This isn't a big deal, and I'm ok with way. I probably wouldn't have mentioned it in new code (Xuelei was apparently a fan :) ), but it was surprising to see you change the existing switch indention style in two places in this test. See the PDF [Java Coding Conventions](https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.oracle.com/docs/tech/java/codeconventions.pdf&ved=2ahUKEwiNqLPMz8eNAxVXJDQIHY33NrEQFnoECBkQAQ&usg=AOvVaw0D2xdWb0D3hvB-nDkKWcU9), section 7.8 on Page 13. My personal preference is as doc'd, as it reduces the indention creep by 1 level and gives more vertical room for code before hitting the recommended 80 char/line max. If you Yah-oogl-ing (combo of Yahoo/Google/Bing :) ), you might [find the newer HTML version](https://www.oracle.com/java/technologies/javase/codeconventions-contents.html), but the spacing in the article is completely broken! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2113086029 From duke at openjdk.org Thu May 29 05:26:07 2025 From: duke at openjdk.org (Nibedita Jena) Date: Thu, 29 May 2025 05:26:07 GMT Subject: RFR: 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir [v2] In-Reply-To: References: Message-ID: > Generate intermediate/temporary files into the work directory, not in the test source directory. Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: Removed test bug number ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25505/files - new: https://git.openjdk.org/jdk/pull/25505/files/b9960f70..8aaa9acc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25505&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25505&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25505/head:pull/25505 PR: https://git.openjdk.org/jdk/pull/25505 From jpai at openjdk.org Thu May 29 06:06:45 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 May 2025 06:06:45 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null Message-ID: Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: import java.net.*; public class Test { public static void main(String[] args) throws Exception { System.out.println("testing against Java " + System.getProperty("java.version")); final ClassLoader cl = new URLClassLoader(new URL[0], null); final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); } } which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: testing against Java 24 Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) at Test.main(Test.java:8) No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass. Once we settle on the proposed text, I'll file a CSR for this change. I've marked the issue as fix version "26" since there's no rush for this change. But if we settle down on this text and the change looks good, this week, then I'll go ahead and propose this for 25. ------------- Commit messages: - 8228773: URLClassLoader constructors should include API note warning that the parent should not be null Changes: https://git.openjdk.org/jdk/pull/25517/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25517&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8228773 Stats: 45 lines in 2 files changed: 30 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/25517.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25517/head:pull/25517 PR: https://git.openjdk.org/jdk/pull/25517 From duke at openjdk.org Thu May 29 06:55:59 2025 From: duke at openjdk.org (duke) Date: Thu, 29 May 2025 06:55:59 GMT Subject: Withdrawn: 8201778: Speed up test javax/net/ssl/DTLS/PacketLossRetransmission.java In-Reply-To: <3Tyz1fAexWwXPNzndFkG4SLcl46kKtAk4uZJymFoSz8=.0c429e07-5dfb-45d6-8a06-fdc99fad50a2@github.com> References: <3Tyz1fAexWwXPNzndFkG4SLcl46kKtAk4uZJymFoSz8=.0c429e07-5dfb-45d6-8a06-fdc99fad50a2@github.com> Message-ID: <_ox1NkP8zD5ksy3zCUD49DzMJm8r9BaZG6JiK4sCo3w=.16340fa8-276c-4422-8a3a-2b1be6dba9ac@github.com> On Mon, 17 Mar 2025 13:19:55 GMT, Fernando Guallini wrote: > The test `javax/net/ssl/DTLS/PacketLossRetransmission` takes about ~2 to complete. The reason is that, in multiple scenarios, the server/client socket times out after 10 seconds waiting to receive a DatagramPacket that has been removed (to simulate a packet loss). > After reducing the time out only for such scenarios, the total test execution is completed within ~20 seconds on average. Other scenarios do not throw SocketTimeOut, no need to update. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24079 From alanb at openjdk.org Thu May 29 08:02:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 May 2025 08:02:54 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null In-Reply-To: References: Message-ID: <8NQKSPKyRcv6dlXCvps4L2SeS_VttHgYs3YfkKgxLzU=.6e542153-a5dc-44dc-aad2-61d93700cd21@github.com> On Thu, 29 May 2025 05:57:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? > > As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. > > Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. > > Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: > > > import java.net.*; > > public class Test { > public static void main(String[] args) throws Exception { > System.out.println("testing against Java " + System.getProperty("java.version")); > > final ClassLoader cl = new URLClassLoader(new URL[0], null); > final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module > System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); > > } > } > > which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: > > > testing against Java 24 > Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet > at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) > at Test.main(Test.java:8) > > > No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass. > > Once we settle on th... src/java.base/share/classes/java/net/URLClassLoader.java line 98: > 96: * Constructs a new URLClassLoader for the specified URLs using the > 97: * {@linkplain ClassLoader#getSystemClassLoader() default delegation > 98: * parent class loader}. The URLs will be searched in the order As we are changing it then maybe we could change this to "using the system class loader as the parent". I think that would be much clearer than "default delegation parent ...". Same thing in SecureClassLoader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113431536 From dfuchs at openjdk.org Thu May 29 08:30:58 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 29 May 2025 08:30:58 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null In-Reply-To: References: Message-ID: On Thu, 29 May 2025 05:57:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? > > As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. > > Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. > > Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: > > > import java.net.*; > > public class Test { > public static void main(String[] args) throws Exception { > System.out.println("testing against Java " + System.getProperty("java.version")); > > final ClassLoader cl = new URLClassLoader(new URL[0], null); > final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module > System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); > > } > } > > which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: > > > testing against Java 24 > Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet > at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) > at Test.main(Test.java:8) > > > No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass. > > Once we settle on th... src/java.base/share/classes/java/net/URLClassLoader.java line 82: > 80: * @apiNote If the {@code parent} is specified as {@code null} (for the > 81: * bootstrap class loader) then there is no guarantee that all platform > 82: * classes are visible. Should we add a link to `{@linkplain ClassLoader##builtinLoaders ...}` somewhere in this API note? > there is no guarantee that all platform classes are visible sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113473277 From michaelm at openjdk.org Thu May 29 09:02:56 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 29 May 2025 09:02:56 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v12] In-Reply-To: References: Message-ID: On Wed, 28 May 2025 23:13:21 GMT, Mark Sheppard wrote: > here are a few files with IOException, UnknownHostException and MalformedURLException, which are worth reviewing for Exception that may have been missed > > IOEXception: > > open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java Ln 562 > > open/src/java.base/share/classes/sun/security/x509/IPAddressName.java > > open/src/java.base/share/classes/sun/security/x509/URIName.java > > open/src/java.base/share/classes/sun/security/x509/RDN.java > > open/src/java.base/share/classes/java/util/jar/JarFile.java > > UnknownHostException > > open/src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java > > open/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java > > MalformedURLException > > open/src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java > > open/src/java.base/share/classes/java/net/URL.java ? Invalid port > > open/src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java > > open/src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java > > open/src/java.rmi/share/classes/java/rmi/Naming.java Thanks, I will take another look at all these cases and update any that I agree need to be included. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2918771547 From michaelm at openjdk.org Thu May 29 09:02:55 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 29 May 2025 09:02:55 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v11] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 20:39:51 GMT, Mark Sheppard wrote: > You could take a slightly more radical approach, and rather than applying a filter explicitly on the exception message, adopt a builder pattern for the creation of the filter exceptions, for example > > FilteredExceptionBuilder / EnhancedExceptionBuilder. > > It might provide be more flexible and provide, encapsulating the filtering and policy application inside the builder. > > EnhancedExceptionBuilder::class() ::exceptionMessage() ::port() ::hostname() ::userDetails() ::filterPolicy() We've been through so many iterations at this stage, that I think what we've landed on is reasonable and probably most importantly, concise such that it's not overly intrusive at the call sites. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2918770154 From myankelevich at openjdk.org Thu May 29 09:32:51 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Thu, 29 May 2025 09:32:51 GMT Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid include/includedir directives after sections [v2] In-Reply-To: <3x5SkIDTrfjuIZpKRDeLMKZ9INQkn8JVDgpq2PxYqXw=.75c242a3-6615-4036-9a79-3131901b4e05@github.com> References: <3x5SkIDTrfjuIZpKRDeLMKZ9INQkn8JVDgpq2PxYqXw=.75c242a3-6615-4036-9a79-3131901b4e05@github.com> Message-ID: On Wed, 28 May 2025 15:25:27 GMT, Weijun Wang wrote: >> src/java.security.jgss/share/classes/sun/security/krb5/Config.java line 774: >> >>> 772: result.add(previous); >>> 773: unwritten.forEach(result::add); >>> 774: unwritten.clear(); >> >> I don't think this code is covered by the tests at all. >> I have found 2 simple ways to test it: >> 1. change the line 62-66 in IncludeDup from >> ```java >> for (var inc : List.of("outside", "beginsec", "insec", "insec2", >> "insubsec", "endsubsec", "endsec")) { >> Files.writeString(Path.of(inc), String.format(""" >> [a] >> b = { >> c = %s >> } >> """, inc)); >> } >> >> to >> ``` >> for (var inc : List.of("outside", "beginsec", "insec", "insec2", >> "insubsec", "endsubsec", "endsec")) { >> Files.writeString(Path.of(inc), String.format(""" >> [a] >> b = >> { c = %s >> } >> """, inc)); >> } >> >> 2. change `krb5.conf` EXAMPLE_3.COM from >> ``` java >> >> EXAMPLE_3.COM = { >> kdc = kdc.example.com >> kdc = kdc2.example.com >> inner = >> { >> aaa = nnn >> } >> } >> >> to >> ```java >> >> EXAMPLE_3.COM = { >> kdc = kdc.example.com >> kdc = kdc2.example.com >> inner = >> { aaa = nnn >> } >> } >> ``` >> >> There are other ways to cover this as well as writing it's own test case, however I feel that it might be an overkill for this. >> What do you think? > > Good catch. Instead I've enhanced the random test to cover this. Thank you :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25421#discussion_r2113575984 From hchao at openjdk.org Thu May 29 11:20:57 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Thu, 29 May 2025 11:20:57 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 00:54:37 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is complete/approved. >> >> Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge branch 'master' into JDK-8341346 > - Remove TlsExporterKeyingMaterial for now. Can add later if needed. > - Merge branch 'master' into JDK-8341346 > - Merge branch 'master' into JDK-8341346 > - Added PKCS11 testing > - Minor bug > - Missed one change > - Merge branch 'master' into JDK-8341346 > - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups > - get*() no longer needed, backout error (oops!) > - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1559: > 1557: emptyHash = md.digest(); > 1558: } catch (NoSuchAlgorithmException nsae) { > 1559: throw new ProviderException( This exception is not listed in `@throws` of new API in `ExtendedSSLSession.java`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2113743245 From aturbanov at openjdk.org Thu May 29 12:30:54 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 29 May 2025 12:30:54 GMT Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 13:01:38 GMT, Weijun Wang wrote: >> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded. >> >> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > safer privKeyToPubKey; updated desciptions for the properties; adding braces to if blocks src/java.base/share/classes/sun/security/provider/NamedKeyFactory.java line 80: > 78: } > 79: > 80: private String checkName(String pname) throws InvalidKeyException { Suggestion: private String checkName(String pname) throws InvalidKeyException { src/java.base/share/classes/sun/security/provider/NamedKeyPairGenerator.java line 158: > 156: } > 157: > 158: private String checkName(String pname) throws InvalidAlgorithmParameterException { Suggestion: private String checkName(String pname) throws InvalidAlgorithmParameterException { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2113843615 PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2113843341 From coffeys at openjdk.org Thu May 29 13:21:57 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 29 May 2025 13:21:57 GMT Subject: RFR: 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir [v2] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 05:26:07 GMT, Nibedita Jena wrote: >> Generate intermediate/temporary files into the work directory, not in the test source directory. > > Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: > > Removed test bug number test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 68: > 66: * The following is to set up the keystores. > 67: */ > 68: private static final String pathToStores = System.getProperty("test.src", "."); can this code boil down to: private static final char[] passphrase = "123456".toCharArray(); private static final String keyFilename = "ks_san.p12"; private static final String trustFilename = "ks_san.p12"; i.e. delete lines 68-70 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25505#discussion_r2113928441 From jpai at openjdk.org Thu May 29 13:23:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 May 2025 13:23:42 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? > > As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. > > Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. > > Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: > > > import java.net.*; > > public class Test { > public static void main(String[] args) throws Exception { > System.out.println("testing against Java " + System.getProperty("java.version")); > > final ClassLoader cl = new URLClassLoader(new URL[0], null); > final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module > System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); > > } > } > > which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: > > > testing against Java 24 > Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet > at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) > at Test.main(Test.java:8) > > > No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass. > > Once we settle on th... Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Alan's suggestion - replace default delegation class loader with system class loader ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25517/files - new: https://git.openjdk.org/jdk/pull/25517/files/6acffa95..95ff99cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25517&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25517&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25517.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25517/head:pull/25517 PR: https://git.openjdk.org/jdk/pull/25517 From jpai at openjdk.org Thu May 29 13:23:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 May 2025 13:23:43 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v2] In-Reply-To: References: Message-ID: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com> On Thu, 29 May 2025 08:28:12 GMT, Daniel Fuchs wrote: >> there is no guarantee that all platform classes are visible > > sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that. Alan's suggestion was that we reuse the existing `@apiNote` from the `java.lang.ClassLoader`'s constructor. So this text was borrowed from that place. Alan, do you suggest we should reword this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113931597 From jpai at openjdk.org Thu May 29 13:23:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 May 2025 13:23:43 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v2] In-Reply-To: <8NQKSPKyRcv6dlXCvps4L2SeS_VttHgYs3YfkKgxLzU=.6e542153-a5dc-44dc-aad2-61d93700cd21@github.com> References: <8NQKSPKyRcv6dlXCvps4L2SeS_VttHgYs3YfkKgxLzU=.6e542153-a5dc-44dc-aad2-61d93700cd21@github.com> Message-ID: <-dIzX_UVlW7Ek6J3CKy_LksBrGYDmSBGrn8pUnyD8z8=.6e4bd106-5cd2-484b-bce1-ef104834a2d4@github.com> On Thu, 29 May 2025 08:00:40 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan's suggestion - replace default delegation class loader with system class loader > > src/java.base/share/classes/java/net/URLClassLoader.java line 98: > >> 96: * Constructs a new URLClassLoader for the specified URLs using the >> 97: * {@linkplain ClassLoader#getSystemClassLoader() default delegation >> 98: * parent class loader}. The URLs will be searched in the order > > As we are changing it then maybe we could change this to "using the system class loader as the parent". I think that would be much clearer than "default delegation parent ...". Same thing in SecureClassLoader. Done - updated these 2 places to use the "system class loader" reference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113928114 From alanb at openjdk.org Thu May 29 13:42:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 May 2025 13:42:54 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v2] In-Reply-To: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com> References: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com> Message-ID: <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com> On Thu, 29 May 2025 13:20:28 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/net/URLClassLoader.java line 82: >> >>> 80: * @apiNote If the {@code parent} is specified as {@code null} (for the >>> 81: * bootstrap class loader) then there is no guarantee that all platform >>> 82: * classes are visible. >> >> Should we add a link to `{@linkplain ClassLoader##builtinLoaders ...}` somewhere in this API note? >> >>> there is no guarantee that all platform classes are visible >> >> sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that. > >>> there is no guarantee that all platform classes are visible >> >> sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that. > > Alan's suggestion was that we reuse the existing `@apiNote` from the `java.lang.ClassLoader`'s constructor. So this text was borrowed from that place. > > Alan, do you suggest we should reword this? I think what you have in the latest commit is good. To address Daniel's comment then we could add another sentence to the API note, something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113971128 From jpai at openjdk.org Thu May 29 13:47:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 May 2025 13:47:56 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v2] In-Reply-To: <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com> References: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com> <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com> Message-ID: On Thu, 29 May 2025 13:40:10 GMT, Alan Bateman wrote: >>>> there is no guarantee that all platform classes are visible >>> >>> sounds (to me) like the behaviour is undefined (which is not the case). A link to the place where the various class loaders are discussed might clarify that. >> >> Alan's suggestion was that we reuse the existing `@apiNote` from the `java.lang.ClassLoader`'s constructor. So this text was borrowed from that place. >> >> Alan, do you suggest we should reword this? > > I think what you have in the latest commit is good. To address Daniel's comment then we could add another sentence to the API note, something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work. > Should we add a link to {@linkplain ClassLoader##builtinLoaders ...} somewhere in this API note? I think we can add that as a link for "bootstrap class loader". Something like: * @apiNote If the {@code parent} is specified as {@code null} (for the * {@linkplain ClassLoader##builtinLoaders bootstrap class loader}) then * there is no guarantee that all platform classes are visible. Should we use this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2113989966 From jpai at openjdk.org Thu May 29 14:03:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 May 2025 14:03:50 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v2] In-Reply-To: References: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com> <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com> Message-ID: On Thu, 29 May 2025 13:45:02 GMT, Jaikiran Pai wrote: > Should we use this? I missed Alan's suggestion to add a separate sentence linking to the ClassLoader section. I will update this PR accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114045277 From abarashev at openjdk.org Thu May 29 14:07:55 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 29 May 2025 14:07:55 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v13] In-Reply-To: References: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> Message-ID: <5n2r7oZqse9jORy8h1DHBFURJBPxLGGZC_AxiMaimMU=.660c2f4d-ec56-4174-8f34-53071d9a112b@github.com> On Thu, 29 May 2025 03:06:25 GMT, Bradford Wetmore wrote: >> Could you please post a link to the guide where it says so? I've found a couple of Oracle examples and both use different switch/case levels: >> >> 1. https://docs.oracle.com/javase/tutorial/java/nutsandbolts/switch.html >> 2. https://docs.oracle.com/en/java/javase/17/language/switch-expressions-and-statements.html >> >> Also, I couldn't find a single occurrence of the same switch/case level in our SSL code. `SSLKeyExchange.java` for example has multiple switch/case statement - all indented. > > This isn't a big deal, and I'm ok with way. I probably wouldn't have mentioned it in new code (Xuelei was apparently a fan :) ), but it was surprising to see you change the existing switch indention style in two places in this test. > > See the PDF [Java Coding Conventions](https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.oracle.com/docs/tech/java/codeconventions.pdf&ved=2ahUKEwiNqLPMz8eNAxVXJDQIHY33NrEQFnoECBkQAQ&usg=AOvVaw0D2xdWb0D3hvB-nDkKWcU9), section 7.8 on Page 13. > > My personal preference is as doc'd, as it reduces the indention creep by 1 level and gives more vertical room for code before hitting the recommended 80 char/line max. > > If you Yah-oogl-ing (combo of Yahoo/Google/Bing :) ), you might [find the newer HTML version](https://www.oracle.com/java/technologies/javase/codeconventions-contents.html), but the spacing in the article is completely broken! I see, thanks! It's good to have a PDF version as HTML version's indentation is simply missing (as you have mentioned). I'll restore the original indentation then, it was done automatically by IntelliJ. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2114053130 From jpai at openjdk.org Thu May 29 14:19:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 May 2025 14:19:08 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? > > As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. > > Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. > > Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: > > > import java.net.*; > > public class Test { > public static void main(String[] args) throws Exception { > System.out.println("testing against Java " + System.getProperty("java.version")); > > final ClassLoader cl = new URLClassLoader(new URL[0], null); > final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module > System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); > > } > } > > which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: > > > testing against Java 24 > Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet > at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) > at Test.main(Test.java:8) > > > No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass. > > Once we settle on th... Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: additional sentence to the apiNote ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25517/files - new: https://git.openjdk.org/jdk/pull/25517/files/95ff99cb..12f70566 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25517&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25517&range=01-02 Stats: 12 lines in 2 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25517.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25517/head:pull/25517 PR: https://git.openjdk.org/jdk/pull/25517 From jpai at openjdk.org Thu May 29 14:19:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 May 2025 14:19:08 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v3] In-Reply-To: References: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com> <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com> Message-ID: On Thu, 29 May 2025 14:01:16 GMT, Jaikiran Pai wrote: >>> Should we add a link to {@linkplain ClassLoader##builtinLoaders ...} somewhere in this API note? >> >> I think we can add that as a link for "bootstrap class loader". Something like: >> >> >> * @apiNote If the {@code parent} is specified as {@code null} (for the >> * {@linkplain ClassLoader##builtinLoaders bootstrap class loader}) then >> * there is no guarantee that all platform classes are visible. >> >> >> Should we use this? > >> Should we use this? > > I missed Alan's suggestion to add a separate sentence linking to the ClassLoader section. I will update this PR accordingly. > something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work. Done. Updated the PR with this text. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114072976 From abarashev at openjdk.org Thu May 29 14:21:55 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 29 May 2025 14:21:55 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v13] In-Reply-To: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> References: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> Message-ID: On Thu, 29 May 2025 00:39:53 GMT, Bradford Wetmore wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comments. Optimize imports. > > test/jdk/sun/security/ssl/SSLSessionImpl/ResumeChecksServer.java line 177: > >> 175: >> 176: switch (mode) { >> 177: case BASIC: > > Same indentation issue here. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2114077366 From abarashev at openjdk.org Thu May 29 14:28:57 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 29 May 2025 14:28:57 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v13] In-Reply-To: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> References: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> Message-ID: On Wed, 28 May 2025 21:42:07 GMT, Bradford Wetmore wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comments. Optimize imports. > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 326: > >> 324: } >> 325: >> 326: this.useExtendedMasterSecret = false; > > This is probably not needed, but ok to stay. > > If you like this style, then you could explicitly add the default `this.preSharedKey = null` for the TLSv1.3+ case around line 340. It is actually needed because `useExtendedMasterSecret` is final, unlike `preSharedKey`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2114090606 From michaelm at openjdk.org Thu May 29 14:35:11 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 29 May 2025 14:35:11 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v13] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Additional callsites identified by Mark S. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23929/files - new: https://git.openjdk.org/jdk/pull/23929/files/cf179f7d..34f20c9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=11-12 Stats: 79 lines in 9 files changed: 27 ins; 0 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From abarashev at openjdk.org Thu May 29 14:44:52 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 29 May 2025 14:44:52 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v13] In-Reply-To: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> References: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> Message-ID: On Tue, 27 May 2025 20:51:51 GMT, Bradford Wetmore wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comments. Optimize imports. > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 289: > >> 287: * < length in bytes> Peer certificate >> 288: * < 1 byte > Number of Local Certificate entries >> 289: * < 1 byte > Local Certificate algorithm length > > Can we add a minor doc note here to say these fields are repeated for each cert (local/peer)? Good idea, done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2114120061 From weijun at openjdk.org Thu May 29 15:25:58 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 29 May 2025 15:25:58 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: References: Message-ID: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> On Thu, 29 May 2025 00:54:37 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is complete/approved. >> >> Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge branch 'master' into JDK-8341346 > - Remove TlsExporterKeyingMaterial for now. Can add later if needed. > - Merge branch 'master' into JDK-8341346 > - Merge branch 'master' into JDK-8341346 > - Added PKCS11 testing > - Minor bug > - Missed one change > - Merge branch 'master' into JDK-8341346 > - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups > - get*() no longer needed, backout error (oops!) > - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 176: > 174: * RFC 8446 (TLSv1.3) treats a null context as non-null/empty. > 175: *

    > 176: * The {@code label} {@code String} will be converted to bytes using Two consecutive `{@code}` look a little strange to me, visually. How about just `{@code label} will be...`? You already use that in `@param label`. Same as in the other method. src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 198: > 196: * {@code label} will be converted to a {@code byte[]} > 197: * before the operation begins. > 198: * @param context the context bytes used in the EKM calculation, or null `null` needs to be in `{@code}`. Same as in `@throws NullPointerException`. Same as in the other method. src/java.base/share/classes/sun/security/internal/spec/TlsPrfParameterSpec.java line 85: > 83: * @param secret the secret to use in the calculation (or null) > 84: * @param keyAlg the algorithm name that the generated SecretKey should > 85: * have, or null if the default should be used You no longer allow it to be `null`. src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1494: > 1492: if (exporterMasterSecret == null) { > 1493: throw new RuntimeException( > 1494: "Exporter master secret not captured"); Do you want to choose another exception type? Like `ProviderException`. Actually, how unlikely this is? If you believe this would never happen (unless there is a programming error), you can even throw an `AssertionError`. Same question in `useTLS10PlusSpec()` for the two randoms. test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 1: > 1: /* Do you want to test about null/empty context difference in TLS 1.2/1.3? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114057734 PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114060429 PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114065976 PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114120216 PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114083657 From dfuchs at openjdk.org Thu May 29 16:16:51 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 29 May 2025 16:16:51 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v3] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 14:19:08 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? >> >> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. >> >> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. >> >> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: >> >> >> import java.net.*; >> >> public class Test { >> public static void main(String[] args) throws Exception { >> System.out.println("testing against Java " + System.getProperty("java.version")); >> >> final ClassLoader cl = new URLClassLoader(new URL[0], null); >> final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module >> System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); >> >> } >> } >> >> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: >> >> >> testing against Java 24 >> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet >> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) >> at Test.main(Test.java:8) >> >> >> No new tests have been introduced and existing tes... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > additional sentence to the apiNote LGTM ------------- PR Review: https://git.openjdk.org/jdk/pull/25517#pullrequestreview-2878852031 From wetmore at openjdk.org Thu May 29 16:19:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 16:19:55 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v13] In-Reply-To: References: <0bmX2SYIX6GeCmd9kOl92r9iWmTlyw96VZkcghl3Gp4=.c9b2e8f1-b99e-4584-b4fa-8542fd658917@github.com> Message-ID: <4v128EkNOo-I4Z6toVPhrgSRMA9z75unBPeJRRPy9Qw=.2422c2f8-f4bc-41a9-9ee1-8a49f732afa3@github.com> On Thu, 29 May 2025 14:26:06 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 326: >> >>> 324: } >>> 325: >>> 326: this.useExtendedMasterSecret = false; >> >> This is probably not needed, but ok to stay. >> >> If you like this style, then you could explicitly add the default `this.preSharedKey = null` for the TLSv1.3+ case around line 340. > > It is actually needed because `useExtendedMasterSecret` is final, unlike `preSharedKey`. Ah, ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2114298191 From weijun.wang at oracle.com Thu May 29 16:44:30 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Thu, 29 May 2025 16:44:30 +0000 Subject: X-Wing KEM In-Reply-To: References: Message-ID: Hi Sebastian. > On May 24, 2025, at 05:40, Sebastian Stenzel wrote: > > Hi all, > > For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing. > > As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs. Thanks for your continued interest on enhancing OpenJDK. That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first. > > All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec? It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible. > > Alternatively, can we make the two mentioned APIs public? No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral. [1] https://openjdk.org/guide/ Thanks, Weijun > > Cheers! > Sebastian > > [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/ > [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07 > [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536 > From alanb at openjdk.org Thu May 29 16:46:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 May 2025 16:46:57 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v3] In-Reply-To: References: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com> <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com> Message-ID: On Thu, 29 May 2025 14:16:36 GMT, Jaikiran Pai wrote: >>> Should we use this? >> >> I missed Alan's suggestion to add a separate sentence linking to the ClassLoader section. I will update this PR accordingly. > >> something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work. > > Done. Updated the PR with this text. Ah, I see I said "system class loader" in error, I meant the bootstrap classloader because the that is what the first sentence is about. Sorry for the confusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114348523 From mullan at openjdk.org Thu May 29 17:01:55 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 29 May 2025 17:01:55 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v3] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 14:19:08 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? >> >> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. >> >> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. >> >> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: >> >> >> import java.net.*; >> >> public class Test { >> public static void main(String[] args) throws Exception { >> System.out.println("testing against Java " + System.getProperty("java.version")); >> >> final ClassLoader cl = new URLClassLoader(new URL[0], null); >> final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module >> System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); >> >> } >> } >> >> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: >> >> >> testing against Java 24 >> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet >> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) >> at Test.main(Test.java:8) >> >> >> No new tests have been introduced and existing tes... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > additional sentence to the apiNote src/java.base/share/classes/java/net/URLClassLoader.java line 87: > 85: * > 86: * @param urls the URLs from which to load classes and resources > 87: * @param parent the parent class loader for delegation, can be null s/null/{@code null}/ src/java.base/share/classes/java/net/URLClassLoader.java line 123: > 121: * obtain protocol handlers when creating new jar URLs. > 122: * > 123: * @apiNote If the {@code parent} is specified as {@code null} (for the I think "If {@code parent}" is more correct, since you are implicitly referring to the parameter. src/java.base/share/classes/java/net/URLClassLoader.java line 127: > 125: * classes are visible. > 126: * See {@linkplain ClassLoader##builtinLoaders Run-time Built-in Class Loaders} > 127: * for information on the system class loader and other built-in class loaders. Seems more relevant to say "for information on the bootstrap class loader and other built-in class loaders." since you specifically mention bootstrap loader in the first sentence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114361908 PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114370688 PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2114366997 From dfuchs at openjdk.org Thu May 29 17:10:04 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 29 May 2025 17:10:04 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v13] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 14:35:11 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > Additional callsites identified by Mark S. src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 566: > 564: filterNonSocketInfo(url.getHost()) > 565: .prefixWith("should be <") > 566: .suffixWith(">"))); Suggestion: throw new IOException(formatMsg("Wrong HTTPS hostname%s", filterNonSocketInfo(url.getHost()) .prefixWith(": should be <") .suffixWith(">"))); src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 560: > 558: if (isa.isUnresolved()) { > 559: throw new UnknownHostException( > 560: formatMsg("%s", filterNonSocketInfo(isa.getHostName()))); Suggestion: formatMsg(filterNonSocketInfo(isa.getHostName()))); src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java line 99: > 97: close(); > 98: throw new UnknownHostException( > 99: formatMsg("%s", filterNonSocketInfo(remote.toString()))); Suggestion: throw new UnknownHostException( formatMsg(filterNonSocketInfo(remote.toString()))); src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java line 125: > 123: protected MalformedURLException newInvalidURISchemeException(String uri) { > 124: return new MalformedURLException(formatMsg("Not an LDAP URL: %s", > 125: filterNonSocketInfo(uri))); Suggestion: return new MalformedURLException(formatMsg("Not an LDAP URL%s", filterNonSocketInfo(uri).prefixWith(": "))); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 238: > 236: > 237: private MalformedURLException newMalformedURLException(String prefix, String msg) { > 238: return new MalformedURLException(formatMsg(prefix + " %s", filterNonSocketInfo(msg))); Suggestion: return new MalformedURLException(prefix + formatMsg(filterNonSocketInfo(msg).withPrefix(prefix.isEmpty()? "" : ": ")); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 250: > 248: URI u = new URI(uri); > 249: scheme = u.getScheme(); > 250: if (scheme == null) throw newMalformedURLException("Invalid URI:", uri); Suggestion: if (scheme == null) throw newMalformedURLException("Invalid URI", uri); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 262: > 260: if (!hostport.equals(auth)) { > 261: // throw if we have user info or regname > 262: throw newMalformedURLException("unsupported authority:", auth); Suggestion: throw newMalformedURLException("unsupported authority", auth); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 271: > 269: if (u.getRawFragment() != null) { > 270: if (!acceptsFragment()) { > 271: throw newMalformedURLException("URI fragments not supported:", uri); Suggestion: throw newMalformedURLException("URI fragments not supported", uri); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 308: > 306: int fmark = uri.indexOf('#'); > 307: if (i < 0 || slash > 0 && i > slash || qmark > 0 && i > qmark || fmark > 0 && i > fmark) { > 308: throw newMalformedURLException("Invalid URI:", uri); Suggestion: throw newMalformedURLException("Invalid URI", uri); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 312: > 310: if (fmark > -1) { > 311: if (!acceptsFragment()) { > 312: throw newMalformedURLException("URI fragments not supported:", uri); Suggestion: throw newMalformedURLException("URI fragments not supported", uri); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 358: > 356: String ui = u.getRawUserInfo(); > 357: if (ui != null) { > 358: throw newMalformedURLException("user info not supported in authority:", ui); Suggestion: throw newMalformedURLException("user info not supported in authority", ui); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 361: > 359: } > 360: if (!"/".equals(p)) { > 361: throw newMalformedURLException("invalid authority:", auth); Suggestion: throw newMalformedURLException("invalid authority", auth); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 364: > 362: } > 363: if (q != null) { > 364: throw newMalformedURLException("invalid trailing characters in authority: ?", q); Suggestion: throw new MalformedURLException("invalid trailing characters in authority: ?" + formatMsg(filterNonSocketInfo(q))); src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 374: > 372: // throw if we have user info or regname > 373: throw newMalformedURLException("Authority component is not server-based, " + > 374: "or contains user info. Unsupported authority:", auth); Suggestion: "or contains user info. Unsupported authority", auth); src/java.rmi/share/classes/java/rmi/Naming.java line 227: > 225: > 226: private static MalformedURLException newMalformedURLException(String prefix, String msg) { > 227: return new MalformedURLException(formatMsg(prefix + " %s", filterNonSocketInfo(msg))); Suggestion: return new MalformedURLException(prefix + formatMsg(filterNonSocketInfo(msg).prefixWith(": ")); src/java.rmi/share/classes/java/rmi/Naming.java line 250: > 248: */ > 249: MalformedURLException mue = newMalformedURLException( > 250: "invalid URL String:", str); Suggestion: "invalid URL String", str); src/java.rmi/share/classes/java/rmi/Naming.java line 282: > 280: if (uri.isOpaque()) { > 281: throw newMalformedURLException( > 282: "not a hierarchical URL:", str); Suggestion: "not a hierarchical URL", str); src/java.rmi/share/classes/java/rmi/Naming.java line 286: > 284: if (uri.getFragment() != null) { > 285: throw newMalformedURLException( > 286: "invalid character, '#', in URL name:", str); Suggestion: "invalid character, '#', in URL name", str); src/java.rmi/share/classes/java/rmi/Naming.java line 289: > 287: } else if (uri.getQuery() != null) { > 288: throw newMalformedURLException( > 289: "invalid character, '?', in URL name:", str); Suggestion: "invalid character, '?', in URL name", str); src/java.rmi/share/classes/java/rmi/Naming.java line 292: > 290: } else if (uri.getUserInfo() != null) { > 291: throw newMalformedURLException( > 292: "invalid character, '@', in URL host:", str); Suggestion: "invalid character, '@', in URL host", str); src/java.rmi/share/classes/java/rmi/Naming.java line 296: > 294: String scheme = uri.getScheme(); > 295: if (scheme != null && !scheme.equals("rmi")) { > 296: throw newMalformedURLException("invalid URL scheme:", str); Suggestion: throw new MalformedURLException(formatMsg("invalid URL scheme%s", filterNonSocketInfo(str).prefixWith(": ").replaceWith(": rmi")); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114314118 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114338001 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114341371 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114325981 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114336092 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114343715 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114344189 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114344732 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114349684 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114360771 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114361269 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114361808 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114372438 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114373811 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114380353 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381257 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381615 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114381991 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114382430 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114382678 PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2114383025 From duke at openjdk.org Thu May 29 17:48:18 2025 From: duke at openjdk.org (Nibedita Jena) Date: Thu, 29 May 2025 17:48:18 GMT Subject: RFR: 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir [v3] In-Reply-To: References: Message-ID: > Generate intermediate/temporary files into the work directory, not in the test source directory. Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: Streamline of code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25505/files - new: https://git.openjdk.org/jdk/pull/25505/files/8aaa9acc..63d70266 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25505&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25505&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25505/head:pull/25505 PR: https://git.openjdk.org/jdk/pull/25505 From coffeys at openjdk.org Thu May 29 18:25:51 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 29 May 2025 18:25:51 GMT Subject: RFR: 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir [v3] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 17:48:18 GMT, Nibedita Jena wrote: >> Generate intermediate/temporary files into the work directory, not in the test source directory. > > Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: > > Streamline of code LGTM ------------- Marked as reviewed by coffeys (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25505#pullrequestreview-2879215291 From prr at openjdk.org Thu May 29 19:08:54 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 29 May 2025 19:08:54 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie wrote: >> I found a few other places in the code that can be cleaned up after the conversion to UTF-8. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Restore MenuShortcut.java > - Restore LocaleDataTest.java Approving client changes ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2879326497 From coffeys at openjdk.org Thu May 29 19:11:25 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 29 May 2025 19:11:25 GMT Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug Message-ID: Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property. To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data. This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data. Debug output data from use of the `java.security.debug` property will now resemble something like the following: properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect. properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch. ------------- Commit messages: - Merge branch 'master' into 8350689-default-timestamps - update system property doc - 8350689 Changes: https://git.openjdk.org/jdk/pull/25528/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25528&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350689 Stats: 182 lines in 5 files changed: 14 ins; 130 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/25528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25528/head:pull/25528 PR: https://git.openjdk.org/jdk/pull/25528 From wetmore at openjdk.org Thu May 29 20:04:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 20:04:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v26] In-Reply-To: References: <-dPDZBm7dtwx9glzUlXRPZH9VFjHXYZWCQFVX01goZg=.95c342bb-56c7-4a28-befc-7cdc85460aa0@github.com> Message-ID: <1fBXXKWhwmVtCs4xV7oD805N2cWK9gXvidfRvEaDCFo=.58eb8aa5-94e8-403c-8ff1-dfa00b3e1d4c@github.com> On Tue, 27 May 2025 23:37:45 GMT, Artur Barashev wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits: >> >> - Remove TlsExporterKeyingMaterial for now. Can add later if needed. >> - Merge branch 'master' into JDK-8341346 >> - Merge branch 'master' into JDK-8341346 >> - Added PKCS11 testing >> - Minor bug >> - Missed one change >> - Merge branch 'master' into JDK-8341346 >> - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups >> - get*() no longer needed, backout error (oops!) >> - Merge branch 'master' into JDK-8341346 >> - ... and 26 more: https://git.openjdk.org/jdk/compare/66747710...67480e99 > > src/java.base/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java line 1: > >> 1: /* > > Not related to this PR, but `engineGenerateKey0` method should be `protected` I will go ahead and tweak it. Shouldn't be a problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114662829 From swen at openjdk.org Thu May 29 20:12:00 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 29 May 2025 20:12:00 GMT Subject: Integrated: 8349400: Improve startup speed via eliminating nested classes In-Reply-To: References: Message-ID: On Sun, 2 Feb 2025 19:35:03 GMT, Shaojin Wen wrote: > During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10 anonymous classes, which slows down the startup. This PR is to improve KnownOIDs and eliminate unnecessary embedded classes. > > > Here's how to reproduce this: > > > public class Startup { > public static void main(String[] args) {} > } > > > > java -verbose:class Startup > > > > [0.665s][info][class,load] sun.security.util.KnownOIDs > [0.666s][info][class,load] sun.security.util.KnownOIDs$1 > [0.667s][info][class,load] sun.security.util.KnownOIDs$2 > [0.667s][info][class,load] sun.security.util.KnownOIDs$3 > [0.668s][info][class,load] sun.security.util.KnownOIDs$4 > [0.668s][info][class,load] sun.security.util.KnownOIDs$5 > [0.668s][info][class,load] sun.security.util.KnownOIDs$6 > [0.668s][info][class,load] sun.security.util.KnownOIDs$7 > [0.669s][info][class,load] sun.security.util.KnownOIDs$8 > [0.669s][info][class,load] sun.security.util.KnownOIDs$9 > [0.669s][info][class,load] sun.security.util.KnownOIDs$10 This pull request has now been integrated. Changeset: d922e318 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/d922e318bc2104d69c46403bceb609d538f3259a Stats: 59 lines in 1 file changed: 10 ins; 34 del; 15 mod 8349400: Improve startup speed via eliminating nested classes Reviewed-by: valeriep, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/23411 From wetmore at openjdk.org Thu May 29 20:16:56 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 20:16:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> References: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> Message-ID: On Thu, 29 May 2025 14:08:10 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Remove TlsExporterKeyingMaterial for now. Can add later if needed. >> - Merge branch 'master' into JDK-8341346 >> - Merge branch 'master' into JDK-8341346 >> - Added PKCS11 testing >> - Minor bug >> - Missed one change >> - Merge branch 'master' into JDK-8341346 >> - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups >> - get*() no longer needed, backout error (oops!) >> - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 > > src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 176: > >> 174: * RFC 8446 (TLSv1.3) treats a null context as non-null/empty. >> 175: *

    >> 176: * The {@code label} {@code String} will be converted to bytes using > > Two consecutive `{@code}` look a little strange to me, visually. How about just `{@code label} will be...`? You already use that in `@param label`. Same as in the other method. Done. * {@code label} will be converted to bytes using * the {@link java.nio.charset.StandardCharsets#UTF_8} * character encoding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114679469 From abarashev at openjdk.org Thu May 29 20:31:14 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 29 May 2025 20:31:14 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v14] In-Reply-To: References: Message-ID: <9mmdBAjxP3U909Otl955PWwgdh2Hc7eNAavvMo1rV14=.6654392b-9e83-4235-8a31-9929c767b11f@github.com> > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8357033 - Restore unit test indentation. Update comments. - Update comments. Optimize imports. - Remove unused imports - Adding a unit test check for certificates - Make sure we got the exact same cert chain. - Assume "createPossession" can return more certificates than in the session ticket - Unit test: add required module - Unit test nit: restore original check - Add a unit test. Don't break on checksum mismatch, we may get all the certificates in the end. - ... and 12 more: https://git.openjdk.org/jdk/compare/aeeba727...6d813458 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/0f745465..6d813458 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=12-13 Stats: 96296 lines in 1519 files changed: 62461 ins; 25982 del; 7853 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From wetmore at openjdk.org Thu May 29 20:33:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 20:33:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> References: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> Message-ID: <0RcPynZ_KgnC2dSHO6JMMnk9LTFzhKAOX1vmuunrh7k=.184fc841-3e8d-4153-8653-37939926c3c9@github.com> On Thu, 29 May 2025 14:09:38 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Remove TlsExporterKeyingMaterial for now. Can add later if needed. >> - Merge branch 'master' into JDK-8341346 >> - Merge branch 'master' into JDK-8341346 >> - Added PKCS11 testing >> - Minor bug >> - Missed one change >> - Merge branch 'master' into JDK-8341346 >> - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups >> - get*() no longer needed, backout error (oops!) >> - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 > > src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 198: > >> 196: * {@code label} will be converted to a {@code byte[]} >> 197: * before the operation begins. >> 198: * @param context the context bytes used in the EKM calculation, or null > > `null` needs to be in `{@code}`. Same as in `@throws NullPointerException`. Same as in the other method. As we discussed in Slack, the javadocs are all over the place on this one. Some have it, others don't. We have more non-code nulls than code in the JSSE docs. I don't mind either way. But if we're going to do this, we might want to do it throughout the security code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114703622 From abarashev at openjdk.org Thu May 29 20:35:33 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 29 May 2025 20:35:33 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v15] In-Reply-To: References: Message-ID: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Restore unit test code formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/6d813458..24ea8947 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=13-14 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From wetmore at openjdk.org Thu May 29 20:37:54 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 20:37:54 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> References: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> Message-ID: <_4JYDI_vv1GEjvgVyM4LT05cCh9osKWbpxo36VhGbS8=.615a0a2a-9b40-490c-957d-8ff909dff556@github.com> On Thu, 29 May 2025 14:12:47 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Remove TlsExporterKeyingMaterial for now. Can add later if needed. >> - Merge branch 'master' into JDK-8341346 >> - Merge branch 'master' into JDK-8341346 >> - Added PKCS11 testing >> - Minor bug >> - Missed one change >> - Merge branch 'master' into JDK-8341346 >> - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups >> - get*() no longer needed, backout error (oops!) >> - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 > > src/java.base/share/classes/sun/security/internal/spec/TlsPrfParameterSpec.java line 85: > >> 83: * @param secret the secret to use in the calculation (or null) >> 84: * @param keyAlg the algorithm name that the generated SecretKey should >> 85: * have, or null if the default should be used > > You no longer allow it to be `null`. Egads, good catch. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114708506 From mpowers at openjdk.org Thu May 29 22:08:52 2025 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 29 May 2025 22:08:52 GMT Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug In-Reply-To: References: Message-ID: On Thu, 29 May 2025 19:06:15 GMT, Sean Coffey wrote: > Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property. > > > To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data. > > This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data. > > Debug output data from use of the `java.security.debug` property will now resemble something like the following: > > > > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect. > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast > > > I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch. You might need to append 8350689 to @bug in a few test programs. test/jdk/sun/security/krb5/auto/LoginModuleDebug.java line 62: > 60: "", > 61: "krb5loginmodule"), > 62: // thread and timestamp on by default now "now" will be confusing ten years from now. test/jdk/sun/security/util/Debug/DebugOptions.java line 58: > 56: private static Stream patternMatches() { > 57: return Stream.of( > 58: // thread and timestamp info on by default now remove "now" test/jdk/sun/security/util/Debug/DebugOptions.java line 62: > 60: EXPECTED_PROP_REGEX, > 61: "properties:"), > 62: // thread and timestamp info on by default now remove "now" ------------- PR Review: https://git.openjdk.org/jdk/pull/25528#pullrequestreview-2879660897 PR Review Comment: https://git.openjdk.org/jdk/pull/25528#discussion_r2114780664 PR Review Comment: https://git.openjdk.org/jdk/pull/25528#discussion_r2114786648 PR Review Comment: https://git.openjdk.org/jdk/pull/25528#discussion_r2114787727 From wetmore at openjdk.org Thu May 29 22:15:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 22:15:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 11:17:50 GMT, Hai-May Chao wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Remove TlsExporterKeyingMaterial for now. Can add later if needed. >> - Merge branch 'master' into JDK-8341346 >> - Merge branch 'master' into JDK-8341346 >> - Added PKCS11 testing >> - Minor bug >> - Missed one change >> - Merge branch 'master' into JDK-8341346 >> - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups >> - get*() no longer needed, backout error (oops!) >> - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1559: > >> 1557: emptyHash = md.digest(); >> 1558: } catch (NoSuchAlgorithmException nsae) { >> 1559: throw new ProviderException( > > This exception is not listed in `@throws` of new API in `ExtendedSSLSession.java`? Weijun and I talked about this. This is a really extreme case all providers that provide basic functionality have been removed. We don't mention this anywhere else, and it's done in several places. It's a RuntimeException, and we don't always document every situation. I'm ok to skip this one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114826097 From wetmore at openjdk.org Thu May 29 22:29:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 29 May 2025 22:29:55 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> References: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> Message-ID: <_pHe7Ea7Rh7GEWiV08QMYfDNd1lOgle1CTSuKYfYRaM=.42fb5cb5-572a-4538-95dd-f55aa86186d7@github.com> On Thu, 29 May 2025 14:22:16 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Remove TlsExporterKeyingMaterial for now. Can add later if needed. >> - Merge branch 'master' into JDK-8341346 >> - Merge branch 'master' into JDK-8341346 >> - Added PKCS11 testing >> - Minor bug >> - Missed one change >> - Merge branch 'master' into JDK-8341346 >> - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups >> - get*() no longer needed, backout error (oops!) >> - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 > > test/jdk/javax/net/ssl/ExtendedSSLSession/ExportKeyingMaterialTests.java line 1: > >> 1: /* > > Do you want to test about null/empty context difference in TLS 1.2/1.3? I can add that in the TLS1.2- arm, although I'm not sure it's really needed. Will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114839789 From weijun at openjdk.org Thu May 29 22:38:53 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 29 May 2025 22:38:53 GMT Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug In-Reply-To: References: Message-ID: On Thu, 29 May 2025 19:06:15 GMT, Sean Coffey wrote: > Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property. > > > To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data. > > This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data. > > Debug output data from use of the `java.security.debug` property will now resemble something like the following: > > > > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect. > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast > > > I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch. Looks great. Do you need a CSR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25528#issuecomment-2920734129 From ascarpino at openjdk.org Thu May 29 22:44:27 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 29 May 2025 22:44:27 GMT Subject: RFR: 8358076: KeyFactory.getInstance("EdDSA").generatePublic(null) throws NPE Message-ID: <-pDvWyv0MbjtmiYZZ9t51UESnsQwbdyZs9lhgqm_qgg=.c9253d63-7118-49b7-b816-8ef98d347d79@github.com> I need a code review to throw `InvalidKeySpecException` when null is passed with `generatePublic()` and `generatePrivate()`. This change takes the opportunity to modernize the KeyFactory code by using `switch` syntax for `instanceof` checking, as well as, keeping the previous design of the implementation method handling the null case. There are existing JCK test cover this case, so no regression test is added. ------------- Commit messages: - add null and update syntax Changes: https://git.openjdk.org/jdk/pull/25533/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25533&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358076 Stats: 200 lines in 4 files changed: 51 ins; 20 del; 129 mod Patch: https://git.openjdk.org/jdk/pull/25533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25533/head:pull/25533 PR: https://git.openjdk.org/jdk/pull/25533 From weijun at openjdk.org Thu May 29 23:35:52 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 29 May 2025 23:35:52 GMT Subject: RFR: 8358076: KeyFactory.getInstance("EdDSA").generatePublic(null) throws NPE In-Reply-To: <-pDvWyv0MbjtmiYZZ9t51UESnsQwbdyZs9lhgqm_qgg=.c9253d63-7118-49b7-b816-8ef98d347d79@github.com> References: <-pDvWyv0MbjtmiYZZ9t51UESnsQwbdyZs9lhgqm_qgg=.c9253d63-7118-49b7-b816-8ef98d347d79@github.com> Message-ID: On Thu, 29 May 2025 22:38:41 GMT, Anthony Scarpino wrote: > I need a code review to throw `InvalidKeySpecException` when null is passed with `generatePublic()` and `generatePrivate()`. This change takes the opportunity to modernize the KeyFactory code by using `switch` syntax for `instanceof` checking, as well as, keeping the previous design of the implementation method handling the null case. There are existing JCK test cover this case, so no regression test is added. src/java.base/share/classes/sun/security/ec/ECKeyFactory.java line 223: > 221: } > 222: case null -> throw new InvalidKeySpecException( > 223: "keySpec most not be null"); `s/most/must/`. Add every other `case null` in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25533#discussion_r2114892682 From hchao at openjdk.org Thu May 29 23:49:53 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Thu, 29 May 2025 23:49:53 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 00:54:37 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is complete/approved. >> >> Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge branch 'master' into JDK-8341346 > - Remove TlsExporterKeyingMaterial for now. Can add later if needed. > - Merge branch 'master' into JDK-8341346 > - Merge branch 'master' into JDK-8341346 > - Added PKCS11 testing > - Minor bug > - Missed one change > - Merge branch 'master' into JDK-8341346 > - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups > - get*() no longer needed, backout error (oops!) > - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 Marked as reviewed by hchao (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2879841654 From ascarpino at openjdk.org Thu May 29 23:55:51 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 29 May 2025 23:55:51 GMT Subject: RFR: 8358076: KeyFactory.getInstance("EdDSA").generatePublic(null) throws NPE In-Reply-To: References: <-pDvWyv0MbjtmiYZZ9t51UESnsQwbdyZs9lhgqm_qgg=.c9253d63-7118-49b7-b816-8ef98d347d79@github.com> Message-ID: On Thu, 29 May 2025 23:32:59 GMT, Weijun Wang wrote: >> I need a code review to throw `InvalidKeySpecException` when null is passed with `generatePublic()` and `generatePrivate()`. This change takes the opportunity to modernize the KeyFactory code by using `switch` syntax for `instanceof` checking, as well as, keeping the previous design of the implementation method handling the null case. There are existing JCK test cover this case, so no regression test is added. > > src/java.base/share/classes/sun/security/ec/ECKeyFactory.java line 223: > >> 221: } >> 222: case null -> throw new InvalidKeySpecException( >> 223: "keySpec most not be null"); > > `s/most/must/`. Add every other `case null` in this PR. Sigh.. one typo that is cut and pasted repeatedly. Sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25533#discussion_r2114909524 From wetmore at openjdk.org Fri May 30 01:13:48 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 30 May 2025 01:13:48 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v28] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is complete/approved. > > Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Last minute codereview comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/858362c8..d0a0a7bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=26-27 Stats: 31 lines in 5 files changed: 24 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From wetmore at openjdk.org Fri May 30 01:27:56 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 30 May 2025 01:27:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> References: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> Message-ID: On Thu, 29 May 2025 14:42:00 GMT, Weijun Wang wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: >> >> - Merge branch 'master' into JDK-8341346 >> - Remove TlsExporterKeyingMaterial for now. Can add later if needed. >> - Merge branch 'master' into JDK-8341346 >> - Merge branch 'master' into JDK-8341346 >> - Added PKCS11 testing >> - Minor bug >> - Missed one change >> - Merge branch 'master' into JDK-8341346 >> - Private Codereview comment: Don't allow use of null keyAlgs, plus some minor cleanups >> - get*() no longer needed, backout error (oops!) >> - ... and 27 more: https://git.openjdk.org/jdk/compare/2ec6ab34...858362c8 > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1494: > >> 1492: if (exporterMasterSecret == null) { >> 1493: throw new RuntimeException( >> 1494: "Exporter master secret not captured"); > > Do you want to choose another exception type? Like `ProviderException`. Actually, how unlikely this is? If you believe this would never happen (unless there is a programming error), you can even throw an `AssertionError`. > > Same question in `useTLS10PlusSpec()` for the two randoms. @wangweij asked if `SSLSession` are ever in a partially completed state. The answer is yes, during handshaking the `SSLSocket/SSLEngine.getHandshakeSession()` methods can return `SSLSession` that is incomplete. As such, it makes more sense for this to be an `IllegalArgumentException`. Drafted the CSR, made the update, and refinalized it. Hopefully the wording is acceptable. ;) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2114985934 From wetmore at openjdk.org Fri May 30 01:48:57 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 30 May 2025 01:48:57 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v15] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 20:35:33 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Restore unit test code formatting One little nit that might help readability, you can skip or do. src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 276: > 274: * < 1 byte > serverNameIndication length > 275: * < length in bytes > serverNameIndication > 276: * < 1 byte > Number of requestedServerNames entries Would you be up for doing ("for each entry") for this one too? I know this is not your code, but it's one place outstanding. Feel free to skip or do. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25310#pullrequestreview-2879982273 PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2114997308 From weijun at openjdk.org Fri May 30 01:53:56 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 30 May 2025 01:53:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v28] In-Reply-To: References: Message-ID: <7j7RJqSNu8rArSRF8NlX2gVRSjryTwI36FHrMXhbPPk=.545457e6-1db1-4601-8b2f-5f9032f4825b@github.com> On Fri, 30 May 2025 01:13:48 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is complete/approved. >> >> Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Last minute codereview comments Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2879996771 From duke at openjdk.org Fri May 30 03:05:01 2025 From: duke at openjdk.org (duke) Date: Fri, 30 May 2025 03:05:01 GMT Subject: Withdrawn: 8345139: Fix bugs and inconsistencies in the Provider services map In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 19:36:09 GMT, Francisco Ferrari Bihurriet wrote: > Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map"). > > #### New services map design > > Here is the high-level hierarchy of the new services map design: > > * `servicesMap` (`ServicesMap`) > * Instances (fields) > * `services` (`Map`): unifies the previous `serviceMap` and `legacyMap` > * `legacySvcKeys` (`Set`): set indicating which keys in `services` correspond to the Legacy API > * `serviceProps` (`Map`): keeps track of the _provider Hashtable entries_ that originated services entries (1) > * `serviceAttrProps` (`Map>`): keeps track of the _provider Hashtable entries_ that originated service attributes (1) > * `serviceSet` (`AtomicReference>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method > * Writers' methods (for providers registering services through the Current or the Legacy API) > * `boolean putService(Service svc)` > * `boolean removeService(Service svc)` > * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)` > * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)` > * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)` > * `boolean removeLegacy(ServiceKey key, String className)` > * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)` > * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)` > * Readers' methods (for services users and `GetInstance` APIs) > * `Set getServices()` > * `Service getService(ServiceKey key)` > * Other methods: default and copy constructors, `void clear()` > > (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms. > > #### Testing > > As part of our testing, we observed all the tests pass in the following categories: > > * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398)) > * `jdk/com/sun/crypto` > * `jdk/java/security` > * Including the new `jdk/java/security/Provider/Ser... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22613 From duke at openjdk.org Fri May 30 03:42:51 2025 From: duke at openjdk.org (duke) Date: Fri, 30 May 2025 03:42:51 GMT Subject: RFR: 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir [v3] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 17:48:18 GMT, Nibedita Jena wrote: >> Generate intermediate/temporary files into the work directory, not in the test source directory. > > Nibedita Jena has updated the pull request incrementally with one additional commit since the last revision: > > Streamline of code @nibjen Your change (at version 63d7026694d395e86b0e09e8e47cafbbf97a7db7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25505#issuecomment-2921140641 From jpai at openjdk.org Fri May 30 06:26:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 30 May 2025 06:26:51 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v3] In-Reply-To: References: <8KGaTp2lF1YqW0Mgn2khjs-KINoK6L6HRwz4VLaXVJI=.a8060e47-280b-44e5-9f11-895de54169e7@github.com> <3RknHpVbL4Jrwy7SFXezERtNoXw6YwxNNoGM14kyeYk=.f696f9a8-f22e-4368-b0a9-b4d8230aa67f@github.com> Message-ID: On Thu, 29 May 2025 16:43:46 GMT, Alan Bateman wrote: >>> something like "See Run-time Built-in Class Loaders for information on the system class loader other and the other built-in class loaders". I think that might work. >> >> Done. Updated the PR with this text. > > Ah, I see I said "system class loader" in error, I meant the bootstrap classloader because the that is what the first sentence is about. Sorry for the confusion. No problem. Although I had seen that discrepancy, I assumed that you probably wanted to nudge users towards the use of system class loader for these constructors. I will replace it to bootstrap class loader shortly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2115221587 From jpai at openjdk.org Fri May 30 06:55:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 30 May 2025 06:55:07 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v4] In-Reply-To: References: Message-ID: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com> > Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? > > As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. > > Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. > > Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: > > > import java.net.*; > > public class Test { > public static void main(String[] args) throws Exception { > System.out.println("testing against Java " + System.getProperty("java.version")); > > final ClassLoader cl = new URLClassLoader(new URL[0], null); > final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module > System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); > > } > } > > which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: > > > testing against Java 24 > Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet > at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) > at Test.main(Test.java:8) > > > No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass. > > Once we settle on th... Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: - replace system class loader reference with bootstrap class loader - remove "the" - {@code null} instead of null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25517/files - new: https://git.openjdk.org/jdk/pull/25517/files/12f70566..9897bec3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25517&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25517&range=02-03 Stats: 18 lines in 2 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/25517.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25517/head:pull/25517 PR: https://git.openjdk.org/jdk/pull/25517 From jpai at openjdk.org Fri May 30 06:55:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 30 May 2025 06:55:08 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v3] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 16:50:49 GMT, Sean Mullan wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> additional sentence to the apiNote > > src/java.base/share/classes/java/net/URLClassLoader.java line 87: > >> 85: * >> 86: * @param urls the URLs from which to load classes and resources >> 87: * @param parent the parent class loader for delegation, can be null > > s/null/{@code null}/ Fixed in the latest update of this PR. > src/java.base/share/classes/java/net/URLClassLoader.java line 123: > >> 121: * obtain protocol handlers when creating new jar URLs. >> 122: * >> 123: * @apiNote If the {@code parent} is specified as {@code null} (for the > > I think "If {@code parent}" is more correct, since you are implicitly referring to the parameter. Done. > src/java.base/share/classes/java/net/URLClassLoader.java line 127: > >> 125: * classes are visible. >> 126: * See {@linkplain ClassLoader##builtinLoaders Run-time Built-in Class Loaders} >> 127: * for information on the system class loader and other built-in class loaders. > > Seems more relevant to say "for information on the bootstrap class loader and other built-in class loaders." since you specifically mention bootstrap loader in the first sentence. Fixed in the latest update of this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2115255429 PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2115255846 PR Review Comment: https://git.openjdk.org/jdk/pull/25517#discussion_r2115255640 From jpai at openjdk.org Fri May 30 07:17:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 30 May 2025 07:17:57 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v4] In-Reply-To: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com> References: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com> Message-ID: On Fri, 30 May 2025 06:55:07 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? >> >> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. >> >> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. >> >> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: >> >> >> import java.net.*; >> >> public class Test { >> public static void main(String[] args) throws Exception { >> System.out.println("testing against Java " + System.getProperty("java.version")); >> >> final ClassLoader cl = new URLClassLoader(new URL[0], null); >> final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module >> System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); >> >> } >> } >> >> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: >> >> >> testing against Java 24 >> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet >> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) >> at Test.main(Test.java:8) >> >> >> No new tests have been introduced and existing tes... > > Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: > > - replace system class loader reference with bootstrap class loader > - remove "the" > - {@code null} instead of null The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8358126 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25517#issuecomment-2921445858 From alanb at openjdk.org Fri May 30 07:17:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 May 2025 07:17:57 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v4] In-Reply-To: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com> References: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com> Message-ID: <21HVYE8jgNoGmFPIpAqTSYtdH7l1EWr_qUViokvicOY=.0b72b66b-56c6-4d71-b323-506d81a7dea2@github.com> On Fri, 30 May 2025 06:55:07 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? >> >> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. >> >> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. >> >> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: >> >> >> import java.net.*; >> >> public class Test { >> public static void main(String[] args) throws Exception { >> System.out.println("testing against Java " + System.getProperty("java.version")); >> >> final ClassLoader cl = new URLClassLoader(new URL[0], null); >> final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module >> System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); >> >> } >> } >> >> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: >> >> >> testing against Java 24 >> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet >> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) >> at Test.main(Test.java:8) >> >> >> No new tests have been introduced and existing tes... > > Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: > > - replace system class loader reference with bootstrap class loader > - remove "the" > - {@code null} instead of null Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25517#pullrequestreview-2880392639 From jnimeh at openjdk.org Fri May 30 07:19:54 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 30 May 2025 07:19:54 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v28] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 01:13:48 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is complete/approved. >> >> Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Last minute codereview comments Marked as reviewed by jnimeh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2880396913 From coffeys at openjdk.org Fri May 30 08:31:31 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 30 May 2025 08:31:31 GMT Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug [v2] In-Reply-To: References: Message-ID: > Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property. > > > To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data. > > This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data. > > Debug output data from use of the `java.security.debug` property will now resemble something like the following: > > > > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect. > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast > > > I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Incorporate review comments from Mark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25528/files - new: https://git.openjdk.org/jdk/pull/25528/files/f07a7ff2..0d766cc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25528&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25528&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25528/head:pull/25528 PR: https://git.openjdk.org/jdk/pull/25528 From michaelm at openjdk.org Fri May 30 09:01:39 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 30 May 2025 09:01:39 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v14] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23929/files - new: https://git.openjdk.org/jdk/pull/23929/files/34f20c9a..cf5233c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=12-13 Stats: 21 lines in 6 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From michaelm at openjdk.org Fri May 30 09:01:39 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 30 May 2025 09:01:39 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v13] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 14:35:11 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > Additional callsites identified by Mark S. Thanks for the suggestions. I have committed all of them except for two. One, I will modify in another way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2921687319 From duke at openjdk.org Fri May 30 09:24:57 2025 From: duke at openjdk.org (Nibedita Jena) Date: Fri, 30 May 2025 09:24:57 GMT Subject: Integrated: 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir In-Reply-To: References: Message-ID: On Wed, 28 May 2025 17:52:31 GMT, Nibedita Jena wrote: > Generate intermediate/temporary files into the work directory, not in the test source directory. This pull request has now been integrated. Changeset: 566e3b21 Author: nibjen Committer: Sean Coffey URL: https://git.openjdk.org/jdk/commit/566e3b21ed14748cb0d9117b6bd58b4bfcf625c6 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod 8357253: Test test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java writes in src dir Reviewed-by: coffeys ------------- PR: https://git.openjdk.org/jdk/pull/25505 From michaelm at openjdk.org Fri May 30 09:39:36 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 30 May 2025 09:39:36 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v15] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - typo in suggestions and other issues - Merge branch 'master' into 8348986-exceptions - Apply suggestions from code review Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> - Additional callsites identified by Mark S. - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - Merge branch 'master' into 8348986-exceptions - update - reduced number of new categories - Merge branch 'master' into 8348986-exceptions - ... and 24 more: https://git.openjdk.org/jdk/compare/e33eeeea...462ee011 ------------- Changes: https://git.openjdk.org/jdk/pull/23929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=14 Stats: 984 lines in 47 files changed: 711 ins; 101 del; 172 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From coffeys at openjdk.org Fri May 30 09:40:54 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 30 May 2025 09:40:54 GMT Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug In-Reply-To: References: Message-ID: On Thu, 29 May 2025 22:36:38 GMT, Weijun Wang wrote: > Looks great. Do you need a CSR? Yes - need a reviewer for CSR: https://bugs.openjdk.org/browse/JDK-8358090 Thanks. I've taken Mark's comments on board. I removed the comment referring to default "on" also since there is no concept of on/off for this option anymore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25528#issuecomment-2921807228 From michaelm at openjdk.org Fri May 30 10:32:57 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 30 May 2025 10:32:57 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v15] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 09:39:36 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - typo in suggestions and other issues > - Merge branch 'master' into 8348986-exceptions > - Apply suggestions from code review > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > - Additional callsites identified by Mark S. > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - Merge branch 'master' into 8348986-exceptions > - update > - reduced number of new categories > - Merge branch 'master' into 8348986-exceptions > - ... and 24 more: https://git.openjdk.org/jdk/compare/e33eeeea...462ee011 The last change to java.net.HostPortrange (renaming the constructor parameter) has caused a problem. The parameter is hiding a field of the same name. I need to fix that now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2921954327 From michaelm at openjdk.org Fri May 30 10:44:11 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 30 May 2025 10:44:11 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v16] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: Fixed problem with j.n.HostPortRange ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23929/files - new: https://git.openjdk.org/jdk/pull/23929/files/462ee011..3eec6c03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=14-15 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From alanb at openjdk.org Fri May 30 10:47:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 May 2025 10:47:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v16] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 10:44:11 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > Fixed problem with j.n.HostPortRange src/java.base/share/classes/sun/net/www/protocol/jmod/Handler.java line 50: > 48: if (index == -1) > 49: throw new MalformedURLException( > 50: formatMsg("no !/ found in url spec%s", filterJarName(s).prefixWith(": "))); JMOD files can only be used at compile time and link time. So I think you can drop the changes jmod stream handler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2115650070 From vyazici at openjdk.org Fri May 30 11:12:15 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 30 May 2025 11:12:15 GMT Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] Message-ID: Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`. `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries. ------------- Commit messages: - Revert more superfluous changes - Fix code typo - Discard changes unrelated with core libraries - Revert superfluous changes - Revert changes to 3rd parties in `com/sun/org/apache` - Revert `PandocFilter` changes - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations Changes: https://git.openjdk.org/jdk/pull/25544/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25544&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357995 Stats: 65 lines in 15 files changed: 16 ins; 7 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/25544.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544 PR: https://git.openjdk.org/jdk/pull/25544 From vyazici at openjdk.org Fri May 30 12:02:37 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 30 May 2025 12:02:37 GMT Subject: RFR: 8357821: Revert incorrectly named JavaLangAccess::unchecked* methods Message-ID: Reverts certain [JDK-8353197](https://bugs.openjdk.org/browse/JDK-8353197) (which implements JavaDoc improvement and precautionary naming for certain unsafe methods in `jdk.internal.access.JavaLangAccess`) changes that are found to be incorrect. See the JBS issue for details on the followed evaluation process. ------------- Commit messages: - Revert incorrect JLA renamings Changes: https://git.openjdk.org/jdk/pull/25545/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25545&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357821 Stats: 25 lines in 12 files changed: 0 ins; 6 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/25545.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25545/head:pull/25545 PR: https://git.openjdk.org/jdk/pull/25545 From varadam at openjdk.org Fri May 30 12:11:30 2025 From: varadam at openjdk.org (Varada M) Date: Fri, 30 May 2025 12:11:30 GMT Subject: RFR: 8358159: empty mode/padding in cipher transformations. Message-ID: Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException. This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null. Testing done for : tier1 - fastdebug level JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) ------------- Commit messages: - JDK-8358159: empty mode/padding in cipher transformations. Changes: https://git.openjdk.org/jdk/pull/25547/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25547&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358159 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25547/head:pull/25547 PR: https://git.openjdk.org/jdk/pull/25547 From sebastian.stenzel at gmail.com Fri May 30 12:40:31 2025 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Fri, 30 May 2025 14:40:31 +0200 Subject: X-Wing KEM In-Reply-To: References: Message-ID: <73235A95-D1EF-4BAA-8F1F-E90355DEFC37@gmail.com> Hi Weijun, waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet? I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC. I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on. Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1] Thank you, Sebastian [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter > On 29. May 2025, at 18:44, Wei-Jun Wang wrote: > > Hi Sebastian. > >> On May 24, 2025, at 05:40, Sebastian Stenzel wrote: >> >> Hi all, >> >> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing. >> >> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs. > > Thanks for your continued interest on enhancing OpenJDK. > > That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first. > >> >> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec? > > It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible. > >> >> Alternatively, can we make the two mentioned APIs public? > > No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral. > > [1] https://openjdk.org/guide/ > > Thanks, > Weijun > >> >> Cheers! >> Sebastian >> >> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/ >> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07 >> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mullan at openjdk.org Fri May 30 12:43:50 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 30 May 2025 12:43:50 GMT Subject: RFR: 8358159: Empty mode/padding in cipher transformations. In-Reply-To: References: Message-ID: <3Z3TT_VySGy5fZr2c39ljN34dvQo-9mPLnWnZB8gluY=.efae4a33-7a03-4d7c-8ccc-d3f6ab35b105@github.com> On Fri, 30 May 2025 12:06:21 GMT, Varada M wrote: > Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException. > This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null. > > Testing done for : tier1 - fastdebug level (AIX) > > JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) I think this should have a regression test for this change. Also, you indicated this patch restores the behavior - do you know what release this last worked in and what issue caused it to stop working? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25547#issuecomment-2922293706 From weijun.wang at oracle.com Fri May 30 13:03:26 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Fri, 30 May 2025 13:03:26 +0000 Subject: X-Wing KEM In-Reply-To: <73235A95-D1EF-4BAA-8F1F-E90355DEFC37@gmail.com> References: <73235A95-D1EF-4BAA-8F1F-E90355DEFC37@gmail.com> Message-ID: <2B84AC72-3A5E-4E81-92DF-5BF19A1100DC@oracle.com> > On May 30, 2025, at 08:40, Sebastian Stenzel wrote: > > Hi Weijun, > > waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet? Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK. > > I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC. > > I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on. I see. > > Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1] Nice to know. Sorry I didn't noticed that earlier. Thanks, Weijun > > Thank you, > Sebastian > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter > >> On 29. May 2025, at 18:44, Wei-Jun Wang wrote: >> >> Hi Sebastian. >> >>> On May 24, 2025, at 05:40, Sebastian Stenzel wrote: >>> >>> Hi all, >>> >>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing. >>> >>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs. >> >> Thanks for your continued interest on enhancing OpenJDK. >> >> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first. >> >>> >>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec? >> >> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible. >> >>> >>> Alternatively, can we make the two mentioned APIs public? >> >> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral. >> >> [1] https://openjdk.org/guide/ >> >> Thanks, >> Weijun >> >>> >>> Cheers! >>> Sebastian >>> >>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/ >>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07 >>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536 >>> >> > From mullan at openjdk.org Fri May 30 13:07:55 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 30 May 2025 13:07:55 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v4] In-Reply-To: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com> References: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com> Message-ID: On Fri, 30 May 2025 06:55:07 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? >> >> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. >> >> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. >> >> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: >> >> >> import java.net.*; >> >> public class Test { >> public static void main(String[] args) throws Exception { >> System.out.println("testing against Java " + System.getProperty("java.version")); >> >> final ClassLoader cl = new URLClassLoader(new URL[0], null); >> final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module >> System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); >> >> } >> } >> >> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: >> >> >> testing against Java 24 >> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet >> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) >> at Test.main(Test.java:8) >> >> >> No new tests have been introduced and existing tes... > > Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: > > - replace system class loader reference with bootstrap class loader > - remove "the" > - {@code null} instead of null Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25517#pullrequestreview-2881305741 From weijun at openjdk.org Fri May 30 13:10:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 30 May 2025 13:10:51 GMT Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug [v2] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 08:31:31 GMT, Sean Coffey wrote: >> Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property. >> >> >> To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data. >> >> This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data. >> >> Debug output data from use of the `java.security.debug` property will now resemble something like the following: >> >> >> >> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect. >> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast >> >> >> I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Mark I added my name as a reviewer to the CSR. The Summary section currently has "This CSR proposes to turn that data on by default". You may just say "turn that data on always". ------------- PR Comment: https://git.openjdk.org/jdk/pull/25528#issuecomment-2922354205 From mullan at openjdk.org Fri May 30 13:34:58 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 30 May 2025 13:34:58 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v16] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 10:44:11 GMT, Michael McMahon wrote: >> Hi, >> >> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP >> addresses from exception message strings, unless the enhanced mode for the specific category >> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and >> updated in 8207846. >> >> This PR aims to increase the coverage of enhanced exception messages in the networking code. >> A limited number of exceptions are already hidden (restricted) by default. The new categories and >> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced >> (while preserving the existing behavior). >> >> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value >> a comma separated list of category names, which identify groups of exceptions where the exception >> message may be enhanced. Any category not listed is "restricted" which means that potentially >> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. >> >> The changes to the java.security conf file describe the exact changes in terms of the categories now >> supported and any changes in behavior. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > Fixed problem with j.n.HostPortRange src/java.base/share/conf/security/java.security line 1282: > 1280: # Exception messages may include potentially sensitive information such as file > 1281: # names, host names, or port numbers. By default, socket related exceptions > 1282: # have this information restricted (meaning the sensitive details are removed). I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2115938656 From weijun at openjdk.org Fri May 30 13:46:51 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 30 May 2025 13:46:51 GMT Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici wrote: > Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`. > > `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries. Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2922441338 From vyazici at openjdk.org Fri May 30 14:01:55 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 30 May 2025 14:01:55 GMT Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 13:44:08 GMT, Weijun Wang wrote: > Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`. Required changes are pretty minimal ? passing `System.getProperty("stdin.encoding")` as an argument to the ctor. I doubt adding an extra layer of indirection (plus the need for changes in `@build` and `@library` tags) will worth it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2922477202 From abarashev at openjdk.org Fri May 30 14:15:35 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 30 May 2025 14:15:35 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v16] In-Reply-To: References: Message-ID: <9f5xy0VZFiUIBjyV1b2QcIEyyjd5PndA34oWBzI5VmQ=.abf989b8-0e70-43df-aa6b-a3d4a0c8fe92@github.com> > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: Update requestedServerNames reading instructions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25310/files - new: https://git.openjdk.org/jdk/pull/25310/files/24ea8947..09a9fa54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25310&range=14-15 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25310/head:pull/25310 PR: https://git.openjdk.org/jdk/pull/25310 From abarashev at openjdk.org Fri May 30 14:15:35 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 30 May 2025 14:15:35 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v15] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 01:40:59 GMT, Bradford Wetmore wrote: >> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore unit test code formatting > > src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 276: > >> 274: * < 1 byte > serverNameIndication length >> 275: * < length in bytes > serverNameIndication >> 276: * < 1 byte > Number of requestedServerNames entries > > Would you be up for doing ("for each entry") for this one too? I know this is not your code, but it's one place outstanding. > > Feel free to skip or do. Good catch, done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2116008140 From alanb at openjdk.org Fri May 30 14:27:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 May 2025 14:27:51 GMT Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici wrote: > Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`. > > `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries. test/jdk/com/sun/tools/attach/Application.java line 40: > 38: > 39: try (BufferedReader br = new BufferedReader(new InputStreamReader( > 40: System.in, System.getProperty("stdin.encoding")))) { This "application" is launched by the test so connected to the parent process rather than the console. test/jdk/java/lang/ProcessHandle/JavaChild.java line 315: > 313: // children and wait for each to exit > 314: sendResult(action, "start"); > 315: try (Reader reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding")); I didn't study the test closely but I think this is another case where a child process is launched so System.in is connected to the parent rather than the console. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2116027806 PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2116031061 From mullan at openjdk.org Fri May 30 14:28:52 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 30 May 2025 14:28:52 GMT Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug [v2] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 08:31:31 GMT, Sean Coffey wrote: >> Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property. >> >> >> To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data. >> >> This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data. >> >> Debug output data from use of the `java.security.debug` property will now resemble something like the following: >> >> >> >> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect. >> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast >> >> >> I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments from Mark What is the behavior if someone had added these options in JDK 23 and is now debugging the same code with JDK 25? Are they ignored? The CSR should also note the behavior. src/java.base/share/classes/java/security/doc-files/debug-system-property.html line 55: > 53: system property, which determines what trace messages are printed during > 54: execution. The value of the property is one or more options separated by a > 55: comma. I suggest we add a sentence to this paragraph noting that each trace message also includes the thread id, timestamp, and caller information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25528#issuecomment-2922548035 PR Review Comment: https://git.openjdk.org/jdk/pull/25528#discussion_r2116024056 From coffeys at openjdk.org Fri May 30 14:43:32 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 30 May 2025 14:43:32 GMT Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug [v3] In-Reply-To: References: Message-ID: > Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property. > > > To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data. > > This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data. > > Debug output data from use of the `java.security.debug` property will now resemble something like the following: > > > > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect. > properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast > > > I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Update property doc as per Sean Mullan comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25528/files - new: https://git.openjdk.org/jdk/pull/25528/files/0d766cc8..85babe83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25528&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25528&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25528/head:pull/25528 PR: https://git.openjdk.org/jdk/pull/25528 From coffeys at openjdk.org Fri May 30 14:47:51 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 30 May 2025 14:47:51 GMT Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for java.security.debug [v2] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 14:26:14 GMT, Sean Mullan wrote: > What is the behavior if someone had added these options in JDK 23 and is now debugging the same code with JDK 25? Are they ignored? The CSR should also note the behavior. I've added this clarification to the CSR: `Continued use of the +thread and +timestamp options will no longer have impact. The thread and timestamp data is always printed and valid security components used in the java.security.debug property will continue to be logged.` > src/java.base/share/classes/java/security/doc-files/debug-system-property.html line 55: > >> 53: system property, which determines what trace messages are printed during >> 54: execution. The value of the property is one or more options separated by a >> 55: comma. > > I suggest we add a sentence to this paragraph noting that each trace message also includes the thread id, timestamp, and caller information. Thanks. Added "Each trace message includes the thread id, timestamp and caller information." to this paragraph ------------- PR Comment: https://git.openjdk.org/jdk/pull/25528#issuecomment-2922595888 PR Review Comment: https://git.openjdk.org/jdk/pull/25528#discussion_r2116063732 From michaelm at openjdk.org Fri May 30 14:52:56 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 30 May 2025 14:52:56 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v16] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 13:32:08 GMT, Sean Mullan wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed problem with j.n.HostPortRange > > src/java.base/share/conf/security/java.security line 1282: > >> 1280: # Exception messages may include potentially sensitive information such as file >> 1281: # names, host names, or port numbers. By default, socket related exceptions >> 1282: # have this information restricted (meaning the sensitive details are removed). > > I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default. Fair point. I think we can make this clearer with a small addition. I propose to add the following sentence after the one starting "By default ..." # Exception messages relating to Jar files and exceptions containing user # identity information are also restricted by default. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2116074735 From hchao at openjdk.org Fri May 30 14:57:56 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 30 May 2025 14:57:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v28] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 01:13:48 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is complete/approved. >> >> Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Last minute codereview comments Marked as reviewed by hchao (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2881612431 From hchao at openjdk.org Fri May 30 14:57:57 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 30 May 2025 14:57:57 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v27] In-Reply-To: References: <-XLj14hX1pe2hJ13B0aDiT959Xx70KxSGNPCLArINjA=.246a3c5e-e155-4bdb-977e-2e8ff9225ee9@github.com> Message-ID: On Fri, 30 May 2025 01:25:37 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 1494: >> >>> 1492: if (exporterMasterSecret == null) { >>> 1493: throw new RuntimeException( >>> 1494: "Exporter master secret not captured"); >> >> Do you want to choose another exception type? Like `ProviderException`. Actually, how unlikely this is? If you believe this would never happen (unless there is a programming error), you can even throw an `AssertionError`. >> >> Same question in `useTLS10PlusSpec()` for the two randoms. > > @wangweij asked if `SSLSession` are ever in a partially completed state. The answer is yes, during handshaking the `SSLSocket/SSLEngine.getHandshakeSession()` methods can return `SSLSession` that is incomplete. As such, it makes more sense for this to be an `IllegalArgumentException`. > > Drafted the CSR, made the update, and refinalized it. Hopefully the wording is acceptable. ;) Updates look good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24976#discussion_r2116081641 From ascarpino at openjdk.org Fri May 30 15:57:09 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 30 May 2025 15:57:09 GMT Subject: RFR: 8358076: KeyFactory.getInstance("EdDSA").generatePublic(null) throws NPE [v2] In-Reply-To: <-pDvWyv0MbjtmiYZZ9t51UESnsQwbdyZs9lhgqm_qgg=.c9253d63-7118-49b7-b816-8ef98d347d79@github.com> References: <-pDvWyv0MbjtmiYZZ9t51UESnsQwbdyZs9lhgqm_qgg=.c9253d63-7118-49b7-b816-8ef98d347d79@github.com> Message-ID: > I need a code review to throw `InvalidKeySpecException` when null is passed with `generatePublic()` and `generatePrivate()`. This change takes the opportunity to modernize the KeyFactory code by using `switch` syntax for `instanceof` checking, as well as, keeping the previous design of the implementation method handling the null case. There are existing JCK test cover this case, so no regression test is added. Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: most should be must ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25533/files - new: https://git.openjdk.org/jdk/pull/25533/files/c5b9a941..78653485 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25533&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25533&range=00-01 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25533.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25533/head:pull/25533 PR: https://git.openjdk.org/jdk/pull/25533 From wetmore at openjdk.org Fri May 30 16:00:55 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 30 May 2025 16:00:55 GMT Subject: RFR: 8357033: Reduce stateless session ticket size [v16] In-Reply-To: <9f5xy0VZFiUIBjyV1b2QcIEyyjd5PndA34oWBzI5VmQ=.abf989b8-0e70-43df-aa6b-a3d4a0c8fe92@github.com> References: <9f5xy0VZFiUIBjyV1b2QcIEyyjd5PndA34oWBzI5VmQ=.abf989b8-0e70-43df-aa6b-a3d4a0c8fe92@github.com> Message-ID: On Fri, 30 May 2025 14:15:35 GMT, Artur Barashev wrote: >> The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. >> >> ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. >> >> When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet >> >> Things done in this PR to reduce the ticket size in order of importance: >> >> 1. Remove local certificates. >> 2. Compress tickets with the size 600 bytes or larger. >> 3. Remove `peerSupportedSignAlgs`. >> 4. Remove `pskIdentity` >> 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 >> 6. Remove `statusResponses` >> >> Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > Update requestedServerNames reading instructions LGTM. Thanks for doing that. ------------- Marked as reviewed by wetmore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25310#pullrequestreview-2881776419 From abarashev at openjdk.org Fri May 30 16:06:01 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 30 May 2025 16:06:01 GMT Subject: Integrated: 8357033: Reduce stateless session ticket size In-Reply-To: References: Message-ID: On Mon, 19 May 2025 21:11:01 GMT, Artur Barashev wrote: > The stateless session ticket is included in the ClientHello message, either in the stateless_ticket extension (pre-TLS1.3), or in the pre_shared_key extension (TLS1.3). With the current construction, the ticket is often the largest contributor to the ClientHello message size. For example, in HttpClient tests we observed a case where a non-resumption ClientHello occupied 360 bytes, and the session ticket (pre_shared_key identity) included in a resumption ClientHello occupied 1600+ bytes. > > ClientHello messages that do not fit in a single packet on the network can greatly increase the handshake time on lossy networks. Ideally we would like the ClientHello message to always fit in a single packet. > > When using QUIC as the underlying protocol, one packet can hold approximately 1100 byte payload. Getting the session ticket size below 700 bytes should be sufficient to make the ClientHello fit in a single packet > > Things done in this PR to reduce the ticket size in order of importance: > > 1. Remove local certificates. > 2. Compress tickets with the size 600 bytes or larger. > 3. Remove `peerSupportedSignAlgs`. > 4. Remove `pskIdentity` > 5. PreSharedKey is only needed by TLSv1.3, masterSecret is only needed by pre-TLSv1.3 > 6. Remove `statusResponses` > > Tickets with a chain of 2 RSA peer certificates are still above 700 bytes (about 1KB), but they are significantly reduced from prior size of about 3KB. This pull request has now been integrated. Changeset: 99048c3d Author: Artur Barashev URL: https://git.openjdk.org/jdk/commit/99048c3d4a66be9bf586949bd08e33cb091fa6bf Stats: 379 lines in 5 files changed: 140 ins; 117 del; 122 mod 8357033: Reduce stateless session ticket size Reviewed-by: wetmore, djelinski, ascarpino ------------- PR: https://git.openjdk.org/jdk/pull/25310 From mullan at openjdk.org Fri May 30 17:35:54 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 30 May 2025 17:35:54 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v16] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 14:50:28 GMT, Michael McMahon wrote: >> src/java.base/share/conf/security/java.security line 1282: >> >>> 1280: # Exception messages may include potentially sensitive information such as file >>> 1281: # names, host names, or port numbers. By default, socket related exceptions >>> 1282: # have this information restricted (meaning the sensitive details are removed). >> >> I found the "By default ..." sentence a little confusing, since other categories are also restricted by default. My initial thought is to just remove this sentence, as reading further will make it more clear that the hostInfoExclSocket category is the only one that is not restricted by default. Alternatively, you could flip the meaning of this sentence and say which exceptions are **not** restricted by default. > > Fair point. I think we can make this clearer with a small addition. I propose to add the following sentence after the one starting "By default ..." > > # Exception messages relating to Jar files and exceptions containing user > # identity information are also restricted by default. I would change "Jar" to "JAR" as I think that is the more common form and used in other places in this file. Looks fine otherwise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2116314192 From rhalade at openjdk.org Fri May 30 18:11:54 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 30 May 2025 18:11:54 GMT Subject: RFR: 8230016: re-visit test sun/security/pkcs11/Serialize/SerializeProvider.java [v3] In-Reply-To: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com> References: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com> Message-ID: <8daR64MqNFiVU89gKl21db41X0aBkoATpyD4tsz5CTM=.16be11cb-29b1-41c3-9eac-0935b94c7a15@github.com> On Wed, 30 Apr 2025 14:36:02 GMT, Mikhail Yankelevich wrote: >> Provider is now added to the Security before the test > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded check Marked as reviewed by rhalade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24750#pullrequestreview-2882060403 From duke at openjdk.org Fri May 30 18:11:54 2025 From: duke at openjdk.org (duke) Date: Fri, 30 May 2025 18:11:54 GMT Subject: RFR: 8230016: re-visit test sun/security/pkcs11/Serialize/SerializeProvider.java [v3] In-Reply-To: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com> References: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com> Message-ID: On Wed, 30 Apr 2025 14:36:02 GMT, Mikhail Yankelevich wrote: >> Provider is now added to the Security before the test > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded check @myankelev Your change (at version 5963bb5e632b66b7be71c5dc7305f497bd5fe773) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24750#issuecomment-2923065695 From duke at openjdk.org Fri May 30 18:19:13 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 30 May 2025 18:19:13 GMT Subject: RFR: 8349550: Improve SASL random usage [v4] In-Reply-To: References: Message-ID: > Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random Koushik Muthukrishnan Thirupattur has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - 8349550: Improve SASL random usage - Merge branch 'master' into 8349550 - 8349550: Improve SASL random usage - Merge branch 'master' into 8349550 - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25241/files - new: https://git.openjdk.org/jdk/pull/25241/files/599aaca2..ffaca710 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25241&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25241&range=02-03 Stats: 13368 lines in 257 files changed: 10427 ins; 2061 del; 880 mod Patch: https://git.openjdk.org/jdk/pull/25241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25241/head:pull/25241 PR: https://git.openjdk.org/jdk/pull/25241 From mullan at openjdk.org Fri May 30 19:30:58 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 30 May 2025 19:30:58 GMT Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4] In-Reply-To: References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com> Message-ID: <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com> On Fri, 18 Apr 2025 14:58:41 GMT, Matthew Donovan wrote: >> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates. >> >> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1) >> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa) >> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0) > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - expanded wildcard imports > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - reversed order of DN strings when making certificates. > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - Merge branch 'master' into certbuilder > - changed boolean array initialization > - 8325766: Review seclibs tests for cert expiry test/lib/jdk/test/lib/security/CertificateBuilder.java line 109: > 107: */ > 108: public static CertificateBuilder newCertificateBuilder(String subjectName, > 109: PublicKey publicKey, PublicKey caKey, KeyUsage... keyUsages) My suggestion is to make this a regular constructor and have an additional method that sets the certificate lifetime as a `Duration` parameter, ex: `new CertificateBuilder(subject, pubKey, caPubKey, keyUsage).withValidity(Duration.ofHours(1));` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2116514041 From weijun at openjdk.org Fri May 30 20:10:53 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 30 May 2025 20:10:53 GMT Subject: RFR: 8358076: KeyFactory.getInstance("EdDSA").generatePublic(null) throws NPE [v2] In-Reply-To: References: <-pDvWyv0MbjtmiYZZ9t51UESnsQwbdyZs9lhgqm_qgg=.c9253d63-7118-49b7-b816-8ef98d347d79@github.com> Message-ID: On Fri, 30 May 2025 15:57:09 GMT, Anthony Scarpino wrote: >> I need a code review to throw `InvalidKeySpecException` when null is passed with `generatePublic()` and `generatePrivate()`. This change takes the opportunity to modernize the KeyFactory code by using `switch` syntax for `instanceof` checking, as well as, keeping the previous design of the implementation method handling the null case. There are existing JCK test cover this case, so no regression test is added. > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > most should be must Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25533#pullrequestreview-2882406471 From ascarpino at openjdk.org Fri May 30 20:15:58 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 30 May 2025 20:15:58 GMT Subject: Integrated: 8358076: KeyFactory.getInstance("EdDSA").generatePublic(null) throws NPE In-Reply-To: <-pDvWyv0MbjtmiYZZ9t51UESnsQwbdyZs9lhgqm_qgg=.c9253d63-7118-49b7-b816-8ef98d347d79@github.com> References: <-pDvWyv0MbjtmiYZZ9t51UESnsQwbdyZs9lhgqm_qgg=.c9253d63-7118-49b7-b816-8ef98d347d79@github.com> Message-ID: On Thu, 29 May 2025 22:38:41 GMT, Anthony Scarpino wrote: > I need a code review to throw `InvalidKeySpecException` when null is passed with `generatePublic()` and `generatePrivate()`. This change takes the opportunity to modernize the KeyFactory code by using `switch` syntax for `instanceof` checking, as well as, keeping the previous design of the implementation method handling the null case. There are existing JCK test cover this case, so no regression test is added. This pull request has now been integrated. Changeset: c9d6e012 Author: Anthony Scarpino URL: https://git.openjdk.org/jdk/commit/c9d6e01233fbc9f3a95a4879feff906748649c54 Stats: 200 lines in 4 files changed: 51 ins; 20 del; 129 mod 8358076: KeyFactory.getInstance("EdDSA").generatePublic(null) throws NPE Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/25533 From michaelm at openjdk.org Fri May 30 20:50:37 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 30 May 2025 20:50:37 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v17] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: doc update to java.security ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23929/files - new: https://git.openjdk.org/jdk/pull/23929/files/3eec6c03..5970c2b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=15-16 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From michaelm at openjdk.org Fri May 30 20:58:11 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 30 May 2025 20:58:11 GMT Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v18] In-Reply-To: References: Message-ID: > Hi, > > Enhanced exception messages are designed to hide sensitive information such as hostnames, IP > addresses from exception message strings, unless the enhanced mode for the specific category > has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and > updated in 8207846. > > This PR aims to increase the coverage of enhanced exception messages in the networking code. > A limited number of exceptions are already hidden (restricted) by default. The new categories and > exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced > (while preserving the existing behavior). > > The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value > a comma separated list of category names, which identify groups of exceptions where the exception > message may be enhanced. Any category not listed is "restricted" which means that potentially > sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text. > > The changes to the java.security conf file describe the exact changes in terms of the categories now > supported and any changes in behavior. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with two additional commits since the last revision: - doc update to java.security - removed jmod/Handler change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23929/files - new: https://git.openjdk.org/jdk/pull/23929/files/5970c2b3..4aad0141 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=16-17 Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929 PR: https://git.openjdk.org/jdk/pull/23929 From wetmore at openjdk.org Fri May 30 21:32:38 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 30 May 2025 21:32:38 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v29] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is complete/approved. > > Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge branch 'master' into JDK-8341346 - Merge branch 'master' into JDK-8341346 - Last minute codereview comments - Merge branch 'master' into JDK-8341346 - Remove TlsExporterKeyingMaterial for now. Can add later if needed. - Merge branch 'master' into JDK-8341346 - Merge branch 'master' into JDK-8341346 - Added PKCS11 testing - Minor bug - Missed one change - ... and 30 more: https://git.openjdk.org/jdk/compare/db340e54...07fda411 ------------- Changes: https://git.openjdk.org/jdk/pull/24976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=28 Stats: 1043 lines in 9 files changed: 1023 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From wetmore at openjdk.org Fri May 30 21:58:38 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 30 May 2025 21:58:38 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v30] In-Reply-To: References: Message-ID: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is complete/approved. > > Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Resolved Merge Problem ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24976/files - new: https://git.openjdk.org/jdk/pull/24976/files/07fda411..d0cf6917 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24976&range=28-29 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24976/head:pull/24976 PR: https://git.openjdk.org/jdk/pull/24976 From jnimeh at openjdk.org Fri May 30 21:58:38 2025 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Fri, 30 May 2025 21:58:38 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v30] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 21:54:55 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is complete/approved. >> >> Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Resolved Merge Problem Marked as reviewed by jnimeh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2882629576 From hchao at openjdk.org Fri May 30 22:01:56 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 30 May 2025 22:01:56 GMT Subject: RFR: 8341346: Add support for exporting TLS Keying Material [v30] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 21:58:38 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. >> >> CSR is complete/approved. >> >> Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) > > Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: > > Resolved Merge Problem Marked as reviewed by hchao (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24976#pullrequestreview-2882635456 From wetmore at openjdk.org Fri May 30 23:09:00 2025 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 30 May 2025 23:09:00 GMT Subject: Integrated: 8341346: Add support for exporting TLS Keying Material In-Reply-To: References: Message-ID: <292ACWvjhRB891IoH8NFr12kx8tjJsDBunsx7LsuhT4=.3e57f29d-370d-40ea-8dd8-7c03a9583313@github.com> On Wed, 30 Apr 2025 22:39:47 GMT, Bradford Wetmore wrote: > Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE respectively. > > CSR is complete/approved. > > Tests include new unit tests for TLSv1-1.3. Have run tier1-2, plus the JCK API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net jck:api/javax_security jck:api/org_ietf jck:api/javax_xml/crypto) This pull request has now been integrated. Changeset: 2926435d Author: Bradford Wetmore URL: https://git.openjdk.org/jdk/commit/2926435d228f21a227763ff4efcf32e511aa258a Stats: 1043 lines in 9 files changed: 1023 ins; 0 del; 20 mod 8341346: Add support for exporting TLS Keying Material Reviewed-by: hchao, jnimeh, weijun ------------- PR: https://git.openjdk.org/jdk/pull/24976 From syan at openjdk.org Sat May 31 02:34:55 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 31 May 2025 02:34:55 GMT Subject: RFR: 8230016: re-visit test sun/security/pkcs11/Serialize/SerializeProvider.java [v3] In-Reply-To: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com> References: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com> Message-ID: On Wed, 30 Apr 2025 14:36:02 GMT, Mikhail Yankelevich wrote: >> Provider is now added to the Security before the test > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded check test/jdk/sun/security/pkcs11/Serialize/SerializeProvider.java line 60: > 58: ObjectInputStream oin = new ObjectInputStream(in); > 59: > 60: Provider p2 = (Provider) oin.readObject(); Hi, does the added whitespace really neeed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24750#discussion_r2117076216 From ecki at zusammenkunft.net Sat May 31 07:01:33 2025 From: ecki at zusammenkunft.net (ecki) Date: Sat, 31 May 2025 09:01:33 +0200 Subject: Quantum Resistant hybrid key exchange In-Reply-To: References: Message-ID: <0C220CEF-D3D9-DB46-80F5-E40EC5BA221F@hxcore.ol> An HTML attachment was scrubbed... URL: From myankelevich at openjdk.org Sat May 31 09:19:53 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Sat, 31 May 2025 09:19:53 GMT Subject: RFR: 8230016: re-visit test sun/security/pkcs11/Serialize/SerializeProvider.java [v3] In-Reply-To: References: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com> Message-ID: On Sat, 31 May 2025 02:32:38 GMT, SendaoYan wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> removed unneeded check > > test/jdk/sun/security/pkcs11/Serialize/SerializeProvider.java line 60: > >> 58: ObjectInputStream oin = new ObjectInputStream(in); >> 59: >> 60: Provider p2 = (Provider) oin.readObject(); > > Hi, does the added whitespace really neeed. Functionally it doesn't make any difference afaik. However, it is generally advisable to have a white space after a cast. Here are 2 popular Java styles (Google and Sun) and one cr form openjdk itself: [https://www.oracle.com/docs/tech/java/codeconventions.pdf](https://www.oracle.com/docs/tech/java/codeconventions.pdf) paragraph 8.2 [https://cr.openjdk.org/~alundblad/styleguide/index-v6.html](https://cr.openjdk.org/~alundblad/styleguide/index-v6.html) paragraph Horizontal Whitespace [https://google.github.io/styleguide/javaguide.html](https://google.github.io/styleguide/javaguide.html) paragraph 4.6.2 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24750#discussion_r2117614490 From jpai at openjdk.org Sat May 31 13:05:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 31 May 2025 13:05:56 GMT Subject: RFR: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null [v4] In-Reply-To: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com> References: <1icrllwoK6mShaz9AOdx2PDwaVCQ-1Ne9w-N5o64-cc=.de4fc6c4-5d75-457d-9a71-84daf23b0f75@github.com> Message-ID: On Fri, 30 May 2025 06:55:07 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? >> >> As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. >> >> Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. >> >> Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: >> >> >> import java.net.*; >> >> public class Test { >> public static void main(String[] args) throws Exception { >> System.out.println("testing against Java " + System.getProperty("java.version")); >> >> final ClassLoader cl = new URLClassLoader(new URL[0], null); >> final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module >> System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); >> >> } >> } >> >> which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: >> >> >> testing against Java 24 >> Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet >> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) >> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) >> at Test.main(Test.java:8) >> >> >> No new tests have been introduced and existing tes... > > Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: > > - replace system class loader reference with bootstrap class loader > - remove "the" > - {@code null} instead of null Thank you all for the reviews. The CSR has been approved. I'll go ahead with the integration now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25517#issuecomment-2925161327 From jpai at openjdk.org Sat May 31 13:05:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 31 May 2025 13:05:57 GMT Subject: Integrated: 8228773: URLClassLoader constructors should include API note warning that the parent should not be null In-Reply-To: References: Message-ID: On Thu, 29 May 2025 05:57:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this doc-only change which proposes to add an `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader` to explain the current implementation of these constructors? This addresses https://bugs.openjdk.org/browse/JDK-8228773? > > As noted in that issue, this updated documentation is to help applications be aware that a `null` value which represents the bootstrap class loader when passed for `parent` class loader will mean that the constructed `URLClassLoader` may not be able to load all platform classes. > > Specifically, only a specific set of modules are mapped (at JDK build time) to the bootstrap class loader. Some modules like `java.sql` are visible to the platform class loader but not to the bootstrap classloader. The distinction between these class loaders is explained in the API documentation of `ClassLoader` class https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ClassLoader.html#builtinLoaders. > > Using `null` (which represents a bootstrap class loader) for `parent` when constructing the `URLClassLoader` then means that the class loader would not be able to load some of these platform classes. For example, consider: > > > import java.net.*; > > public class Test { > public static void main(String[] args) throws Exception { > System.out.println("testing against Java " + System.getProperty("java.version")); > > final ClassLoader cl = new URLClassLoader(new URL[0], null); > final Class klass = cl.loadClass("java.sql.ResultSet"); // load a platform class that belongs to the java.sql module > System.out.println("loaded " + klass + " using classloader: " + klass.getClassLoader()); > > } > } > > which constructs the `URLClassLoader` with the bootstrap class loader as its parent and then attempts to load a platform class `java.sql.ResultSet`. Since this class' module is mapped to the platform class loader and not the bootstrap class loader, running this code against Java 9+ will result in a `ClassNotFoundException`: > > > testing against Java 24 > Exception in thread "main" java.lang.ClassNotFoundException: java.sql.ResultSet > at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:349) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:557) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490) > at Test.main(Test.java:8) > > > No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass. > > Once we settle on th... This pull request has now been integrated. Changeset: 84002d12 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/84002d12ed83c8254422fdda349aa647422d0768 Stats: 57 lines in 2 files changed: 42 ins; 0 del; 15 mod 8228773: URLClassLoader constructors should include API note warning that the parent should not be null Reviewed-by: alanb, mullan ------------- PR: https://git.openjdk.org/jdk/pull/25517