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