From mpowers at openjdk.org  Wed Oct  1 00:30:31 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 1 Oct 2025 00:30:31 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
Message-ID: <jrVYf8HDTOdQAi_tHEV3hwUCwWCDe6af43xb913BE6E=.cd4a8989-6487-4101-9804-7db7c50a846f@github.com>

On Mon, 29 Sep 2025 21:02:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another day another iteration
>
> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 184:
> 
>> 182:      * Returns a formatted string describing the parameters.
>> 183:      */
>> 184:     public String engineToString() {
> 
> Useless now. Therefore, `pbmac1AlgorithmName` is also useless.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 262:
> 
>> 260:                 "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256");
>> 261:         try {
>> 262:             int keyLength = Hmac.equals("HmacSHA512") ? 64*8 : 32*8;
> 
> Use `Mac.getInstance(Hmac).getMacLength()`. There are other algorithms.

Good Suggestion.

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 287:
> 
>> 285:         return mData;
>> 286:     }
>> 287: 
> 
> For all methods below, unless one is used outside of this class, there is no need to create a getter method.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2393136697
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2393136206
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2393136376

From mpowers at openjdk.org  Wed Oct  1 00:30:33 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 1 Oct 2025 00:30:33 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <agbb6TKJjPXL0KsGX2DD1OwmakAqwX7S-hyYYsu8XW8=.86305721-6110-4ffa-b437-c042be2fe1db@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
 <agbb6TKJjPXL0KsGX2DD1OwmakAqwX7S-hyYYsu8XW8=.86305721-6110-4ffa-b437-c042be2fe1db@github.com>
Message-ID: <3ABjFa83fX8uubyIb0Ul91MB2vzWon5_0usArF0YRYg=.dd16cdd2-0566-4b45-91aa-407b7104fe25@github.com>

On Mon, 29 Sep 2025 20:46:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 260:
>> 
>>> 258: 
>>> 259:         var skf = SecretKeyFactory.getInstance(kdfHmac.equals("HmacSHA512") ?
>>> 260:                 "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256");
>> 
>> Why not just use `"PBKDF2With" + kdfHmac`? What if `kdfHmac` is "HmacSHA384"?
>
> Also, for old algorithms, this `SecretKeyFactory` should not be used, even if the final result can also be used. Use the old `getPBEKey` code here.

Fixed both. Tested with HmacSHA384 using keystore generated by `openssl` command.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2393135787

From mpowers at openjdk.org  Wed Oct  1 00:30:34 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 1 Oct 2025 00:30:34 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v7]
In-Reply-To: <qf79Wtj6vq4G-Aa3Tf4E75wl2kb53Q4iovvQivSoq1U=.c34e95e8-c33b-48bd-b22b-9a9efa22014e@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <Wlfzh3j_8gt3FJ6R8U4q4QBBp56zm6t71f4Lo_VnwA0=.7ae9adde-c0bd-4696-93e7-8526473969e1@github.com>
 <_o21Ka_ZkI3a5noqBvHjwynh4ceOQ1gIIdJC2xlJkUk=.4ed60c3f-5ea9-4fdf-9f8e-576349544c77@github.com>
 <ANbU7hdfH-huNvKFTmhyzYZZxz_XTdgfY2AcSr4SMoY=.afb9f714-b916-4fe9-8baf-90cb86f3804a@github.com>
 <qf79Wtj6vq4G-Aa3Tf4E75wl2kb53Q4iovvQivSoq1U=.c34e95e8-c33b-48bd-b22b-9a9efa22014e@github.com>
Message-ID: <zPZ0WzI4L6WXMKePtTbMsuqc5GOQcSO9--aYaolo-lg=.9a1ef59d-0577-421b-931a-cb418ac81827@github.com>

On Tue, 30 Sep 2025 11:28:32 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> A4-A6 are expected to throw an exception. That's why I catch the exception and print "pass".
>> Am I missing something?
>
> As you say, `load()` is expected to throw an exception so if it doesn't, the test should fail. Without throwing an explicit exception after `ks.load()`, the test will still pass.
> 
> Suggestion:
> 
>                     try {
>                         ks = KeyStore.getInstance("PKCS12");
>                         ks.load(...);
>                         throw new Exception("The expected exception was not thrown.");
>                     } catch (Exception expected) {
>                         System.out.println("PASS");
>                     }

I see it now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2393139000

From matthias.baesken at sap.com  Wed Oct  1 13:14:52 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 1 Oct 2025 13:14:52 +0000
Subject: OS & JVM keystores
Message-ID: <DU2PR02MB10258B3A343C4C404349F02B593E6A@DU2PR02MB10258.eurprd02.prod.outlook.com>

Hi , we were recently asked if it is possible to have in Java something like a "union" of the Java certs and the system keystore.

Currently it seems only be possible to use one of them, e.g. a) use the Java cacerts or  b) switch fully to the system keystore (on Windows, there seems to be -Djavax.net.ssl.trustStoreType=Windows-ROOT )

For a more detailed discussion see

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/929<https://urldefense.com/v3/__https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/929__;!!ACWV5N9M2RV99hQ!MZG04zXcn4IlpyOa_UDJl2-Fzb8aajztWecVbGgy74qgYbxtucZFIoV_fZpyk__sk3QIXQc7xqj3ZlRNAaE8Tm_Iz8I$>

"What we would need is a union of both keystores, which is currently not possible (neither is accessing the 'System Roots' nor is telling the JVM to use a union of multiple stores)."

and also
https://github.com/eclipse-packaging/packages/pull/224<https://urldefense.com/v3/__https://github.com/eclipse-packaging/packages/pull/224__;!!ACWV5N9M2RV99hQ!MZG04zXcn4IlpyOa_UDJl2-Fzb8aajztWecVbGgy74qgYbxtucZFIoV_fZpyk__sk3QIXQc7xqj3ZlRNAaE8j4QB9Iw$>


Sean Coffey also pointed out that there is the option of  implementing  an own 'TrustManagerFactory' implementation via addition of a provider  (currently, only the JSSE provider provides such functionality by default. e.g. entry point to loading trusted certs would be via this code: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java#L48<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java*L48__;Iw!!ACWV5N9M2RV99hQ!Pdqi9KrO5AO_y6ZznwdSXbEoDEQHWDkIys-OOLQmQl134sT8OK4RyzRqIXu3e8oEQF3tnVeGP1Tnju0HOYp5hiQwZos$>   ).


 So is there some plan to have such a "union" / merging directly in  the JDK  ?
Or any hints how to handle this ?

(seems there are some people building a "union" / merged trustStore with scripts but this looks a bit like a hack to me and will not work for all users)


Best regards, Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20251001/bfb2da8c/attachment-0001.htm>

From myankelevich at openjdk.org  Wed Oct  1 13:52:24 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 1 Oct 2025 13:52:24 GMT
Subject: RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider [v2]
In-Reply-To: <44icvjzKcQKQluE3bn9tbleAnD5kqDt4sXBs2vaVHAY=.1042d1b0-53dd-4bcc-bb2d-1d8b170a3c3a@github.com>
References: <UinqQ-Wm48c6ihJchiUZ8T7oIpM3WwTzF2mtRk1wj6E=.b085b8aa-0945-4e27-be7e-fd87c7ec62c4@github.com>
 <44icvjzKcQKQluE3bn9tbleAnD5kqDt4sXBs2vaVHAY=.1042d1b0-53dd-4bcc-bb2d-1d8b170a3c3a@github.com>
Message-ID: <CggOP62hs8EkUQc5c1gfl71aNIJC--FCZ1QEZ8k6JOw=.5d23b6de-4ef0-45df-b012-6be232286d86@github.com>

On Tue, 30 Sep 2025 08:14:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Change SunJSSE to use `TlsUpdateNplus1` instead of `AES` as the key algorithm when deriving the next application traffic secret.
>> 
>> SunPKCS11 provider checks the key length when creating an `AES` key, and since 384 bits is not a valid AES key length, the key creation fails.
>> 
>> `TlsUpdateNplus1` is [already recognized](https://github.com/openjdk/jdk/blob/3c9fd7688f4d73067db9b128c329ca7603a60578/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L287) as a standard TLS generic key by SunPKCS11.
>> 
>> Key update is now exercised by the FipsModeTLS test. The test passes with the changes, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove isIv
>  - Replace if/else with ternary

src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 204:

> 202:         int getKeyLength(CipherSuite cs) {
> 203:             return switch (this) {
> 204:                 case TlsUpdateNplus1 -> cs.hashAlg.hashLength;

I believe this is not covered by any tests, do you think the test could be amended to cover this case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27498#discussion_r2394640235

From djelinski at openjdk.org  Wed Oct  1 14:49:28 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 1 Oct 2025 14:49:28 GMT
Subject: RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider [v2]
In-Reply-To: <CggOP62hs8EkUQc5c1gfl71aNIJC--FCZ1QEZ8k6JOw=.5d23b6de-4ef0-45df-b012-6be232286d86@github.com>
References: <UinqQ-Wm48c6ihJchiUZ8T7oIpM3WwTzF2mtRk1wj6E=.b085b8aa-0945-4e27-be7e-fd87c7ec62c4@github.com>
 <44icvjzKcQKQluE3bn9tbleAnD5kqDt4sXBs2vaVHAY=.1042d1b0-53dd-4bcc-bb2d-1d8b170a3c3a@github.com>
 <CggOP62hs8EkUQc5c1gfl71aNIJC--FCZ1QEZ8k6JOw=.5d23b6de-4ef0-45df-b012-6be232286d86@github.com>
Message-ID: <TRRkR7fRHMTy-cWE8rf26I7iMHirHFgBryD1j1-iWTs=.531200d3-d8a6-4725-a0db-290895530c26@github.com>

On Wed, 1 Oct 2025 13:43:15 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove isIv
>>  - Replace if/else with ternary
>
> src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 204:
> 
>> 202:         int getKeyLength(CipherSuite cs) {
>> 203:             return switch (this) {
>> 204:                 case TlsUpdateNplus1 -> cs.hashAlg.hashLength;
> 
> I believe this is not covered by any tests, do you think the test could be amended to cover this case?

There are no functional changes to getKeyLength; this is purely a refactoring. Any bugs in this code would be caught by interop testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27498#discussion_r2394884939

From myankelevich at openjdk.org  Wed Oct  1 16:24:26 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 1 Oct 2025 16:24:26 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available
In-Reply-To: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
Message-ID: <JY452lAyC4opIYSsFcpKgA-TikUweAjgRKsrqrPVN4E=.84cb55c0-6f05-43b6-a1b4-abad6489d241@github.com>

On Thu, 25 Sep 2025 14:27:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.

test/jdk/sun/security/provider/acvp/Launcher.java line 124:

> 122:         } catch (IOException e) {
> 123:             if (e.getMessage().contains("Cannot find the artifact ACVP-Server")) {
> 124:                 throw new SkippedException("ACVP-Server not available, skip test.");

nit: 
Suggestion:

                throw new SkippedException("ACVP-Server not available.");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27491#discussion_r2395162470

From mark.reinhold at oracle.com  Wed Oct  1 17:03:55 2025
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Wed, 1 Oct 2025 17:03:55 +0000
Subject: New candidate JEP: 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
Message-ID: <20250930171429.924CF81F974@eggemoggin.niobe.net>

https://openjdk.org/jeps/527

  Summary: Enhance the security of Java applications that require secure
  network communication by implementing hybrid key exchange algorithms
  for TLS 1.3.  Such algorithms defend against future quantum computing
  attacks by combining a quantum-resistant algorithm with a traditional
  algorithm.  Applications that use the javax.net.ssl APIs will benefit
  from these improved algorithms by default, without change to existing
  code.

- Mark

From bchristi at openjdk.org  Wed Oct  1 18:38:55 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 1 Oct 2025 18:38:55 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v3]
In-Reply-To: <TBC_-bS0wveSnqaD7o2rlRCMe_gfBMJDaHTeO6tPJ8s=.751b9545-3c0b-4600-8976-df931df8c1ee@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <TBC_-bS0wveSnqaD7o2rlRCMe_gfBMJDaHTeO6tPJ8s=.751b9545-3c0b-4600-8976-df931df8c1ee@github.com>
Message-ID: <5jy7TESrdbKHEh9oS_BZHjUh-mvL5lhoMlihE1XCXIY=.98295122-bc66-4b80-810d-47cbf3197fc3@github.com>

On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unused code
>  - removed the commented out code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 688:

> 686: 
> 687:                     flushAndCloseOutputStream();
> 688:                     // 8313657 socket is not closed until GC is run

Would it be worth keeping a comment here about why `sock` is not closed, or at least mentioning 8362268?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2395496537

From ecki at zusammenkunft.net  Wed Oct  1 18:52:00 2025
From: ecki at zusammenkunft.net (ecki)
Date: Wed, 1 Oct 2025 20:52:00 +0200
Subject: OS & JVM keystores
In-Reply-To: <DU2PR02MB10258B3A343C4C404349F02B593E6A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB10258B3A343C4C404349F02B593E6A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <06B54461-5C43-2546-A935-5BD830A44C04@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20251001/8b26883f/attachment.htm>

From sean.mullan at oracle.com  Wed Oct  1 19:01:14 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 1 Oct 2025 15:01:14 -0400
Subject: OS & JVM keystores
In-Reply-To: <DU2PR02MB10258B3A343C4C404349F02B593E6A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB10258B3A343C4C404349F02B593E6A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <caab79d9-cf1f-465a-95f4-37d26e4b5ef0@oracle.com>

Hi,

There is already a feature in the JDK that is close to what you are 
looking for. There is a KeyStore type called "DKS" (called the 
DomainKeyStore). See 
https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/security/DomainLoadStoreParameter.html 
for more info on how to configure it.

Basically, it uses a config file to present a collection of keystores as 
one logical keystore.

Currently there is no way to specify the configuration file as a system 
property, so you would have to write a custom TrustManagerFactory.

I would try seeing if this solution is workable and we can think about 
whether adding a system property for the config file is something that 
would be useful.

--Sean

On 10/1/25 9:14 AM, Baesken, Matthias wrote:
>
> Hi , we were recently asked if it is possible to have in Java 
> something like a "union" of the Java certs and the system keystore.
>
> Currently it seems only be possible to use one of them, e.g. a) use 
> the Java cacerts or? b) switch fully to the system keystore (on 
> Windows, there seems to be -Djavax.net.ssl.trustStoreType=Windows-ROOT )
>
> For a more detailed discussion see
>
> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/929 
> <https://urldefense.com/v3/__https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/929__;!!ACWV5N9M2RV99hQ!MZG04zXcn4IlpyOa_UDJl2-Fzb8aajztWecVbGgy74qgYbxtucZFIoV_fZpyk__sk3QIXQc7xqj3ZlRNAaE8Tm_Iz8I$>
>
> *"What we would need is a union of both keystores, which is currently 
> not possible (neither is accessing the 'System Roots' nor is telling 
> the JVM to use a union of multiple stores)."*
>
> and also
>
> https://github.com/eclipse-packaging/packages/pull/224 
> <https://urldefense.com/v3/__https://github.com/eclipse-packaging/packages/pull/224__;!!ACWV5N9M2RV99hQ!MZG04zXcn4IlpyOa_UDJl2-Fzb8aajztWecVbGgy74qgYbxtucZFIoV_fZpyk__sk3QIXQc7xqj3ZlRNAaE8j4QB9Iw$>
>
> Sean Coffey also pointed out that there is the option of implementing 
> ?an own 'TrustManagerFactory' implementation via addition of a 
> provider? (currently, only the JSSE provider provides such 
> functionality by default. e.g. entry point to loading trusted certs 
> would be via this code: 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java#L48 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java*L48__;Iw!!ACWV5N9M2RV99hQ!Pdqi9KrO5AO_y6ZznwdSXbEoDEQHWDkIys-OOLQmQl134sT8OK4RyzRqIXu3e8oEQF3tnVeGP1Tnju0HOYp5hiQwZos$> 
> ).
>
> ?So is there some plan to have such a "union" / merging directly in 
> ?the JDK ??
>
> Or any hints how to handle this ?
>
> (seems there are some people building a "union" / merged trustStore 
> with scripts but this looks a bit like a hack to me and will not work 
> for all users)
>
> Best regards, Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20251001/b05fc2ea/attachment-0001.htm>

From weijun at openjdk.org  Wed Oct  1 21:20:26 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Oct 2025 21:20:26 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <j7mcC0LYDigWC8xays2YETA96yfGKZMBtY_xxbJ_5t4=.1c71e850-38a6-4a08-b1cd-0b1350d60bd7@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

Comments on the APIs.

src/java.base/share/classes/java/security/PEM.java line 98:

> 96:      * formatted.
> 97:      * @throws NullPointerException if {@code type} and/or {@code content} are
> 98:      * {@code null}.

No need to add a period at the end if it's not a full sentence. There are several places in this file.

src/java.base/share/classes/java/security/PEM.java line 117:

> 115:      * {@code content} data in String form.  {@code leadingData} is set to null.
> 116:      *
> 117:      * @param type the PEM type identifier

In the other constructor, the words are "the type identifier". Please be consistent.

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

> 74:  *  decryption)</li>
> 75:  *  <li>ENCRYPTED PRIVATE KEY : {@code PKCS8EncodedKeySpec} (if configured with
> 76:  *  decryption)</li>

Plus "and passed as a Class parameter".

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

> 117:  * {@snippet lang = java:
> 118:  *     PEMDecoder pd = PEMDecoder.of();
> 119:  *     PrivateKey priKey = pd.decode(priKeyPEM, PrivateKey.class);

In the 2nd example below, indent `withFactory(provider);` with 8 spaces.

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

> 331:      *
> 332:      * <p> This method reads the {@code String} until PEM data is found
> 333:      * or the end of the {@code String} is reached.  If no PEM data is found,

Three lines above. Do we need to say "tClass must extend DEREncodable"? The `<S extends DEREncodable>` style means it has to be.

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

> 372:      * the PEM footer or the end of the stream. If an I/O error occurs,
> 373:      * the read position in the stream may become inconsistent.
> 374:      * It is recommended to perform no further decoding operations

Three lines above. Is it better to say "until the end of the first PEM footer"? Same with the other decode-from-stream method.

src/java.base/share/classes/java/security/PEMEncoder.java line 43:

> 41: import java.util.Objects;
> 42: import java.util.concurrent.locks.ReentrantLock;
> 43: 

In the 2nd line below, you used "store and transfer security objects". Let's all use "cryptographic objects". Same in `PEMDecoder`.

src/java.base/share/classes/java/security/PEMEncoder.java line 61:

> 59:  * which takes a password and returns a new {@code PEMEncoder} instance
> 60:  * configured to encrypt the key with that password. Alternatively, a
> 61:  * private key encrypted as an {@code EncryptedKeyInfo} object can be encoded

Typo, it's `EncryptedPrivateKeyInfo`. Maybe add a link.

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

> 66:  * contain both private and public keys.
> 67:  * {@link KeyPair} objects passed to the {@code encode} or
> 68:  * {@code encodeToString} methods are encoded as a

Three lines above. Should "OneAsymmetricKey" be fixed-width `OneAsymmetricKey`?

src/java.base/share/classes/java/security/PEMEncoder.java line 69:

> 67:  * {@link KeyPair} objects passed to the {@code encode} or
> 68:  * {@code encodeToString} methods are encoded as a
> 69:  * OneAsymmetricKey structure using the "PRIVATE KEY" type.

Should "OneAsymmetricKey" be fixed-width `OneAsymmetricKey`? Also, 4 lines above here.

src/java.base/share/classes/java/security/PEMEncoder.java line 95:

> 93:  *  <li>{@code PKCS8EncodedKeySpec} (if configured with encryption) :
> 94:  *  ENCRYPTED PRIVATE KEY</li>
> 95:  *  <li>{@code PEM} : {@code PEM.type()}</li>

`X509EncodedKeySpec` missing.

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

> 328: 
> 329:     /**
> 330:      * Creates and encrypts an {@code EncryptedPrivateKeyInfo} from a given

I know the line above is not new, but it sounds strange to me. You cannot encrypt something that is already named "encrypted".

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

> 366:      */
> 367:     @PreviewFeature(feature = PreviewFeature.Feature.PEM_API)
> 368:     public static EncryptedPrivateKeyInfo encryptKey(DEREncodable de,

Shall we name it `encryptKey` or simply `encrypt`? I'm asking because it can be something other than a key. The decrypt side has `getKey`, `getKeySpec`, and `getKayPair`. Since we have only one on the encrypt side, it needn't use the noun of one of them.

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

> 457:     public static EncryptedPrivateKeyInfo encryptKey(DEREncodable de,
> 458:         Key encryptKey, String algorithm, AlgorithmParameterSpec params,
> 459:         Provider provider, SecureRandom random) {

Technically, must `encryptKey` be a PBE key? Can it be any key? I notice that PBE is not mentioned in `getKey`.

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

PR Review: https://git.openjdk.org/jdk/pull/27147#pullrequestreview-3290505282
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395706082
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395700263
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395742704
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395761939
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395797969
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395782621
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395714807
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395720590
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395722689
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395724602
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395729138
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395505870
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395494777
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395575014

From weijun at openjdk.org  Wed Oct  1 21:20:28 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Oct 2025 21:20:28 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <j7mcC0LYDigWC8xays2YETA96yfGKZMBtY_xxbJ_5t4=.1c71e850-38a6-4a08-b1cd-0b1350d60bd7@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <j7mcC0LYDigWC8xays2YETA96yfGKZMBtY_xxbJ_5t4=.1c71e850-38a6-4a08-b1cd-0b1350d60bd7@github.com>
Message-ID: <ZBj_bazRX5r3eYcR6JR6bbp_oYqTdcfSzVkKkh6-Vts=.829810f4-1f68-448b-b129-464dcd40407d@github.com>

On Wed, 1 Oct 2025 20:02:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed some decoder comments
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 76:
> 
>> 74:  *  decryption)</li>
>> 75:  *  <li>ENCRYPTED PRIVATE KEY : {@code PKCS8EncodedKeySpec} (if configured with
>> 76:  *  decryption)</li>
> 
> Plus "and passed as a Class parameter".

You can also decode `PRIVATE KEY` or `ENCRYPTED PRIVATE KEY` into a `PublicKey` if it's passed as a class parameter, right?

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 368:
> 
>> 366:      */
>> 367:     @PreviewFeature(feature = PreviewFeature.Feature.PEM_API)
>> 368:     public static EncryptedPrivateKeyInfo encryptKey(DEREncodable de,
> 
> Shall we name it `encryptKey` or simply `encrypt`? I'm asking because it can be something other than a key. The decrypt side has `getKey`, `getKeySpec`, and `getKayPair`. Since we have only one on the encrypt side, it needn't use the noun of one of them.

I cannot comment on the `@param provider` line. Shall we change "the Provider will be used" to "the Provider used"? This is consistent with `getKeyPair`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395748169
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395527848

From weijun at openjdk.org  Wed Oct  1 21:20:29 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 1 Oct 2025 21:20:29 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <ZBj_bazRX5r3eYcR6JR6bbp_oYqTdcfSzVkKkh6-Vts=.829810f4-1f68-448b-b129-464dcd40407d@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <j7mcC0LYDigWC8xays2YETA96yfGKZMBtY_xxbJ_5t4=.1c71e850-38a6-4a08-b1cd-0b1350d60bd7@github.com>
 <ZBj_bazRX5r3eYcR6JR6bbp_oYqTdcfSzVkKkh6-Vts=.829810f4-1f68-448b-b129-464dcd40407d@github.com>
Message-ID: <FpjV0TCxbO_scW1i0VMc1GSjJvBB4GosgtWE63l3CEE=.70e611e1-8719-4c96-8dc4-05746c0ed31d@github.com>

On Wed, 1 Oct 2025 18:46:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 368:
>> 
>>> 366:      */
>>> 367:     @PreviewFeature(feature = PreviewFeature.Feature.PEM_API)
>>> 368:     public static EncryptedPrivateKeyInfo encryptKey(DEREncodable de,
>> 
>> Shall we name it `encryptKey` or simply `encrypt`? I'm asking because it can be something other than a key. The decrypt side has `getKey`, `getKeySpec`, and `getKayPair`. Since we have only one on the encrypt side, it needn't use the noun of one of them.
>
> I cannot comment on the `@param provider` line. Shall we change "the Provider will be used" to "the Provider used"? This is consistent with `getKeyPair`.

I also cannot comment on the `@throws NullPointerException` line. How about changing ". If" there to ", or if"? This appears in other methods as well.

Also, for other places when an NPE is thrown, sometimes you use "when the key or password is null", sometimes it's "if the key or password are null". Please use the same wording.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2395535170

From valeriep at openjdk.org  Thu Oct  2 01:10:51 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 2 Oct 2025 01:10:51 GMT
Subject: RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider [v2]
In-Reply-To: <44icvjzKcQKQluE3bn9tbleAnD5kqDt4sXBs2vaVHAY=.1042d1b0-53dd-4bcc-bb2d-1d8b170a3c3a@github.com>
References: <UinqQ-Wm48c6ihJchiUZ8T7oIpM3WwTzF2mtRk1wj6E=.b085b8aa-0945-4e27-be7e-fd87c7ec62c4@github.com>
 <44icvjzKcQKQluE3bn9tbleAnD5kqDt4sXBs2vaVHAY=.1042d1b0-53dd-4bcc-bb2d-1d8b170a3c3a@github.com>
Message-ID: <kK9NQgnuF8X9G5Yq0UgeWzmhuqoQyDxHYf4PfH4ubro=.6e70c3d0-a94c-4cf8-a15a-a03da73d35fc@github.com>

On Tue, 30 Sep 2025 08:14:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Change SunJSSE to use `TlsUpdateNplus1` instead of `AES` as the key algorithm when deriving the next application traffic secret.
>> 
>> SunPKCS11 provider checks the key length when creating an `AES` key, and since 384 bits is not a valid AES key length, the key creation fails.
>> 
>> `TlsUpdateNplus1` is [already recognized](https://github.com/openjdk/jdk/blob/3c9fd7688f4d73067db9b128c329ca7603a60578/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L287) as a standard TLS generic key by SunPKCS11.
>> 
>> Key update is now exercised by the FipsModeTLS test. The test passes with the changes, fails without them. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove isIv
>  - Replace if/else with ternary

Changes look good to me. Thanks~

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27498#pullrequestreview-3291762196

From mdonovan at openjdk.org  Thu Oct  2 11:31:47 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 2 Oct 2025 11:31:47 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <pI0eJIHdSw72R3vuyOWeNuDZv796bVjCvaFFDag_m94=.fd65f249-5b40-408f-92e4-c85c4948fb42@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
 <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
 <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>
 <cnqT7g1JdcDC0IjD8h386mUWQPL9AgcQOW_Djrjz4l4=.06a5f9be-ad54-4466-936d-7a443560cd2b@github.com>
 <pI0eJIHdSw72R3vuyOWeNuDZv796bVjCvaFFDag_m94=.fd65f249-5b40-408f-92e4-c85c4948fb42@github.com>
Message-ID: <HMDr8G0o2N5E4sAZr328oSrzLmNeIUNW8ct5-VVYwSU=.e77bf9c5-727b-456a-b095-98e2306a62a2@github.com>

On Mon, 4 Aug 2025 13:46:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> I think we should either implement a public API to provide those signature schemes or not display them at all to avoid any confusion. If someone sets `jdk.tls.client.SignatureSchemes` system property they would sure know about it. That property overrides all other signature schemes for both "signature_algorithms" and "signature_algorithms_cert" extensions.

I removed the signature algorithms from this output. If accurate lists aren't generated until TLS handshake, then I don't think there's any reason to print a list here.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3360709304

From matthias.baesken at sap.com  Thu Oct  2 12:31:16 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 2 Oct 2025 12:31:16 +0000
Subject: OS & JVM keystores
In-Reply-To: <caab79d9-cf1f-465a-95f4-37d26e4b5ef0@oracle.com>
References: <DU2PR02MB10258B3A343C4C404349F02B593E6A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <caab79d9-cf1f-465a-95f4-37d26e4b5ef0@oracle.com>
Message-ID: <DU2PR02MB1025826C3A0315697B198A44C93E7A@DU2PR02MB10258.eurprd02.prod.outlook.com>

Hi Sean, what you propose sounds really good.
The DKSTest  I found

https://github.com/openjdk/jdk/blob/8be16160d2a6275ff619ea4cebb725475c646052/test/jdk/sun/security/provider/KeyStore/DKSTest.java#L111


mentions also ?system?  , is this the  system (OS ,  e.g. Windows) ? keystore or the cacert ?

The documentation at

https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/security/DomainLoadStoreParameter.html

mentions ?system?   as  keystore system-truststore  but there it is pointing to    keystoreURI="${java.home}/lib/security/cacerts";


Best regards, Matthias



>Hi,

>There is already a feature in the JDK that is close to what you are looking for. There is a KeyStore type called "DKS" (called the DomainKeyStore). See https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/security/DomainLoadStoreParameter.html for more info on how to configure it.

>Basically, it uses a config file to present a collection of keystores as one logical keystore.

>Currently there is no way to specify the configuration file as a system property, so you would have to write a custom TrustManagerFactory.

>I would try seeing if this solution is workable and we can think about whether adding a system property for the config file is something that would be useful.

>--Sean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20251002/d3459a01/attachment-0001.htm>

From djelinski at openjdk.org  Thu Oct  2 13:29:46 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 2 Oct 2025 13:29:46 GMT
Subject: RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider [v2]
In-Reply-To: <kK9NQgnuF8X9G5Yq0UgeWzmhuqoQyDxHYf4PfH4ubro=.6e70c3d0-a94c-4cf8-a15a-a03da73d35fc@github.com>
References: <UinqQ-Wm48c6ihJchiUZ8T7oIpM3WwTzF2mtRk1wj6E=.b085b8aa-0945-4e27-be7e-fd87c7ec62c4@github.com>
 <44icvjzKcQKQluE3bn9tbleAnD5kqDt4sXBs2vaVHAY=.1042d1b0-53dd-4bcc-bb2d-1d8b170a3c3a@github.com>
 <kK9NQgnuF8X9G5Yq0UgeWzmhuqoQyDxHYf4PfH4ubro=.6e70c3d0-a94c-4cf8-a15a-a03da73d35fc@github.com>
Message-ID: <ClDLm2TdrE6eteNyaVp-gvnQ_e8HK4t6QzuawIb26nA=.24800712-394f-436d-a942-f73098051d49@github.com>

On Thu, 2 Oct 2025 01:08:21 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove isIv
>>  - Replace if/else with ternary
>
> Changes look good to me. Thanks~

Thanks @valeriepeng @myankelev for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/27498#issuecomment-3361226574

From djelinski at openjdk.org  Thu Oct  2 13:33:09 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 2 Oct 2025 13:33:09 GMT
Subject: Integrated: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider
In-Reply-To: <UinqQ-Wm48c6ihJchiUZ8T7oIpM3WwTzF2mtRk1wj6E=.b085b8aa-0945-4e27-be7e-fd87c7ec62c4@github.com>
References: <UinqQ-Wm48c6ihJchiUZ8T7oIpM3WwTzF2mtRk1wj6E=.b085b8aa-0945-4e27-be7e-fd87c7ec62c4@github.com>
Message-ID: <r32QGzw4UqUN5HMhaBw4tqDdQU5cXmgcyPyOLKsOJ0Q=.640e2067-25f0-40b1-b8bf-4a15be65cb41@github.com>

On Thu, 25 Sep 2025 19:45:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Change SunJSSE to use `TlsUpdateNplus1` instead of `AES` as the key algorithm when deriving the next application traffic secret.
> 
> SunPKCS11 provider checks the key length when creating an `AES` key, and since 384 bits is not a valid AES key length, the key creation fails.
> 
> `TlsUpdateNplus1` is [already recognized](https://github.com/openjdk/jdk/blob/3c9fd7688f4d73067db9b128c329ca7603a60578/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L287) as a standard TLS generic key by SunPKCS11.
> 
> Key update is now exercised by the FipsModeTLS test. The test passes with the changes, fails without them. Other tier1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: 56baf64a
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56baf64ada04f233fbfe4e0cd033c86183e22015
Stats:     21 lines in 2 files changed: 6 ins; 4 del; 11 mod

8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider

Reviewed-by: valeriep

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

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

From abarashev at openjdk.org  Thu Oct  2 13:45:57 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 2 Oct 2025 13:45:57 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <HMDr8G0o2N5E4sAZr328oSrzLmNeIUNW8ct5-VVYwSU=.e77bf9c5-727b-456a-b095-98e2306a62a2@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
 <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
 <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>
 <cnqT7g1JdcDC0IjD8h386mUWQPL9AgcQOW_Djrjz4l4=.06a5f9be-ad54-4466-936d-7a443560cd2b@github.com>
 <pI0eJIHdSw72R3vuyOWeNuDZv796bVjCvaFFDag_m94=.fd65f249-5b40-408f-92e4-c85c4948fb42@github.com>
 <HMDr8G0o2N5E4sAZr328oSrzLmNeIUNW8ct5-VVYwSU=.e77bf9c5-727b-456a-b095-98e2306a62a2@github.com>
Message-ID: <yRn564YrhbIqkLxbIQu-sL3CsY78mrxNFwJqY-ISGNk=.a23fae24-6dc6-456a-a419-cd78e29fd8e6@github.com>

On Thu, 2 Oct 2025 11:29:12 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> > I think we should either implement a public API to provide those signature schemes or not display them at all to avoid any confusion. If someone sets `jdk.tls.client.SignatureSchemes` system property they would sure know about it. That property overrides all other signature schemes for both "signature_algorithms" and "signature_algorithms_cert" extensions.
> 
> I removed the signature algorithms from this output. If accurate lists aren't generated until TLS handshake, then I don't think there's any reason to print a list here.

Sounds good. I've created [JDK-8366364](https://bugs.openjdk.org/browse/JDK-8366364) to address this problem. Once it's done we can include signature algorithms in the output.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3361286352

From sean.mullan at oracle.com  Thu Oct  2 14:18:06 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 2 Oct 2025 10:18:06 -0400
Subject: OS & JVM keystores
In-Reply-To: <DU2PR02MB1025826C3A0315697B198A44C93E7A@DU2PR02MB10258.eurprd02.prod.outlook.com>
References: <DU2PR02MB10258B3A343C4C404349F02B593E6A@DU2PR02MB10258.eurprd02.prod.outlook.com>
 <caab79d9-cf1f-465a-95f4-37d26e4b5ef0@oracle.com>
 <DU2PR02MB1025826C3A0315697B198A44C93E7A@DU2PR02MB10258.eurprd02.prod.outlook.com>
Message-ID: <9d14c3a8-d4d2-4713-995e-4df3a20de777@oracle.com>


On 10/2/25 8:31 AM, Baesken, Matthias wrote:
>
> Hi Sean, what you propose sounds really good.
>
> The DKSTest? I found
>
> https://github.com/openjdk/jdk/blob/8be16160d2a6275ff619ea4cebb725475c646052/test/jdk/sun/security/provider/KeyStore/DKSTest.java#L111
>
> mentions also ?system?? , is this the ?system (OS ,? e.g. Windows) ? 
> keystore or the cacert ?
>
No, that's just the name of the domain in the config file: 
https://github.com/openjdk/jdk/blob/8be16160d2a6275ff619ea4cebb725475c646052/test/jdk/sun/security/provider/KeyStore/domains.cfg

See also the constructor which explains the URI parameter: 
https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/security/DomainLoadStoreParameter.html#%3Cinit%3E(java.net.URI,java.util.Map)

--Sean

> The documentation at
>
> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/security/DomainLoadStoreParameter.html
>
> mentions ?system??? as? keystore system-truststore? but there it is 
> pointing to ??keystoreURI="${java.home}/lib/security/cacerts";
>
> Best regards, Matthias
>
> >Hi,
>
> >There is already a feature in the JDK that is close to what you are 
> looking for. There is a KeyStore type called "DKS" (called the 
> DomainKeyStore). See 
> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/security/DomainLoadStoreParameter.html 
> for more info on how to configure it.
>
> >Basically, it uses a config file to present a collection of keystores 
> as one logical keystore.
>
> >Currently there is no way to specify the configuration file as a 
> system property, so you would have to write a custom TrustManagerFactory.
>
> >I would try seeing if this solution is workable and we can think 
> about whether adding a system property for the config file is 
> something that would be useful.
>
> >--Sean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20251002/d17144bb/attachment-0001.htm>

From myankelevich at openjdk.org  Thu Oct  2 14:31:30 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 2 Oct 2025 14:31:30 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v3]
In-Reply-To: <TBC_-bS0wveSnqaD7o2rlRCMe_gfBMJDaHTeO6tPJ8s=.751b9545-3c0b-4600-8976-df931df8c1ee@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <TBC_-bS0wveSnqaD7o2rlRCMe_gfBMJDaHTeO6tPJ8s=.751b9545-3c0b-4600-8976-df931df8c1ee@github.com>
Message-ID: <z96sMNXwnPPGZJYn-zXJdV3IWvGiB8Eli2-tpc13B4A=.0ba92a9c-066e-456b-ab88-d670d6ccb6bc@github.com>

On Tue, 2 Sep 2025 15:28:00 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unused code
>  - removed the commented out code

test/jdk/com/sun/jndi/ldap/SocketCloseTest.java line 143:

> 141:     }
> 142: 
> 143:     private static class CustomSocket extends Socket {

minor: could you please cleanup unused imports after this change?

test/jdk/com/sun/jndi/ldap/SocketCloseTest.java line 144:

> 142:     private static class CustomSocket extends Socket {
> 143:         private int closeMethodCalled = 0;
> 144:         private LdapOutputStream output = new LdapOutputStream();

I believe these are local objects which are no longer used after removal of this. I'd personally remove the `private static class LdapInputStream extends InputStream {` and `private static class LdapOutputStream extends OutputStream {` further down the file

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2399024192
PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2399032966

From rhalade at openjdk.org  Thu Oct  2 15:50:49 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 2 Oct 2025 15:50:49 GMT
Subject: RFR: 8360562: sun/security/tools/keytool/i18n.java add an ability
 to add comment for failures [v2]
In-Reply-To: <e84bNkdfN-w8ejjigLjA5mwZRSN8qnvjFW5O1VES3aE=.91e4589b-32eb-4109-9708-892692c6ad1d@github.com>
References: <tmVGkU114dsTBgM6_8wJlg2sz8fGN1Kpsnc0C9n1zHg=.05908d2e-e9de-464c-96fd-c6bf6dfe36f0@github.com>
 <e84bNkdfN-w8ejjigLjA5mwZRSN8qnvjFW5O1VES3aE=.91e4589b-32eb-4109-9708-892692c6ad1d@github.com>
Message-ID: <sWhr5JtAYyM44NPWoJRhV7wvNJoJAPc8wvwLFSI5EG8=.c3f5dba7-e70e-4972-a5a0-1b8fbb7b83b8@github.com>

On Mon, 21 Jul 2025 11:59:20 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> When the test is run now the reason for the failure will be requested providing further feedback.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Matthew's style comments

Is this enhancement requested related to some test failure that were not clear to triage? The fix looks good but is there a need for it?

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

PR Comment: https://git.openjdk.org/jdk/pull/26412#issuecomment-3361948352

From myankelevich at openjdk.org  Thu Oct  2 16:09:27 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 2 Oct 2025 16:09:27 GMT
Subject: RFR: 8360562: sun/security/tools/keytool/i18n.java add an ability
 to add comment for failures [v2]
In-Reply-To: <sWhr5JtAYyM44NPWoJRhV7wvNJoJAPc8wvwLFSI5EG8=.c3f5dba7-e70e-4972-a5a0-1b8fbb7b83b8@github.com>
References: <tmVGkU114dsTBgM6_8wJlg2sz8fGN1Kpsnc0C9n1zHg=.05908d2e-e9de-464c-96fd-c6bf6dfe36f0@github.com>
 <e84bNkdfN-w8ejjigLjA5mwZRSN8qnvjFW5O1VES3aE=.91e4589b-32eb-4109-9708-892692c6ad1d@github.com>
 <sWhr5JtAYyM44NPWoJRhV7wvNJoJAPc8wvwLFSI5EG8=.c3f5dba7-e70e-4972-a5a0-1b8fbb7b83b8@github.com>
Message-ID: <iWrIrTTAN5LiDq0YuO9F90q8WKrYeZWOPOm8xN9WT1g=.c6b5a44a-61ee-4dde-b5b2-d471b24a865c@github.com>

On Thu, 2 Oct 2025 15:48:19 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Is this enhancement requested related to some test failure that were not clear to triage? The fix looks good but is there a need for it?

Yes, the error was missed several times before, as there was no comment. The error itself turned out to be a non-issue, but it was still missed and triaging it took quite a bit of time.

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

PR Comment: https://git.openjdk.org/jdk/pull/26412#issuecomment-3362010166

From wxiao at openjdk.org  Thu Oct  2 16:19:56 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Thu, 2 Oct 2025 16:19:56 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
Message-ID: <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>

> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
> 
> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
> 
> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
> 
> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update the code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26566/files
  - new: https://git.openjdk.org/jdk/pull/26566/files/dd21da3e..77b418d4

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

  Stats: 35 lines in 3 files changed: 4 ins; 31 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26566/head:pull/26566

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

From rhalade at openjdk.org  Thu Oct  2 16:53:15 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 2 Oct 2025 16:53:15 GMT
Subject: RFR: 8360562: sun/security/tools/keytool/i18n.java add an ability
 to add comment for failures [v2]
In-Reply-To: <e84bNkdfN-w8ejjigLjA5mwZRSN8qnvjFW5O1VES3aE=.91e4589b-32eb-4109-9708-892692c6ad1d@github.com>
References: <tmVGkU114dsTBgM6_8wJlg2sz8fGN1Kpsnc0C9n1zHg=.05908d2e-e9de-464c-96fd-c6bf6dfe36f0@github.com>
 <e84bNkdfN-w8ejjigLjA5mwZRSN8qnvjFW5O1VES3aE=.91e4589b-32eb-4109-9708-892692c6ad1d@github.com>
Message-ID: <iFR0flysg4EeQn0V5rKlyqHuFmSUCOdNOMkBXcmtpuw=.8a8cb2fe-959e-4313-95ed-f3a94b1f4976@github.com>

On Mon, 21 Jul 2025 11:59:20 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> When the test is run now the reason for the failure will be requested providing further feedback.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Matthew's style comments

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26412#pullrequestreview-3295493991

From mpowers at openjdk.org  Thu Oct  2 18:09:09 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Oct 2025 18:09:09 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
Message-ID: <o__PHfGybPhLYSY052MgZrZabU5PeXtbBH9YGrc2oKM=.7a3946e4-4d56-4787-b2fc-5d3837e480ca@github.com>

On Mon, 29 Sep 2025 21:00:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another day another iteration
>
> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 190:
> 
>> 188:         var skf = SecretKeyFactory.getInstance(
>> 189:                 kdfHmac.equals("HmacSHA512") ?
>> 190:                 "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256");
> 
> The calculation of mac can be consolidated in one method, which is then called by both `processMacData` and `calculateMac`.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 250:
> 
>> 248:             }
>> 249:         }
>> 250:         // Fall back to old way of computing MAC
> 
> This is not a fallback. There are 2 different kinds of algorithms. If it starts with "PBEWith", PBMAC1 is used. If it starts with "HmacPBE", the old algorithm is used.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399651513
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399651055

From mpowers at openjdk.org  Thu Oct  2 18:09:11 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Oct 2025 18:09:11 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v3]
In-Reply-To: <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <oG840hSliwqHawwcaNtpXRp9cpGQWHb-X-4C3ZBNIyw=.280a7d48-4787-434a-9bf5-b85ddde150e5@github.com>
 <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com>
Message-ID: <I9l_U9r_L1opvFsgmI2o06xmbghTcSGIFF6eUXbR5mU=.4b61ea14-8867-4036-98be-c9c83f8e7651@github.com>

On Wed, 17 Sep 2025 14:39:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   a few more comments
>
> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1509:
> 
>> 1507: 
>> 1508:         var skf = SecretKeyFactory.getInstance(kdfHmac.equals("HmacSHA512") ?
>> 1509:                 "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256");
> 
> Why is PBKDF2 used for non-PBMAC1 algorithms as well?

Changed to `SecretKeyFactory.getInstance("PBE")` for non-PBMAC1 algorithms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399649266

From mpowers at openjdk.org  Thu Oct  2 18:09:14 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Oct 2025 18:09:14 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v7]
In-Reply-To: <UbJx1N8uoAChaBaTAsOISObUwj0o3Czfrl97O8mmQAI=.ccde7ecf-0b04-4931-a964-92763ada960e@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <Wlfzh3j_8gt3FJ6R8U4q4QBBp56zm6t71f4Lo_VnwA0=.7ae9adde-c0bd-4696-93e7-8526473969e1@github.com>
 <RXD4bqV11krnBLUDMQDR3j6YdS7DElH0wscB4K_Prmk=.4ed011c0-d8e4-448d-a7e5-4c67535bde1f@github.com>
 <UbJx1N8uoAChaBaTAsOISObUwj0o3Czfrl97O8mmQAI=.ccde7ecf-0b04-4931-a964-92763ada960e@github.com>
Message-ID: <E3cUQqRiF3kE83m5i7pxzGbXmtU6qnv7-BLay4cEtJo=.b52511b3-3c81-47f7-88ef-84d4309610b7@github.com>

On Wed, 24 Sep 2025 14:03:04 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2196:
>> 
>>> 2194:                     String algName =
>>> 2195:                             macData.getDigestAlgName().toUpperCase(Locale.ENGLISH);
>>> 2196:                     if (algName.equals("PBMAC1")) {
>> 
>> We should manage to move algorithm-specific logic inside `MacData` as much as possible, ideally everything. For example, instead of letting `macData.getDigestAlgName()` returning either "HmacSHA256" or "PBMAC1", it should return the final `macAlgorithm` we need. If the calculation and verification must be different, they can also be moved into `MacData`.
>
> This makes sense.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399650327

From mpowers at openjdk.org  Thu Oct  2 18:40:57 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Oct 2025 18:40:57 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
Message-ID: <7v2pfCaX0CEdLhp8X-ggKHL-lNkPjiMoIoaRmCYA8wo=.e3cf2f05-b853-486b-a546-13e476194aa9@github.com>

On Tue, 30 Sep 2025 19:36:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another day another iteration
>
> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 86:
> 
>> 84:     protected void Init(AlgorithmParameterSpec paramSpec)
>> 85:         throws InvalidParameterSpecException {
>> 86:         if (!(paramSpec instanceof PBEParameterSpec)) {
> 
> Use the instanceof pattern (see JEP 394) to avoid the need to cast on lines 90 and 91.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 178:
> 
>> 176:             throws  Exception {
>> 177:         final String kdfHmac;
>> 178:         final String Hmac;
> 
> Use lower-case as first letter of variable names, s/Hmac/hmac

fixed

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 151:
> 
>> 149:      */
>> 150:     public byte[] getSalt() {
>> 151:         return this.salt.clone();
> 
> I don't think you need to return a clone here as you are just using it internally and not mutating it or exposing it to applications that could modify it. I'll double-check as I review the rest of the code.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399737516
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399739051
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399737960

From mpowers at openjdk.org  Thu Oct  2 18:49:53 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Oct 2025 18:49:53 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>

> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  more review comments from Weijun and Sean

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24429/files
  - new: https://git.openjdk.org/jdk/pull/24429/files/21eca48e..3dea54d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=09-10

  Stats: 392 lines in 5 files changed: 270 ins; 68 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/24429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429

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

From mpowers at openjdk.org  Thu Oct  2 19:24:51 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Oct 2025 19:24:51 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v3]
In-Reply-To: <I9l_U9r_L1opvFsgmI2o06xmbghTcSGIFF6eUXbR5mU=.4b61ea14-8867-4036-98be-c9c83f8e7651@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <oG840hSliwqHawwcaNtpXRp9cpGQWHb-X-4C3ZBNIyw=.280a7d48-4787-434a-9bf5-b85ddde150e5@github.com>
 <0oljeE8PATeewmIhhv140SBbADTTS0k3XcJbNZIs5zQ=.4eb21b4c-fc2f-4a26-ad74-c346ea2bca78@github.com>
 <I9l_U9r_L1opvFsgmI2o06xmbghTcSGIFF6eUXbR5mU=.4b61ea14-8867-4036-98be-c9c83f8e7651@github.com>
Message-ID: <y9CLHrP6ZQWaN4Sl4cMkA-q1LCZlBxw2Qso0ECM6POM=.599bf732-4c2c-44bc-a24b-4e0ab9ce274a@github.com>

On Thu, 2 Oct 2025 18:05:24 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1509:
>> 
>>> 1507: 
>>> 1508:         var skf = SecretKeyFactory.getInstance(kdfHmac.equals("HmacSHA512") ?
>>> 1509:                 "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256");
>> 
>> Why is PBKDF2 used for non-PBMAC1 algorithms as well?
>
> Changed to `SecretKeyFactory.getInstance("PBE")` for non-PBMAC1 algorithms.

I'm now using `SecretKeyFactory.getInstance("PBE")` for non-PBMAC1 algorithms. This code has now been moved into MacData.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399850353

From mpowers at openjdk.org  Thu Oct  2 19:43:56 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Oct 2025 19:43:56 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <7v2pfCaX0CEdLhp8X-ggKHL-lNkPjiMoIoaRmCYA8wo=.e3cf2f05-b853-486b-a546-13e476194aa9@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
 <7v2pfCaX0CEdLhp8X-ggKHL-lNkPjiMoIoaRmCYA8wo=.e3cf2f05-b853-486b-a546-13e476194aa9@github.com>
Message-ID: <hslQh4w7ChdEkWP3UiRQUvzWCQbbMmCiHnEfyrCNx6I=.4a1415e4-989d-46a8-97d4-5f8c9c97968b@github.com>

On Thu, 2 Oct 2025 18:37:00 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 86:
>> 
>>> 84:     protected void Init(AlgorithmParameterSpec paramSpec)
>>> 85:         throws InvalidParameterSpecException {
>>> 86:         if (!(paramSpec instanceof PBEParameterSpec)) {
>> 
>> Use the instanceof pattern (see JEP 394) to avoid the need to cast on lines 90 and 91.
>
> fixed

fixed

>> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 178:
>> 
>>> 176:             throws  Exception {
>>> 177:         final String kdfHmac;
>>> 178:         final String Hmac;
>> 
>> Use lower-case as first letter of variable names, s/Hmac/hmac
>
> fixed

fixed

>> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 151:
>> 
>>> 149:      */
>>> 150:     public byte[] getSalt() {
>>> 151:         return this.salt.clone();
>> 
>> I don't think you need to return a clone here as you are just using it internally and not mutating it or exposing it to applications that could modify it. I'll double-check as I review the rest of the code.
>
> fixed

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399889006
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399889926
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399886026

From mpowers at openjdk.org  Thu Oct  2 19:43:58 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 2 Oct 2025 19:43:58 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <o__PHfGybPhLYSY052MgZrZabU5PeXtbBH9YGrc2oKM=.7a3946e4-4d56-4787-b2fc-5d3837e480ca@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
 <o__PHfGybPhLYSY052MgZrZabU5PeXtbBH9YGrc2oKM=.7a3946e4-4d56-4787-b2fc-5d3837e480ca@github.com>
Message-ID: <Pljc1wq6HdNOjnjopDKM-Ni0-Ls_85VG2QsmKJFgCxY=.926991e8-e5fe-490b-9411-4adcfd0ac334@github.com>

On Thu, 2 Oct 2025 18:06:37 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 190:
>> 
>>> 188:         var skf = SecretKeyFactory.getInstance(
>>> 189:                 kdfHmac.equals("HmacSHA512") ?
>>> 190:                 "PBKDF2WithHmacSHA512" : "PBKDF2WithHmacSHA256");
>> 
>> The calculation of mac can be consolidated in one method, which is then called by both `processMacData` and `calculateMac`.
>
> fixed

Is this a game of Whac-A-Mole? I already commented that this is fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2399883749

From mullan at openjdk.org  Thu Oct  2 20:13:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Oct 2025 20:13:54 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <id9u2MuQptQ3Y1e5xpQnX9VAT9VhaGNOSMFdQ6KrOKk=.8965d2eb-5533-44e7-98f3-5b27077a818f@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 110:

> 108:     /**
> 109:      * Constructor that takes both public and private encodings.  If
> 110:      * publicEncoding is null, a V1 PKCS8 encoding is created; otherwise, V2 is

This comment: "If publicEncoding is null, a V1 PKCS8 encoding is created"

I don't think this is always true. A V2 encoding could be created if `publicEncoding` is `null` and `decode()` parses the `privateEncoding` and the version is V2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2399947984

From mullan at openjdk.org  Thu Oct  2 20:25:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Oct 2025 20:25:58 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <rG6-ppN7qVilHgYC3CIVpNYwUsHBR9K8MoJsaJPF8AE=.1933f0d9-f45f-4177-9388-b7ca12a51da5@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 124:

> 122:                         "the given PublicKey");
> 123:                 }
> 124:                 version = V1;

Why do you set the version to V1 here? There is a public and private key.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2399976439

From weijun at openjdk.org  Thu Oct  2 21:04:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Oct 2025 21:04:53 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
Message-ID: <jwN9HMSZfEdODrmvKwPGaWk8HxouxdNpkwaNNkVUccw=.fd240dc5-0538-4fbc-ab76-728eaaa61e67@github.com>

On Thu, 2 Oct 2025 18:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more review comments from Weijun and Sean

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 267:

> 265:             hmac = macAlgorithm;
> 266:         } else {
> 267:             throw new ParsingException("unexpected algorithm");

Do we no longer support `HmacPBESHA512` etc?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2400056255

From weijun at openjdk.org  Thu Oct  2 21:09:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 2 Oct 2025 21:09:57 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
Message-ID: <iqJxcmtbFV70oR4ZZbT9cqEf8c8Y8dcOZQWiBLhL88w=.0998df93-0832-4c54-bc34-60a97aa80c71@github.com>

On Thu, 2 Oct 2025 18:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more review comments from Weijun and Sean

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 364:

> 362:         }
> 363: 
> 364:         if (this.encoded != null)

I don't think it's worth caching the `encoded` inside the object. The `getEncoded` method is only called once for each object. Just return the `encoded` output directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2400066890

From mullan at openjdk.org  Thu Oct  2 21:18:49 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Oct 2025 21:18:49 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <JR4Q-2dx4dkqcrl4F3oiQIzDXE2iwAcyuzSPca1AeW0=.508e8db7-c22d-4907-8a53-9e02aca45b15@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 105:

> 103:         Arrays.fill(sArr, (byte) 0);
> 104:         makeEncoding(sOctets);
> 105:         Arrays.fill(sOctets, (byte) 0);

You need a try-finally block so that the arrays are cleared even in the case an exception is thrown.

src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 115:

> 113:         ArrayUtil.reverse(privBytes);
> 114:         makeEncoding(privBytes);
> 115:         Arrays.fill(privBytes, (byte) 0);

You need a try-finally block so that the array is cleared even in the case an exception is thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2400077187
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2400075946

From valeriep at openjdk.org  Thu Oct  2 23:21:18 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 2 Oct 2025 23:21:18 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE
Message-ID: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>

This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 

Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 

Thanks in advance for the review~

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

Commit messages:
 - 8368984: Extra slashes in Cipher transformation leads to NSPE instead of NSAE

Changes: https://git.openjdk.org/jdk/pull/27615/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27615&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368984
  Stats: 159 lines in 4 files changed: 46 ins; 45 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/27615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27615/head:pull/27615

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

From mdonovan at openjdk.org  Thu Oct  2 23:36:53 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 2 Oct 2025 23:36:53 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
Message-ID: <TvcfrMTh0MWAHLnZnz_DjLh81jHz08tvep8SuFyNUSI=.d99b962e-f3f1-40b7-9c19-ed1d0542cfd2@github.com>

On Thu, 2 Oct 2025 18:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more review comments from Weijun and Sean

I've been trying to run `sun/security/pkcs12/KeytoolOpensslInteropTest.java` with your branch and it has been failing when creating the `kslegacyimp` file: https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java#L189

(Technically, the test fails on line 192 because the file doesn't exist.)

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

PR Comment: https://git.openjdk.org/jdk/pull/24429#issuecomment-3363616672

From hchao at openjdk.org  Fri Oct  3 00:03:20 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 3 Oct 2025 00:03:20 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
Message-ID: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>

Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

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

Commit messages:
 - 8314323: TLS 1.3 Hybrid Key Exchange
 - Merge
 - 8314323: TLS 1.3 Hybrid Key Exchange

Changes: https://git.openjdk.org/jdk/pull/27614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314323
  Stats: 1728 lines in 23 files changed: 1619 ins; 46 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From mpowers at openjdk.org  Fri Oct  3 01:55:49 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 3 Oct 2025 01:55:49 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
Message-ID: <zffIkgh7_m1I9uOzzpGSIVgk68c6lrWIrxbqXj-F9gA=.c29930fb-1f72-4a2e-a76d-452c50e2c4ce@github.com>

On Thu, 2 Oct 2025 18:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more review comments from Weijun and Sean

[mpdonova](https://github.com/mpdonova) I know about this one. I broke this test this morning with my latest push. Good to know someone is checking.

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

PR Comment: https://git.openjdk.org/jdk/pull/24429#issuecomment-3363866631

From weijun at openjdk.org  Fri Oct  3 02:40:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Oct 2025 02:40:51 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE
In-Reply-To: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
Message-ID: <bIQa4lpaiAp04nVn-3k3ebfDAh6vdfenL6NAb8mxxjM=.84ab3ec0-8830-4616-9d09-345735e97ffd@github.com>

On Thu, 2 Oct 2025 23:14:48 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 
> 
> Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 
> 
> Thanks in advance for the review~

src/java.base/share/classes/javax/crypto/Cipher.java line 329:

> 327:                     SHA512TRUNCATED.length());
> 328:             sha512SlashIdx = (sha512Idx != -1 ? sha512Idx + 3 : -2);
> 329:         }

The logic is quite complex. Can you create a dedicated method for it like `indexOfRealSlashIn(String s)`?

Also, although we know there is no `512/2` in valid `mode`, there is no need to treat it specially, especially if we have `indexOfReachSlashIn`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27615#discussion_r2400611322

From myankelevich at openjdk.org  Fri Oct  3 07:40:30 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 3 Oct 2025 07:40:30 GMT
Subject: Integrated: 8360562: sun/security/tools/keytool/i18n.java add an
 ability to add comment for failures
In-Reply-To: <tmVGkU114dsTBgM6_8wJlg2sz8fGN1Kpsnc0C9n1zHg=.05908d2e-e9de-464c-96fd-c6bf6dfe36f0@github.com>
References: <tmVGkU114dsTBgM6_8wJlg2sz8fGN1Kpsnc0C9n1zHg=.05908d2e-e9de-464c-96fd-c6bf6dfe36f0@github.com>
Message-ID: <QC1DopuEhjYQzLiFeHD-3Ff3jobH5c6MwcaxDjE-asc=.e1803650-3eea-4a64-8e67-c1875854b7b7@github.com>

On Mon, 21 Jul 2025 10:49:18 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> When the test is run now the reason for the failure will be requested providing further feedback.

This pull request has now been integrated.

Changeset: ebb6fd7d
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ebb6fd7d7865fd20ff2f90b4ef72c5ef6a3e5dea
Stats:     44 lines in 1 file changed: 42 ins; 0 del; 2 mod

8360562: sun/security/tools/keytool/i18n.java add an ability to add comment for failures

Reviewed-by: rhalade

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

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

From mullan at openjdk.org  Fri Oct  3 13:27:38 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 3 Oct 2025 13:27:38 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <M4ZBrtG-QdsCAsmPecRmsTU6arjbkrKxT5NuK_TXuhY=.9d66b840-5be9-4a80-976d-de9fe6fff79b@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

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

> 42:  * when the data type cannot be represented by a cryptographic object.
> 43:  * If {@code PEM} is desired instead of a cryptographic object, the
> 44:  * decoding methods {@link PEMDecoder#decode(String, Class)} or

Suggest rewording this, and reusing some text from the JEP as: 

"If you need access to the leading data of a PEM text, or if you want to handle the text?s content yourself, use the decoding methods ... with `PEM.class` as an argument."

src/java.base/share/classes/java/security/PEM.java line 49:

> 47:  *
> 48:  * <p> A {@code PEM} object can be encoded back to its textual format by using
> 49:  * encode methods in {@link PEMEncoder} or the {@link #toString()} method.

I'd probably say "calling" instead of "using" and switch the order, and a few other tweaks. Suggest: 

"A {@code PEM} object can be encoded back to its textual format by calling the {@link #toString()} method or the encode methods of {@link PEMEncoder}."

src/java.base/share/classes/java/security/PEM.java line 55:

> 53:  *
> 54:  * <p>No validation is performed during instantiation to ensure that
> 55:  * {@code type} conforms to {@code RFC 7468} or other legacy formats, that

I don't think RFC 7468 should be in code font.

src/java.base/share/classes/java/security/PEM.java line 61:

> 59:  * Common {@code type} values include, but are not limited to:
> 60:  * CERTIFICATE, CERTIFICATE REQUEST, ATTRIBUTE CERTIFICATE, X509 CRL, PKCS7,
> 61:  * CMS, PRIVATE KEY, ENCRYPTED PRIVATE KEY, RSA PRIVATE KEY, or PUBLIC KEY.

s/RSA PRIVATE KEY/PRIVATE KEY/

src/java.base/share/classes/java/security/PEM.java line 63:

> 61:  * CMS, PRIVATE KEY, ENCRYPTED PRIVATE KEY, RSA PRIVATE KEY, or PUBLIC KEY.
> 62:  *
> 63:  * <p> {@code leadingData} may be null if there was no data preceding the PEM

s/may be null/will be null/
s/was no/is no/

src/java.base/share/classes/java/security/PEM.java line 65:

> 63:  * <p> {@code leadingData} may be null if there was no data preceding the PEM
> 64:  * header during decoding.  {@code leadingData} can be useful for reading
> 65:  * metadata that accompanies PEM data. {@code leadingData} is not defensively

s/PEM/the PEM/

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

> 64:  * header during decoding.  {@code leadingData} can be useful for reading
> 65:  * metadata that accompanies PEM data. {@code leadingData} is not defensively
> 66:  * copied and the {@link #leadingData()} method does not return a clone.

s/copied/copied by the constructor/

src/java.base/share/classes/java/security/PEM.java line 88:

> 86: 
> 87:     /**
> 88:      * Creates a {@code PEM} instance with the given parameters.

s/the given/the specified/

In the other ctor, you say what the parameters are, so you should do the same here.

src/java.base/share/classes/java/security/PEM.java line 114:

> 112: 
> 113:     /**
> 114:      * Creates a {@code PEM} instance with a given {@code type} and

s/a given/the specified/

src/java.base/share/classes/java/security/PEM.java line 115:

> 113:     /**
> 114:      * Creates a {@code PEM} instance with a given {@code type} and
> 115:      * {@code content} data in String form.  {@code leadingData} is set to null.

"in String form" is redundant since those are the types of the parameters. Suggest removing those words.

src/java.base/share/classes/java/security/PEM.java line 115:

> 113:     /**
> 114:      * Creates a {@code PEM} instance with a given {@code type} and
> 115:      * {@code content} data in String form.  {@code leadingData} is set to null.

Put null in code font.

src/java.base/share/classes/java/security/PEM.java line 130:

> 128: 
> 129:     /**
> 130:      * Returns the type and Base64 encoding in PEM textual format.

s/Base64 encoding/Base64-encoded data/

src/java.base/share/classes/java/security/PEM.java line 130:

> 128: 
> 129:     /**
> 130:      * Returns the type and Base64 encoding in PEM textual format.

Do we need to say "textual"? Suggest removing that word.

src/java.base/share/classes/java/security/PEM.java line 131:

> 129:     /**
> 130:      * Returns the type and Base64 encoding in PEM textual format.
> 131:      * {@code leadingData} is not returned by this method.

Suggest rewording as "leadingData is not included in the PEM data returned by this method."

src/java.base/share/classes/java/security/PEM.java line 139:

> 137: 
> 138:     /**
> 139:      * Returns a Base64 decoded byte array of {@code content}.

s/Base64 decoded/Base64-decoded/

src/java.base/share/classes/java/security/PEM.java line 139:

> 137: 
> 138:     /**
> 139:      * Returns a Base64 decoded byte array of {@code content}.

Suggest stating that each invocation of this method returns a new byte array, as it isn't clear.

src/java.base/share/classes/java/security/PEM.java line 144:

> 142:      * @throws IllegalArgumentException on a decoding error
> 143:      *
> 144:      * @see Base64#getMimeDecoder()

Suggest you also add a sentence that states this method uses the using the MIME type base64 decoding scheme, otherwise the `@see` doesn't have much context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401784001
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401900160
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401801859
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401818161
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401824375
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401827152
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401882889
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401865919
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401861840
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401858716
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401860156
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401849924
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401851466
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401847055
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401831443
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401840888
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401839164

From mullan at openjdk.org  Fri Oct  3 13:27:41 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 3 Oct 2025 13:27:41 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <j7mcC0LYDigWC8xays2YETA96yfGKZMBtY_xxbJ_5t4=.1c71e850-38a6-4a08-b1cd-0b1350d60bd7@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <j7mcC0LYDigWC8xays2YETA96yfGKZMBtY_xxbJ_5t4=.1c71e850-38a6-4a08-b1cd-0b1350d60bd7@github.com>
Message-ID: <C6VRDvMODv_fbdKRWUpzgdYMrnjBlHujLUeAyDFgyNI=.5a1c65e5-c66f-483b-ae93-2ae945697f74@github.com>

On Wed, 1 Oct 2025 19:46:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed some decoder comments
>
> src/java.base/share/classes/java/security/PEM.java line 98:
> 
>> 96:      * formatted.
>> 97:      * @throws NullPointerException if {@code type} and/or {@code content} are
>> 98:      * {@code null}.
> 
> No need to add a period at the end if it's not a full sentence. There are several places in this file.

Line 94, s/maybe/may be/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2401875387

From weijun at openjdk.org  Fri Oct  3 14:06:49 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Oct 2025 14:06:49 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <QCNg1vwrVwF9go6ocJjpuC6huSCZ96fCWwXFo_i_RIc=.56624471-fb68-43b2-8c31-a79b41c70882@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

One test comment.

test/jdk/javax/crypto/EncryptedPrivateKeyInfo/GetKeyPair.java line 103:

> 101:             "PublicKey didn't match with decoded.");
> 102:         Asserts.assertEqualsByteArray(kps.origPubEncoding, actualPubEncoding,
> 103:             "PublicKey didn't match with decoded.");

There is no need to always compare public key encoding twice. You can compare `kpOrig.getPublic()` and `mlkemKP.getPubic()` once after line 72.

Then you can just compare `mlkemKP` and `kp` and there is no need to invent a new `KeyPairs` type.

I would more like to see this test and `GetKey` merged, probably also covering `getKeySpec`.

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

PR Review: https://git.openjdk.org/jdk/pull/27147#pullrequestreview-3296464508
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2400109232

From abarashev at openjdk.org  Fri Oct  3 14:22:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 3 Oct 2025 14:22:49 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <iKjo_aYDXQWwn5k3p-ByUzeHjTiOwbys2AFBoHb_Wxk=.58218cec-ffc7-4c0e-9754-822da3f7ec29@github.com>

On Thu, 2 Oct 2025 22:52:49 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 316:

> 314:                 // Skip AlgorithmParameters for KEMs (not supported)
> 315:                 if (namedGroupSpec == NamedGroupSpec.NAMED_GROUP_KEM) {
> 316:                     if (defaultProviderName == null) {

We assume that if provider is not null then it must be DH without doing any checks to confirm that. It would be cleaner to call getProvider() instead.

> Provider p = getProvider();
                    if (p == null) {
                        KeyFactory.getInstance(name);
                    } else {
                        KeyFactory.getInstance(name, p);
                    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402120722

From weijun at openjdk.org  Fri Oct  3 15:17:36 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Oct 2025 15:17:36 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available
In-Reply-To: <JY452lAyC4opIYSsFcpKgA-TikUweAjgRKsrqrPVN4E=.84cb55c0-6f05-43b6-a1b4-abad6489d241@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
 <JY452lAyC4opIYSsFcpKgA-TikUweAjgRKsrqrPVN4E=.84cb55c0-6f05-43b6-a1b4-abad6489d241@github.com>
Message-ID: <_VR8jTuexQxRqQXgnZ8X1Wlp_8LAdJctG0zAPf3w_aU=.53a94c9d-d9b6-4bcb-bb3f-01b69bd7c96e@github.com>

On Wed, 1 Oct 2025 16:20:01 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.
>
> test/jdk/sun/security/provider/acvp/Launcher.java line 124:
> 
>> 122:         } catch (IOException e) {
>> 123:             if (e.getMessage().contains("Cannot find the artifact ACVP-Server")) {
>> 124:                 throw new SkippedException("ACVP-Server not available, skip test.");
> 
> nit: 
> Suggestion:
> 
>                 throw new SkippedException("ACVP-Server not available.");

Hi @myankelev, can you just take a look at all our tests that call `ArtifactResolver.fetchOne` to see if it can directly throw a `SkippedException`? Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27491#discussion_r2402345258

From weijun at openjdk.org  Fri Oct  3 16:03:47 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Oct 2025 16:03:47 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <29jAiuBqIdivXhkbUJ1tS68VM9-i9HvX6cDuI1EjiPE=.4b7ee7c5-64c7-40ea-b9ee-70403116e04f@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

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

> 1: /*

Since you added `getKey` and `getKeyPair` with a password argument, can we also add a `getKeySpec` with the same argument to be consistent?

Also, if you add this method, can it be used instead of `Pem.decryptEncoding`? That method is called inside EPKI and it creates another EPKI which looks wasteful and dangerously recursive.

src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 252:

> 250:                 int version = seq.data.getInteger();
> 251:                 if (version == 1) { // EC
> 252:                     byte[] oct = seq.data.getOctetString();  // private key

If you call `seq.data.getDerValue()` then the return value uses the original array with an offset and a length. So there is no need to call `Arrays.fill` next.

src/java.base/share/classes/sun/security/util/Pem.java line 376:

> 374:             SharedSecrets.getJavaSecuritySpecAccess().
> 375:                 clearEncodedKeySpec(p8KeySpec);
> 376:             keySpec.clearPassword();

Why are the lines above indented? Were you trying to add a try-finally here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402364435
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402215329
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402261371

From hchao at openjdk.org  Fri Oct  3 16:31:31 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 3 Oct 2025 16:31:31 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores
Message-ID: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>

This PR improves security warning when using JKS or JCEKS keystores.

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

Commit messages:
 - Merge
 - 8353749: Improve security warning when using JKS or JCEKS keystores

Changes: https://git.openjdk.org/jdk/pull/27624/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353749
  Stats: 350 lines in 9 files changed: 329 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27624/head:pull/27624

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

From abarashev at openjdk.org  Fri Oct  3 16:55:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 3 Oct 2025 16:55:49 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <zDfpQXHerQwWUq2Q5Un2wGNUpc_to2g41OC8fXWSA9s=.3b06325c-bc79-4c87-9dd3-53a0f42e2707@github.com>

On Thu, 2 Oct 2025 22:52:49 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

src/java.base/share/classes/com/sun/crypto/provider/DH.java line 248:

> 246:                 "XDH", "XDH", NamedParameterSpec.X25519),
> 247: 
> 248:         X448(56, 56,

Why do we need `X448` and `P521`?

src/java.base/share/classes/sun/security/util/Hybrid.java line 100:

> 98:     private static KEM getKEM(String name) throws NoSuchAlgorithmException {
> 99:         if (name.startsWith("secp") || name.equals("X25519") ||
> 100:                 name.equals("X448")) {

Do we need `X448` here? Also, please provide a comment for this method with functionality description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402639954
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402633190

From jnimeh at openjdk.org  Fri Oct  3 17:08:47 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 3 Oct 2025 17:08:47 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <zDfpQXHerQwWUq2Q5Un2wGNUpc_to2g41OC8fXWSA9s=.3b06325c-bc79-4c87-9dd3-53a0f42e2707@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <zDfpQXHerQwWUq2Q5Un2wGNUpc_to2g41OC8fXWSA9s=.3b06325c-bc79-4c87-9dd3-53a0f42e2707@github.com>
Message-ID: <oDS0DIr2nsi02JB98PN_E2sZbd9Qls_UzIvGwHMwhTI=.515048a1-2e4b-4474-b6f9-f321e13d12fc@github.com>

On Fri, 3 Oct 2025 16:53:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 248:
> 
>> 246:                 "XDH", "XDH", NamedParameterSpec.X25519),
>> 247: 
>> 248:         X448(56, 56,
> 
> Why do we need `X448` and `P521`?

Need, no.  Want, yes.  The support for traditional curves that are not part of the first round of hybrid KEMs lays the groundwork for future hybrid KEMs that might use these larger curves.  It also gives us the base framework to move these algorithms as named groups to KEM implementations in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402680762

From abarashev at openjdk.org  Fri Oct  3 17:21:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 3 Oct 2025 17:21:51 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <oDS0DIr2nsi02JB98PN_E2sZbd9Qls_UzIvGwHMwhTI=.515048a1-2e4b-4474-b6f9-f321e13d12fc@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <zDfpQXHerQwWUq2Q5Un2wGNUpc_to2g41OC8fXWSA9s=.3b06325c-bc79-4c87-9dd3-53a0f42e2707@github.com>
 <oDS0DIr2nsi02JB98PN_E2sZbd9Qls_UzIvGwHMwhTI=.515048a1-2e4b-4474-b6f9-f321e13d12fc@github.com>
Message-ID: <dfXllrRVcNLi1P4uRimE879Dge9Nfhty1H19VGDiC8E=.d5bf5fe5-f3ca-4deb-b506-41ee4b1cabfd@github.com>

On Fri, 3 Oct 2025 17:05:57 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 248:
>> 
>>> 246:                 "XDH", "XDH", NamedParameterSpec.X25519),
>>> 247: 
>>> 248:         X448(56, 56,
>> 
>> Why do we need `X448` and `P521`?
>
> Need, no.  Want, yes.  The support for traditional curves that are not part of the first round of hybrid KEMs lays the groundwork for future hybrid KEMs that might use these larger curves.  It also gives us the base framework to move these algorithms as named groups to KEM implementations in the future.

I see, thanks for the explanation! I guess it makes sense if we expect those curves to be used in the future rounds of hybrid KEM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402716798

From abarashev at openjdk.org  Fri Oct  3 17:24:47 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 3 Oct 2025 17:24:47 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <MIFOZmCTj6r3YfGNkcSCkY1ZZmdgbkHYnqU_SipHZTg=.93f4e70b-1dea-4c3f-a633-bb697bdde1cd@github.com>

On Thu, 2 Oct 2025 22:52:49 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

src/java.base/share/classes/com/sun/crypto/provider/DH.java line 138:

> 136:         private final PublicKey pkR;
> 137:         private final PrivateKey skR;
> 138:         private final AlgorithmParameterSpec spec;

This variable is not being used, it can be removed together with the constructor parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402727971

From duke at openjdk.org  Fri Oct  3 17:31:55 2025
From: duke at openjdk.org (Bernd)
Date: Fri, 3 Oct 2025 17:31:55 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>

On Thu, 2 Oct 2025 22:52:49 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

src/java.base/share/classes/com/sun/crypto/provider/DH.java line 224:

> 222:             } else if (k instanceof XECKey xkey
> 223:                     && xkey.getParams() instanceof NamedParameterSpec ns) {
> 224:                 if (ns.getName().equalsIgnoreCase("X25519")) {

Maybe use NamedParameterSpec.X25519?

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 218:

> 216:             PredefinedDHParameterSpecs.ffdheParams.get(8192)),
> 217: 
> 218:     ML_KEM_512(0x0200, "MLKEM512",

Are they needed for this Jep?

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 653:

> 651:         NAMED_GROUP_XDH("XDH", XDHScheme.instance),
> 652: 
> 653:         NAMED_GROUP_KEM("PQC", KEMScheme.instance),

That Choice of Name needs probably an explaining comment if it is for pure PQC and/ormhybrid?

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 802:

> 800:                         FFDHE_3072,
> 801:                         FFDHE_4096,
> 802:                         FFDHE_6144,

Unrelated change?

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 906:

> 904:                 NamedGroup[] groups = new NamedGroup[] {
> 905: 
> 906:                         // Hybrid key agreements

It feels like all the infra for X448MLKEM1024 is there, so rather than removing x448 from this patch, why not implement it (it?s more obvious than P511 Variants)

src/java.base/share/classes/sun/security/util/Hybrid.java line 75:

> 73: 
> 74:     private static AlgorithmParameterSpec getSpec(String name) {
> 75:         if (name.startsWith("secp")) {

This seems to be repeated multiple times including the case sensitive string, maybe have an APS.isGenericEC() helper?

src/java.base/share/classes/sun/security/util/Hybrid.java line 230:

> 228:         private static int leftPublicLength(String name) {
> 229:             return switch (name.toLowerCase(Locale.ROOT)) {
> 230:                 case "secp256r1" -> 65;

Isn?t that Part formte named groups, maybe Look it up instead?

src/java.base/share/classes/sun/security/util/Hybrid.java line 290:

> 288:     private static byte[] concat(byte[]... inputs) {
> 289:         ByteArrayOutputStream o = new ByteArrayOutputStream();
> 290:         Arrays.stream(inputs).forEach(o::writeBytes);

Do we really want a non presized buffer and a stream in the handshake hot path?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402691528
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402706225
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402713652
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402721266
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402719813
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402730803
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402738310
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402742473

From mullan at openjdk.org  Fri Oct  3 17:36:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 3 Oct 2025 17:36:54 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <_YwYgBFom2Ha47E3HudHBHFVEb9Wnm1GSZlDK11VTTQ=.9fd7a186-cdac-404c-bd50-dfa1e3861b20@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

src/java.base/share/classes/java/security/PEMEncoder.java line 1:

> 1: /*

Suggest using "PEM-encoded" instead of "PEM encoded" to be consistent with JEP wording.

src/java.base/share/classes/java/security/PEMEncoder.java line 1:

> 1: /*

line 48, s/CRL/CRLs/

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

> 69:  * OneAsymmetricKey structure using the "PRIVATE KEY" type.
> 70:  *
> 71:  * <p> When encoding a {@link PEM}, the API surrounds the

suggest saying "When encoding a PEM object, ..."

src/java.base/share/classes/java/security/PEMEncoder.java line 72:

> 70:  *
> 71:  * <p> When encoding a {@link PEM}, the API surrounds the
> 72:  * {@link PEM#content()} with the PEM header and footer

s/the/a/

src/java.base/share/classes/java/security/PEMEncoder.java line 73:

> 71:  * <p> When encoding a {@link PEM}, the API surrounds the
> 72:  * {@link PEM#content()} with the PEM header and footer
> 73:  * from {@link PEM#type()}. {@link PEM#leadingData()} is

s/from/of/

src/java.base/share/classes/java/security/PEMEncoder.java line 74:

> 72:  * {@link PEM#content()} with the PEM header and footer
> 73:  * from {@link PEM#type()}. {@link PEM#leadingData()} is
> 74:  * not included in the encoding.  {@code PEM} will not perform

I don't think you need this final sentence, leave that to the `PEM` javadocs.

src/java.base/share/classes/java/security/PEMEncoder.java line 267:

> 265:      * by the {@code jdk.epkcs8.defaultAlgorithm} security property and
> 266:      * uses the default encryption parameters of the provider that is selected.
> 267:      * For greater flexibility with encryption options and parameters, use

Suggest using the JEP words here instead: "To use non-default encryption parameters, or to encrypt with a different encryption [provider](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/security/Provider.html), use ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402627574
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402745066
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402751207
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402754710
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402755066
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402759080
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402653825

From jnimeh at openjdk.org  Fri Oct  3 18:10:53 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 3 Oct 2025 18:10:53 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
Message-ID: <1QQ_1iFfLNgiLezNZNsd_w9POP2msxTOK6L9YLBbF3k=.237c769e-23b6-4c5f-a8c2-2e8f9139aa7c@github.com>

On Fri, 3 Oct 2025 17:20:04 GMT, Bernd <duke at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 906:
> 
>> 904:                 NamedGroup[] groups = new NamedGroup[] {
>> 905: 
>> 906:                         // Hybrid key agreements
> 
> It feels like all the infra for X448MLKEM1024 is there, so rather than removing x448 from this patch, why not implement it (it?s more obvious than P511 Variants)

Indeed the infrastructure is there, but I don't see an IETF draft that covers that hybrid variant for TLS, nor do I see an IANA mapping for it here: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

There needs to be a standard for TLS 1.3 backing these hybrid KEMs before we implement them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402875164

From jnimeh at openjdk.org  Fri Oct  3 18:32:47 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 3 Oct 2025 18:32:47 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
Message-ID: <yMGhnOT8WxEd-y_dNQAaTFoGr1z9n9p6fub6j44rr3c=.127191ee-1f7a-4288-a2f1-d21083b4640b@github.com>

On Fri, 3 Oct 2025 17:20:32 GMT, Bernd <duke at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 802:
> 
>> 800:                         FFDHE_3072,
>> 801:                         FFDHE_4096,
>> 802:                         FFDHE_6144,
> 
> Unrelated change?

No, the choise to knock out ffdhe6144 and 8192 from the default list was done on purpose.  I don't think they get much use and they can always be re-enabled via SSLParameters or the system property.  We're open to feedback on this if you or others feel like they should remain in place, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2402940752

From sherman at openjdk.org  Fri Oct  3 19:10:20 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 3 Oct 2025 19:10:20 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support
Message-ID: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>

### Summary

Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.

Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:

**String.equalsIgnoreCase(String)**

- Unicode-aware, locale-independent.
- Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
- Limited: does not support 1:M mapping defined in Unicode case folding.

**Character.toLowerCase(int) / Character.toUpperCase(int)**

- Locale-independent, single code point only.
- No support for 1:M mappings.

**String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**

- Based on Unicode SpecialCasing.txt, supports 1:M mappings.
- Intended primarily for presentation/display, not structural case-insensitive matching.
- Requires full string conversion before comparison, which is less efficient and not intended for structural matching.

**1:M mapping example, U+00DF (?)**

- String.toUpperCase(Locale.ROOT, "?") ? "SS"
- Case folding produces "ss", matching Unicode caseless comparison rules.


jshell> "\u00df".equalsIgnoreCase("ss")
$22 ==> false

jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
$24 ==> true


### Motivation & Direction

Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.

- Unicode-compliant **full** case folding.
- Simpler, stable and more efficient case-less matching without workarounds.
- Brings Java's string comparison handling in line with other programming languages/libraries.

This PR proposes to introduce the following comparison methods in `String` class

- boolean equalsFoldCase(String anotherString)
- int compareToFoldCase(String anotherString)
- Comparator<String> UNICODE_CASEFOLD_ORDER

These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.

*Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.

### The New API


   /**
     * Compares this {@code String} to another {@code String} for equality,
     * using <em>Unicode case folding</em>. Two strings are considered equal
     * by this method if their case-folded forms are identical.
     * <p>
     * Case folding is defined by the Unicode Standard in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")}
     * returns {@code true}, since the character {@code U+00DF} (sharp s) folds
     * to {@code "ss"}.
     * <p>
     * Case folding is locale-independent and language-neutral, unlike
     * locale-sensitive transformations such as {@link #toLowerCase()} or
     * {@link #toUpperCase()}. It is intended for caseless matching,
     * searching, and indexing.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #equalsIgnoreCase(String)}. It implements full case folding as
     * defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code equalsIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }</pre>
     *
     * @param  anotherString
     *         The {@code String} to compare this {@code String} against
     *
     * @return  {@code true} if the given object is not {@code null} and represents
     *          the same sequence of characters as this string under Unicode case
     *          folding; {@code false} otherwise.
     *
     * @see     #compareToFoldCase(String)
     * @see     #equalsIgnoreCase(String)
     * @since   26
     */
    public boolean equalsFoldCase(String anotherString)

    /**
     * Compares two strings lexicographically using <em>Unicode case folding</em>.
     * This method returns an integer whose sign is that of calling {@code compareTo}
     * on the Unicode case folded version of the strings. Unicode Case folding
     * eliminates differences in case according to the Unicode Standard, using the
     * mappings defined in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}.
     * <p>
     * Case folding is a locale-independent, language-neutral form of case mapping,
     * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)},
     * which applies a simpler locale-insensitive uppercase mapping. This method
     * follows the Unicode <em>full</em> case folding, providing stable and
     * consistent results across all environments.
     * <p>
     * Note that this method does <em>not</em> take locale into account, and may
     * produce results that differ from locale-sensitive ordering. Use
     * {@link java.text.Collator} for locale-sensitive comparison.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #compareToIgnoreCase(String)}. It implements the <em>full</em> case folding
     * as defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code compareToIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }</pre>
     *
     * @param   str   the {@code String} to be compared.
     * @return  a negative integer, zero, or a positive integer as the specified
     *          String is greater than, equal to, or less than this String,
     *          ignoring case considerations by case folding.
     * @see     #equalsFoldCase(String)
     * @see     #compareToIgnoreCase(String)
     * @see     java.text.Collator
     * @since   26
     */
    public int compareToFoldCase(String str) 

    /**
     * A Comparator that orders {@code String} objects as by
     * {@link #compareToFoldCase(String) compareToFoldCase()}.
     *
     * @see     #compareToFoldCase(String)
     * @since   26
     */
    public static final Comparator<String> UNICODE_CASEFOLD_ORDER;



### Usage Examples

Sharp s (U+00DF) case-folds to "ss"


    "stra?e".equalsIgnoreCase("strasse");             // false
    "stra?e".compareToIgnoreCase("strasse");          // != 0
    "stra?e".equalsFoldCase("strasse");               // true



### Performance

The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing  compareToIgnoreCase().


Benchmark                                         Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.asciiGreekLower         avgt   15  20.195 ? 0.300  ns/op
StringCompareToIgnoreCase.asciiGreekLowerCF       avgt   15  11.051 ? 0.254  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLower    avgt   15   6.035 ? 0.047  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLowerCF  avgt   15  14.786 ? 0.382  ns/op
StringCompareToIgnoreCase.asciiLower              avgt   15  17.688 ? 1.396  ns/op
StringCompareToIgnoreCase.asciiLowerCF            avgt   15  44.552 ? 0.155  ns/op
StringCompareToIgnoreCase.asciiUpperLower         avgt   15  13.069 ? 0.487  ns/op
StringCompareToIgnoreCase.asciiUpperLowerCF       avgt   15  58.684 ? 0.274  ns/op
StringCompareToIgnoreCase.greekLower              avgt   15  20.642 ? 0.082  ns/op
StringCompareToIgnoreCase.greekLowerCF            avgt   15   7.255 ? 0.271  ns/op
StringCompareToIgnoreCase.greekUpperLower         avgt   15   5.737 ? 0.013  ns/op
StringCompareToIgnoreCase.greekUpperLowerCF       avgt   15  11.100 ? 1.147  ns/op
StringCompareToIgnoreCase.lower                   avgt   15  20.192 ? 0.044  ns/op
StringCompareToIgnoreCase.lowerrCF                avgt   15  11.257 ? 0.259  ns/op
StringCompareToIgnoreCase.supLower                avgt   15  54.801 ? 0.415  ns/op
StringCompareToIgnoreCase.supLowerCF              avgt   15  15.207 ? 0.418  ns/op
StringCompareToIgnoreCase.supUpperLower           avgt   15  14.431 ? 0.188  ns/op
StringCompareToIgnoreCase.supUpperLowerCF         avgt   15  19.149 ? 0.985  ns/op
StringCompareToIgnoreCase.upperLower              avgt   15   5.650 ? 0.051  ns/op
StringCompareToIgnoreCase.upperLowerCF            avgt   15  14.338 ? 0.352  ns/op
StringCompareToIgnoreCase.utf16SubLower           avgt   15  14.774 ? 0.200  ns/op
StringCompareToIgnoreCase.utf16SubLowerCF         avgt   15   2.669 ? 0.041  ns/op
StringCompareToIgnoreCase.utf16SupUpperLower      avgt   15  16.250 ? 0.099  ns/op
StringCompareToIgnoreCase.utf16SupUpperLowerCF    avgt   15  11.524 ? 0.327  ns/op



### Refs

[Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790)
[Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping)
[Unicode Technical Standard #18:  Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches)
[Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt)
[Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt)

### Other Languages

**Python string.casefold()**

The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons.

**Perl?s fc()**

Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings.
Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case.
Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. 

**ICU4J UCharacter.foldCase (Java)** 

Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF).
Method Signature (String based): public static String foldCase(String str, int options)
Method Signature (CharSequence & Appendable based): public static <A extends Appendable> A foldCase(CharSequence src, A dest, int options, Edits edits)
Key Features:
Case Folding: Converts a string to its case-folded equivalent.
Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings.
Context Insensitive: The mapping of a character is not affected by surrounding characters.
Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text.
Result Length: The resulting string can be longer or shorter than the original.
Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes.

**u_strFoldCase (C/C++)**

A lower-level C API function for case folding a string.
Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior.
Availability: Found in the ustring.h and unistr.h headers in the ICU4C library.

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

Commit messages:
 - 8365675: Add String Unicode Case-Folding Support

Changes: https://git.openjdk.org/jdk/pull/26892/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365675
  Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892

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

From mullan at openjdk.org  Fri Oct  3 19:18:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 3 Oct 2025 19:18:11 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <I8KK1qdpY7YWffSfwUPka4OeS1ZXxJjBaod4UabQAng=.2be979d4-6125-4fe7-8855-bf8aaa58b20c@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

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

> 1: /*

Line 506: s/still/also/
508: s/decrypt/decrypt the/
510: s/PEMEncoder/PEMDecoder
511: put code around null

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

> 1: /*

Line 492: "Any errors using the {@code Provider} will occur during decoding."

What does that mean? Does it mean they are thrown by this method? If so, it should be declared as an exception.

Also: 495: s/to/with/
496: put code around null

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

> 84:  * <p> If the PEM type does not have a corresponding class,
> 85:  * {@code decode(String)} and {@code decode(InputStream)} will return a
> 86:  * {@link PEM}.

s/PEM/PEM object/

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

> 101:  *
> 102:  * <p> A new {@code PEMDecoder} instance is created when configured
> 103:  * with {@link #withFactory(Provider)} and/or

I think you can just say "or" instead of "and/or".

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

> 104:  * {@link #withDecryption(char[])}. The {@link #withFactory(Provider)} method
> 105:  * uses the specified provider to produce cryptographic objects from
> 106:  * {@link KeyFactory} and{@link CertificateFactory}.

space after "and".

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

> 105:  * uses the specified provider to produce cryptographic objects from
> 106:  * {@link KeyFactory} and{@link CertificateFactory}.
> 107:  * {@link #withDecryption(char[])} configures the decoder to process

Say "The withDecryption(char[]) method" so this is more visible as a new sentence.

Also: s/process/decode and decrypt/

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

> 107:  * {@link #withDecryption(char[])} configures the decoder to process
> 108:  * encrypted private key PEM data using the given password.
> 109:  * If decryption fails, a {@link IllegalArgumentException} is thrown.

s/a/an/

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

> 133:  * {@code X.509 CERTIFICATE}, {@code CRL}, and {@code RSA PRIVATE KEY}.
> 134:  *
> 135:  * @see PEMEncoder

line 126, I think the "." should be on this line.

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

> 337:      * a {@link PEM} is returned containing the
> 338:      * type identifier and Base64 encoding. Any non-PEM data preceding
> 339:      * the PEM header will be stored in {@code leadingData}.  Other

Most of my comments below on decode that takes an input stream also apply to this method.

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

> 372:      * the PEM footer or the end of the stream. If an I/O error occurs,
> 373:      * the read position in the stream may become inconsistent.
> 374:      * It is recommended to perform no further decoding operations

First sentence (line 367), change to: "Decodes and returns a DEREncodable of the specified class for the specified InputStream."

368: s/extend/extend or implement/

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

> 376:      *
> 377:      * <p> If the class parameter is {@code PEM.class},
> 378:      * a {@link PEM} is returned containing the

s/PEM/PEM object/

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

> 377:      * <p> If the class parameter is {@code PEM.class},
> 378:      * a {@link PEM} is returned containing the
> 379:      * type identifier and Base64 encoding. Any non-PEM data preceding

s/Base64 encoding/Base64-encoded data/

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

> 379:      * type identifier and Base64 encoding. Any non-PEM data preceding
> 380:      * the PEM header will be stored in {@code leadingData}.  Other
> 381:      * class parameters will not return preceding non-PEM data.

Suggest rewording as: "For `DEREncodable` types other than `PEM`, leading data is ignored and not returned as part of the `DEREncodable` object."

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

> 389:      *   {@code DEREncodable}.
> 390:      * @return a {@code DEREncodable} typecast to {@code tClass}
> 391:      * @throws IOException on IO or PEM syntax error where the

386: "extends or implements"

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

> 389:      *   {@code DEREncodable}.
> 390:      * @return a {@code DEREncodable} typecast to {@code tClass}
> 391:      * @throws IOException on IO or PEM syntax error where the

Why would bad PEM syntax be an IOE? Should this be an IAE, similar to a decoding error?

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

> 391:      * @throws IOException on IO or PEM syntax error where the
> 392:      * {@code InputStream} did not complete decoding.
> 393:      * @throws EOFException at the end of the {@code InputStream}

How about: "if the end of the input stream has been reached unexpectedly"

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

> 392:      * {@code InputStream} did not complete decoding.
> 393:      * @throws EOFException at the end of the {@code InputStream}
> 394:      * @throws IllegalArgumentException on error with arguments or in decoding

Can you be more specific here? What does "on error with arguments" mean? What type of decoding issues result in IAE?

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

> 393:      * @throws EOFException at the end of the {@code InputStream}
> 394:      * @throws IllegalArgumentException on error with arguments or in decoding
> 395:      * @throws ClassCastException if {@code tClass} is invalid for the PEM type

suggest: s/is invalid for/does not represent/

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

> 394:      * @throws IllegalArgumentException on error with arguments or in decoding
> 395:      * @throws ClassCastException if {@code tClass} is invalid for the PEM type
> 396:      * @throws NullPointerException when any input values are null

put code font around null

src/java.base/share/classes/java/security/PEMEncoder.java line 1:

> 1: /*

For withEncryption, suggest changing the first sentence to better match `PEMDecoder.withEncryption` which reads better to me. So suggest:

"Returns a copy of this PEMEncoder that encrypts and encodes private keys using the specified password and default encryption algorithm."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402961418
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402979334
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403075672
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403081459
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403083470
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403085853
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403092375
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403098282
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403066797
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403007926
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403008593
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403015740
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403025383
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403032724
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403063120
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403047428
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403043967
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403040845
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403038460
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402952350

From ascarpino at openjdk.org  Fri Oct  3 20:30:03 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 3 Oct 2025 20:30:03 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v44]
In-Reply-To: <qE1Qr9UVEtIkpPn_EFVFKIbcVhdItJvob-_CVYPiSzU=.d5066ddf-9071-4278-a8a8-04211182f508@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <qE1Qr9UVEtIkpPn_EFVFKIbcVhdItJvob-_CVYPiSzU=.d5066ddf-9071-4278-a8a8-04211182f508@github.com>
Message-ID: <6kH5XMj7nJm1LO7f-uE4waSeiJA6zm6BSWRHQpaa-k0=.a0c66fec-16ec-46ea-9d6d-01cf702b62ab@github.com>

On Tue, 16 Sep 2025 14:58:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> <img alt="image" src="https://github.com/user-attachments/assets/df3b454d-2161-4036-9930-c4f84d887b31" />
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more key checks; some small spec change

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 31:

> 29: import java.io.Serial;
> 30: import java.math.BigInteger;
> 31: import java.security.AsymmetricKey;

Since your original putback used import java.security.* and others below, was it your intent to specify 11 java.security class instead of using a wildcard, or did the IDE do this?

src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 225:

> 223:     }
> 224: 
> 225:     //@Override

Do you need this comment here and the next method below?

src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 452:

> 450:         private static void checkMatch(boolean inSpec, AsymmetricKey k, int kem_id)
> 451:                 throws InvalidKeyException, InvalidAlgorithmParameterException {
> 452:             var p = k.getParams();

nit: It looks like you could have used a `switch (k.params())` here.

src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 499:

> 497:                     DHKEM.I2OSP(params.kdf_id(), 2),
> 498:                     DHKEM.I2OSP(params.aead_id(), 2));
> 499:             kdfAlg = switch (params.kdf_id()) {

I think it would be more efficient to have one switch that sets both values instead of two identical switches to set each.  Similar to what you did in `AEAD()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2395233573
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2402601153
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2402807458
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2402688988

From ascarpino at openjdk.org  Fri Oct  3 20:30:05 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 3 Oct 2025 20:30:05 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v44]
In-Reply-To: <6kH5XMj7nJm1LO7f-uE4waSeiJA6zm6BSWRHQpaa-k0=.a0c66fec-16ec-46ea-9d6d-01cf702b62ab@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <qE1Qr9UVEtIkpPn_EFVFKIbcVhdItJvob-_CVYPiSzU=.d5066ddf-9071-4278-a8a8-04211182f508@github.com>
 <6kH5XMj7nJm1LO7f-uE4waSeiJA6zm6BSWRHQpaa-k0=.a0c66fec-16ec-46ea-9d6d-01cf702b62ab@github.com>
Message-ID: <QFSI_cvhO3laH7hCIYsoI9E6MgZQSaIRyHtxkgDNHx4=.5ba9a81d-738d-42db-8560-238bc532037b@github.com>

On Fri, 3 Oct 2025 17:47:41 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more key checks; some small spec change
>
> src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 452:
> 
>> 450:         private static void checkMatch(boolean inSpec, AsymmetricKey k, int kem_id)
>> 451:                 throws InvalidKeyException, InvalidAlgorithmParameterException {
>> 452:             var p = k.getParams();
> 
> nit: It looks like you could have used a `switch (k.params())` here.

There are also other candidates for switch in `Impl.init()` and `engineInit()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2403038528

From ascarpino at openjdk.org  Fri Oct  3 20:30:06 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 3 Oct 2025 20:30:06 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v43]
In-Reply-To: <khZcPKA_8aNTVyJQp_eoH2VfshwHxrTLcb-L6yV6Smg=.8fb7a066-4e18-4920-866f-2ebf805da553@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <bvMLuVwolSYg-1YaPirWxTQFw3Fagp9_1mwoxAdfh-I=.c6f4bff4-f90e-4690-83d4-d0614d5b6ef7@github.com>
 <gJ_WsnvXKbQetznaKLpXw4HVtgaLhU1y-avbzTOl5GU=.b93e8d43-cd85-4998-8063-0a1c87b23c7e@github.com>
 <0vyXx7KpYnPSBrrt9lcNLlnmzotIYo9ACVMQy3HLX3k=.04011be3-0259-40cf-b8db-dc439a2aaf4b@github.com>
 <dIyetHjTIzftdsvzjBJzBw0zM6xUIMTNxU6tVUrmXHQ=.6bf2fae5-db05-4ebd-9fa6-35fce6b5af95@github.com>
 <khZcPKA_8aNTVyJQp_eoH2VfshwHxrTLcb-L6yV6Smg=.8fb7a066-4e18-4920-866f-2ebf805da553@github.com>
Message-ID: <vuwHaDTVrlgYmMl8rucmNQPXexKp19w4-hH8Mm3HHvE=.a8896b3d-1bab-43f6-bf5c-86889e504e68@github.com>

On Mon, 15 Sep 2025 23:17:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I know it's `getFormat`.  Since there is a length check for "RAW", I was wondering why "PKCS#8", didn't use `psk.getEncoded().length` to checked.  If you are handling the "RAW" case in this method and later on a short key is checked, that is fine.
>
> I'm expecting a `SecretKey` here. If it's "PKCS#8", I probably will have to error out somewhere. But then inside `HPKE` the implementation, it should work with both software and hardware keys so I should not look at `getFormat` anymore. Anyway, I'm just trying to do as much as I can.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2403120951

From mullan at openjdk.org  Fri Oct  3 20:31:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 3 Oct 2025 20:31:58 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
Message-ID: <nso7dDgb79zORCUBiKe1cbtfEbTg0s8n_EKeSUUCLd4=.91071a41-e78a-442a-8bdf-24cf858a6b03@github.com>

On Thu, 25 Sep 2025 23:03:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed some decoder comments

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

> 391: 
> 392:     /**
> 393:      * Creates and encrypts an {@code EncryptedPrivateKeyInfo} from a given

s/a given/the specified/

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

> 392:     /**
> 393:      * Creates and encrypts an {@code EncryptedPrivateKeyInfo} from a given
> 394:      * {@code DEREncodable} and password.  Default algorithm and parameters are

Need to be more specific - what algorithm and what parameters.

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

> 396:      *
> 397:      * @param de the {@code DEREncodable} to be encrypted. Usage
> 398:      *            limited to {@link PrivateKey}, {@link KeyPair}, and

"Usage limited" sounds odd. Maybe "The supported `DEREncodable types are ... An IllegalArgumentException is thrown for any other type."

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

> 400:      * @param password the password used in the PBE encryption.  This array
> 401:      *                 will be cloned before being used.
> 402:      * @return an {@code EncryptedPrivateKeyInfo}

Next line: 

"@throws IllegalArgumentException on initialization errors based on the
arguments passed to the method"

What does this mean - you need to be more specific about what are the error cases. Otherwise it will not be helpful for TCK test writers on how to test this.

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

> 411:      * {@code AlgorithmParameterSpec} are the provider's algorithm defaults.
> 412:      *
> 413:      * @since 25

Throwing a RuntimeException on encryption error is too general.

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

> 533:      * @param decryptKey the decryption key and cannot be {@code null}
> 534:      * @param provider the {@code Provider} used for Cipher decryption and
> 535:      *                 {@code PrivateKey} generation. A {@code null} value will

Same comment about provider as below.

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

> 538:      * @throws GeneralSecurityException if an error occurs parsing,
> 539:      * decrypting the data, or producing the key object.
> 540:      * @throws NullPointerException if {@code decryptKey} is {@code null}

Same comment about exceptions as below.

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

> 563:      */
> 564:     @PreviewFeature(feature = PreviewFeature.Feature.PEM_API)
> 565:     public KeyPair getKeyPair(char[] password) throws GeneralSecurityException {

This should specifically throw an `InvalidKeyException` if decryption fails. I think you want to specify the exact subclasses when it is clearly the right behavior. In this case, the method should always throw `InvalidKeyException` on decryption errors.

Also why generalize it to throw `GeneralSecurityException`? This should throw the same exceptions as `getKeySpec(Key, Provider)` since the params are the same.

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

> 583:      * @param decryptKey the decryption key and cannot be {@code null}
> 584:      * @param provider the {@code Provider} used for Cipher decryption and
> 585:      *                 key generation. A {@code null} value will

Why do you allow null? This is inconsistent with the other methods that take Provider arguments. I think consistency is important.

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

> 586:      *                 use the default provider configuration.
> 587:      * @return a {@code KeyPair} extracted from the encrypted data
> 588:      * @throws GeneralSecurityException if an error occurs parsing,

Same comment as above on the exceptions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403250173
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403251624
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403255532
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403260574
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403264388
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403246374
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403245654
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403237211
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403243416
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403241992

From mullan at openjdk.org  Fri Oct  3 20:32:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 3 Oct 2025 20:32:00 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <nso7dDgb79zORCUBiKe1cbtfEbTg0s8n_EKeSUUCLd4=.91071a41-e78a-442a-8bdf-24cf858a6b03@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <nso7dDgb79zORCUBiKe1cbtfEbTg0s8n_EKeSUUCLd4=.91071a41-e78a-442a-8bdf-24cf858a6b03@github.com>
Message-ID: <fxc_LSu8Pw8ymUXp41QcrNT0rrMnkOZPP7k_cs8XYdI=.09153ff1-8e2c-4755-89a8-26a534d11b13@github.com>

On Fri, 3 Oct 2025 20:24:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed some decoder comments
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 413:
> 
>> 411:      * {@code AlgorithmParameterSpec} are the provider's algorithm defaults.
>> 412:      *
>> 413:      * @since 25
> 
> Throwing a RuntimeException on encryption error is too general.

On NPE, there is no `key` param.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2403265921

From weijun at openjdk.org  Fri Oct  3 20:55:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 3 Oct 2025 20:55:52 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
Message-ID: <QEn79dm-lDcfTWZcY_mE3SwMyJMmeVEH1IydafcebwM=.cfe68998-b6e4-4e57-a2d8-ff598e8829ba@github.com>

On Thu, 2 Oct 2025 18:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more review comments from Weijun and Sean

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 209:

> 207:             }
> 208:         } finally {
> 209:             destroyPBEKey(pbeKey);

The `PBEKeySpec` object created in both cases should also be cleaned up by calling `keySpec.clearPassword()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2403323256

From duke at openjdk.org  Sat Oct  4 10:31:47 2025
From: duke at openjdk.org (Bernd)
Date: Sat, 4 Oct 2025 10:31:47 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange
In-Reply-To: <yMGhnOT8WxEd-y_dNQAaTFoGr1z9n9p6fub6j44rr3c=.127191ee-1f7a-4288-a2f1-d21083b4640b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
 <yMGhnOT8WxEd-y_dNQAaTFoGr1z9n9p6fub6j44rr3c=.127191ee-1f7a-4288-a2f1-d21083b4640b@github.com>
Message-ID: <5EkdnKfJtxe3vsLOKtBFIY-az7weziM5gUVQsGKlUF4=.0f444330-cc27-4796-9424-9a9666afaf5c@github.com>

On Fri, 3 Oct 2025 18:30:08 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 802:
>> 
>>> 800:                         FFDHE_3072,
>>> 801:                         FFDHE_4096,
>>> 802:                         FFDHE_6144,
>> 
>> Unrelated change?
>
> No, the choise to knock out ffdhe6144 and 8192 from the default list was done on purpose.  I don't think they get much use and they can always be re-enabled via SSLParameters or the system property.  We're open to feedback on this if you or others feel like they should remain in place, though.

The change is I think ok, doesn?t make much of a difference for most cases I was just thinking it needed its own commit and ticket reference but if it was intentional fine as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2403898451

From weijun at openjdk.org  Sat Oct  4 18:54:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 4 Oct 2025 18:54:54 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <QEn79dm-lDcfTWZcY_mE3SwMyJMmeVEH1IydafcebwM=.cfe68998-b6e4-4e57-a2d8-ff598e8829ba@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
 <QEn79dm-lDcfTWZcY_mE3SwMyJMmeVEH1IydafcebwM=.cfe68998-b6e4-4e57-a2d8-ff598e8829ba@github.com>
Message-ID: <pd01OhObrnNjOWygWVqbdPypXS_-sDhZKS92HhOVIYU=.e52f0d90-be8a-4882-858c-bc2b9acd8e88@github.com>

On Fri, 3 Oct 2025 20:53:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more review comments from Weijun and Sean
>
> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 209:
> 
>> 207:             }
>> 208:         } finally {
>> 209:             destroyPBEKey(pbeKey);
> 
> The `PBEKeySpec` object created in both cases should also be cleaned up by calling `keySpec.clearPassword()`.

The password in `PBKDF2KeyImpl` is not cleaned. It does have a `clear` method but no `destroy`. Consider adding a `destroy` to it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2404131005

From mpowers at openjdk.org  Sat Oct  4 21:25:58 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 4 Oct 2025 21:25:58 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
Message-ID: <2h4ufobcAqNL2aXFVGTjiMWHB02tt_ZHuIdIspwWosk=.31fdff09-6a7a-4959-8c70-609368ff0b42@github.com>

On Tue, 30 Sep 2025 19:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another day another iteration
>
> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 84:
> 
>> 82:     private int keyLength = -1;
>> 83: 
>> 84:     protected void Init(AlgorithmParameterSpec paramSpec)
> 
> I don't think you need a separate method. Put this code in the constructor. Same for the other `Init` method. Then you can also make the fields final.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 174:
> 
>> 172:     }
>> 173: 
>> 174:     void processMacData(AlgorithmParameterSpec params,
> 
> Can be static?

No - perhaps in an earlier iteration of the code, but not in the latest.

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 186:
> 
>> 184:             kdfHmac = macAlgorithm;
>> 185:             Hmac = macAlgorithm;
>> 186:         }
> 
> Did you consider adding another kdfHmac parameter to the method and passing in the correct values?

This comment appears to apply to an earlier iteration. It is not easy to keep track of all these iterations. I believe the latest iteration fixes this.

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 71:
> 
>> 69:  * </pre>
>> 70:  */
>> 71: final public class PBKDF2Parameters {
> 
> `public` should be before `final`. For reference, see the last sentence of https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.1.1

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2404173249
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2404173197
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2404173157
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2404173428

From mpowers at openjdk.org  Sat Oct  4 21:26:01 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 4 Oct 2025 21:26:01 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <jwN9HMSZfEdODrmvKwPGaWk8HxouxdNpkwaNNkVUccw=.fd240dc5-0538-4fbc-ab76-728eaaa61e67@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
 <jwN9HMSZfEdODrmvKwPGaWk8HxouxdNpkwaNNkVUccw=.fd240dc5-0538-4fbc-ab76-728eaaa61e67@github.com>
Message-ID: <ppJgACnyNXYfaCrR4NrbMYjcRRXeTmqvmoE-s1vOiFE=.48fc196d-ab39-42b5-bdb7-95b1838dde3f@github.com>

On Thu, 2 Oct 2025 21:01:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more review comments from Weijun and Sean
>
> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 267:
> 
>> 265:             hmac = macAlgorithm;
>> 266:         } else {
>> 267:             throw new ParsingException("unexpected algorithm");
> 
> Do we no longer support `HmacPBESHA512` etc?

Don't know how that happened. It's obviously wrong. Fixed.

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 364:
> 
>> 362:         }
>> 363: 
>> 364:         if (this.encoded != null)
> 
> I don't think it's worth caching the `encoded` inside the object. The `getEncoded` method is only called once for each object. Just return the `encoded` output directly.

Agreed. Since it's no longer cached, there is also no reason to clone the `encoded` output.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2404173019
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2404172989

From hchao at openjdk.org  Sun Oct  5 12:27:24 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sun, 5 Oct 2025 12:27:24 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v2]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <osmzSDvG9ftU7Ha53P0VNZIl29cH0YN3O8ToCsNd-0g=.3159d9c7-6505-416e-8ba6-39661ec7b942@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Updates with review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/c7ba12a7..3c0e91ed

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

  Stats: 32 lines in 3 files changed: 19 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From hchao at openjdk.org  Sun Oct  5 12:27:26 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sun, 5 Oct 2025 12:27:26 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v2]
In-Reply-To: <MIFOZmCTj6r3YfGNkcSCkY1ZZmdgbkHYnqU_SipHZTg=.93f4e70b-1dea-4c3f-a633-bb697bdde1cd@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <MIFOZmCTj6r3YfGNkcSCkY1ZZmdgbkHYnqU_SipHZTg=.93f4e70b-1dea-4c3f-a633-bb697bdde1cd@github.com>
Message-ID: <DPvBPGbjH6Pb13RvMBy6D-on6VY-ObOVq7dRzDnRaLE=.6991c53c-da4c-457d-9bf7-431b950ef89b@github.com>

On Fri, 3 Oct 2025 17:22:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates with review comments
>
> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 138:
> 
>> 136:         private final PublicKey pkR;
>> 137:         private final PrivateKey skR;
>> 138:         private final AlgorithmParameterSpec spec;
> 
> This variable is not being used, it can be removed together with the constructor parameter.

Removed variable spec.

> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 316:
> 
>> 314:                 // Skip AlgorithmParameters for KEMs (not supported)
>> 315:                 if (namedGroupSpec == NamedGroupSpec.NAMED_GROUP_KEM) {
>> 316:                     if (defaultProviderName == null) {
> 
> We assume that if provider is not null then it must be DH without doing any checks to confirm that. It would be cleaner to call getProvider() instead.
> 
>> Provider p = getProvider();
>                     if (p == null) {
>                         KeyFactory.getInstance(name);
>                     } else {
>                         KeyFactory.getInstance(name, p);
>                     }

Done.

> src/java.base/share/classes/sun/security/util/Hybrid.java line 100:
> 
>> 98:     private static KEM getKEM(String name) throws NoSuchAlgorithmException {
>> 99:         if (name.startsWith("secp") || name.equals("X25519") ||
>> 100:                 name.equals("X448")) {
> 
> Do we need `X448` here? Also, please provide a comment for this method with functionality description.

X448 removed, and comment added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2404458729
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2404458518
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2404458608

From hchao at openjdk.org  Sun Oct  5 12:27:26 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sun, 5 Oct 2025 12:27:26 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v2]
In-Reply-To: <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
Message-ID: <2eDcr2BqION52VUhVBxpHNnHgJ7H-yODIbhrLkEqPUk=.912193fb-824a-4fdd-bbe9-93cd761dc9e0@github.com>

On Fri, 3 Oct 2025 17:10:01 GMT, Bernd <duke at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates with review comments
>
> src/java.base/share/classes/com/sun/crypto/provider/DH.java line 224:
> 
>> 222:             } else if (k instanceof XECKey xkey
>> 223:                     && xkey.getParams() instanceof NamedParameterSpec ns) {
>> 224:                 if (ns.getName().equalsIgnoreCase("X25519")) {
> 
> Maybe use NamedParameterSpec.X25519?

Updated.

> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 218:
> 
>> 216:             PredefinedDHParameterSpecs.ffdheParams.get(8192)),
>> 217: 
>> 218:     ML_KEM_512(0x0200, "MLKEM512",
> 
> Are they needed for this Jep?

We added ML-KEM NamedGroups with null AlgorithmParameterSpec, and they won?t appear as negotiable named groups.  They were added to support debug display and recognition of MLKEM named groups when used in the key share, so we can see them in debug and know if they are used. It'd help for interop debugging/testing.

> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 653:
> 
>> 651:         NAMED_GROUP_XDH("XDH", XDHScheme.instance),
>> 652: 
>> 653:         NAMED_GROUP_KEM("PQC", KEMScheme.instance),
> 
> That Choice of Name needs probably an explaining comment if it is for pure PQC and/ormhybrid?

Comment added.

> src/java.base/share/classes/sun/security/util/Hybrid.java line 290:
> 
>> 288:     private static byte[] concat(byte[]... inputs) {
>> 289:         ByteArrayOutputStream o = new ByteArrayOutputStream();
>> 290:         Arrays.stream(inputs).forEach(o::writeBytes);
> 
> Do we really want a non presized buffer and a stream in the handshake hot path?

Updated to use presized buffer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2404458870
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2404459083
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2404459100
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2404459855

From jnimeh at openjdk.org  Sun Oct  5 13:50:58 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Sun, 5 Oct 2025 13:50:58 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v2]
In-Reply-To: <5EkdnKfJtxe3vsLOKtBFIY-az7weziM5gUVQsGKlUF4=.0f444330-cc27-4796-9424-9a9666afaf5c@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
 <yMGhnOT8WxEd-y_dNQAaTFoGr1z9n9p6fub6j44rr3c=.127191ee-1f7a-4288-a2f1-d21083b4640b@github.com>
 <5EkdnKfJtxe3vsLOKtBFIY-az7weziM5gUVQsGKlUF4=.0f444330-cc27-4796-9424-9a9666afaf5c@github.com>
Message-ID: <oDu6SgIENutIjVC4IxqOPO3lFDG0oqwJE7U2ekUGPYQ=.a226b985-7c30-43d6-b3a3-00a508e360ed@github.com>

On Sat, 4 Oct 2025 10:29:33 GMT, Bernd <duke at openjdk.org> wrote:

>> No, the choise to knock out ffdhe6144 and 8192 from the default list was done on purpose.  I don't think they get much use and they can always be re-enabled via SSLParameters or the system property.  We're open to feedback on this if you or others feel like they should remain in place, though.
>
> The change is I think ok, doesn?t make much of a difference for most cases I was just thinking it needed its own commit and ticket reference but if it was intentional fine as well.

I think you make a fair point here.  It probably deserves its own change, JBS entry, CSR, etc.  We'll leave them in for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2404493866

From mullan at openjdk.org  Mon Oct  6 12:38:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Oct 2025 12:38:47 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores
In-Reply-To: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
Message-ID: <P9c5IM615DIjJpw6CN2FpFT3Z4aLiuNzGDaTgxIwLWk=.9c03ccf4-8af6-4b3c-9f81-355d2015fb60@github.com>

On Fri, 3 Oct 2025 16:26:13 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This PR improves security warning when using JKS or JCEKS keystores.

src/java.base/share/classes/java/security/KeyStore.java line 832:

> 830:     }
> 831: 
> 832:     private static void outdatedKeyStoreLog(String type) {

I think it would be simpler to include this warning in the constructor of `sun.security.provider.JavaKeyStore`. Then you don't need to call this method.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 244:

> 242:     private boolean allAliasesFound = true;
> 243:     private boolean hasMultipleManifests = false;
> 244:     private boolean outdatedFormat = false;

Suggest calling this variable "weakKeyStore".

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1490:

> 1488:             warnings.add(String.format(rb.getString(
> 1489:                     "outdated.storetype.warning"),
> 1490:                     realStoreType, keystore));

You can pass `store.getType()` instead of `realStoreType` here.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 2419:

> 2417:                     outdatedFormat = true;
> 2418:                 }
> 2419:             }

I don't think you need the `realStoreType` field. If you move this check to the end of the `else` block starting on line 2424 (which means the keystore is a file), and just check the `KeyStore.type()` I think it should be sufficient, ex:


if (store.getType().equalsIgnoreCase("JKS")
        || store.getType().equalsIgnoreCase("JCEKS")) {
    weakKeyStore = true;
}

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 225:

> 223: signature.verification.failed.on.entry.1.when.reading.via.jarinputstream=Signature verification failed on entry %s when reading via JarInputStream
> 224: signature.verification.failed.on.entry.1.when.reading.via.jarfile=Signature verification failed on entry %s when reading via JarFile
> 225: outdated.storetype.warning=%1$s uses outdated cryptographic algorithms and will be removed in a future release. Migrate to PKCS12 using:\n\

Call this "jks.storetype.warning" so it is consistent with `keytool.properties`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2406034343
PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2406011582
PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2406027915
PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2406025879
PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2406004701

From mullan at openjdk.org  Mon Oct  6 13:14:38 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Oct 2025 13:14:38 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v3]
In-Reply-To: <dcocyfrABZ5Ty7grHShtJ_u_rC-cNrQiVktfqAsktwk=.5285a479-4d48-4748-9b43-2e0663d6da68@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <dcocyfrABZ5Ty7grHShtJ_u_rC-cNrQiVktfqAsktwk=.5285a479-4d48-4748-9b43-2e0663d6da68@github.com>
Message-ID: <l17x001greEzMbl04HMtSldxj9F8oHfhTW2N1VfBzPU=.4651cd41-0704-4c69-bd9c-bfec80691e71@github.com>

On Wed, 3 Sep 2025 19:35:27 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - I removed signature algorithms output because the information is created during TLS handshake
>  - Merge branch 'master' into secsettings
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

Please add a release note for this change and update the bug title and description to note that you are not including signature algorithms now - thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3371568610

From weijun at openjdk.org  Mon Oct  6 13:23:05 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 13:23:05 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v3]
In-Reply-To: <dcocyfrABZ5Ty7grHShtJ_u_rC-cNrQiVktfqAsktwk=.5285a479-4d48-4748-9b43-2e0663d6da68@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <dcocyfrABZ5Ty7grHShtJ_u_rC-cNrQiVktfqAsktwk=.5285a479-4d48-4748-9b43-2e0663d6da68@github.com>
Message-ID: <K56jees88glu5KO-X714qx0bT83lb4oSdgh1B6XKTVk=.7d4f6345-70e1-483c-bdb5-693b228c9926@github.com>

On Wed, 3 Sep 2025 19:35:27 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - I removed signature algorithms output because the information is created during TLS handshake
>  - Merge branch 'master' into secsettings
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

The ciphersuites are different for TLS <=1.2 and 1.3. Do we just mix them in the same list?

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3371618738

From abarashev at openjdk.org  Mon Oct  6 14:00:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 6 Oct 2025 14:00:34 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v2]
In-Reply-To: <osmzSDvG9ftU7Ha53P0VNZIl29cH0YN3O8ToCsNd-0g=.3159d9c7-6505-416e-8ba6-39661ec7b942@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <osmzSDvG9ftU7Ha53P0VNZIl29cH0YN3O8ToCsNd-0g=.3159d9c7-6505-416e-8ba6-39661ec7b942@github.com>
Message-ID: <9vRpBCW-57VDb5ASOBF7ftNgj1-Njad6HQedTIy9qWE=.106f604a-a977-486d-9047-ee0c309fcc16@github.com>

On Sun, 5 Oct 2025 12:27:24 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates with review comments

test/jdk/sun/security/ssl/CipherSuite/DisabledCurve.java line 31:

> 29:         DisabledCurve DISABLE_NONE PASS
> 30:  * @run main/othervm -Djdk.tls.namedGroups="secp384r1"
> 31:         DisabledCurve secp384r1 FAIL

This test case fails whether we specify `-Djdk.tls.namedGroups="secp384r1"` or not, because the test certificate also uses `secp384r1` algorithm in the signature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2406492497

From mullan at openjdk.org  Mon Oct  6 14:53:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Oct 2025 14:53:50 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v10]
In-Reply-To: <m9EfrVX42Nmjr7wx03iRw7ETXbfx1GcQQk6QKyfg6FU=.e038bba8-b432-42fe-b51e-9dcb574ed86d@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
 <m9EfrVX42Nmjr7wx03iRw7ETXbfx1GcQQk6QKyfg6FU=.e038bba8-b432-42fe-b51e-9dcb574ed86d@github.com>
Message-ID: <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>

On Fri, 26 Sep 2025 22:59:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Allow password hiding even if there is no `System.console`. A manual test is included.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update bug list in test

src/java.base/share/classes/sun/security/util/Password.java line 62:

> 60:                     consoleEntered = ConsoleHolder.readPassword();
> 61:                     // readPassword returns "" if you just press ENTER with the built-in Console,
> 62:                     // to be compatible with old Password class, change to null

This is an odd comment - what is the "old Password class"? Maybe you just want to remove the "to be compatible with old Password class" part from this comment.

test/jdk/sun/security/tools/keytool/EchoPassword.java line 1:

> 1: /*

In this test, where are you verifying that a warning is shown when the input is echoed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2406585327
PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2406794334

From weijun at openjdk.org  Mon Oct  6 15:07:19 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 15:07:19 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v11]
In-Reply-To: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
Message-ID: <P6QvxP6d92txbI9uquJqqjxflJylQKH3Ri2ry-vDxA0=.fb52a205-c489-4660-a55e-a3c2b7a67514@github.com>

> Allow password hiding even if there is no `System.console`. A manual test is included.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more cleanup; simpler reallocation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27196/files
  - new: https://git.openjdk.org/jdk/pull/27196/files/15e76512..befc698a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=09-10

  Stats: 15 lines in 1 file changed: 5 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196

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

From weijun at openjdk.org  Mon Oct  6 15:16:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 15:16:54 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v10]
In-Reply-To: <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
 <m9EfrVX42Nmjr7wx03iRw7ETXbfx1GcQQk6QKyfg6FU=.e038bba8-b432-42fe-b51e-9dcb574ed86d@github.com>
 <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>
Message-ID: <6VesvUNEDQ5ml401NDz3AIPxSDjjmF2YAoysdiB69Y4=.a3e17f7e-6920-487d-9f47-1f0218e835ee@github.com>

On Mon, 6 Oct 2025 14:14:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update bug list in test
>
> src/java.base/share/classes/sun/security/util/Password.java line 62:
> 
>> 60:                     consoleEntered = ConsoleHolder.readPassword();
>> 61:                     // readPassword returns "" if you just press ENTER with the built-in Console,
>> 62:                     // to be compatible with old Password class, change to null
> 
> This is an odd comment - what is the "old Password class"? Maybe you just want to remove the "to be compatible with old Password class" part from this comment.

I meant to be consistent with the parse-from-inputstream behavior, but I just realized the more important check here is for null since that is a possible return value. For an empty input, even if we don't stop here, `consoleBytes` and `in` will be empty and the first `in.read()` would return -1 and `offset` stays 0 and a null will be returned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2406926705

From mpowers at openjdk.org  Mon Oct  6 15:24:30 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 6 Oct 2025 15:24:30 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
Message-ID: <MxZzXmqpp0btbmLQAcgLP9mYaqubVl4-8_dJybr9_7Q=.dcd8d985-06c9-4872-9733-b81fd04e1b0b@github.com>

On Tue, 30 Sep 2025 19:18:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another day another iteration
>
> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: package com.sun.crypto.provider;
> 
> This class can be moved to the `sun/security/pkcs12` package and made package-private as it is only referenced by `PKCS12KeyStore`. We can always move it again later if necessary.

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2406976174

From mpowers at openjdk.org  Mon Oct  6 15:24:32 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 6 Oct 2025 15:24:32 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
Message-ID: <h3w_dBacQsnbCktD7AAVZ4fYKLqOdEsVPLlNqmZbfSs=.c99b4905-23e8-423d-96e5-af47dd3143ff@github.com>

On Mon, 29 Sep 2025 21:07:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another day another iteration
>
> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 69:
> 
>> 67:     private String pbmac1AlgorithmName = null;
>> 68: 
>> 69:     private byte[] salt = null;
> 
> Instead of including so many PBKDF2 components, can we just put one `PBKDF2Parameters` field here? We can also remove the `getPrf`, `getSalt`, and `getIterations` methods. IMO it's not awkward to call `pbmac1Params.getKdfParams().getPrf()` etc.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2406977451

From weijun at openjdk.org  Mon Oct  6 15:27:32 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 15:27:32 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v10]
In-Reply-To: <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
 <m9EfrVX42Nmjr7wx03iRw7ETXbfx1GcQQk6QKyfg6FU=.e038bba8-b432-42fe-b51e-9dcb574ed86d@github.com>
 <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>
Message-ID: <OCP59TT9G3uPXzKco7vWoxGFJqE0r7MhesBHGvUwOAI=.275f753a-c566-4c6e-9691-4160b21813c3@github.com>

On Mon, 6 Oct 2025 14:51:13 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update bug list in test
>
> test/jdk/sun/security/tools/keytool/EchoPassword.java line 1:
> 
>> 1: /*
> 
> In this test, where are you verifying that a warning is shown when the input is echoed?

As I mentioned in the comment, an IDE Run Window or in JShell is the only case I know now that the input is echoed on screen. This test will not cover those cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2406995465

From weijun at openjdk.org  Mon Oct  6 15:31:27 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 15:31:27 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v12]
In-Reply-To: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
Message-ID: <b1PT909B5J0Hl4Gplp8y42CiNVEjt2Oc8MK8F_DRTWY=.7b6d883d-2318-4a28-85c7-7483ede93e8b@github.com>

> Allow password hiding even if there is no `System.console`. A manual test is included.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more null check; one less empty check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27196/files
  - new: https://git.openjdk.org/jdk/pull/27196/files/befc698a..93220920

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=10-11

  Stats: 7 lines in 3 files changed: 2 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196

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

From mdonovan at openjdk.org  Mon Oct  6 16:00:34 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 6 Oct 2025 16:00:34 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v3]
In-Reply-To: <K56jees88glu5KO-X714qx0bT83lb4oSdgh1B6XKTVk=.7d4f6345-70e1-483c-bdb5-693b228c9926@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <dcocyfrABZ5Ty7grHShtJ_u_rC-cNrQiVktfqAsktwk=.5285a479-4d48-4748-9b43-2e0663d6da68@github.com>
 <K56jees88glu5KO-X714qx0bT83lb4oSdgh1B6XKTVk=.7d4f6345-70e1-483c-bdb5-693b228c9926@github.com>
Message-ID: <EVF3mrdthxokVIKWw1YQEu0FB-A-gNHmMj4E4GFxjiw=.8bbe049b-45ac-49e1-94bb-677edc450cc9@github.com>

On Mon, 6 Oct 2025 13:20:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The ciphersuites are very different for TLS <=1.2 and 1.3. Do we just mix them in the same list?

Ciphersuites are printed in the order that `SSLContext.getEnabledCipherSuites()` returns them.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3372460873

From mdonovan at openjdk.org  Mon Oct  6 16:25:11 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 6 Oct 2025 16:25:11 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v3]
In-Reply-To: <l17x001greEzMbl04HMtSldxj9F8oHfhTW2N1VfBzPU=.4651cd41-0704-4c69-bd9c-bfec80691e71@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <dcocyfrABZ5Ty7grHShtJ_u_rC-cNrQiVktfqAsktwk=.5285a479-4d48-4748-9b43-2e0663d6da68@github.com>
 <l17x001greEzMbl04HMtSldxj9F8oHfhTW2N1VfBzPU=.4651cd41-0704-4c69-bd9c-bfec80691e71@github.com>
Message-ID: <4ycc76TzINSAAFMg07kE9TYNlnDGZsnZZ6V5VH3BGbo=.aeb09e4f-114d-4c1a-9dde-bad2dad68f5b@github.com>

On Mon, 6 Oct 2025 13:11:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please add a release note for this change and update the bug title and description to note that you are not including signature algorithms now - thanks.

I updated the bug and added a release note https://bugs.openjdk.org/browse/JDK-8369225.

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

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3372622369

From valeriep at openjdk.org  Mon Oct  6 18:00:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 6 Oct 2025 18:00:02 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE
In-Reply-To: <bIQa4lpaiAp04nVn-3k3ebfDAh6vdfenL6NAb8mxxjM=.84ab3ec0-8830-4616-9d09-345735e97ffd@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
 <bIQa4lpaiAp04nVn-3k3ebfDAh6vdfenL6NAb8mxxjM=.84ab3ec0-8830-4616-9d09-345735e97ffd@github.com>
Message-ID: <C2m9eDljR4DDIJWSNIOCYvWLXrowIRbD_9AEqUx3SLQ=.ae3d3778-b874-417d-82a7-321ad3ec2e43@github.com>

On Fri, 3 Oct 2025 02:37:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 
>> 
>> Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 
>> 
>> Thanks in advance for the review~
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 329:
> 
>> 327:                     SHA512TRUNCATED.length());
>> 328:             sha512SlashIdx = (sha512Idx != -1 ? sha512Idx + 3 : -2);
>> 329:         }
> 
> The logic is quite complex. Can you create a dedicated method for it like `indexOfRealSlashIn(String s)`?
> 
> We can even call it on the mode part.

There are quite a few values being updated here, that's why I didn't make it into a method initially. Let me think about it more...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27615#discussion_r2407720539

From duke at openjdk.org  Mon Oct  6 18:24:01 2025
From: duke at openjdk.org (Larry Cable)
Date: Mon, 6 Oct 2025 18:24:01 GMT
Subject: RFR: JDK-8365400: add JFR event to capture location (if available) of
 class files loaded
Message-ID: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>

while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint.

therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined.

this association can be used for various "applications" such as basic auditing etc

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8365400
 - JDK-8365400: add JFR event to capture location (if available) of class files loaded

Changes: https://git.openjdk.org/jdk/pull/27656/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27656&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365400
  Stats: 111 lines in 6 files changed: 103 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27656/head:pull/27656

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

From lmesnik at openjdk.org  Mon Oct  6 18:39:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 6 Oct 2025 18:39:50 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
References: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
Message-ID: <tNjEoPi0vqLQI_1SopA4EmVT6uJNeBJIFxHokB_iaAM=.997a8607-df62-4d99-88b9-a2061e9e5b7d@github.com>

On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable <duke at openjdk.org> wrote:

> while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint.
> 
> therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined.
> 
> this association can be used for various "applications" such as basic auditing etc

Can you please a new test for the added functionality?

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

PR Comment: https://git.openjdk.org/jdk/pull/27656#issuecomment-3373312592

From weijun at openjdk.org  Mon Oct  6 19:51:46 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 19:51:46 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE
In-Reply-To: <C2m9eDljR4DDIJWSNIOCYvWLXrowIRbD_9AEqUx3SLQ=.ae3d3778-b874-417d-82a7-321ad3ec2e43@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
 <bIQa4lpaiAp04nVn-3k3ebfDAh6vdfenL6NAb8mxxjM=.84ab3ec0-8830-4616-9d09-345735e97ffd@github.com>
 <C2m9eDljR4DDIJWSNIOCYvWLXrowIRbD_9AEqUx3SLQ=.ae3d3778-b874-417d-82a7-321ad3ec2e43@github.com>
Message-ID: <W0mtftBpsqVCQiDXo3sCbt--_YmNeRvngtGMrYYw99Y=.67419d79-c8fd-4882-a6d4-dabbf434ee5a@github.com>

On Mon, 6 Oct 2025 17:56:59 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/Cipher.java line 329:
>> 
>>> 327:                     SHA512TRUNCATED.length());
>>> 328:             sha512SlashIdx = (sha512Idx != -1 ? sha512Idx + 3 : -2);
>>> 329:         }
>> 
>> The logic is quite complex. Can you create a dedicated method for it like `indexOfRealSlashIn(String s)`?
>> 
>> We can even call it on the mode part.
>
> There are quite a few values being updated here, that's why I didn't make it into a method initially. Let me think about it more...

Both `sha512Idx` and `sha512SlashIdx` locally assigned, `SHA512TRUNCATED` is a constant, `transformation` is not mutated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27615#discussion_r2408217227

From mullan at openjdk.org  Mon Oct  6 20:03:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Oct 2025 20:03:06 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
Message-ID: <7jhZVUSB2yFkXloSftuRXHZRFXkqoR4Ggj6BpotEphk=.23631446-ee02-4704-9827-97b8c7716b50@github.com>

On Thu, 2 Oct 2025 18:49:53 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more review comments from Weijun and Sean

src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 75:

> 73: 
> 74:     // the key derivation function (default is HmacSHA1)
> 75:     private final ObjectIdentifier kdfAlgo_OID =

This can just be a local variable in `getEncoded`.

src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 81:

> 79:     private int keyLength = -1;
> 80: 
> 81:     protected void Init(AlgorithmParameterSpec paramSpec)

You don't need this method/ctor anymore, only the one that takes a `byte[]`.

src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 97:

> 95:                     + "not an ASN.1 SEQUENCE tag");
> 96:         }
> 97:         DerValue[] Info = (new DerInputStream(pBMAC1_params.toByteArray()))

No need for parens around `new DerInputStream`.

Also, s/Info/info/

src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 138:

> 136:     }
> 137: 
> 138:     protected byte[] getEncoded() throws IOException {

The methods don't need to be `protected`. Make them package-private after you move the class to `sun.security.pkcs12`.

src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 172:

> 170:     protected byte[] getEncoded(String encodingMethod) throws IOException {
> 171:         return getEncoded();
> 172:     }

This method doesn't seem useful or needed.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 179:

> 177:     }
> 178: 
> 179:     static Mac getMac(String macAlgorithm, char[] password,

This method can be private.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 204:

> 202:         try {
> 203:             if (macAlgorithm.startsWith("PBEWith")) {
> 204:                  m.init(pbeKey);

should be 4 spaces indent instead of 5 spaces, also on line 206.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 244:

> 242:      * create a message authentication code (MAC)
> 243:      */
> 244:     public static byte[] calculateMac(char[] passwd, byte[] data,

Method should be package-private.

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 84:

> 82: 
> 83:     // the pseudorandom function (default is HmacSHA1)
> 84:     private ObjectIdentifier kdfAlgo_OID =

I agree with Valerie that it looks like it can be a local variable inside the constructor on line 125.

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 89:

> 87:     private String prfAlgo = "HmacSHA1";
> 88: 
> 89:     public PBKDF2Parameters(DerValue keyDerivationFunc) throws IOException {

Add some comments describing this ctor and its parameter.

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 148:

> 146:      *
> 147:      * @return the salt. Returns a new array
> 148:      * each time this method is called.

Does not return a new array each time called so remove this comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408034141
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408043209
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408046719
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408070382
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408067504
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408174703
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408165609
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408206621
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2407354430
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2407440344
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2407364493

From mullan at openjdk.org  Mon Oct  6 20:03:09 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Oct 2025 20:03:09 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
Message-ID: <2q8dF1UaPHP7Y2i7PCMIlTEPTXViDmTrBlzAj3O_I6U=.3aa148e5-b57e-46c0-8bb6-315fa813c774@github.com>

On Mon, 29 Sep 2025 20:53:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another day another iteration
>
> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 322:
> 
>> 320:      * ASN.1 encoding.
>> 321:      */
>> 322:     public byte[] getEncoded() throws NoSuchAlgorithmException, IOException {
> 
> Since you have moved the decoding of PBKDF2-Params into its own class, are you going to move the encoding there as well? Ideally, a `PBKDF2Parameters` object can be either created using a `DerValue` or its components (salt, ic, keyLen), and then it has a `getEncoded()` method.
> 
> Same with the new `PBMAC1Parameters` class.

Yes, I have the same comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408245973

From mullan at openjdk.org  Mon Oct  6 20:03:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Oct 2025 20:03:11 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <7jhZVUSB2yFkXloSftuRXHZRFXkqoR4Ggj6BpotEphk=.23631446-ee02-4704-9827-97b8c7716b50@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
 <7jhZVUSB2yFkXloSftuRXHZRFXkqoR4Ggj6BpotEphk=.23631446-ee02-4704-9827-97b8c7716b50@github.com>
Message-ID: <87jVH7gFhQn8zKCm7dca1PVnqda4LM9GX-lx6EXgJs4=.aa54cf92-2192-43d5-b8d4-f4b9600e3393@github.com>

On Mon, 6 Oct 2025 16:53:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more review comments from Weijun and Sean
>
> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 89:
> 
>> 87:     private String prfAlgo = "HmacSHA1";
>> 88: 
>> 89:     public PBKDF2Parameters(DerValue keyDerivationFunc) throws IOException {
> 
> Add some comments describing this ctor and its parameter.

It's also a little unusual you are passing in the KDF algorithmId and not its parameters here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2408020713

From egahlin at openjdk.org  Mon Oct  6 22:38:45 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 6 Oct 2025 22:38:45 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
References: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
Message-ID: <EhFGA0j5SHyFwd9hWWM01rq95cjr-X3dqFNoyMStDRM=.5c37ecc6-c120-4096-bddc-79db7c4ed158@github.com>

On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable <duke at openjdk.org> wrote:

> while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint.
> 
> therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined.
> 
> this association can be used for various "applications" such as basic auditing etc

I have not reviewed SecureClassLoader, as this is better done by people who are more knowledgeable in the area. That said, toExternalForm() appears to be a somewhat expensive function, so you may want to add a guard. Also check for null.

        ClassFileDefineEvent event = new ClassFileDefineEvent();
        if (event.isEnabled()) {
            event.definedClass = cls;
            if (cs != null) {
                URL location = cs.getLocation();
                if (location != null) {
                    event.path = location.toExternalForm();
                }
            }
            event.commit();   
        }
        
Could you also add the event to profile.jfc? Please remove "Name" from the label "Defined Class Name," as the whole class is serialized, and add a test to test/jdk/jdk/jfr/event/runtime.

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

PR Comment: https://git.openjdk.org/jdk/pull/27656#issuecomment-3374488908

From duke at openjdk.org  Mon Oct  6 22:42:45 2025
From: duke at openjdk.org (Larry Cable)
Date: Mon, 6 Oct 2025 22:42:45 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
References: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
Message-ID: <LsLd_gjUL544EEo5kbjpTU2XWzty_a8FUXpT24Fs7DY=.2c8fe126-4ca6-4a43-886f-c2c0d33a2ae7@github.com>

On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable <duke at openjdk.org> wrote:

> while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint.
> 
> therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined.
> 
> this association can be used for various "applications" such as basic auditing etc

sounds good, will do so!

thx


On 10/6/25 3:33 PM, Erik Gahlin wrote:
> *egahlin* left a comment (openjdk/jdk#27656) 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27656*issuecomment-3374488908__;Iw!!ACWV5N9M2RV99hQ!LsYP65VL4wbG0567H5u0fobZGwD-AhgqyFUXDwC7LTnVDAop8HdvYCAzZLBn4QogqPSZA-LReG2opO6WMvYfxMeLZw$>
>
> I have not reviewed SecureClassLoader, as this is better done by 
> people who are more knowledgeable in the area. That said, 
> toExternalForm() appears to be a somewhat expensive function, so you 
> may want to add a guard. Also check for null.
>
> |ClassFileDefineEvent evt = new ClassFileDefineEvent(); if 
> (event.shouldCommit()) { event.definedClass = cls; if (cs != null) { 
> URL location = cs.getLocation(); if (location != null) { event = 
> location.toExternalForm(); } } event.commit(); } |
>
> Could you also add the event to profile.jfc? Please remove "Name" from 
> the label "Defined Class Name," as the whole class is serialized, and 
> add a test to test/jdk/jdk/jfr/event/runtime.
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27656*issuecomment-3374488908__;Iw!!ACWV5N9M2RV99hQ!LsYP65VL4wbG0567H5u0fobZGwD-AhgqyFUXDwC7LTnVDAop8HdvYCAzZLBn4QogqPSZA-LReG2opO6WMvYfxMeLZw$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67UO5YZDJZINJIH73T33WLU5PAVCNFSM6AAAAACIN4BNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZUGQ4DQOJQHA__;!!ACWV5N9M2RV99hQ!LsYP65VL4wbG0567H5u0fobZGwD-AhgqyFUXDwC7LTnVDAop8HdvYCAzZLBn4QogqPSZA-LReG2opO6WMvY6rHOFuw$>.
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--------------H8Nh870r73JozTO7kRSnjvm6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    sounds good, will do so!<br>
    <br>
    thx<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 10/6/25 3:33 PM, Erik Gahlin wrote:<br>
    </div>
    <blockquote type="cite" ***@***.***">
      
      <div style="display: flex; flex-wrap: wrap; white-space: pre-wrap; align-items: center; "><img height="20" width="20" style="border-radius:50%; margin-right: 4px;" decoding="async" src="https://avatars.githubusercontent.com/u/43493071?s=20&amp;v=4" moz-do-not-send="true"><strong>egahlin</strong> left a comment <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27656*issuecomment-3374488908__;Iw!!ACWV5N9M2RV99hQ!LsYP65VL4wbG0567H5u0fobZGwD-AhgqyFUXDwC7LTnVDAop8HdvYCAzZLBn4QogqPSZA-LReG2opO6WMvYfxMeLZw$" moz-do-not-send="true">(openjdk/jdk#27656)</a></div>
      <p dir="auto">I have not reviewed SecureClassLoader, as this is
        better done by people who are more knowledgeable in the area.
        That said, toExternalForm() appears to be a somewhat expensive
        function, so you may want to add a guard. Also check for null.</p>
      <pre class="notranslate"><code class="notranslate">    ClassFileDefineEvent evt = new ClassFileDefineEvent();
    if (event.shouldCommit()) {
        event.definedClass = cls;
        if (cs != null) {
            URL location = cs.getLocation();
            if (location != null) {
                event = location.toExternalForm();
            }
        }
        event.commit();   
    }
</code></pre>
      <p dir="auto">Could you also add the event to profile.jfc? Please
        remove &quot;Name&quot; from the label &quot;Defined Class Name,&quot; as the whole
        class is serialized, and add a test to
        test/jdk/jdk/jfr/event/runtime.</p>
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">?<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27656*issuecomment-3374488908__;Iw!!ACWV5N9M2RV99hQ!LsYP65VL4wbG0567H5u0fobZGwD-AhgqyFUXDwC7LTnVDAop8HdvYCAzZLBn4QogqPSZA-LReG2opO6WMvYfxMeLZw$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67UO5YZDJZINJIH73T33WLU5PAVCNFSM6AAAAACIN4BNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZUGQ4DQOJQHA__;!!ACWV5N9M2RV99hQ!LsYP65VL4wbG0567H5u0fobZGwD-AhgqyFUXDwC7LTnVDAop8HdvYCAzZLBn4QogqPSZA-LReG2opO6WMvY6rHOFuw$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67R5OH4OJJA2F6QE6NL3WLU5PA5CNFSM6AAAAACIN4BNMWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTWJEKOUY.gif" height="1" width="1" alt="" moz-do-not-send="true"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span>&lt;openjdk/jdk/pull/27656/c3374488908</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p>
      <script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/27656#issuecomment-3374488908",
"url": "https://github.com/openjdk/jdk/pull/27656#issuecomment-3374488908",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>

--------------H8Nh870r73JozTO7kRSnjvm6--

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

PR Comment: https://git.openjdk.org/jdk/pull/27656#issuecomment-3374507982

From egahlin at openjdk.org  Mon Oct  6 22:50:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 6 Oct 2025 22:50:44 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
References: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
Message-ID: <dEMZy0agPn1d1DERiPHthMx-8le4SCFx5KZGpNF3Ob4=.4cb29edd-1c2a-44ba-8c95-aefd2b9f9b48@github.com>

On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable <duke at openjdk.org> wrote:

> while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint.
> 
> therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined.
> 
> this association can be used for various "applications" such as basic auditing etc

What is the scope of the event? I assume it will not work for all classes. Could more be added, or could the limitation be stated somewhere, e.g. Label("Secure Class File Define")? The event name can still be generic.

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

PR Comment: https://git.openjdk.org/jdk/pull/27656#issuecomment-3374538971

From valeriep at openjdk.org  Tue Oct  7 00:01:01 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 7 Oct 2025 00:01:01 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE [v2]
In-Reply-To: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
Message-ID: <r2Pg8nqGpv8ESJJzxkz0I-Omn-h8uLVuBJRloq4Kuhg=.6e033204-af77-4b49-a3f7-aa6d6503efbd@github.com>

> This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 
> 
> Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 
> 
> Thanks in advance for the review~

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

  refactored using record to keep track of indices

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27615/files
  - new: https://git.openjdk.org/jdk/pull/27615/files/65c4ca6f..5b29656b

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

  Stats: 96 lines in 1 file changed: 43 ins; 44 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27615/head:pull/27615

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

From valeriep at openjdk.org  Tue Oct  7 01:05:50 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 7 Oct 2025 01:05:50 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE [v2]
In-Reply-To: <W0mtftBpsqVCQiDXo3sCbt--_YmNeRvngtGMrYYw99Y=.67419d79-c8fd-4882-a6d4-dabbf434ee5a@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
 <bIQa4lpaiAp04nVn-3k3ebfDAh6vdfenL6NAb8mxxjM=.84ab3ec0-8830-4616-9d09-345735e97ffd@github.com>
 <C2m9eDljR4DDIJWSNIOCYvWLXrowIRbD_9AEqUx3SLQ=.ae3d3778-b874-417d-82a7-321ad3ec2e43@github.com>
 <W0mtftBpsqVCQiDXo3sCbt--_YmNeRvngtGMrYYw99Y=.67419d79-c8fd-4882-a6d4-dabbf434ee5a@github.com>
Message-ID: <2JlbNHFl77WgWXLV5-Yf2M_xwRqYbtmWMmLXbaXPgIE=.41a6ceea-81f7-43d9-9929-8f8f155dbc7a@github.com>

On Mon, 6 Oct 2025 19:48:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There are quite a few values being updated here, that's why I didn't make it into a method initially. Let me think about it more...
>
> Both `sha512Idx` and `sha512SlashIdx` locally assigned, `SHA512TRUNCATED` is a constant, `transformation` is not mutated.

I did refactoring it using a record. If we apply the same method on mode as well, then the flow is simplified even though the mode should not contain truncated algorithms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27615#discussion_r2409062884

From mpowers at openjdk.org  Tue Oct  7 02:13:57 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Oct 2025 02:13:57 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <7jhZVUSB2yFkXloSftuRXHZRFXkqoR4Ggj6BpotEphk=.23631446-ee02-4704-9827-97b8c7716b50@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
 <7jhZVUSB2yFkXloSftuRXHZRFXkqoR4Ggj6BpotEphk=.23631446-ee02-4704-9827-97b8c7716b50@github.com>
Message-ID: <URy5XRjbdOwk0-ruSNEeo3UQ7_Z6CRL9xXU-qE9hT3c=.3d25a296-5b05-4245-934a-0ff1b653f23c@github.com>

On Mon, 6 Oct 2025 19:04:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more review comments from Weijun and Sean
>
> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 75:
> 
>> 73: 
>> 74:     // the key derivation function (default is HmacSHA1)
>> 75:     private final ObjectIdentifier kdfAlgo_OID =
> 
> This can just be a local variable in `getEncoded`.

fixed

> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 81:
> 
>> 79:     private int keyLength = -1;
>> 80: 
>> 81:     protected void Init(AlgorithmParameterSpec paramSpec)
> 
> You don't need this method/ctor. You should add one that takes the different components as objects and then generates the bytes. Move the code that is currently doing this out of `MacData`.

It's long gone.

> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 97:
> 
>> 95:                     + "not an ASN.1 SEQUENCE tag");
>> 96:         }
>> 97:         DerValue[] Info = (new DerInputStream(pBMAC1_params.toByteArray()))
> 
> No need for parens around `new DerInputStream`.
> 
> Also, s/Info/info/

fixed

> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 138:
> 
>> 136:     }
>> 137: 
>> 138:     protected byte[] getEncoded() throws IOException {
> 
> The methods don't need to be `protected`. Make them package-private after you move the class to `sun.security.pkcs12`.

fixed

> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 172:
> 
>> 170:     protected byte[] getEncoded(String encodingMethod) throws IOException {
>> 171:         return getEncoded();
>> 172:     }
> 
> This method doesn't seem useful or needed.

gone

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 179:
> 
>> 177:     }
>> 178: 
>> 179:     static Mac getMac(String macAlgorithm, char[] password,
> 
> This method can be private.

done

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 204:
> 
>> 202:         try {
>> 203:             if (macAlgorithm.startsWith("PBEWith")) {
>> 204:                  m.init(pbeKey);
> 
> should be 4 spaces indent instead of 5 spaces, also on line 206.

Fixed. You must have special eyes to catch this.

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 244:
> 
>> 242:      * create a message authentication code (MAC)
>> 243:      */
>> 244:     public static byte[] calculateMac(char[] passwd, byte[] data,
> 
> Method should be package-private.

fixed

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 84:
> 
>> 82: 
>> 83:     // the pseudorandom function (default is HmacSHA1)
>> 84:     private ObjectIdentifier kdfAlgo_OID =
> 
> I agree with Valerie that it looks like it can be a local variable inside the constructor on line 125.

fixed

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 148:
> 
>> 146:      *
>> 147:      * @return the salt. Returns a new array
>> 148:      * each time this method is called.
> 
> Does not return a new array each time called so remove this comment.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409138459
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409138117
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409137896
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409137013
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409137544
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409136445
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409136625
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409135754
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409138788
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409138659

From mpowers at openjdk.org  Tue Oct  7 02:14:00 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Oct 2025 02:14:00 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <pd01OhObrnNjOWygWVqbdPypXS_-sDhZKS92HhOVIYU=.e52f0d90-be8a-4882-858c-bc2b9acd8e88@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
 <QEn79dm-lDcfTWZcY_mE3SwMyJMmeVEH1IydafcebwM=.cfe68998-b6e4-4e57-a2d8-ff598e8829ba@github.com>
 <pd01OhObrnNjOWygWVqbdPypXS_-sDhZKS92HhOVIYU=.e52f0d90-be8a-4882-858c-bc2b9acd8e88@github.com>
Message-ID: <7FfOsTzz_fRaj4ppP1G8Y3trBXPWam5g36mBiWuzX2c=.4fcba3ff-5a9e-4b69-a01c-30a4ee802b7a@github.com>

On Sat, 4 Oct 2025 18:51:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 209:
>> 
>>> 207:             }
>>> 208:         } finally {
>>> 209:             destroyPBEKey(pbeKey);
>> 
>> The `PBEKeySpec` object created in both cases should also be cleaned up by calling `keySpec.clearPassword()`.
>
> The password in `PBKDF2KeyImpl` is not cleaned. It does have a `clear` method but no `destroy`. Consider adding a `destroy` to it.

Both are now fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2409138925

From alanb at openjdk.org  Tue Oct  7 05:31:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 7 Oct 2025 05:31:47 GMT
Subject: RFR: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <LsLd_gjUL544EEo5kbjpTU2XWzty_a8FUXpT24Fs7DY=.2c8fe126-4ca6-4a43-886f-c2c0d33a2ae7@github.com>
References: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
 <LsLd_gjUL544EEo5kbjpTU2XWzty_a8FUXpT24Fs7DY=.2c8fe126-4ca6-4a43-886f-c2c0d33a2ae7@github.com>
Message-ID: <cLs6XDeVYOdylvZpklRFQVW4sR0iZ72IgsWocWvjqs0=.994b1e63-b426-4543-9bde-83b27f76da15@github.com>

On Mon, 6 Oct 2025 22:40:22 GMT, Larry Cable <duke at openjdk.org> wrote:

>> while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint.
>> 
>> therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined.
>> 
>> this association can be used for various "applications" such as basic auditing etc
>
> sounds good, will do so!
> 
> thx
> 
> 
> On 10/6/25 3:33 PM, Erik Gahlin wrote:
>> *egahlin* left a comment (openjdk/jdk#27656) 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27656*issuecomment-3374488908__;Iw!!ACWV5N9M2RV99hQ!LsYP65VL4wbG0567H5u0fobZGwD-AhgqyFUXDwC7LTnVDAop8HdvYCAzZLBn4QogqPSZA-LReG2opO6WMvYfxMeLZw$>
>>
>> I have not reviewed SecureClassLoader, as this is better done by 
>> people who are more knowledgeable in the area. That said, 
>> toExternalForm() appears to be a somewhat expensive function, so you 
>> may want to add a guard. Also check for null.
>>
>> |ClassFileDefineEvent evt = new ClassFileDefineEvent(); if 
>> (event.shouldCommit()) { event.definedClass = cls; if (cs != null) { 
>> URL location = cs.getLocation(); if (location != null) { event = 
>> location.toExternalForm(); } } event.commit(); } |
>>
>> Could you also add the event to profile.jfc? Please remove "Name" from 
>> the label "Defined Class Name," as the whole class is serialized, and 
>> add a test to test/jdk/jdk/jfr/event/runtime.
>>
>> ?
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27656*issuecomment-3374488908__;Iw!!ACWV5N9M2RV99hQ!LsYP65VL4wbG0567H5u0fobZGwD-AhgqyFUXDwC7LTnVDAop8HdvYCAzZLBn4QogqPSZA-LReG2opO6WMvYfxMeLZw$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67UO5YZDJZINJIH73T33WLU5PAVCNFSM6AAAAACIN4BNMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZUGQ4DQOJQHA__;!!ACWV5N9M2RV99hQ!LsYP65VL4wbG0567H5u0fobZGwD-AhgqyFUXDwC7LTnVDAop8HdvYCAzZLBn4QogqPSZA-LReG2opO6WMvY6rHOFuw$>.
>> You are receiving this because you were mentioned.Message ID: 
>> ***@***.***>
>>
> 
> --------------H8Nh870r73JozTO7kRSnjvm6
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> <!DOCTYPE html><html><head>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
>   </head>
>   <body>
>     sounds good, will do so!<br>
>     <br>
>     thx<br>
>     <br>
>     <br>
>     <div class="moz-cite-prefix">On 10/6/25 3:33 PM, Erik Gahlin wrote:<br>
>     </div>
>     <blockquote type="cite" ***@***.***">
>       
>       <div style="display: flex; flex-wrap: wrap; white-space: pre-wrap; align-items: center; "><img height="20" width="20" style="border-radius:50%; margin-right: 4px;" decoding="async" src="https://avatars.githubusercontent.com/u/43493071?s=20&amp;v=4" moz-do-not-send="true"><strong>egahlin</strong> left a comment <a href="https://urldefense.com/v3/__h...

@larry-cable would it be possible to provide a summary on why the existing ClassLoad/ClassDefine events can't be updated to  add the additional fields? 

I think it would also be useful to understand why SecureClassLoader has been chosen as the place to record this event. The class loading part of the boot loader is in the VM, not Java. The modified code paths will get used for the platform and app class loaders but it's coin toss with custom class loaders as they might extend ClassLoader directly.

Have you looked at the defineClass implementation in the base class (java.lang.ClassLoader)? It already extracts the location from the protection domain so that the VM has the code source. For classes loaded by the boot loader, the VM will generate a code source that is the string representation of a "jrt" or "file" URL.  That code source is mostly used by logging (e.g. -Xlog:class+load) and CDS/AOT but I suspect what you are looking for it to get at these in the VM when recording an event.

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

PR Comment: https://git.openjdk.org/jdk/pull/27656#issuecomment-3375263156

From duke at openjdk.org  Tue Oct  7 08:49:58 2025
From: duke at openjdk.org (Larry Cable)
Date: Tue, 7 Oct 2025 08:49:58 GMT
Subject: Withdrawn: 8365400: enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
References: <VvfTT-fkIlz1GvF0orh1FhptI-RFJXVprB53IjtsMQs=.8f82cce5-3a80-4a87-a069-ec9909d88818@github.com>
Message-ID: <S6_4SPhWph6w5KfLkWdkslFu3SG_G7QKnnRRcrDe5J4=.0e373b06-820c-45e4-939f-4ce8cd1859d4@github.com>

On Mon, 6 Oct 2025 18:15:51 GMT, Larry Cable <duke at openjdk.org> wrote:

> while existing class loading JFR events exist, none of these provide the path (if available) from which a class is loaded/defined, nor are they easily modified to do so from a compatibility standpoint.
> 
> therefore this ER/PR adds a simple JFR event that encapsulates a tuple of class and path that can be enabled in order to provide an audit/debug trail of locations (path, if available) from which a particular class is loaded/defined.
> 
> this association can be used for various "applications" such as basic auditing etc

This pull request has been closed without being integrated.

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

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

From mullan at openjdk.org  Tue Oct  7 13:22:37 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 7 Oct 2025 13:22:37 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v12]
In-Reply-To: <b1PT909B5J0Hl4Gplp8y42CiNVEjt2Oc8MK8F_DRTWY=.7b6d883d-2318-4a28-85c7-7483ede93e8b@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
 <b1PT909B5J0Hl4Gplp8y42CiNVEjt2Oc8MK8F_DRTWY=.7b6d883d-2318-4a28-85c7-7483ede93e8b@github.com>
Message-ID: <xymmCHquz50KFh9YIuAsbWo2V0KrxV8JBUzG2MulUY8=.2c7293ea-16ea-4705-9c37-878bcfe01ed9@github.com>

On Mon, 6 Oct 2025 15:31:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Allow password hiding even if there is no `System.console`. A manual test is included.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more null check; one less empty check

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3310089768

From abarashev at openjdk.org  Tue Oct  7 15:58:33 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 7 Oct 2025 15:58:33 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure
Message-ID: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>

If the NewSessionTicket message is lost, the handshake fails on the client side with:
javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.

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

Commit messages:
 - 8367059: DTLS: loss of NewSessionTicket message results in handshake failure

Changes: https://git.openjdk.org/jdk/pull/27677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27677&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367059
  Stats: 52 lines in 4 files changed: 40 ins; 7 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27677/head:pull/27677

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

From valeriep at openjdk.org  Tue Oct  7 17:45:54 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 7 Oct 2025 17:45:54 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE [v3]
In-Reply-To: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
Message-ID: <Vf0dKCX7aQ6DBeFw0xuBztbSvDJThfslZBAbKcSt7P4=.2a47e141-15ed-4927-a30d-d900bcfc9a53@github.com>

> This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 
> 
> Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 
> 
> Thanks in advance for the review~

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

  Updated based on Weijun's suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27615/files
  - new: https://git.openjdk.org/jdk/pull/27615/files/5b29656b..6fa2a15f

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

  Stats: 61 lines in 1 file changed: 9 ins; 15 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/27615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27615/head:pull/27615

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

From weijun at openjdk.org  Tue Oct  7 18:40:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 7 Oct 2025 18:40:12 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE [v3]
In-Reply-To: <Vf0dKCX7aQ6DBeFw0xuBztbSvDJThfslZBAbKcSt7P4=.2a47e141-15ed-4927-a30d-d900bcfc9a53@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
 <Vf0dKCX7aQ6DBeFw0xuBztbSvDJThfslZBAbKcSt7P4=.2a47e141-15ed-4927-a30d-d900bcfc9a53@github.com>
Message-ID: <12RQwa2uyoY3wTfLHAiFGxy7IPgAcSLZ_iYPi-jdu_A=.c048b2a5-75e6-40b9-a075-70e0a45a3f93@github.com>

On Tue, 7 Oct 2025 17:45:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 
>> 
>> Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on Weijun's suggestion.

src/java.base/share/classes/javax/crypto/Cipher.java line 290:

> 288: 
> 289:     // for special handling SHA-512/224, SHA-512/256, SHA512/224, SHA512/256
> 290:     private static final String SHA512TRUNCATED = "512/2";

Is this constant still used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27615#discussion_r2411552299

From acobbs at openjdk.org  Tue Oct  7 19:40:35 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 7 Oct 2025 19:40:35 GMT
Subject: RFR: 5038439: Warning message for literal shift amounts outside the
 canonical domain
Message-ID: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>

When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored.

This can create a trap for the unwary, as in this example:

public long readLongBigEndian(byte[] buf, int offset) {
    return ((buf[offset + 0] & 0xff) << 56)   // BUG HERE
         | ((buf[offset + 1] & 0xff) << 48)   // BUG HERE
         | ((buf[offset + 2] & 0xff) << 40)   // BUG HERE
         | ((buf[offset + 3] & 0xff) << 32)   // BUG HERE
         | ((buf[offset + 4] & 0xff) << 24)
         | ((buf[offset + 5] & 0xff) << 16)
         | ((buf[offset + 6] & 0xff) << 8)
         | ((buf[offset + 7] & 0xff);
}

This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`.

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

Commit messages:
 - Merge branch 'master' into JDK-5038439 to fix conflict.
 - Add "long" as a supported message parameter type.
 - Use "bit(s)" instead of "bits" where value could be 1.
 - Merge branch 'master' into JDK-5038439
 - Sprinkle more variety into the regression test.
 - Minor diff cleanup.
 - Update "lossy-conversions" description in compiler module Javadoc.
 - Warn for bit shifts using an out-of-range shift amount.

Changes: https://git.openjdk.org/jdk/pull/27102/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-5038439
  Stats: 194 lines in 14 files changed: 184 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27102.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27102/head:pull/27102

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

From mpowers at openjdk.org  Tue Oct  7 20:40:42 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Oct 2025 20:40:42 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <_L0hfQJzB28Qo1DzrRwvrrhWk0iSyHF1HC3qcsT1F9A=.c734d050-5626-4654-a1b8-a000f0a9208b@github.com>
Message-ID: <Fw5kV6TPUXNeOGjxVS3-iSIMyXh0xx_UfBGd9muM7BM=.1195c907-6e87-4f55-b7c6-5b2b23c13f78@github.com>

On Mon, 29 Sep 2025 20:57:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another day another iteration
>
> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 84:
> 
>> 82:     private int keyLength = -1;
>> 83: 
>> 84:     protected void Init(AlgorithmParameterSpec paramSpec)
> 
> Method names should start with a lowercase letter. If it's not used, remove it.
> 
> That said, in a different comment, I was hoping we can also construct a `PBMAC1Parameters` object using its components.

Not in this initial integration.

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 234:
> 
>> 232:         String Hmac = null;
>> 233: 
>> 234:         if (newKeystore) {
> 
> What could happen if `newKeystore` is different? Is the only difference about the `And` in `macAlgorithm`? Can we just treat it in a consistent way no matter if a new keystore is created?

Fixed. `newKeystore` has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2411828976
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2411830126

From weijun at openjdk.org  Tue Oct  7 20:40:41 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 7 Oct 2025 20:40:41 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v2]
In-Reply-To: <2eDcr2BqION52VUhVBxpHNnHgJ7H-yODIbhrLkEqPUk=.912193fb-824a-4fdd-bbe9-93cd761dc9e0@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
 <2eDcr2BqION52VUhVBxpHNnHgJ7H-yODIbhrLkEqPUk=.912193fb-824a-4fdd-bbe9-93cd761dc9e0@github.com>
Message-ID: <aSCoxYZHhVZ0vTRwC1gIGSbvKpvdbJnz__eZtOWpBLQ=.eef3a7e4-e587-47a5-bf66-990502a3bde5@github.com>

On Sun, 5 Oct 2025 12:22:28 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 653:
>> 
>>> 651:         NAMED_GROUP_XDH("XDH", XDHScheme.instance),
>>> 652: 
>>> 653:         NAMED_GROUP_KEM("PQC", KEMScheme.instance),
>> 
>> That Choice of Name needs probably an explaining comment if it is for pure PQC and/ormhybrid?
>
> Comment added.

Maybe we can rename "PQC" to "KEM" to be consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2411793311

From mpowers at openjdk.org  Tue Oct  7 20:40:46 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Oct 2025 20:40:46 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v3]
In-Reply-To: <O6646LU9zRGOtRc8aAEATTk3EpmTdpeKAHjy_dQ1doI=.ab2e2e28-487f-4084-b535-e73ebd7bec33@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <oG840hSliwqHawwcaNtpXRp9cpGQWHb-X-4C3ZBNIyw=.280a7d48-4787-434a-9bf5-b85ddde150e5@github.com>
 <O6646LU9zRGOtRc8aAEATTk3EpmTdpeKAHjy_dQ1doI=.ab2e2e28-487f-4084-b535-e73ebd7bec33@github.com>
Message-ID: <08SntfYhxrQjaVkIX90vYAp_0ZPHjdR9xPftipFYMK8=.8a19239a-3a0a-4260-8f4c-3c567ee1cf70@github.com>

On Wed, 17 Sep 2025 21:32:20 GMT, Thomas Fitzsimmons <fitzsim at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   a few more comments
>
> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 173:
> 
>> 171:         if (keyLength > 0) {
>> 172:             pBKDF2_params.putInteger(keyLength / 8); // derived key length (in octets)
>> 173:         }
> 
> I think `keyLength` is a MUST here.  Maybe this should instead check if `keyLength` is `<= 0`, and if so, throw an exception.  Then proceed to encode `keyLength` unconditionally.

After innumerable iterations, this encoding method will be removed from `PBMAC1Parameters`.
That said, keyLength now comes from the Mac before being encoded in `MacData`:


Mac m = Mac.getInstance(hmac);
int keyLength = m.getMacLength()*8;

If this doesn't work, we have some other serious issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2411832590

From mpowers at openjdk.org  Tue Oct  7 20:40:48 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Oct 2025 20:40:48 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <WqdPwOcdvYdYV2uZYX7WKjPY9uJWH-vkW_1XulHqzig=.cacf4ead-af35-41f1-989b-5c4d3180fb14@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <Zq5sy9fZI8zcBodpiaH_o9vyYRl_T1JMqJY-ix7p964=.456e196b-0f49-4e03-9881-226f069d37fa@github.com>
 <65rndgokdUz7OZKSVapsWnHN8XbKfw95N0tw0V438FU=.7b8bc21a-eedc-422c-82e2-353f3d6d35bc@github.com>
 <WqdPwOcdvYdYV2uZYX7WKjPY9uJWH-vkW_1XulHqzig=.cacf4ead-af35-41f1-989b-5c4d3180fb14@github.com>
Message-ID: <uhEEwvX5VURSi4BroKWuoNoMSslfz2GbV0fdjUhXTN0=.159c5182-07ab-4a7a-b63a-0757884f486f@github.com>

On Wed, 17 Sep 2025 14:55:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Not yet. I'm looking at Sean's comments today.
>
> And this duplicates `MacData.getEncoded()`.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2411835460

From mpowers at openjdk.org  Tue Oct  7 20:40:50 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Oct 2025 20:40:50 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <2h4ufobcAqNL2aXFVGTjiMWHB02tt_ZHuIdIspwWosk=.31fdff09-6a7a-4959-8c70-609368ff0b42@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
 <2h4ufobcAqNL2aXFVGTjiMWHB02tt_ZHuIdIspwWosk=.31fdff09-6a7a-4959-8c70-609368ff0b42@github.com>
Message-ID: <Jdjc2nQeAFQyV69WxpB_4mlAAhsLu-IWrEBEeonlbNE=.7242ae98-bf3a-4c2f-9373-f7d6af65e5ba@github.com>

On Sat, 4 Oct 2025 21:22:10 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 186:
>> 
>>> 184:             kdfHmac = macAlgorithm;
>>> 185:             Hmac = macAlgorithm;
>>> 186:         }
>> 
>> Did you consider adding another kdfHmac parameter to the method and passing in the correct values?
>
> This comment appears to apply to an earlier iteration. It is not easy to keep track of all these iterations. I believe the latest iteration fixes this.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2411823179

From mpowers at openjdk.org  Tue Oct  7 20:40:53 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Oct 2025 20:40:53 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <7FfOsTzz_fRaj4ppP1G8Y3trBXPWam5g36mBiWuzX2c=.4fcba3ff-5a9e-4b69-a01c-30a4ee802b7a@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
 <QEn79dm-lDcfTWZcY_mE3SwMyJMmeVEH1IydafcebwM=.cfe68998-b6e4-4e57-a2d8-ff598e8829ba@github.com>
 <pd01OhObrnNjOWygWVqbdPypXS_-sDhZKS92HhOVIYU=.e52f0d90-be8a-4882-858c-bc2b9acd8e88@github.com>
 <7FfOsTzz_fRaj4ppP1G8Y3trBXPWam5g36mBiWuzX2c=.4fcba3ff-5a9e-4b69-a01c-30a4ee802b7a@github.com>
Message-ID: <oLEtkFjwUuTFYpHaDQraEUU3BKerLb01HGT4WEjFalM=.21a45c1b-8886-46dc-901e-c902349c02f4@github.com>

On Tue, 7 Oct 2025 02:11:12 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> The password in `PBKDF2KeyImpl` is not cleaned. It does have a `clear` method but no `destroy`. Consider adding a `destroy` to it.
>
> Both are now fixed.

I believe this is fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2411822310

From mpowers at openjdk.org  Tue Oct  7 20:40:56 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Oct 2025 20:40:56 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v8]
In-Reply-To: <6msqSRuJOehVa1Ib63ms-lcQukjVNt6Ctz1mqeYxV9g=.83b7dd10-c1e0-4062-a8a8-0ac989b60a7d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <-XmyyXayIpWRuXvXrX-rshiHJq8h53O5c71OR45cWyg=.9e95899d-28b4-48c1-ae82-7c7bb1f2067d@github.com>
 <J9-C1W_rhT6CsDyz9xPwjyR37VigoaU9AsfmHsl3Yd8=.6e511058-0ad9-480a-bbcb-2a6717df065c@github.com>
 <Q4Clpd6s9DOf7HPtP5aXFh8-UyWKBg1P3N5fTzI1J6o=.cee8b54f-95ac-4fea-add9-98019b173b06@github.com>
 <4Ws4EnpXUanfhcF5Mvh0No4Vi7g6hEwBDN1Mkn6moFI=.248ecf09-a866-4c8f-b7ba-278d3376cf2e@github.com>
 <3-4I8Ao43vrp0yAxzpHD0AU14ON4oza9h8KPrV_Hcpo=.451a4dac-d9bc-4ab3-a308-f83c2f6e2c99@github.com>
 <6msqSRuJOehVa1Ib63ms-lcQukjVNt6Ctz1mqeYxV9g=.83b7dd10-c1e0-4062-a8a8-0ac989b60a7d@github.com>
Message-ID: <5XZ-MB3gOl0dzPrqYxvUHuABus9BN80wGyujashYBas=.b37f4aeb-e503-43f6-a7db-7780a98aefec@github.com>

On Wed, 24 Sep 2025 16:47:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> There is no difference whether `newKeystore` is true or false. Yes, I can see `writeIterationCount` has already been set to `defaultMacIterationCount()` before, but then there is no need to set it to the same value again here.
>> 
>> `macAlgorithm` needs to be set when reading a keystore. This ensures when `store` is called, the original algorithm is used.
>
> The `macAlgorithm` and `writeIterationCount` fields are initialized to be null and -1. When reading a keystore, they are filled with the actual values. When storing a keystore, if they are still null or -1, default values are used.

This code has changed. I think this is fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2411830768

From weijun at openjdk.org  Tue Oct  7 20:42:48 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 7 Oct 2025 20:42:48 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE [v4]
In-Reply-To: <7QLbTmEuoiIch_Focv04z5oo7F7r2JcXkTY477WUD74=.a66f4ce8-03a0-43f9-a260-b04ae8940afc@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
 <7QLbTmEuoiIch_Focv04z5oo7F7r2JcXkTY477WUD74=.a66f4ce8-03a0-43f9-a260-b04ae8940afc@github.com>
Message-ID: <hSCFUb1TnNC_XG4ookRZ49eAek-UnhIjrNtPDo6iTCs=.2147e41b-9451-4955-a632-260980c77377@github.com>

On Tue, 7 Oct 2025 20:31:45 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 
>> 
>> Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused variable

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27615#pullrequestreview-3311799957

From valeriep at openjdk.org  Tue Oct  7 20:42:48 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 7 Oct 2025 20:42:48 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE [v4]
In-Reply-To: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
Message-ID: <7QLbTmEuoiIch_Focv04z5oo7F7r2JcXkTY477WUD74=.a66f4ce8-03a0-43f9-a260-b04ae8940afc@github.com>

> This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 
> 
> Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 
> 
> Thanks in advance for the review~

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

  removed unused variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27615/files
  - new: https://git.openjdk.org/jdk/pull/27615/files/6fa2a15f..c94c056f

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

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

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

From mpowers at openjdk.org  Tue Oct  7 21:24:35 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 7 Oct 2025 21:24:35 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v12]
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <e0k15guahZhu_w4UOQlxoeUefb1mbI8Zom0_Cng_IOY=.9839df92-3d7c-4269-96fb-57a242ff0d70@github.com>

> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  more review comments from Sean and Weijun

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24429/files
  - new: https://git.openjdk.org/jdk/pull/24429/files/3dea54d9..3b348af4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=10-11

  Stats: 359 lines in 7 files changed: 131 ins; 209 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429

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

From weijun at openjdk.org  Tue Oct  7 21:53:11 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 7 Oct 2025 21:53:11 GMT
Subject: RFR: 8326609: AES implementation with updates specified in FIPS
 197
In-Reply-To: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
References: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
Message-ID: <u_LGLr2UIWJm0F3UkhZMPQS1witvcr7yVuWQxCXlEGg=.a9abe31f-2b15-40e2-852f-8a47e948e79f@github.com>

On Sat, 23 Aug 2025 06:55:14 GMT, Shawn M Emery <duke at openjdk.org> wrote:

> This is a draft PR for early review with the following intent:
> 
> i) This work is to replace the existing AES cipher under the Cryptix license with an Oracle version. 
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several blocks statements are flattened for optimization purposes.
> 
> Note: I have not seen the original Cryptix code, so please don't refer to the deltas, but rather provide references based on the new AESCrypt.java code itself.
> 
> Updates in this delta:
> Phase 2: Optimization - SW
> Phase 3: Optimization - HW
> Fix round key ordering for inverse
> Cleanup comments and style
> Remove extraneous code
> Create constant-time execution - including inverse multiplication Remove sensitive information - including temporary round key attributes

1. I noticed some instance fields are passed into instance methods (for example, `rounds` into `genRKeys())`. Have you considered letting the methods access those fields directly, or make the methods static instead?
2. I remember you used to have methods to generate the large constant arrays. Are they still useful?
3. There is an ongoing discussion about expanding AES to a larger block size. Does the rewrite have this in mind?

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

PR Comment: https://git.openjdk.org/jdk/pull/26912#issuecomment-3224599283

From duke at openjdk.org  Tue Oct  7 21:53:10 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 7 Oct 2025 21:53:10 GMT
Subject: RFR: 8326609: AES implementation with updates specified in FIPS 197
Message-ID: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>

This is a draft PR for early review with the following intent:

i) This work is to replace the existing AES cipher under the Cryptix license with an Oracle version. 

ii) The lookup tables are employed for performance, but also for operating in constant time.

iii) Several blocks statements are flattened for optimization purposes.

Note: I have not seen the original Cryptix code, so please don't refer to the deltas, but rather provide references based on the new AESCrypt.java code itself.

Updates in this delta:
Phase 2: Optimization - SW
Phase 3: Optimization - HW
Fix round key ordering for inverse
Cleanup comments and style
Remove extraneous code
Create constant-time execution - including inverse multiplication Remove sensitive information - including temporary round key attributes

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

Commit messages:
 - Clear inverse mix column transform data from the heap
 - Fix code style remnants
 - Fix indentation - wrapping
 - Code cleanup - round 2
 - Merge with master branch
 - Code cleanup
 - Update copyright year
 - Optimizations for -Xint and -Xcomp modes with Mergestore technique
 - Remove unused variables
 - Reduce the number of object created - for performance
 - ... and 8 more: https://git.openjdk.org/jdk/compare/8c3ca024...5dc19778

Changes: https://git.openjdk.org/jdk/pull/26912/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26912&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326609
  Stats: 1725 lines in 2 files changed: 409 ins; 340 del; 976 mod
  Patch: https://git.openjdk.org/jdk/pull/26912.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26912/head:pull/26912

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

From duke at openjdk.org  Tue Oct  7 21:53:11 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 7 Oct 2025 21:53:11 GMT
Subject: RFR: 8326609: AES implementation with updates specified in FIPS
 197
In-Reply-To: <u_LGLr2UIWJm0F3UkhZMPQS1witvcr7yVuWQxCXlEGg=.a9abe31f-2b15-40e2-852f-8a47e948e79f@github.com>
References: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
 <u_LGLr2UIWJm0F3UkhZMPQS1witvcr7yVuWQxCXlEGg=.a9abe31f-2b15-40e2-852f-8a47e948e79f@github.com>
Message-ID: <JfGXpcapje9N89fNMlaCdY9RQ1xTu6kCDMLeXD-kzvs=.b37cd656-bb26-47fc-9c7b-e472618615e9@github.com>

On Tue, 26 Aug 2025 15:12:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> 1. I noticed some instance fields are passed into instance methods (for example, `rounds` into `genRKeys())`. Have you considered letting the methods access those fields directly, or make the methods static instead?

Good catch; I'll do the former and make updates in the next commit.  See commit 18acd27 for this change and for the method comments to declare mutable and immutable arguments.

> 2. I remember you used to have methods to generate the large constant arrays. Are they still useful?

In this case, the table generators were only meant to create the static lookup tables.  If we were concerned about constrained devices then dynamically generating the tables would be more appropriate, however I don't think that this was the goal with the original source code, given that the current size of AESCrypt is greater than my implementation.

> 3. There is an ongoing discussion about expanding AES to a larger block size. Does the rewrite have this in mind?

Good point; I believe the code is designed to be flexible in introducing a larger block size (i.e., Rijndael-256) given a couple of design elements; i) assigning 'len' to something like 'int WB2 = 8', ii) where there has been flattening for performance optimizations, the statements would be doubled (4->8), and iii) the proposed key size (256 bits) is already supported.

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

PR Comment: https://git.openjdk.org/jdk/pull/26912#issuecomment-3226759891

From ascarpino at openjdk.org  Tue Oct  7 21:53:12 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 7 Oct 2025 21:53:12 GMT
Subject: RFR: 8326609: AES implementation with updates specified in FIPS
 197
In-Reply-To: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
References: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
Message-ID: <SDzbCtcMeceoJOBVDev0GlmjuOXwfHmf11nissjzQPE=.36bc8ad3-d716-47fb-a92d-2828f3bea890@github.com>

On Sat, 23 Aug 2025 06:55:14 GMT, Shawn M Emery <duke at openjdk.org> wrote:

> This is a draft PR for early review with the following intent:
> 
> i) This work is to replace the existing AES cipher under the Cryptix license with an Oracle version. 
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several blocks statements are flattened for optimization purposes.
> 
> Note: I have not seen the original Cryptix code, so please don't refer to the deltas, but rather provide references based on the new AESCrypt.java code itself.
> 
> Updates in this delta:
> Phase 2: Optimization - SW
> Phase 3: Optimization - HW
> Fix round key ordering for inverse
> Cleanup comments and style
> Remove extraneous code
> Create constant-time execution - including inverse multiplication Remove sensitive information - including temporary round key attributes

src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 629:

> 627:             throw new InvalidKeyException ("Invalid algorithm name.");
> 628:         }
> 629:         if (key.length == AES_128_NKEYS) {

A suggestion is the new style switch

switch (key.length) {
    case AES_128_NKEYS -> { ... }
    ...
    default -> throws ...
}

src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 642:

> 640:                     "Invalid key length (" + key.length + ").");
> 641:         }
> 642:         if (!Arrays.equals(prevKey, key)) {

You will want to use `MessageDigest.isEqual(...)` here as it's a constant time.  I realize the usage of `MessageDigest` is strange, but the check method has never been moved to a generic utility java class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26912#discussion_r2310702523
PR Review Comment: https://git.openjdk.org/jdk/pull/26912#discussion_r2310729712

From duke at openjdk.org  Tue Oct  7 21:53:12 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 7 Oct 2025 21:53:12 GMT
Subject: RFR: 8326609: AES implementation with updates specified in FIPS
 197
In-Reply-To: <SDzbCtcMeceoJOBVDev0GlmjuOXwfHmf11nissjzQPE=.36bc8ad3-d716-47fb-a92d-2828f3bea890@github.com>
References: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
 <SDzbCtcMeceoJOBVDev0GlmjuOXwfHmf11nissjzQPE=.36bc8ad3-d716-47fb-a92d-2828f3bea890@github.com>
Message-ID: <aEN7nxrDNnTMawjC7ZBElmsAbygHWQmLT6m9w2Ix-G0=.31643233-6da0-46fa-a3ab-8a495343c8ca@github.com>

On Fri, 29 Aug 2025 17:16:45 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> This is a draft PR for early review with the following intent:
>> 
>> i) This work is to replace the existing AES cipher under the Cryptix license with an Oracle version. 
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several blocks statements are flattened for optimization purposes.
>> 
>> Note: I have not seen the original Cryptix code, so please don't refer to the deltas, but rather provide references based on the new AESCrypt.java code itself.
>> 
>> Updates in this delta:
>> Phase 2: Optimization - SW
>> Phase 3: Optimization - HW
>> Fix round key ordering for inverse
>> Cleanup comments and style
>> Remove extraneous code
>> Create constant-time execution - including inverse multiplication Remove sensitive information - including temporary round key attributes
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 629:
> 
>> 627:             throw new InvalidKeyException ("Invalid algorithm name.");
>> 628:         }
>> 629:         if (key.length == AES_128_NKEYS) {
> 
> A suggestion is the new style switch
> 
> switch (key.length) {
>     case AES_128_NKEYS -> { ... }
>     ...
>     default -> throws ...
> }

Thank you for the suggestion, I will make them in the next commit.  See f819d9f.

> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 642:
> 
>> 640:                     "Invalid key length (" + key.length + ").");
>> 641:         }
>> 642:         if (!Arrays.equals(prevKey, key)) {
> 
> You will want to use `MessageDigest.isEqual(...)` here as it's a constant time.  I realize the usage of `MessageDigest` is strange, but the check method has never been moved to a generic utility java class.

Good catch!  I will make this change in the next commit.  See f819d9f.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26912#discussion_r2311809449
PR Review Comment: https://git.openjdk.org/jdk/pull/26912#discussion_r2311809957

From fitzsim at openjdk.org  Tue Oct  7 23:39:24 2025
From: fitzsim at openjdk.org (Thomas Fitzsimmons)
Date: Tue, 7 Oct 2025 23:39:24 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v3]
In-Reply-To: <08SntfYhxrQjaVkIX90vYAp_0ZPHjdR9xPftipFYMK8=.8a19239a-3a0a-4260-8f4c-3c567ee1cf70@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <oG840hSliwqHawwcaNtpXRp9cpGQWHb-X-4C3ZBNIyw=.280a7d48-4787-434a-9bf5-b85ddde150e5@github.com>
 <O6646LU9zRGOtRc8aAEATTk3EpmTdpeKAHjy_dQ1doI=.ab2e2e28-487f-4084-b535-e73ebd7bec33@github.com>
 <08SntfYhxrQjaVkIX90vYAp_0ZPHjdR9xPftipFYMK8=.8a19239a-3a0a-4260-8f4c-3c567ee1cf70@github.com>
Message-ID: <rvK0WE0iDRlvZi4gyetBUmQvd5WiLw9cFBIHcARPAr4=.0027192f-4b2d-400a-b3ce-2d5a5c62ffab@github.com>

On Tue, 7 Oct 2025 20:33:24 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java line 173:
>> 
>>> 171:         if (keyLength > 0) {
>>> 172:             pBKDF2_params.putInteger(keyLength / 8); // derived key length (in octets)
>>> 173:         }
>> 
>> I think `keyLength` is a MUST here.  Maybe this should instead check if `keyLength` is `<= 0`, and if so, throw an exception.  Then proceed to encode `keyLength` unconditionally.
>
> After innumerable iterations, this encoding method will be removed from `PBMAC1Parameters`.
> That said, keyLength now comes from the Mac before being encoded in `MacData`:
> 
> 
> Mac m = Mac.getInstance(hmac);
> int keyLength = m.getMacLength()*8;
> 
> If this doesn't work, we have some other serious issues.

The `> 0` check is still there in MacData.getEncoded:


        if (this.pbmac1Keystore) {
        [...]
            // encode derived key length
            if (this.keyLength > 0) {
                pBKDF2_params.putInteger(this.keyLength / 8); // derived key length (in octets)
            }


How about making sure it is greater than zero in the constructor instead, something like:


--- a/src/java.base/share/classes/sun/security/pkcs12/MacData.java
+++ b/src/java.base/share/classes/sun/security/pkcs12/MacData.java
@@ -122,6 +122,10 @@ class MacData {
         }
         if (algName.equals("PBMAC1")) {
             this.pbmac1Keystore = true;
+            if (keyLength <= 0) {
+                throw new IllegalArgumentException("the keyLength " +
+                        "parameter for PBMAC1 must be greater than 0");
+            }
         }
         algid = AlgorithmId.get(algName);
 
@@ -333,9 +337,7 @@ byte[] getEncoded() throws NoSuchAlgorithmException, IOException {
             pBKDF2_params.putInteger(this.iterations);
 
             // encode derived key length
-            if (this.keyLength > 0) {
-                pBKDF2_params.putInteger(this.keyLength / 8); // derived key length (in octets)
-            }
+            pBKDF2_params.putInteger(this.keyLength / 8); // derived key length (in octets)
             pBKDF2_params.write(DerValue.tag_Sequence, kdfHmac);
             tmp3.putOID(pkcs5PBKDF2_OID);
             tmp3.write(DerValue.tag_Sequence, pBKDF2_params);


Should `keyLength` also be initialized in the `MacData(DerInputStream derin)` constructor?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2412170819

From valeriep at openjdk.org  Wed Oct  8 02:23:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 8 Oct 2025 02:23:05 GMT
Subject: RFR: 8368694: PKCS11-NSS generic keys generated by DH have leading
 zeroes stripped
In-Reply-To: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com>
References: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com>
Message-ID: <up1lilAXbBOT5NopI6B4R-SyHBVaNI9TtBNAcG7ZUbE=.3b38c582-d83b-4146-a182-644cf3cbb4cd@github.com>

On Thu, 25 Sep 2025 16:28:25 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The DiffieHellman KeyAgreement supports 2 key algorithms: TlsPremasterSecret and Generic. The Generic algorithm is supposed to generate keys of a constant length, keeping leading zeroes as appropriate.
> 
> This PR changes the SunPKCS11 implementation to pass a CKA_VALUE_LEN attribute when a fixed length is needed; when the attribute is absent, the PKCS11 provider strips the leading zeroes.
> 
> Added a check to the existing test cases to verify the fix. The check passes with the fix, fails without it. Other tier1-3 tests continue to pass.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyAgreement.java line 335:

> 333:                         new CK_ATTRIBUTE(CKA_CLASS, CKO_SECRET_KEY),
> 334:                         new CK_ATTRIBUTE(CKA_KEY_TYPE, keyType),
> 335:                         new CK_ATTRIBUTE(CKA_VALUE_LEN, secretLen),

How about attributes in another `xxxGenerateSecret(...)` method? Should we also add `CKA_VALUE_LEN` attribute  with `secretLen` value there as well, i.e. line 200-203,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27494#discussion_r2412341167

From valeriep at openjdk.org  Wed Oct  8 05:56:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 8 Oct 2025 05:56:03 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE [v4]
In-Reply-To: <7QLbTmEuoiIch_Focv04z5oo7F7r2JcXkTY477WUD74=.a66f4ce8-03a0-43f9-a260-b04ae8940afc@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
 <7QLbTmEuoiIch_Focv04z5oo7F7r2JcXkTY477WUD74=.a66f4ce8-03a0-43f9-a260-b04ae8940afc@github.com>
Message-ID: <WutyH7p-0OW5ImedwuauSjb4q_nNpfR4xT3a77jqV84=.35cc1ae0-71e9-4048-9735-6b94831ebd7a@github.com>

On Tue, 7 Oct 2025 20:42:48 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 
>> 
>> Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused variable

Thanks for the review~

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

PR Comment: https://git.openjdk.org/jdk/pull/27615#issuecomment-3379691303

From valeriep at openjdk.org  Wed Oct  8 05:56:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 8 Oct 2025 05:56:06 GMT
Subject: RFR: 8368984: Extra slashes in Cipher transformation leads to NSPE
 instead of NSAE [v3]
In-Reply-To: <12RQwa2uyoY3wTfLHAiFGxy7IPgAcSLZ_iYPi-jdu_A=.c048b2a5-75e6-40b9-a075-70e0a45a3f93@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
 <Vf0dKCX7aQ6DBeFw0xuBztbSvDJThfslZBAbKcSt7P4=.2a47e141-15ed-4927-a30d-d900bcfc9a53@github.com>
 <12RQwa2uyoY3wTfLHAiFGxy7IPgAcSLZ_iYPi-jdu_A=.c048b2a5-75e6-40b9-a075-70e0a45a3f93@github.com>
Message-ID: <XhSvpFwsL2VbrwjInq0SuP2NfiZEvMvAEtoOAWgCpKc=.d6e894d6-43fa-43f5-90b8-b3b632a641fc@github.com>

On Tue, 7 Oct 2025 18:35:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on Weijun's suggestion.
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 290:
> 
>> 288: 
>> 289:     // for special handling SHA-512/224, SHA-512/256, SHA512/224, SHA512/256
>> 290:     private static final String SHA512TRUNCATED = "512/2";
> 
> Is this constant still used?

Nope, I've removed it in the last commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27615#discussion_r2412594205

From raveenakushwah83 at gmail.com  Wed Oct  8 07:26:12 2025
From: raveenakushwah83 at gmail.com (Isha K)
Date: Wed, 8 Oct 2025 12:56:12 +0530
Subject: Issues we are facing in fips mode
Message-ID: <CAG6QaQ_Fi4SS9H96y4MCV4nVFGGfLY6jstWNCn01RaJ9P+dPPA@mail.gmail.com>

Hi

     This mail is to check with you on two issues we are facing.

1. In our application for tls handshake, we are using tomcat 10.1.44 server
along with JDK 17.0.3+7.

In our application, we observed that in non fips mode using tls1.2/ tls1.3
protocol, session tickets are sent, but not in fips mode where we are using
bcfips-2.0.1 , bctls-fips-2.0.20, bcutil-fips-2.0.3 and bcpkix-fips-2.0.8
jars.

Is it expected behaviour? I checked online but didn't find any supporting
statements.

2. In non fips we had this property javax.net.debug in jvm.properties which
would give us details on the handshake in catalina.out file , but in fips
this property is not working.

To enable fips we are setting bcfips, bcjsse provider as 1st and 2nd
priority in java.security file.

Please let me know if any other details are required.

Your response will help us in narrowing down the issue and work on the
actual ones.

Waiting keenly for your response.

Regards
Raveena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20251008/028d1175/attachment.htm>

From djelinski at openjdk.org  Wed Oct  8 10:13:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Oct 2025 10:13:01 GMT
Subject: RFR: 8368694: PKCS11-NSS generic keys generated by DH have leading
 zeroes stripped [v2]
In-Reply-To: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com>
References: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com>
Message-ID: <Eprt7L6hCKXNb6NGT9_KT1Bs85v4RplGTcZzLaPg3gs=.cd53209f-a449-483b-9019-9733dc682366@github.com>

> The DiffieHellman KeyAgreement supports 2 key algorithms: TlsPremasterSecret and Generic. The Generic algorithm is supposed to generate keys of a constant length, keeping leading zeroes as appropriate.
> 
> This PR changes the SunPKCS11 implementation to pass a CKA_VALUE_LEN attribute when a fixed length is needed; when the attribute is absent, the PKCS11 provider strips the leading zeroes.
> 
> Added a check to the existing test cases to verify the fix. The check passes with the fix, fails without it. Other tier1-3 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Use CKA_VALUE_LEN in parameterless engineGenerateSecret

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27494/files
  - new: https://git.openjdk.org/jdk/pull/27494/files/7f1e31bf..818e0348

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

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

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

From djelinski at openjdk.org  Wed Oct  8 10:19:13 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 8 Oct 2025 10:19:13 GMT
Subject: RFR: 8368694: PKCS11-NSS generic keys generated by DH have leading
 zeroes stripped [v2]
In-Reply-To: <up1lilAXbBOT5NopI6B4R-SyHBVaNI9TtBNAcG7ZUbE=.3b38c582-d83b-4146-a182-644cf3cbb4cd@github.com>
References: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com>
 <up1lilAXbBOT5NopI6B4R-SyHBVaNI9TtBNAcG7ZUbE=.3b38c582-d83b-4146-a182-644cf3cbb4cd@github.com>
Message-ID: <w0jOjXoGlAXJK6HP89yvTLNRxkhvpzJIlnakbGgBnw8=.bb06ad4e-865d-449b-b280-2aceeb88c1ca@github.com>

On Wed, 8 Oct 2025 02:20:17 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use CKA_VALUE_LEN in parameterless engineGenerateSecret
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyAgreement.java line 335:
> 
>> 333:                         new CK_ATTRIBUTE(CKA_CLASS, CKO_SECRET_KEY),
>> 334:                         new CK_ATTRIBUTE(CKA_KEY_TYPE, keyType),
>> 335:                         new CK_ATTRIBUTE(CKA_VALUE_LEN, secretLen),
> 
> How about attributes in another `xxxGenerateSecret(...)` method? Should we also add `CKA_VALUE_LEN` attribute  with `secretLen` value there as well, i.e. line 200-203,

Thanks @valeriepeng for the review. I added CKA_VALUE_LEN to the paramterless overload now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27494#discussion_r2413358229

From shade at openjdk.org  Wed Oct  8 11:44:07 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 11:44:07 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available
In-Reply-To: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
Message-ID: <H4qY9_uRjjXF8Ikk4nZa-UVLRDVpXOpa0F9qtH_c44w=.6c4537f3-3b46-4c24-87e2-6dce16095af4@github.com>

On Thu, 25 Sep 2025 14:27:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.

This test is failing pretty consistently for us now. Any progress on this? :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27491#issuecomment-3381124410

From weijun at openjdk.org  Wed Oct  8 11:52:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 8 Oct 2025 11:52:04 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available
In-Reply-To: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
Message-ID: <SY5ddQnb-KmT5hEoY9iBC_Vzd_v9pbWQ_zB4rYS0W0c=.1d92183c-aa94-4826-b4ba-fd670c692750@github.com>

On Thu, 25 Sep 2025 14:27:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.

The change looks fine. Please fix this way for now, and we'll see if it can be made simpler later. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27491#pullrequestreview-3314448708

From sean.mullan at oracle.com  Wed Oct  8 12:07:33 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Oct 2025 08:07:33 -0400
Subject: Issues we are facing in fips mode
In-Reply-To: <CAG6QaQ_Fi4SS9H96y4MCV4nVFGGfLY6jstWNCn01RaJ9P+dPPA@mail.gmail.com>
References: <CAG6QaQ_Fi4SS9H96y4MCV4nVFGGfLY6jstWNCn01RaJ9P+dPPA@mail.gmail.com>
Message-ID: <71d8958b-8441-431c-bee5-1fa570047780@oracle.com>

This does not appear to be a JDK issue. You are using JAR files from 
Bouncy Castle, so I think you should contact them for assistance.

Thanks,
Sean

On 10/8/25 3:26 AM, Isha K wrote:
> Hi
> 
>  ? ? ?This mail is to check with you on two issues we are facing.
> 
> 1. In our application for tls handshake, we are using tomcat 10.1.44 
> server along with JDK 17.0.3+7.
> 
> In our application, we observed that in non fips mode using tls1.2/ 
> tls1.3 protocol, session tickets are sent, but not in fips mode where we 
> are using bcfips-2.0.1 , bctls-fips-2.0.20, bcutil-fips-2.0.3 and 
> bcpkix-fips-2.0.8 jars.
> 
> Is it expected behaviour? I checked online but didn't find any 
> supporting statements.
> 
> 2. In non fips we had this property javax.net.debug in jvm.properties 
> which would give us details on the handshake in catalina.out file , but 
> in fips this property is not working.
> 
> To enable fips we are setting bcfips, bcjsse provider as 1st and 2nd 
> priority in java.security file.
> 
> Please let me know if any other details are required.
> 
> Your response will help us in narrowing down the issue and work on the 
> actual ones.
> 
> Waiting keenly for your response.
> 
> Regards
> Raveena


From myankelevich at openjdk.org  Wed Oct  8 15:19:50 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 8 Oct 2025 15:19:50 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available
In-Reply-To: <_VR8jTuexQxRqQXgnZ8X1Wlp_8LAdJctG0zAPf3w_aU=.53a94c9d-d9b6-4bcb-bb3f-01b69bd7c96e@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
 <JY452lAyC4opIYSsFcpKgA-TikUweAjgRKsrqrPVN4E=.84cb55c0-6f05-43b6-a1b4-abad6489d241@github.com>
 <_VR8jTuexQxRqQXgnZ8X1Wlp_8LAdJctG0zAPf3w_aU=.53a94c9d-d9b6-4bcb-bb3f-01b69bd7c96e@github.com>
Message-ID: <LR4eDddt7Jifhme7V_j0dR1dsFg3fXoIgoMlxWIRF0A=.90bc7dc8-4a80-4b62-856e-4e3f76ae426b@github.com>

On Fri, 3 Oct 2025 15:14:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/provider/acvp/Launcher.java line 124:
>> 
>>> 122:         } catch (IOException e) {
>>> 123:             if (e.getMessage().contains("Cannot find the artifact ACVP-Server")) {
>>> 124:                 throw new SkippedException("ACVP-Server not available, skip test.");
>> 
>> nit: 
>> Suggestion:
>> 
>>                 throw new SkippedException("ACVP-Server not available.");
>
> Hi @myankelev, can you just take a look at all our tests that call `ArtifactResolver.fetchOne` to see if it can directly throw a `SkippedException`? Thanks.

@wangweij `ArtifactResolver.fetchOne` is called in a couple of places but calls different artifacts. I think if it is changed to throw skipped exception itself it might end up not very descriptive. Also, it throws an IOException if it can't find a file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27491#discussion_r2414222141

From myankelevich at openjdk.org  Wed Oct  8 15:27:24 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 8 Oct 2025 15:27:24 GMT
Subject: RFR: 8368982: Test sun/security/tools/jarsigner/EC.java completed and
 timed out
Message-ID: <sIQCKm-XGEghN_mfOHChULMIrWOgjCvEidb56SM6suM=.2a708c5e-45ed-41b6-bc81-78e5b60afed5@github.com>

Increased a timeout from default 120. Each test runs 25 commands with 5 sec spent on each, so this made it likely that 120 would timeout. I think changing it to 300 would be a nice buffer.

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

Commit messages:
 - JDK-8368982: Test sun/security/tools/jarsigner/EC.java completed and timed out

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

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

From shade at openjdk.org  Wed Oct  8 16:43:02 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 16:43:02 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available
In-Reply-To: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
Message-ID: <CU9xRKit0cKgHteQeW6ldXhYsYgYsybR5715hWOazzY=.7edb305e-7b3b-451b-afdf-93211e82bde8@github.com>

On Thu, 25 Sep 2025 14:27:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.

Thanks, let's do it.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27491#pullrequestreview-3315683151

From duke at openjdk.org  Wed Oct  8 16:58:55 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 8 Oct 2025 16:58:55 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always have
 NULL as params
Message-ID: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>

Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.

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

Commit messages:
 - 8367008: Algorithm identifiers for HmacSHA* should always have NULL as params
 - 8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

Changes: https://git.openjdk.org/jdk/pull/27700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27700&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367008
  Stats: 103 lines in 2 files changed: 43 ins; 27 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/27700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27700/head:pull/27700

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

From valeriep at openjdk.org  Wed Oct  8 17:29:18 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 8 Oct 2025 17:29:18 GMT
Subject: RFR: 8368694: PKCS11-NSS generic keys generated by DH have leading
 zeroes stripped [v2]
In-Reply-To: <Eprt7L6hCKXNb6NGT9_KT1Bs85v4RplGTcZzLaPg3gs=.cd53209f-a449-483b-9019-9733dc682366@github.com>
References: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com>
 <Eprt7L6hCKXNb6NGT9_KT1Bs85v4RplGTcZzLaPg3gs=.cd53209f-a449-483b-9019-9733dc682366@github.com>
Message-ID: <6_ERa0V9gnDLK75M2Su0e7g7FNXmMVjhg3ENh_kUyv0=.9c194234-3f6b-43a4-ab04-5b68f43c4db4@github.com>

On Wed, 8 Oct 2025 10:13:01 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> The DiffieHellman KeyAgreement supports 2 key algorithms: TlsPremasterSecret and Generic. The Generic algorithm is supposed to generate keys of a constant length, keeping leading zeroes as appropriate.
>> 
>> This PR changes the SunPKCS11 implementation to pass a CKA_VALUE_LEN attribute when a fixed length is needed; when the attribute is absent, the PKCS11 provider strips the leading zeroes.
>> 
>> Added a check to the existing test cases to verify the fix. The check passes with the fix, fails without it. Other tier1-3 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use CKA_VALUE_LEN in parameterless engineGenerateSecret

Changes look good.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27494#pullrequestreview-3315836291

From valeriep at openjdk.org  Wed Oct  8 17:38:58 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 8 Oct 2025 17:38:58 GMT
Subject: Integrated: 8368984: Extra slashes in Cipher transformation leads to
 NSPE instead of NSAE
In-Reply-To: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
References: <95cziIdAyVtyeOZImF-plGtjmZ_INh3A5LvjQ7aKb8E=.e4f90259-c76d-4f71-84fa-2913e5ebb0d3@github.com>
Message-ID: <N4sGGIuWZ8F5V0X7PMJTlT7VK0is9OIYLA3nzcqqPCw=.4c79bfa2-4a4e-49c3-8384-69496e367e70@github.com>

On Thu, 2 Oct 2025 23:14:48 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> This PR updates the cipher transformation parsing and verification logic to be stricter and throws NoSuchAlgorithmException (NSAE) when additional slash(es) is found. With the existing parsing logic, the extra slash(es) is likely to end up in the last component, i.e. the padding scheme, and lead to NoSuchPaddingException (NSPE) from the underlying CipherSpi object. 
> 
> Out of the supported cipher algorithms for all JDK providers, PBES2 cipher algorithms and RSA cipher with OAEP paddings may contain truncated SHA-512 in their transformations. This proposed fix would check for truncated SHA in both algorithm and padding schemes and throws NSAE if any extra slash is found. 
> 
> Thanks in advance for the review~

This pull request has now been integrated.

Changeset: ac73e688
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac73e688b13595b63dcfc9ce0aee76e7262d68c3
Stats:     168 lines in 4 files changed: 50 ins; 58 del; 60 mod

8368984: Extra slashes in Cipher transformation leads to NSPE instead of NSAE

Reviewed-by: weijun

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

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

From mullan at openjdk.org  Wed Oct  8 17:52:35 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 8 Oct 2025 17:52:35 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups [v3]
In-Reply-To: <dcocyfrABZ5Ty7grHShtJ_u_rC-cNrQiVktfqAsktwk=.5285a479-4d48-4748-9b43-2e0663d6da68@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <dcocyfrABZ5Ty7grHShtJ_u_rC-cNrQiVktfqAsktwk=.5285a479-4d48-4748-9b43-2e0663d6da68@github.com>
Message-ID: <pguIjdmAf3qMOGVCFkY1O8fh5aT2Toll0mKzsWKzPnY=.ac945723-aed1-48c4-b56d-7db6f7e9bf05@github.com>

On Wed, 3 Sep 2025 19:35:27 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - I removed signature algorithms output because the information is created during TLS handshake
>  - Merge branch 'master' into secsettings
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

src/java.base/share/classes/sun/launcher/SecuritySettings.java line 140:

> 138:             }
> 139: 
> 140:             ostream.println("\n" + TWOINDENT + "Enabled Groups:");

Change this to "Enabled Named Groups:". This would be more consistent with the API (`get/setNamedGroups`) and the Named Groups section of the Standard Algorithm Names spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24424#discussion_r2414604767

From abarashev at openjdk.org  Wed Oct  8 21:45:24 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 8 Oct 2025 21:45:24 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v2]
In-Reply-To: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
Message-ID: <NpSXKc_VP1vipXxdfJW_lR5jVvhEEBByfUmaJEefgtc=.11bd5374-6e81-4127-8e59-7a443d80f3d2@github.com>

> If the NewSessionTicket message is lost, the handshake fails on the client side with:
> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Address Daniel's suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27677/files
  - new: https://git.openjdk.org/jdk/pull/27677/files/9ce3adb0..ae13a016

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

  Stats: 80 lines in 3 files changed: 60 ins; 14 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27677/head:pull/27677

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

From abarashev at openjdk.org  Wed Oct  8 21:58:22 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 8 Oct 2025 21:58:22 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v3]
In-Reply-To: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
Message-ID: <-gt7Mtg7jKKb6kIoj98JIcZlAcyuibtj2vfXYUH9Zp8=.0e8a1f6a-6bcf-4f1a-8949-660b07466e99@github.com>

> If the NewSessionTicket message is lost, the handshake fails on the client side with:
> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Make sure we log the correct "isReady" value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27677/files
  - new: https://git.openjdk.org/jdk/pull/27677/files/ae13a016..e6da9b06

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

  Stats: 18 lines in 1 file changed: 7 ins; 7 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27677/head:pull/27677

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

From dholmes at openjdk.org  Thu Oct  9 02:08:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:08:07 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v4]
In-Reply-To: <BcSiADOz3PuL2aGThKS0UTlFlTZjXwpzNpFyuztnB8k=.49fc6743-ef25-46ec-8432-903deed615a5@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <e9iXm-BSdvvUoZQK3aAarNc0ER3GwByVS9UorOyeyJs=.cab06bfc-81be-4f9c-ac06-b142af67db0f@github.com>
 <HqL4iMPA3RNYPXe3qWGZajhaEddQEnU4wHmo--Wk0a8=.484a4841-7593-4d57-87bf-6723689a8803@github.com>
 <K1HnWhAw-MFAnbCkwK2QwdlJjWuSw1iKzel7SvRtzDg=.43e4c957-fc45-4551-97c5-073011f5157a@github.com>
 <1Ed3XduxQZKSVBUng2-sUeD1ib9ZZqRQBN18n0SrAwY=.496748d7-01f9-4b9f-a184-d364f3d7d0f2@github.com>
 <VuK3AaZ6zIZmNgnGWk0ydc9wEazGvyHdfWiDVFeurHs=.514d7ab3-2811-4764-99a6-9ca95b20de1b@github.com>
 <BcSiADOz3PuL2aGThKS0UTlFlTZjXwpzNpFyuztnB8k=.49fc6743-ef25-46ec-8432-903deed615a5@github.com>
Message-ID: <dIvZ3g5gD63kYKL0ztB_2Sh8CLSsnzDJ8zvtlAgd3EY=.2757ef4f-189b-47b9-b69f-01892376f4db@github.com>

On Wed, 8 Oct 2025 08:05:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > I think what you are suggesting is that the JEP could instead have -Xcheck:jni emit a warning when JNI setter functions mutate final fields, and maybe change it to be a fatal error in the future, maybe as part of the future JEP that proposes to move "deny" the default.
> > 
> > 
> > @AlanBateman yes that is exactly what I am suggesting. Thanks
> 
> I discussed this with Ron. Mutating final fields from native code isn't core to this JEP. A fatal error would be better but we are okay with it initially being a warning instead. So we'll update that section of the JEP, and change the addition to jniCheck to use ReportJNIWarning instead of ReportJNIFatalError.

Thank you @AlanBateman and @pron !

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

PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3383789373

From syan at openjdk.org  Thu Oct  9 03:46:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 Oct 2025 03:46:36 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available [v2]
In-Reply-To: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
Message-ID: <d5FF92Ebi1hdBHo1D-I_IgtZAMkkibLyPesDQlJr_AA=.5341bdb2-5d11-4232-b92a-391d6c93a6f4@github.com>

> Hi all,
> 
> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.

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

  Update test/jdk/sun/security/provider/acvp/Launcher.java
  
  Co-authored-by: Mikhail Yankelevich <mikhailyankelevich at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27491/files
  - new: https://git.openjdk.org/jdk/pull/27491/files/b38be66e..38567b6f

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

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

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

From syan at openjdk.org  Thu Oct  9 03:51:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 Oct 2025 03:51:02 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available [v2]
In-Reply-To: <LR4eDddt7Jifhme7V_j0dR1dsFg3fXoIgoMlxWIRF0A=.90bc7dc8-4a80-4b62-856e-4e3f76ae426b@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
 <JY452lAyC4opIYSsFcpKgA-TikUweAjgRKsrqrPVN4E=.84cb55c0-6f05-43b6-a1b4-abad6489d241@github.com>
 <_VR8jTuexQxRqQXgnZ8X1Wlp_8LAdJctG0zAPf3w_aU=.53a94c9d-d9b6-4bcb-bb3f-01b69bd7c96e@github.com>
 <LR4eDddt7Jifhme7V_j0dR1dsFg3fXoIgoMlxWIRF0A=.90bc7dc8-4a80-4b62-856e-4e3f76ae426b@github.com>
Message-ID: <XW1G8-aOXZ2yJrV9PPceckZ29iRZJCB_8l962hKLoZk=.d878984f-47a0-4ef4-9b56-9f5296697684@github.com>

On Wed, 8 Oct 2025 15:16:47 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Hi @myankelev, can you just take a look at all our tests that call `ArtifactResolver.fetchOne` to see if it can directly throw a `SkippedException`? Thanks.
>
> @wangweij `ArtifactResolver.fetchOne` is called in a couple of places but calls different artifacts. I think if it is changed to throw skipped exception itself it might end up not very descriptive. Also, it throws an IOException if it can't find a file.

Sorry for the delay response. I have update the Exception messages, can you review again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27491#discussion_r2415496330

From shade at openjdk.org  Thu Oct  9 04:43:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Oct 2025 04:43:17 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available [v2]
In-Reply-To: <d5FF92Ebi1hdBHo1D-I_IgtZAMkkibLyPesDQlJr_AA=.5341bdb2-5d11-4232-b92a-391d6c93a6f4@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
 <d5FF92Ebi1hdBHo1D-I_IgtZAMkkibLyPesDQlJr_AA=.5341bdb2-5d11-4232-b92a-391d6c93a6f4@github.com>
Message-ID: <iVUkdCPe4gI8bmPQontMZyUmXy1--ufzGFjN07vd78s=.194a2ca7-9f1f-44ae-b6ef-a03d4eaccedd@github.com>

On Thu, 9 Oct 2025 03:46:36 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/security/provider/acvp/Launcher.java
>   
>   Co-authored-by: Mikhail Yankelevich <mikhailyankelevich at gmail.com>

Thanks, let's do it.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27491#pullrequestreview-3317200652

From hchao at openjdk.org  Thu Oct  9 05:59:04 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 9 Oct 2025 05:59:04 GMT
Subject: RFR: 8366244: TLS1.3 ChangeCipherSpec message received after the
 client's Finished message should trigger a connection abort with
 "unexpected message" [v2]
In-Reply-To: <tOBsRr4qwmkhRAU8lRYSr1SbNrg7545mQIPwhak4mdU=.0eb15843-ddfd-4058-a65e-1d609113bbaf@github.com>
References: <L7cJZ-9ReOFAMB41aKSQ33_vjyVqntPhENHq5l5UhFM=.a87e5a87-d8da-45bd-a616-3d7b51f025a2@github.com>
 <tOBsRr4qwmkhRAU8lRYSr1SbNrg7545mQIPwhak4mdU=.0eb15843-ddfd-4058-a65e-1d609113bbaf@github.com>
Message-ID: <fLuPj6KGz_uMxTKuFFxPd5e68cKpWul79ngpzA1onkA=.4e3ece35-162e-4cc2-81b9-731d5277f2e9@github.com>

On Mon, 29 Sep 2025 16:43:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> According to the TLS specification, RFC 8446 section 5,
>> 
>> An implementation may receive an unencrypted record of type
>>    change_cipher_spec consisting of the single byte value 0x01 at any
>>    time after the first ClientHello message has been sent or received
>>    and before the peer's Finished message has been received and MUST
>>    simply drop it without further processing. Note that this record may
>>    appear at a point at the handshake where the implementation is
>>    expecting protected records, and so it is necessary to detect this
>>    condition prior to attempting to deprotect the record. An
>>    implementation which receives any other change_cipher_spec value or
>>    which receives a protected change_cipher_spec record MUST abort the
>>    handshake with an "unexpected_message" alert. If an implementation
>>    detects a change_cipher_spec record received before the first
>>    ClientHello message or after the peer's Finished message, it MUST be
>>    treated as an unexpected record type (though stateless servers may
>>    not be able to distinguish these cases from allowed cases).
>> 
>> 
>> However the TLS implementation ignores a CCS message received after the client's Finished, instead of sending an alert(fatal, unexpected_message) and aborting the connection.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27529#pullrequestreview-3317323910

From djelinski at openjdk.org  Thu Oct  9 06:01:05 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 9 Oct 2025 06:01:05 GMT
Subject: RFR: 8368694: PKCS11-NSS generic keys generated by DH have leading
 zeroes stripped [v2]
In-Reply-To: <6_ERa0V9gnDLK75M2Su0e7g7FNXmMVjhg3ENh_kUyv0=.9c194234-3f6b-43a4-ab04-5b68f43c4db4@github.com>
References: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com>
 <Eprt7L6hCKXNb6NGT9_KT1Bs85v4RplGTcZzLaPg3gs=.cd53209f-a449-483b-9019-9733dc682366@github.com>
 <6_ERa0V9gnDLK75M2Su0e7g7FNXmMVjhg3ENh_kUyv0=.9c194234-3f6b-43a4-ab04-5b68f43c4db4@github.com>
Message-ID: <kYe0mFXxhqhk0SQC5r-K_ztRseJ1XcWfJXyo1mOK6xg=.8497ed21-7f18-416a-b9aa-98ebcba55bcf@github.com>

On Wed, 8 Oct 2025 17:26:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use CKA_VALUE_LEN in parameterless engineGenerateSecret
>
> Changes look good.

Thanks @valeriepeng for the re-review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27494#issuecomment-3384242024

From djelinski at openjdk.org  Thu Oct  9 06:04:14 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 9 Oct 2025 06:04:14 GMT
Subject: Integrated: 8368694: PKCS11-NSS generic keys generated by DH have
 leading zeroes stripped
In-Reply-To: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com>
References: <1m7vZTKvXDRzCY-B14L9woDdIt0ubjBmhJLcVcC7-Xs=.a0e752fd-0deb-4971-b5c3-e82833cc7fde@github.com>
Message-ID: <dOrdn89Y_KyJTNSO1eJePvKok4EWHjxjvbEwz2hmN5k=.0fbacae6-8d4b-44df-8537-4cb90adc0361@github.com>

On Thu, 25 Sep 2025 16:28:25 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The DiffieHellman KeyAgreement supports 2 key algorithms: TlsPremasterSecret and Generic. The Generic algorithm is supposed to generate keys of a constant length, keeping leading zeroes as appropriate.
> 
> This PR changes the SunPKCS11 implementation to pass a CKA_VALUE_LEN attribute when a fixed length is needed; when the attribute is absent, the PKCS11 provider strips the leading zeroes.
> 
> Added a check to the existing test cases to verify the fix. The check passes with the fix, fails without it. Other tier1-3 tests continue to pass.

This pull request has now been integrated.

Changeset: 914b44e2
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/914b44e277df23418736eb00c022bbd829d64e11
Stats:     88 lines in 3 files changed: 52 ins; 25 del; 11 mod

8368694: PKCS11-NSS generic keys generated by DH have leading zeroes stripped

Reviewed-by: valeriep

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

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

From coffeys at openjdk.org  Thu Oct  9 08:14:17 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 9 Oct 2025 08:14:17 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v23]
In-Reply-To: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
Message-ID: <Wi7X4p3e981qjhuu7CJDAzoc0Ss9-taohqW2mRmhy4k=.bded5b64-1f53-467b-b7c7-776405c1bc47@github.com>

> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
> 
> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
> 
> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
> 
> 
>         System.err.println("help           print the help messages");
>         System.err.println("expand         expand debugging information");
>         System.err.println();
>         System.err.println("all            turn on all debugging");
>         System.err.println("ssl            turn on ssl debugging");
>         System.err.println();
>         System.err.println("The following can be used with ssl:");
>         System.err.println("\trecord       enable per-record tracing");
>         System.err.println("\thandshake    print each handshake message");
>         System.err.println("\tkeygen       print key generation data");
>         System.err.println("\tsession      print session activity");
>         System.err.println("\tdefaultctx   print default SSL initialization");
>         System.err.println("\tsslctx       print SSLContext tracing");
>         System.err.println("\tsessioncache print session cache tracing");
>         System.err.println("\tkeymanager   print key manager tracing");
>         System.err.println("\ttrustmanager print trust manager tracing");
>         System.err.println("\tpluggability print pluggability tracing");
>         System.err.println();
>         System.err.println("\thandshake debugging can be widened with:");
>         System.err.println("\tdata         hex dump of each handshake message");
>         System.err.println("\tverbose      verbose handshake message printing");
>         System.err.println();
>         System.err.println("\trecord debugging can be widened with:");
>         System.err.println("\tplaintext    hex dump of record plaintext");
>         System.err.println("\tpacket       print raw SSL/TLS packets");
> 
> 
> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
> 
> the output has changed slightly with respect to that  - less verbose
> 
> e.g. old style:
> 
> 
> javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut...

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:

 - Merge branch 'master' into 8044609-ssl
 - Merge branch 'master' into 8044609-ssl
 - Incorporate review comments from Brad
 - Merge branch 'master' into 8044609-ssl
 - Further review comments, copyright years also
 - Initial review comments from Brad
 - Merge branch 'master' into 8044609-ssl
 - 1 file omitted during merge
 - Merge branch 'master' into 8044609-ssl
 - Merge branch 'master' into 8044609-ssl
 - ... and 31 more: https://git.openjdk.org/jdk/compare/6bec42ad...53f9d757

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

Changes: https://git.openjdk.org/jdk/pull/18764/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=22
  Stats: 1330 lines in 84 files changed: 483 ins; 87 del; 760 mod
  Patch: https://git.openjdk.org/jdk/pull/18764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764

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

From coffeys at openjdk.org  Thu Oct  9 08:31:04 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 9 Oct 2025 08:31:04 GMT
Subject: RFR: 8360373:
 src/java.base/share/classes/sun/security/util/Debug.java implement negative
 testing
In-Reply-To: <ORFqOHCMSIMwf5Xq7b4DqNw2UAogbRLgIOgAQkBRRPU=.7adcfefe-42d7-4c88-9e0e-e52c7bb00338@github.com>
References: <ORFqOHCMSIMwf5Xq7b4DqNw2UAogbRLgIOgAQkBRRPU=.7adcfefe-42d7-4c88-9e0e-e52c7bb00338@github.com>
Message-ID: <vgf5MP4ZRpISQnEK0yeXu6aiIVwEBwUr54zuoQR11_I=.5c5970b3-2873-4d7a-9c43-f3884400cff1@github.com>

On Fri, 15 Aug 2025 10:41:40 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Please consider my proposal to add some negative testing to the Debug.java. 
> 
> Adding a test, that will automatically convert current test cases into a broken parameters and expecting the successful execution, but without a debug result. This approach should keep the simplicity of adding new test cases, as this is happening automatically.

test/jdk/sun/security/util/Debug/DebugOptions.java line 140:

> 138: 
> 139:         final OutputAnalyzer outputAnalyzer = ProcessTools.executeTestJava(
> 140:                 paramName + "NONSENSE" + nonsenseParam + "NONSENSE",

you're printing the test parms in the "Executing" statement at line 135 but then you're augmenting this value further in the executeTestJava method call. Is that intended ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26796#discussion_r2415976908

From duke at openjdk.org  Thu Oct  9 09:09:51 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Thu, 9 Oct 2025 09:09:51 GMT
Subject: RFR: 8366244: TLS1.3 ChangeCipherSpec message received after the
 client's Finished message should trigger a connection abort with
 "unexpected message" [v2]
In-Reply-To: <tOBsRr4qwmkhRAU8lRYSr1SbNrg7545mQIPwhak4mdU=.0eb15843-ddfd-4058-a65e-1d609113bbaf@github.com>
References: <L7cJZ-9ReOFAMB41aKSQ33_vjyVqntPhENHq5l5UhFM=.a87e5a87-d8da-45bd-a616-3d7b51f025a2@github.com>
 <tOBsRr4qwmkhRAU8lRYSr1SbNrg7545mQIPwhak4mdU=.0eb15843-ddfd-4058-a65e-1d609113bbaf@github.com>
Message-ID: <5rNZ4RB43P4t4l0u_Vz9AakFa6n_rbr9GGJ3elBQmD0=.f7d41bb6-adcc-42c6-9577-1ba07a00682c@github.com>

On Mon, 29 Sep 2025 16:43:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> According to the TLS specification, RFC 8446 section 5,
>> 
>> An implementation may receive an unencrypted record of type
>>    change_cipher_spec consisting of the single byte value 0x01 at any
>>    time after the first ClientHello message has been sent or received
>>    and before the peer's Finished message has been received and MUST
>>    simply drop it without further processing. Note that this record may
>>    appear at a point at the handshake where the implementation is
>>    expecting protected records, and so it is necessary to detect this
>>    condition prior to attempting to deprotect the record. An
>>    implementation which receives any other change_cipher_spec value or
>>    which receives a protected change_cipher_spec record MUST abort the
>>    handshake with an "unexpected_message" alert. If an implementation
>>    detects a change_cipher_spec record received before the first
>>    ClientHello message or after the peer's Finished message, it MUST be
>>    treated as an unexpected record type (though stateless servers may
>>    not be able to distinguish these cases from allowed cases).
>> 
>> 
>> However the TLS implementation ignores a CCS message received after the client's Finished, instead of sending an alert(fatal, unexpected_message) and aborting the connection.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by friedbyalice at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/27529#pullrequestreview-3317945400

From mdonovan at openjdk.org  Thu Oct  9 11:45:35 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 9 Oct 2025 11:45:35 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups [v4]
In-Reply-To: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
Message-ID: <T_v38G-SmAn7nq_3vthICQtGqJo674I-5nV3XNaL09c=.75a6d7c6-599e-4af0-b263-845972aeb96d@github.com>

> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.

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

 - changed title to 'Enabled Named Groups'
 - Merge branch 'master' into secsettings
 - I removed signature algorithms output because the information is created during TLS handshake
 - Merge branch 'master' into secsettings
 - removed unused import, updated tools/launcher/Settings.java test
 - Merge branch 'master' into secsettings
 - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24424/files
  - new: https://git.openjdk.org/jdk/pull/24424/files/1e21e080..a2182b9f

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

  Stats: 204412 lines in 2784 files changed: 154746 ins; 31954 del; 17712 mod
  Patch: https://git.openjdk.org/jdk/pull/24424.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24424/head:pull/24424

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

From mdonovan at openjdk.org  Thu Oct  9 11:49:19 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 9 Oct 2025 11:49:19 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v2]
In-Reply-To: <osmzSDvG9ftU7Ha53P0VNZIl29cH0YN3O8ToCsNd-0g=.3159d9c7-6505-416e-8ba6-39661ec7b942@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <osmzSDvG9ftU7Ha53P0VNZIl29cH0YN3O8ToCsNd-0g=.3159d9c7-6505-416e-8ba6-39661ec7b942@github.com>
Message-ID: <7zrw8Ap-KrTjfZnWSsVdSoEull2pnavxROnJthCoEbU=.7f07d25f-6d80-4088-857d-8954fd2ea4d8@github.com>

On Sun, 5 Oct 2025 12:27:24 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates with review comments

Can you add these new groups to `test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java`?

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

PR Comment: https://git.openjdk.org/jdk/pull/27614#issuecomment-3385498579

From mullan at openjdk.org  Thu Oct  9 13:08:31 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 9 Oct 2025 13:08:31 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups [v4]
In-Reply-To: <T_v38G-SmAn7nq_3vthICQtGqJo674I-5nV3XNaL09c=.75a6d7c6-599e-4af0-b263-845972aeb96d@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <T_v38G-SmAn7nq_3vthICQtGqJo674I-5nV3XNaL09c=.75a6d7c6-599e-4af0-b263-845972aeb96d@github.com>
Message-ID: <hf_7ri1ntuHwg8HLGrvai9VuNsLKmvjAD8qhzldCXps=.98cb1387-f949-441b-aec5-cd1bedf15525@github.com>

On Thu, 9 Oct 2025 11:45:35 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - changed title to 'Enabled Named Groups'
>  - Merge branch 'master' into secsettings
>  - I removed signature algorithms output because the information is created during TLS handshake
>  - Merge branch 'master' into secsettings
>  - removed unused import, updated tools/launcher/Settings.java test
>  - Merge branch 'master' into secsettings
>  - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24424#pullrequestreview-3318883788

From syan at openjdk.org  Thu Oct  9 13:12:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 Oct 2025 13:12:49 GMT
Subject: RFR: 8368982: Test sun/security/tools/jarsigner/EC.java completed
 and timed out
In-Reply-To: <sIQCKm-XGEghN_mfOHChULMIrWOgjCvEidb56SM6suM=.2a708c5e-45ed-41b6-bc81-78e5b60afed5@github.com>
References: <sIQCKm-XGEghN_mfOHChULMIrWOgjCvEidb56SM6suM=.2a708c5e-45ed-41b6-bc81-78e5b60afed5@github.com>
Message-ID: <1Zi9ufvPcRyqYb4-LTd_2WnHa8A_tJXpCejU84cjT9E=.c0cb457b-98ad-47aa-b283-6c39061887f6@github.com>

On Wed, 8 Oct 2025 15:21:13 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Increased a timeout from default 120. Each test runs 25 commands with 5 sec spent on each, so this made it likely that 120 would timeout. I think changing it to 300 would be a nice buffer.

test/jdk/sun/security/tools/jarsigner/EC.java line 29:

> 27:  * @summary enhance security tools to use ECC algorithm
> 28:  * @library /test/lib
> 29:  * @run main/timeout=300 EC

Do we need update the copyright year from 2020 to 2025

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27695#discussion_r2416746324

From syan at openjdk.org  Thu Oct  9 13:18:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 Oct 2025 13:18:16 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available [v2]
In-Reply-To: <d5FF92Ebi1hdBHo1D-I_IgtZAMkkibLyPesDQlJr_AA=.5341bdb2-5d11-4232-b92a-391d6c93a6f4@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
 <d5FF92Ebi1hdBHo1D-I_IgtZAMkkibLyPesDQlJr_AA=.5341bdb2-5d11-4232-b92a-391d6c93a6f4@github.com>
Message-ID: <hi67JEilm8EVaYIbaTFm21A-yA_j4U3pHecHYvMCIaM=.3288e401-8e72-495e-a75b-08f3c4c7eaf2@github.com>

On Thu, 9 Oct 2025 03:46:36 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/security/provider/acvp/Launcher.java
>   
>   Co-authored-by: Mikhail Yankelevich <mikhailyankelevich at gmail.com>

GHA report [macos-aarch64 / test (hs/tier1 runtime)](https://github.com/sendaoYan/jdk-ysd/actions/runs/18364827089/job/52316679074#logs) fails 'Failed to download resource "make"' during 'Install Dependencies', it seems like environmental issue or test infrastructure issue, unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27491#issuecomment-3385829878

From myankelevich at openjdk.org  Thu Oct  9 13:22:31 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 9 Oct 2025 13:22:31 GMT
Subject: RFR: 8368982: Test sun/security/tools/jarsigner/EC.java completed
 and timed out [v2]
In-Reply-To: <sIQCKm-XGEghN_mfOHChULMIrWOgjCvEidb56SM6suM=.2a708c5e-45ed-41b6-bc81-78e5b60afed5@github.com>
References: <sIQCKm-XGEghN_mfOHChULMIrWOgjCvEidb56SM6suM=.2a708c5e-45ed-41b6-bc81-78e5b60afed5@github.com>
Message-ID: <2t4aFYJt5stJGbYfTJAWfroOKyqZJzv9dR3XOixOnHA=.c636993a-9f22-4bd2-be56-3cf87f6bae07@github.com>

> Increased a timeout from default 120. Each test runs 25 commands with 5 sec spent on each, so this made it likely that 120 would timeout. I think changing it to 300 would be a nice buffer.

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

  copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27695/files
  - new: https://git.openjdk.org/jdk/pull/27695/files/5fc712f1..150c1bec

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

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

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

From myankelevich at openjdk.org  Thu Oct  9 13:22:34 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 9 Oct 2025 13:22:34 GMT
Subject: RFR: 8368982: Test sun/security/tools/jarsigner/EC.java completed
 and timed out [v2]
In-Reply-To: <1Zi9ufvPcRyqYb4-LTd_2WnHa8A_tJXpCejU84cjT9E=.c0cb457b-98ad-47aa-b283-6c39061887f6@github.com>
References: <sIQCKm-XGEghN_mfOHChULMIrWOgjCvEidb56SM6suM=.2a708c5e-45ed-41b6-bc81-78e5b60afed5@github.com>
 <1Zi9ufvPcRyqYb4-LTd_2WnHa8A_tJXpCejU84cjT9E=.c0cb457b-98ad-47aa-b283-6c39061887f6@github.com>
Message-ID: <KnF4PVOT-AzcVv9-vyRlONwKHrW4J3BONdYwMEDlOjo=.087906df-43a7-40bc-8a52-09a17f296883@github.com>

On Thu, 9 Oct 2025 13:09:39 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> test/jdk/sun/security/tools/jarsigner/EC.java line 29:
> 
>> 27:  * @summary enhance security tools to use ECC algorithm
>> 28:  * @library /test/lib
>> 29:  * @run main/timeout=300 EC
> 
> Do we need update the copyright year from 2020 to 2025

fixed, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27695#discussion_r2416774677

From mdonovan at openjdk.org  Thu Oct  9 13:23:22 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 9 Oct 2025 13:23:22 GMT
Subject: Integrated: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups
In-Reply-To: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
Message-ID: <m0q9yGqCmamg8W1EQOtgVVEiHVYLECb-612UBgRPT1E=.22dda342-355b-4001-adb8-96c65afbcefd@github.com>

On Thu, 3 Apr 2025 18:47:43 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read.

This pull request has now been integrated.

Changeset: 5bb9fed9
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5bb9fed9de3297639d5c0cd1d8046656d98863dd
Stats:     16 lines in 2 files changed: 14 ins; 0 del; 2 mod

8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups

Reviewed-by: mullan, coffeys

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

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

From abarashev at openjdk.org  Thu Oct  9 13:44:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 9 Oct 2025 13:44:52 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v4]
In-Reply-To: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
Message-ID: <vEreiAP8fNIo2j8nu_W8KU477s-topBxW17Gw5PxZF4=.c8f24ba3-8a19-470f-9499-210d493a52bf@github.com>

> If the NewSessionTicket message is lost, the handshake fails on the client side with:
> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Remove unneeded exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27677/files
  - new: https://git.openjdk.org/jdk/pull/27677/files/e6da9b06..b5740400

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

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

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

From abarashev at openjdk.org  Thu Oct  9 14:02:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 9 Oct 2025 14:02:46 GMT
Subject: Integrated: 8366244: TLS1.3 ChangeCipherSpec message received after
 the client's Finished message should trigger a connection abort with
 "unexpected message"
In-Reply-To: <L7cJZ-9ReOFAMB41aKSQ33_vjyVqntPhENHq5l5UhFM=.a87e5a87-d8da-45bd-a616-3d7b51f025a2@github.com>
References: <L7cJZ-9ReOFAMB41aKSQ33_vjyVqntPhENHq5l5UhFM=.a87e5a87-d8da-45bd-a616-3d7b51f025a2@github.com>
Message-ID: <woIuXLRL6ttILPV84sMwOaNbIgbLjxi53nNYsIyaMt4=.a5b095c1-612d-4f50-a19c-2cb653f2498a@github.com>

On Fri, 26 Sep 2025 15:38:20 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> According to the TLS specification, RFC 8446 section 5,
> 
> An implementation may receive an unencrypted record of type
>    change_cipher_spec consisting of the single byte value 0x01 at any
>    time after the first ClientHello message has been sent or received
>    and before the peer's Finished message has been received and MUST
>    simply drop it without further processing. Note that this record may
>    appear at a point at the handshake where the implementation is
>    expecting protected records, and so it is necessary to detect this
>    condition prior to attempting to deprotect the record. An
>    implementation which receives any other change_cipher_spec value or
>    which receives a protected change_cipher_spec record MUST abort the
>    handshake with an "unexpected_message" alert. If an implementation
>    detects a change_cipher_spec record received before the first
>    ClientHello message or after the peer's Finished message, it MUST be
>    treated as an unexpected record type (though stateless servers may
>    not be able to distinguish these cases from allowed cases).
> 
> 
> However the TLS implementation ignores a CCS message received after the client's Finished, instead of sending an alert(fatal, unexpected_message) and aborting the connection.

This pull request has now been integrated.

Changeset: 233d3a8d
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/233d3a8d43578af4eafd572cee3db0978d3d65a0
Stats:     135 lines in 2 files changed: 134 ins; 0 del; 1 mod

8366244: TLS1.3 ChangeCipherSpec message received after the client's Finished message should trigger a connection abort with "unexpected message"

Reviewed-by: hchao

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

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

From myankelevich at openjdk.org  Thu Oct  9 14:14:00 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 9 Oct 2025 14:14:00 GMT
Subject: RFR: 8360373:
 src/java.base/share/classes/sun/security/util/Debug.java implement negative
 testing
In-Reply-To: <vgf5MP4ZRpISQnEK0yeXu6aiIVwEBwUr54zuoQR11_I=.5c5970b3-2873-4d7a-9c43-f3884400cff1@github.com>
References: <ORFqOHCMSIMwf5Xq7b4DqNw2UAogbRLgIOgAQkBRRPU=.7adcfefe-42d7-4c88-9e0e-e52c7bb00338@github.com>
 <vgf5MP4ZRpISQnEK0yeXu6aiIVwEBwUr54zuoQR11_I=.5c5970b3-2873-4d7a-9c43-f3884400cff1@github.com>
Message-ID: <jVPOwlW7JNJUoO-Fwc4Ky8tNK0SWYSpcc5r9hq6BwVQ=.342dc139-03e5-48b5-b817-8f56f274268d@github.com>

On Thu, 9 Oct 2025 08:28:24 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Please consider my proposal to add some negative testing to the Debug.java. 
>> 
>> Adding a test, that will automatically convert current test cases into a broken parameters and expecting the successful execution, but without a debug result. This approach should keep the simplicity of adding new test cases, as this is happening automatically.
>
> test/jdk/sun/security/util/Debug/DebugOptions.java line 140:
> 
>> 138: 
>> 139:         final OutputAnalyzer outputAnalyzer = ProcessTools.executeTestJava(
>> 140:                 paramName + "NONSENSE" + nonsenseParam + "NONSENSE",
> 
> you're printing the test parms in the "Executing" statement at line 135 but then you're augmenting this value further in the executeTestJava method call. Is that intended ?

Thanks for spotting this! no, this is an error, it should have been printed in full. Changed in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26796#discussion_r2416944181

From mdonovan at openjdk.org  Thu Oct  9 14:15:01 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 9 Oct 2025 14:15:01 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <tONyFGC_X3OMRBlzhANlHJ2-Pvuy640QhXVseH32NYM=.3809e3a4-2369-4334-8556-ebf2b1a13f07@github.com>

On Wed, 8 Oct 2025 16:49:42 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 143:

> 141:         if (params.tag == DerValue.tag_Null) {
> 142:             if (params.length() != 0) {
> 143:                 throw new IOException("invalid NULL");

Can this exception message be more descriptive?

test/jdk/sun/security/x509/AlgorithmId/NullParams.java line 70:

> 68:         test("SHA3-384withRSA", true);
> 69:         test("SHA3-512withRSA", true);
> 70:         test("HmacSHA1", true);

Update the copyright year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2416949082
PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2416926253

From myankelevich at openjdk.org  Thu Oct  9 14:22:30 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 9 Oct 2025 14:22:30 GMT
Subject: RFR: 8360373:
 src/java.base/share/classes/sun/security/util/Debug.java implement negative
 testing [v2]
In-Reply-To: <ORFqOHCMSIMwf5Xq7b4DqNw2UAogbRLgIOgAQkBRRPU=.7adcfefe-42d7-4c88-9e0e-e52c7bb00338@github.com>
References: <ORFqOHCMSIMwf5Xq7b4DqNw2UAogbRLgIOgAQkBRRPU=.7adcfefe-42d7-4c88-9e0e-e52c7bb00338@github.com>
Message-ID: <0iXi56HMzuY4SjqLavAmCzwxHwt6KJguA6JOul2guDM=.c9d20483-263e-4819-b6ba-fd5f900dfca5@github.com>

> Please consider my proposal to add some negative testing to the Debug.java. 
> 
> Adding a test, that will automatically convert current test cases into a broken parameters and expecting the successful execution, but without a debug result. This approach should keep the simplicity of adding new test cases, as this is happening automatically.

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

  logging issue fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26796/files
  - new: https://git.openjdk.org/jdk/pull/26796/files/326685d7..95ed14d5

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

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

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

From weijun at openjdk.org  Thu Oct  9 14:23:25 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 9 Oct 2025 14:23:25 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available [v2]
In-Reply-To: <d5FF92Ebi1hdBHo1D-I_IgtZAMkkibLyPesDQlJr_AA=.5341bdb2-5d11-4232-b92a-391d6c93a6f4@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
 <d5FF92Ebi1hdBHo1D-I_IgtZAMkkibLyPesDQlJr_AA=.5341bdb2-5d11-4232-b92a-391d6c93a6f4@github.com>
Message-ID: <p0b-9lMVV3a4Gdbj4Fiyfqk_pbnWkSTPhvc7PYt79yI=.ee7d4f95-c237-41b8-9923-05d511699838@github.com>

On Thu, 9 Oct 2025 03:46:36 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/security/provider/acvp/Launcher.java
>   
>   Co-authored-by: Mikhail Yankelevich <mikhailyankelevich at gmail.com>

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27491#pullrequestreview-3319240279

From myankelevich at openjdk.org  Thu Oct  9 14:23:25 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 9 Oct 2025 14:23:25 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available [v2]
In-Reply-To: <d5FF92Ebi1hdBHo1D-I_IgtZAMkkibLyPesDQlJr_AA=.5341bdb2-5d11-4232-b92a-391d6c93a6f4@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
 <d5FF92Ebi1hdBHo1D-I_IgtZAMkkibLyPesDQlJr_AA=.5341bdb2-5d11-4232-b92a-391d6c93a6f4@github.com>
Message-ID: <6FyYNCEBzM4Ln79tY98fehRLTJtfKCOiYDEpDpfIv54=.c7606824-5119-4ad7-bcbe-3b43e5c5ca07@github.com>

On Thu, 9 Oct 2025 03:46:36 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/security/provider/acvp/Launcher.java
>   
>   Co-authored-by: Mikhail Yankelevich <mikhailyankelevich at gmail.com>

lgtm

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

PR Comment: https://git.openjdk.org/jdk/pull/27491#issuecomment-3386114530

From syan at openjdk.org  Thu Oct  9 14:30:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 Oct 2025 14:30:40 GMT
Subject: RFR: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available
In-Reply-To: <H4qY9_uRjjXF8Ikk4nZa-UVLRDVpXOpa0F9qtH_c44w=.6c4537f3-3b46-4c24-87e2-6dce16095af4@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
 <H4qY9_uRjjXF8Ikk4nZa-UVLRDVpXOpa0F9qtH_c44w=.6c4537f3-3b46-4c24-87e2-6dce16095af4@github.com>
Message-ID: <VIWM70CrjpT36lAEp4N4Q4_OQ0h1dylMpkGk9k5Zbww=.85a12791-796a-4653-b72e-9c1d21939cc5@github.com>

On Wed, 8 Oct 2025 11:41:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.
>
> This test is failing pretty consistently for us now. Any progress on this? :)

Thanks for the reviews @shipilev @wangweij @myankelev

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

PR Comment: https://git.openjdk.org/jdk/pull/27491#issuecomment-3386137660

From syan at openjdk.org  Thu Oct  9 14:30:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 9 Oct 2025 14:30:42 GMT
Subject: Integrated: 8368677: acvp test should throw SkippedException when no
 ACVP-Server available
In-Reply-To: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
References: <PhWyRZ6Wpct5HjyPNt4N6oRDXcnukyHXErimV6iJyQI=.79ac5719-1acd-4988-86ef-0d36e215089d@github.com>
Message-ID: <NS6kYIV7dLKg28qNthCIoX5InzdG7NqvgLT9t03GQd0=.ce85e212-a2e3-400c-b51f-4375efd56dc9@github.com>

On Thu, 25 Sep 2025 14:27:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Currently sun/security/provider/acvp/Launcher.java report fails "java.io.IOException: Cannot find the artifact ACVP-Server". This is not jvm bug cause this failure, so I think sun/security/provider/acvp/Launcher.java test should throw SkippedException when no ACVP-Server available.

This pull request has now been integrated.

Changeset: 13f460c3
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13f460c3958b3513f0e62851fa3588f30d75daa3
Stats:     10 lines in 1 file changed: 9 ins; 0 del; 1 mod

8368677: acvp test should throw SkippedException when no ACVP-Server available

Reviewed-by: weijun, shade

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

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

From coffeys at openjdk.org  Thu Oct  9 16:30:30 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 9 Oct 2025 16:30:30 GMT
Subject: RFR: 8360373:
 src/java.base/share/classes/sun/security/util/Debug.java implement negative
 testing [v2]
In-Reply-To: <0iXi56HMzuY4SjqLavAmCzwxHwt6KJguA6JOul2guDM=.c9d20483-263e-4819-b6ba-fd5f900dfca5@github.com>
References: <ORFqOHCMSIMwf5Xq7b4DqNw2UAogbRLgIOgAQkBRRPU=.7adcfefe-42d7-4c88-9e0e-e52c7bb00338@github.com>
 <0iXi56HMzuY4SjqLavAmCzwxHwt6KJguA6JOul2guDM=.c9d20483-263e-4819-b6ba-fd5f900dfca5@github.com>
Message-ID: <Ywupz99S8FddFvP1Pk--4O4sZRtiZM6wWGLSES9SX00=.4e4b1908-69d2-4763-8a69-c74989d92c61@github.com>

On Thu, 9 Oct 2025 14:22:30 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Please consider my proposal to add some negative testing to the Debug.java. 
>> 
>> Adding a test, that will automatically convert current test cases into a broken parameters and expecting the successful execution, but without a debug result. This approach should keep the simplicity of adding new test cases, as this is happening automatically.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   logging issue fix

Looks fine to me

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26796#pullrequestreview-3319747362

From duke at openjdk.org  Thu Oct  9 18:29:29 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 9 Oct 2025 18:29:29 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v2]
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <94yPEVDgAnOJR8rVw_eooSc-bUlTvfYoRWfUms1QNVo=.b6110316-2889-4c13-a728-a0aab1702fd5@github.com>

> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with two additional commits since the last revision:

 - 8367008: Algorithm identifiers for HmacSHA* should always have NULL as params
 - 8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27700/files
  - new: https://git.openjdk.org/jdk/pull/27700/files/e7fc886f..3213fe68

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

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

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

From mpowers at openjdk.org  Thu Oct  9 20:48:13 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 9 Oct 2025 20:48:13 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v3]
In-Reply-To: <rvK0WE0iDRlvZi4gyetBUmQvd5WiLw9cFBIHcARPAr4=.0027192f-4b2d-400a-b3ce-2d5a5c62ffab@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <oG840hSliwqHawwcaNtpXRp9cpGQWHb-X-4C3ZBNIyw=.280a7d48-4787-434a-9bf5-b85ddde150e5@github.com>
 <O6646LU9zRGOtRc8aAEATTk3EpmTdpeKAHjy_dQ1doI=.ab2e2e28-487f-4084-b535-e73ebd7bec33@github.com>
 <08SntfYhxrQjaVkIX90vYAp_0ZPHjdR9xPftipFYMK8=.8a19239a-3a0a-4260-8f4c-3c567ee1cf70@github.com>
 <rvK0WE0iDRlvZi4gyetBUmQvd5WiLw9cFBIHcARPAr4=.0027192f-4b2d-400a-b3ce-2d5a5c62ffab@github.com>
Message-ID: <pFWrq8hm1EJDWgjEADXiiAZPXpIl_5jFDrlOnapI-Ws=.ef0187b0-dc42-451e-9255-6e58ea59bb89@github.com>

On Tue, 7 Oct 2025 23:36:39 GMT, Thomas Fitzsimmons <fitzsim at openjdk.org> wrote:

>> After innumerable iterations, this encoding method will be removed from `PBMAC1Parameters`.
>> That said, keyLength now comes from the Mac before being encoded in `MacData`:
>> 
>> 
>> Mac m = Mac.getInstance(hmac);
>> int keyLength = m.getMacLength()*8;
>> 
>> If this doesn't work, we have some other serious issues.
>
> The `> 0` check is still there in MacData.getEncoded:
> 
> 
>         if (this.pbmac1Keystore) {
>         [...]
>             // encode derived key length
>             if (this.keyLength > 0) {
>                 pBKDF2_params.putInteger(this.keyLength / 8); // derived key length (in octets)
>             }
> 
> 
> How about making sure it is greater than zero in the constructor instead, something like:
> 
> 
> --- a/src/java.base/share/classes/sun/security/pkcs12/MacData.java
> +++ b/src/java.base/share/classes/sun/security/pkcs12/MacData.java
> @@ -122,6 +122,10 @@ class MacData {
>          }
>          if (algName.equals("PBMAC1")) {
>              this.pbmac1Keystore = true;
> +            if (keyLength <= 0) {
> +                throw new IllegalArgumentException("the keyLength " +
> +                        "parameter for PBMAC1 must be greater than 0");
> +            }
>          }
>          algid = AlgorithmId.get(algName);
>  
> @@ -333,9 +337,7 @@ byte[] getEncoded() throws NoSuchAlgorithmException, IOException {
>              pBKDF2_params.putInteger(this.iterations);
>  
>              // encode derived key length
> -            if (this.keyLength > 0) {
> -                pBKDF2_params.putInteger(this.keyLength / 8); // derived key length (in octets)
> -            }
> +            pBKDF2_params.putInteger(this.keyLength / 8); // derived key length (in octets)
>              pBKDF2_params.write(DerValue.tag_Sequence, kdfHmac);
>              tmp3.putOID(pkcs5PBKDF2_OID);
>              tmp3.write(DerValue.tag_Sequence, pBKDF2_params);
> 
> 
> Should `keyLength` also be initialized in the `MacData(DerInputStream derin)` constructor?

This code has changed a lot recently. I agree that the `> 0` check allows the `keyLength` field to be omitted - in violation of the spec. I will soon push code without the ` > 0` check and`keyLength / 8` operation. `keyLength` will be set to `Mac.getMacLength()`.

To answer your second question about `MacData(DerInputStream derin)`, the `keyLength` will be set to the value in the input stream. An exception will be thrown by `MacData` if `keyLength` is not present in the input stream.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2417918527

From mpowers at openjdk.org  Thu Oct  9 20:48:15 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 9 Oct 2025 20:48:15 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v7]
In-Reply-To: <Ghy1IUEnuYw6y2_ZhVdrVB4uraDHA9i9b2ksW80h79M=.9e84337e-c970-4b1b-af14-af73e7dda7e4@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <Wlfzh3j_8gt3FJ6R8U4q4QBBp56zm6t71f4Lo_VnwA0=.7ae9adde-c0bd-4696-93e7-8526473969e1@github.com>
 <f_xk4a63SFRycVJ0ZdxNj32ikHm4xx9pu7iyYYw3bI0=.c9fc1096-48b9-4684-8a96-f85ca3d7eb2f@github.com>
 <Ghy1IUEnuYw6y2_ZhVdrVB4uraDHA9i9b2ksW80h79M=.9e84337e-c970-4b1b-af14-af73e7dda7e4@github.com>
Message-ID: <FGFPGE5POgqui0c0uDy3Fx6jIWmnziRgGg12bIac3kM=.7dd3a4b9-04e2-4847-ad33-5216da109e47@github.com>

On Wed, 24 Sep 2025 02:48:42 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1964:
>> 
>>> 1962:                     ((PBEParameterSpec)params).getIterationCount(),
>>> 1963:                     kdfHmac.equals("HmacSHA512") ? 64*8 : 32*8));
>>> 1964:             Mac m = Mac.getInstance(kdfHmac);
>> 
>> `kdfHmac` is used as `prfHmac` here. If you intend to only support them being the same, please error out as early as possible when parsing PBMAC1-params. You might be able to support them at loading but still lack enough info at storing.
>
> An exception is now thrown in `MacData` when reading.

They can now be different when loading a keystore. My comment about an exception being thrown is no longer valid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2417921148

From weijun at openjdk.org  Fri Oct 10 02:30:03 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 10 Oct 2025 02:30:03 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v2]
In-Reply-To: <94yPEVDgAnOJR8rVw_eooSc-bUlTvfYoRWfUms1QNVo=.b6110316-2889-4c13-a728-a0aab1702fd5@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <94yPEVDgAnOJR8rVw_eooSc-bUlTvfYoRWfUms1QNVo=.b6110316-2889-4c13-a728-a0aab1702fd5@github.com>
Message-ID: <gbQjUkxfNo08WBeXpgdqvzDtHGes9z7prfNH5uCtCFA=.07c1d8ce-307d-4293-91b8-b30218adf06a@github.com>

On Thu, 9 Oct 2025 18:29:29 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8367008: Algorithm identifiers for HmacSHA* should always have NULL as params
>  - 8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 690:

> 688:             ObjectIdentifier.of(KnownOIDs.HmacSHA256),
> 689:             ObjectIdentifier.of(KnownOIDs.HmacSHA384),
> 690:             ObjectIdentifier.of(KnownOIDs.HmacSHA512)

The "HMAC algorithm identifiers" section of https://www.rfc-editor.org/rfc/rfc9879.html#name-asn1-module also includes algid-hmacWithSHA512-224 and algid-hmacWithSHA512-256.

Also, I have always been wondering how SHA3 Hmac `AlgorithmId` are encoded. https://datatracker.ietf.org/doc/html/rfc9688#name-signature-algorithms says "the parameters field MUST be absent". Although I'm not sure if this is only in CMS, but I think it's worth adding a reference here explaining why those OIDs are not included.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2418356050

From myankelevich at openjdk.org  Fri Oct 10 06:58:14 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 10 Oct 2025 06:58:14 GMT
Subject: RFR: 8360373:
 src/java.base/share/classes/sun/security/util/Debug.java implement negative
 testing [v2]
In-Reply-To: <Ywupz99S8FddFvP1Pk--4O4sZRtiZM6wWGLSES9SX00=.4e4b1908-69d2-4763-8a69-c74989d92c61@github.com>
References: <ORFqOHCMSIMwf5Xq7b4DqNw2UAogbRLgIOgAQkBRRPU=.7adcfefe-42d7-4c88-9e0e-e52c7bb00338@github.com>
 <0iXi56HMzuY4SjqLavAmCzwxHwt6KJguA6JOul2guDM=.c9d20483-263e-4819-b6ba-fd5f900dfca5@github.com>
 <Ywupz99S8FddFvP1Pk--4O4sZRtiZM6wWGLSES9SX00=.4e4b1908-69d2-4763-8a69-c74989d92c61@github.com>
Message-ID: <r-39iutJ7JoKTfUS1sz2ze0n9tc4lp7-uUeVU2QVGsc=.435e80ac-6edb-46cc-a5b1-4bbfe0386910@github.com>

On Thu, 9 Oct 2025 16:27:47 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   logging issue fix
>
> Looks fine to me

@coffeys thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26796#issuecomment-3388541449

From myankelevich at openjdk.org  Fri Oct 10 06:58:15 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 10 Oct 2025 06:58:15 GMT
Subject: Integrated: 8360373:
 src/java.base/share/classes/sun/security/util/Debug.java implement negative
 testing
In-Reply-To: <ORFqOHCMSIMwf5Xq7b4DqNw2UAogbRLgIOgAQkBRRPU=.7adcfefe-42d7-4c88-9e0e-e52c7bb00338@github.com>
References: <ORFqOHCMSIMwf5Xq7b4DqNw2UAogbRLgIOgAQkBRRPU=.7adcfefe-42d7-4c88-9e0e-e52c7bb00338@github.com>
Message-ID: <K7KC_71af12vtlvtzg2W-yuVkbDPmVESXp-MBp8BSdg=.151d988d-0236-49a1-897d-089a62371775@github.com>

On Fri, 15 Aug 2025 10:41:40 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Please consider my proposal to add some negative testing to the Debug.java. 
> 
> Adding a test, that will automatically convert current test cases into a broken parameters and expecting the successful execution, but without a debug result. This approach should keep the simplicity of adding new test cases, as this is happening automatically.

This pull request has now been integrated.

Changeset: b6e5ef4a
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6e5ef4ad0989d3bf0c579dbd6f5bf36b52e41e2
Stats:     74 lines in 1 file changed: 74 ins; 0 del; 0 mod

8360373: src/java.base/share/classes/sun/security/util/Debug.java implement negative testing

Reviewed-by: coffeys

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

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

From hchao at openjdk.org  Fri Oct 10 07:04:19 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 10 Oct 2025 07:04:19 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores
In-Reply-To: <P9c5IM615DIjJpw6CN2FpFT3Z4aLiuNzGDaTgxIwLWk=.9c03ccf4-8af6-4b3c-9f81-355d2015fb60@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <P9c5IM615DIjJpw6CN2FpFT3Z4aLiuNzGDaTgxIwLWk=.9c03ccf4-8af6-4b3c-9f81-355d2015fb60@github.com>
Message-ID: <qqpjcPdI7BGgwnwvA454dU_-jG8KzrytYTqjrpi3pag=.1a9affc6-744f-485c-91e8-950f689b44c8@github.com>

On Mon, 6 Oct 2025 12:27:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This PR improves security warning when using JKS or JCEKS keystores.
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 244:
> 
>> 242:     private boolean allAliasesFound = true;
>> 243:     private boolean hasMultipleManifests = false;
>> 244:     private boolean outdatedFormat = false;
> 
> Suggest calling this variable "weakKeyStore".

Done.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 2419:
> 
>> 2417:                     outdatedFormat = true;
>> 2418:                 }
>> 2419:             }
> 
> I don't think you need the `realStoreType` field. If you move this check to the end of the `else` block starting on line 2424 (which means the keystore is a file), and just check the `KeyStore.type()` I think it should be sufficient, ex:
> 
> 
> if (store.getType().equalsIgnoreCase("JKS")
>         || store.getType().equalsIgnoreCase("JCEKS")) {
>     weakKeyStore = true;
> }

Done.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 225:
> 
>> 223: signature.verification.failed.on.entry.1.when.reading.via.jarinputstream=Signature verification failed on entry %s when reading via JarInputStream
>> 224: signature.verification.failed.on.entry.1.when.reading.via.jarfile=Signature verification failed on entry %s when reading via JarFile
>> 225: outdated.storetype.warning=%1$s uses outdated cryptographic algorithms and will be removed in a future release. Migrate to PKCS12 using:\n\
> 
> Call this "jks.storetype.warning" so it is consistent with `keytool.properties`.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2418702964
PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2418703223
PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2418702879

From hchao at openjdk.org  Fri Oct 10 07:08:03 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 10 Oct 2025 07:08:03 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores
In-Reply-To: <P9c5IM615DIjJpw6CN2FpFT3Z4aLiuNzGDaTgxIwLWk=.9c03ccf4-8af6-4b3c-9f81-355d2015fb60@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <P9c5IM615DIjJpw6CN2FpFT3Z4aLiuNzGDaTgxIwLWk=.9c03ccf4-8af6-4b3c-9f81-355d2015fb60@github.com>
Message-ID: <jagw8De91xzsP7CTyuPVz0V2BV32fGhrodmnPMRza5Y=.82194756-809d-4c07-a9c2-bd1da41486df@github.com>

On Mon, 6 Oct 2025 12:35:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This PR improves security warning when using JKS or JCEKS keystores.
>
> src/java.base/share/classes/java/security/KeyStore.java line 832:
> 
>> 830:     }
>> 831: 
>> 832:     private static void outdatedKeyStoreLog(String type) {
> 
> I think it would be simpler to include this warning in the constructor of `sun.security.provider.JavaKeyStore`. Then you don't need to call this method.

Moved the warning to `engineLoad()` in `JceKeyStore` and `JavaKeyStore`, instead of in their constructors. Otherwise, we may get false positive warnings from KeyStore.getInstance() when it goes thru the list of providers to probe for the right keystore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2418709706

From hchao at openjdk.org  Fri Oct 10 07:20:20 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 10 Oct 2025 07:20:20 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v2]
In-Reply-To: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
Message-ID: <T82JcGsvUqdnw3wQ9I4cnb1SUS3jXOOQ_B8-_y53IeQ=.45fcacaf-7e3b-4406-98f5-aa8370b376fb@github.com>

> This PR improves security warning when using JKS or JCEKS keystores.

Hai-May Chao has updated the pull request incrementally with four additional commits since the last revision:

 - Updates with review comments
 - Updates with review comments
 - Revert changes to KeyStore.java
 - Remove test TestOutdatedKeyStore.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27624/files
  - new: https://git.openjdk.org/jdk/pull/27624/files/560d4163..452e5cda

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

  Stats: 291 lines in 7 files changed: 73 ins; 186 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/27624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27624/head:pull/27624

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

From hchao at openjdk.org  Fri Oct 10 07:20:22 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 10 Oct 2025 07:20:22 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v2]
In-Reply-To: <P9c5IM615DIjJpw6CN2FpFT3Z4aLiuNzGDaTgxIwLWk=.9c03ccf4-8af6-4b3c-9f81-355d2015fb60@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <P9c5IM615DIjJpw6CN2FpFT3Z4aLiuNzGDaTgxIwLWk=.9c03ccf4-8af6-4b3c-9f81-355d2015fb60@github.com>
Message-ID: <64dm1hE2BdW2bO_X5w551a8_ffEkP2lvrGA6dzX5yuA=.a28edb1d-7b8a-47f2-9b05-54706ac7fefc@github.com>

On Mon, 6 Oct 2025 12:33:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Updates with review comments
>>  - Updates with review comments
>>  - Revert changes to KeyStore.java
>>  - Remove test TestOutdatedKeyStore.java
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1490:
> 
>> 1488:             warnings.add(String.format(rb.getString(
>> 1489:                     "outdated.storetype.warning"),
>> 1490:                     realStoreType, keystore));
> 
> You can pass `store.getType()` instead of `realStoreType` here.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2418728178

From djelinski at openjdk.org  Fri Oct 10 13:02:38 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 10 Oct 2025 13:02:38 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v4]
In-Reply-To: <vEreiAP8fNIo2j8nu_W8KU477s-topBxW17Gw5PxZF4=.c8f24ba3-8a19-470f-9499-210d493a52bf@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <vEreiAP8fNIo2j8nu_W8KU477s-topBxW17Gw5PxZF4=.c8f24ba3-8a19-470f-9499-210d493a52bf@github.com>
Message-ID: <1A02_rglQcRLxnVlMgPljb58AUSjI2IvGvJ3k1orUIA=.0840bd3d-bcbf-4b07-9e27-39254275e54c@github.com>

On Thu, 9 Oct 2025 13:44:52 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> If the NewSessionTicket message is lost, the handshake fails on the client side with:
>> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded exception

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27677#pullrequestreview-3323295524

From mullan at openjdk.org  Fri Oct 10 14:21:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 10 Oct 2025 14:21:58 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v2]
In-Reply-To: <T82JcGsvUqdnw3wQ9I4cnb1SUS3jXOOQ_B8-_y53IeQ=.45fcacaf-7e3b-4406-98f5-aa8370b376fb@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <T82JcGsvUqdnw3wQ9I4cnb1SUS3jXOOQ_B8-_y53IeQ=.45fcacaf-7e3b-4406-98f5-aa8370b376fb@github.com>
Message-ID: <k3xOsGy4xCKxbn8AKaNiVzUwVul95IJxn-nzANCD_xU=.3de5eda3-65cf-4c43-a2d2-28e87ebdc918@github.com>

On Fri, 10 Oct 2025 07:20:20 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This PR improves security warning when using JKS or JCEKS keystores.
>
> Hai-May Chao has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Updates with review comments
>  - Updates with review comments
>  - Revert changes to KeyStore.java
>  - Remove test TestOutdatedKeyStore.java

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 2432:

> 2430:                         }
> 2431:                     }
> 2432:                     if (store.getType().equalsIgnoreCase("JKS")

We should put in the same logic here as in `keytool` to check if the real storetype is JKS or JCEKS. See https://github.com/openjdk/jdk/blob/f6d77cb33299ae0636a2b52ee752f27e9ea9191b/src/java.base/share/classes/sun/security/tools/keytool/Main.java#L1392

test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8217375 8260286 8267319 8353749

This is not specifically testing this issue, so I don't think you should include the bugid.

test/jdk/sun/security/tools/jarsigner/warnings/Test.java line 1:

> 1: /*

I think you should create a new test which is a subclass of this Test which checks that JKS and JCEKS produce the proper warnings when using jarsigner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2420484696
PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2420255919
PR Review Comment: https://git.openjdk.org/jdk/pull/27624#discussion_r2420295556

From weijun at openjdk.org  Fri Oct 10 15:33:35 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 10 Oct 2025 15:33:35 GMT
Subject: RFR: 8353749: Improve security warning when using JKS or JCEKS
 keystores [v2]
In-Reply-To: <T82JcGsvUqdnw3wQ9I4cnb1SUS3jXOOQ_B8-_y53IeQ=.45fcacaf-7e3b-4406-98f5-aa8370b376fb@github.com>
References: <0hDHwS_-eQ6AEZf1_xjSP-DhscTExpbdHMSzoY3Xx8o=.ddc0c692-a356-446b-b6c5-adbdaa0499fe@github.com>
 <T82JcGsvUqdnw3wQ9I4cnb1SUS3jXOOQ_B8-_y53IeQ=.45fcacaf-7e3b-4406-98f5-aa8370b376fb@github.com>
Message-ID: <w_iuX7NFa2fGfuKT7C15twDpNL_101nScNj4KX2J1fw=.d67b62ea-6011-4f66-88ea-444eda2f870f@github.com>

On Fri, 10 Oct 2025 07:20:20 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> This PR improves security warning when using JKS or JCEKS keystores.
>
> Hai-May Chao has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Updates with review comments
>  - Updates with review comments
>  - Revert changes to KeyStore.java
>  - Remove test TestOutdatedKeyStore.java

Do we need to add a warning at `store`? For example, someone `getInstance("JKS")` and `load(null, null)`, and finally `store` it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27624#issuecomment-3390788804

From ascarpino at openjdk.org  Fri Oct 10 16:35:57 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 10 Oct 2025 16:35:57 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <M4ZBrtG-QdsCAsmPecRmsTU6arjbkrKxT5NuK_TXuhY=.9d66b840-5be9-4a80-976d-de9fe6fff79b@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <M4ZBrtG-QdsCAsmPecRmsTU6arjbkrKxT5NuK_TXuhY=.9d66b840-5be9-4a80-976d-de9fe6fff79b@github.com>
Message-ID: <YawNmD3JifD542wr8AD3cfxrKIQIyY8kTfnd1nPHEp8=.84d4439d-d877-4447-a3cd-997a972cbfd7@github.com>

On Fri, 3 Oct 2025 12:56:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed some decoder comments
>
> src/java.base/share/classes/java/security/PEM.java line 61:
> 
>> 59:  * Common {@code type} values include, but are not limited to:
>> 60:  * CERTIFICATE, CERTIFICATE REQUEST, ATTRIBUTE CERTIFICATE, X509 CRL, PKCS7,
>> 61:  * CMS, PRIVATE KEY, ENCRYPTED PRIVATE KEY, RSA PRIVATE KEY, or PUBLIC KEY.
> 
> s/RSA PRIVATE KEY/PRIVATE KEY/

"PRIVATE KEY" is earlier in the list and "RSA PRIVATE KEY" is a valid type.

> src/java.base/share/classes/java/security/PEM.java line 88:
> 
>> 86: 
>> 87:     /**
>> 88:      * Creates a {@code PEM} instance with the given parameters.
> 
> s/the given/the specified/
> 
> In the other ctor, you say what the parameters are, so you should do the same here.

I'll just remove the other constructor description as it's not necessary to repeat what `@params` already documents.

> src/java.base/share/classes/java/security/PEM.java line 131:
> 
>> 129:     /**
>> 130:      * Returns the type and Base64 encoding in PEM textual format.
>> 131:      * {@code leadingData} is not returned by this method.
> 
> Suggest rewording as "leadingData is not included in the PEM data returned by this method."

I prefer the conciseness of the sentence as it is only clarifying the previous sentence.

> src/java.base/share/classes/java/security/PEM.java line 139:
> 
>> 137: 
>> 138:     /**
>> 139:      * Returns a Base64 decoded byte array of {@code content}.
> 
> Suggest stating that each invocation of this method returns a new byte array, as it isn't clear.

I changed it to "a new decoded ..." as that should suggest it's a new byte array.  Also this is a `record` so any value not defined in the class description has to be new.

> src/java.base/share/classes/java/security/PEM.java line 144:
> 
>> 142:      * @throws IllegalArgumentException on a decoding error
>> 143:      *
>> 144:      * @see Base64#getMimeDecoder()
> 
> Suggest you also add a sentence that states this method uses the using the MIME type base64 decoding scheme, otherwise the `@see` doesn't have much context.

reworded

> src/java.base/share/classes/java/security/PEMDecoder.java line 1:
> 
>> 1: /*
> 
> Line 492: "Any errors using the {@code Provider} will occur during decoding."
> 
> What does that mean? Does it mean they are thrown by this method? If so, it should be declared as an exception.
> 
> Also: 495: s/to/with/
> 496: put code around null

They occur during decoding.

> src/java.base/share/classes/java/security/PEMDecoder.java line 135:
> 
>> 133:  * {@code X.509 CERTIFICATE}, {@code CRL}, and {@code RSA PRIVATE KEY}.
>> 134:  *
>> 135:  * @see PEMEncoder
> 
> line 126, I think the "." should be on this line.

I don't understand this comment, but the paragraph was changed so it may not be applicable.

> src/java.base/share/classes/java/security/PEMDecoder.java line 374:
> 
>> 372:      * the PEM footer or the end of the stream. If an I/O error occurs,
>> 373:      * the read position in the stream may become inconsistent.
>> 374:      * It is recommended to perform no further decoding operations
> 
> First sentence (line 367), change to: "Decodes and returns a DEREncodable of the specified class for the specified InputStream."
> 
> 368: s/extend/extend or implement/

The second comment conflicts with a previous comment by Weijun.  That part of the sentence was removed.

> src/java.base/share/classes/java/security/PEMDecoder.java line 391:
> 
>> 389:      *   {@code DEREncodable}.
>> 390:      * @return a {@code DEREncodable} typecast to {@code tClass}
>> 391:      * @throws IOException on IO or PEM syntax error where the
> 
> Why would bad PEM syntax be an IOE? Should this be an IAE, similar to a decoding error?

This was a @wangweij comment from the first preview that syntax error are not recoverable and should be IOE.

> src/java.base/share/classes/java/security/PEMDecoder.java line 393:
> 
>> 391:      * @throws IOException on IO or PEM syntax error where the
>> 392:      * {@code InputStream} did not complete decoding.
>> 393:      * @throws EOFException at the end of the {@code InputStream}
> 
> How about: "if the end of the input stream has been reached unexpectedly"

I needed to rework the description anyway

> src/java.base/share/classes/java/security/PEMDecoder.java line 394:
> 
>> 392:      * {@code InputStream} did not complete decoding.
>> 393:      * @throws EOFException at the end of the {@code InputStream}
>> 394:      * @throws IllegalArgumentException on error with arguments or in decoding
> 
> Can you be more specific here? What does "on error with arguments" mean? What type of decoding issues result in IAE?

I'm removing that change, it's unclear to me what I was trying to clarify.

> src/java.base/share/classes/java/security/PEMEncoder.java line 1:
> 
>> 1: /*
> 
> For withEncryption, suggest changing the first sentence to better match `PEMDecoder.withEncryption` which reads better to me. So suggest:
> 
> "Returns a copy of this PEMEncoder that encrypts and encodes private keys using the specified password and default encryption algorithm."

Since PEMEncoder can encrypt 3 classes, it cannot follow your suggestion exactly.  I think saying "... encrypts and encodes using the specified password ..." sets up the second paragraph that states what can be encrypted.

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 398:
> 
>> 396:      *
>> 397:      * @param de the {@code DEREncodable} to be encrypted. Usage
>> 398:      *            limited to {@link PrivateKey}, {@link KeyPair}, and
> 
> "Usage limited" sounds odd. Maybe "The supported `DEREncodable types are ... An IllegalArgumentException is thrown for any other type."

I updated the supported types, but left the IAE to the @throws section.

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 402:
> 
>> 400:      * @param password the password used in the PBE encryption.  This array
>> 401:      *                 will be cloned before being used.
>> 402:      * @return an {@code EncryptedPrivateKeyInfo}
> 
> Next line: 
> 
> "@throws IllegalArgumentException on initialization errors based on the
> arguments passed to the method"
> 
> What does this mean - you need to be more specific about what are the error cases. Otherwise it will not be helpful for TCK test writers on how to test this.

I put more detail in IAE

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 565:
> 
>> 563:      */
>> 564:     @PreviewFeature(feature = PreviewFeature.Feature.PEM_API)
>> 565:     public KeyPair getKeyPair(char[] password) throws GeneralSecurityException {
> 
> This should specifically throw an `InvalidKeyException` if decryption fails. I think you want to specify the exact subclasses when it is clearly the right behavior. In this case, the method should always throw `InvalidKeyException` on decryption errors.
> 
> Also why generalize it to throw `GeneralSecurityException`? This should throw the same exceptions as `getKeySpec(Key, Provider)` since the params are the same.

Sure, not specifying InvalidKeyException for non-KeyPair return cases in the javadoc is an oversight.  Underneath the code, the `InvalidKeyException` and `NoSuchAlgorithmException` were always thrown, it's the method signature that is different.  Documenting `getKeyPair()` that NSAE and IKE are thrown.  Essentially, I'd replace `@throws GeneralSecurityException ...` with `@throws InvalidKeyException ...`.

I think it is user-friendly to have GSE  on the method signature. Specifying `NoSuchAlgorithmException` in the method signature I don't think offers value and is purely informative. Since the algorithm is determined by the encoding and cannot be influenced by either getKeyPair method.

`getKeySpec()` has generalized its exception handling by wrapping `IllegalBlockSizeException` and `BadPaddingException` into `InvalidKeyException`.  The `getKeySpecImpl()` method that all the`getKeySpec()` methods call, wrap `GeneralSecurityException` and `IOException` into `InvalidKeyException`.

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 585:
> 
>> 583:      * @param decryptKey the decryption key and cannot be {@code null}
>> 584:      * @param provider the {@code Provider} used for Cipher decryption and
>> 585:      *                 key generation. A {@code null} value will
> 
> Why do you allow null? This is inconsistent with the other methods that take Provider arguments. I think consistency is important.

This behavior is consistent with getKey() and encryptKey(). It allows the user to use a Key without specifying a provider. Otherwise, I would need to add a third method, getKeyPair(Key).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2402621237
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2408968998
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2408981945
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2408995855
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2411543503
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2411550342
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2411981646
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2412072575
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2412222361
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2412237603
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2412400535
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2412457945
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2417744866
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2417890681
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2415573556
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2418306533

From ascarpino at openjdk.org  Fri Oct 10 16:36:04 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 10 Oct 2025 16:36:04 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <fxc_LSu8Pw8ymUXp41QcrNT0rrMnkOZPP7k_cs8XYdI=.09153ff1-8e2c-4755-89a8-26a534d11b13@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <nso7dDgb79zORCUBiKe1cbtfEbTg0s8n_EKeSUUCLd4=.91071a41-e78a-442a-8bdf-24cf858a6b03@github.com>
 <fxc_LSu8Pw8ymUXp41QcrNT0rrMnkOZPP7k_cs8XYdI=.09153ff1-8e2c-4755-89a8-26a534d11b13@github.com>
Message-ID: <ZXpgIZWO5KaHxwv0T58M3Vk1BJdealvNKCJ93pep9D8=.718abc10-e4ef-4060-823c-c39efd692bf0@github.com>

On Fri, 3 Oct 2025 20:25:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 413:
>> 
>>> 411:      * {@code AlgorithmParameterSpec} are the provider's algorithm defaults.
>>> 412:      *
>>> 413:      * @since 25
>> 
>> Throwing a RuntimeException on encryption error is too general.
>
> On NPE, there is no `key` param.

Ok, I can reword RuntimeException somewhat, but it really is summed up by `Cipher.doFinal()` throwing an error, so an actual "encryption error".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2417376649

From ascarpino at openjdk.org  Fri Oct 10 16:36:01 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 10 Oct 2025 16:36:01 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <j7mcC0LYDigWC8xays2YETA96yfGKZMBtY_xxbJ_5t4=.1c71e850-38a6-4a08-b1cd-0b1350d60bd7@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <j7mcC0LYDigWC8xays2YETA96yfGKZMBtY_xxbJ_5t4=.1c71e850-38a6-4a08-b1cd-0b1350d60bd7@github.com>
Message-ID: <bNkdGr2oDRcndoC3PDcn3PC1hZWRuft6QNUe60l8piE=.ea3e224b-71a1-4735-b254-94b44271fcb3@github.com>

On Wed, 1 Oct 2025 20:13:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed some decoder comments
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 374:
> 
>> 372:      * the PEM footer or the end of the stream. If an I/O error occurs,
>> 373:      * the read position in the stream may become inconsistent.
>> 374:      * It is recommended to perform no further decoding operations
> 
> Three lines above. Is it better to say "until the end of the first PEM footer"? Same with the other decode-from-stream method.

"first" sounds awkward to me, I can change it to "a PEM footer".

> src/java.base/share/classes/java/security/PEMEncoder.java line 69:
> 
>> 67:  * {@link KeyPair} objects passed to the {@code encode} or
>> 68:  * {@code encodeToString} methods are encoded as a
>> 69:  * OneAsymmetricKey structure using the "PRIVATE KEY" type.
> 
> Should "OneAsymmetricKey" be fixed-width `OneAsymmetricKey`? Also, 4 lines above here.

I think it would be confusing to have @code around it or other monospaced font when there is no class with that name.  If that were the case, then PKCS #8 and ASN.1 would need it to and I think it would become harder to read with all the font changes.

> src/java.base/share/classes/java/security/PEMEncoder.java line 95:
> 
>> 93:  *  <li>{@code PKCS8EncodedKeySpec} (if configured with encryption) :
>> 94:  *  ENCRYPTED PRIVATE KEY</li>
>> 95:  *  <li>{@code PEM} : {@code PEM.type()}</li>
> 
> `X509EncodedKeySpec` missing.

line 91?

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 1:
> 
>> 1: /*
> 
> Since you added `getKey` and `getKeyPair` with a password argument, can we also add a `getKeySpec` with the same argument to be consistent?
> 
> Also, if you add this method, can it be used instead of `Pem.decryptEncoding`? That method is called inside EPKI and it creates another EPKI which looks wasteful and dangerously recursive.

Hmm..  I had not planned to add any to getKeySpec as I view that as legacy.  We can consider that in a future update.

I can probably change the internal method to take the `this` instead.

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 459:
> 
>> 457:     public static EncryptedPrivateKeyInfo encryptKey(DEREncodable de,
>> 458:         Key encryptKey, String algorithm, AlgorithmParameterSpec params,
>> 459:         Provider provider, SecureRandom random) {
> 
> Technically, must `encryptKey` be a PBE key? Can it be any key? I notice that PBE is not mentioned in `getKey`.

No, I should clean that up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2411999544
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2412463817
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2396287482
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2414636177
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2417915297

From ascarpino at openjdk.org  Fri Oct 10 16:36:03 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 10 Oct 2025 16:36:03 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <FpjV0TCxbO_scW1i0VMc1GSjJvBB4GosgtWE63l3CEE=.70e611e1-8719-4c96-8dc4-05746c0ed31d@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <j7mcC0LYDigWC8xays2YETA96yfGKZMBtY_xxbJ_5t4=.1c71e850-38a6-4a08-b1cd-0b1350d60bd7@github.com>
 <ZBj_bazRX5r3eYcR6JR6bbp_oYqTdcfSzVkKkh6-Vts=.829810f4-1f68-448b-b129-464dcd40407d@github.com>
 <FpjV0TCxbO_scW1i0VMc1GSjJvBB4GosgtWE63l3CEE=.70e611e1-8719-4c96-8dc4-05746c0ed31d@github.com>
Message-ID: <Xpl_rpFYZxiILkcNubdyDOYNQqrVk6MIFz8W4CrsJ8g=.bf8e6ff5-c696-40c2-8d1d-dd765d5dcec9@github.com>

On Wed, 1 Oct 2025 18:48:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I cannot comment on the `@param provider` line. Shall we change "the Provider will be used" to "the Provider used"? This is consistent with `getKeyPair`.
>
> I also cannot comment on the `@throws NullPointerException` line. How about changing ". If" there to ", or if"? This appears in other methods as well.
> 
> Also, for other places when an NPE is thrown, sometimes you use "when the key or password is null", sometimes it's "if the key or password are null". Please use the same wording.

yes, I'll rework the NPE

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2417281599

From duke at openjdk.org  Fri Oct 10 20:16:46 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 10 Oct 2025 20:16:46 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v3]
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <LGTbkcr2j79C6NNm3U4BcbAQcoRfPMWdAZ9NO1uuzpg=.c3980651-16b9-46f4-a0b7-93d164230275@github.com>

> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.

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

  8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27700/files
  - new: https://git.openjdk.org/jdk/pull/27700/files/3213fe68..ece6dbba

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

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

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

From duke at openjdk.org  Fri Oct 10 20:20:03 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 10 Oct 2025 20:20:03 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v2]
In-Reply-To: <gbQjUkxfNo08WBeXpgdqvzDtHGes9z7prfNH5uCtCFA=.07c1d8ce-307d-4293-91b8-b30218adf06a@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <94yPEVDgAnOJR8rVw_eooSc-bUlTvfYoRWfUms1QNVo=.b6110316-2889-4c13-a728-a0aab1702fd5@github.com>
 <gbQjUkxfNo08WBeXpgdqvzDtHGes9z7prfNH5uCtCFA=.07c1d8ce-307d-4293-91b8-b30218adf06a@github.com>
Message-ID: <Yj5xiJznxkI3GkhMT_3xIC_-2JUnpMuzK5ILW5LfG18=.eafc7ad9-9b91-42bb-97b6-1ccf501a3309@github.com>

On Fri, 10 Oct 2025 02:27:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8367008: Algorithm identifiers for HmacSHA* should always have NULL as params
>>  - 8367008: Algorithm identifiers for HmacSHA* should always have NULL as params
>
> src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 690:
> 
>> 688:             ObjectIdentifier.of(KnownOIDs.HmacSHA256),
>> 689:             ObjectIdentifier.of(KnownOIDs.HmacSHA384),
>> 690:             ObjectIdentifier.of(KnownOIDs.HmacSHA512)
> 
> The "HMAC algorithm identifiers" section of https://www.rfc-editor.org/rfc/rfc9879.html#name-asn1-module also includes algid-hmacWithSHA512-224 and algid-hmacWithSHA512-256.
> 
> Also, I have always been wondering how SHA3 Hmac `AlgorithmId` are encoded. https://datatracker.ietf.org/doc/html/rfc9688#name-signature-algorithms says "the parameters field MUST be absent". Although I'm not sure if this is only in CMS, but I think it's worth adding a reference here explaining why those OIDs are not included.

Thank you for catching that.

I?ve added the missing HMAC OIDs HmacSHA512_224 and HmacSHA512_256 as specified in [RFC 9879 ?4](https://www.rfc-editor.org/rfc/rfc9879.html#name-asn1-module)

Regarding SHA3-based HMACs, I have added a comment in the code as per your suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2422005098

From mullan at openjdk.org  Fri Oct 10 21:17:12 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 10 Oct 2025 21:17:12 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v12]
In-Reply-To: <e0k15guahZhu_w4UOQlxoeUefb1mbI8Zom0_Cng_IOY=.9839df92-3d7c-4269-96fb-57a242ff0d70@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <e0k15guahZhu_w4UOQlxoeUefb1mbI8Zom0_Cng_IOY=.9839df92-3d7c-4269-96fb-57a242ff0d70@github.com>
Message-ID: <m30UiJ-wRqDHj7mal0TXqpIPLt2J6bKvwXZ3PeagyZw=.0622219f-01a3-4551-b820-ea310ec5fb60@github.com>

On Tue, 7 Oct 2025 21:24:35 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more review comments from Sean and Weijun

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 65:

> 63:     private String hmac;
> 64:     private int keyLength;
> 65:     private boolean pbmac1Keystore = false;

New fields can be `final`.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 94:

> 92: 
> 93:             algParams = new PBMAC1Parameters(
> 94:                     digestAlgorithmId.getEncodedParams());

These lines can be combined.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 262:

> 260:             hmac = macAlgorithm;
> 261:         } else {
> 262:             throw new ParsingException("unexpected algorithm");

Include the name of the algorithm in the exception message.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 381:

> 379:     }
> 380: 
> 381:     public static String parseKdfHmac(String text) {

This method and `parseHmac` can be private.

src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 69:

> 67:     private final int keyLength;
> 68: 
> 69:     public PBMAC1Parameters(byte[] encoded) throws IOException {

The constructor and the 2 methods should be package-private instead of public.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2420721670
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2420729544
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2422071228
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2422076155
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2421072779

From weijun at openjdk.org  Fri Oct 10 21:30:03 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 10 Oct 2025 21:30:03 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v3]
In-Reply-To: <LGTbkcr2j79C6NNm3U4BcbAQcoRfPMWdAZ9NO1uuzpg=.c3980651-16b9-46f4-a0b7-93d164230275@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <LGTbkcr2j79C6NNm3U4BcbAQcoRfPMWdAZ9NO1uuzpg=.c3980651-16b9-46f4-a0b7-93d164230275@github.com>
Message-ID: <GTC0_r3kBQ-yCeRzamgJ4RLSiiy_Y3okAJBjRVYz9sc=.e8986bea-e320-4d38-8262-83473e232ad1@github.com>

On Fri, 10 Oct 2025 20:16:46 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 194:

> 192:             // if most RFCs suggested absent.
> 193:             // RSA key and signature algorithms and HmacSHA* algorithms requires
> 194:             // the NULL parameters to be present, see A.1 and A.2.4 of RFC 8017.

Move the comment above inside `OIDS_REQUIRING_NULL`, into different lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2422122724

From ascarpino at openjdk.org  Sat Oct 11 01:54:52 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 11 Oct 2025 01:54:52 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v5]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <IMZp6gzc0xBiM68d5NCk0RFLgQP2S215JJXKy5lpHmk=.b3dc58b5-9fe8-4924-ba66-b5443d495c12@github.com>

> Hi
> 
> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
> 
> - Renamed the name of `PEMRecord` class to `PEM`.
> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
> 
> thanks
> 
> Tony

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

 - major doc update, change to encrypt()
 - update preview

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/e13bff47..db913c3c

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

  Stats: 566 lines in 11 files changed: 177 ins; 154 del; 235 mod
  Patch: https://git.openjdk.org/jdk/pull/27147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147

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

From mpowers at openjdk.org  Sat Oct 11 02:39:13 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 11 Oct 2025 02:39:13 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v10]
In-Reply-To: <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <zVABGW17jakQdqCarOmboKzcfqEBAyxIttpzaAVE6AA=.97b0c8e1-f58f-436a-8d5e-28ce50715eac@github.com>
 <z4swN05ig3tnrW29fjE_DrpmhNyxJj03bXr0zvHTNck=.b0118bfc-eef0-4df9-9e77-c346bf309f8b@github.com>
Message-ID: <m4GcyBp4VYgo0C9OE4DVaJhBHdW27_OeV77ertwJUxE=.19dea54c-7c31-483d-ad45-87f93b8a0038@github.com>

On Tue, 30 Sep 2025 19:40:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another day another iteration
>
> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 51:
> 
>> 49:  * @author Sharon Liu
>> 50:  */
>> 51: 
> 
> It would be useful to add the ASN.1 definition here for reference.

added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2422386982

From mpowers at openjdk.org  Sat Oct 11 02:39:17 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 11 Oct 2025 02:39:17 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v12]
In-Reply-To: <m30UiJ-wRqDHj7mal0TXqpIPLt2J6bKvwXZ3PeagyZw=.0622219f-01a3-4551-b820-ea310ec5fb60@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <e0k15guahZhu_w4UOQlxoeUefb1mbI8Zom0_Cng_IOY=.9839df92-3d7c-4269-96fb-57a242ff0d70@github.com>
 <m30UiJ-wRqDHj7mal0TXqpIPLt2J6bKvwXZ3PeagyZw=.0622219f-01a3-4551-b820-ea310ec5fb60@github.com>
Message-ID: <KtW-iY0E9ORaLYRsuYgVAJ27YR1HEkWkAca7w48LmaY=.a7bebb24-941c-4527-919e-a9afe1ae9994@github.com>

On Fri, 10 Oct 2025 15:04:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more review comments from Sean and Weijun
>
> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 65:
> 
>> 63:     private String hmac;
>> 64:     private int keyLength;
>> 65:     private boolean pbmac1Keystore = false;
> 
> New fields can be `final`.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 94:
> 
>> 92: 
>> 93:             algParams = new PBMAC1Parameters(
>> 94:                     digestAlgorithmId.getEncodedParams());
> 
> These lines can be combined.

Still more than 80 so I broke the line at `.getEncodedParams().`

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 262:
> 
>> 260:             hmac = macAlgorithm;
>> 261:         } else {
>> 262:             throw new ParsingException("unexpected algorithm");
> 
> Include the name of the algorithm in the exception message.

done

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 381:
> 
>> 379:     }
>> 380: 
>> 381:     public static String parseKdfHmac(String text) {
> 
> This method and `parseHmac` can be private.

fixed

> src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 69:
> 
>> 67:     private final int keyLength;
>> 68: 
>> 69:     public PBMAC1Parameters(byte[] encoded) throws IOException {
> 
> The constructor and the 2 methods should be package-private instead of public.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2422387088
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2422387097
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2422387123
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2422387143
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2422387108

From mpowers at openjdk.org  Sat Oct 11 02:39:18 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 11 Oct 2025 02:39:18 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <87jVH7gFhQn8zKCm7dca1PVnqda4LM9GX-lx6EXgJs4=.aa54cf92-2192-43d5-b8d4-f4b9600e3393@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
 <7jhZVUSB2yFkXloSftuRXHZRFXkqoR4Ggj6BpotEphk=.23631446-ee02-4704-9827-97b8c7716b50@github.com>
 <87jVH7gFhQn8zKCm7dca1PVnqda4LM9GX-lx6EXgJs4=.aa54cf92-2192-43d5-b8d4-f4b9600e3393@github.com>
Message-ID: <ZyACg-bMYfa0RYvmlcV-deTCh5ZanCl_UDNfFIpNVAk=.78184fa2-fec3-4cc1-9ed9-d152fd891381@github.com>

On Mon, 6 Oct 2025 19:01:04 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 89:
>> 
>>> 87:     private String prfAlgo = "HmacSHA1";
>>> 88: 
>>> 89:     public PBKDF2Parameters(DerValue keyDerivationFunc) throws IOException {
>> 
>> Add some comments describing this ctor and its parameter.
>
> It's also a little unusual you are passing in the KDF algorithmId and not its parameters here.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2422387054

From abarashev at openjdk.org  Sat Oct 11 04:36:05 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Sat, 11 Oct 2025 04:36:05 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v5]
In-Reply-To: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
Message-ID: <6cWXULLkfTIZMOXSGBNdws3uB-Fi7--swunqaJd4QkY=.c41f9f1d-4f60-4974-a39a-a494b23d2b8b@github.com>

> If the NewSessionTicket message is lost, the handshake fails on the client side with:
> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  The fix and unit test for session resumption case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27677/files
  - new: https://git.openjdk.org/jdk/pull/27677/files/b5740400..5d34fd5c

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

  Stats: 310 lines in 3 files changed: 247 ins; 28 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/27677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27677/head:pull/27677

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

From duke at openjdk.org  Sat Oct 11 04:41:37 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 11 Oct 2025 04:41:37 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v4]
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <2xUYIFuiVjfpLrR1CPGXIsxqquPus1y3Y8kQokmiqWs=.e6172458-7a59-45a3-a338-b95f4a5626e5@github.com>

> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.

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

  8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27700/files
  - new: https://git.openjdk.org/jdk/pull/27700/files/ece6dbba..2ae9355e

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

  Stats: 15 lines in 1 file changed: 6 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27700/head:pull/27700

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

From duke at openjdk.org  Sat Oct 11 21:33:08 2025
From: duke at openjdk.org (Michael Rittmeister)
Date: Sat, 11 Oct 2025 21:33:08 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v6]
In-Reply-To: <v-8jXMI4RZi-xND2CAvicQLzG5PMZfLiXwGkcBYfSKE=.29c97184-9410-455e-934f-f20727ebd37a@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <v-8jXMI4RZi-xND2CAvicQLzG5PMZfLiXwGkcBYfSKE=.29c97184-9410-455e-934f-f20727ebd37a@github.com>
Message-ID: <2QLsmCJsYS4wm_vCTFFFGq8EPJbNPcImYpJBeuNLQxY=.d44e51e9-5475-4540-abd5-a912525ef0e0@github.com>

On Tue, 29 Jul 2025 10:05:18 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> 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...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce a shell test for anonymous pipes
>   
>   This use case has been discussed and analyzed in the pull request, but
>   we didn't have a test case for it. By introducing a test, we make sure
>   we don't have regressions in this area, regardless of the alternative
>   we choose to advance with for this fix.

I would like to point out, this also causes JDK 24+ to be incompatible with Microsofts UWP platform, as an UWP app also doesn't have permissions to the parent folder

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3393669685

From duke at openjdk.org  Sun Oct 12 01:26:43 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sun, 12 Oct 2025 01:26:43 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v5]
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <jAREXFgeXflXzTz0axZQwWJ8OBd1OTZu0OV0U89eZxk=.404060d0-b679-43ae-b7b0-288831b222ca@github.com>

> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.

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

  8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27700/files
  - new: https://git.openjdk.org/jdk/pull/27700/files/2ae9355e..dab47e75

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

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

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

From pminborg at openjdk.org  Mon Oct 13 11:51:02 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 11:51:02 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
Message-ID: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>

Implement JEP 526: Lazy Constants (Second Preview)

The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.

The old benchmarks are not moved/renamed to allow comparison with previous releases.

`java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

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

Commit messages:
 - Add optimization where the computing function is returned directly
 - Add benchmark of Optionals
 - Merge branch 'master' into lazy-constants
 - Update src/java.base/share/classes/java/lang/LazyConstant.java
 - Update src/java.base/share/classes/java/util/LazyCollections.java
 - Fix failing test
 - Clean up
 - Merge branch 'master' into lazy-constants
 - Update JEP number
 - Fix doc issues
 - ... and 76 more: https://git.openjdk.org/jdk/compare/1605e839...3e287031

Changes: https://git.openjdk.org/jdk/pull/27605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366178
  Stats: 8721 lines in 60 files changed: 4112 ins; 4490 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From duke at openjdk.org  Mon Oct 13 11:51:02 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 13 Oct 2025 11:51:02 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <8VsjXECvVSYRtKpK4PId8s_8RM0T00n4BzmfO6RTinM=.e1bb59c4-8a85-4d3c-8980-249cd529b50b@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

I?m?gonna?miss **Stable?Values**, as?it?has some?use?cases which?aren?t?served by?**Lazy?Constants**, and?on?which I?depend?on in?some of?my?code, so?I?m stuck?with using?regular non?`final`?fields.

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

Also, in the [JEP?526]?table under ?[Flexible?initialization with?lazy?constants]?:
> |                 	| Update count	| Update location	| Constant folding?	| Concurrent updates?
> | --------------  	| ------------	| ---------------	| -----------------	| -------------------
> | `final` field   	| 1         	| Constructor or static initializer	| Yes 	| No
> | `LazyConstant`  	| [0, 1]    	| Anywhere	| Yes, after initialization	| Yes, by winner
> | Non-`final` field	| [0, ?)    	| Anywhere	| No 	| Yes

The??Update?location? of?`LazyConstant` shouldn?t?be??Anywhere?, as?that?was only?accurate for?`StableValue`, but?not for?`LazyConstant`, which?is?updated by?calling the?passed `Supplier`.

Similarly, concurrent?updates are?prevented for?`LazyConstant`s by?using `synchronized?(this)`.

[JEP?526]: https://openjdk.org/jeps/526
[Flexible?initialization with?lazy?constants]: https://openjdk.org/jeps/526#Flexible-initialization-with-lazy-constants

Getting?access to?the?underlying `StableValue`?API with?**Lazy?Constants** is?way?too?hacky and?convoluted (but?doable):
<details>
<summary>StableVar.java</summary>


/*
 * Any copyright is dedicated to the Public Domain.
 * https://creativecommons.org/publicdomain/zero/1.0/
 */

import java.util.NoSuchElementException;
import java.util.function.Supplier;

import org.jspecify.annotations.NullMarked;
import org.jspecify.annotations.Nullable;

import static java.lang.System.identityHashCode;
import static java.util.Objects.requireNonNull;

/// Horrible awful hack to get access to raw stable values in JDK 26+.
@NullMarked
public sealed interface StableVar<T> permits StableHacks.StableVarImpl {
	boolean trySet(final T contents) throws NullPointerException, IllegalStateException;
	@Nullable T orNull();
	T orElse(final T other) throws NullPointerException;
	T orElseThrow() throws NoSuchElementException;
	boolean isSet();
	T orElseSet(final Supplier<? extends T> supplier) throws NullPointerException, IllegalStateException;
	void setOrThrow(final T contents) throws NullPointerException, IllegalStateException;

	static <T> StableVar<T> of() {
		return StableHacks.newInstance();
	}
}

/// Encapsulates the actual implementation of `StableValue` on `LazyConstant`
///
/// @author ExE Boss
@NullMarked
/*package*/ final @Namespace class StableHacks {
	private StableHacks() throws InstantiationException { throw new InstantiationException(StableHacks.class.getName()); }

	private static final String UNSET_SUFFIX = ".unset";
	private static final Object UNSET = new Object() {
		@Override
		public int hashCode() {
			return 0;
		}

		@Override
		public String toString() {
			return "unset";
		}
	};

	private static final ScopedValue<?> SCOPE = ScopedValue.newInstance();
	private static final Supplier<?> SCOPE_GETTER = SCOPE::get;

	/*package*/ static final <T> StableVarImpl<T> newInstance() {
		return new StableValue<>();
	}

	/*package*/ sealed interface StableVarImpl<T> extends StableVar<T> {
	}

	private record StableValue<T>(
		// Implemented as a record so that the JVM treats this as a trusted final field
		// even when `-XX:+TrustFinalNonStaticFields` is not set
		LazyConstant<T> contents
	) implements StableVarImpl<T> {
		@SuppressWarnings("unchecked")
		private StableValue() {
			this(LazyConstant.<T>of((Supplier) SCOPE_GETTER));
		}

		private StableValue {
			if (contents.isInitialized()) throw new InternalError();
		}

		@SuppressWarnings("unchecked")
		private final ScopedValue<T> scope() {
			return (ScopedValue<T>) SCOPE;
		}

		private final void preventReentry() throws IllegalStateException {
			if (Thread.holdsLock(this)) {
				throw new IllegalStateException("Recursive initialization of a stable value is illegal");
			}
		}

		@Override
		public boolean trySet(final T contents) throws NullPointerException, IllegalStateException {
			requireNonNull(contents);
			if (this.contents.isInitialized()) return false;

			preventReentry();
			synchronized (this) {
				return this.setImpl(contents);
			}
		}

		@Override
		@SuppressWarnings("unchecked")
		public final @Nullable T orNull() {
			return unwrapUnset(((LazyConstant) this.contents).orElse(UNSET));
		}

		@Override
		public T orElse(T other) throws NullPointerException {
			return this.contents.orElse(other);
		}

		@Override
		public T orElseThrow() throws NoSuchElementException {
			{ final T contents; if ((contents = this.orNull()) != null) {
				return contents;
			} }
			throw new NoSuchElementException();
		}

		@Override
		public boolean isSet() {
			return this.contents.isInitialized();
		}

		@Override
		public T orElseSet(final Supplier<? extends T> supplier) throws NullPointerException, IllegalStateException {
			requireNonNull(supplier);
			{ final T contents; if ((contents = this.orNull()) != null) {
				return contents;
			} }
			return orElseSetSlowPath(supplier);
		}

		@Override
		public void setOrThrow(final T contents) throws NullPointerException, IllegalStateException {
			if (!trySet(contents)) {
				throw new IllegalStateException();
			}
		}

		private final T orElseSetSlowPath(
			final Supplier<? extends T> supplier
		) throws NullPointerException, IllegalStateException {
			preventReentry();
			synchronized (this) {
				{ final T contents; if ((contents = this.orNull()) != null) {
					return contents;
				} }

				final T newValue;
				this.setImpl(newValue = requireNonNull(supplier.get()));
				return newValue;
			}
		}

		private final boolean setImpl(final T contents) {
			assert Thread.holdsLock(this);
			if (this.contents.isInitialized()) {
				return false;
			}

			ScopedValue.where(this.scope(), contents).run(this.contents::get);
			return true;
		}

		@Override
		public final boolean equals(final Object obj) {
			return this == obj;
		}

		@Override
		public final int hashCode() {
			return identityHashCode(this);
		}

		@Override
		public String toString() {
			final Object contents;
			return renderValue(
				"StableValue",
				(contents = this.orNull()) != this
					? contents
					: "(this StableValue)"
			);
		}
	}

	@SuppressWarnings("unchecked")
	private static final <T> @Nullable T unwrapUnset(final @Nullable Object obj) {
		return (obj == UNSET) ? null : (T) obj;
	}

	private static final String renderValue(
		final String type,
		final @Nullable Object value
	) throws NullPointerException {
		return (value == null)
			? type.concat(UNSET_SUFFIX)
			: (type + '[' + value + ']');
	}
}

</details>

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3367784825
PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3368298279

From liach at openjdk.org  Mon Oct 13 11:51:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 Oct 2025 11:51:04 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <8VsjXECvVSYRtKpK4PId8s_8RM0T00n4BzmfO6RTinM=.e1bb59c4-8a85-4d3c-8980-249cd529b50b@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <8VsjXECvVSYRtKpK4PId8s_8RM0T00n4BzmfO6RTinM=.e1bb59c4-8a85-4d3c-8980-249cd529b50b@github.com>
Message-ID: <SWOVc9fSGxDdTnOysqyKN7UssFHDXP9hMWfH1RwnMUg=.16ea0766-c0c3-4e37-9328-6e8d30a2b9a6@github.com>

On Sat, 4 Oct 2025 14:29:08 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Getting?access to?the?underlying `StableValue`?API with?**Lazy?Constants** is?way?too?hacky and?convoluted (but?doable):
> <details>
> <summary>StableVar.java</summary>
> 
> 
> /*
>  * Any copyright is dedicated to the Public Domain.
>  * https://creativecommons.org/publicdomain/zero/1.0/
>  */
> 
> import java.util.NoSuchElementException;
> import java.util.function.Supplier;
> 
> import org.jspecify.annotations.NullMarked;
> import org.jspecify.annotations.Nullable;
> 
> import static java.lang.System.identityHashCode;
> import static java.util.Objects.requireNonNull;
> 
> /// Horrible awful hack to get access to raw stable values in JDK 26+.
> @NullMarked
> public sealed interface StableVar<T> permits StableHacks.StableVarImpl {
> 	boolean trySet(final T contents) throws NullPointerException, IllegalStateException;
> 	@Nullable T orNull();
> 	T orElse(final T other) throws NullPointerException;
> 	T orElseThrow() throws NoSuchElementException;
> 	boolean isSet();
> 	T orElseSet(final Supplier<? extends T> supplier) throws NullPointerException, IllegalStateException;
> 	void setOrThrow(final T contents) throws NullPointerException, IllegalStateException;
> 
> 	static <T> StableVar<T> of() {
> 		return StableHacks.newInstance();
> 	}
> }
> 
> /// Encapsulates the actual implementation of `StableValue` on `LazyConstant`
> ///
> /// @author ExE Boss
> @NullMarked
> /*package*/ final @Namespace class StableHacks {
> 	private StableHacks() throws InstantiationException { throw new InstantiationException(StableHacks.class.getName()); }
> 
> 	private static final String UNSET_SUFFIX = ".unset";
> 	private static final Object UNSET = new Object() {
> 		@Override
> 		public int hashCode() {
> 			return 0;
> 		}
> 
> 		@Override
> 		public String toString() {
> 			return "unset";
> 		}
> 	};
> 
> 	private static final ScopedValue<?> SCOPE = ScopedValue.newInstance();
> 	private static final Supplier<?> SCOPE_GETTER = SCOPE::get;
> 
> 	/*package*/ static final <T> StableVarImpl<T> newInstance() {
> 		return new StableValue<>();
> 	}
> 
> 	/*package*/ sealed interface StableVarImpl<T> extends StableVar<T> {
> 	}
> 
> 	private record StableValue<T>(
> 		// Implemented as a record so that the JVM treats this as a trusted final field
> 		// even when `-XX:+TrustFinalNonStaticFields` is not set
> 		LazyConstant<T> contents
> 	) implements StableVarImpl<T> {
> 		@SuppressWarnings("unchecked")
> 		private StableValue() {
> 			this(LazyConstant.<T>of((Supplier) SCOPE_GETTER));
> 		}
> 
> 		private StableValue {
> 			if (contents.isInitialized()) throw new InternalError();
> 		}
> 
> 		@SuppressWarnings("unchecked")
> 		private fi...

Hi @ExE-Boss, this new JEP describes how this functionality will be provided in the future:

> Lazy constants cover the common, high-level use cases for lazy initialization. In the future we might consider providing stable access semantics directly, at a lower level, for reference, array, and primitive fields. This would address, for example, use cases where the computing function associated with a lazy constant is not known at construction.

This would be necessary, as there are usage patterns (such as nominal descriptors in ClassFile API) that would benefit from multiple assignment and a stable promoted read.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3368317631

From duke at openjdk.org  Mon Oct 13 11:51:05 2025
From: duke at openjdk.org (Burning_TNT)
Date: Mon, 13 Oct 2025 11:51:05 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <TVnou37DZfwZQEaiDRAA1hc1k7IdtX6Yegnn-l106lE=.832b0a36-0bef-4863-8f2c-c5291860921a@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

It's essential to provide a low-level API as those in StableValue. Completely migrating to factory pattern may forcing users to build their own LazyConstant wrapper as ExeBoss has down above.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3369054838

From pminborg at openjdk.org  Mon Oct 13 11:51:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 11:51:05 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <5N4q67er51rXJ8E1oqNY4gCowyJ_K4x1SCeWncz1dFY=.2fe20197-fffe-467f-a1af-5816594c7e78@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

> I?m?gonna?miss **Stable?Values**, as?it?has some?use?cases which?aren?t?served by?**Lazy?Constants**, and?on?which I?depend?on in?some of?my?code, so?I?m stuck?with using?regular non?`final`?fields.
> 
> Also, in the [JEP?526](https://openjdk.org/jeps/526)?table under ?[Flexible?initialization with?lazy?constants](https://openjdk.org/jeps/526#Flexible-initialization-with-lazy-constants)?:
> 
> > Update count
> > Update location
> > Constant folding?
> > Concurrent updates?
> > 
> > 
> > 
> > 
> > `final` field
> > 1
> > Constructor or static initializer
> > Yes
> > No
> > 
> > 
> > `LazyConstant`
> > [0, 1]
> > Anywhere
> > Yes, after initialization
> > Yes, by winner
> > 
> > 
> > Non-`final` field
> > [0, ?)
> > Anywhere
> > No
> > Yes
> 
> The??Update?location? of?`LazyConstant` shouldn?t?be??Anywhere?, as?that?was only?accurate for?`StableValue`, but?not for?`LazyConstant`, which?is?updated by?calling the?passed `Supplier`.
> 
> Similarly, concurrent?updates are?prevented for?`LazyConstant`s by?using `synchronized?(this)`.

I've updated the JEP. Thanks for pointing out this. Let me know what you think about the new text.

We are exploring better ways to provide low-level, imperative, lazy constant/stable value fields. This work will be done outside the current JEP.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3396693041
PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3397160926

From duke at openjdk.org  Mon Oct 13 11:51:06 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 13 Oct 2025 11:51:06 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <5N4q67er51rXJ8E1oqNY4gCowyJ_K4x1SCeWncz1dFY=.2fe20197-fffe-467f-a1af-5816594c7e78@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <5N4q67er51rXJ8E1oqNY4gCowyJ_K4x1SCeWncz1dFY=.2fe20197-fffe-467f-a1af-5816594c7e78@github.com>
Message-ID: <AMjEdNjzqVRGYeBQyCHtgEcYNYpj2iJR1-j9qYbRy1k=.eb628b5d-462e-463c-9dfc-bba90840b478@github.com>

On Mon, 13 Oct 2025 09:49:16 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> I've updated the JEP. Thanks for pointing out this. Let me know what you think about the new text.

The?change was?made to?the?wrong?row (?Non?`final`?field? instead of??`LazyConstant`?).

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3396866550

From fandreuzzi at openjdk.org  Mon Oct 13 11:51:09 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 13 Oct 2025 11:51:09 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <9oTBJDVY4LhEXsE4tVJAItdEvmaA3YcZ0BbUrw7M9uk=.86f99b3a-fbb2-4ce4-916d-e0487fce4211@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/java/lang/LazyConstant.java line 166:

> 164:  *
> 165:  * <h2 id="performance">Performance</h2>
> 166:  * As a lazy constant can never change after it has been initialized. Therefore,

Suggestion:

 * A lazy constant can never change after it has been initialized. Therefore,

src/java.base/share/classes/java/util/LazyCollections.java line 80:

> 78:         }
> 79: 
> 80:         @Override public boolean  isEmpty() { return size == 0;}

Suggestion:

        @Override public boolean  isEmpty() { return size == 0; }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399059426
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399074220

From duke at openjdk.org  Mon Oct 13 11:51:10 2025
From: duke at openjdk.org (Kerman)
Date: Mon, 13 Oct 2025 11:51:10 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/java/util/Optional.java line 74:

> 72:      * If non-null, the value; if null, indicates no value is present
> 73:      */
> 74:     @Stable

Shouldn?t this also add a null sentinel to allow the folding of the empty case? Or is that irrelevant because empty would be the terminator of a chain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399352909

From liach at openjdk.org  Mon Oct 13 11:51:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 Oct 2025 11:51:11 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>
Message-ID: <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com>

On Thu, 2 Oct 2025 16:16:44 GMT, Kerman <duke at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> src/java.base/share/classes/java/util/Optional.java line 74:
> 
>> 72:      * If non-null, the value; if null, indicates no value is present
>> 73:      */
>> 74:     @Stable
> 
> Shouldn?t this also add a null sentinel to allow the folding of the empty case? Or is that irrelevant because empty would be the terminator of a chain.

Usually a null sentinel is used when null indicates something different. I think maybe to allow folding the empty case, we should probably add a new annotation or a new element-value to indicate this status and properly handle it in C1/C2 (similar to the field trusting in ciField)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2403729792

From pminborg at openjdk.org  Mon Oct 13 11:51:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 11:51:11 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <qtZot2WX6UOjKT0P4mi4CQKOjoIU5CJMmCieIplwO00=.5ae10b17-9aae-471e-866a-ed876c4d0ffe@github.com>
 <-lErHk2PzyJCaPQGrEwCt3nObTrTHs7_p53eBXspUGE=.50dc2375-8769-49a5-9308-ab40132bbd19@github.com>
Message-ID: <P1Ti8_ofzrMmdzekvWxWvLQP5Khkt8Ivfb_xGQArNl4=.14fdc4b4-bec7-4b6f-ab71-86d42fb64006@github.com>

On Sat, 4 Oct 2025 04:13:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Optional.java line 74:
>> 
>>> 72:      * If non-null, the value; if null, indicates no value is present
>>> 73:      */
>>> 74:     @Stable
>> 
>> Shouldn?t this also add a null sentinel to allow the folding of the empty case? Or is that irrelevant because empty would be the terminator of a chain.
>
> Usually a null sentinel is used when null indicates something different. I think maybe to allow folding the empty case, we should probably add a new annotation or a new element-value to indicate this status and properly handle it in C1/C2 (similar to the field trusting in ciField)

I've added two new benchmarks:


    private static final LazyConstant<Optional<Integer>> OPTIONAL_42 = LazyConstant.of(() -> Optional.of(42));
    private static final LazyConstant<Optional<Integer>> OPTIONAL_42_2 = LazyConstant.of(() -> Optional.of(42));
    private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY = LazyConstant.of(Optional::empty);
    private static final LazyConstant<Optional<Integer>> OPTIONAL_EMPTY2 = LazyConstant.of(Optional::empty);
    
    ...
    
        @Benchmark
    public int staticOptional42() {
        return OPTIONAL_42.get().orElseThrow() + OPTIONAL_42_2.get().orElseThrow();
    }

    @Benchmark
    public boolean staticOptionalEmpty() {
        return OPTIONAL_EMPTY.get().isEmpty() ^ OPTIONAL_EMPTY2.get().isEmpty();
    }

    


Which gives:


Benchmark                              Mode  Cnt  Score   Error  Units
StableValueBenchmark.staticOptional42  avgt   10  0.354 ? 0.045  ns/op

Benchmark                                 Mode  Cnt  Score   Error  Units
StableValueBenchmark.staticOptionalEmpty  avgt   10  0.370 ? 0.030  ns/op


So, both `Optional` variants appears to support constant folding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426044826

From liach at openjdk.org  Mon Oct 13 11:51:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 Oct 2025 11:51:13 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <OyJKBdreExBHONphUNrOVtJ8TEpmdlecqbZDjFgrhEM=.fb64e148-7414-4eba-99ba-b0d2f6ba4c5d@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/jdk/internal/lang/LazyConstantImpl.java line 171:

> 169: 
> 170:     public static <T> LazyConstantImpl<T> ofLazy(Supplier<? extends T> computingFunction) {
> 171:         return new LazyConstantImpl<>(computingFunction);

We might return the function if it is already a LazyConstantImpl.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399678324

From duke at openjdk.org  Mon Oct 13 11:51:14 2025
From: duke at openjdk.org (Jefferson Quesado)
Date: Mon, 13 Oct 2025 11:51:14 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <DFUyMXwPa0KgUxCg8sqLAnVDCf7r24HF87kBzAqyxxo=.41c8ef77-aca1-485d-92b3-e7a8c3523e2f@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/sun/nio/ch/Net.java line 99:

> 97:     }
> 98: 
> 99:     private static final LazyConstant<Boolean> SHUTDOWN_WRITE_BEFORE_CLOSE = LazyConstant.of(new Supplier<Boolean>() {

I wonder if there is a reason for not using `BooleanSupplier`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2399205774

From liach at openjdk.org  Mon Oct 13 11:51:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 Oct 2025 11:51:15 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <DFUyMXwPa0KgUxCg8sqLAnVDCf7r24HF87kBzAqyxxo=.41c8ef77-aca1-485d-92b3-e7a8c3523e2f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <DFUyMXwPa0KgUxCg8sqLAnVDCf7r24HF87kBzAqyxxo=.41c8ef77-aca1-485d-92b3-e7a8c3523e2f@github.com>
Message-ID: <AjWu6XWSBdL6kT-2NK5BQYTG2FK9vxBk0qeh3t6i4cY=.ce2fa0da-7ac9-4dca-b143-3bfcde3a53dc@github.com>

On Thu, 2 Oct 2025 15:21:37 GMT, Jefferson Quesado <duke at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> src/java.base/share/classes/sun/nio/ch/Net.java line 99:
> 
>> 97:     }
>> 98: 
>> 99:     private static final LazyConstant<Boolean> SHUTDOWN_WRITE_BEFORE_CLOSE = LazyConstant.of(new Supplier<Boolean>() {
> 
> I wonder if there is a reason for not using `BooleanSupplier`.

Unfortunately, BooleanSupplier does not extend Supplier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2403730001

From mcimadamore at openjdk.org  Mon Oct 13 13:08:03 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:08:03 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <IJfERenZovbr-x3XK-M_VPrQu5OpXqgRf8qMolrANcA=.f11fb9f6-4e31-4282-a65e-20178f3f7a5c@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

test/jdk/java/lang/LazyConstant/DemoImperativeTest.java line 25:

> 23: 
> 24: /* @test
> 25:  * @summary Demo of an imperative stable value based on a lazy constant

Should this summary be updated (and. some of the classes defined here)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426297364

From mcimadamore at openjdk.org  Mon Oct 13 13:20:38 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:20:38 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <UwW2wfRoSBvn4EQ_p4awxVaWLBafdoRPkzWzxqDBjPk=.ad928444-c48a-4715-9df3-29e982f251e8@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/java/util/LazyCollections.java line 255:

> 253:     }
> 254: 
> 255:     interface LenientList<E> extends List<E> {

Ok, this seems needed to give access to `getAcquire` from sublists created from other sublists...

src/java.base/share/classes/java/util/LazyCollections.java line 360:

> 358: 
> 359:         @Stable
> 360:         private final Set<K> keySet;

I believe putting the field in here might cause some redundancies -- for instance LazyMap extends this class and addss a `Map<K, Integer>`, from which you can clearly derive the key set...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426326166
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426329562

From djelinski at openjdk.org  Mon Oct 13 13:29:28 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 13 Oct 2025 13:29:28 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v5]
In-Reply-To: <6cWXULLkfTIZMOXSGBNdws3uB-Fi7--swunqaJd4QkY=.c41f9f1d-4f60-4974-a39a-a494b23d2b8b@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <6cWXULLkfTIZMOXSGBNdws3uB-Fi7--swunqaJd4QkY=.c41f9f1d-4f60-4974-a39a-a494b23d2b8b@github.com>
Message-ID: <UZPhFZsEh4s459hySMvY4SdUzjwpE6W4BZUsH7Md7tI=.a1cf7be9-a0c1-47d4-bfc7-7ca589d27ac7@github.com>

On Sat, 11 Oct 2025 04:36:05 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> If the NewSessionTicket message is lost, the handshake fails on the client side with:
>> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The fix and unit test for session resumption case

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 138:

> 136:                 isClient ? getClientDTLSContext() : getServerDTLSContext();
> 137:         SSLEngine engine = context.createSSLEngine(HOST,
> 138:                 isClient ? CLIENT_PORT : SERVER_PORT);

Suggestion:

                isClient ? SERVER_PORT : CLIENT_PORT);

Client uses server port, server uses client port.

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 541:

> 539:                 new InetSocketAddress(HOST, SERVER_PORT);
> 540:         InetSocketAddress clientSocketAddress =
> 541:                 new InetSocketAddress(HOST, CLIENT_PORT);

Don't fix ports here. There's a nonzero chance that some other process will take these ports before you.

Use port zero here. The port numbers used in SSLEngine don't need to match the datagram socket, they just need to match between the initial session and the resumption.

test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 630:

> 628:     static int findAvailablePort() {
> 629:         try (var socket = new DatagramSocket(0)) {
> 630:             return socket.getLocalPort();

You can use a hardcoded number here; it doesn't need to correspond to a real socket.

test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java line 97:

> 95:             // and resuming sessions.
> 96:             SSLEngine clientEngine = testCase.clientContext.createSSLEngine(
> 97:                     HOST, CLIENT_PORT);

Suggestion:

                    HOST, SERVER_PORT);

rationale: see previous comments

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2426335814
PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2426342510
PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2426353394
PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2426345242

From mcimadamore at openjdk.org  Mon Oct 13 13:30:34 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:30:34 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <dSBYO8NKyIwDPb7yzVSDIpuq1lRvZLpDzktyC8Xp6CI=.b5c05905-71b7-442a-ac2f-906462a63cb1@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/java/lang/LazyConstant.java line 42:

> 40: 
> 41: /**
> 42:  * A lazy constant is a deferred, shallowly immutable constant to be computed at

It seems like the javadoc is a snapshot of an earlier version of the JEP where the word "content" was replaced with "constant". I think we should go back to "content" and say (as we did for stable values) that a "A lazy constant is a holder of contents that can be set at most once."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426358262

From mcimadamore at openjdk.org  Mon Oct 13 13:34:33 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:34:33 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <56kNzRwD6WRl9bHJUKb-YU1TuN6Tha_crXrwvfb-EmU=.c601a0b2-a66f-4d7f-9952-d235ee935fb1@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/java/lang/LazyConstant.java line 98:

> 96:  * constant is not initialized.
> 97:  * <p>
> 98:  * If the computing function throws any unchecked exception or Error, that Throwable

add some code blocks around `Error` and `Throwable`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426369216

From mcimadamore at openjdk.org  Mon Oct 13 13:40:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:40:54 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <PYlhP-FkE-PKcQaOgl0Xwhvemn4TKJXCZ8jlI6Vtp8M=.440ce203-cf7c-41bc-90f5-87085e8d0673@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/java/lang/LazyConstant.java line 155:

> 153:  * {@code final} fields of any newly created objects, are safely published.
> 154:  * <p>
> 155:  * The computing function runs on the caller?s thread.

Here you might define "we call that thread the computing thread" -- this might be useful when defining other concepts in this section (maybe)

src/java.base/share/classes/java/lang/LazyConstant.java line 157:

> 155:  * The computing function runs on the caller?s thread.
> 156:  * <p>
> 157:  * If a thread that is blocked by another computing thread is interrupted, this is not

I'm not sure I understand what you mean in this para

src/java.base/share/classes/java/lang/LazyConstant.java line 172:

> 170:  * (e.g. in cases where the lazy constant itself is stored in a
> 171:  * {@code static final} field) or forms a trusted chain to such a VM constant via
> 172:  * one or more layers of a {@linkplain Record record} fields or final fields

one or more layers of "trusted" fields -- then in parenthesis you say what these "trusted" fields are.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426383095
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426379186
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426387301

From mcimadamore at openjdk.org  Mon Oct 13 13:40:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:40:56 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <PYlhP-FkE-PKcQaOgl0Xwhvemn4TKJXCZ8jlI6Vtp8M=.440ce203-cf7c-41bc-90f5-87085e8d0673@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <PYlhP-FkE-PKcQaOgl0Xwhvemn4TKJXCZ8jlI6Vtp8M=.440ce203-cf7c-41bc-90f5-87085e8d0673@github.com>
Message-ID: <ThzUBTfwY0Tg1fk0l-ulOAO7QGoD6AmaiZmItOUj960=.d9f5c279-f149-4d8a-b9a2-ca53154264f7@github.com>

On Mon, 13 Oct 2025 13:35:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 157:
> 
>> 155:  * The computing function runs on the caller?s thread.
>> 156:  * <p>
>> 157:  * If a thread that is blocked by another computing thread is interrupted, this is not
> 
> I'm not sure I understand what you mean in this para

E.g. "thread that is blocked by another computing thread". Did you mean to say "if the thread running the computing function is interrupted"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426381677

From mcimadamore at openjdk.org  Mon Oct 13 13:46:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:46:48 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <o3w7K129sBV4DQKXHIHW1OVv_tZnJJ9KjsgSbVQRUhQ=.48d8ca41-c15b-4d55-980b-bbeab1cbb51c@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/java/lang/LazyConstant.java line 188:

> 186:  *          arbitrary depth can be used, which provides constant components.
> 187:  *          More generally, a lazy constant can hold other lazy constants of
> 188:  *          arbitrary depth and still provide transitive constancy.

I'm not sure the term "constancy" is common to mean constant-ness. I think it might be better to use the term "constant-folding" -- and then define "constant-folding" in the above "performance" section:

>  A lazy constant can never change after it has been initialized. Therefore,
> a JVM implementation may, for an initialized lazy constant, elide all future reads
>  of that lazy constant, and instead directly use any constant that it has previously
>  observed

Then you can add "we call this optimization constant-folding".

src/java.base/share/classes/java/lang/LazyConstant.java line 192:

> 190:  *          The {@code LazyConstant} type is not {@link Serializable}.
> 191:  *          <p>
> 192:  *          It is not recommended putting lazy constants into equality-based collections

Not sure what you mean here. It seems like the javadoc for `equals` says that it triggers initialization, so it should be ok?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426397976
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426402669

From pminborg at openjdk.org  Mon Oct 13 13:46:51 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 13:46:51 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <UwW2wfRoSBvn4EQ_p4awxVaWLBafdoRPkzWzxqDBjPk=.ad928444-c48a-4715-9df3-29e982f251e8@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <UwW2wfRoSBvn4EQ_p4awxVaWLBafdoRPkzWzxqDBjPk=.ad928444-c48a-4715-9df3-29e982f251e8@github.com>
Message-ID: <m4bMbcy87MR8-ejhrcvK164NmcAO-HMK4GaqIIrBA_I=.d06c3218-1410-4cb8-bec5-a63d13a68547@github.com>

On Mon, 13 Oct 2025 13:17:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> src/java.base/share/classes/java/util/LazyCollections.java line 360:
> 
>> 358: 
>> 359:         @Stable
>> 360:         private final Set<K> keySet;
> 
> I believe putting the field in here might cause some redundancies -- for instance LazyMap extends this class and addss a `Map<K, Integer>`, from which you can clearly derive the key set...

It is true that `AbstractMap` already contains a `keySet` field. If we annotate `AbstractMap.keySet` with `@Stable` (which seems ok to do), we can get rid of this field. A note here is that eventually, we would like to get rid of all the fields in `AbstractMap`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426399337

From mcimadamore at openjdk.org  Mon Oct 13 13:50:07 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 13:50:07 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <ynVsjhWXWBevYph6ShH_2uggF_ih6eYgR2Up9_tcp-Y=.c6304b0b-0176-4717-81f7-f40db22542ff@github.com>

On Thu, 2 Oct 2025 10:51:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

src/java.base/share/classes/java/lang/LazyConstant.java line 276:

> 274:      * this method might block or throw.
> 275:      *
> 276:      * @implSpec The order of potential initialization triggering is specified as:

Do we really need to specify this?

src/java.base/share/classes/java/lang/LazyConstant.java line 312:

> 310:     String toString();
> 311: 
> 312:     // Factories

Suggestion:

    // Factory

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426409576
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426412926

From pminborg at openjdk.org  Mon Oct 13 13:54:44 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 13:54:44 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v2]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/3e287031..0978179a

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

  Stats: 7 lines in 2 files changed: 3 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From abarashev at openjdk.org  Mon Oct 13 13:58:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 13 Oct 2025 13:58:49 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v5]
In-Reply-To: <UZPhFZsEh4s459hySMvY4SdUzjwpE6W4BZUsH7Md7tI=.a1cf7be9-a0c1-47d4-bfc7-7ca589d27ac7@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <6cWXULLkfTIZMOXSGBNdws3uB-Fi7--swunqaJd4QkY=.c41f9f1d-4f60-4974-a39a-a494b23d2b8b@github.com>
 <UZPhFZsEh4s459hySMvY4SdUzjwpE6W4BZUsH7Md7tI=.a1cf7be9-a0c1-47d4-bfc7-7ca589d27ac7@github.com>
Message-ID: <JKAovYFrK9obqTxa6c4Mbd8nzbQLUezk4dAB6TL4ClM=.b1f0af49-8fe2-433f-af90-4937a318529e@github.com>

On Mon, 13 Oct 2025 13:22:31 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The fix and unit test for session resumption case
>
> test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 541:
> 
>> 539:                 new InetSocketAddress(HOST, SERVER_PORT);
>> 540:         InetSocketAddress clientSocketAddress =
>> 541:                 new InetSocketAddress(HOST, CLIENT_PORT);
> 
> Don't fix ports here. There's a nonzero chance that some other process will take these ports before you.
> 
> Use port zero here. The port numbers used in SSLEngine don't need to match the datagram socket, they just need to match between the initial session and the resumption.

Good catch, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2426435630

From abarashev at openjdk.org  Mon Oct 13 14:02:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 13 Oct 2025 14:02:49 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v5]
In-Reply-To: <UZPhFZsEh4s459hySMvY4SdUzjwpE6W4BZUsH7Md7tI=.a1cf7be9-a0c1-47d4-bfc7-7ca589d27ac7@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <6cWXULLkfTIZMOXSGBNdws3uB-Fi7--swunqaJd4QkY=.c41f9f1d-4f60-4974-a39a-a494b23d2b8b@github.com>
 <UZPhFZsEh4s459hySMvY4SdUzjwpE6W4BZUsH7Md7tI=.a1cf7be9-a0c1-47d4-bfc7-7ca589d27ac7@github.com>
Message-ID: <rT7_xeBn0Vx4ybHrObrihNmHC2frfGIUqSriKBZb15k=.23a6e0e8-e4b5-46cd-b1d2-77014e05243c@github.com>

On Mon, 13 Oct 2025 13:19:59 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The fix and unit test for session resumption case
>
> test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 138:
> 
>> 136:                 isClient ? getClientDTLSContext() : getServerDTLSContext();
>> 137:         SSLEngine engine = context.createSSLEngine(HOST,
>> 138:                 isClient ? CLIENT_PORT : SERVER_PORT);
> 
> Suggestion:
> 
>                 isClient ? SERVER_PORT : CLIENT_PORT);
> 
> Client uses server port, server uses client port.

Not sure what I'm missing here: if `isClient` is `true` then we use `CLIENT_PORT`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2426444171

From pminborg at openjdk.org  Mon Oct 13 14:03:37 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 14:03:37 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v3]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <IldqX9DxZgp9eOXHKfrj-C41jqWCPVkWhJ7EzYjl61I=.0d9650be-567d-4160-a8bd-0aeb73e2f6ff@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add links around Error and Throwable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/0978179a..5770e033

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

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

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

From pminborg at openjdk.org  Mon Oct 13 14:03:41 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 14:03:41 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v3]
In-Reply-To: <ThzUBTfwY0Tg1fk0l-ulOAO7QGoD6AmaiZmItOUj960=.d9f5c279-f149-4d8a-b9a2-ca53154264f7@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <PYlhP-FkE-PKcQaOgl0Xwhvemn4TKJXCZ8jlI6Vtp8M=.440ce203-cf7c-41bc-90f5-87085e8d0673@github.com>
 <ThzUBTfwY0Tg1fk0l-ulOAO7QGoD6AmaiZmItOUj960=.d9f5c279-f149-4d8a-b9a2-ca53154264f7@github.com>
Message-ID: <0kU7XwB4vVkXnZLTj79Gen7puX7sPTKNfZwkf3I1wpM=.840e45e2-87bb-41ad-a4be-8d474458559d@github.com>

On Mon, 13 Oct 2025 13:36:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/LazyConstant.java line 157:
>> 
>>> 155:  * The computing function runs on the caller?s thread.
>>> 156:  * <p>
>>> 157:  * If a thread that is blocked by another computing thread is interrupted, this is not
>> 
>> I'm not sure I understand what you mean in this para
>
> E.g. "thread that is blocked by another computing thread". Did you mean to say "if the thread running the computing function is interrupted"?

If a thread `A` won the race and invokes the computing function, and another thread `B` comes along while computation takes place by `A`, then interrupting thread `B` will not have any effect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426445641

From dfuchs at openjdk.org  Mon Oct 13 14:05:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 14:05:44 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
Message-ID: <tduqK45Wvxn--nWm13DAhCuVPJoXW_qWnRhwEstfjjM=.25ea42f0-7c03-4642-81d0-25abe246dc74@github.com>

On Thu, 2 Oct 2025 16:19:56 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the code

The proposed solution needs more explaining, and integrate properly with the connection lock.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 497:

> 495:         } catch (IOException ioEx) {
> 496:             //ignore the error;
> 497:         }

Given that this is called after `conn.cleanup` and that `conn.cleanup` closes the socket if not null and set it to null after, can you explain in which circumstance this method would find a non-null `conn.sock`?

Another issue is that this method attempts to modify the state of the connection without holding the connection lock. This is not good.

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26566#pullrequestreview-3331775448
PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2426446665

From pminborg at openjdk.org  Mon Oct 13 14:13:42 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 14:13:42 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v4]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <Hj8ocZSN6FRk9zvUHiZMREPvnEVAkOTyckyheI815OA=.333cb757-eca2-4853-b740-7192b3de05c0@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Reprhase text around the computing thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/5770e033..47af4307

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

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

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

From djelinski at openjdk.org  Mon Oct 13 14:14:35 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 13 Oct 2025 14:14:35 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v5]
In-Reply-To: <rT7_xeBn0Vx4ybHrObrihNmHC2frfGIUqSriKBZb15k=.23a6e0e8-e4b5-46cd-b1d2-77014e05243c@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <6cWXULLkfTIZMOXSGBNdws3uB-Fi7--swunqaJd4QkY=.c41f9f1d-4f60-4974-a39a-a494b23d2b8b@github.com>
 <UZPhFZsEh4s459hySMvY4SdUzjwpE6W4BZUsH7Md7tI=.a1cf7be9-a0c1-47d4-bfc7-7ca589d27ac7@github.com>
 <rT7_xeBn0Vx4ybHrObrihNmHC2frfGIUqSriKBZb15k=.23a6e0e8-e4b5-46cd-b1d2-77014e05243c@github.com>
Message-ID: <SI6xSEODsR2e7kaqcpmcKfKsb47blHXM7XUgLFvwgew=.3ddfd66b-c61c-4a0b-aa98-0fd3b9a72d23@github.com>

On Mon, 13 Oct 2025 13:59:21 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 138:
>> 
>>> 136:                 isClient ? getClientDTLSContext() : getServerDTLSContext();
>>> 137:         SSLEngine engine = context.createSSLEngine(HOST,
>>> 138:                 isClient ? CLIENT_PORT : SERVER_PORT);
>> 
>> Suggestion:
>> 
>>                 isClient ? SERVER_PORT : CLIENT_PORT);
>> 
>> Client uses server port, server uses client port.
>
> Not sure what I'm missing here: if `isClient` is `true` then we use `CLIENT_PORT`

right. The client is supposed to use the server port, and the server may use the client port (but may also use the no-argument createSSLEngine overload)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2426476570

From pminborg at openjdk.org  Mon Oct 13 14:18:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 14:18:53 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v5]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <XNc0nLtm-T0BzPOp8FCsK7sTv3GvS2-MxZkwGxQmpQM=.d4214560-698b-4d85-b079-7a7e43a098ff@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rephrase trusted field text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/47af4307..ea14b8f9

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

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

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

From pminborg at openjdk.org  Mon Oct 13 14:22:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 14:22:13 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v6]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <5EAP5ubicOh_odm_aPlWJZbDQTuV0AIRs-fHlW7jTlc=.86692372-8a21-49dc-a453-4dbeef84d242@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Define constant folding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/ea14b8f9..e25eeb9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=04-05

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

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

From pminborg at openjdk.org  Mon Oct 13 14:33:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 14:33:06 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v7]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <GphZBYlM0eL9LEaj0-3gNxp_8Bu1cpeGp2EZHUSDmNs=.25a985c7-65e2-4e97-ad14-bb56fd515081@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/LazyConstant.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/e25eeb9b..5845a7a5

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

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

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

From mcimadamore at openjdk.org  Mon Oct 13 14:33:08 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 14:33:08 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v6]
In-Reply-To: <5EAP5ubicOh_odm_aPlWJZbDQTuV0AIRs-fHlW7jTlc=.86692372-8a21-49dc-a453-4dbeef84d242@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <5EAP5ubicOh_odm_aPlWJZbDQTuV0AIRs-fHlW7jTlc=.86692372-8a21-49dc-a453-4dbeef84d242@github.com>
Message-ID: <E500jbBTwknLUkWrDv_PeJko1o0BSpMgyAe7bJeQmH0=.ac6261e4-b40f-49c7-984f-3a9d64299324@github.com>

On Mon, 13 Oct 2025 14:22:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Define constant folding

src/java.base/share/classes/java/lang/LazyConstant.java line 156:

> 154:  * {@code final} fields of any newly created objects, are safely published.
> 155:  * <p>
> 156:  * If the computing thread or any thread that is blocked by the computing thread

My worry here is that when we say "any thread that is blocked" we really meany "any thread". But in reality this javadoc only refers to threads that are trying to call `get` and end up blocked because some other thread won the race. E.g. if a thread is blocked by the computing thread for any other reason, we don't know whether interrupting that thread will result in an `InterruptedException` ? I think it might be worth simplifying this a bit, starting with the property you want to assert:

> Thread interruption does not cancel initialization of a lazy constant. In other words, if the computing thread is 
> interrupted, `LazyConstant::get` doesn't clear the interrupted thread?s status is not cleared, nor does it throw 
> an `InterruptedException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426515394

From pminborg at openjdk.org  Mon Oct 13 14:33:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Oct 2025 14:33:10 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v7]
In-Reply-To: <o3w7K129sBV4DQKXHIHW1OVv_tZnJJ9KjsgSbVQRUhQ=.48d8ca41-c15b-4d55-980b-bbeab1cbb51c@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <o3w7K129sBV4DQKXHIHW1OVv_tZnJJ9KjsgSbVQRUhQ=.48d8ca41-c15b-4d55-980b-bbeab1cbb51c@github.com>
Message-ID: <EQ3-nnbKwCkMFZlW5cpSlia8Su2xKgvsNU6XUDefQ3Q=.3323f66a-8b10-4f5f-9374-0249983ee38d@github.com>

On Mon, 13 Oct 2025 13:44:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/LazyConstant.java
>>   
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 192:
> 
>> 190:  *          The {@code LazyConstant} type is not {@link Serializable}.
>> 191:  *          <p>
>> 192:  *          It is not recommended putting lazy constants into equality-based collections
> 
> Not sure what you mean here. It seems like the javadoc for `equals` says that it triggers initialization, so it should be ok?

Formally, it is ok, but may result in strange side effects if we, for example, put a key of type LazyConstant in a map. It will then be initialized immediately (upon `map.put()`), and the put operation can therefore have non-obvious side effects.

> src/java.base/share/classes/java/lang/LazyConstant.java line 276:
> 
>> 274:      * this method might block or throw.
>> 275:      *
>> 276:      * @implSpec The order of potential initialization triggering is specified as:
> 
> Do we really need to specify this?

This is a corner case, but we might have two uninitialized LCs. The order in which they get computed might be significant (e.g., they operate on shared data structures).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426507366
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426513556

From mcimadamore at openjdk.org  Mon Oct 13 14:33:13 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 14:33:13 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v7]
In-Reply-To: <EQ3-nnbKwCkMFZlW5cpSlia8Su2xKgvsNU6XUDefQ3Q=.3323f66a-8b10-4f5f-9374-0249983ee38d@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <o3w7K129sBV4DQKXHIHW1OVv_tZnJJ9KjsgSbVQRUhQ=.48d8ca41-c15b-4d55-980b-bbeab1cbb51c@github.com>
 <EQ3-nnbKwCkMFZlW5cpSlia8Su2xKgvsNU6XUDefQ3Q=.3323f66a-8b10-4f5f-9374-0249983ee38d@github.com>
Message-ID: <vIyoyRk2KDwELMXXH1mZrV-YyjTCNNGT_JDDZn6KRxg=.072079c3-e283-4ee5-972c-7b618c81142d@github.com>

On Mon, 13 Oct 2025 14:25:58 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/LazyConstant.java line 276:
>> 
>>> 274:      * this method might block or throw.
>>> 275:      *
>>> 276:      * @implSpec The order of potential initialization triggering is specified as:
>> 
>> Do we really need to specify this?
>
> This is a corner case, but we might have two uninitialized LCs. The order in which they get computed might be significant (e.g., they operate on shared data structures).

I understand that the order might be significant -- but I still wonder if we should specify that order. This seems to add constraints to the implementation. Do we really want clients to rely on the order in which lazy constants are initialized when calling `equals` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426522315

From mcimadamore at openjdk.org  Mon Oct 13 14:37:27 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 14:37:27 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v7]
In-Reply-To: <EQ3-nnbKwCkMFZlW5cpSlia8Su2xKgvsNU6XUDefQ3Q=.3323f66a-8b10-4f5f-9374-0249983ee38d@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <o3w7K129sBV4DQKXHIHW1OVv_tZnJJ9KjsgSbVQRUhQ=.48d8ca41-c15b-4d55-980b-bbeab1cbb51c@github.com>
 <EQ3-nnbKwCkMFZlW5cpSlia8Su2xKgvsNU6XUDefQ3Q=.3323f66a-8b10-4f5f-9374-0249983ee38d@github.com>
Message-ID: <PwdbZAd-GEbpUF9sIFPB5PYPqSNieFuYCoEHCsgU6IQ=.c98a02c0-1f7d-43f7-bcde-f7e00a5694ac@github.com>

On Mon, 13 Oct 2025 14:23:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/LazyConstant.java line 192:
>> 
>>> 190:  *          The {@code LazyConstant} type is not {@link Serializable}.
>>> 191:  *          <p>
>>> 192:  *          It is not recommended putting lazy constants into equality-based collections
>> 
>> Not sure what you mean here. It seems like the javadoc for `equals` says that it triggers initialization, so it should be ok?
>
> Formally, it is ok, but may result in strange side effects if we, for example, put a key of type LazyConstant in a map. It will then be initialized immediately (upon `map.put()`), and the put operation can therefore have non-obvious side effects.

I think it would be better to link to `equals` more explicitly -- e.g. "As equals and hashCode might trigger the initialization of a lazy constant, it is recommended to avoid storing lazy constants into equality-based collections (or similar constructs) as their addition (e.g. via `Map::put`, or `Set::add`) might result in subtle side-effects).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426535831

From mcimadamore at openjdk.org  Mon Oct 13 14:44:09 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Oct 2025 14:44:09 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v7]
In-Reply-To: <GphZBYlM0eL9LEaj0-3gNxp_8Bu1cpeGp2EZHUSDmNs=.25a985c7-65e2-4e97-ad14-bb56fd515081@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <GphZBYlM0eL9LEaj0-3gNxp_8Bu1cpeGp2EZHUSDmNs=.25a985c7-65e2-4e97-ad14-bb56fd515081@github.com>
Message-ID: <cLuf73uxsm0P8Y5Ak2gfd1VaA9V10vEzfC_o5eiF_D4=.f5dda44e-3621-422f-9c82-0066316b3f08@github.com>

On Mon, 13 Oct 2025 14:33:06 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/LazyConstant.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

src/java.base/share/classes/java/lang/LazyConstant.java line 287:

> 285:      */
> 286:     @Override
> 287:     boolean equals(Object obj);

There is a tension here (same for hashCode). A lazy constant is a mutable cell that can be updated only once, given some computing function. When you compare two lazy constants, you can either compare the mutable cell (e.g. the pointer to the memory location where the constant will be eventually stored), or you can compare the constants. Here, the javadoc decides to opt for comparing the constants -- but this might be problematic, as now `equals` can throw exceptions too (and/or result in blocking, as you say in the javadoc). So, I'm not too sure what's the best option here -- do we have an idea of how frequent it is to want to compare two lazy constants "by value" ?

(for reference, we have no precedent for this: `ClassValue`, `ScopedValue` and `ThreadLocal` do not redefine equals/hashCode).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426553275

From dfuchs at openjdk.org  Mon Oct 13 14:48:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 14:48:03 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
Message-ID: <4eeQ0CbilDZk7lV_uym2Ljc2ml2scqzdXngypsxJd2g=.aa15ac6e-a2f7-4b45-b508-bc3d522f851f@github.com>

On Thu, 2 Oct 2025 16:19:56 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 728:

> 726: 
> 727:     // flush and close output stream
> 728:     private void flushAndCloseOutputStream() {

If this method no longer closes the output stream it should no longer be called `flushAndCloseOutputStream()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2426518167

From dfuchs at openjdk.org  Mon Oct 13 14:48:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 13 Oct 2025 14:48:06 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <tduqK45Wvxn--nWm13DAhCuVPJoXW_qWnRhwEstfjjM=.25ea42f0-7c03-4642-81d0-25abe246dc74@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <18wOsB1ycd6JEaIieaDFcDhoJMedcBTokO6gowhWLGA=.2098adf5-96b3-41fa-a9c3-6cc7d1af7398@github.com>
 <tduqK45Wvxn--nWm13DAhCuVPJoXW_qWnRhwEstfjjM=.25ea42f0-7c03-4642-81d0-25abe246dc74@github.com>
Message-ID: <28HuiAgul6pkdGJSzNJSDFejHnJ7GoZ-k-WmNs1p2vw=.919a1733-ecd7-4624-9451-af39309f3778@github.com>

On Mon, 13 Oct 2025 14:00:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the code
>
> src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 497:
> 
>> 495:         } catch (IOException ioEx) {
>> 496:             //ignore the error;
>> 497:         }
> 
> [OK - I missed that the cleanup method had been modified to no longer close the socket]
> 
> But another issue is that this method attempts to modify the state of the connection without holding the connection lock. This is not good.

One possibility could be to move this code to the connection so that it can participate in the locking.

However - I'm concerned that this proposed fix will reintroduced https://bugs.openjdk.org/browse/JDK-8313657

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2426563973

From abarashev at openjdk.org  Mon Oct 13 15:07:37 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 13 Oct 2025 15:07:37 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v5]
In-Reply-To: <JKAovYFrK9obqTxa6c4Mbd8nzbQLUezk4dAB6TL4ClM=.b1f0af49-8fe2-433f-af90-4937a318529e@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <6cWXULLkfTIZMOXSGBNdws3uB-Fi7--swunqaJd4QkY=.c41f9f1d-4f60-4974-a39a-a494b23d2b8b@github.com>
 <UZPhFZsEh4s459hySMvY4SdUzjwpE6W4BZUsH7Md7tI=.a1cf7be9-a0c1-47d4-bfc7-7ca589d27ac7@github.com>
 <JKAovYFrK9obqTxa6c4Mbd8nzbQLUezk4dAB6TL4ClM=.b1f0af49-8fe2-433f-af90-4937a318529e@github.com>
Message-ID: <fIFdtZO-sdrYKoCiZ_jMgjwamZvRqq0-Eruz2tqFTZQ=.7dc66899-d6dc-4e50-8910-0702a2a019a5@github.com>

On Mon, 13 Oct 2025 13:56:11 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 541:
>> 
>>> 539:                 new InetSocketAddress(HOST, SERVER_PORT);
>>> 540:         InetSocketAddress clientSocketAddress =
>>> 541:                 new InetSocketAddress(HOST, CLIENT_PORT);
>> 
>> Don't fix ports here. There's a nonzero chance that some other process will take these ports before you.
>> 
>> Use port zero here. The port numbers used in SSLEngine don't need to match the datagram socket, they just need to match between the initial session and the resumption.
>
> Good catch, thanks!

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2426615664

From abarashev at openjdk.org  Mon Oct 13 15:07:40 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 13 Oct 2025 15:07:40 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v5]
In-Reply-To: <UZPhFZsEh4s459hySMvY4SdUzjwpE6W4BZUsH7Md7tI=.a1cf7be9-a0c1-47d4-bfc7-7ca589d27ac7@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <6cWXULLkfTIZMOXSGBNdws3uB-Fi7--swunqaJd4QkY=.c41f9f1d-4f60-4974-a39a-a494b23d2b8b@github.com>
 <UZPhFZsEh4s459hySMvY4SdUzjwpE6W4BZUsH7Md7tI=.a1cf7be9-a0c1-47d4-bfc7-7ca589d27ac7@github.com>
Message-ID: <PPMB8XT16LKDTCLwY26nxpChP7vKj0V36vhIyQi9NU0=.894639d4-7302-44bc-afdd-b9b713fd53d1@github.com>

On Mon, 13 Oct 2025 13:26:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The fix and unit test for session resumption case
>
> test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java line 630:
> 
>> 628:     static int findAvailablePort() {
>> 629:         try (var socket = new DatagramSocket(0)) {
>> 630:             return socket.getLocalPort();
> 
> You can use a hardcoded number here; it doesn't need to correspond to a real socket.

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2426616921

From abarashev at openjdk.org  Mon Oct 13 15:17:06 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 13 Oct 2025 15:17:06 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v6]
In-Reply-To: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
Message-ID: <sLXKusgRJy9O4rAlxvNAhgV-EHJQeSsk44PqMGaltok=.4c12da4b-5519-45f1-ad52-75ae136740c3@github.com>

> If the NewSessionTicket message is lost, the handshake fails on the client side with:
> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27677/files
  - new: https://git.openjdk.org/jdk/pull/27677/files/5d34fd5c..bcfaa2e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27677&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27677&range=04-05

  Stats: 47 lines in 3 files changed: 13 ins; 23 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27677/head:pull/27677

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

From duke at openjdk.org  Mon Oct 13 16:52:00 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 13 Oct 2025 16:52:00 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v2]
In-Reply-To: <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@github.com>
Message-ID: <jCbxReR2JSGBiZhPw3QWRFp-rKNcpvkpOIQKKzzj5eQ=.7e9eea38-658a-4437-b853-5d780af246e8@github.com>

On Mon, 13 Oct 2025 13:54:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant field

src/java.base/share/classes/java/util/AbstractMap.java line 335:

> 333:      */
> 334:     @Stable
> 335:     transient Set<K>        keySet;

Are?all?uses of?this?field in?`java.util` able?to?handle the?`@Stable`ness of?this?field correctly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2426844190

From hchao at openjdk.org  Mon Oct 13 17:04:22 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 13 Oct 2025 17:04:22 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v3]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <ao3w5G6aj21Pdf1AmTTzibglHCl8lFvOz_Ht0RS_QOA=.562a4757-9d51-4393-9658-59c49c735bfc@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:

 - Rename NAMED_GROUP_KEM from PQC to KEM
 - Updates with review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/3c0e91ed..5457a73c

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

  Stats: 24 lines in 3 files changed: 16 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27614/head:pull/27614

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

From hchao at openjdk.org  Mon Oct 13 17:10:09 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 13 Oct 2025 17:10:09 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v3]
In-Reply-To: <ao3w5G6aj21Pdf1AmTTzibglHCl8lFvOz_Ht0RS_QOA=.562a4757-9d51-4393-9658-59c49c735bfc@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <ao3w5G6aj21Pdf1AmTTzibglHCl8lFvOz_Ht0RS_QOA=.562a4757-9d51-4393-9658-59c49c735bfc@github.com>
Message-ID: <foUmEOnK_SFoBWiPR5OA4XwHFgChKksGL9DAYK35bVo=.1ac0b902-b284-43a0-99dd-e822e04e1255@github.com>

On Mon, 13 Oct 2025 17:04:22 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rename NAMED_GROUP_KEM from PQC to KEM
>  - Updates with review comments

New groups added to test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/27614#issuecomment-3398357133

From hchao at openjdk.org  Mon Oct 13 17:10:11 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 13 Oct 2025 17:10:11 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v3]
In-Reply-To: <aSCoxYZHhVZ0vTRwC1gIGSbvKpvdbJnz__eZtOWpBLQ=.eef3a7e4-e587-47a5-bf66-990502a3bde5@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
 <2eDcr2BqION52VUhVBxpHNnHgJ7H-yODIbhrLkEqPUk=.912193fb-824a-4fdd-bbe9-93cd761dc9e0@github.com>
 <aSCoxYZHhVZ0vTRwC1gIGSbvKpvdbJnz__eZtOWpBLQ=.eef3a7e4-e587-47a5-bf66-990502a3bde5@github.com>
Message-ID: <-OdcFveRslTu9bBX7lJN40CWnYdL1R_WGFwpFiM_l4w=.5cd6c759-a9b8-4693-8587-48925e2124e0@github.com>

On Tue, 7 Oct 2025 20:16:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Comment added.
>
> Maybe we can rename "PQC" to "KEM" to be consistent.

Rename done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2426878279

From hchao at openjdk.org  Mon Oct 13 17:10:12 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 13 Oct 2025 17:10:12 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v3]
In-Reply-To: <oDu6SgIENutIjVC4IxqOPO3lFDG0oqwJE7U2ekUGPYQ=.a226b985-7c30-43d6-b3a3-00a508e360ed@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
 <yMGhnOT8WxEd-y_dNQAaTFoGr1z9n9p6fub6j44rr3c=.127191ee-1f7a-4288-a2f1-d21083b4640b@github.com>
 <5EkdnKfJtxe3vsLOKtBFIY-az7weziM5gUVQsGKlUF4=.0f444330-cc27-4796-9424-9a9666afaf5c@github.com>
 <oDu6SgIENutIjVC4IxqOPO3lFDG0oqwJE7U2ekUGPYQ=.a226b985-7c30-43d6-b3a3-00a508e360ed@github.com>
Message-ID: <b1u6Keqe_1dRTLhKfR9Bcjs5jt-yC9UR6igVu4FRr04=.3c802531-6cb3-4e70-9ca5-7f527b0960a7@github.com>

On Sun, 5 Oct 2025 13:47:36 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> The change is I think ok, doesn?t make much of a difference for most cases I was just thinking it needed its own commit and ticket reference but if it was intentional fine as well.
>
> I think you make a fair point here.  It probably deserves its own change, JBS entry, CSR, etc.  We'll leave them in for now.

ffdhe6144 and 8192 added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2426879451

From hchao at openjdk.org  Mon Oct 13 17:10:15 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 13 Oct 2025 17:10:15 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v3]
In-Reply-To: <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <C-QlNXxC41h0GRlPzSgP4wSKKkht0NoHjsouQK5XAcs=.b06457e3-ac7c-40b7-8853-5c5d149110e5@github.com>
Message-ID: <igNPWnFMFetP5FshVp4mfareD-tIJ_oBIAMecQo2SKo=.52f673fc-67bc-468c-b369-42df2b9956b8@github.com>

On Fri, 3 Oct 2025 17:23:37 GMT, Bernd <duke at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Rename NAMED_GROUP_KEM from PQC to KEM
>>  - Updates with review comments
>
> src/java.base/share/classes/sun/security/util/Hybrid.java line 75:
> 
>> 73: 
>> 74:     private static AlgorithmParameterSpec getSpec(String name) {
>> 75:         if (name.startsWith("secp")) {
> 
> This seems to be repeated multiple times including the case sensitive string, maybe have an APS.isGenericEC() helper?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2426879655

From hchao at openjdk.org  Mon Oct 13 17:10:17 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 13 Oct 2025 17:10:17 GMT
Subject: RFR: 8314323: TLS 1.3 Hybrid Key Exchange [v2]
In-Reply-To: <9vRpBCW-57VDb5ASOBF7ftNgj1-Njad6HQedTIy9qWE=.106f604a-a977-486d-9047-ee0c309fcc16@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <osmzSDvG9ftU7Ha53P0VNZIl29cH0YN3O8ToCsNd-0g=.3159d9c7-6505-416e-8ba6-39661ec7b942@github.com>
 <9vRpBCW-57VDb5ASOBF7ftNgj1-Njad6HQedTIy9qWE=.106f604a-a977-486d-9047-ee0c309fcc16@github.com>
Message-ID: <Ct-fDQEeaAvtcVTe0AVSTM3AzTqDnmyygzzs5cjvgYk=.3d4a3416-95de-4b2f-9c98-0c1cdae6fccb@github.com>

On Mon, 6 Oct 2025 13:57:48 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates with review comments
>
> test/jdk/sun/security/ssl/CipherSuite/DisabledCurve.java line 31:
> 
>> 29:         DisabledCurve DISABLE_NONE PASS
>> 30:  * @run main/othervm -Djdk.tls.namedGroups="secp384r1"
>> 31:         DisabledCurve secp384r1 FAIL
> 
> This test case fails whether we specify `-Djdk.tls.namedGroups="secp384r1"` or not, because the test certificate also uses `secp384r1` algorithm in the signature.

This is an exsiting test entry, and perahps filing a separate ticket if any change shall be made.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2426883325

From ascarpino at openjdk.org  Mon Oct 13 17:22:25 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 13 Oct 2025 17:22:25 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>

> Hi
> 
> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
> 
> - Renamed the name of `PEMRecord` class to `PEM`.
> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
> 
> thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/db913c3c..3e183c5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=04-05

  Stats: 21 lines in 3 files changed: 14 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147

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

From abarashev at openjdk.org  Mon Oct 13 17:28:06 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 13 Oct 2025 17:28:06 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v7]
In-Reply-To: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
Message-ID: <3NyWRChxFJ0TOzOSX9oYNxoiYb0OM1SbcTHHArBueEE=.6f390963-ef3a-40c4-b01e-3fe5b0c5cf79@github.com>

> If the NewSessionTicket message is lost, the handshake fails on the client side with:
> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Restore "createSSLEngine" access privileges to make existing tests pass

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27677/files
  - new: https://git.openjdk.org/jdk/pull/27677/files/bcfaa2e1..13271c2e

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

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

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

From duke at openjdk.org  Mon Oct 13 18:08:53 2025
From: duke at openjdk.org (duke)
Date: Mon, 13 Oct 2025 18:08:53 GMT
Subject: Withdrawn: 8365608: Test is skipped without skip exception
 /test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java
In-Reply-To: <pKQHmZhhKAlI92KpUp9NQBxRiNz1Tm0prC5mh2fb5G4=.8ec9f6f6-727f-4530-880a-3a43369437be@github.com>
References: <pKQHmZhhKAlI92KpUp9NQBxRiNz1Tm0prC5mh2fb5G4=.8ec9f6f6-727f-4530-880a-3a43369437be@github.com>
Message-ID: <6PdhqM13_5twO-gxPkGAWNrW7pTs66th76DQQ12EsJ4=.a67ffca7-8344-40a6-886b-489603cd583f@github.com>

On Fri, 15 Aug 2025 17:13:53 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Replaced skip messages with skip exceptions

This pull request has been closed without being integrated.

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

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

From ascarpino at openjdk.org  Mon Oct 13 19:20:38 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 13 Oct 2025 19:20:38 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <29jAiuBqIdivXhkbUJ1tS68VM9-i9HvX6cDuI1EjiPE=.4b7ee7c5-64c7-40ea-b9ee-70403116e04f@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <29jAiuBqIdivXhkbUJ1tS68VM9-i9HvX6cDuI1EjiPE=.4b7ee7c5-64c7-40ea-b9ee-70403116e04f@github.com>
Message-ID: <T0-_5Bln9xOd8uH9BEY6ZHxgdcLJuX5rneDWiPt8Pko=.7202a853-60be-46f6-a086-30ff8e271b64@github.com>

On Fri, 3 Oct 2025 14:42:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed some decoder comments
>
> src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java line 252:
> 
>> 250:                 int version = seq.data.getInteger();
>> 251:                 if (version == 1) { // EC
>> 252:                     byte[] oct = seq.data.getOctetString();  // private key
> 
> If you call `seq.data.getDerValue()` then the return value uses the original array with an offset and a length. So there is no need to call `Arrays.fill` next.

cool, thanks.. I didn't realize it didn't make a`getDerValue` didn't make a copy.

> src/java.base/share/classes/sun/security/util/Pem.java line 376:
> 
>> 374:             SharedSecrets.getJavaSecuritySpecAccess().
>> 375:                 clearEncodedKeySpec(p8KeySpec);
>> 376:             keySpec.clearPassword();
> 
> Why are the lines above indented? Were you trying to add a try-finally here?

Yes, I fixed that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2423026619
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2423065762

From ascarpino at openjdk.org  Mon Oct 13 19:20:41 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 13 Oct 2025 19:20:41 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <rG6-ppN7qVilHgYC3CIVpNYwUsHBR9K8MoJsaJPF8AE=.1933f0d9-f45f-4177-9388-b7ca12a51da5@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <rG6-ppN7qVilHgYC3CIVpNYwUsHBR9K8MoJsaJPF8AE=.1933f0d9-f45f-4177-9388-b7ca12a51da5@github.com>
Message-ID: <9ShRvp-TUqUUwmOK3xkEZxVt5h7PmcdU99bzNuRBfuE=.262af995-1666-453a-a8d6-db9e4fdc1f4b@github.com>

On Thu, 2 Oct 2025 20:23:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed some decoder comments
>
> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 124:
> 
>> 122:                         "the given PublicKey");
>> 123:                 }
>> 124:                 version = V1;
> 
> Why do you set the version to V1 here? There is a public and private key.

The issue is EC SEC1v2 uses a V1 version, unlike PKCS#8, but since the original encoding is returned, I can leave version number unchanged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2423065359

From mbalao at openjdk.org  Mon Oct 13 22:06:28 2025
From: mbalao at openjdk.org (Martin Balao Alonso)
Date: Mon, 13 Oct 2025 22:06:28 GMT
Subject: RFR: 8225739: sun/security/pkcs11/tls/tls12/FipsModeTLS12.java is
 not reliable [v2]
In-Reply-To: <3Y-OWPpeWf2LfdUUllVANzvs9LnldUWFMKL0IaMowB0=.a25b90df-fbc1-42f3-b132-9f3c4818e480@github.com>
References: <3Y-OWPpeWf2LfdUUllVANzvs9LnldUWFMKL0IaMowB0=.a25b90df-fbc1-42f3-b132-9f3c4818e480@github.com>
Message-ID: <liFqHduCCuQJOdmD_E2EPPD0BHNCBxhhZBPRaJaJduI=.7130b0b0-018e-4fe4-acd7-b8909ce6ff4e@github.com>

> Hello,
> 
> I would like to propose a solution for this test that makes it more clear when it's skipped.
> 
> Regards,
> Martin.-

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

 - Merge openjdk:master
   
   Fix trivial conflict in the copyright of the test.
   
   Old path:
   test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java
   
   New path:
   test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java
 - 8225739: sun/security/pkcs11/tls/tls12/FipsModeTLS12.java is not reliable.

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

Changes: https://git.openjdk.org/jdk/pull/23177/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23177&range=01
  Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23177/head:pull/23177

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

From fferrari at openjdk.org  Mon Oct 13 22:11:09 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 13 Oct 2025 22:11:09 GMT
Subject: RFR: 8225739: sun/security/pkcs11/tls/tls12/FipsModeTLS12.java is
 not reliable [v2]
In-Reply-To: <3W8oXM7Q_0dMJ2ObHMIwEqSXTUaY5z-LzRb9c_yMCYM=.c645dde9-403e-4ed9-af85-1edd07392a24@github.com>
References: <3Y-OWPpeWf2LfdUUllVANzvs9LnldUWFMKL0IaMowB0=.a25b90df-fbc1-42f3-b132-9f3c4818e480@github.com>
 <3W8oXM7Q_0dMJ2ObHMIwEqSXTUaY5z-LzRb9c_yMCYM=.c645dde9-403e-4ed9-af85-1edd07392a24@github.com>
Message-ID: <Djeod661omH_uN_TqQFJy4-UltuGW_8Pu1DMftzyd9k=.acf93c2e-b5b7-4119-a5c2-6c186d2a8a11@github.com>

On Fri, 7 Feb 2025 20:49:09 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Martin Balao Alonso has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge openjdk:master
>>    
>>    Fix trivial conflict in the copyright of the test.
>>    
>>    Old path:
>>    test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java
>>    
>>    New path:
>>    test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java
>>  - 8225739: sun/security/pkcs11/tls/tls12/FipsModeTLS12.java is not reliable.
>
> test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java line 95:
> 
>> 93:                 System.out.println(e);
>> 94:             }
>> 95:             throw new SkippedException("Test skipped: failure during " +
> 
> I think we should update test to fail if call to `initialize` fails with any other exception than `SkippedException` which is thrown from call to `initSecmod` if NSS library fails. So you can remove try-catch here.

Hi @rhalade,

I'm continuing with @martinuy's work on this issue. Are you sure the [`loadNSPR` failure inside `initSecmod`](https://github.com/openjdk/jdk/blob/jdk-26+19/test/jdk/sun/security/pkcs11/SecmodTest.java#L48-L51) is the only case we are observing in [JDK-8225739](https://bugs.openjdk.org/browse/JDK-8225739 "sun/security/pkcs11/tls/tls12/FipsModeTLS12.java is not reliable")?

I'm asking because [the previous `getNSSLibDir` call](https://github.com/openjdk/jdk/blob/jdk-26+19/test/jdk/sun/security/pkcs11/SecmodTest.java#L47) can also fail in the following cases:

* When pointing the test to find NSS inside a nonexistent directory:
  ```
  java.nio.file.NoSuchFileException: /tmp/lib64
      at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
      at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108)
      at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
      at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:57)
      at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:162)
      at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
      at java.base/java.nio.file.Files.readAttributes(Files.java:1702)
      at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:216)
      at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:268)
      at java.base/java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:306)
      at java.base/java.nio.file.FileTreeIterator.<init>(FileTreeIterator.java:69)
      at java.base/java.nio.file.Files.find(Files.java:3649)
      at PKCS11Test.findNSSLibrary(PKCS11Test.java:792)
      at PKCS11Test.fetchNssLib(PKCS11Test.java:788)
      at PKCS11Test.fetchNssLib(PKCS11Test.java:767)
      at PKCS11Test.getNSSLibPath(PKCS11Test.java:257)
      at PKCS11Test.getNSSLibDir(PKCS11Test.java:243)
      at PKCS11Test.getNSSLibDir(PKCS11Test.java:239)
      at SecmodTest.initSecmod(SecmodTest.java:47)
      at FipsModeTLS.initialize(FipsModeTLS.java:448)
      ... 5 more
  ```
* When pointing the test to find NSS inside an empty directory:
  ```
  java.lang.RuntimeException: NSS library "libnss3.so" was not found in /tmp/lib64
      at PKCS11Test.lambda$findNSSLibrary$1(PKCS11Test.java:797)
      at java.base/java.util.Optional.orElseThrow(Optional.java:403)
      at PKCS11Test.findNSSLibrary(PKCS11Test.java:796)
      at PKCS11Test.fetchNssLib(PKCS11Test.java:788)
      at PKCS11Test.fetchNssLib(PKCS11Test.java:767)
      at PKCS11Test.getNSSLibPath(PKCS11Test.java:257)
      at PKCS11Test.getNSSLibDir(PKCS11Test.java:243)
      at PKCS11Test.getNSSLibDir(PKCS11Test.java:239)
      at SecmodTest.initSecmod(SecmodTest.java:47)
      at FipsModeTLS.initialize(FipsModeTLS.java:448)
      ... 5 more
  ```
* When using a flawed library (`libnss3.so` and `libsoftokn3.so` replaced by unrelated libraries):
  ```
  java.lang.NullPointerException: Symbol not found: NSS_VersionCheck
      at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.nssVersionCheck(Native Method)
      at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.fetchVersions(Secmod.java:120)
      at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:231)
      at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:220)
      at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:125)
      at PKCS11Test.getSunPKCS11(PKCS11Test.java:158)
      at PKCS11Test.getSunPKCS11(PKCS11Test.java:150)
      at FipsModeTLS.initialize(FipsModeTLS.java:451)
      ... 5 more
  ```

How about the following change?


diff --git a/test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java b/test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java
index 1aece0a00e9..c8a9fe14419 100644
--- a/test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java
+++ b/test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java
@@ -92,15 +92,7 @@ public static void main(String[] args) throws Exception {
         // reduce the limit to trigger a key update later
         Security.setProperty("jdk.tls.keyLimits",
                 "AES/GCM/NoPadding KeyUpdate 10000");
-        try {
-            initialize();
-        } catch (Exception e) {
-            if (enableDebug) {
-                System.out.println(e);
-            }
-            throw new SkippedException("Test skipped: failure during " +
-                    "initialization.");
-        }
+        initialize();
 
         if (shouldRun()) {
             // Test against JCE
@@ -118,9 +110,6 @@ public static void main(String[] args) throws Exception {
     }
 
     private static boolean shouldRun() {
-        if (sunPKCS11NSSProvider == null) {
-            return false;
-        }
         try {
             String proto = System.getProperty("jdk.tls.client.protocols");
             if ("TLSv1.3".equals(proto)) {
@@ -455,12 +444,13 @@ private static void initialize() throws Exception {
         //  1. SunPKCS11 (with an NSS FIPS mode backend)
         //  2. SUN (to handle X.509 certificates)
         //  3. SunJSSE (for a TLS engine)
-
-        if (initSecmod() == false) {
-            return;
+        try {
+            initSecmod();
+            String configName = BASE + SEP + "nss.cfg";
+            sunPKCS11NSSProvider = getSunPKCS11(configName);
+        } catch (Exception e) {
+            throw new SkippedException("SunPKCS11 initialization failed", e);
         }
-        String configName = BASE + SEP + "nss.cfg";
-        sunPKCS11NSSProvider = getSunPKCS11(configName);
         System.out.println("SunPKCS11 provider: " + sunPKCS11NSSProvider);
 
         List<Provider> installedProviders = new LinkedList<>();



If I don't include this new `try`/`catch` inside `initialize`, could you execute a similar regression to the one where this issue was found?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23177#discussion_r2427408511

From duke at openjdk.org  Tue Oct 14 03:59:08 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 14 Oct 2025 03:59:08 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
Message-ID: <tU3THcc719OPGwLGc3PrOLFmcjJLO6yHzSO5jLHFibA=.da11816a-e8e4-472f-b70e-74cc895fd13c@github.com>

On Mon, 13 Oct 2025 17:22:25 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates

src/java.base/share/classes/java/security/DEREncodable.java line 58:

> 56: public sealed interface DEREncodable permits AsymmetricKey, KeyPair,
> 57:     PKCS8EncodedKeySpec, X509EncodedKeySpec, EncryptedPrivateKeyInfo,
> 58:     X509Certificate, X509CRL, PEM {

Do we need to add any javadoc note here stating why PEM replaces PEMRecord to help understand intent?

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

> 66:  * metadata that accompanies the PEM data. This value was not defensively
> 67:  * copied by the constructor, and the {@link #leadingData()} method does not
> 68:  * return a clone.

I see the Javadoc already notes that leadingData isn?t defensively copied or cloned. Given that PEM is a record (and callers might assume immutability), should we clarify ownership semantics a bit more ? e.g., that the caller must not modify the array after passing it in?

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

> 230:                     }
> 231:                     byte[] p8 = Pem.decryptEncoding(
> 232:                         decoder.decode(pem.content()), password.getPassword());

Should we need a null check for pem and a short defensive check for pem.content() being empty/blank before attempting decode? Also do we explicitly specify why explicit zeroing is used ?

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

> 231:                     byte[] p8 = Pem.decryptEncoding(
> 232:                         decoder.decode(pem.content()), password.getPassword());
> 233:                     DEREncodable d = Pem.toDEREncodable(p8, true, factory);

If toDEREncodable may throw, do we need to guarantee zeroing on all paths in case of success or exception?

src/java.base/share/classes/java/security/PEMEncoder.java line 286:

> 284:      * privateKeyEncoding will be zeroed when the method returns
> 285:      */
> 286:     private String buildKey(byte[] publicEncoding, byte[] privateEncoding) {

Do we need to explicitly document argument contracts: which combination corresponds to which PEM types here ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2427844413
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2427845013
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2427845632
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2427845911
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2427846490

From djelinski at openjdk.org  Tue Oct 14 09:44:38 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 14 Oct 2025 09:44:38 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v7]
In-Reply-To: <3NyWRChxFJ0TOzOSX9oYNxoiYb0OM1SbcTHHArBueEE=.6f390963-ef3a-40c4-b01e-3fe5b0c5cf79@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <3NyWRChxFJ0TOzOSX9oYNxoiYb0OM1SbcTHHArBueEE=.6f390963-ef3a-40c4-b01e-3fe5b0c5cf79@github.com>
Message-ID: <L_okNtPdgFNssPYw1PPwEsBaRw2MU7sbZxXg-eIewWE=.606fbb16-821e-4914-b268-5b548d86bc0a@github.com>

On Mon, 13 Oct 2025 17:28:06 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> If the NewSessionTicket message is lost, the handshake fails on the client side with:
>> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore "createSSLEngine" access privileges to make existing tests pass

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27677#pullrequestreview-3334751833

From dholmes at openjdk.org  Tue Oct 14 11:07:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Oct 2025 11:07:47 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
Message-ID: <XSak1YrP_B846xlT_rbM8gF8ssAbl9CypoqqCSWozBY=.dc8c9638-85cf-4510-8114-d02075f597d1@github.com>

On Wed, 8 Oct 2025 08:15:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - Add testUnreflectExpectingWarning
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

Hotspot changes look fine. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3335034246

From myankelevich at openjdk.org  Tue Oct 14 11:32:44 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 14 Oct 2025 11:32:44 GMT
Subject: RFR: 8360395: sun/security/tools/keytool/i18n.java user country is
 current user location instead of the language
Message-ID: <RhPO5u_2ArMs5xdcJ8vRnTmi8t0PtVdzQAopkKpHPEc=.590d7d13-3756-45ed-9973-4ecc3f683dcb@github.com>

User location would now follow the language location, not the current location of the test machine

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

Commit messages:
 - JDK-8360395: sun/security/tools/keytool/i18n.java user country is current user location instead of the language

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

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

From vyazici at openjdk.org  Tue Oct 14 11:33:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 14 Oct 2025 11:33:20 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
Message-ID: <2Ij8EYFqIDDqSIA7QCNejs8yMSVeKeLywF82ayw8DzQ=.7fa24297-a8f0-414c-8253-1e2ffd81b60b@github.com>

On Wed, 8 Oct 2025 08:15:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - Add testUnreflectExpectingWarning
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 80:

> 78: 
> 79:     /**
> 80:      * Test executable JAR with code thatyses  Lookup.unreflectSetter to get MH to a

Suggestion:

     * Test executable JAR with code that uses Lookup.unreflectSetter to get MH to a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2428816748

From vyazici at openjdk.org  Tue Oct 14 11:38:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 14 Oct 2025 11:38:11 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v8]
In-Reply-To: <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
 <d0VymukMBrH529qrMuTFkLIs3BBRHfmMxVTBy2MTj0g=.69a858d4-7379-48bb-98e4-37aaf958904d@github.com>
Message-ID: <A6-9e6Q2pHdZNJSkxX7iMj_jetrLXfMAIc_bdx8jAGA=.87d14a7a-58e0-419d-bac9-27a056e1218e@github.com>

On Wed, 8 Oct 2025 08:15:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>> 
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>> 
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>> 
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Suppress warnings from some tests
>  - Change -Xcheck:jni to be warning rather than fatal error
>  - Merge branch 'master' into JDK-8353835
>  - Simplify filter
>  - Merge branch 'master' into JDK-8353835
>  - Update Xcheck:jni description
>  - Add testUnreflectExpectingWarning
>  - Merge branch 'master' into JDK-8353835
>  - Add test for -Xlog:jni=debug
>  - Merge branch 'master' into JDK-8353835
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/2ac24bf1...635556aa

I've reviewed the `test/` changes, and they LGTM.

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3335136796

From alanb at openjdk.org  Tue Oct 14 13:47:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Oct 2025 13:47:55 GMT
Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
 [v9]
In-Reply-To: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
References: <sUAJM4UfwbZXyqSER7z048e_YhSpciMk9MTgshBh8sU=.c3f255cd-afc9-41fe-937b-b5b0b058e592@github.com>
Message-ID: <3JlQE_SY_oPghJ13xGjdALIADPSp4dajFsMfrw3vCA0=.434d3878-0d61-4518-af3c-636817cbf3dc@github.com>

> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
> 
> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
> 
> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a warning and -Xlog:jni=debug logs a message to help identity JNI code that mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err without a warning, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
> 
> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - Fix typo in test comment
 - Merge branch 'master' into JDK-8353835
 - Merge branch 'master' into JDK-8353835
 - Suppress warnings from some tests
 - Change -Xcheck:jni to be warning rather than fatal error
 - Merge branch 'master' into JDK-8353835
 - Simplify filter
 - Merge branch 'master' into JDK-8353835
 - Update Xcheck:jni description
 - Add testUnreflectExpectingWarning
 - ... and 34 more: https://git.openjdk.org/jdk/compare/90cf3a20...1d0cb6c9

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

Changes: https://git.openjdk.org/jdk/pull/25115/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=08
  Stats: 4852 lines in 70 files changed: 4667 ins; 54 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/25115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115

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

From abarashev at openjdk.org  Tue Oct 14 18:18:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 14 Oct 2025 18:18:51 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v3]
In-Reply-To: <DPvBPGbjH6Pb13RvMBy6D-on6VY-ObOVq7dRzDnRaLE=.6991c53c-da4c-457d-9bf7-431b950ef89b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <MIFOZmCTj6r3YfGNkcSCkY1ZZmdgbkHYnqU_SipHZTg=.93f4e70b-1dea-4c3f-a633-bb697bdde1cd@github.com>
 <DPvBPGbjH6Pb13RvMBy6D-on6VY-ObOVq7dRzDnRaLE=.6991c53c-da4c-457d-9bf7-431b950ef89b@github.com>
Message-ID: <Cw48p17DgWzXtGwhoHfWC_gtcJltXFvdsKwyTGn5gOM=.bde342e9-bb2a-4cf3-84d9-94bdeced7bef@github.com>

On Sun, 5 Oct 2025 12:21:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 316:
>> 
>>> 314:                 // Skip AlgorithmParameters for KEMs (not supported)
>>> 315:                 if (namedGroupSpec == NamedGroupSpec.NAMED_GROUP_KEM) {
>>> 316:                     if (defaultProviderName == null) {
>> 
>> We assume that if provider is not null then it must be DH without doing any checks to confirm that. It would be cleaner to call getProvider() instead.
>> 
>>> Provider p = getProvider();
>>                     if (p == null) {
>>                         KeyFactory.getInstance(name);
>>                     } else {
>>                         KeyFactory.getInstance(name, p);
>>                     }
>
> Done.

It's actually unchanged, do you plan to do it in the next iteration?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2430049480

From mullan at openjdk.org  Tue Oct 14 18:22:34 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 14 Oct 2025 18:22:34 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
Message-ID: <QKd77sCWYGnd_nsDCw8ca64ciRSKA-UMbBlIJnRcfJA=.5cfb7c94-e275-4a6a-ace9-b44a9ef52061@github.com>

On Mon, 13 Oct 2025 17:22:25 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates

src/java.base/share/classes/java/security/PEM.java line 46:

> 44:  * handle the text content directly, use the decoding methods
> 45:  * {@link PEMDecoder#decode(String, Class)} or
> 46:  * {@link PEMDecoder#decode(InputStream, Class)} with {@code PEM.class} as a

s/a/an/

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

> 64:  * <p> {@code leadingData} is {@code null} if there is no data preceding the PEM
> 65:  * header during decoding.  {@code leadingData} can be useful for reading
> 66:  * metadata that accompanies the PEM data. This value was not defensively

s/was not/is not/

src/java.base/share/classes/java/security/PEM.java line 94:

> 92:      * @param type the PEM type identifier
> 93:      * @param content the Base64-encoded data, excluding the PEM header and
> 94:      *               footer

indent one more space?

src/java.base/share/classes/java/security/PEM.java line 96:

> 94:      *               footer
> 95:      * @param leadingData any non-PEM data read during the decoding process
> 96:      *                    before the PEM header.  This value may be {@code null}

Missing period after null.

src/java.base/share/classes/java/security/PEM.java line 98:

> 96:      *                    before the PEM header.  This value may be {@code null}
> 97:      * @throws IllegalArgumentException if {@code type} is incorrectly
> 98:      * formatted

suggest indenting the second line of the throws javadoc to `IllegalArgumentException`. Same comment on other lines.

src/java.base/share/classes/java/security/PEM.java line 111:

> 109:             type.startsWith("END ")) {
> 110:             throw new IllegalArgumentException("PEM syntax labels found.  " +
> 111:                 "Only the PEM type identifier is allowed");

Missing period after "allowed".

src/java.base/share/classes/java/security/PEM.java line 121:

> 119:      * @param type the PEM type identifier
> 120:      * @param content the Base64-encoded data, excluding the PEM header and
> 121:      *               footer

indent one more space?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430010324
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430026453
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430042789
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430035970
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430046763
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430039670
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430043305

From mullan at openjdk.org  Tue Oct 14 18:22:37 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 14 Oct 2025 18:22:37 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <YawNmD3JifD542wr8AD3cfxrKIQIyY8kTfnd1nPHEp8=.84d4439d-d877-4447-a3cd-997a972cbfd7@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <M4ZBrtG-QdsCAsmPecRmsTU6arjbkrKxT5NuK_TXuhY=.9d66b840-5be9-4a80-976d-de9fe6fff79b@github.com>
 <YawNmD3JifD542wr8AD3cfxrKIQIyY8kTfnd1nPHEp8=.84d4439d-d877-4447-a3cd-997a972cbfd7@github.com>
Message-ID: <WAOEpZsoOiwe0F_VfvYwhpUIO5wH308WYIxNBx0SHVE=.8a340cbc-6dcb-46da-b593-0b68d0126714@github.com>

On Fri, 3 Oct 2025 16:48:28 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/PEM.java line 61:
>> 
>>> 59:  * Common {@code type} values include, but are not limited to:
>>> 60:  * CERTIFICATE, CERTIFICATE REQUEST, ATTRIBUTE CERTIFICATE, X509 CRL, PKCS7,
>>> 61:  * CMS, PRIVATE KEY, ENCRYPTED PRIVATE KEY, RSA PRIVATE KEY, or PUBLIC KEY.
>> 
>> s/RSA PRIVATE KEY/PRIVATE KEY/
>
> "PRIVATE KEY" is earlier in the list and "RSA PRIVATE KEY" is a valid type.

Ok, but is it really common? All the others are listed in RFC 7468 but not this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430024366

From mullan at openjdk.org  Tue Oct 14 18:22:39 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 14 Oct 2025 18:22:39 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <tU3THcc719OPGwLGc3PrOLFmcjJLO6yHzSO5jLHFibA=.da11816a-e8e4-472f-b70e-74cc895fd13c@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
 <tU3THcc719OPGwLGc3PrOLFmcjJLO6yHzSO5jLHFibA=.da11816a-e8e4-472f-b70e-74cc895fd13c@github.com>
Message-ID: <6OEepOj6pw-DDlaYHCubSl5G8DKw3efI2Z6L9ycypIE=.e1fa5348-fd61-40ad-93b3-f03656c93645@github.com>

On Tue, 14 Oct 2025 03:55:54 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates
>
> src/java.base/share/classes/java/security/PEM.java line 68:
> 
>> 66:  * metadata that accompanies the PEM data. This value was not defensively
>> 67:  * copied by the constructor, and the {@link #leadingData()} method does not
>> 68:  * return a clone.
> 
> I see the Javadoc already notes that leadingData isn?t defensively copied or cloned. Given that PEM is a record (and callers might assume immutability), should we clarify ownership semantics a bit more ? e.g., that the caller must not modify the array after passing it in?

The javadoc should clearly describe the mutability aspects, but we can't control what the caller does after that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430031746

From duke at openjdk.org  Tue Oct 14 19:37:18 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 14 Oct 2025 19:37:18 GMT
Subject: RFR: 8326609: AES implementation with updates specified in FIPS
 197
In-Reply-To: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
References: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
Message-ID: <ubkVVk20RwOFMfHh9S9TkmJZER3o4fRm6824J-vaNAw=.ae116228-fd5c-4c81-b9a3-8e48ddf63483@github.com>

On Sat, 23 Aug 2025 06:55:14 GMT, Shawn M Emery <duke at openjdk.org> wrote:

> General:
> 
> -----------
> 
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't refer to the deltas, but rather provide references based on the new AESCrypt.java code itself.
> 
> 
> 
> Correctness:
> 
> -----------------
> 
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: passed, with 51 known failures
> 
> 
> 
> Security:
> 
> -----------
> 
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> 
> 
> Performance:
> 
> ------------------
> 
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options...

Closing this PR, which is replaced with PR #27807.

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

PR Comment: https://git.openjdk.org/jdk/pull/26912#issuecomment-3403318143

From duke at openjdk.org  Tue Oct 14 19:37:19 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 14 Oct 2025 19:37:19 GMT
Subject: Withdrawn: 8326609: AES implementation with updates specified in FIPS
 197
In-Reply-To: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
References: <wRlrE735Fk0OYXgQS6ik6hWhMqHNYSz7-L7c_5Wbx7o=.c12e688a-b29b-4120-804a-45258537b4b3@github.com>
Message-ID: <qf6ZBh4IbmWrP_CX3zFMv1Y32Pnfz9o_ZH5jnoNuxi4=.959a34cc-bdc9-46eb-b4d8-1a6bdb5488e4@github.com>

On Sat, 23 Aug 2025 06:55:14 GMT, Shawn M Emery <duke at openjdk.org> wrote:

> General:
> 
> -----------
> 
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't refer to the deltas, but rather provide references based on the new AESCrypt.java code itself.
> 
> 
> 
> Correctness:
> 
> -----------------
> 
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: passed, with 51 known failures
> 
> 
> 
> Security:
> 
> -----------
> 
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> 
> 
> Performance:
> 
> ------------------
> 
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options...

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Oct 14 19:40:37 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 14 Oct 2025 19:40:37 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in FIPS
 197
Message-ID: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>

General:
-----------
i) This work is to replace the existing AES cipher under the Cryptix license.

ii) The lookup tables are employed for performance, but also for operating in constant time.

iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.

iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.

Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.

Correctness:
-----------------
The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:

i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass

-intrinsics mode for:

ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass

iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures

iv) jdk_security_infra: passed, with 48 known failures

v) tier1 and tier2: all 110257 tests pass

Security:
-----------
In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.

Performance:
------------------
All AES related benchmarks have been executed against the new and original Cryptix code:

micro:org.openjdk.bench.javax.crypto.AES

micro:org.openjdk.bench.javax.crypto.full.AESBench

micro:org.openjdk.bench.javax.crypto.full.AESExtraBench

micro:org.openjdk.bench.javax.crypto.full.AESGCMBench

micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer

micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream

micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream

micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.

micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)

The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:

i) Default (no JVM options, non-intrinsics) mode:

a) Encryption:  the new code performed better for both architectures tested (x86: +7.6%, arm64: +3.5%)

Analysis: the new code makes some optimizations in the last cipher round with the T2 lookup table that Cryptix may not, hence the better performance in non-intrinsics.

b) Decryption: the new code performed mixed between architectures tested (x86: +8.3%, arm64: -1.1%)

Analysis: the new code performs predominately better, except for decryption on arm64, which we believe is negligible and acceptable to have noticeably better performance with x86 decryption.

ii) Default (no JVM options, intrinsics) mode:

a) Encryption and Decryption:  as expected, both the new code and Cryptix code performed similarly (within the error margins)

Analysis: this is from the fact that the intrinsics related code has not changed with the new changes.

iii) Interpreted-only (-Xint) mode:

a) Encryption: the new code performed better than the Cryptix code for both architectures (x86: +0.6%, arm64: +6.0%).

b) Decryption:  the new code performed slightly worse than the Cryptix code for both architectures (x86: -3.3%, arm64: -2.4%).

Analysis: the design of the new code was focused on instruction efficiency; eliminating unnecessary index variables, rolling out the rounds loop, and using no objects for round and inverse round transforms.  This is especially noticeable in arm64 encryption, but we believe that decryption's slight drop in performance is negligible.

iv) JIT compiler (-Xcomp) mode:

a) Encryption: in this mode, performance is mixed performant between the two architectures tested (x86: +11.7%, arm64: +1.5%).

b) Decryption: performance is decreases for both of the architectures tested (x86: -4.9%, arm64: -3.2%).

Analysis: As with the no options results, we believe that the increase in performance for both architectures in encryption is most likely from the T2 gadgetry that we've implemented.   We believe that the slight performance drop in decryption is negligible.  In any case, the -Xcomp option is primarily used for debugging purposes, ergo we are not as concerned about this slight drop.

Resource utilization:
----------------------------
The new AES code uses similar resources to that of the existing Cryptix code.  Memory allocation has the following characteristics:

i) Peak allocation for both Cryptix and the new code is only a fraction of a percentage point different for both the 1 cipher object and 10 cipher objects test.

Analysis: We believe that this is negligible given the difference in the 20ms to 50ms window of peak allocation.

ii) Total GC pause for Cryptix and the new code only differs by less than 5% for both the 1 object and 10 objects test.

Analysis: This is acceptable behavior given that the benchmark performance for the new code is better overall.

iii) Peak pre-GC allocation for Cryptix and the new code is only a fraction of a percent more for the new code in the 1 object case and is only 2% more for the 10 objects case.

Analysis: These differences indicate ~500 bytes per object discrepancy between the Cryptix and new code, which is also negligible.

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

Commit messages:
 - Implement the rest of the class name changes in intrinsics
 - 8326609: New AES implementation with updates specified in FIPS 197

Changes: https://git.openjdk.org/jdk/pull/27807/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326609
  Stats: 2989 lines in 5 files changed: 1506 ins; 1473 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

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

From duke at openjdk.org  Tue Oct 14 19:48:47 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 14 Oct 2025 19:48:47 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v2]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <wGmz5WRIGP3mnHpKLUsFWiYnozxc6f03IBNnoXl9C74=.9d47b978-a185-4dee-8672-a40cdad940db@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Add vmIntrinsics.hpp updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/1f742c1f..af0f9c4c

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

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

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

From vlivanov at openjdk.org  Tue Oct 14 20:07:13 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 14 Oct 2025 20:07:13 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v2]
In-Reply-To: <wGmz5WRIGP3mnHpKLUsFWiYnozxc6f03IBNnoXl9C74=.9d47b978-a185-4dee-8672-a40cdad940db@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <wGmz5WRIGP3mnHpKLUsFWiYnozxc6f03IBNnoXl9C74=.9d47b978-a185-4dee-8672-a40cdad940db@github.com>
Message-ID: <CSUxKWtLVPCrQZoIl7_vt5cFqxY4ppiHQQ7xP_UvdQI=.0e19c47f-a715-45d3-a06e-1390fa313bf1@github.com>

On Tue, 14 Oct 2025 19:48:47 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add vmIntrinsics.hpp updates

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:

> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
> 42:  */
> 43: public final class AESCrypt extends SymmetricCipher {

Should the class be named `AES_Crypt` instead?

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1408:

> 1406:      */
> 1407:     public void encryptBlock(byte[] plain, int pOff, byte[] cipher, int cOff) {
> 1408:         implEncryptBlock(plain, pOff, cipher, cOff);

There are no bounds checks around intrinsic methods. Previous implementation has a comment stating that the checks are placed in caller code (for performance reasons) and declared the methods package-private. It makes sense either to introduce bounds checks here or keep the wrappers package-private.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2430292341
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2430306371

From mullan at openjdk.org  Tue Oct 14 20:15:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 14 Oct 2025 20:15:07 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
Message-ID: <3uQjLbI_v3-CBM6dg6v1_1W2wzjlqqBzN4FTlQukVjg=.4493d8d9-971b-44e6-baf6-fc5ed6637206@github.com>

On Mon, 13 Oct 2025 17:22:25 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates

src/java.base/share/classes/java/security/PEMEncoder.java line 77:

> 75:  *
> 76:  * <p> The following lists the supported {@code DEREncodable} classes and
> 77:  * the PEM types they encoded as:

s/encoded/encode/

src/java.base/share/classes/java/security/PEMEncoder.java line 89:

> 87:  *  <li>{@code KeyPair} : PRIVATE KEY</li>
> 88:  *  <li>{@code KeyPair} :
> 89:  *  ENCRYPTED PRIVATE KEY if configured with encryption)</li>

s/if/(if/

src/java.base/share/classes/java/security/PEMEncoder.java line 326:

> 324:             if (privateEncoding == null) {
> 325:                 throw new IllegalArgumentException("This DEREncodable cannot " +
> 326:                     "be encrypted.");

It seems you could move this check earlier when you check if `keyspec` is not null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430223693
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430224875
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430313564

From hchao at openjdk.org  Tue Oct 14 20:38:25 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 14 Oct 2025 20:38:25 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v4]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <5rYXtrnCdSgxiZg15kav4wpYUZQQkAbccCd_DsCcrPY=.ae3154f9-0566-49f7-965d-da7cfe753141@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Call getProvider() in NamedGroup.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/5457a73c..39d2f1c0

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

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

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

From hchao at openjdk.org  Tue Oct 14 20:38:26 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 14 Oct 2025 20:38:26 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v4]
In-Reply-To: <Cw48p17DgWzXtGwhoHfWC_gtcJltXFvdsKwyTGn5gOM=.bde342e9-bb2a-4cf3-84d9-94bdeced7bef@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <MIFOZmCTj6r3YfGNkcSCkY1ZZmdgbkHYnqU_SipHZTg=.93f4e70b-1dea-4c3f-a633-bb697bdde1cd@github.com>
 <DPvBPGbjH6Pb13RvMBy6D-on6VY-ObOVq7dRzDnRaLE=.6991c53c-da4c-457d-9bf7-431b950ef89b@github.com>
 <Cw48p17DgWzXtGwhoHfWC_gtcJltXFvdsKwyTGn5gOM=.bde342e9-bb2a-4cf3-84d9-94bdeced7bef@github.com>
Message-ID: <ywlxibr4nhb2w8Irj4CoWx7xpUxoe5zvZfX8rl-gNXg=.6fdfe5b9-4b3a-4362-bf73-c97437e891fc@github.com>

On Tue, 14 Oct 2025 18:15:37 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Done.
>
> It's actually unchanged, do you plan to do it in the next iteration?

Sorry. Changed to call getProvider() as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2430384528

From abarashev at openjdk.org  Tue Oct 14 22:21:06 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 14 Oct 2025 22:21:06 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v4]
In-Reply-To: <5rYXtrnCdSgxiZg15kav4wpYUZQQkAbccCd_DsCcrPY=.ae3154f9-0566-49f7-965d-da7cfe753141@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5rYXtrnCdSgxiZg15kav4wpYUZQQkAbccCd_DsCcrPY=.ae3154f9-0566-49f7-965d-da7cfe753141@github.com>
Message-ID: <jxMy9YwtcjdlNQN9ipOXwkD1NOmLVNay9IqTG9YgJ8U=.40817dba-436c-4979-a4e0-fa87f016eb53@github.com>

On Tue, 14 Oct 2025 20:38:25 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Call getProvider() in NamedGroup.java

test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java line 42:

> 40:     FFDHE8192("ffdhe8192");
> 41: 
> 42:     X25519MLKEM768("X25519MLKEM768);

Invalid syntax: The matching quotation mark is missing,

test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java line 43:

> 41: 
> 42:     X25519MLKEM768("X25519MLKEM768);
> 43:     SecP256r1MLKEM768("SecP256r1MLKEM768");

Invalid syntax: enums should be comma-separated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2430617097
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2430620520

From hchao at openjdk.org  Tue Oct 14 22:58:47 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 14 Oct 2025 22:58:47 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v5]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <VMFNF3GlGbZWXvAeVLWYJhxgU75q1QA6zM61lnwtFlQ=.0a62e12e-98ff-4306-aafb-491b7f3217e8@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in NamedGroup test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/39d2f1c0..21c8dcc3

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

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

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

From hchao at openjdk.org  Tue Oct 14 22:58:48 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 14 Oct 2025 22:58:48 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v4]
In-Reply-To: <jxMy9YwtcjdlNQN9ipOXwkD1NOmLVNay9IqTG9YgJ8U=.40817dba-436c-4979-a4e0-fa87f016eb53@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <5rYXtrnCdSgxiZg15kav4wpYUZQQkAbccCd_DsCcrPY=.ae3154f9-0566-49f7-965d-da7cfe753141@github.com>
 <jxMy9YwtcjdlNQN9ipOXwkD1NOmLVNay9IqTG9YgJ8U=.40817dba-436c-4979-a4e0-fa87f016eb53@github.com>
Message-ID: <XitHV-Ibcv83d_fHT4HvXhLoLzXAlBK7e0cJLs4JhD4=.2263efc8-2ec1-41ae-9927-a7bb4d1414d8@github.com>

On Tue, 14 Oct 2025 22:16:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Call getProvider() in NamedGroup.java
>
> test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java line 42:
> 
>> 40:     FFDHE8192("ffdhe8192");
>> 41: 
>> 42:     X25519MLKEM768("X25519MLKEM768);
> 
> Invalid syntax: The matching quotation mark is missing,

Fixed.

> test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java line 43:
> 
>> 41: 
>> 42:     X25519MLKEM768("X25519MLKEM768);
>> 43:     SecP256r1MLKEM768("SecP256r1MLKEM768");
> 
> Invalid syntax: enums should be comma-separated.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2430684475
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2430684557

From abarashev at openjdk.org  Tue Oct 14 23:05:07 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 14 Oct 2025 23:05:07 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v5]
In-Reply-To: <VMFNF3GlGbZWXvAeVLWYJhxgU75q1QA6zM61lnwtFlQ=.0a62e12e-98ff-4306-aafb-491b7f3217e8@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <VMFNF3GlGbZWXvAeVLWYJhxgU75q1QA6zM61lnwtFlQ=.0a62e12e-98ff-4306-aafb-491b7f3217e8@github.com>
Message-ID: <uJdhoQyRLqD_ICHDWLPKDBOupKsn639_WJdnjmv7Pgs=.1b0325a3-05d9-42d6-83db-ea8c8e26c041@github.com>

On Tue, 14 Oct 2025 22:58:47 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in NamedGroup test

src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 239:

> 237:             "DH"),
> 238: 
> 239:     SecP256r1MLKEM768(0x11eb, "SecP256r1MLKEM768",

Nit: the rest of named groups in this file are all upper-cased.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2430700930

From abarashev at openjdk.org  Tue Oct 14 23:09:14 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 14 Oct 2025 23:09:14 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v5]
In-Reply-To: <VMFNF3GlGbZWXvAeVLWYJhxgU75q1QA6zM61lnwtFlQ=.0a62e12e-98ff-4306-aafb-491b7f3217e8@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <VMFNF3GlGbZWXvAeVLWYJhxgU75q1QA6zM61lnwtFlQ=.0a62e12e-98ff-4306-aafb-491b7f3217e8@github.com>
Message-ID: <rElJs74xOeSa5SArOiCcqvI2QEWjvOAUf1O3IJxAUns=.44094815-92e3-43fc-8a1c-f56d54408477@github.com>

On Tue, 14 Oct 2025 22:58:47 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in NamedGroup test

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 583:

> 581:             // However, this is changed for KEM: the server (as encapsulator)
> 582:             // must perform both actions ? derive the secret and generate the
> 583:             // encapsulated message at the same time during SHKeyShareProducer.

Nit: `during SHKeyShareProducer` doesn't seem gramatically correct, did you mean `during encapsulation in SHKeyShareProducer`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2430706063

From abarashev at openjdk.org  Tue Oct 14 23:14:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 14 Oct 2025 23:14:08 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v5]
In-Reply-To: <VMFNF3GlGbZWXvAeVLWYJhxgU75q1QA6zM61lnwtFlQ=.0a62e12e-98ff-4306-aafb-491b7f3217e8@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <VMFNF3GlGbZWXvAeVLWYJhxgU75q1QA6zM61lnwtFlQ=.0a62e12e-98ff-4306-aafb-491b7f3217e8@github.com>
Message-ID: <9ClJUn3YRfhb8PMqut70bmqzxAHvAc-qYp5xeiveJ8s=.a3b881fb-5f1a-4935-bdd9-0133447cf3af@github.com>

On Tue, 14 Oct 2025 22:58:47 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in NamedGroup test

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 577:

> 575:             //  Both peers perform similar operations: generate a public key,
> 576:             //  send it, and compute a shared secret upon receiving the peer's
> 577:             //  public key.

Nit: We use both `public key` and `key share` in this comment when describing Traditional Key Agreement. I think we should use only `key share`  (as in RFC 8446) when describing a traditional key exchange to avoid any confusion with KEM's public key.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2430718513

From mpowers at openjdk.org  Tue Oct 14 23:43:39 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 14 Oct 2025 23:43:39 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v13]
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>

> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  remaining comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24429/files
  - new: https://git.openjdk.org/jdk/pull/24429/files/3b348af4..9e68d650

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=11-12

  Stats: 368 lines in 7 files changed: 123 ins; 188 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/24429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24429/head:pull/24429

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

From mpowers at openjdk.org  Tue Oct 14 23:43:40 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 14 Oct 2025 23:43:40 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v11]
In-Reply-To: <ZyACg-bMYfa0RYvmlcV-deTCh5ZanCl_UDNfFIpNVAk=.78184fa2-fec3-4cc1-9ed9-d152fd891381@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <bHkWlE62OPU2FCMGd792NJsUvzuqyIuaFsMzJvOXN1o=.fdb693e1-d8ec-42b4-8047-b9bbbdcd858f@github.com>
 <7jhZVUSB2yFkXloSftuRXHZRFXkqoR4Ggj6BpotEphk=.23631446-ee02-4704-9827-97b8c7716b50@github.com>
 <87jVH7gFhQn8zKCm7dca1PVnqda4LM9GX-lx6EXgJs4=.aa54cf92-2192-43d5-b8d4-f4b9600e3393@github.com>
 <ZyACg-bMYfa0RYvmlcV-deTCh5ZanCl_UDNfFIpNVAk=.78184fa2-fec3-4cc1-9ed9-d152fd891381@github.com>
Message-ID: <X7lQU7Xe8VkiT-G0H5mXfW2fDKajTm9lca0krg5kZzg=.391503a2-26ea-4507-afb2-fe75fd1ec792@github.com>

On Sat, 11 Oct 2025 02:35:30 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> It's also a little unusual you are passing in the KDF algorithmId and not its parameters here.
>
> fixed

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2430753447

From weijun at openjdk.org  Wed Oct 15 01:57:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Oct 2025 01:57:09 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v13]
In-Reply-To: <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
Message-ID: <0o4cfK2TRRyeuqZZldoK_wBC2siYQav6sTE6GFC4QJo=.63e41b59-cd5c-4dd5-adba-85dd8142c6a8@github.com>

On Tue, 14 Oct 2025 23:43:39 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remaining comments

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 152:

> 150:                     params.getIterationCount(), len);
> 151:             pbeKey = skf.generateSecret(new PBEKeySpec(password,
> 152:                     params.getSalt(), params.getIterationCount(), len));

You already created a variable named `keySpec`. Do not create another exact same `PBEKeySpec` object.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2430913964

From duke at openjdk.org  Wed Oct 15 05:28:31 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 05:28:31 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v3]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <pvGmT_u4TE-_gtt7yhf058HoRipYgkQVI8oYbkEV1SY=.5b4110d3-06bb-4acd-b505-56d93502fb67@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with two additional commits since the last revision:

 - encryptBlock/decryptBlock methods set to package-private
 - Revert AESCrypt to AES_Crypt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/af0f9c4c..07003719

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

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

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

From duke at openjdk.org  Wed Oct 15 05:28:34 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 05:28:34 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v2]
In-Reply-To: <CSUxKWtLVPCrQZoIl7_vt5cFqxY4ppiHQQ7xP_UvdQI=.0e19c47f-a715-45d3-a06e-1390fa313bf1@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <wGmz5WRIGP3mnHpKLUsFWiYnozxc6f03IBNnoXl9C74=.9d47b978-a185-4dee-8672-a40cdad940db@github.com>
 <CSUxKWtLVPCrQZoIl7_vt5cFqxY4ppiHQQ7xP_UvdQI=.0e19c47f-a715-45d3-a06e-1390fa313bf1@github.com>
Message-ID: <D2KZsuYONV7RWb5pLafjRBxTUuduVnH4yy78DUFc0vQ=.43c62b91-7a35-40c1-a24c-dbd9ab669b59@github.com>

On Tue, 14 Oct 2025 19:59:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add vmIntrinsics.hpp updates
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:
> 
>> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
>> 42:  */
>> 43: public final class AESCrypt extends SymmetricCipher {
> 
> Should the class be named `AES_Crypt` instead?

Yes, you're right.  I'm not sure how it reverted back to AESCrypt.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1408:
> 
>> 1406:      */
>> 1407:     public void encryptBlock(byte[] plain, int pOff, byte[] cipher, int cOff) {
>> 1408:         implEncryptBlock(plain, pOff, cipher, cOff);
> 
> There are no bounds checks around intrinsic methods. Previous implementation has a comment stating that the checks are placed in caller code (for performance reasons) and declared the methods package-private. It makes sense either to introduce bounds checks here or keep the wrappers package-private.

Good catch, I will leave it as package-private then.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2431157744
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2431158083

From duke at openjdk.org  Wed Oct 15 05:51:40 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 05:51:40 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Add remaining files to be staged

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/07003719..3fc25aef

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

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

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

From hchao at openjdk.org  Wed Oct 15 06:48:50 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 15 Oct 2025 06:48:50 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
Message-ID: <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>

> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.

Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:

 - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
 - Updated comment in ServerHello and hybrid to upper-case in NamedGroup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27614/files
  - new: https://git.openjdk.org/jdk/pull/27614/files/21c8dcc3..f98b5385

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27614&range=04-05

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

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

From hchao at openjdk.org  Wed Oct 15 06:48:56 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 15 Oct 2025 06:48:56 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v5]
In-Reply-To: <uJdhoQyRLqD_ICHDWLPKDBOupKsn639_WJdnjmv7Pgs=.1b0325a3-05d9-42d6-83db-ea8c8e26c041@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <VMFNF3GlGbZWXvAeVLWYJhxgU75q1QA6zM61lnwtFlQ=.0a62e12e-98ff-4306-aafb-491b7f3217e8@github.com>
 <uJdhoQyRLqD_ICHDWLPKDBOupKsn639_WJdnjmv7Pgs=.1b0325a3-05d9-42d6-83db-ea8c8e26c041@github.com>
Message-ID: <jHBtFLtYe6mGR6l3ULLPj-Xj8R_PB6a13N7HemgexW0=.b6897c19-d1ed-4ed4-91a5-064dbfc27c1f@github.com>

On Tue, 14 Oct 2025 23:02:01 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in NamedGroup test
>
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java line 239:
> 
>> 237:             "DH"),
>> 238: 
>> 239:     SecP256r1MLKEM768(0x11eb, "SecP256r1MLKEM768",
> 
> Nit: the rest of named groups in this file are all upper-cased.

Changed hybrid groups to upper-case.

> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 577:
> 
>> 575:             //  Both peers perform similar operations: generate a public key,
>> 576:             //  send it, and compute a shared secret upon receiving the peer's
>> 577:             //  public key.
> 
> Nit: We use both `public key` and `key share` in this comment when describing Traditional Key Agreement. I think we should use only `key share`  (as in RFC 8446) when describing a traditional key exchange to avoid any confusion with KEM's public key.

Fixed the comment.

> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 583:
> 
>> 581:             // However, this is changed for KEM: the server (as encapsulator)
>> 582:             // must perform both actions ? derive the secret and generate the
>> 583:             // encapsulated message at the same time during SHKeyShareProducer.
> 
> Nit: `during SHKeyShareProducer` doesn't seem gramatically correct, did you mean `during encapsulation in SHKeyShareProducer`?

Yes, comment updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2431296914
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2431297802
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2431297470

From weijun at openjdk.org  Wed Oct 15 13:14:41 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Oct 2025 13:14:41 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v13]
In-Reply-To: <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
Message-ID: <-GnMlHO_Zl1YxpL1QjlM0VladUKUz8bp7kk5pGGmc64=.8d27f116-1ae1-4abb-b7fb-d3a22bf026f5@github.com>

On Tue, 14 Oct 2025 23:43:39 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remaining comments

src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 308:

> 306:         DerOutputStream pBES2_params = new DerOutputStream();
> 307:         pBES2_params.write(DerValue.tag_Sequence,
> 308:                 PBKDF2Parameters.encode(salt, iCount, keysize, kdfAlgo_OID));

`keySize` here is number of bits, but the `PBKDF2Parameters.encode` requires number of bytes. This means a newly created PKCS12 keystore is invalid. When Java loads a PKCS12 keystore, this field is read but not validated. On the other hand, openssl validates it and will report an error.

Suggestion: either always use the same style in all fields and method arguments, or name them precisely.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432512562

From mullan at openjdk.org  Wed Oct 15 14:04:18 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 15 Oct 2025 14:04:18 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
Message-ID: <wUkrBestiwLW4P6tKzSPtxxyHNuIMtPcX92acX1Rj0E=.281d5420-3403-4fe6-91f9-93820c22f1e9@github.com>

On Mon, 13 Oct 2025 17:22:25 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates

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

> 45: /**
> 46:  * {@code PEMDecoder} implements a decoder for Privacy-Enhanced Mail (PEM) data.
> 47:  * PEM is a textual encoding used to store and transfer security

In `PEMEncoder` it says "cryptographic objects", here it says "security objects". Should be consistent.

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

> 61:  *  <li>X509 CERTIFICATE : {@code X509Certificate}</li>
> 62:  *  <li>X.509 CERTIFICATE : {@code X509Certificate}</li>
> 63:  *  <li>CRL : {@code X509CRL}</li>

X509 CERTIFICATE, X.509 CERTIFICATE, and CRL are not standard types as defined in RFC 7468. Putting them in this list means all implementations must support them, which I don't think is appropriate. I think these types should be moved to the Implementation Note.

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

> 64:  *  <li>X509 CRL : {@code X509CRL}</li>
> 65:  *  <li>PUBLIC KEY : {@code PublicKey}</li>
> 66:  *  <li>PUBLIC KEY : {@code X509EncodedKeySpec} (When passed as a {@code Class}

"When" should be lower-case. Same comment for following bullets that contain parentheses.

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

> 112:  * The {@link #withFactory(Provider)} method uses the specified provider
> 113:  * to produce cryptographic objects from {@link KeyFactory} and
> 114:  * {@link CertificateFactory}. The {@link #withDecryption(char[])} configures the

The {@link #withDecryption(char[])} method ...

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

> 117:  * If an encrypted private key PEM is processed by a decoder not configured
> 118:  * for decryption, an {@link EncryptedPrivateKeyInfo} object is returned.
> 119:  * Decryption configured instances will decode unencrypted PEM.

Reword this sentence so it is easier to understand, ex: "A PEMDecoder configured for decryption .."

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

> 134:  * }
> 135:  *
> 136:  * @implNote This implementation decodes PEM type {@code RSA PRIVATE KEY} as

s/PEM/the PEM/

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

> 341:      * leading data preceding the PEM header. For {@code DEREncodable} types
> 342:      * other than {@code PEM}, leading data is ignored and not returned as part
> 343:      * of the DEREncodable object.

put code font around DEREncodable.

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

> 385:      *
> 386:      * <p> If no PEM data is found, an {@code IllegalArgumentException} is
> 387:      * thrown.

Below it says an `EOFException` is thrown if no PEM data is found. Same comment for method that takes a Class param.

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

> 397:      *   end of the {@code InputStream}
> 398:      * @throws IllegalArgumentException on error in decoding
> 399:      * @throws ClassCastException if {@code tClass} does not represent the PEM type

It's a little odd this throws a `ClassCastException`. This seems more like an `IllegalArgumentException` to me because you are passing in the wrong type.

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

> 497:      *
> 498:      * @param provider the factory provider
> 499:      * @return a new PEMEncoder instance configured with the {@code Provider}.

s/PEMEncoder/PEMDecoder/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432340162
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432655321
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432346397
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432360574
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432366357
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432369853
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432399291
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432427373
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432459995
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432466783

From mullan at openjdk.org  Wed Oct 15 14:04:20 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 15 Oct 2025 14:04:20 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <YawNmD3JifD542wr8AD3cfxrKIQIyY8kTfnd1nPHEp8=.84d4439d-d877-4447-a3cd-997a972cbfd7@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <M4ZBrtG-QdsCAsmPecRmsTU6arjbkrKxT5NuK_TXuhY=.9d66b840-5be9-4a80-976d-de9fe6fff79b@github.com>
 <YawNmD3JifD542wr8AD3cfxrKIQIyY8kTfnd1nPHEp8=.84d4439d-d877-4447-a3cd-997a972cbfd7@github.com>
Message-ID: <dIfzQifm52nWWcwZWHjP1i1grDfxFz4gpL_qnf7Rqd8=.106c021d-568a-4ced-8d20-56806ef8ce85@github.com>

On Wed, 8 Oct 2025 00:18:09 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/PEMDecoder.java line 391:
>> 
>>> 389:      *   {@code DEREncodable}.
>>> 390:      * @return a {@code DEREncodable} typecast to {@code tClass}
>>> 391:      * @throws IOException on IO or PEM syntax error where the
>> 
>> Why would bad PEM syntax be an IOE? Should this be an IAE, similar to a decoding error?
>
> This was a @wangweij comment from the first preview that syntax error are not recoverable and should be IOE.

You mean they are recoverable? Otherwise it should probably be an IAE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432436920

From abarashev at openjdk.org  Wed Oct 15 14:29:15 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 15 Oct 2025 14:29:15 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
Message-ID: <rnvj8T0dfhB25JE3I9IBG2QAGxfpnqXRmkCCHkBMaZk=.d397a41b-d807-4dcf-8ffe-5d2318633aff@github.com>

On Wed, 15 Oct 2025 06:48:50 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Implement hybrid key exchange support for TLS 1.3 by adding three post-quantum hybrid named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
>> Please see [JEP 527](https://openjdk.org/jeps/527) for details about this change.
>
> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
>  - Updated comment in ServerHello and hybrid to upper-case in NamedGroup

src/java.base/share/classes/java/security/spec/NamedParameterSpec.java line 141:

> 139:      * @since 26
> 140:      */
> 141:     public static final NamedParameterSpec SecP384r1MLKEM1024

Nit: Let's make these all upper-case as well to keep things consistent across files.

test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java line 44:

> 42:     X25519MLKEM768("X25519MLKEM768"),
> 43:     SecP256r1MLKEM768("SecP256r1MLKEM768"),
> 44:     SecP384r1MLKEM1024("SecP384r1MLKEM1024");

Nit: Make those uppercase.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2432782187
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2432785713

From weijun at openjdk.org  Wed Oct 15 14:46:29 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Oct 2025 14:46:29 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v13]
In-Reply-To: <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
Message-ID: <Hm-CVYxb3buQI0-d6-bRFgL69vXzpa3zA1Svxe1vkQQ=.b6fa8708-cecd-40bf-8978-03bad51d8ee6@github.com>

On Tue, 14 Oct 2025 23:43:39 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remaining comments

These are mostly style-related comments.

Please add javadoc comments to new methods, especially in `MacData`.

src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 251:

> 249:         keysize = kdfParams.getKeyLength();
> 250: 
> 251:         if (pBES2_params.tag != DerValue.tag_Sequence) {

You can probably move this check before line 228. Note that the same check has been performed on line 214 and the only reason to do it again is if `pBES2_params` has been reassigned on line 227.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 65:

> 63:  * }
> 64:  *
> 65:  * </pre>

Please move the `@author` line to the end of the javadoc comment.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 135:

> 133:     }
> 134: 
> 135:     private static Mac getMac(String macAlgorithm, char[] password,

I would rather let this method return `mac.doFinal(data)`. The method cleans up `pbeKey` in a finally block and I somehow cannot guarantee it would not have any negative impact when the `Mac` object is still alive.

There are two places this method is called and the `Mac` object is used for other purposes. For one, its `getAlgorithm` is called and used in a debug log. I think the `macAlgorithm` can be used too. The other called `getMacLength` but that is the same of the length of the `doFinal` output.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 147:

> 145:         if (macAlgorithm.startsWith("pbewith")) {
> 146:             m = Mac.getInstance(hmac);
> 147:             int len = keyLength == 0 ? m.getMacLength()*8 : keyLength;

Somehow I prefer to use `-1` for the default case. This is consistent with `PBKDF2Parameters`.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 155:

> 153:         } else {
> 154:             hmac = macAlgorithm;
> 155:             m = Mac.getInstance(hmac);

Don't assign to `hmac` and just call `Mac.getInstance(macAlgorithm)`. Mutating `hmac` makes people wondering if it has a purpose.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 160:

> 158:             pbeKey = skf.generateSecret(keySpec);
> 159:         }
> 160:         keySpec.clearPassword();

Put the line above into the `finally` block at the end. Exceptions could be thrown in the lines above.

This will also help merging the two `if (macAlgorithm.startsWith("pbewith"))` checks into one.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 208:

> 206:             String macAlgorithm, int macIterationCount, byte[] salt)
> 207:             throws IOException, NoSuchAlgorithmException {
> 208:         final byte[] mData;

No need for `mData`. Just `return bytes.toByteArray()` at the end.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 210:

> 208:         final byte[] mData;
> 209:         final PBEParameterSpec params;
> 210:         String algName = "PBMAC1";

No need to assign a value now. Assign it in the `if (macAlgorithm.startsWith("pbewith"))` block.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 214:

> 212:         String hmac;
> 213:         Mac m;
> 214:         int keyLength;

Useless.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 225:

> 223:         } else if (macAlgorithm.startsWith("hmacpbe")) {
> 224:             algName = macAlgorithm.substring(7);
> 225:             kdfHmac = macAlgorithm;

Assign null to `kdfHmac`. People might wonder it's useful in this case.

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 240:

> 238:             DerOutputStream bytes = new DerOutputStream();
> 239:             bytes.write(encode(algName, macResult, params, kdfHmac, hmac,
> 240:                     m.getMacLength()));

`m.getLength()` is the same as `macResult`.

src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 99:

> 97:         this.hmacAlgo = o.stdName();
> 98: 
> 99:         DerValue kdf = pBMAC1_params.data.getDerValue();

This is just `info[0]`. You have already read all sub-components on line 77.

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2074:

> 2072:                 MacData macData = new MacData(s);
> 2073:                 int ic = macData.getIterations();
> 2074:                 byte[] salt = macData.getSalt();

This is useless.

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 80:

> 78:     private final int keyLength;
> 79: 
> 80:     private String prfAlgo;

This can be final.

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 86:

> 84:      * parameter block.
> 85:      * 
> 86:      * @param keyDerivationFunc the DER encoding of the parameter block

The `@param` name should be `pBKDF2_params`.

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 152:

> 150:                         .putOctetString(salt)
> 151:                         .putInteger(iterationCount)
> 152:                         .putInteger(keyLength)

When this method is called, `keyLength` can never be -1. Please add a comment or `assert` statement.

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

PR Review: https://git.openjdk.org/jdk/pull/24429#pullrequestreview-3340688324
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432766065
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432772229
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432791173
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432797416
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432800846
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432803553
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432821945
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432810417
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432823775
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432818517
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432827317
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432835982
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432837929
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432839534
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432841221
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2432845455

From mullan at openjdk.org  Wed Oct 15 15:14:13 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 15 Oct 2025 15:14:13 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
Message-ID: <F0hELe2z5SOajVaCMgvSUVLOaFNgBR0nk7oa4OQ-mcA=.6460d914-177f-43ec-80b3-b88e710f1b34@github.com>

On Mon, 13 Oct 2025 17:22:25 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi
>> 
>> Please review the [Second Preview](https://openjdk.org/jeps/8360563) for the PEM API.  The most significant changes from [JEP 470](https://openjdk.org/jeps/470) are:
>> 
>> - Renamed the name of `PEMRecord` class to `PEM`.
>> - Revised the new `encryptKey` methods of the `EncryptedPrivateKeyInfo` class to accept `DEREncodable` objects rather than just `PrivateKey` objects so that cryptographic objects with public keys, i.e., `KeyPair` and `PKCS8EncodedKeySpec`, can also be encrypted.
>> - Enhanced the `PEMEncoder` and `PEMDecoder` classes to support the encryption and decryption of `KeyPair` and `PKCS8EncodedKeySpec` objects.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates

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

> 341:      * @param password the password used for PBE encryption. This array is cloned
> 342:      *                 before use.
> 343:      * @param algorithm the PBE encryption algorithm. If {@code null}, the default

I think I commented on this before, but I think null should not be allowed. This method should only be used when you want to specify your own algorithm.

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

> 517:      * @throws InvalidKeyException if the encoded data does not contain both a
> 518:      * public and private key, or if an error occurs during parsing, decryption,
> 519:      * or key generation

Missing an `@since 25`.

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

> 593:      * @throws InvalidKeyException if the encoded data lacks a public key or an
> 594:      *         error occurs during parsing, decryption, or key generation
> 595:      *

GeneralSecurityException shows up in the javadoc with no detail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432945751
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432825205
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432962291

From mullan at openjdk.org  Wed Oct 15 15:14:14 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 15 Oct 2025 15:14:14 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <ZXpgIZWO5KaHxwv0T58M3Vk1BJdealvNKCJ93pep9D8=.718abc10-e4ef-4060-823c-c39efd692bf0@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <nso7dDgb79zORCUBiKe1cbtfEbTg0s8n_EKeSUUCLd4=.91071a41-e78a-442a-8bdf-24cf858a6b03@github.com>
 <fxc_LSu8Pw8ymUXp41QcrNT0rrMnkOZPP7k_cs8XYdI=.09153ff1-8e2c-4755-89a8-26a534d11b13@github.com>
 <ZXpgIZWO5KaHxwv0T58M3Vk1BJdealvNKCJ93pep9D8=.718abc10-e4ef-4060-823c-c39efd692bf0@github.com>
Message-ID: <rHFGR4pcQnwe-m9EZrfEC4t3bHf7wTvWnJQfaJRtyg0=.4dab2967-4533-4766-96f1-3878987b1680@github.com>

On Thu, 9 Oct 2025 16:50:01 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> On NPE, there is no `key` param.
>
> Ok, I can reword RuntimeException somewhat, but it really is summed up by `Cipher.doFinal()` throwing an error, so an actual "encryption error".

What I mean is that it is very rare for an API to be specified to throw a `RuntimeException`. It is typically a subclass. Also, I know the PEM API is more geared towards throwing unchecked exceptions, but this is an existing lower-level class that already throws checked exceptions when things go wrong, so it does feel to me a bit inconsistent to be throwing runtime exceptions when crypto operations fail in the new methods.

Consider having another look at the way errors are treated in the next API update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2432926931

From abarashev at openjdk.org  Wed Oct 15 15:50:24 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 15 Oct 2025 15:50:24 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <rnvj8T0dfhB25JE3I9IBG2QAGxfpnqXRmkCCHkBMaZk=.d397a41b-d807-4dcf-8ffe-5d2318633aff@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <rnvj8T0dfhB25JE3I9IBG2QAGxfpnqXRmkCCHkBMaZk=.d397a41b-d807-4dcf-8ffe-5d2318633aff@github.com>
Message-ID: <1jfKnuQ2VxfTPkAo5Algl_mnx1jJum-sfZA5HQZ0OLY=.f3a3841f-71c8-48d4-88ee-8cb04f0e04ba@github.com>

On Wed, 15 Oct 2025 14:26:43 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert changes to UseStrongDHSizes test as ffdhe6144/8192 added back
>>  - Updated comment in ServerHello and hybrid to upper-case in NamedGroup
>
> test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java line 44:
> 
>> 42:     X25519MLKEM768("X25519MLKEM768"),
>> 43:     SecP256r1MLKEM768("SecP256r1MLKEM768"),
>> 44:     SecP384r1MLKEM1024("SecP384r1MLKEM1024");
> 
> Nit: Make those uppercase.

We keep the actual name strings the same as in spec, the enum variables are to be uppercase for consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2433102109

From wetmore at openjdk.org  Wed Oct 15 17:05:09 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 15 Oct 2025 17:05:09 GMT
Subject: RFR: 8368493: Disable most JSSE debug output by default,
 and increase the default maximum output log size
Message-ID: <zcd0Bt3gLzyvL1N9Ky4xhh2FgvneDHW0qBIQYZNkG5o=.a37e1689-6d92-4dd8-8153-44788c605f62@github.com>

See the bug for more info.  This will allow for:

1. extra/unneeded JSSE debug output will not be added to each test run, saving space and noise.
2. make it easier to get the full JSSE debug output when enabled.

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

Commit messages:
 - Corrected a couple syntax errors
 - Disabled javax.net.debug output in sun.security tests by default, added switches to be consistent about turning back on
 - Merge branch 'master' into JDK-8368493
 - Disabled javax.net.debug output in javax.net.ssl tests by default, added switches to be consistent about turning back on
 - 8368493: Consider increasing the default maximum output log size for JSSE unit tests

Changes: https://git.openjdk.org/jdk/pull/27455/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27455&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368493
  Stats: 364 lines in 27 files changed: 264 ins; 9 del; 91 mod
  Patch: https://git.openjdk.org/jdk/pull/27455.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27455/head:pull/27455

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

From ascarpino at openjdk.org  Wed Oct 15 17:12:25 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 15 Oct 2025 17:12:25 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <tU3THcc719OPGwLGc3PrOLFmcjJLO6yHzSO5jLHFibA=.da11816a-e8e4-472f-b70e-74cc895fd13c@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
 <tU3THcc719OPGwLGc3PrOLFmcjJLO6yHzSO5jLHFibA=.da11816a-e8e4-472f-b70e-74cc895fd13c@github.com>
Message-ID: <Hv7AtYfqgBD993hOOIZI7OEHlYEjoubfCu8Uoy7tkSw=.ffcb5b00-046d-4880-a678-82a65810bace@github.com>

On Tue, 14 Oct 2025 03:55:20 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates
>
> src/java.base/share/classes/java/security/DEREncodable.java line 58:
> 
>> 56: public sealed interface DEREncodable permits AsymmetricKey, KeyPair,
>> 57:     PKCS8EncodedKeySpec, X509EncodedKeySpec, EncryptedPrivateKeyInfo,
>> 58:     X509Certificate, X509CRL, PEM {
> 
> Do we need to add any javadoc note here stating why PEM replaces PEMRecord to help understand intent?

No, that is for the JEP and/or CSR to explain.

> src/java.base/share/classes/java/security/PEMDecoder.java line 232:
> 
>> 230:                     }
>> 231:                     byte[] p8 = Pem.decryptEncoding(
>> 232:                         decoder.decode(pem.content()), password.getPassword());
> 
> Should we need a null check for pem and a short defensive check for pem.content() being empty/blank before attempting decode? Also do we explicitly specify why explicit zeroing is used ?

PEM disallows a null 'context'.  As for empty values, I purposefully let Base64 decoder do those checks.

> src/java.base/share/classes/java/security/PEMDecoder.java line 233:
> 
>> 231:                     byte[] p8 = Pem.decryptEncoding(
>> 232:                         decoder.decode(pem.content()), password.getPassword());
>> 233:                     DEREncodable d = Pem.toDEREncodable(p8, true, factory);
> 
> If toDEREncodable may throw, do we need to guarantee zeroing on all paths in case of success or exception?

Yes, that is was changed as part of a different code change.

> src/java.base/share/classes/java/security/PEMEncoder.java line 286:
> 
>> 284:      * privateKeyEncoding will be zeroed when the method returns
>> 285:      */
>> 286:     private String buildKey(byte[] publicEncoding, byte[] privateEncoding) {
> 
> Do we need to explicitly document argument contracts: which combination corresponds to which PEM types here ?

This is an internal method, so nothing needs to be documented.  As far as PEM types and their DEREncodables, that is done at the class-level javadoc

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430766713
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430780389
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430782537
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430782856

From ascarpino at openjdk.org  Wed Oct 15 17:12:26 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 15 Oct 2025 17:12:26 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <WAOEpZsoOiwe0F_VfvYwhpUIO5wH308WYIxNBx0SHVE=.8a340cbc-6dcb-46da-b593-0b68d0126714@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <M4ZBrtG-QdsCAsmPecRmsTU6arjbkrKxT5NuK_TXuhY=.9d66b840-5be9-4a80-976d-de9fe6fff79b@github.com>
 <YawNmD3JifD542wr8AD3cfxrKIQIyY8kTfnd1nPHEp8=.84d4439d-d877-4447-a3cd-997a972cbfd7@github.com>
 <WAOEpZsoOiwe0F_VfvYwhpUIO5wH308WYIxNBx0SHVE=.8a340cbc-6dcb-46da-b593-0b68d0126714@github.com>
Message-ID: <BCTwdA_w1wHlLb7BHjxisDC11xNm_m2Od_VIyIBAQi0=.ee3e654a-fd21-46f9-8755-7af41eca4d7a@github.com>

On Tue, 14 Oct 2025 18:03:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> "PRIVATE KEY" is earlier in the list and "RSA PRIVATE KEY" is a valid type.
>
> Ok, but is it really common? All the others are listed in RFC 7468 but not this one.

Yes, it is the PKCS#1 standard.  RSA PRIVATE KEY was an OpenSSL standard for a long time and only recently changed to PRIVATE KEY.   MacOS (15.7.1), which is LibreSSL, still uses RSA PRIVATE KEY by default.   It's probably used more often than half of the above list.

>> This was a @wangweij comment from the first preview that syntax error are not recoverable and should be IOE.
>
> You mean they are recoverable? Otherwise it should probably be an IAE.

not recoverable such that reading from the stream is stopped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430691201
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2433356041

From ascarpino at openjdk.org  Wed Oct 15 17:12:30 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 15 Oct 2025 17:12:30 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <wUkrBestiwLW4P6tKzSPtxxyHNuIMtPcX92acX1Rj0E=.281d5420-3403-4fe6-91f9-93820c22f1e9@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
 <wUkrBestiwLW4P6tKzSPtxxyHNuIMtPcX92acX1Rj0E=.281d5420-3403-4fe6-91f9-93820c22f1e9@github.com>
Message-ID: <IjuOBAM9G4yIXokbMD2B2tyNGLc-SJp5YbAlFy9LSSk=.4a70118a-802f-4742-93ba-e803d3738607@github.com>

On Wed, 15 Oct 2025 12:56:04 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 399:
> 
>> 397:      *   end of the {@code InputStream}
>> 398:      * @throws IllegalArgumentException on error in decoding
>> 399:      * @throws ClassCastException if {@code tClass} does not represent the PEM type
> 
> It's a little odd this throws a `ClassCastException`. This seems more like an `IllegalArgumentException` to me because you are passing in the wrong type.

@wangweij pushed for CCE instead of IAE.  It is a valid argument, but cannot be cast to that object.  I think one can make a case for both exception types, but CCE was a bit stronger.

> src/java.base/share/classes/java/security/PEMEncoder.java line 326:
> 
>> 324:             if (privateEncoding == null) {
>> 325:                 throw new IllegalArgumentException("This DEREncodable cannot " +
>> 326:                     "be encrypted.");
> 
> It seems you could move this check earlier when you check if `keyspec` is not null.

buildKey is now reworked from a bug

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2433371104
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430763698

From ascarpino at openjdk.org  Wed Oct 15 17:12:34 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 15 Oct 2025 17:12:34 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <QCNg1vwrVwF9go6ocJjpuC6huSCZ96fCWwXFo_i_RIc=.56624471-fb68-43b2-8c31-a79b41c70882@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <QCNg1vwrVwF9go6ocJjpuC6huSCZ96fCWwXFo_i_RIc=.56624471-fb68-43b2-8c31-a79b41c70882@github.com>
Message-ID: <VesqYpWwaCkzIvH1V6PlNYoNON9G25oeXVX0RDaWCT0=.4bd6cf71-994b-4219-b7f8-f2c7248df7be@github.com>

On Thu, 2 Oct 2025 21:26:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed some decoder comments
>
> test/jdk/javax/crypto/EncryptedPrivateKeyInfo/GetKeyPair.java line 103:
> 
>> 101:             "PublicKey didn't match with decoded.");
>> 102:         Asserts.assertEqualsByteArray(kps.origPubEncoding, actualPubEncoding,
>> 103:             "PublicKey didn't match with decoded.");
> 
> There is no need to always compare public key encoding twice. You can compare `kpOrig.getPublic()` and `mlkemKP.getPubic()` once after line 72.
> 
> Then you can just compare `mlkemKP` and `kp` and there is no need to invent a new `KeyPairs` type.
> 
> I would more like to see this test and `GetKey` merged, probably also covering `getKeySpec`.

I can clean this up.  But I don't plan to expand it to other tests.   getKey uses the same code, so it's pretty much covered.  Maybe something for the test plan to look into.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2430789599

From wetmore at openjdk.org  Wed Oct 15 17:19:42 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 15 Oct 2025 17:19:42 GMT
Subject: RFR: 8368493: Disable most JSSE debug output by default,
 and increase the default maximum output log size [v2]
In-Reply-To: <zcd0Bt3gLzyvL1N9Ky4xhh2FgvneDHW0qBIQYZNkG5o=.a37e1689-6d92-4dd8-8153-44788c605f62@github.com>
References: <zcd0Bt3gLzyvL1N9Ky4xhh2FgvneDHW0qBIQYZNkG5o=.a37e1689-6d92-4dd8-8153-44788c605f62@github.com>
Message-ID: <5hwoLpZ68DndKJfKLXqzv0rgmt2qHg9dVtIRA3ksJqo=.94bc5bf3-e52d-457b-954c-4ff7eda8f20d@github.com>

> See the bug for more info.  This will allow for:
> 
> 1. extra/unneeded JSSE debug output will not be added to each test run, saving space and noise.
> 2. make it easier to get the full JSSE debug output when enabled.

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

  Adjusted sizes to be more reasonable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27455/files
  - new: https://git.openjdk.org/jdk/pull/27455/files/6bb3044d..9eb8091c

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

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

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

From wxiao at openjdk.org  Wed Oct 15 17:34:55 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 15 Oct 2025 17:34:55 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
Message-ID: <GdQJR_L3OVYAJ0cOC_X5r0oG1s8R93GRhyuCuWGKhl0=.b24ee90c-024f-49d7-a352-8600eb7da9fd@github.com>

> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
> 
> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
> 
> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
> 
> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.

Weibing Xiao has updated the pull request 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 26 additional commits since the last revision:

 - update the code
 - Merge branch 'master' of github.com:openjdk/jdk into JDK-8362268
 - Merge branch 'master' into JDK-8362268
 - Merge branch 'master' of github.com:weibxiao/jdk
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'master' of github.com:openjdk/jdk
 - Merge branch 'openjdk:master' into master
 - Merge branch 'master' of github.com:openjdk/jdk
 - Merge branch 'master' of github.com:openjdk/jdk
 - ... and 16 more: https://git.openjdk.org/jdk/compare/b031257e...4dd20668

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26566/files
  - new: https://git.openjdk.org/jdk/pull/26566/files/77b418d4..4dd20668

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

  Stats: 271102 lines in 4269 files changed: 197659 ins; 48393 del; 25050 mod
  Patch: https://git.openjdk.org/jdk/pull/26566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26566/head:pull/26566

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

From valeriep at openjdk.org  Wed Oct 15 17:58:38 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 17:58:38 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
Message-ID: <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>

On Wed, 15 Oct 2025 05:51:40 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add remaining files to be staged

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:

> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
> 42:  */
> 43: public final class AES_Crypt extends SymmetricCipher {

This internal class does not need to be public? I'd assume it's only used within the same package?

test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 53:

> 51:     public void setup() throws Exception {
> 52:         SecretKeySpec keySpec = new SecretKeySpec(new byte[]{-80, -103, -1, 68, -29, -94, 61, -52, 93, -59, -128, 105, 110, 88, 44, 105}, "AES");
> 53:         IvParameterSpec iv = new IvParameterSpec(new byte[]{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00});

Is the all-0s IV intentional?

test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 82:

> 80:     public byte[] testUseAesIntrinsics() throws Exception {
> 81:         return cipher.doFinal(ct);
> 82:     }

These 3 methods look same to me except for the method names?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433490853
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433487319
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433483607

From wxiao at openjdk.org  Wed Oct 15 18:40:39 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Wed, 15 Oct 2025 18:40:39 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: <GdQJR_L3OVYAJ0cOC_X5r0oG1s8R93GRhyuCuWGKhl0=.b24ee90c-024f-49d7-a352-8600eb7da9fd@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <GdQJR_L3OVYAJ0cOC_X5r0oG1s8R93GRhyuCuWGKhl0=.b24ee90c-024f-49d7-a352-8600eb7da9fd@github.com>
Message-ID: <5jvW2mPcnGEjhnL3fn2_xOqtzZzX_SD3UEYAZlSlIKw=.b34ffb32-9ee3-412b-8256-b57bccf73716@github.com>

On Wed, 15 Oct 2025 17:34:55 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao has updated the pull request 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 26 additional commits since the last revision:
> 
>  - update the code
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8362268
>  - Merge branch 'master' into JDK-8362268
>  - Merge branch 'master' of github.com:weibxiao/jdk
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/340509e1...4dd20668

Updated the code to address the review comments.
Add some of my extra analysis as below,

In JDK, at the line https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/java.naming/share/classes/com/sun/jndi/ldap/sasl/SaslInputStream.java#L127, the buffer length was larger than default value 65536, it would trigger the exception. At the line of 451 of Connnection.java, the exception was caught.  Connection::cleanup got called. At line https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L657, the method of closeOpenedSocket will close the output stream. For Sasl implementation, this output stream is SaslOutputStream.java.  So that SaslOutputStream::close is used to close the stream. Inside this method, GssKrb5Client::dispose was called, its implementation is base class GssKrb5Base::dispose, which is disposing the GSS Context and set it to be null. At mean time, Sasl output stream was till in the middle to handle the buffer by using GssKrb5Base::wrap. Since Gss Con
 text already set to be null, it caused the NPE at line of https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140.

JNDI connection was created inside the constructor o LdapClient.java. When Connection object was created, the output stream and input stream was created also. For Sasl implementation, it was SaslnputStream and SaslOutputStream. Both resources were created inside LdapClient when Connection object was created. It seems ok to close them in LdapClient.java.  Consider locking the connection, the change was called inside LdapClient::close, which was using ReentrantLock to control the access. Hope to get more info to refine the code here.

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

PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3407777489

From valeriep at openjdk.org  Wed Oct 15 18:48:29 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 18:48:29 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
Message-ID: <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>

On Wed, 15 Oct 2025 05:51:40 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add remaining files to be staged

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55:

> 53: 
> 54:     private static final int AES_256_ROUNDS = 14;
> 55:     private static final int AES_256_NKEYS = 32;

The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433608974

From valeriep at openjdk.org  Wed Oct 15 18:53:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 18:53:55 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>
Message-ID: <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com>

On Wed, 15 Oct 2025 18:45:24 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add remaining files to be staged
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55:
> 
>> 53: 
>> 54:     private static final int AES_256_ROUNDS = 14;
>> 55:     private static final int AES_256_NKEYS = 32;
> 
> The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here?

Or, merge the values defined in `AESConstants` into this class. Either way is fine with me as long as no duplicated values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433622686

From valeriep at openjdk.org  Wed Oct 15 20:48:45 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 20:48:45 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
Message-ID: <pR3Bq_Jp14q-QJIxyEnudtV63OVd_BMavZJRfeBQXuM=.6344bb6b-7263-4628-af4a-3d1ed39f05fa@github.com>

On Wed, 15 Oct 2025 05:51:40 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add remaining files to be staged

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 920:

> 918:             if (prevKey != null) {
> 919:                 Arrays.fill(prevKey, (byte) 0);
> 920:             }

Can be moved down to be right before `prevKey = key.clone()` call? This way, `sessionK` assignments are together and not separated by this call

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433898660

From weijun at openjdk.org  Wed Oct 15 20:50:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Oct 2025 20:50:59 GMT
Subject: Integrated: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep
In-Reply-To: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
Message-ID: <VINVigPpAuUHumUpsTv57oe-EVKi4n_CDGw68alyluw=.319759d8-19fe-427f-9046-2206c3855453@github.com>

On Wed, 10 Sep 2025 15:43:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Allow password hiding even if there is no `System.console`. A manual test is included.

This pull request has now been integrated.

Changeset: a7a3a660
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7a3a660e33fabc025ebe887f5605741be9ca8c3
Stats:     335 lines in 6 files changed: 287 ins; 12 del; 36 mod

8354469: Keytool exposes the password in plain text when command is piped using | grep

Reviewed-by: mullan, smarks, naoto, hchao

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

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

From duke at openjdk.org  Wed Oct 15 21:31:23 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 21:31:23 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
Message-ID: <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com>

On Wed, 15 Oct 2025 17:54:37 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add remaining files to be staged
>
> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 53:
> 
>> 51:     public void setup() throws Exception {
>> 52:         SecretKeySpec keySpec = new SecretKeySpec(new byte[]{-80, -103, -1, 68, -29, -94, 61, -52, 93, -59, -128, 105, 110, 88, 44, 105}, "AES");
>> 53:         IvParameterSpec iv = new IvParameterSpec(new byte[]{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00});
> 
> Is the all-0s IV intentional?

Yes, it's in keeping with the other benchmarks (e.g., test/micro/org/openjdk/bench/javax/crypto/AES.java).

> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 82:
> 
>> 80:     public byte[] testUseAesIntrinsics() throws Exception {
>> 81:         return cipher.doFinal(ct);
>> 82:     }
> 
> These 3 methods look same to me except for the method names?

The forked arguments will test different levels of optimizations:
testBaseline: no optimizations
testUseAes: AES optimizations
testUseAesIntrinsics: AES machine instructions

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434006387
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434001817

From duke at openjdk.org  Wed Oct 15 23:04:10 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 23:04:10 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/3fc25aef..f48160cf

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

  Stats: 31 lines in 1 file changed: 6 ins; 10 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

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

From duke at openjdk.org  Wed Oct 15 23:04:11 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 23:04:11 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
Message-ID: <ExNTY6lbqeXpuYF1Eo_wd0s0fKZ7wgq5OyQ57Ux3ja8=.44937ab1-2c2f-4ef5-a3ba-e33ca56f0950@github.com>

On Wed, 15 Oct 2025 17:55:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add remaining files to be staged
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43:
> 
>> 41:  * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688
>> 42:  */
>> 43: public final class AES_Crypt extends SymmetricCipher {
> 
> This internal class does not need to be public? I'd assume it's only used within the same package?

You're right, it doesn't appear to be used externally.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 920:
> 
>> 918:             if (prevKey != null) {
>> 919:                 Arrays.fill(prevKey, (byte) 0);
>> 920:             }
> 
> Can be moved down to be right before `prevKey = key.clone()` call? This way, `sessionK` assignments are together and not separated by this call

It can be and I agree.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434164829
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434165068

From duke at openjdk.org  Wed Oct 15 23:04:13 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Wed, 15 Oct 2025 23:04:13 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com>
 <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com>
Message-ID: <Tv0ojGuZQ_ououiASu5P4XEucY8dOVh3147dIjXVOdE=.cea0db2b-7bfa-4c4a-9dbf-03fce792d5b7@github.com>

On Wed, 15 Oct 2025 18:51:29 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55:
>> 
>>> 53: 
>>> 54:     private static final int AES_256_ROUNDS = 14;
>>> 55:     private static final int AES_256_NKEYS = 32;
>> 
>> The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here?
>
> Or, merge the values defined in `AESConstants` into this class. Either way is fine with me as long as no duplicated values.

I've made the update that references the AESConstants to avoid duplication.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434164972

From valeriep at openjdk.org  Wed Oct 15 23:31:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 15 Oct 2025 23:31:03 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v4]
In-Reply-To: <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <G0tiYq6juFKVVOedEPAuUr7ljugIhHmIUUzn5NkLGvw=.cecb6252-42f3-4534-85e0-cfd996fc0420@github.com>
 <buQTjHiQ7ZuPw5O7MblEEnDoiu1CyhOsdTd3MLfYvCo=.36d501fd-27e1-4fd4-b41c-0294d58cd597@github.com>
 <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com>
Message-ID: <-4wxYGqcPRXJYZEXd91_MPCBd491IFjd7TOnMP_HdxE=.060bb090-1084-4a3b-8315-2116e73e69df@github.com>

On Wed, 15 Oct 2025 21:26:33 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 82:
>> 
>>> 80:     public byte[] testUseAesIntrinsics() throws Exception {
>>> 81:         return cipher.doFinal(ct);
>>> 82:     }
>> 
>> These 3 methods look same to me except for the method names?
>
> The forked arguments will test different levels of optimizations:
> testBaseline: no optimizations
> testUseAes: AES optimizations
> testUseAesIntrinsics: AES machine instructions

Ah, I see, some has "+" vs some uses "-". My eye sights are getting worse. (sigh)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434206251

From valeriep at openjdk.org  Thu Oct 16 00:21:12 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:21:12 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <5aAa7y5hs9zHT05sehzUaDmSXY31QDQPj_ioD9V9nK8=.78641e57-e2df-4f8b-9c0b-35a56fbea7db@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 896:

> 894:         if (key.length == AESConstants.AES_KEYSIZES[0]) {
> 895:             rounds = AES_128_ROUNDS;
> 896:             nk = AESConstants.AES_KEYSIZES[0]/WB;

Looks like we can get rid of `nk` as the `genRKeys(byte[])` method can calculate/derive it based on the specified `key` argument, i.e. `key.length >> 2` or `key.length / WB`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434256434

From valeriep at openjdk.org  Thu Oct 16 00:42:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:42:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <qPoLbshdcb3fGcA-JIb1nZgS7bET9g_8KbyV2RA3XRE=.5538825c-7d6a-43a5-b0a9-b243b42329ec@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 954:

> 952:             }
> 953:             w[i] = w[i - nk] ^ tmp;
> 954:         }

Looks like most of these local variables can be removed? Since you are not changing the value of `len`, you can just use `WB`. `rW` is only used inside the if-block from line 944-948, so it can be declared on line 945.  Line 946-948 can be merged on one line, e.g. `tmp = subByte(rW, SBOX) ^ RCON[(i / nk) - 1];` and no need for `subWord` and `g`. Same goes for line 950 and 951.
Also, the value of `WB * (rounds + 1)` is used twice, this can be stored in a local variable say `wLen`, so it's only calculated once.
Same goes for the `i * WB` value from line 937-940

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434276514

From valeriep at openjdk.org  Thu Oct 16 00:45:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:45:03 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <qPoLbshdcb3fGcA-JIb1nZgS7bET9g_8KbyV2RA3XRE=.5538825c-7d6a-43a5-b0a9-b243b42329ec@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 <qPoLbshdcb3fGcA-JIb1nZgS7bET9g_8KbyV2RA3XRE=.5538825c-7d6a-43a5-b0a9-b243b42329ec@github.com>
Message-ID: <2Qva3E5Ux0iHeg_Xx_yDV06gkjVmtIQL0J1aL2oSkmE=.28ead96c-2f65-4501-b44d-97898d032d6a@github.com>

On Thu, 16 Oct 2025 00:38:09 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 954:
> 
>> 952:             }
>> 953:             w[i] = w[i - nk] ^ tmp;
>> 954:         }
> 
> Looks like most of these local variables can be removed? Since you are not changing the value of `len`, you can just use `WB`. `rW` is only used inside the if-block from line 944-948, so it can be declared on line 945.  Line 946-948 can be merged on one line, e.g. `tmp = subByte(rW, SBOX) ^ RCON[(i / nk) - 1];` and no need for `subWord` and `g`. Same goes for line 950 and 951.
> Also, the value of `WB * (rounds + 1)` is used twice, this can be stored in a local variable say `wLen`, so it's only calculated once.
> Same goes for the `i * WB` value from line 937-940

On the second thought, instead of calculating `i * WB` value, You can use another local variable to store this index and increment it by 4 for each iteration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434280527

From valeriep at openjdk.org  Thu Oct 16 00:51:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:51:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <Yi-i_G6rzZSf--f5B98FDZmpxH-hziNwnrw71ap4KbE=.987c1c0b-5184-40f2-82fa-54622f850943@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:

> 930:      * @return w the cipher round keys.
> 931:      */
> 932:     private int[] genRKeys(byte[] key, int nk) {

nit: The spec names this "keyExpansion" and documents it under section 5.2. Could we include this in the method javadoc? Also, how about "genRoundKeys" or "doKeyExpansion" as method name? `nk` can be derived from `key` and maybe no need for extra argument?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434286447

From valeriep at openjdk.org  Thu Oct 16 00:54:10 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 00:54:10 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <w6vLcHWKA1qYfAWNSHroBPE9koyKrHgcLtJLkYSCfPc=.8f1ce350-5856-4668-a3a5-8052e351d3a2@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:

> 930:      * @return w the cipher round keys.
> 931:      */
> 932:     private int[] genRKeys(byte[] key, int nk) {

This method can be static?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434289681

From mpowers at openjdk.org  Thu Oct 16 02:41:25 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 16 Oct 2025 02:41:25 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v13]
In-Reply-To: <Hm-CVYxb3buQI0-d6-bRFgL69vXzpa3zA1Svxe1vkQQ=.b6fa8708-cecd-40bf-8978-03bad51d8ee6@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
 <Hm-CVYxb3buQI0-d6-bRFgL69vXzpa3zA1Svxe1vkQQ=.b6fa8708-cecd-40bf-8978-03bad51d8ee6@github.com>
Message-ID: <VbuGPk3cvRZC4kUsIVTtfrecvOeUUbR-aml0g9ryApo=.d6cef936-5df1-4092-b400-25d4cba980b8@github.com>

On Wed, 15 Oct 2025 14:21:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remaining comments
>
> src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 251:
> 
>> 249:         keysize = kdfParams.getKeyLength();
>> 250: 
>> 251:         if (pBES2_params.tag != DerValue.tag_Sequence) {
> 
> You can probably move this check before line 228. Note that the same check has been performed on line 214 and the only reason to do it again is if `pBES2_params` has been reassigned on line 227.

fixed

> src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 308:
> 
>> 306:         DerOutputStream pBES2_params = new DerOutputStream();
>> 307:         pBES2_params.write(DerValue.tag_Sequence,
>> 308:                 PBKDF2Parameters.encode(salt, iCount, keysize, kdfAlgo_OID));
> 
> `keySize` here is number of bits, but the `PBKDF2Parameters.encode` requires number of bytes. This means a newly created PKCS12 keystore is invalid. When Java loads a PKCS12 keystore, this field is read but not validated. On the other hand, openssl validates it and will report an error.
> 
> Suggestion: either always use the same style in all fields and method arguments, or name them precisely.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 65:
> 
>> 63:  * }
>> 64:  *
>> 65:  * </pre>
> 
> Please move the `@author` line to the end of the javadoc comment.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 135:
> 
>> 133:     }
>> 134: 
>> 135:     private static Mac getMac(String macAlgorithm, char[] password,
> 
> I would rather let this method return `mac.doFinal(data)`. The method cleans up `pbeKey` in a finally block and I somehow cannot guarantee it would not have any negative impact when the `Mac` object is still alive.
> 
> There are two places this method is called and the `Mac` object is used for other purposes. For one, its `getAlgorithm` is called and used in a debug log. I think the `macAlgorithm` can be used too. The other called `getMacLength` but that is the same of the length of the `doFinal` output.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 147:
> 
>> 145:         if (macAlgorithm.startsWith("pbewith")) {
>> 146:             m = Mac.getInstance(hmac);
>> 147:             int len = keyLength == 0 ? m.getMacLength()*8 : keyLength;
> 
> Somehow I prefer to use `-1` for the default case. This is consistent with `PBKDF2Parameters`.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 152:
> 
>> 150:                     params.getIterationCount(), len);
>> 151:             pbeKey = skf.generateSecret(new PBEKeySpec(password,
>> 152:                     params.getSalt(), params.getIterationCount(), len));
> 
> You already created a variable named `keySpec`. Do not create another exact same `PBEKeySpec` object.

It also caused the leak of uncleaned memory that was seen during testing. Fixed.

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 155:
> 
>> 153:         } else {
>> 154:             hmac = macAlgorithm;
>> 155:             m = Mac.getInstance(hmac);
> 
> Don't assign to `hmac` and just call `Mac.getInstance(macAlgorithm)`. Mutating `hmac` makes people wondering if it has a purpose.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 208:
> 
>> 206:             String macAlgorithm, int macIterationCount, byte[] salt)
>> 207:             throws IOException, NoSuchAlgorithmException {
>> 208:         final byte[] mData;
> 
> No need for `mData`. Just `return bytes.toByteArray()` at the end.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 210:
> 
>> 208:         final byte[] mData;
>> 209:         final PBEParameterSpec params;
>> 210:         String algName = "PBMAC1";
> 
> No need to assign a value now. Assign it in the `if (macAlgorithm.startsWith("pbewith"))` block.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 214:
> 
>> 212:         String hmac;
>> 213:         Mac m;
>> 214:         int keyLength;
> 
> Useless.

removed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 225:
> 
>> 223:         } else if (macAlgorithm.startsWith("hmacpbe")) {
>> 224:             algName = macAlgorithm.substring(7);
>> 225:             kdfHmac = macAlgorithm;
> 
> Assign null to `kdfHmac`. People might wonder it's useful in this case.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 240:
> 
>> 238:             DerOutputStream bytes = new DerOutputStream();
>> 239:             bytes.write(encode(algName, macResult, params, kdfHmac, hmac,
>> 240:                     m.getMacLength()));
> 
> `m.getLength()` is the same as `macResult`.

fixed

> src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 99:
> 
>> 97:         this.hmacAlgo = o.stdName();
>> 98: 
>> 99:         DerValue kdf = pBMAC1_params.data.getDerValue();
> 
> This is just `info[0]`. You have already read all sub-components on line 77.

fixed

> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2074:
> 
>> 2072:                 MacData macData = new MacData(s);
>> 2073:                 int ic = macData.getIterations();
>> 2074:                 byte[] salt = macData.getSalt();
> 
> This is useless.

removed

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 80:
> 
>> 78:     private final int keyLength;
>> 79: 
>> 80:     private String prfAlgo;
> 
> This can be final.

fixed

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 86:
> 
>> 84:      * parameter block.
>> 85:      * 
>> 86:      * @param keyDerivationFunc the DER encoding of the parameter block
> 
> The `@param` name should be `pBKDF2_params`.

changed

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 152:
> 
>> 150:                         .putOctetString(salt)
>> 151:                         .putInteger(iterationCount)
>> 152:                         .putInteger(keyLength)
> 
> Currently, when this method is called, `keyLength` can never be -1. Please add an `assert` statement so it will not be accidentally called later with a length being -1.

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434402411
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434402543
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434402294
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434402161
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434402031
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434402657
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434401928
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434401499
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434401788
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434401352
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434401623
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434401266
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434401136
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434401047
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434400938
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434400777
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2434400633

From duke at openjdk.org  Thu Oct 16 03:43:17 2025
From: duke at openjdk.org (duke)
Date: Thu, 16 Oct 2025 03:43:17 GMT
Subject: Withdrawn: 8365861: test/jdk/sun/security/pkcs11/Provider/ tests
 skipped without SkippedException
In-Reply-To: <Gz2_zX8dMTJ3SEOVZ2k8YfkqueUZk_ISkjl8SGEHGgc=.377a6dc0-5b9b-44bb-bb22-84a6a7128788@github.com>
References: <Gz2_zX8dMTJ3SEOVZ2k8YfkqueUZk_ISkjl8SGEHGgc=.377a6dc0-5b9b-44bb-bb22-84a6a7128788@github.com>
Message-ID: <HIKbj_m45PXUE99_XOU7Ty29la5CYO0lF88ETwbEVF0=.324321a3-b1ca-4623-8e95-b17fd2c00523@github.com>

On Wed, 20 Aug 2025 14:58:44 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> * test/jdk/sun/security/pkcs11/Provider/ tests skipped without SkippedException:
>   - test/jdk/sun/security/pkcs11/Provider/LoginISE.java 
>   - test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java
>   - test/jdk/sun/security/pkcs11/Provider/Absolute.java
> * cleanup

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Oct 16 04:04:23 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 04:04:23 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v6]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <D10CYOe7aMVvFnVLVSIC24rkS5X9Bn2ieVJzLhZGyp0=.f302f432-567b-4531-afe4-c93142842180@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/f48160cf..fbf2117f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=04-05

  Stats: 28 lines in 1 file changed: 1 ins; 10 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

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

From duke at openjdk.org  Thu Oct 16 04:04:25 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 04:04:25 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <5aAa7y5hs9zHT05sehzUaDmSXY31QDQPj_ioD9V9nK8=.78641e57-e2df-4f8b-9c0b-35a56fbea7db@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 <5aAa7y5hs9zHT05sehzUaDmSXY31QDQPj_ioD9V9nK8=.78641e57-e2df-4f8b-9c0b-35a56fbea7db@github.com>
Message-ID: <yHo_j7EhetLMz1IanELnanT28tBeCLmJaqVUgLxkBHc=.e74d74a3-1217-44fa-a5c8-e783cf46ada9@github.com>

On Thu, 16 Oct 2025 00:18:08 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 896:
> 
>> 894:         if (key.length == AESConstants.AES_KEYSIZES[0]) {
>> 895:             rounds = AES_128_ROUNDS;
>> 896:             nk = AESConstants.AES_KEYSIZES[0]/WB;
> 
> Looks like we can get rid of `nk` as the `genRKeys(byte[])` method can calculate/derive it based on the specified `key` argument, i.e. `key.length >> 2` or `key.length / WB`

Sounds reasonable.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:
> 
>> 930:      * @return w the cipher round keys.
>> 931:      */
>> 932:     private int[] genRKeys(byte[] key, int nk) {
> 
> nit: The spec names this "keyExpansion" and documents it under section 5.2. Could we include this in the method javadoc? Also, how about "genRoundKeys" or "doKeyExpansion" as method name? `nk` can be derived from `key` and maybe no need for extra argument?

Actually I used Stallings' cryptography book specifically for the round key concepts, hence the variable name mismatch at least for 128 bit keys.  But after your suggestions is does look more like FIPS 192-upd 1 so I will reference the section ;)  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 932:
> 
>> 930:      * @return w the cipher round keys.
>> 931:      */
>> 932:     private int[] genRKeys(byte[] key, int nk) {
> 
> This method can be static if you pass the `rounds` value as a method argument.

Yes and subWord() would also need to be static for this change.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434497086
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434497821
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434498001

From duke at openjdk.org  Thu Oct 16 04:04:27 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 04:04:27 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <2Qva3E5Ux0iHeg_Xx_yDV06gkjVmtIQL0J1aL2oSkmE=.28ead96c-2f65-4501-b44d-97898d032d6a@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 <qPoLbshdcb3fGcA-JIb1nZgS7bET9g_8KbyV2RA3XRE=.5538825c-7d6a-43a5-b0a9-b243b42329ec@github.com>
 <2Qva3E5Ux0iHeg_Xx_yDV06gkjVmtIQL0J1aL2oSkmE=.28ead96c-2f65-4501-b44d-97898d032d6a@github.com>
Message-ID: <pa0LOr36bCeDYO7IvgvJ3drt327DMt4q8hyoXqnA5xI=.824d2138-c29d-4288-97a3-f50d9561bb44@github.com>

On Thu, 16 Oct 2025 00:42:20 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 954:
>> 
>>> 952:             }
>>> 953:             w[i] = w[i - nk] ^ tmp;
>>> 954:         }
>> 
>> Looks like most of these local variables can be removed? Since you are not changing the value of `len`, you can just use `WB`. `rW` is only used inside the if-block from line 944-948, so it can be declared on line 945.  Line 946-948 can be merged on one line, e.g. `tmp = subByte(rW, SBOX) ^ RCON[(i / nk) - 1];` and no need for `subWord` and `g`. Same goes for line 950 and 951.
>> Also, the value of `WB * (rounds + 1)` is used twice, this can be stored in a local variable say `wLen`, so it's only calculated once.
>> Same goes for the `i * WB` value from line 937-940
>
> On the second thought, instead of calculating `i * WB` value, You can use another local variable to store this index and increment it by 4 for each iteration.

I've made these changes and used the 2nd approach for indexing key.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434497439

From valeriep at openjdk.org  Thu Oct 16 04:52:04 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 04:52:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
Message-ID: <v-fZkjDTWZW5AFNnqiF4NDIE457JuGsjatiBa2oBnoI=.e53a7090-417e-42f1-b1c2-8ff0d7f43687@github.com>

On Wed, 15 Oct 2025 23:04:10 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1032:

> 1030:      * @return the substituted word.
> 1031:      */
> 1032:     private int subByte(int state, byte[][] sub) {

Given the input and output are both `int` type, i.e. word, maybe it's better named as `subWord` ? This also matches the pseudocode routine name used in the spec. 
This method also can be made static. It seems that `sub` is always the static `SBOX`, maybe we don't have to use an argument to pass it? 
nit: the variable name `state` is a bit misleading as we are only using part of it. A state is consisting of 4 words and the input here is only 1 word.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434562796

From duke at openjdk.org  Thu Oct 16 05:14:44 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 05:14:44 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/fbf2117f..9f00c355

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

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

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

From duke at openjdk.org  Thu Oct 16 05:14:44 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 05:14:44 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v5]
In-Reply-To: <v-fZkjDTWZW5AFNnqiF4NDIE457JuGsjatiBa2oBnoI=.e53a7090-417e-42f1-b1c2-8ff0d7f43687@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <-4R3yVX3ufogOLHqu2y6c2EGOPKmiy0rTuVwQoCk_SE=.942b296d-4540-4f57-ac5c-ff214d2985bc@github.com>
 <v-fZkjDTWZW5AFNnqiF4NDIE457JuGsjatiBa2oBnoI=.e53a7090-417e-42f1-b1c2-8ff0d7f43687@github.com>
Message-ID: <hKfLGz8VD8L74v1tnU6dKb_qBAhjU3zfbMxg_hFuc2A=.6f6a4d6a-a9f8-4ba4-a3b7-9e2b827cf015@github.com>

On Thu, 16 Oct 2025 04:49:11 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1032:
> 
>> 1030:      * @return the substituted word.
>> 1031:      */
>> 1032:     private int subByte(int state, byte[][] sub) {
> 
> Given the input and output are both `int` type, i.e. word, maybe it's better named as `subWord` ? This also matches the pseudocode routine name used in the spec. 
> This method also can be made static. It seems that `sub` is always the static `SBOX`, maybe we don't have to use an argument to pass it? 
> nit: the variable name `state` is a bit misleading as we are only using part of it. A state is consisting of 4 words and the input here is only 1 word.

Good, it was a byte operation, but evolved to a word.
Last commit made it a static.
Yes, before I switched over to a LUT for the inverse mix column transform of the inverse key expansion it needed both, but doesn't anymore.
I'll switch from state to word then.
Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434594049

From pminborg at openjdk.org  Thu Oct 16 12:10:32 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 Oct 2025 12:10:32 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v7]
In-Reply-To: <cLuf73uxsm0P8Y5Ak2gfd1VaA9V10vEzfC_o5eiF_D4=.f5dda44e-3621-422f-9c82-0066316b3f08@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <GphZBYlM0eL9LEaj0-3gNxp_8Bu1cpeGp2EZHUSDmNs=.25a985c7-65e2-4e97-ad14-bb56fd515081@github.com>
 <cLuf73uxsm0P8Y5Ak2gfd1VaA9V10vEzfC_o5eiF_D4=.f5dda44e-3621-422f-9c82-0066316b3f08@github.com>
Message-ID: <L63k3vhn-_JXjCB4YWqP0BMS5Or2o7wpsxkSWhMLDsY=.1623d0c1-9a5d-4163-8cc3-67a886e2388a@github.com>

On Mon, 13 Oct 2025 14:41:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/LazyConstant.java
>>   
>>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 287:
> 
>> 285:      */
>> 286:     @Override
>> 287:     boolean equals(Object obj);
> 
> There is a tension here (same for hashCode). A lazy constant is a mutable cell that can be updated only once, given some computing function. When you compare two lazy constants, you can either compare the mutable cell (e.g. the pointer to the memory location where the constant will be eventually stored), or you can compare the constants. Here, the javadoc decides to opt for comparing the constants -- but this might be problematic, as now `equals` can throw exceptions too (and/or result in blocking, as you say in the javadoc). So, I'm not too sure what's the best option here -- do we have an idea of how frequent it is to want to compare two lazy constants "by value" ?
> 
> (for reference, we have no precedent for this: `ClassValue`, `ScopedValue` and `ThreadLocal` do not redefine equals/hashCode).

I have reverted back to the default Object::hashCode and Object::equals methods

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2435655625

From pminborg at openjdk.org  Thu Oct 16 12:13:46 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 Oct 2025 12:13:46 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v2]
In-Reply-To: <jCbxReR2JSGBiZhPw3QWRFp-rKNcpvkpOIQKKzzj5eQ=.7e9eea38-658a-4437-b853-5d780af246e8@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@github.com>
 <jCbxReR2JSGBiZhPw3QWRFp-rKNcpvkpOIQKKzzj5eQ=.7e9eea38-658a-4437-b853-5d780af246e8@github.com>
Message-ID: <Pm4UEROLGDC9v5wdm6odooBmw04zFIvRel9yXiYBFtk=.eff34e79-d727-445c-a604-b7f7a7f7eef5@github.com>

On Mon, 13 Oct 2025 16:48:07 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant field
>
> src/java.base/share/classes/java/util/AbstractMap.java line 335:
> 
>> 333:      */
>> 334:     @Stable
>> 335:     transient Set<K>        keySet;
> 
> Are?all?uses of?this?field in?`java.util` able?to?handle the?`@Stable`ness of?this?field correctly?

That is a good question. The potentially different keySet values should be freely substitutable or else there seams to be something wrong. If they are FS, then the VM should be able to pick any. But it is a big assumption to say that *all* maps that extend AM behave in such a way.  We could go back to the previous version and shadow the field. That seems safest.

Note: there is work in progress to remove these fields.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2435668562

From pminborg at openjdk.org  Thu Oct 16 12:23:26 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 Oct 2025 12:23:26 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v8]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <H9hS2hCFYQUJKs8Z1tFJF8tfI0I-cXFC5D-CQ85N4tE=.ee785239-ed06-400b-be31-e5274835e330@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

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

 - Revert back to Object::(hashCode/equals)
 - Merge branch 'master' into lazy-constants
 - Update src/java.base/share/classes/java/lang/LazyConstant.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Define constant folding
 - Rephrase trusted field text
 - Reprhase text around the computing thread
 - Add links around Error and Throwable
 - Remove redundant field
 - Add optimization where the computing function is returned directly
 - Add benchmark of Optionals
 - ... and 84 more: https://git.openjdk.org/jdk/compare/6cbed094...8fa4a4ca

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/5845a7a5..8fa4a4ca

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

  Stats: 10612 lines in 265 files changed: 5868 ins; 4190 del; 554 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From pminborg at openjdk.org  Thu Oct 16 12:33:31 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 Oct 2025 12:33:31 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v9]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <ZxQxlFeFPecpLa_sU9qbd7gMm9uY0jTH_q1VxODfix4=.db081508-da3c-4d8f-8c22-75082d22ae0c@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rephrase docs on interrupt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/8fa4a4ca..e6268f3d

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

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

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

From pminborg at openjdk.org  Thu Oct 16 12:37:35 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 Oct 2025 12:37:35 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v10]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <QP4aSxOxtSEMQ-CHJhBYAw4NloJio1P3CKW8yjhzYrw=.14a2c02a-1011-4676-bbb4-37c6086b543f@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update first javadoc sentence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/e6268f3d..f5493909

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

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

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

From pminborg at openjdk.org  Thu Oct 16 12:41:56 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 16 Oct 2025 12:41:56 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v11]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <FfKEX44uLjX6qwwlHMRVemJfXnWa6F3wYCNcygDw0aY=.360770c3-3b38-449c-913e-d467ee2baa39@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix test descriptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/f5493909..a51f221a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=09-10

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

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

From mullan at openjdk.org  Thu Oct 16 13:06:25 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 16 Oct 2025 13:06:25 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v13]
In-Reply-To: <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
Message-ID: <5J0Qw7kB_LS-9JA25c6L1ptSNgrv7-wO250eskQdFa8=.73e68edb-f1f1-46b9-98c0-156e2204df2d@github.com>

On Tue, 14 Oct 2025 23:43:39 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remaining comments

src/java.base/share/classes/sun/security/pkcs12/MacData.java line 229:

> 227:         } else {
> 228:             throw new ParsingException("unexpected algorithm '"
> 229:                     +macAlgorithm+ "'");

add spaces around `+`.

src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 121:

> 119:             String kdfHmac, String hmac, byte[] digest) throws NoSuchAlgorithmException {
> 120:         if (algName.equals("PBMAC1")) {
> 121:             return new DerOutputStream().write(DerValue.tag_Sequence, new DerOutputStream()

This use of method chaining is compact, but I find it much harder to review. Consider breaking it up into something more readable. Also, some of the lines are quite long.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2435830879
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2435811684

From weijun at openjdk.org  Thu Oct 16 13:36:21 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 16 Oct 2025 13:36:21 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v13]
In-Reply-To: <5J0Qw7kB_LS-9JA25c6L1ptSNgrv7-wO250eskQdFa8=.73e68edb-f1f1-46b9-98c0-156e2204df2d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <8YN8wBsE62x4fGJKdV6AU1nq2wpmjDiea9dRg6t7-Xg=.04071184-36c7-400b-8f3f-5218ac6f3f4d@github.com>
 <5J0Qw7kB_LS-9JA25c6L1ptSNgrv7-wO250eskQdFa8=.73e68edb-f1f1-46b9-98c0-156e2204df2d@github.com>
Message-ID: <cf2ubdsBgwpTHq-tN_v-btCKegyRqxi1e8mCNDYvUN8=.a9daade3-4740-4010-9e5a-d9b8d98d7742@github.com>

On Thu, 16 Oct 2025 12:56:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remaining comments
>
> src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 121:
> 
>> 119:             String kdfHmac, String hmac, byte[] digest) throws NoSuchAlgorithmException {
>> 120:         if (algName.equals("PBMAC1")) {
>> 121:             return new DerOutputStream().write(DerValue.tag_Sequence, new DerOutputStream()
> 
> This use of method chaining is compact, but I find it much harder to review. Consider breaking it up into something more readable. Also, some of the lines are quite long.

Oh, I suggested this format so it maps almost line to line with the actual encoding:

SEQUENCE
  SEQUENCE
    SEQUENCE
      OID 1.2.840.113549.1.5.14 (PBMAC1)
      SEQUENCE
        SEQUENCE
          OID 1.2.840.113549.1.5.12 (PBKDF2WithHmacSHA1)
          SEQUENCE
            OCTET STRING  (20 bytes)
            INTEGER 10000
            INTEGER 20
            SEQUENCE
              OID 1.2.840.113549.2.7 (HmacSHA1)
              NULL
        SEQUENCE
          OID 1.2.840.113549.2.7 (HmacSHA1)
          NULL
    OCTET STRING  (20 bytes)
  OCTET STRING  (523127819, 8 bytes)
  INTEGER 1

But yes, the single large expression does not align well with the multi-level ASN.1 grammar at the top of this file. I'm fine with breaking it up to better align with that structure.

BTW, the else block is not about PBMAC1. Maybe we should move it back into `MacData`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2435926887

From myankelevich at openjdk.org  Thu Oct 16 16:43:50 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 16 Oct 2025 16:43:50 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl
Message-ID: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>

In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)

Extra logging and error propagating should be implemented for the X509KeyManagerImpl.

Thank you @djelinski for finding the issue and analysis.

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

Commit messages:
 - JDK-8369995: Implement extra logging and/or propagate errors in X509KeyManagerImpl

Changes: https://git.openjdk.org/jdk/pull/27851/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27851&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369995
  Stats: 176 lines in 3 files changed: 163 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27851/head:pull/27851

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

From djelinski at openjdk.org  Thu Oct 16 18:49:56 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 16 Oct 2025 18:49:56 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <DxYv65XqVjHEXyFwrCuEW53wVuZgJ1Qq60OMzHYygn8=.b90630a9-51bc-4ff1-a665-0f2152fff982@github.com>

On Thu, 16 Oct 2025 16:34:50 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
> 
> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
> 
> Thank you @djelinski for finding the issue and analysis.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 248:

> 246:                  KeyStoreException |
> 247:                  NumberFormatException |
> 248:                  NoSuchAlgorithmException e) {

Could you fix the (preexisting) IndexOutOfBounds issues?
- the check in line 226 looks wrong; `secondDot == firstDot` will always return `false`. It should be `secondDot == -1` instead; the current version will probably throw SIOOBE on aliases with a single dot, like `A.1`.
- `builders.get(builderIndex)` might throw IOOBE if builderIndex is out of range for the builders list, like `A.-1.B`.

The only exceptions that we want to propagate here are the `RuntimeException`s thrown by `builder` and `ks`, and we only propagate them so that they can be reported and fixed.

test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 58:

> 56:     @Test
> 57:     public void getCertificateChainIncompleteString() {
> 58:         Assert.assertThrows(StringIndexOutOfBoundsException.class,

Once you fix the KeyManager, you'll need a different set of tests here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2437051091
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2437095546

From abarashev at openjdk.org  Thu Oct 16 19:21:47 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 16 Oct 2025 19:21:47 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <FvINaMPW-pEjnc2nZo0mzRGanTBAODtzh7nNdvjvLSM=.aef859c4-dbc7-4730-a3a6-6b0e2d7ee9c6@github.com>

On Thu, 16 Oct 2025 16:34:50 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
> 
> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
> 
> Thank you @djelinski for finding the issue and analysis.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 251:

> 249:             // ignore and only log exception
> 250:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 251:                 SSLLogger.fine("KeyMgr: exception triggered: " + e);

I think this should be logged at `warning` level.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2437204394

From abarashev at openjdk.org  Thu Oct 16 19:26:21 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 16 Oct 2025 19:26:21 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl
In-Reply-To: <FvINaMPW-pEjnc2nZo0mzRGanTBAODtzh7nNdvjvLSM=.aef859c4-dbc7-4730-a3a6-6b0e2d7ee9c6@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <FvINaMPW-pEjnc2nZo0mzRGanTBAODtzh7nNdvjvLSM=.aef859c4-dbc7-4730-a3a6-6b0e2d7ee9c6@github.com>
Message-ID: <oBf0m7GFYWDIpktb3oho9gpnZ9w410MAP20D_GVLzuE=.21bca5c1-65e7-4ad7-8bcc-cfd0125e9ac8@github.com>

On Thu, 16 Oct 2025 19:18:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
>> 
>> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
>> 
>> Thank you @djelinski for finding the issue and analysis.
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 251:
> 
>> 249:             // ignore and only log exception
>> 250:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>> 251:                 SSLLogger.fine("KeyMgr: exception triggered: " + e);
> 
> I think this should be logged at `warning` level.

Also, `KeyMgr:` string can be removed, the logger will prepend the message with the full class name and line number.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2437216813

From mbalao at openjdk.org  Thu Oct 16 19:39:28 2025
From: mbalao at openjdk.org (Martin Balao Alonso)
Date: Thu, 16 Oct 2025 19:39:28 GMT
Subject: RFR: 8225739: sun/security/pkcs11/tls/tls12/FipsModeTLS12.java is
 not reliable [v3]
In-Reply-To: <3Y-OWPpeWf2LfdUUllVANzvs9LnldUWFMKL0IaMowB0=.a25b90df-fbc1-42f3-b132-9f3c4818e480@github.com>
References: <3Y-OWPpeWf2LfdUUllVANzvs9LnldUWFMKL0IaMowB0=.a25b90df-fbc1-42f3-b132-9f3c4818e480@github.com>
Message-ID: <w_1YdEVXaXPF51uN-Le4SHuGux0FD96_hoSNRLCeFuY=.b581c968-0a4b-4eb0-8cf3-851aff1778ab@github.com>

> Hello,
> 
> I would like to propose a solution for this test that makes it more clear when it's skipped.
> 
> Regards,
> Martin.-

Martin Balao Alonso has updated the pull request incrementally with one additional commit since the last revision:

  Adapt according to @rhalade review suggestions
  
  But keep some exception handling in the initialize() method, see the
  following comment for more details:
  https://github.com/openjdk/jdk/pull/23177#discussion_r2427408511

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23177/files
  - new: https://git.openjdk.org/jdk/pull/23177/files/fcdd422c..c4a24917

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

  Stats: 21 lines in 1 file changed: 4 ins; 13 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23177/head:pull/23177

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

From valeriep at openjdk.org  Thu Oct 16 20:04:35 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 16 Oct 2025 20:04:35 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>
Message-ID: <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>

On Thu, 16 Oct 2025 05:14:44 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1040:

> 1038:      * @param p [in] the plaintext to be encrypted.
> 1039:      * @param po [in] the plaintext offset in the array of bytes.
> 1040:      * @param c [out] the encrypted ciphertext output.

nit: ciphertext already implied to be encrypted. Maybe no need for the "encrypted" adj.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1157:

> 1155:             ti3 = T0[a3 >>> 24] ^ T1[(a0 >> 16) & 0xFF]
> 1156:                     ^ T2[(a1 >> 8) & 0xFF] ^ T3[a2 & 0xFF] ^ K[w + 7];
> 1157:             w += 8;

No need for w, since you already checked the `rounds` value, you can directly reference K inside this block, i.e. K[40] - K[47]. Same goes for the next block for AES-256, i.e. directly reference K[48]-K[55].

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1195:

> 1193:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
> 1194:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
> 1195:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w+3];

Here you always use the last 4 elements of `K`, so you can just use `w = K.length - 4` and no need to keep tracking it in the earlier 2 blocks.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1220:

> 1218:      * @param c [in] the ciphertext to be decrypted.
> 1219:      * @param co [in] the ciphertext offset in the array of bytes.
> 1220:      * @param p [out] the decrypted plaintext output.

nit: same comment for removing "decrypted" adj.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437316942
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437308268
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437313179
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437325831

From duke at openjdk.org  Thu Oct 16 20:04:37 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 20:04:37 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>
 <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>
Message-ID: <yjp97Nf6C11SkoOkNb7wxk04vZ4FFWcGX_rVDgRCx_w=.431a9ec0-3cb4-47fa-b404-aa292bfcaa8a@github.com>

On Thu, 16 Oct 2025 19:55:12 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1157:
> 
>> 1155:             ti3 = T0[a3 >>> 24] ^ T1[(a0 >> 16) & 0xFF]
>> 1156:                     ^ T2[(a1 >> 8) & 0xFF] ^ T3[a2 & 0xFF] ^ K[w + 7];
>> 1157:             w += 8;
> 
> No need for w, since you already checked the `rounds` value, you can directly reference K inside this block, i.e. K[40] - K[47]. Same goes for the next block for AES-256, i.e. directly reference K[48]-K[55].

I would still need w for lines 1180 - 1195 though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437324027

From duke at openjdk.org  Thu Oct 16 20:22:20 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 20:22:20 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/9f00c355..a5991a2f

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

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

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

From duke at openjdk.org  Thu Oct 16 20:22:22 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 16 Oct 2025 20:22:22 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v7]
In-Reply-To: <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <oT2wX-q2OA1sTyC8rt576Ry-1PZfWHR9dZybV2poolI=.0ffc3772-164e-4bac-baf0-fe10e07fc169@github.com>
 <thhkFtuKIT1UnLkPyHEclJl9rz478YFQC8NXFkhhG3s=.9af93ffd-4ccd-408d-bc0d-fe58bc81bac8@github.com>
Message-ID: <rlaQjW3we7FZT6JSVZUmC8DLRTVpTDk4P5fwg348HHM=.a2e1dfc0-d154-44ed-b478-33eaa27b4d34@github.com>

On Thu, 16 Oct 2025 19:58:40 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1040:
> 
>> 1038:      * @param p [in] the plaintext to be encrypted.
>> 1039:      * @param po [in] the plaintext offset in the array of bytes.
>> 1040:      * @param c [out] the encrypted ciphertext output.
> 
> nit: ciphertext already implied to be encrypted. Maybe no need for the "encrypted" adj.

Agreed.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1195:
> 
>> 1193:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
>> 1194:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
>> 1195:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w+3];
> 
> Here you always use the last 4 elements of `K`, so you can just use `w = K.length - 4` and no need to keep tracking it in the earlier 2 blocks.

Agreed.  I've changed decryption as well.  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1220:
> 
>> 1218:      * @param c [in] the ciphertext to be decrypted.
>> 1219:      * @param co [in] the ciphertext offset in the array of bytes.
>> 1220:      * @param p [out] the decrypted plaintext output.
> 
> nit: same comment for removing "decrypted" adj.

Agreed.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437361415
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437361126
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437362009

From weijun at openjdk.org  Fri Oct 17 03:12:05 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Oct 2025 03:12:05 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v5]
In-Reply-To: <jAREXFgeXflXzTz0axZQwWJ8OBd1OTZu0OV0U89eZxk=.404060d0-b679-43ae-b7b0-288831b222ca@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <jAREXFgeXflXzTz0axZQwWJ8OBd1OTZu0OV0U89eZxk=.404060d0-b679-43ae-b7b0-288831b222ca@github.com>
Message-ID: <Z1cJ-LqWjLK9GvrlxniY557vvLxuOfWnm6A-A6aFrLw=.33b44af0-f978-4b13-9ab4-4fcb7d916b6e@github.com>

On Sun, 12 Oct 2025 01:26:43 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27700#pullrequestreview-3347880709

From valeriep at openjdk.org  Fri Oct 17 05:44:04 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 05:44:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
Message-ID: <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>

On Thu, 16 Oct 2025 20:22:20 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911:

> 909:             }
> 910:             sessionK[0] = genRoundKeys(key, rounds);
> 911:             sessionK[1] = invGenRoundKeys();

Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g.

 private static int[][] genRoundKeys(byte[] key, int rounds) {
        int[][] ks = new int[2][]; // key schedule

        int wLen = (rounds + 1) * WB;
        int nk = key.length / WB;

        // generate the round keys for encryption
        int[] w = new int[wLen];
        for (int i = 0, j = 0; i < nk; i++, j+=4) {
            w[i] = ((key[j] & 0xFF) << 24)
                    | ((key[j + 1] & 0xFF) << 16)
                    | ((key[j + 2] & 0xFF) << 8)
                    | (key[j + 3] & 0xFF);
        }
        for (int i = nk; i < wLen; i++) {
            int tmp = w[i - 1];
            if (i % nk == 0) {
                int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24);
                tmp = subWord(rW) ^ RCON[(i / nk) - 1];
            } else if ((nk > 6) && ((i % nk) == WB)) {
                tmp = subWord(tmp);
            }
            w[i] = w[i - nk] ^ tmp;
        }
        ks[0] = w;

        // generate the decryption round keys based on encryption ones
        int[] dw = new int[wLen];
        int[] temp = new int[WB];

        // Intrinsics requires the inverse key expansion to be reverse order
        // except for the first and last round key as the first two round keys
        // are without a mix column transform.
        for (int i = 1; i < rounds; i++) {
            System.arraycopy(w, i * WB, temp, 0, WB);
            invMixRKey(temp);
            System.arraycopy(temp, 0, dw, wLen - (i * WB), WB);
        }
        // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)]
        System.arraycopy(w, 0, dw, 0, WB);
        System.arraycopy(w, wLen - WB, dw, WB, WB);
        ks[1] = dw;
        Arrays.fill(temp, 0);

        return ks;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438441223

From valeriep at openjdk.org  Fri Oct 17 06:17:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 06:17:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
Message-ID: <Tj5N0POau9TQJhtth0YNN7hx2ofNHkn57Bx4FCPMuWw=.7c460466-36c2-4679-8bb9-b9c1f756f402@github.com>

On Thu, 16 Oct 2025 20:22:20 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958:

> 956:      * @return the processed round key row.
> 957:      */
> 958:     private static int invMix(int[] state, int idx) {

It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g.

    private static void invMixRKey(int[] state) {
        state[0] = invMix(state[0]);
        state[1] = invMix(state[1]);
        state[2] = invMix(state[2]);
        state[3] = invMix(state[3]);
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438501716

From valeriep at openjdk.org  Fri Oct 17 06:30:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 06:30:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
Message-ID: <56BA-l6ZrdSY0IRWxXme_AM_CWW_vtBSrzYqIA4oZaE=.b9011356-c376-455a-8964-4534f9db6035@github.com>

On Thu, 16 Oct 2025 20:22:20 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 976:

> 974:      * @param state [in, out] the round key for inverse mix column processing.
> 975:      */
> 976:     private static void invMixRKey(int[] state) {

nit: name the method "invMixColumns(int[])". This name matches the spec psuedo code and goes better with the "state" argument name. Or use "invMixRoundKey(int[] roundKey)"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438537870

From duke at openjdk.org  Fri Oct 17 06:56:43 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 06:56:43 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <bSpdp7-d6oB_azxWIu-KYH-7yRy8xTIYqS0aPz-oUsw=.8fed6422-10fd-4112-8be3-73778f7d3d23@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/a5991a2f..2ce35b97

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

  Stats: 47 lines in 1 file changed: 7 ins; 39 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27807/head:pull/27807

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

From duke at openjdk.org  Fri Oct 17 06:56:46 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 06:56:46 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
Message-ID: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>

On Fri, 17 Oct 2025 05:41:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911:
> 
>> 909:             }
>> 910:             sessionK[0] = genRoundKeys(key, rounds);
>> 911:             sessionK[1] = invGenRoundKeys();
> 
> Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g.
> 
>  private static int[][] genRoundKeys(byte[] key, int rounds) {
>         int[][] ks = new int[2][]; // key schedule
> 
>         int wLen = (rounds + 1) * WB;
>         int nk = key.length / WB;
> 
>         // generate the round keys for encryption
>         int[] w = new int[wLen];
>         for (int i = 0, j = 0; i < nk; i++, j+=4) {
>             w[i] = ((key[j] & 0xFF) << 24)
>                     | ((key[j + 1] & 0xFF) << 16)
>                     | ((key[j + 2] & 0xFF) << 8)
>                     | (key[j + 3] & 0xFF);
>         }
>         for (int i = nk; i < wLen; i++) {
>             int tmp = w[i - 1];
>             if (i % nk == 0) {
>                 int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24);
>                 tmp = subWord(rW) ^ RCON[(i / nk) - 1];
>             } else if ((nk > 6) && ((i % nk) == WB)) {
>                 tmp = subWord(tmp);
>             }
>             w[i] = w[i - nk] ^ tmp;
>         }
>         ks[0] = w;
> 
>         // generate the decryption round keys based on encryption ones
>         int[] dw = new int[wLen];
>         int[] temp = new int[WB];
> 
>         // Intrinsics requires the inverse key expansion to be reverse order
>         // except for the first and last round key as the first two round keys
>         // are without a mix column transform.
>         for (int i = 1; i < rounds; i++) {
>             System.arraycopy(w, i * WB, temp, 0, WB);
>             invMixRKey(temp);
>             System.arraycopy(temp, 0, dw, wLen - (i * WB), WB);
>         }
>         // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)]
>         System.arraycopy(w, 0, dw, 0, WB);
>         System.arraycopy(w, wLen - WB, dw, WB, WB);
>         ks[1] = dw;
>         Arrays.fill(temp, 0);
> 
>         return ks;
>     }

These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse.  The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958:
> 
>> 956:      * @return the processed round key row.
>> 957:      */
>> 958:     private static int invMix(int[] state, int idx) {
> 
> It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g.
> 
>     private static void invMixRKey(int[] state) {
>         state[0] = invMix(state[0]);
>         state[1] = invMix(state[1]);
>         state[2] = invMix(state[2]);
>         state[3] = invMix(state[3]);
>     }

I've removed this method and inlined this logic in the invGenRoundKeys method.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 976:
> 
>> 974:      * @param state [in, out] the round key for inverse mix column processing.
>> 975:      */
>> 976:     private static void invMixRKey(int[] state) {
> 
> nit: name the method "invMixColumns(int[])". This name matches the spec psuedo code and goes better with the "state" argument name. Or use "invMixRoundKey(int[] roundKey)"?

I've removed this method and inlined this logic in the invGenRoundKeys method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438587221
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438587085
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438586207

From valeriep at openjdk.org  Fri Oct 17 07:07:11 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 07:07:11 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
Message-ID: <3IhmbTDiDNPdMTe_K1OZx6sC67UGjObzOXwX8Ekp7pA=.0e742e44-4dba-4680-8f24-7321f8516071@github.com>

On Fri, 17 Oct 2025 06:52:39 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958:
>> 
>>> 956:      * @return the processed round key row.
>>> 957:      */
>>> 958:     private static int invMix(int[] state, int idx) {
>> 
>> It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g.
>> 
>>     private static void invMixRKey(int[] state) {
>>         state[0] = invMix(state[0]);
>>         state[1] = invMix(state[1]);
>>         state[2] = invMix(state[2]);
>>         state[3] = invMix(state[3]);
>>     }
>
> I've removed this method and inlined this logic in the invGenRoundKeys method.

Sure, this works as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438612714

From pminborg at openjdk.org  Fri Oct 17 09:25:01 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Oct 2025 09:25:01 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v12]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update javadocs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/a51f221a..6a6e804e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=10-11

  Stats: 59 lines in 1 file changed: 7 ins; 3 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From mcimadamore at openjdk.org  Fri Oct 17 09:51:21 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Oct 2025 09:51:21 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v12]
In-Reply-To: <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
Message-ID: <xUCqJe-9AQt-lhaeB7CPjVQih7dHQ_Cf9W4Mr39SZ4Q=.89bba8d8-6976-4cb4-8526-2ff801ac268c@github.com>

On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadocs

src/java.base/share/classes/java/lang/LazyConstant.java line 46:

> 44:  * A lazy constant is created using the factory method
> 45:  * {@linkplain LazyConstant#of(Supplier) LazyConstant.of({@code <computing function>})}.
> 46:  * When created, the contents (and hence the lazy constant itself) is <em>not initialized</em>.

"When created, the lazy constant is not initialized, meaning it has no contents."

E.g. it's the lazy constant that is initialized/not initialized. The content "just is". (or "is not", if not initialized).

src/java.base/share/classes/java/lang/LazyConstant.java line 47:

> 45:  * {@linkplain LazyConstant#of(Supplier) LazyConstant.of({@code <computing function>})}.
> 46:  * When created, the contents (and hence the lazy constant itself) is <em>not initialized</em>.
> 47:  * The contents (of type {@code T}) can then be <em>initialized</em>

Again, "a lazy constant can be initialized, and its content retrieved, by calling get"

src/java.base/share/classes/java/lang/LazyConstant.java line 50:

> 48:  * (and retrieved) by calling {@linkplain #get()}. The first time {@linkplain #get()}
> 49:  * is called, the underlying <em>computing function</em> (provided at construction) will
> 50:  * be invoked and the result will be used to initialize the contents. Once initialized,

"and the result will be used to initialize the lazy constant. Once a lazy constant is initialized, its contents can never change..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439058429
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439060624
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439064085

From mcimadamore at openjdk.org  Fri Oct 17 09:56:18 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Oct 2025 09:56:18 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v12]
In-Reply-To: <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
Message-ID: <e9sxObjsMVjJAWHKFwjRKKlj3gI2o8WkJsPmFR86YNI=.db93632d-0563-4537-b125-3082e51d24b9@github.com>

On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadocs

src/java.base/share/classes/java/lang/LazyConstant.java line 54:

> 52:  * again upon subsequent {@linkplain #get() get} invocations.
> 53:  * <p>
> 54:  * A lazy constant is <em>shallowly immutable</em>, meaning the reference to the contents

This para here seems a bit redundant. In part it repeats something already said (when initialized, contents will never change). I'd drop this from here, and maybe push it down to an API note (e.g. note: the contents of a lazy constant can be mutable -- e.g. an ArrayList).

src/java.base/share/classes/java/lang/LazyConstant.java line 60:

> 58:  * <p>
> 59:  * Consider the following example where a lazy constant field "{@code logger}" is a
> 60:  * shallowly immutable holder of an object of type {@code Logger}:

"where the lazy constant field "logger" holds an object of type Logger"

src/java.base/share/classes/java/lang/LazyConstant.java line 77:

> 75:  *}
> 76:  * <p>
> 77:  * Initially, the lazy constant (and its contents) is <em>not initialized</em>.

Suggestion:

 * Initially, the lazy constant is <em>not initialized</em>.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439072055
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439073774
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439075865

From mcimadamore at openjdk.org  Fri Oct 17 10:08:22 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Oct 2025 10:08:22 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v12]
In-Reply-To: <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
Message-ID: <KUnnT7OFVdtdQT0Rn7dOgdL29WBLMai36yPCeiVteFQ=.884c2191-c362-49eb-8450-3351d1570dc3@github.com>

On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadocs

src/java.base/share/classes/java/lang/LazyConstant.java line 101:

> 99:  * {@linkplain Error}, that {@linkplain Throwable} is propagated to the caller, and the
> 100:  * lazy constant remains uninitialized. In other words, upon an unsuccessful invocation of
> 101:  * the computing function, neither a constant, the exception, nor the fact that

"In other words" I don't think this sentence adds much. I think it's better to just drop it. The main thing to say is that if computing function is unsuccessful, the lazy constant stays uninitialized (which we already said).

src/java.base/share/classes/java/lang/LazyConstant.java line 111:

> 109:  * which are held by lazy constants:
> 110:  *
> 111:  * {@snippet lang = java:

If you wanted, you could reuse the `Component`  class -- that one already has a lazy constant field, so if you put the component itself in another lazy constant field you have your composition example.

src/java.base/share/classes/java/lang/LazyConstant.java line 144:

> 142:  *
> 143:  * <h2 id="thread-safety">Thread Safety</h2>
> 144:  * A lazy constant is guaranteed to be initialized atomically and at most once. If

We already mention some of these above:

"Furthermore, {@linkplain #get()} guarantees that, out of several threads trying to
 * invoke the computing function simultaneously, only one is ever selected for
 * computation"
 
 Maybe add a reference form that text to this section?

src/java.base/share/classes/java/lang/LazyConstant.java line 152:

> 150:  * <p>
> 151:  * The invocation of the computing function and the resulting initialization of
> 152:  * the constant {@linkplain java.util.concurrent##MemoryVisibility <em>happens-before</em>}

Do you mean constant or content? I think the latter? E.g. when you initialize a lazy constant, you safely publish its contents? (the lazy constant itself is already published)

src/java.base/share/classes/java/lang/LazyConstant.java line 158:

> 156:  * Thread interruption does not cancel the initialization of a lazy constant. In other
> 157:  * words, if the computing thread is interrupted, {@code LazyConstant::get} doesn't clear
> 158:  * the interrupted thread?s status, nor does it throw an InterruptedException.

Suggestion:

 * the interrupted thread?s status, nor does it throw an {@code InterruptedException}.

src/java.base/share/classes/java/lang/LazyConstant.java line 164:

> 162:  *
> 163:  * <h2 id="performance">Performance</h2>
> 164:  * A lazy constant can never change after it has been initialized. Therefore,

The contents of a lazy constant can never change after the lazy constant has been initialized (again, spell out things clearly)

src/java.base/share/classes/java/lang/LazyConstant.java line 166:

> 164:  * A lazy constant can never change after it has been initialized. Therefore,
> 165:  * a JVM implementation may, for an initialized lazy constant, elide all future reads
> 166:  * of that lazy constant and instead directly use any constant that it has previously

"elide all future reads of that lazy constant's contents and instead use the contents that has been previously observed"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439091644
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439096445
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439102301
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439110166
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439114804
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439119542
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439124386

From alanb at openjdk.org  Fri Oct 17 10:10:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Oct 2025 10:10:36 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions
In-Reply-To: <45gEnigXd-WxofLVYu0K6QDbLq72YZvzroUWy-owk6M=.d25d1075-2488-4982-906f-5cc431429823@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <VOpnIb1YIv419CudMEK6ftGQ0a6OSolUquaAO63BKtI=.7a414618-6d5a-4b8f-9a9c-3c35e7655960@github.com>
 <45gEnigXd-WxofLVYu0K6QDbLq72YZvzroUWy-owk6M=.d25d1075-2488-4982-906f-5cc431429823@github.com>
Message-ID: <iw4NcdhA6TkUsoHcdrKXsQsG2d9CtBrXBobuXyUT0QY=.cad72c9d-ac36-4b65-a915-381a864f10ff@github.com>

On Thu, 1 May 2025 10:35:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> File::getCanonicalPath seems to take the best-effort approach (both in Linux and Windows), whereas Path::toRealPath is stricter.
>> 
>> Path::toRealPath is doing the right thing, and consistent with realpath(2). The issue with File::getCanonicalXXX is that it is specified to return a canonical file even if it doesn't exist, so this is why you see a lot more code to compute a result.
>> 
>> Maybe the recursive include check them maybe it should use the file key instead.
>
>> @AlanBateman are you ok with letting the original [c6f1d5f](https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab) reviewers know of this fix and take a look? Or do you think further discussion is needed somewhere else?
> 
> Have you had time to try using the file key to detect the recursive include case?

> Hi @AlanBateman, I'm resuming the work on this one.
> 
> > Have you had time to try using the file key to detect the recursive include case?
> 
> By "file key", do you mean `Files.readAttributes(Path.of("..."), BasicFileAttributes.class).fileKey()`? This works on _Linux_ but returns `null` on _Windows_.

Can you try Files.isSameFile? It will use the file key on all platforms. If the file located by the included path, and the previous files encountered, are accessible then it can be loadFromPath..

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3414764843

From mcimadamore at openjdk.org  Fri Oct 17 10:20:09 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Oct 2025 10:20:09 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v12]
In-Reply-To: <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
Message-ID: <2V6nUv7mUoPV7kx6uQXMTM9D4Xdm-1xEK7ErgbEAdds=.0bc05925-08b5-4799-903c-04b9bfa4760d@github.com>

On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadocs

src/java.base/share/classes/java/lang/LazyConstant.java line 168:

> 166:  * of that lazy constant and instead directly use any constant that it has previously
> 167:  * observed. We call this optimization <em>constant folding</em>. This is only possible if
> 168:  * the reference to the lazy constant is a VM constant (e.g. in cases where

Not sure talking about VM constant is good. We could alternatively say:

"if the lazy constant is stored in a static final field, either directly, or indirectly, via one or more trusted fields (i.e. any combination...)"

src/java.base/share/classes/java/lang/LazyConstant.java line 179:

> 177:  * must be <em>non-null</em>, or a {@link NullPointerException} will be thrown.
> 178:  *
> 179:  * @apiNote Once a lazy constant is initialized with an object, the object cannot ever be

Once a lazy constant is initialized, its contents can never be removed...

src/java.base/share/classes/java/lang/LazyConstant.java line 182:

> 180:  *          removed. This can be a source of an unintended memory leak. More specifically,
> 181:  *          a lazy constant {@linkplain java.lang.ref##reachability strongly references}
> 182:  *          the object it was initialized with. Hence, a lazy constant will hold

s/the object it was initialized with/its contents (here and below)

src/java.base/share/classes/java/lang/LazyConstant.java line 186:

> 184:  *          is collected (if ever).
> 185:  *          <p>
> 186:  *          A {@code LazyConstant} that has a type parameter {@code T} that is an

"A lazy constant whose contents is an array will not optimize access to the the elements of such array. Instead, ..."

src/java.base/share/classes/java/lang/LazyConstant.java line 191:

> 189:  *          Instead, a {@linkplain List#ofLazy(int, IntFunction) lazy list} of
> 190:  *          arbitrary depth can be used, which provides constant components.
> 191:  *          More generally, a lazy constant can hold other lazy constants of

More generally... you said that in the composition section?

src/java.base/share/classes/java/lang/LazyConstant.java line 233:

> 231: 
> 232:     /**
> 233:      * {@return the initialized contents. If not initialized, first computes and

"initialized contents" is not a term you have defined in this javadoc. `get` returns the contents of this lazy constant. If the lazy constant is not initialized...

src/java.base/share/classes/java/lang/LazyConstant.java line 267:

> 265:      */
> 266:     @Override
> 267:     String toString();

I think it might be worth also defining a javadoc for equals/hashCode, to say explicitly that they will also not trigger initialization

src/java.base/share/classes/java/lang/LazyConstant.java line 284:

> 282:      * directly.
> 283:      *
> 284:      * @param computingFunction in the form of a Supplier to be used to compute

Suggestion:

     * @param computingFunction a {@code Supplier} used to initialize

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439138229
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439141653
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439144255
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439156012
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439150170
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439161143
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439169909
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439174349

From mcimadamore at openjdk.org  Fri Oct 17 10:25:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Oct 2025 10:25:47 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v12]
In-Reply-To: <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <EAkEuqwBLqe1nPzz8tIWkWiJYrV6B-xgL6hZaDuZ78o=.cbff24a4-9ccd-426a-a4ac-587f88bf1075@github.com>
Message-ID: <lMM70mIcRkJ1oFHM4p3g1jjZWbLW8z3fRzTNHk-nK1g=.cf4bdaaa-1613-4415-add4-77c1e48ec97e@github.com>

On Fri, 17 Oct 2025 09:25:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadocs

src/java.base/share/classes/java/util/List.java line 1231:

> 1229:      * will be thrown.
> 1230:      * <p>
> 1231:      * The returned lazy list strongly references its computing

We should say that hashCode/equals trigger computation

src/java.base/share/classes/java/util/Map.java line 1784:

> 1782:      * will be thrown.
> 1783:      * <p>
> 1784:      * The returned lazy map strongly references its underlying

Again, we should say that equals/hashCode triggers computation

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439200027
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2439207782

From pminborg at openjdk.org  Fri Oct 17 11:43:47 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Oct 2025 11:43:47 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v13]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <kYdb8x52_D7-3eZZc1mK22QlsDwP0kwlv0P04wKaSjU=.1c6ed62e-7bea-4da3-b9e7-e6f2c8ac4ebc@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update wording on List/Map Object methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/6a6e804e..8cde6974

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=11-12

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

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

From pminborg at openjdk.org  Fri Oct 17 12:13:48 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Oct 2025 12:13:48 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v14]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <wiw_E3cb4mrh4lG3uXZOIsbqhr8GztAxu1vqWnsFEtQ=.eeb727bb-7717-4897-a99d-623f203b98d4@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve equals/hashCode document

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/8cde6974..77ae3fe1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=12-13

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

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

From myankelevich at openjdk.org  Fri Oct 17 12:18:45 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 12:18:45 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v2]
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <7pRMc17mRL0rR5CgNInq8GrFJpnBOMUkthE1bgF3Vf4=.5bae54e5-4faa-46d2-872e-94da6c3e049f@github.com>

> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
> 
> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
> 
> Additionally, dot checking logic has been changed, so no cases similar to `.A` will not trigger StringOutOfBounds exceptions. 
> 
> Thank you @djelinski for finding the issue and analysis.

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

  index out of bounds and string out of bounds exception fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27851/files
  - new: https://git.openjdk.org/jdk/pull/27851/files/cabf86f0..6f1c6a28

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

  Stats: 298 lines in 3 files changed: 193 ins; 52 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/27851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27851/head:pull/27851

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

From myankelevich at openjdk.org  Fri Oct 17 12:18:47 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 12:18:47 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v2]
In-Reply-To: <DxYv65XqVjHEXyFwrCuEW53wVuZgJ1Qq60OMzHYygn8=.b90630a9-51bc-4ff1-a665-0f2152fff982@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <DxYv65XqVjHEXyFwrCuEW53wVuZgJ1Qq60OMzHYygn8=.b90630a9-51bc-4ff1-a665-0f2152fff982@github.com>
Message-ID: <X2Tt6p40XEii3YSpw1sdQLglRbWzL7w4U-8pni_7Z24=.81710e10-2aa1-48df-9a1e-ba24f4c52172@github.com>

On Thu, 16 Oct 2025 18:32:20 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   index out of bounds and string out of bounds exception fixes
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 248:
> 
>> 246:                  KeyStoreException |
>> 247:                  NumberFormatException |
>> 248:                  NoSuchAlgorithmException e) {
> 
> Could you fix the (preexisting) IndexOutOfBounds issues?
> - the check in line 226 looks wrong; `secondDot == firstDot` will always return `false`. It should be `secondDot == -1` instead; the current version will probably throw SIOOBE on aliases with a single dot, like `A.1`.
> - `builders.get(builderIndex)` might throw IOOBE if builderIndex is out of range for the builders list, like `A.-1.B`.
> 
> The only exceptions that we want to propagate here are the `RuntimeException`s thrown by `builder` and `ks`, and we only propagate them so that they can be reported and fixed.

I agree, changed in the next commit. Will update the ticket as well

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2439666430

From myankelevich at openjdk.org  Fri Oct 17 12:18:49 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 12:18:49 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v2]
In-Reply-To: <oBf0m7GFYWDIpktb3oho9gpnZ9w410MAP20D_GVLzuE=.21bca5c1-65e7-4ad7-8bcc-cfd0125e9ac8@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <FvINaMPW-pEjnc2nZo0mzRGanTBAODtzh7nNdvjvLSM=.aef859c4-dbc7-4730-a3a6-6b0e2d7ee9c6@github.com>
 <oBf0m7GFYWDIpktb3oho9gpnZ9w410MAP20D_GVLzuE=.21bca5c1-65e7-4ad7-8bcc-cfd0125e9ac8@github.com>
Message-ID: <A9Qbdo4O8VY6vQ1Mc_-ntRhemzpu_bJniyewE66aCGc=.4dd0a727-0de4-4c1c-aa9e-4b2aaa7a3e76@github.com>

On Thu, 16 Oct 2025 19:24:06 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 251:
>> 
>>> 249:             // ignore and only log exception
>>> 250:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>>> 251:                 SSLLogger.fine("KeyMgr: exception triggered: " + e);
>> 
>> I think this should be logged at `warning` level.
>
> Also, `KeyMgr:` string can be removed, the logger will prepend the message with the full class name and line number.

I agree with logging this as warning. However I think keeping `KeyMgr:` would be better, as this format is used in the existing code in the class. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2439693629

From myankelevich at openjdk.org  Fri Oct 17 12:23:55 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 12:23:55 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v3]
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <EaFz9HhXI0JExAHyqLqwKzC9LrX36JYW1Gb_7Df3_Dc=.e72cfb2f-03e0-4e7a-9fbc-79f623560b9b@github.com>

> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
> 
> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
> 
> Additionally, dot checking logic has been changed, so no cases similar to `.A` will not trigger StringOutOfBounds exceptions. 
> 
> Thank you @djelinski for finding the issue and analysis.

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

  changed log to warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27851/files
  - new: https://git.openjdk.org/jdk/pull/27851/files/6f1c6a28..98e84b22

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

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

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

From pminborg at openjdk.org  Fri Oct 17 12:28:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Oct 2025 12:28:15 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v15]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <SJDlPpzmN5qFKTDK9QLQUIMrmifovO6kM-b6ieFssl4=.da2c69d7-7660-451b-ad27-2b5571c48601@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Improve method docs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/77ae3fe1..e2c24f5c

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

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

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

From epeter at openjdk.org  Fri Oct 17 13:02:04 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 17 Oct 2025 13:02:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: <bSpdp7-d6oB_azxWIu-KYH-7yRy8xTIYqS0aPz-oUsw=.8fed6422-10fd-4112-8be3-73778f7d3d23@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <bSpdp7-d6oB_azxWIu-KYH-7yRy8xTIYqS0aPz-oUsw=.8fed6422-10fd-4112-8be3-73778f7d3d23@github.com>
Message-ID: <j3iXi_pwWF6jLiOwx66HI49j_9-0Pvniu-RcxpVUczc=.4a49e952-ec3a-4995-a4c3-43f15978f9a0@github.com>

On Fri, 17 Oct 2025 06:56:43 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 44:

> 42: 
> 43:     @Param("10000000")
> 44:     private int count;

Drive-by comment / question:
Did you do all benchmarking with this single (quite large) size? How are the results for much smaller sizes? It may be worth it to just get a nice plot that goes over a range of sizes, to see if it behaves as expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2439948821

From pminborg at openjdk.org  Fri Oct 17 13:13:45 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Oct 2025 13:13:45 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v16]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <j-PnauaTb4hTx3aM7nhcSITeqkosHn5kOZtOLaHOLfY=.7d5b07ad-e633-498b-b910-aa9d90a8f44f@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update docs after comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/e2c24f5c..d961426d

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

  Stats: 58 lines in 1 file changed: 3 ins; 16 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From myankelevich at openjdk.org  Fri Oct 17 13:28:35 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 13:28:35 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v5]
In-Reply-To: <jAREXFgeXflXzTz0axZQwWJ8OBd1OTZu0OV0U89eZxk=.404060d0-b679-43ae-b7b0-288831b222ca@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <jAREXFgeXflXzTz0axZQwWJ8OBd1OTZu0OV0U89eZxk=.404060d0-b679-43ae-b7b0-288831b222ca@github.com>
Message-ID: <U2xfUQsErs-2iGKu8q_VuPRsmay4U6E72BEF2Gx2vlI=.8c835ec8-7a84-45c5-b34e-6704441326e1@github.com>

On Sun, 12 Oct 2025 01:26:43 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 146:

> 144:          */
> 145:         if (params.tag == DerValue.tag_Null) {
> 146:             if (params.length() != 0) {

Could you please extend the current tests to cover the case when `params.tag == DerValue.tag_Null `? This doesn't seem to be covered by your tests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2440026013

From pminborg at openjdk.org  Fri Oct 17 14:06:44 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Oct 2025 14:06:44 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v17]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <zM7MjwEPDlbkRqVK3oKF_XoNurV_SolIFwVf3IECToA=.420b3ead-658d-4cf5-9793-483483f87087@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert the AbstractMap.keySet @Stable annotation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/d961426d..698b4125

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

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

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

From pminborg at openjdk.org  Fri Oct 17 14:10:39 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Oct 2025 14:10:39 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v2]
In-Reply-To: <Pm4UEROLGDC9v5wdm6odooBmw04zFIvRel9yXiYBFtk=.eff34e79-d727-445c-a604-b7f7a7f7eef5@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <90jKH5-Bb3vf27uhLPOUtgmYmZRFdH1voVYr8kIR__I=.2aff8cb2-38be-4dd3-a1df-e3f8a7a90542@github.com>
 <jCbxReR2JSGBiZhPw3QWRFp-rKNcpvkpOIQKKzzj5eQ=.7e9eea38-658a-4437-b853-5d780af246e8@github.com>
 <Pm4UEROLGDC9v5wdm6odooBmw04zFIvRel9yXiYBFtk=.eff34e79-d727-445c-a604-b7f7a7f7eef5@github.com>
Message-ID: <d3vSMHiL-Mf8Qab1IoTHg7nTpD6FEOXPUYH0lMoTgz8=.b694f42c-74fc-4848-bcc9-9b9d9cae96c6@github.com>

On Thu, 16 Oct 2025 12:10:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/AbstractMap.java line 335:
>> 
>>> 333:      */
>>> 334:     @Stable
>>> 335:     transient Set<K>        keySet;
>> 
>> Are?all?uses of?this?field in?`java.util` able?to?handle the?`@Stable`ness of?this?field correctly?
>
> That is a good question. The potentially different keySet values should be freely substitutable or else there seams to be something wrong. If they are FS, then the VM should be able to pick any. But it is a big assumption to say that *all* maps that extend AM behave in such a way.  We could go back to the previous version and shadow the field. That seems safest.
> 
> Note: there is work in progress to remove these fields.

I've reverted the @Stable annotation on AM.keySet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440164233

From mcimadamore at openjdk.org  Fri Oct 17 14:17:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Oct 2025 14:17:54 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v16]
In-Reply-To: <j-PnauaTb4hTx3aM7nhcSITeqkosHn5kOZtOLaHOLfY=.7d5b07ad-e633-498b-b910-aa9d90a8f44f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <j-PnauaTb4hTx3aM7nhcSITeqkosHn5kOZtOLaHOLfY=.7d5b07ad-e633-498b-b910-aa9d90a8f44f@github.com>
Message-ID: <_kXdqyWalfyZNF_Bhnuw9NQh-9x3cutCQEB-r72fLR4=.aaadf47e-46d7-43d2-99dc-c6e0da1f8ad6@github.com>

On Fri, 17 Oct 2025 13:13:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update docs after comments

src/java.base/share/classes/java/lang/LazyConstant.java line 154:

> 152:  *
> 153:  * <h2 id="performance">Performance</h2>
> 154:  * The contents of lazy constant can never change after it has been initialized. Therefore,

Suggestion:

 * The contents of a lazy constant can never change after it has been initialized. Therefore,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440185045

From dfuchs at openjdk.org  Fri Oct 17 14:20:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 17 Oct 2025 14:20:07 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: <GdQJR_L3OVYAJ0cOC_X5r0oG1s8R93GRhyuCuWGKhl0=.b24ee90c-024f-49d7-a352-8600eb7da9fd@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <GdQJR_L3OVYAJ0cOC_X5r0oG1s8R93GRhyuCuWGKhl0=.b24ee90c-024f-49d7-a352-8600eb7da9fd@github.com>
Message-ID: <-MxJhdamHj4NGqunHTNpIhyrbFSHx3wzuxL_EhH8ErM=.48bc2423-5517-47b1-b1ec-a51e13ab5fd0@github.com>

On Wed, 15 Oct 2025 17:34:55 GMT, Weibing Xiao <wxiao at openjdk.org> wrote:

>> [webrev.zip](https://github.com/user-attachments/files/22605072/webrev.zip)
>> NPE thrown from SASL GSSAPI impl when TLS is used with QOP auth-int against Active Directory.
>> 
>> When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message, and tried to send the abandoned info to the client at line  https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java#L140. That's the reason to throw NPE.
>> 
>> The change is going to close socket and output stream in LdapClient.java. It would allow SASL client code to send the abandoned request to client; then dispose GSS context. This will avoid NPE to thrown at line 140 of GssKrb5Base.java.
>> 
>> No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached the updated webrev for the reference.
>
> Weibing Xiao has updated the pull request 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 26 additional commits since the last revision:
> 
>  - update the code
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8362268
>  - Merge branch 'master' into JDK-8362268
>  - Merge branch 'master' of github.com:weibxiao/jdk
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - Merge branch 'master' of github.com:openjdk/jdk
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/614738ee...4dd20668

I am not quite sure I understand how this fix works. If all tests are passing then it may be OK. I hope it isn't going to re-introduce a resource leak though. Synchronization/locking must be fixed however, and I have suggseted some changes below that will ensure it integrates correctly with the locking strategy in the Connection class.

It would be good to get @AlekseiEfimov review.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 464:

> 462:                     // Not being pooled; continue with closing
> 463:                     conn.cleanup(reqCtls, false);
> 464:                     closeOpenedResource();

Please replace these two lines with:

`conn.cleanupAndClose(reqCtls);`

Then add a method in Connection:


    void cleanupAndClose(Control[] reqCtls) {
        lock.lock();
        try {

            cleanup(reqCtls, false);

            // 8313657 socket is not closed until GC is run
            // it caused the bug 8362268, hence moved here

            if (outStream != null) {
                outStream.close();
            }

            if (!sock.isClosed()) {
                sock.close();
            }
        } catch (IOException ignored) {
            // we're closing, ignore IO.
        } finally {
            lock.unlock();
        }
    }

src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 497:

> 495:         } catch (IOException ioEx) {
> 496:             //ignore the error;
> 497:         }

Please revert this change. Use conn.cleanupAnadClose(...) instead.

src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java line 512:

> 510:         }
> 511:         conn.cleanup(null, false);
> 512:         closeOpenedResource();

same here. replace these two lines with:

`conn.cleanupAndClose(null);`

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26566#pullrequestreview-3350556027
PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2440169793
PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2440180557
PR Review Comment: https://git.openjdk.org/jdk/pull/26566#discussion_r2440177815

From mcimadamore at openjdk.org  Fri Oct 17 14:30:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Oct 2025 14:30:06 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v16]
In-Reply-To: <ozjeuDLJZqL9_hkN8EXq0Yrq8i7iXnYcgp0zzu-N2hc=.6cf84441-438b-4f11-a135-fc3522a229b7@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <j-PnauaTb4hTx3aM7nhcSITeqkosHn5kOZtOLaHOLfY=.7d5b07ad-e633-498b-b910-aa9d90a8f44f@github.com>
 <ozjeuDLJZqL9_hkN8EXq0Yrq8i7iXnYcgp0zzu-N2hc=.6cf84441-438b-4f11-a135-fc3522a229b7@github.com>
Message-ID: <WEay5PEu7rQ9WQvs2_RUJ6CaOpTiPgOX4Eo37Nnzl4g=.a4e1fbbf-f41f-4414-a382-b5d95ebb0f66@github.com>

On Fri, 17 Oct 2025 14:23:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update docs after comments
>
> src/java.base/share/classes/java/util/List.java line 1235:
> 
>> 1233:      * or more lazy elements. The returned list's {@linkplain Object#toString() toString()}
>> 1234:      * method never triggers initialization of elements. Instead, an
>> 1235:      * implementation-dependant string is returned for uninitialized elements.
> 
> Suggestion:
> 
>      * implementation-dependent string is returned for uninitialized elements.

Design comment: I note some internal discomfort at the fact that equals/hashCode trigger initialization, but toString does not... effectively this would make replacing a regular immutable list with a lazy list not possible in all cases. Not saying we should do anything now -- but something to monitor

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440214527

From mcimadamore at openjdk.org  Fri Oct 17 14:30:05 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Oct 2025 14:30:05 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v16]
In-Reply-To: <j-PnauaTb4hTx3aM7nhcSITeqkosHn5kOZtOLaHOLfY=.7d5b07ad-e633-498b-b910-aa9d90a8f44f@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <j-PnauaTb4hTx3aM7nhcSITeqkosHn5kOZtOLaHOLfY=.7d5b07ad-e633-498b-b910-aa9d90a8f44f@github.com>
Message-ID: <ozjeuDLJZqL9_hkN8EXq0Yrq8i7iXnYcgp0zzu-N2hc=.6cf84441-438b-4f11-a135-fc3522a229b7@github.com>

On Fri, 17 Oct 2025 13:13:45 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update docs after comments

src/java.base/share/classes/java/lang/LazyConstant.java line 157:

> 155:  * a JVM implementation may, for an initialized lazy constant, elide all future reads of
> 156:  * that lazy constant's contents and instead use the contents that has been previously
> 157:  * observed. We call this optimization <em>constant folding</em>. This is only possible

This is still not ok.

First, there seems to be some typo ("if the reference to the lazy constant in a static final field or...").

Secondly, trusted chain _to_ such field. I think it's the other way around, the trusted chain starts at a static final field, and then eventually gets to the lazy constant, possibly traversing one or more trusted fields.

src/java.base/share/classes/java/lang/LazyConstant.java line 174:

> 172:  *          the lazy constant itself is collected (if ever).
> 173:  *          <p>
> 174:  *          A lazy constant whose contents is an array will not optimize access to

"While it's possible to store an array inside a lazy constant, doing so will not result in improved access to the array elements. Instead ..."

src/java.base/share/classes/java/lang/LazyConstant.java line 289:

> 287:      *
> 288:      * @param computingFunction in the form of a {@linkplain Supplier} to be used
> 289:      *                          to compute the constant

s/compute/initialize (e.g. the term "compute the constant" is not defined anywhere)

src/java.base/share/classes/java/util/List.java line 1235:

> 1233:      * or more lazy elements. The returned list's {@linkplain Object#toString() toString()}
> 1234:      * method never triggers initialization of elements. Instead, an
> 1235:      * implementation-dependant string is returned for uninitialized elements.

Suggestion:

     * implementation-dependent string is returned for uninitialized elements.

src/java.base/share/classes/java/util/Map.java line 1788:

> 1786:      * or more lazy values. The returned maps's {@linkplain Object#toString() toString()}
> 1787:      * method never triggers initialization of values. Instead, an
> 1788:      * implementation-dependant string is returned for uninitialized values.

Suggestion:

     * implementation-dependent string is returned for uninitialized values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440193622
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440203445
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440207743
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440209019
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2440216157

From pminborg at openjdk.org  Fri Oct 17 14:29:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Oct 2025 14:29:55 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v18]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <YyGmHxACh7zwY-kH6mg2--bXWmUrQcxpHwd4jrWesWs=.291a50d4-fda4-4bd4-9266-66fe947e4fae@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

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

 - Merge branch 'master' into lazy-constants
 - Revert the AbstractMap.keySet @Stable annotation
 - Update docs after comments
 - Improve method docs
 - Improve equals/hashCode document
 - Update wording on List/Map Object methods
 - Update javadocs
 - Fix test descriptions
 - Update first javadoc sentence
 - Rephrase docs on interrupt
 - ... and 94 more: https://git.openjdk.org/jdk/compare/e2f6db0f...fc064e47

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/698b4125..fc064e47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=16-17

  Stats: 8176 lines in 211 files changed: 4888 ins; 2457 del; 831 mod
  Patch: https://git.openjdk.org/jdk/pull/27605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27605/head:pull/27605

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

From abarashev at openjdk.org  Fri Oct 17 14:37:07 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 17 Oct 2025 14:37:07 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v3]
In-Reply-To: <A9Qbdo4O8VY6vQ1Mc_-ntRhemzpu_bJniyewE66aCGc=.4dd0a727-0de4-4c1c-aa9e-4b2aaa7a3e76@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <FvINaMPW-pEjnc2nZo0mzRGanTBAODtzh7nNdvjvLSM=.aef859c4-dbc7-4730-a3a6-6b0e2d7ee9c6@github.com>
 <oBf0m7GFYWDIpktb3oho9gpnZ9w410MAP20D_GVLzuE=.21bca5c1-65e7-4ad7-8bcc-cfd0125e9ac8@github.com>
 <A9Qbdo4O8VY6vQ1Mc_-ntRhemzpu_bJniyewE66aCGc=.4dd0a727-0de4-4c1c-aa9e-4b2aaa7a3e76@github.com>
Message-ID: <LAOrb6HqnrTlCAFrEom_Ct8MMzayb9qGx3je4wjVJiQ=.a41e5765-55a8-464c-b94a-e1516c4d5575@github.com>

On Fri, 17 Oct 2025 12:13:23 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Also, `KeyMgr:` string can be removed, the logger will prepend the message with the full class name and line number.
>
> I agree with logging this as warning. However I think keeping `KeyMgr:` would be better, as this format is used in the existing code in the class. What do you think?

Oh, I see. Let's remove the `KeyMgr: ` prefix throughout the whole file, it was left here from the initial version of this file when logging was done by a simple debug logger. So such prefix was useful then, but not now. Also let's make the log message more informative: `"Exception thrown while getting an alias " + alias + ": " + e`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2440241654

From pminborg at openjdk.org  Fri Oct 17 14:58:44 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Oct 2025 14:58:44 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v19]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <v3sG56zWR11ZcqRFPXrHCQejTYT2AEe2dtCGwvQ2ct4=.568aec50-75c3-4b5b-becf-ff11f56806ef@github.com>

> Implement JEP 526: Lazy Constants (Second Preview)
> 
> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
> 
> The old benchmarks are not moved/renamed to allow comparison with previous releases.
> 
> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update after doc comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/fc064e47..6721ca4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=17-18

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

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

From mullan at openjdk.org  Fri Oct 17 15:12:18 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 17 Oct 2025 15:12:18 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <BCTwdA_w1wHlLb7BHjxisDC11xNm_m2Od_VIyIBAQi0=.ee3e654a-fd21-46f9-8755-7af41eca4d7a@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <Q6mc75rp9Fz66tDaLBWXYPAA1R_64nQ-oCp21uhgTvY=.155ff35c-7b7b-4d67-af8f-892c25fb88fe@github.com>
 <M4ZBrtG-QdsCAsmPecRmsTU6arjbkrKxT5NuK_TXuhY=.9d66b840-5be9-4a80-976d-de9fe6fff79b@github.com>
 <YawNmD3JifD542wr8AD3cfxrKIQIyY8kTfnd1nPHEp8=.84d4439d-d877-4447-a3cd-997a972cbfd7@github.com>
 <WAOEpZsoOiwe0F_VfvYwhpUIO5wH308WYIxNBx0SHVE=.8a340cbc-6dcb-46da-b593-0b68d0126714@github.com>
 <BCTwdA_w1wHlLb7BHjxisDC11xNm_m2Od_VIyIBAQi0=.ee3e654a-fd21-46f9-8755-7af41eca4d7a@github.com>
Message-ID: <NYg2_7oI19jE5o-sVVInnOKmIsicf-ve994Ashk58pg=.ada873de-d26b-4a89-b8fb-6b65b0130286@github.com>

On Tue, 14 Oct 2025 22:57:32 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Ok, but is it really common? All the others are listed in RFC 7468 but not this one.
>
> Yes, it is the PKCS#1 standard.  RSA PRIVATE KEY was an OpenSSL standard for a long time and only recently changed to PRIVATE KEY.   MacOS (15.7.1), which is LibreSSL, still uses RSA PRIVATE KEY by default.   It's probably used more often than half of the above list.

I still think since it was never part of an official RFC or standard that we can point to, it should not be in the main part of the javadoc, but in the implementation note, which gives us more flexibility if we ever want to phase out support for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2440338434

From myankelevich at openjdk.org  Fri Oct 17 15:57:07 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 15:57:07 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v4]
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <KXVIxCkTlwRYP5lT2eXEam2pQaMEVD4omIAq0jfrxSg=.717d5f42-8b6a-45d8-99f3-2a4727872504@github.com>

> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
> 
> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
> 
> Additionally, dot checking logic has been changed, so no cases similar to `.A` will not trigger StringOutOfBounds exceptions. 
> 
> Thank you @djelinski for finding the issue and analysis.

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

  preventing double run of tests that don't need it; Changed messages and made the error message a warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27851/files
  - new: https://git.openjdk.org/jdk/pull/27851/files/98e84b22..55652191

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

  Stats: 25 lines in 2 files changed: 15 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27851/head:pull/27851

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

From myankelevich at openjdk.org  Fri Oct 17 15:57:08 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 15:57:08 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v4]
In-Reply-To: <LAOrb6HqnrTlCAFrEom_Ct8MMzayb9qGx3je4wjVJiQ=.a41e5765-55a8-464c-b94a-e1516c4d5575@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <FvINaMPW-pEjnc2nZo0mzRGanTBAODtzh7nNdvjvLSM=.aef859c4-dbc7-4730-a3a6-6b0e2d7ee9c6@github.com>
 <oBf0m7GFYWDIpktb3oho9gpnZ9w410MAP20D_GVLzuE=.21bca5c1-65e7-4ad7-8bcc-cfd0125e9ac8@github.com>
 <A9Qbdo4O8VY6vQ1Mc_-ntRhemzpu_bJniyewE66aCGc=.4dd0a727-0de4-4c1c-aa9e-4b2aaa7a3e76@github.com>
 <LAOrb6HqnrTlCAFrEom_Ct8MMzayb9qGx3je4wjVJiQ=.a41e5765-55a8-464c-b94a-e1516c4d5575@github.com>
Message-ID: <YtpXLak-Zoo2Ixk7G8Hu3bWLjMiGu6GEQIPcg-pbp6g=.a37a0a7e-c611-4e0c-9f90-fcbc84d25c91@github.com>

On Fri, 17 Oct 2025 14:34:57 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> I agree with logging this as warning. However I think keeping `KeyMgr:` would be better, as this format is used in the existing code in the class. What do you think?
>
> Oh, I see. Let's remove the `KeyMgr: ` prefix throughout the whole file, it was left here from the initial version of this file when logging was done by a simple debug logger. So such prefix was useful then, but not now. Also let's make the log message more informative: `"Exception thrown while getting an alias " + alias + ": " + e`

Ok, thanks. Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2440454817

From abarashev at openjdk.org  Fri Oct 17 16:23:09 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 17 Oct 2025 16:23:09 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v4]
In-Reply-To: <KXVIxCkTlwRYP5lT2eXEam2pQaMEVD4omIAq0jfrxSg=.717d5f42-8b6a-45d8-99f3-2a4727872504@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <KXVIxCkTlwRYP5lT2eXEam2pQaMEVD4omIAq0jfrxSg=.717d5f42-8b6a-45d8-99f3-2a4727872504@github.com>
Message-ID: <_PurnkrCTTbNIZ0abx8mY3hXvgxM4E4X3Ppafyi8Wms=.9b3b84bc-5359-4e3a-8133-2410d3f42792@github.com>

On Fri, 17 Oct 2025 15:57:07 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
>> 
>> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
>> 
>> Additionally, dot checking logic has been changed, so no cases similar to `.A` will not trigger StringOutOfBounds exceptions. 
>> 
>> Thank you @djelinski for finding the issue and analysis.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   preventing double run of tests that don't need it; Changed messages and made the error message a warning

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 226:

> 224:         int firstDot = alias.indexOf('.');
> 225:         int secondDot = alias.indexOf('.', firstDot + 1);
> 226:         if ((firstDot == -1) || (secondDot == -1)) {

The following code looks correct to me to check for a proper alias format and to avoid Out of Bounds exception. Please add a test case for that:

        // parse the alias
        int firstDot = alias.indexOf('.');
        int secondDot = -1;

        if (firstDot > 0 && alias.length() - firstDot > 3) {
            secondDot = alias.indexOf('.', firstDot + 1);
        }

        if (secondDot - firstDot < 2 || alias.length() - secondDot < 2) {
            if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
                SSLLogger.warning("Invalid alias format: " + alias);
            }
            return null;
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2440527221

From myankelevich at openjdk.org  Fri Oct 17 17:03:35 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 17:03:35 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v5]
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <683oAeUWN54IRsCukMod9Ytb8dyV7o2LMi9UXSJr5a4=.29493812-1a6d-47c8-8f38-78bf1f5c2e3b@github.com>

> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
> 
> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
> 
> Additionally, dot checking logic has been changed, so no cases similar to `.A` will not trigger StringOutOfBounds exceptions. 
> 
> Thank you @djelinski for finding the issue and analysis.

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

  Artur's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27851/files
  - new: https://git.openjdk.org/jdk/pull/27851/files/55652191..a44f2b8f

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

  Stats: 36 lines in 2 files changed: 26 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27851/head:pull/27851

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

From myankelevich at openjdk.org  Fri Oct 17 17:03:38 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 17:03:38 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v4]
In-Reply-To: <_PurnkrCTTbNIZ0abx8mY3hXvgxM4E4X3Ppafyi8Wms=.9b3b84bc-5359-4e3a-8133-2410d3f42792@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <KXVIxCkTlwRYP5lT2eXEam2pQaMEVD4omIAq0jfrxSg=.717d5f42-8b6a-45d8-99f3-2a4727872504@github.com>
 <_PurnkrCTTbNIZ0abx8mY3hXvgxM4E4X3Ppafyi8Wms=.9b3b84bc-5359-4e3a-8133-2410d3f42792@github.com>
Message-ID: <uTxL-BU8jOZku_tpgO5xVOIfAKV6d2-0yRWDDM9KNVs=.5bef5142-9840-408a-bb27-54d769c0b944@github.com>

On Fri, 17 Oct 2025 16:20:27 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   preventing double run of tests that don't need it; Changed messages and made the error message a warning
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 226:
> 
>> 224:         int firstDot = alias.indexOf('.');
>> 225:         int secondDot = alias.indexOf('.', firstDot + 1);
>> 226:         if ((firstDot == -1) || (secondDot == -1)) {
> 
> The following code looks correct to me to check for a proper alias format and to avoid Out of Bounds exception. Please add a test case for that:
> 
>         // parse the alias
>         int firstDot = alias.indexOf('.');
>         int secondDot = -1;
> 
>         if (firstDot > 0 && alias.length() - firstDot > 3) {
>             secondDot = alias.indexOf('.', firstDot + 1);
>         }
> 
>         if (secondDot - firstDot < 2 || alias.length() - secondDot < 2) {
>             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>                 SSLLogger.warning("Invalid alias format: " + alias);
>             }
>             return null;
>         }

Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2440619297

From duke at openjdk.org  Fri Oct 17 17:22:06 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 17:22:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: <j3iXi_pwWF6jLiOwx66HI49j_9-0Pvniu-RcxpVUczc=.4a49e952-ec3a-4995-a4c3-43f15978f9a0@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <bSpdp7-d6oB_azxWIu-KYH-7yRy8xTIYqS0aPz-oUsw=.8fed6422-10fd-4112-8be3-73778f7d3d23@github.com>
 <j3iXi_pwWF6jLiOwx66HI49j_9-0Pvniu-RcxpVUczc=.4a49e952-ec3a-4995-a4c3-43f15978f9a0@github.com>
Message-ID: <tOAQr4K9Q0-4neNivQbqMCd0PYrjQ1j8u0I1tFxzLTQ=.116a124c-347f-4bc8-892b-3d63ac985fc2@github.com>

On Fri, 17 Oct 2025 12:59:42 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> test/micro/org/openjdk/bench/javax/crypto/AESDecrypt.java line 44:
> 
>> 42: 
>> 43:     @Param("10000000")
>> 44:     private int count;
> 
> Drive-by comment / question:
> Did you do all benchmarking with this single (quite large) size? How are the results for much smaller sizes? It may be worth it to just get a nice plot that goes over a range of sizes, to see if it behaves as expected.

The benchmarks listed in the PR description execute tests for data sizes ranging from 16 to 10_000_000 bytes for decryption and encryption.  The difference in performance between the old and new code were within SE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2440660231

From abarashev at openjdk.org  Fri Oct 17 17:52:05 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 17 Oct 2025 17:52:05 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v5]
In-Reply-To: <683oAeUWN54IRsCukMod9Ytb8dyV7o2LMi9UXSJr5a4=.29493812-1a6d-47c8-8f38-78bf1f5c2e3b@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <683oAeUWN54IRsCukMod9Ytb8dyV7o2LMi9UXSJr5a4=.29493812-1a6d-47c8-8f38-78bf1f5c2e3b@github.com>
Message-ID: <w2qE7orZpvwa-lXTDfLGUP9kR5xoUmM8YId7TES3b_8=.a6811159-5ec9-42d7-93ed-f9c71fe7fe97@github.com>

On Fri, 17 Oct 2025 17:03:35 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
>> 
>> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
>> 
>> Additionally, dot checking logic has been changed, so no cases similar to `.A` will not trigger StringOutOfBounds exceptions. 
>> 
>> Thank you @djelinski for finding the issue and analysis.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Artur's comments

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 234:

> 232:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 233:                 SSLLogger.warning("Invalid alias format: " + alias);
> 234:             }

Since the 2nd `indexOf` method actually doesn't throw Out Of Bounds exception if the 2nd argument is larger than the string's length (it returns `-1` instead), we can simplify this code:

        int firstDot = alias.indexOf('.');
        int secondDot = alias.indexOf('.', firstDot + 1);

        if (firstDot < 1 || secondDot - firstDot < 2
                || alias.length() - secondDot < 2) {
            if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
                SSLLogger.warning("Invalid alias format: " + alias);
            }
            return null;
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2440738514

From mcimadamore at openjdk.org  Fri Oct 17 19:58:08 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Oct 2025 19:58:08 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v19]
In-Reply-To: <v3sG56zWR11ZcqRFPXrHCQejTYT2AEe2dtCGwvQ2ct4=.568aec50-75c3-4b5b-becf-ff11f56806ef@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <v3sG56zWR11ZcqRFPXrHCQejTYT2AEe2dtCGwvQ2ct4=.568aec50-75c3-4b5b-becf-ff11f56806ef@github.com>
Message-ID: <2Ow8e38mfpHtFTbD5kUe4BKOaWACguUWAfKwerScgMg=.228371ce-d23d-4dc2-816c-ce80c7da7771@github.com>

On Fri, 17 Oct 2025 14:58:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 526: Lazy Constants (Second Preview)
>> 
>> The lazy list/map implementations are broken out from `ImmutableCollections` to a separate class.
>> 
>> The old benchmarks are not moved/renamed to allow comparison with previous releases.
>> 
>> `java.util.Optional` is updated so that its field is annotated with `@Stable`.  This is to allow `Optional` instances to be held in lazy constants and still provide constant folding.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after doc comments

src/java.base/share/classes/java/lang/LazyConstant.java line 161:

> 159:  * to a lazy constant or if there is a chain from a {@code static final} field -- via one
> 160:  * or more <em>trusted fields</em> (i.e., {@code static final} fields,
> 161:  * {@linkplain Record record} fields, lazy constants, lazy lists, lazy maps,

lazy constants and lazy lists/maps are not themselves "trusted final fields" (at least not yet), so not sure they belong here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2441086058

From duke at openjdk.org  Fri Oct 17 20:07:05 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 20:07:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/2ce35b97..1102c609

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

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

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

From duke at openjdk.org  Fri Oct 17 20:07:06 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 20:07:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
Message-ID: <fQw14Ou_q9Cy-r1MOaGdV3sOjMC9eJUr87DAKStG9ow=.cd297de3-dabf-4ece-8061-469ab6cd75bc@github.com>

On Fri, 17 Oct 2025 06:52:44 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911:
>> 
>>> 909:             }
>>> 910:             sessionK[0] = genRoundKeys(key, rounds);
>>> 911:             sessionK[1] = invGenRoundKeys();
>> 
>> Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g.
>> 
>>  private static int[][] genRoundKeys(byte[] key, int rounds) {
>>         int[][] ks = new int[2][]; // key schedule
>> 
>>         int wLen = (rounds + 1) * WB;
>>         int nk = key.length / WB;
>> 
>>         // generate the round keys for encryption
>>         int[] w = new int[wLen];
>>         for (int i = 0, j = 0; i < nk; i++, j+=4) {
>>             w[i] = ((key[j] & 0xFF) << 24)
>>                     | ((key[j + 1] & 0xFF) << 16)
>>                     | ((key[j + 2] & 0xFF) << 8)
>>                     | (key[j + 3] & 0xFF);
>>         }
>>         for (int i = nk; i < wLen; i++) {
>>             int tmp = w[i - 1];
>>             if (i % nk == 0) {
>>                 int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24);
>>                 tmp = subWord(rW) ^ RCON[(i / nk) - 1];
>>             } else if ((nk > 6) && ((i % nk) == WB)) {
>>                 tmp = subWord(tmp);
>>             }
>>             w[i] = w[i - nk] ^ tmp;
>>         }
>>         ks[0] = w;
>> 
>>         // generate the decryption round keys based on encryption ones
>>         int[] dw = new int[wLen];
>>         int[] temp = new int[WB];
>> 
>>         // Intrinsics requires the inverse key expansion to be reverse order
>>         // except for the first and last round key as the first two round keys
>>         // are without a mix column transform.
>>         for (int i = 1; i < rounds; i++) {
>>             System.arraycopy(w, i * WB, temp, 0, WB);
>>             invMixRKey(temp);
>>             System.arraycopy(temp, 0, dw, wLen - (i * WB), WB);
>>         }
>>         // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)]
>>         System.arraycopy(w, 0, dw, 0, WB);
>>         System.arraycopy(w, wLen - WB, dw, WB, WB);
>>         ks[1] = dw;
>>         Arrays.fill(temp, 0);
>> 
>>         return ks;
>>     }
>
> These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse.  The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed.

I did make changes based on your code to eliminate len and updates to variable names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441096947

From valeriep at openjdk.org  Fri Oct 17 20:21:02 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 20:21:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <fQw14Ou_q9Cy-r1MOaGdV3sOjMC9eJUr87DAKStG9ow=.cd297de3-dabf-4ece-8061-469ab6cd75bc@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <dC69TZf8IXsj9a57XXAZLeVWylFvJcNxdcwbudwKJms=.56710058-fc3a-49d0-9e12-597d0c40bd1c@github.com>
 <2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com>
 <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>
 <fQw14Ou_q9Cy-r1MOaGdV3sOjMC9eJUr87DAKStG9ow=.cd297de3-dabf-4ece-8061-469ab6cd75bc@github.com>
Message-ID: <pEwq7YYOrOAjUcU-TfiysuljGQuX8hj3gjyyWCJqLA0=.4a832c1f-6956-4ec8-9f50-8684b6629e69@github.com>

On Fri, 17 Oct 2025 20:01:21 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse.  The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed.
>
> I did make changes based on your code to eliminate len and updates to variable names.

Yes, I take a second look and maybe a smaller adjustments would work as well. E.g,
1) nit: method name `invGenRoundKeys`  -> `genInvRoundKeys`
2) make this method static by passing `sessionKey[0]` and `rounds` as arguments,
3) no need for `len` since it's always `WB`
4) for the intermediate buffer of 4 words, can we not use `w` as this name is used in both the spec and genRoundKeys method as "Word array for the key schedule". It'd help people understand the code better if we adopt the same naming convention in "Algorithm 5 Pseudocode for KEYEXPANSIONEIC()", e.g. `temp` for the intermediate buffer and `dw` for the final result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441139964

From valeriep at openjdk.org  Fri Oct 17 21:15:04 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 21:15:04 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
Message-ID: <YiNxhEwPmyVD3XbE_Ci0A9gAJKT1sXcPUoK9s5nLrTU=.45af1d49-3a5e-4b9d-a08b-cf51d9fe8098@github.com>

On Fri, 17 Oct 2025 20:07:05 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 45:

> 43: final class AES_Crypt extends SymmetricCipher {
> 44: 
> 45:     // Number of words in a block

nit: from the usage, e.g. `int nk = key.length / WB`;, it seems WB means "number of bytes in a word".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441263128

From valeriep at openjdk.org  Fri Oct 17 21:39:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 17 Oct 2025 21:39:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
Message-ID: <lvnDTYQtlU2Cog7Nh73cg9940Q6emY3n8CTnoKR7vXo=.80347c43-9992-42bc-9c27-56380c8a5726@github.com>

On Fri, 17 Oct 2025 20:07:05 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> General:
>> -----------
>> i) This work is to replace the existing AES cipher under the Cryptix license.
>> 
>> ii) The lookup tables are employed for performance, but also for operating in constant time.
>> 
>> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
>> 
>> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
>> 
>> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
>> 
>> Correctness:
>> -----------------
>> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
>> 
>> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
>> 
>> -intrinsics mode for:
>> 
>> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
>> 
>> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
>> 
>> iv) jdk_security_infra: passed, with 48 known failures
>> 
>> v) tier1 and tier2: all 110257 tests pass
>> 
>> Security:
>> -----------
>> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
>> 
>> Performance:
>> ------------------
>> All AES related benchmarks have been executed against the new and original Cryptix code:
>> 
>> micro:org.openjdk.bench.javax.crypto.AES
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
>> 
>> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
>> 
>> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
>> 
>> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption re...
>
> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates for code review comments from @valeriepeng

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 134:

> 132:     };
> 133: 
> 134:     private static final int[] T0 = {

nit: add comment for all these precomputed lookup tables and their usage.

Are these tables publicly available somewhere? I checked both spec in the class header and they don't have these included. I wonder if they are made available somewhere which corresponds with the current impl code better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441320498

From abarashev at openjdk.org  Fri Oct 17 22:03:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 17 Oct 2025 22:03:13 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v5]
In-Reply-To: <683oAeUWN54IRsCukMod9Ytb8dyV7o2LMi9UXSJr5a4=.29493812-1a6d-47c8-8f38-78bf1f5c2e3b@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <683oAeUWN54IRsCukMod9Ytb8dyV7o2LMi9UXSJr5a4=.29493812-1a6d-47c8-8f38-78bf1f5c2e3b@github.com>
Message-ID: <3oK8bHp2736ZwvLNvG1IvkG6D7BhigXoKhcfIsWHvLk=.519ab1b8-8f77-4870-9fdf-df7168c5fa91@github.com>

On Fri, 17 Oct 2025 17:03:35 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
>> 
>> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
>> 
>> Additionally, dot checking logic has been changed, so no cases similar to `.A` will not trigger StringOutOfBounds exceptions. 
>> 
>> Thank you @djelinski for finding the issue and analysis.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Artur's comments

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 260:

> 258:             // ignore and only log exception
> 259:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 260:                 SSLLogger.warning("Exception thrown while getting an alias " + alias + ": " + e);

Line length > 80

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2441360564

From duke at openjdk.org  Fri Oct 17 22:19:26 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 22:19:26 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v11]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <Eru3ph2VIaQUrfafNUbqvChxAekUYdfypR7GYv1st5o=.d9acf2a8-cad2-4e17-8df4-ec496535bdaf@github.com>

> General:
> -----------
> i) This work is to replace the existing AES cipher under the Cryptix license.
> 
> ii) The lookup tables are employed for performance, but also for operating in constant time.
> 
> iii) Several loops have been unrolled for optimization purposes, but are harder to read and don't meet coding style guidelines.
> 
> iv) None of the AES related intrinsics has been modified in this PR, but the new code has been updated to use the intrinsics related hooks for the AES block and key table arguments.
> 
> Note: I've purposefully not seen the original Cryptix code, so when making a code review comment please don't quote the code in the AESCrypt.java file.
> 
> Correctness:
> -----------------
> The following AES-specific regression tests have passed in intrinsics (default) and non-intrinsic (-Xint) modes:
> 
> i) test/jdk/com/sun/crypto/provider/Cipher/AES: all 27 tests pass
> 
> -intrinsics mode for:
> 
> ii) test/hotspot/jtreg/compiler/codegen/aes: all 4 tests pass
> 
> iii) jck:api/java_security, jck:api/javax_crypto, jck:api/javax_net, jck:api/javax_security, jck:api/org_ietf, and jck:api/javax_xml/crypto: passed, with 10 known failures
> 
> iv) jdk_security_infra: passed, with 48 known failures
> 
> v) tier1 and tier2: all 110257 tests pass
> 
> Security:
> -----------
> In order to prevent side-channel (timing and differential power analysis) attacks the code has been constructed to operate in constant time and does not use conditionals based on the key or key expansion table.  This is accomplished by using lookup tables in both the cipher and inverse cipher of AES.
> 
> Performance:
> ------------------
> All AES related benchmarks have been executed against the new and original Cryptix code:
> 
> micro:org.openjdk.bench.javax.crypto.AES
> 
> micro:org.openjdk.bench.javax.crypto.full.AESBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESExtraBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMBench
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMByteBuffer
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherOutputStream
> 
> micro:org.openjdk.bench.javax.crypto.full.AESKeyWrapBench.
> 
> micro:org.openjdk.bench.java.security.CipherSuiteBench (AES)
> 
> The benchmarks were executed in different compiler modes (default (no compiler options), -Xint, and -Xcomp) and on two different architectures (x86 and arm64) with the following encryption results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:

  Updates for code review comments from @valeriepeng

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27807/files
  - new: https://git.openjdk.org/jdk/pull/27807/files/1102c609..e0741b17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=09-10

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

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

From duke at openjdk.org  Fri Oct 17 22:19:28 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Fri, 17 Oct 2025 22:19:28 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v10]
In-Reply-To: <YiNxhEwPmyVD3XbE_Ci0A9gAJKT1sXcPUoK9s5nLrTU=.45af1d49-3a5e-4b9d-a08b-cf51d9fe8098@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <J0Zb08KZczfhjWmP_A8Qqv0T4-ogNu7BBRLWlcE3wEY=.f52c58a9-d66d-4264-933d-f453721789a2@github.com>
 <YiNxhEwPmyVD3XbE_Ci0A9gAJKT1sXcPUoK9s5nLrTU=.45af1d49-3a5e-4b9d-a08b-cf51d9fe8098@github.com>
Message-ID: <CyofiIE6O8yr1TKC7R-DQRP2qBh5XAJLS5_avs_sdeM=.ef58babb-0ec5-4d9f-a365-f8296fcd0522@github.com>

On Fri, 17 Oct 2025 21:12:21 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates for code review comments from @valeriepeng
>
> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 45:
> 
>> 43: final class AES_Crypt extends SymmetricCipher {
>> 44: 
>> 45:     // Number of words in a block
> 
> nit: from the usage, e.g. `int nk = key.length / WB`;, it seems WB means "number of bytes in a word".

I agree, it should be bytes per word for number of keys (nk) calculation, so BW?  I want to preserved words per block (WB) for maintainability (e.g., if we decide to implement Rijndael-256, where WB = 8).  Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 134:
> 
>> 132:     };
>> 133: 
>> 134:     private static final int[] T0 = {
> 
> nit: add comment for all these precomputed lookup tables and their usage.
> 
> Are these tables publicly available somewhere? I checked both spec in the class header and they don't have these included. I wonder if they are made available somewhere which corresponds with the current impl code better.

I generated the tables separately, but their usage is referenced in the original specification cited in section 5.2.1.  If made comments indicating of such.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441377285
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441377328

From iklam at openjdk.org  Fri Oct 17 22:27:35 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Oct 2025 22:27:35 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
Message-ID: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>

By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

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

Commit messages:
 - 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets

Changes: https://git.openjdk.org/jdk/pull/27880/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368199
  Stats: 38 lines in 7 files changed: 5 ins; 30 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27880.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880

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

From myankelevich at openjdk.org  Fri Oct 17 22:39:49 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 22:39:49 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>

> In [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667), there were issues with debugging due to no logging or throwing of errors by X509KeyManagerImpl::getEntry. [Line](https://github.com/openjdk/jdk/blob/6a4c2676a6378f573bd58d1bc32b57765d756291/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L243-L245)
> 
> Extra logging and error propagating should be implemented for the X509KeyManagerImpl.
> 
> Additionally, dot checking logic has been changed, so no cases similar to `.A` will not trigger StringOutOfBounds exceptions. 
> 
> Thank you @djelinski for finding the issue and analysis.

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

  Artur's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27851/files
  - new: https://git.openjdk.org/jdk/pull/27851/files/a44f2b8f..370a1538

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27851&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27851&range=04-05

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

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

From myankelevich at openjdk.org  Fri Oct 17 22:39:49 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 17 Oct 2025 22:39:49 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v5]
In-Reply-To: <3oK8bHp2736ZwvLNvG1IvkG6D7BhigXoKhcfIsWHvLk=.519ab1b8-8f77-4870-9fdf-df7168c5fa91@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <683oAeUWN54IRsCukMod9Ytb8dyV7o2LMi9UXSJr5a4=.29493812-1a6d-47c8-8f38-78bf1f5c2e3b@github.com>
 <3oK8bHp2736ZwvLNvG1IvkG6D7BhigXoKhcfIsWHvLk=.519ab1b8-8f77-4870-9fdf-df7168c5fa91@github.com>
Message-ID: <FbIavLYcY-uRDd1I-Py59Uqv_1Be5RLLyDH4Qr-1-mM=.07239d1b-31aa-43c7-90f2-f46e5dfeffb6@github.com>

On Fri, 17 Oct 2025 22:00:50 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Artur's comments
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 260:
> 
>> 258:             // ignore and only log exception
>> 259:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>> 260:                 SSLLogger.warning("Exception thrown while getting an alias " + alias + ": " + e);
> 
> Line length > 80

done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2441397174

From duke at openjdk.org  Sat Oct 18 01:07:11 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 18 Oct 2025 01:07:11 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v19]
In-Reply-To: <2Ow8e38mfpHtFTbD5kUe4BKOaWACguUWAfKwerScgMg=.228371ce-d23d-4dc2-816c-ce80c7da7771@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <v3sG56zWR11ZcqRFPXrHCQejTYT2AEe2dtCGwvQ2ct4=.568aec50-75c3-4b5b-becf-ff11f56806ef@github.com>
 <2Ow8e38mfpHtFTbD5kUe4BKOaWACguUWAfKwerScgMg=.228371ce-d23d-4dc2-816c-ce80c7da7771@github.com>
Message-ID: <7R8km2ZfztfyDcrUvjd_5P85J7pBMsxAIY-tP76jnTc=.d4311603-0098-4f89-84b3-f073bec00a4d@github.com>

On Fri, 17 Oct 2025 19:55:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after doc comments
>
> src/java.base/share/classes/java/lang/LazyConstant.java line 161:
> 
>> 159:  * to a lazy constant or if there is a chain from a {@code static final} field -- via one
>> 160:  * or more <em>trusted fields</em> (i.e., {@code static final} fields,
>> 161:  * {@linkplain Record record} fields, lazy constants, lazy lists, lazy maps,
> 
> lazy constants and lazy lists/maps are not themselves "trusted final fields" (at least not yet), so not sure they belong here?

The?`@Stable`?annotation makes?fields with?non?`null`?values into?trusted?fields when?the?class is?loaded by?a?platform class?loader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2441495949

From liach at openjdk.org  Sat Oct 18 02:51:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 18 Oct 2025 02:51:01 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
Message-ID: <MSydyJ1SxJvdZ_ZyK4pV86t-zXfAU9wAa7AUSxOYB9o=.5f069a2e-7b22-4919-9056-29c92e2611ba@github.com>

On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 69:

> 67: public class SharedSecrets {
> 68:     // This field is not necessarily stable
> 69:     private static JavaAWTFontAccess javaAWTFontAccess;

Does aot initialization work with this field?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2441536894

From iklam at openjdk.org  Sat Oct 18 04:06:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 18 Oct 2025 04:06:00 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: <MSydyJ1SxJvdZ_ZyK4pV86t-zXfAU9wAa7AUSxOYB9o=.5f069a2e-7b22-4919-9056-29c92e2611ba@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <MSydyJ1SxJvdZ_ZyK4pV86t-zXfAU9wAa7AUSxOYB9o=.5f069a2e-7b22-4919-9056-29c92e2611ba@github.com>
Message-ID: <N3MHMIjsIytlrCXoOWG_ovVHahZbtAzm34yxhKSlMe0=.b8216f31-198a-4e61-be5d-f11e349291e6@github.com>

On Sat, 18 Oct 2025 02:48:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.
>
> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 69:
> 
>> 67: public class SharedSecrets {
>> 68:     // This field is not necessarily stable
>> 69:     private static JavaAWTFontAccess javaAWTFontAccess;
> 
> Does aot initialization work with this field?

I think this field is safe. There are two places that could set it, but they will always set it to an instance of `JavaAWTFontAccessImpl`, which is stateless.

https://github.com/openjdk/jdk/blob/eff6439e75d79c67370e79638024296e01101b48/src/java.desktop/share/classes/java/awt/font/NumericShaper.java#L148-L149

https://github.com/openjdk/jdk/blob/eff6439e75d79c67370e79638024296e01101b48/src/java.desktop/share/classes/java/awt/font/TextAttribute.java#L251-L252

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2441561760

From liach at openjdk.org  Sat Oct 18 04:18:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 18 Oct 2025 04:18:00 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
Message-ID: <oojYW-Q_h8aVzlLlKzkwtYblXvZ4sYQWYQDDRUuJadM=.5cf68102-6f94-4515-b08d-dd75a75a8c1d@github.com>

On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

Archiving the accessors should be fine.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3352526259

From myankelevich at openjdk.org  Sat Oct 18 16:54:04 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Sat, 18 Oct 2025 16:54:04 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v5]
In-Reply-To: <w2qE7orZpvwa-lXTDfLGUP9kR5xoUmM8YId7TES3b_8=.a6811159-5ec9-42d7-93ed-f9c71fe7fe97@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <683oAeUWN54IRsCukMod9Ytb8dyV7o2LMi9UXSJr5a4=.29493812-1a6d-47c8-8f38-78bf1f5c2e3b@github.com>
 <w2qE7orZpvwa-lXTDfLGUP9kR5xoUmM8YId7TES3b_8=.a6811159-5ec9-42d7-93ed-f9c71fe7fe97@github.com>
Message-ID: <nguIkLyLkcOgEUMV6B4JSky4F9nl-crqek-L6XTZMko=.dc2291a7-3f75-49fb-a575-0b51e53384aa@github.com>

On Fri, 17 Oct 2025 17:49:11 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Artur's comments
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 234:
> 
>> 232:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>> 233:                 SSLLogger.warning("Invalid alias format: " + alias);
>> 234:             }
> 
> Since the 2nd `indexOf` method actually doesn't throw Out Of Bounds exception if the 2nd argument is larger than the string's length (it returns `-1` instead), we can simplify this code:
> 
>         int firstDot = alias.indexOf('.');
>         int secondDot = alias.indexOf('.', firstDot + 1);
> 
>         if (firstDot < 1 || secondDot - firstDot < 2
>                 || alias.length() - secondDot < 2) {
>             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>                 SSLLogger.warning("Invalid alias format: " + alias);
>             }
>             return null;
>         }

Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2442497146

From duke at openjdk.org  Sat Oct 18 20:17:42 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 18 Oct 2025 20:17:42 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v6]
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <DHsu_zcLjAzFFKHam9VuWKNkm-CkCtN0sLzmnBmHS6E=.93e858b5-ed9d-483c-a7cc-4b40860c2224@github.com>

> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.

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

  8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27700/files
  - new: https://git.openjdk.org/jdk/pull/27700/files/dab47e75..67d1d598

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27700&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27700&range=04-05

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

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

From duke at openjdk.org  Sat Oct 18 20:23:41 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 18 Oct 2025 20:23:41 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v7]
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <l5t84J3PNBevaT4j-6uoIWokHK7q1fZBW-t32e2FGhY=.a0fe3f93-00f0-4ef2-8f5a-ca129db7d8c0@github.com>

> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.

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

  8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27700/files
  - new: https://git.openjdk.org/jdk/pull/27700/files/67d1d598..c4197e2a

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

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

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

From myankelevich at openjdk.org  Sat Oct 18 20:45:06 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Sat, 18 Oct 2025 20:45:06 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v7]
In-Reply-To: <l5t84J3PNBevaT4j-6uoIWokHK7q1fZBW-t32e2FGhY=.a0fe3f93-00f0-4ef2-8f5a-ca129db7d8c0@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <l5t84J3PNBevaT4j-6uoIWokHK7q1fZBW-t32e2FGhY=.a0fe3f93-00f0-4ef2-8f5a-ca129db7d8c0@github.com>
Message-ID: <V1f75WjFYXXlKpkv7Gc3ghdIe72aYzbkY8rLlgDyF4o=.9e034854-2652-4387-a5cc-527dd609cb28@github.com>

On Sat, 18 Oct 2025 20:23:41 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Looking at RFC 9879 on PBES2 and PBMAC1 in PKCS12, algorithm identifiers for HmacSHA*** (like SHA***) should always contain NULL as params. We can update the list at AlgorithmId.encode(DOS) to enforce this rule.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

Looks good, just a few questions about the test

test/jdk/sun/security/x509/AlgorithmId/AlgorithmIdEqualsHashCode.java line 32:

> 30:  */
> 31: 
> 32: import java.io.*;

Nit: as you're touching this tests, if there is another commit, could you please change all wildcard imports in the test to the explicit ones?

test/jdk/sun/security/x509/AlgorithmId/AlgorithmIdEqualsHashCode.java line 42:

> 40: public class AlgorithmIdEqualsHashCode {
> 41: 
> 42:     static boolean failed = false;

As far as I can see, this is only used as a part of the test. Could you please make it local variable if it stays at all?

test/jdk/sun/security/x509/AlgorithmId/AlgorithmIdEqualsHashCode.java line 103:

> 101:         }
> 102: 
> 103:         try {

I have 2 questions here: 

1. Wouldn't it be easier if it was fail by default and pass only if conditions are met? In case of the future changes this seems to me to be a bit clearer and easier to maintain. But i'm ok with how it is  now as well. 
2. I strongly feel you should throw an exception when this is failed, otherwise this will never indicate a fail, only log. This way it is also consistent with all the other code above. However, if you want to keep it as it is, what do you think about checking the failed status underneath and throwing an exception if it failed?

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

PR Review: https://git.openjdk.org/jdk/pull/27700#pullrequestreview-3353766572
PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2442593187
PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2442592276
PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2442590144