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

From duke at openjdk.org  Sun Oct 19 01:52:02 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sun, 19 Oct 2025 01:52:02 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v8]
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <60mYDiyd3A-ZAhzFXJygnak_1uRp2LqcneHt3EGhdW8=.b9a2c1d0-b2b6-45db-bd71-3f8ddda9d6a2@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/c4197e2a..ed3d2ac3

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

  Stats: 36 lines in 1 file changed: 11 ins; 9 del; 16 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  Sun Oct 19 02:18:43 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sun, 19 Oct 2025 02:18:43 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v12]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@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/e0741b17..5ea6933b

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

  Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 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  Sun Oct 19 02:18:44 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Sun, 19 Oct 2025 02:18:44 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <pEwq7YYOrOAjUcU-TfiysuljGQuX8hj3gjyyWCJqLA0=.4a832c1f-6956-4ec8-9f50-8684b6629e69@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>
 <pEwq7YYOrOAjUcU-TfiysuljGQuX8hj3gjyyWCJqLA0=.4a832c1f-6956-4ec8-9f50-8684b6629e69@github.com>
Message-ID: <7kU60fP_Aw4oiwfwMN48YfFwC70wVObcHQpSXqZvyC4=.5094fe4c-de7e-4a96-8000-121a9db66ae5@github.com>

On Fri, 17 Oct 2025 20:18:24 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> 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.

Sorry, missed this comment in the melee.  Re: 1) method name, agreed; 2) to static, agreed; 3) remove len, prior commit; 4) variable name alignment, agreed.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2442722654

From myankelevich at openjdk.org  Sun Oct 19 08:26:07 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Sun, 19 Oct 2025 08:26:07 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v8]
In-Reply-To: <60mYDiyd3A-ZAhzFXJygnak_1uRp2LqcneHt3EGhdW8=.b9a2c1d0-b2b6-45db-bd71-3f8ddda9d6a2@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <60mYDiyd3A-ZAhzFXJygnak_1uRp2LqcneHt3EGhdW8=.b9a2c1d0-b2b6-45db-bd71-3f8ddda9d6a2@github.com>
Message-ID: <T-UXS9wUD7Tfooju3kicHF-sid-tNL77cTvqM_ACvM4=.dde199e3-c4ec-4231-9bc2-7eb6ede09f26@github.com>

On Sun, 19 Oct 2025 01:52:02 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

Thank you for your changes. LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/27700#pullrequestreview-3354136947

From djelinski at openjdk.org  Mon Oct 20 08:14:03 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 20 Oct 2025 08:14:03 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
Message-ID: <Qu6IFrBthtEW52W1o5AyRO6gF0rPwzg8xB_YN4RnHPs=.70cc5ebe-a2d0-40e6-91c5-d19c2238a46e@github.com>

On Fri, 17 Oct 2025 22:39:49 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

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27851#pullrequestreview-3355394423

From wxiao at openjdk.org  Mon Oct 20 13:04:15 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Mon, 20 Oct 2025 13:04:15 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v6]
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: <LtAjAZ-lCL_1yfif4gJXcvWBfnT4oA4Wu9jgvqjYE3E=.950cc7d3-65a3-4647-81a0-d9314d5eaafb@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:

  add new method to handle connection cleaning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26566/files
  - new: https://git.openjdk.org/jdk/pull/26566/files/4dd20668..c69d484b

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

  Stats: 41 lines in 2 files changed: 19 ins; 20 del; 2 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 heidinga at openjdk.org  Mon Oct 20 13:56:45 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 20 Oct 2025 13:56:45 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: <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@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 65:

> 63: 
> 64: // Static fields in this class are stateless, so the values initialized in the
> 65: // AOT assembly phase can be safely cached.

Looking through the implementations of the Access classes, and I have concerns about:
`setJavaObjectInputFilterAccess` as it is implemented using a lambda:

SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);

Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well?

`Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445087494

From heidinga at openjdk.org  Mon Oct 20 13:56:46 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 20 Oct 2025 13:56:46 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
Message-ID: <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>

On Mon, 20 Oct 2025 13:51:18 GMT, Dan Heidinga <heidinga 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 65:
> 
>> 63: 
>> 64: // Static fields in this class are stateless, so the values initialized in the
>> 65: // AOT assembly phase can be safely cached.
> 
> Looking through the implementations of the Access classes, and I have concerns about:
> `setJavaObjectInputFilterAccess` as it is implemented using a lambda:
> 
> SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);
> 
> Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well?
> 
> `Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase.

There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized.

        SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray);
        SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445095385

From abarashev at openjdk.org  Mon Oct 20 14:31:32 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 20 Oct 2025 14:31:32 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
Message-ID: <wLZZX7eirdOvHjaaRGdov027ostGCw3vun0biwGGeJ8=.44807e29-76c4-4fea-a11e-8aad3b8258ec@github.com>

On Fri, 17 Oct 2025 22:39:49 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 227:

> 225:         int secondDot = alias.indexOf('.', firstDot + 1);
> 226: 
> 227:         if (firstDot < 1 ||

Nit: `||` should be first on the new line per style guide.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445192198

From abarashev at openjdk.org  Mon Oct 20 14:36:33 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 20 Oct 2025 14:36:33 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
Message-ID: <jZ4PwgczgjwbnmCCRrpGgkphdKtcq8Dk9IkaYjB41hE=.7dca4e31-11b5-417c-a7f1-56dab55593c0@github.com>

On Fri, 17 Oct 2025 22:39:49 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

test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 41:

> 39:  *
> 40:  * @run junit NullCases
> 41:  * @run junit/othervm -Djavax.net.debug=ssl:keymanager -Darg=debug NullCases

Why do we have a 2nd run with debugging on?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445205270

From abarashev at openjdk.org  Mon Oct 20 15:07:09 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 20 Oct 2025 15:07:09 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
Message-ID: <K7a-ag1E2tkJbsEEImqLrL82zUwQQPUO32KXnhTZOL4=.e87f4db8-3934-4894-8627-55372f2748f2@github.com>

On Fri, 17 Oct 2025 22:39:49 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

test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 68:

> 66: 
> 67: public class NullCases {
> 68:     private static final String KEY_MGR_EXCEPTION_MESSAGE = "Exception thrown while getting an alias";

Line length.

test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 217:

> 215: 
> 216:     @ParameterizedTest
> 217:     @ValueSource(strings = {"..1", ".9.123456789"})

Please add tests with the `.` being the last character and with `..` in the middle of the string

test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 59:

> 57:         // initialising exception throwing ks
> 58:         // cleaned up after the tests are complete
> 59:         final KeyManagerFactory exceptionThrowingKMF = KeyManagerFactory.getInstance("NewSunX509");

Line length here and throughout the rest of the file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445286498
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445289406
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445293600

From abarashev at openjdk.org  Mon Oct 20 15:10:11 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 20 Oct 2025 15:10:11 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
Message-ID: <hss60eLGvJqDke06gdKuFJwH9HDgncb-IA-Oe0JCK-w=.4e6bf8f3-13ef-4c5e-9dd0-4cbcdac961bc@github.com>

On Fri, 17 Oct 2025 22:39:49 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

test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 87:

> 85:     public static class MyCustomKSProvider extends java.security.Provider {
> 86:         public MyCustomKSProvider() {
> 87:             super("MyCustomKSProvider", 1.0, "My Custom KS Provider");

Deprecated constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445300477

From weijun at openjdk.org  Mon Oct 20 15:45:05 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Oct 2025 15:45:05 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v8]
In-Reply-To: <60mYDiyd3A-ZAhzFXJygnak_1uRp2LqcneHt3EGhdW8=.b9a2c1d0-b2b6-45db-bd71-3f8ddda9d6a2@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <60mYDiyd3A-ZAhzFXJygnak_1uRp2LqcneHt3EGhdW8=.b9a2c1d0-b2b6-45db-bd71-3f8ddda9d6a2@github.com>
Message-ID: <Q4-xx3r1AW29EHjBkyqAIwMyfnNhgu5N8R5gbHColLc=.85592b7b-83f6-4400-85f7-16707242b3c2@github.com>

On Sun, 19 Oct 2025 01:52:02 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

test/jdk/sun/security/x509/AlgorithmId/AlgorithmIdEqualsHashCode.java line 136:

> 134:                     + e);
> 135:             throw e; // Rethrow to mark test failure
> 136:         }

The whole section can be simply

// Construct an AlgorithmId with explicit DER NULL parameters
DerValue explicitNullParams = new DerValue(DerValue.tag_Null, new byte[0]);
AlgorithmId aiNullParams = new AlgorithmId(AlgorithmId.SHA256_oid,
        explicitNullParams);
// The constructor should canonicalize this to "no parameters"
Asserts.assertTrue(aiNullParams.getEncodedParams() == null);
AlgorithmId aiNormal = AlgorithmId.get("SHA-256");
Asserts.assertEquals(aiNullParams, aiNormal);
Asserts.assertEquals(aiNullParams.hashCode(), aiNormal.hashCode());

test/jdk/sun/security/x509/AlgorithmId/AlgorithmIdEqualsHashCode.java line 150:

> 148:             throw new Exception("FAILED invalid ASN.1 NULL test: unexpected exception" +
> 149:                     " type", e);
> 150:         }

I wonder if it's necessary to throw a wrapped exception here. As long as the exception has stack traces that lead you to the point of failure, that's enough. In fact, this whole section can be written as

DerValue invalidNull = new DerValue(DerValue.tag_Null, new byte[]{0x00});
Asserts.assertThrows(IOException.class,
        () -> new AlgorithmId(AlgorithmId.SHA256_oid, invalidNull));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2445391121
PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2445385142

From wetmore at openjdk.org  Mon Oct 20 16:35:06 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 20 Oct 2025 16:35:06 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
Message-ID: <3QHdBvYZy3bgufgwAWorEFmlSYMH8o-9rdnCGbMgV2w=.8959aa75-8b01-4f55-8a96-645d79cbfc60@github.com>

On Fri, 17 Oct 2025 22:39:49 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

A few initial comments.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 231:

> 229:             alias.length() - secondDot < 2) {
> 230: 
> 231:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {

`ssl,keymanager`   

We're in the process of cleaning these up.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 258:

> 256:                  IndexOutOfBoundsException e) {
> 257:             // ignore and only log exception
> 258:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {

`ssl,keymanager`

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

PR Review: https://git.openjdk.org/jdk/pull/27851#pullrequestreview-3357097856
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445485209
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445486206

From wetmore at openjdk.org  Mon Oct 20 16:35:10 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 20 Oct 2025 16:35:10 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <wLZZX7eirdOvHjaaRGdov027ostGCw3vun0biwGGeJ8=.44807e29-76c4-4fea-a11e-8aad3b8258ec@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
 <wLZZX7eirdOvHjaaRGdov027ostGCw3vun0biwGGeJ8=.44807e29-76c4-4fea-a11e-8aad3b8258ec@github.com>
Message-ID: <Hv2bHEAdaAzgdxkG5YCTVfns8CgvA5Gcj4b1QHgQlSg=.6ceb919f-2fbe-48fe-975d-1a3d5038ccbe@github.com>

On Mon, 20 Oct 2025 14:28:39 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 227:
> 
>> 225:         int secondDot = alias.indexOf('.', firstDot + 1);
>> 226: 
>> 227:         if (firstDot < 1 ||
> 
> Nit: `||` should be first on the new line per style guide.

Nit:  I prefer to (over)use commas to indicate exactly what you intended.

Artur is right on the `||`, but I am guilty of doing it your way.  :)

That said, the next lines in a conditional should be indented by 8.  

        if ((firstDot < 1) || (secondDot - firstDot < 2) ||
                (alias.length() - secondDot < 2))
            if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
                SSLLogger.warning("Invalid alias format: " + alias);
            }

> test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 41:
> 
>> 39:  *
>> 40:  * @run junit NullCases
>> 41:  * @run junit/othervm -Djavax.net.debug=ssl:keymanager -Darg=debug NullCases
> 
> Why do we have a 2nd run with debugging on?

I am in the process of disabling extra (unneeded) debug output.  It looks like there is a good reason to run with debug to check the logging output here, but is there a reason to do an initial run **without** the debugging on?

> test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 68:
> 
>> 66: 
>> 67: public class NullCases {
>> 68:     private static final String KEY_MGR_EXCEPTION_MESSAGE = "Exception thrown while getting an alias";
> 
> Line length.

I noticed several other cases here.  Please keep line lengths to <=80.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445485110
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445494979
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445498509

From iklam at openjdk.org  Mon Oct 20 16:54:03 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 20 Oct 2025 16:54:03 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
 <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>
Message-ID: <OX-wQE2nG9P-Z0-oPjLlWzZO3Sl0Wrkj8moXNPaHQug=.4efa2e49-c6b6-463d-861e-369ebad5970b@github.com>

On Mon, 20 Oct 2025 13:53:52 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 65:
>> 
>>> 63: 
>>> 64: // Static fields in this class are stateless, so the values initialized in the
>>> 65: // AOT assembly phase can be safely cached.
>> 
>> Looking through the implementations of the Access classes, and I have concerns about:
>> `setJavaObjectInputFilterAccess` as it is implemented using a lambda:
>> 
>> SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);
>> 
>> Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well?
>> 
>> `Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase.
>
> There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized.
> 
>         SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray);
>         SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString);

These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445577257

From abarashev at openjdk.org  Mon Oct 20 17:22:05 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 20 Oct 2025 17:22:05 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <3QHdBvYZy3bgufgwAWorEFmlSYMH8o-9rdnCGbMgV2w=.8959aa75-8b01-4f55-8a96-645d79cbfc60@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
 <3QHdBvYZy3bgufgwAWorEFmlSYMH8o-9rdnCGbMgV2w=.8959aa75-8b01-4f55-8a96-645d79cbfc60@github.com>
Message-ID: <4SuUU4yEJB8NKsVbCaDI3J1ji9a63QbuxkwiFcHzr1o=.34269848-f687-42dd-acbf-af99cb17ac83@github.com>

On Mon, 20 Oct 2025 16:14:33 GMT, Bradford Wetmore <wetmore 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 231:
> 
>> 229:             alias.length() - secondDot < 2) {
>> 230: 
>> 231:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 
> `ssl,keymanager`   
> 
> We're in the process of cleaning these up.

I guess we should change it throughout the file then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445641930

From heidinga at openjdk.org  Mon Oct 20 17:43:03 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 20 Oct 2025 17:43:03 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: <OX-wQE2nG9P-Z0-oPjLlWzZO3Sl0Wrkj8moXNPaHQug=.4efa2e49-c6b6-463d-861e-369ebad5970b@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
 <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>
 <OX-wQE2nG9P-Z0-oPjLlWzZO3Sl0Wrkj8moXNPaHQug=.4efa2e49-c6b6-463d-861e-369ebad5970b@github.com>
Message-ID: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>

On Mon, 20 Oct 2025 16:51:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized.
>> 
>>         SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray);
>>         SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString);
>
> These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise?

Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?

Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null?

The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445689913

From ascarpino at openjdk.org  Mon Oct 20 18:56:14 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 20 Oct 2025 18:56:14 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v6]
In-Reply-To: <F0hELe2z5SOajVaCMgvSUVLOaFNgBR0nk7oa4OQ-mcA=.6460d914-177f-43ec-80b3-b88e710f1b34@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <OYKRn5a28ztisbzsDHOr6NTbs4kiwAAxoLEYY-cvwAY=.6cf4e462-3cb1-467e-bad1-22ea048a4edb@github.com>
 <F0hELe2z5SOajVaCMgvSUVLOaFNgBR0nk7oa4OQ-mcA=.6460d914-177f-43ec-80b3-b88e710f1b34@github.com>
Message-ID: <hE6sAyB_5lt7C7SIPN6IyClX-2T59F_UgLijUCWmC9o=.03ace452-50b4-445f-99d4-0d33d617a001@github.com>

On Wed, 15 Oct 2025 15:06:48 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/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.

I've changed the methods to disallow null

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

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

From ascarpino at openjdk.org  Mon Oct 20 18:56:17 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 20 Oct 2025 18:56:17 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: <hPae-ltWOrtqj_IebTFVjDB_8UHQf9GclEOuCe1j3rE=.72f07586-39c8-4e0f-861b-234e814b4e02@github.com>

On Thu, 9 Oct 2025 05:00:45 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> 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`.

I'm changed the throws to NASE and IKE

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

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

From ascarpino at openjdk.org  Mon Oct 20 18:56:15 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 20 Oct 2025 18:56:15 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <rHFGR4pcQnwe-m9EZrfEC4t3bHf7wTvWnJQfaJRtyg0=.4dab2967-4533-4766-96f1-3878987b1680@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>
 <rHFGR4pcQnwe-m9EZrfEC4t3bHf7wTvWnJQfaJRtyg0=.4dab2967-4533-4766-96f1-3878987b1680@github.com>
Message-ID: <M99WUGoHj3vkWDqv-9jm-68BgID__FUi8CQAtOOiQRM=.f4cd743c-d89e-430c-b4d9-b60f979d4a98@github.com>

On Wed, 15 Oct 2025 15:02:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> 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.

If I remember correctly, in the preview 1 code review this was `GeneralSecurityException` and there was a comment to change it.  I'm happy to go back to GSE.

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

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

From myankelevich at openjdk.org  Mon Oct 20 19:28:05 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 20 Oct 2025 19:28:05 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <Hv2bHEAdaAzgdxkG5YCTVfns8CgvA5Gcj4b1QHgQlSg=.6ceb919f-2fbe-48fe-975d-1a3d5038ccbe@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
 <wLZZX7eirdOvHjaaRGdov027ostGCw3vun0biwGGeJ8=.44807e29-76c4-4fea-a11e-8aad3b8258ec@github.com>
 <Hv2bHEAdaAzgdxkG5YCTVfns8CgvA5Gcj4b1QHgQlSg=.6ceb919f-2fbe-48fe-975d-1a3d5038ccbe@github.com>
Message-ID: <4NgMzInTNI85mthYTXUfNQQbB5jr1wrr5t8WPQ-4sTM=.a6c001e4-d9c7-451c-bef7-18796407949b@github.com>

On Mon, 20 Oct 2025 16:18:26 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 41:
>> 
>>> 39:  *
>>> 40:  * @run junit NullCases
>>> 41:  * @run junit/othervm -Djavax.net.debug=ssl:keymanager -Darg=debug NullCases
>> 
>> Why do we have a 2nd run with debugging on?
>
> I am in the process of disabling extra (unneeded) debug output.  It looks like there is a good reason to run with debug to check the logging output here, but is there a reason to do an initial run **without** the debugging on?

I wanted to cover all potential cases with and without debug on. In case the debug ever breaks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445900410

From duke at openjdk.org  Mon Oct 20 20:11:39 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Mon, 20 Oct 2025 20:11:39 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v9]
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <N42QpORV_3rufKoWLN2006isH4PZpMdSxs2CaccIJM8=.87d369a1-1657-42dd-836a-bfd4ac66fc01@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: Updated the EqualsHashCode Test based on review comments moving from the wrapped exceptions version to the Asserts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27700/files
  - new: https://git.openjdk.org/jdk/pull/27700/files/ed3d2ac3..3718e21f

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

  Stats: 51 lines in 1 file changed: 3 ins; 36 del; 12 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  Mon Oct 20 20:21:42 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 20 Oct 2025 20:21:42 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v7]
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <4l9AGGYIeqW8AEUMiA7W-Cn7FDb-hxeZWTgYhxLG04g=.8cbea465-8160-45ec-9318-c7a33ab8f577@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:

  comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27851/files
  - new: https://git.openjdk.org/jdk/pull/27851/files/370a1538..b62fc9aa

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

  Stats: 92 lines in 3 files changed: 37 ins; 13 del; 42 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  Mon Oct 20 20:21:44 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 20 Oct 2025 20:21:44 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <Hv2bHEAdaAzgdxkG5YCTVfns8CgvA5Gcj4b1QHgQlSg=.6ceb919f-2fbe-48fe-975d-1a3d5038ccbe@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
 <wLZZX7eirdOvHjaaRGdov027ostGCw3vun0biwGGeJ8=.44807e29-76c4-4fea-a11e-8aad3b8258ec@github.com>
 <Hv2bHEAdaAzgdxkG5YCTVfns8CgvA5Gcj4b1QHgQlSg=.6ceb919f-2fbe-48fe-975d-1a3d5038ccbe@github.com>
Message-ID: <441WYlo0qa2gHgOdyjAtzoEMShmLefeKAkSQaXy0bn0=.cde826b7-09a2-4d3c-9631-ff2c81fe8c75@github.com>

On Mon, 20 Oct 2025 16:14:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 227:
>> 
>>> 225:         int secondDot = alias.indexOf('.', firstDot + 1);
>>> 226: 
>>> 227:         if (firstDot < 1 ||
>> 
>> Nit: `||` should be first on the new line per style guide.
>
> Nit:  I prefer to (over)use commas to indicate exactly what you intended.
> 
> Artur is right on the `||`, but I am guilty of doing it your way.  :)
> 
> That said, the next lines in a conditional should be indented by 8.  
> 
>         if ((firstDot < 1) || (secondDot - firstDot < 2) ||
>                 (alias.length() - secondDot < 2))
>             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>                 SSLLogger.warning("Invalid alias format: " + alias);
>             }

Done in the next commit

>> test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 68:
>> 
>>> 66: 
>>> 67: public class NullCases {
>>> 68:     private static final String KEY_MGR_EXCEPTION_MESSAGE = "Exception thrown while getting an alias";
>> 
>> Line length.
>
> I noticed several other cases here.  Please keep line lengths to <=80.

Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2446017042
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2446012829

From myankelevich at openjdk.org  Mon Oct 20 20:21:45 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 20 Oct 2025 20:21:45 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <4SuUU4yEJB8NKsVbCaDI3J1ji9a63QbuxkwiFcHzr1o=.34269848-f687-42dd-acbf-af99cb17ac83@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
 <3QHdBvYZy3bgufgwAWorEFmlSYMH8o-9rdnCGbMgV2w=.8959aa75-8b01-4f55-8a96-645d79cbfc60@github.com>
 <4SuUU4yEJB8NKsVbCaDI3J1ji9a63QbuxkwiFcHzr1o=.34269848-f687-42dd-acbf-af99cb17ac83@github.com>
Message-ID: <DflAUtGFZiU94YX5nOoQdfWSFVFPi-ATXb2F1n2CRsA=.0bc9f925-67fb-4ced-bf2e-b7daa426dfc2@github.com>

On Mon, 20 Oct 2025 17:18:58 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 231:
>> 
>>> 229:             alias.length() - secondDot < 2) {
>>> 230: 
>>> 231:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>> 
>> `ssl,keymanager`   
>> 
>> We're in the process of cleaning these up.
>
> I guess we should change it throughout the file then.

Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2446016868

From myankelevich at openjdk.org  Mon Oct 20 20:21:47 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 20 Oct 2025 20:21:47 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <3QHdBvYZy3bgufgwAWorEFmlSYMH8o-9rdnCGbMgV2w=.8959aa75-8b01-4f55-8a96-645d79cbfc60@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
 <3QHdBvYZy3bgufgwAWorEFmlSYMH8o-9rdnCGbMgV2w=.8959aa75-8b01-4f55-8a96-645d79cbfc60@github.com>
Message-ID: <7pqpKf0vgJkXMkbgwGhr50Ufz-CKSZKBhdz3pOS1Cjs=.7a9390f3-62ce-49fe-a129-6169eca79e97@github.com>

On Mon, 20 Oct 2025 16:14:56 GMT, Bradford Wetmore <wetmore 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 258:
> 
>> 256:                  IndexOutOfBoundsException e) {
>> 257:             // ignore and only log exception
>> 258:             if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 
> `ssl,keymanager`

Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2446016488

From myankelevich at openjdk.org  Mon Oct 20 20:21:49 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 20 Oct 2025 20:21:49 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v6]
In-Reply-To: <K7a-ag1E2tkJbsEEImqLrL82zUwQQPUO32KXnhTZOL4=.e87f4db8-3934-4894-8627-55372f2748f2@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
 <K7a-ag1E2tkJbsEEImqLrL82zUwQQPUO32KXnhTZOL4=.e87f4db8-3934-4894-8627-55372f2748f2@github.com>
Message-ID: <wi8hE_mZcmqmaiBkBVmqcz7iT0foFxgqCHAojaF3h7E=.749ab1c5-d6ee-4515-9d59-ba031861779c@github.com>

On Mon, 20 Oct 2025 15:02:52 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
>
> test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 217:
> 
>> 215: 
>> 216:     @ParameterizedTest
>> 217:     @ValueSource(strings = {"..1", ".9.123456789"})
> 
> Please add tests with the `.` being the last character and with `..` in the middle of the string

Done in the next commit

> test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 59:
> 
>> 57:         // initialising exception throwing ks
>> 58:         // cleaned up after the tests are complete
>> 59:         final KeyManagerFactory exceptionThrowingKMF = KeyManagerFactory.getInstance("NewSunX509");
> 
> Line length here and throughout the rest of the file.

Done in the next commit

> test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 87:
> 
>> 85:     public static class MyCustomKSProvider extends java.security.Provider {
>> 86:         public MyCustomKSProvider() {
>> 87:             super("MyCustomKSProvider", 1.0, "My Custom KS Provider");
> 
> Deprecated constructor.

Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445991824
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445991265
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2445991481

From abarashev at openjdk.org  Mon Oct 20 20:47:09 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 20 Oct 2025 20:47:09 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v7]
In-Reply-To: <4l9AGGYIeqW8AEUMiA7W-Cn7FDb-hxeZWTgYhxLG04g=.8cbea465-8160-45ec-9318-c7a33ab8f577@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <4l9AGGYIeqW8AEUMiA7W-Cn7FDb-hxeZWTgYhxLG04g=.8cbea465-8160-45ec-9318-c7a33ab8f577@github.com>
Message-ID: <Qc54H46ZvGTyMEm6ZrchXBSqSLbrDKjfmMcVzKi_P1o=.60415deb-1f7f-4521-9615-ab207cddb653@github.com>

On Mon, 20 Oct 2025 20:21:42 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:
> 
>   comments

test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 223:

> 221: 
> 222:     @ParameterizedTest
> 223:     @ValueSource(strings = {"1..",".1.", "..1", ".9.123456789"})

You still miss the test string with `..` in the middle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2446079800

From duke at openjdk.org  Mon Oct 20 20:47:48 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Mon, 20 Oct 2025 20:47:48 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v10]
In-Reply-To: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
Message-ID: <3cWnWUg_mjp4TXU536P_UzPemz5GqCs9rrVzIqGyPU8=.6598fa4e-f732-49c1-911c-d145618fb1d1@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: Added bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27700/files
  - new: https://git.openjdk.org/jdk/pull/27700/files/3718e21f..b17f69ff

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

  Stats: 1 line in 1 file changed: 0 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 weijun at openjdk.org  Mon Oct 20 20:47:49 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Oct 2025 20:47:49 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v10]
In-Reply-To: <3cWnWUg_mjp4TXU536P_UzPemz5GqCs9rrVzIqGyPU8=.6598fa4e-f732-49c1-911c-d145618fb1d1@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <3cWnWUg_mjp4TXU536P_UzPemz5GqCs9rrVzIqGyPU8=.6598fa4e-f732-49c1-911c-d145618fb1d1@github.com>
Message-ID: <qiuPUXbwqFzaV88leQYBlPmx0gsell-WNTbEUED8TY0=.62bc6397-b655-4580-8694-dc600a2d3096@github.com>

On Mon, 20 Oct 2025 20:44:32 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: Added bug id

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27700#pullrequestreview-3357869808

From weijun at openjdk.org  Mon Oct 20 20:47:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 20 Oct 2025 20:47:51 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v9]
In-Reply-To: <N42QpORV_3rufKoWLN2006isH4PZpMdSxs2CaccIJM8=.87d369a1-1657-42dd-836a-bfd4ac66fc01@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <N42QpORV_3rufKoWLN2006isH4PZpMdSxs2CaccIJM8=.87d369a1-1657-42dd-836a-bfd4ac66fc01@github.com>
Message-ID: <JF7xZZegmYvvH6WKzvXeaPwDf6yMumXZf6I0soLAaxo=.ffda1187-a7a1-4c65-8e87-875c49f758b7@github.com>

On Mon, 20 Oct 2025 20:11:39 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: Updated the EqualsHashCode Test based on review comments moving from the wrapped exceptions version to the Asserts

test/jdk/sun/security/x509/AlgorithmId/AlgorithmIdEqualsHashCode.java line 27:

> 25:  * @test
> 26:  * @author Gary Ellison
> 27:  * @bug 4170635 8258247

Please add 8367008 to `@bug`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27700#discussion_r2446072591

From ascarpino at openjdk.org  Mon Oct 20 22:19:41 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 20 Oct 2025 22:19:41 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@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:

 - fix non-pbe
 - doc updates, zeroing, fix unencrypted keypair encoding, exception mods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/3e183c5a..2e9332b9

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

  Stats: 523 lines in 9 files changed: 175 ins; 132 del; 216 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 valeriep at openjdk.org  Mon Oct 20 23:17:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 20 Oct 2025 23:17:03 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v12]
In-Reply-To: <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
Message-ID: <2uIJVPehvByBLLKXHTHvkysLZIyHXsUvviNj1mbelxE=.379ce84d-7532-4a61-a63a-f4f54791b4e7@github.com>

On Sun, 19 Oct 2025 02:18: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

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1034:

> 1032:         int ti0, ti1, ti2, ti3;
> 1033:         int a0, a1, a2, a3;
> 1034:         int w = K.length - 4;

nit: 4 could be WB?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446328176

From valeriep at openjdk.org  Mon Oct 20 23:51:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 20 Oct 2025 23:51:06 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v12]
In-Reply-To: <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
Message-ID: <f5xiBLOaW_WpinUZ3U7Ck1H-Cez7MWhv4uSkRXOKKOw=.cf641d24-07b9-4202-b056-cc20e52f20c7@github.com>

On Sun, 19 Oct 2025 02:18: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

Just have some minor questions and nit.

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 589:

> 587: 
> 588:     // Lookup table for inverse substitution transform of last round as
> 589:     // described in the international journal article referenced.

Is there a link that I can look it up also?

src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1180:

> 1178:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
> 1179:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
> 1180:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w + 3];

Is this last round processing also based on spec or some journal?

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

PR Review: https://git.openjdk.org/jdk/pull/27807#pullrequestreview-3358325489
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446391365
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446389723

From duke at openjdk.org  Tue Oct 21 00:05:31 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 21 Oct 2025 00:05:31 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v13]
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@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/5ea6933b..fdfd3892

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27807&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 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  Tue Oct 21 00:05:34 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 21 Oct 2025 00:05:34 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v12]
In-Reply-To: <f5xiBLOaW_WpinUZ3U7Ck1H-Cez7MWhv4uSkRXOKKOw=.cf641d24-07b9-4202-b056-cc20e52f20c7@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <3nnB5pkNnYqYi6OAH3u83PNmiO607_xwHXCmCeIE7gA=.371aa791-952e-4143-9012-1728dbf31ae9@github.com>
 <f5xiBLOaW_WpinUZ3U7Ck1H-Cez7MWhv4uSkRXOKKOw=.cf641d24-07b9-4202-b056-cc20e52f20c7@github.com>
Message-ID: <Eh36gbo8zuwSO_Onq_XfViiimSCKuku-A-XH-CV10sw=.a788694f-3bf3-4a5b-88cb-b356e4ae8943@github.com>

On Mon, 20 Oct 2025 23:47:51 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 589:
> 
>> 587: 
>> 588:     // Lookup table for inverse substitution transform of last round as
>> 589:     // described in the international journal article referenced.
> 
> Is there a link that I can look it up also?

Yes, it's the 3rd document cited for this class: https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1034:
> 
>> 1032:         int ti0, ti1, ti2, ti3;
>> 1033:         int a0, a1, a2, a3;
>> 1034:         int w = K.length - 4;
> 
> nit: 4 could be WB?

Yes, I think that logic is acceptable. Fixed.

> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1180:
> 
>> 1178:                 ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000
>> 1179:                 ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00
>> 1180:                 ^ T1[ti2 & 0xFF] & 0xFF ^ K[w + 3];
> 
> Is this last round processing also based on spec or some journal?

Yes, it's an optimization based on the 3rd document cited for this class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446411532
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446411617
PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446411563

From duke at openjdk.org  Tue Oct 21 00:21:05 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 21 Oct 2025 00:21:05 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v8]
In-Reply-To: <3IhmbTDiDNPdMTe_K1OZx6sC67UGjObzOXwX8Ekp7pA=.0e742e44-4dba-4680-8f24-7321f8516071@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>
 <3IhmbTDiDNPdMTe_K1OZx6sC67UGjObzOXwX8Ekp7pA=.0e742e44-4dba-4680-8f24-7321f8516071@github.com>
Message-ID: <56yK_DbZSYd0QHrNIo3kAy5wxesDss6VTTB0Ii6q_JU=.12a00665-fd8d-4e44-a169-5fec560fc0b2@github.com>

On Fri, 17 Oct 2025 07:04:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I've removed this method and inlined this logic in the invGenRoundKeys method.
>
> Sure, this works as well.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446428127

From duke at openjdk.org  Tue Oct 21 00:21:07 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Tue, 21 Oct 2025 00:21:07 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: <PDpfpmbfNV44CQjYzvy4hoOdUWDN7k5VNqKYMZT_Kz4=.410e2407-6689-4ee6-a3e7-538c52eef8bf@github.com>

On Fri, 17 Oct 2025 06:52:16 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> 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.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446428552

From epeter at openjdk.org  Tue Oct 21 05:50:02 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 21 Oct 2025 05:50:02 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v9]
In-Reply-To: <tOAQr4K9Q0-4neNivQbqMCd0PYrjQ1j8u0I1tFxzLTQ=.116a124c-347f-4bc8-892b-3d63ac985fc2@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>
 <tOAQr4K9Q0-4neNivQbqMCd0PYrjQ1j8u0I1tFxzLTQ=.116a124c-347f-4bc8-892b-3d63ac985fc2@github.com>
Message-ID: <FnsJnOqlH8GvLjpxaPYYVWnyuwExnUQvIU_DsRlTpTo=.a25060e5-2dd0-4159-84da-3fb6aa0145ba@github.com>

On Fri, 17 Oct 2025 17:19:09 GMT, Shawn M Emery <duke at openjdk.org> wrote:

>> 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.

Ok, sure. Why not list all the relevant sizes in the benchmark itself then?
But totally up to you. This was just a hint/drive-by comment, feel free to mark it as resolved :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446783134

From wxiao at openjdk.org  Tue Oct 21 13:04:50 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Tue, 21 Oct 2025 13:04:50 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v6]
In-Reply-To: <LtAjAZ-lCL_1yfif4gJXcvWBfnT4oA4Wu9jgvqjYE3E=.950cc7d3-65a3-4647-81a0-d9314d5eaafb@github.com>
References: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>
 <LtAjAZ-lCL_1yfif4gJXcvWBfnT4oA4Wu9jgvqjYE3E=.950cc7d3-65a3-4647-81a0-d9314d5eaafb@github.com>
Message-ID: <A-3ixfC4WMhz9qJDObiu1tybibqdXIlOWCtctHNSrWQ=.a0301696-b620-4f45-bfe0-34c8c2160524@github.com>

On Mon, 20 Oct 2025 13:04:15 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:
> 
>   add new method to handle connection cleaning

Updated the code accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3426517818

From mullan at openjdk.org  Tue Oct 21 15:16:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 21 Oct 2025 15:16:55 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
Message-ID: <wCRpZq2cbt6YKgRjpAbmErgaNiY23CfOtnJ7mmmjPKo=.ac7e7e9e-2b01-4fef-8439-cf2a117e78ba@github.com>

On Mon, 20 Oct 2025 22:19:41 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 two additional commits since the last revision:
> 
>  - fix non-pbe
>  - doc updates, zeroing, fix unencrypted keypair encoding, exception mods

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

> 313:         }
> 314:         byte[] result = pkcs8Key.generateEncoding().clone();
> 315:         pkcs8Key.clear();

Put this in a finally block so it gets cleared even if `generateEncoding` throws an exception. You should also clear the return value of `generateEncoding` (before you clone it). Although I don't think you need the clone, since `generateEncoding` returns a new array each time.

test/jdk/java/security/PEM/PEMData.java line 51:

> 49:         """, KeyPair.class, "SunEC");
> 50: 
> 51:     public static final Entry ecsecp256dom0 = new Entry("ecsecp256dom0",

What does dom0 mean? Can you add a comment as to what is in this PEM?

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

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

From weijun at openjdk.org  Tue Oct 21 15:35:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 21 Oct 2025 15:35:51 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <bNkdGr2oDRcndoC3PDcn3PC1hZWRuft6QNUe60l8piE=.ea3e224b-71a1-4735-b254-94b44271fcb3@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>
 <bNkdGr2oDRcndoC3PDcn3PC1hZWRuft6QNUe60l8piE=.ea3e224b-71a1-4735-b254-94b44271fcb3@github.com>
Message-ID: <NGmKWYDg9k3WjCdSZyaQYPcBVKG3G2O59EXKjWT0Zug=.4376bffd-4b50-44a7-83c2-3cd574756920@github.com>

On Wed, 1 Oct 2025 23:57:33 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> 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?

I meant you can decode a `PRIVATE KEY` or `ENCRYPTED PRIVATE KEY` into an `X509EncodedKeySpec` object if it contains a public key.

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

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

From weijun at openjdk.org  Tue Oct 21 15:35:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 21 Oct 2025 15:35:54 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <wCRpZq2cbt6YKgRjpAbmErgaNiY23CfOtnJ7mmmjPKo=.ac7e7e9e-2b01-4fef-8439-cf2a117e78ba@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
 <wCRpZq2cbt6YKgRjpAbmErgaNiY23CfOtnJ7mmmjPKo=.ac7e7e9e-2b01-4fef-8439-cf2a117e78ba@github.com>
Message-ID: <KyHAEYA31aLE29W_JXSG9ac-01Y5xYfU8_kMM3rX6Gk=.a04a361d-9953-4d52-b812-1ee1706bca15@github.com>

On Tue, 21 Oct 2025 15:08:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix non-pbe
>>  - doc updates, zeroing, fix unencrypted keypair encoding, exception mods
>
> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 315:
> 
>> 313:         }
>> 314:         byte[] result = pkcs8Key.generateEncoding().clone();
>> 315:         pkcs8Key.clear();
> 
> Put this in a finally block so it gets cleared even if `generateEncoding` throws an exception. You should also clear the return value of `generateEncoding` (before you clone it). Although I don't think you need the clone, since `generateEncoding` returns a new array each time.

Unfortunately `generateEncoding` also assigned the result to the internal field `encodedKey`.

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

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

From weijun at openjdk.org  Tue Oct 21 15:44:36 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 21 Oct 2025 15:44:36 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: <DYTPDcs-tByAMKPUX-OO199-JAFVWwMry7AA2gKmcb0=.469665ad-bc6f-4375-af2e-7b0c234868dd@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 84:

> 82:  *  <li>ENCRYPTED PRIVATE KEY : {@code PublicKey} (If configured with
> 83:  *  decryption, the encoding contains a public key, and is passed as a
> 84:  *  {@code Class} parameter)</li>

If it can be decoded into `PublicKey` then it can also be decoded into an `X509EncodedKeySpec`.

Shall we create sub-bullets or even a table to describe different outputs for the same type?

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

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

From weijun at openjdk.org  Tue Oct 21 17:24:01 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 21 Oct 2025 17:24:01 GMT
Subject: RFR: 8370082: Intermediate objects clean up in DHKEM and HKDF
Message-ID: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>

Clean up more intermediate objects created during HKDF and DHKEM operations.

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

Commit messages:
 - more clean up

Changes: https://git.openjdk.org/jdk/pull/27921/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27921&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370082
  Stats: 32 lines in 5 files changed: 25 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27921.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27921/head:pull/27921

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

From bchristi at openjdk.org  Tue Oct 21 17:38:42 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 21 Oct 2025 17:38:42 GMT
Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7
Message-ID: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>

This brings in cpu25_10 changes.

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

Commit messages:
 - 8360937: Enhance certificate handling
 - 8359454: Enhance String handling
 - 8356294: Enhance Path Factories
 - 8352637: Enhance bytecode verification

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/27922/files
  Stats: 225 lines in 15 files changed: 174 ins; 9 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/27922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27922/head:pull/27922

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

From kcr at openjdk.org  Tue Oct 21 17:41:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 17:41:46 GMT
Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7
In-Reply-To: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
References: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
Message-ID: <Hxy49RusqR0DUef_wVpRAEUWdrtv7xeHwm3pe4KboAk=.06e11611-28a7-424d-a48a-9950efbc9b9a@github.com>

On Tue, 21 Oct 2025 17:32:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu25_10 changes.

You have the wrong hash for the HEAD of the merge. It should be `e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7`, so the PR title should be:


Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7

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

PR Comment: https://git.openjdk.org/jdk/pull/27922#issuecomment-3428190818

From ascarpino at openjdk.org  Tue Oct 21 17:43:54 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 21 Oct 2025 17:43:54 GMT
Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v4]
In-Reply-To: <d3_ynxSPnUY6SaTIBAKL4xsH-f5fqq8EPVbjqj8dmVo=.2364c858-4d57-4bbf-b83c-2bbb3523cd23@github.com>
References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
 <d3_ynxSPnUY6SaTIBAKL4xsH-f5fqq8EPVbjqj8dmVo=.2364c858-4d57-4bbf-b83c-2bbb3523cd23@github.com>
Message-ID: <AvdZ7nHV3ZDtLIsuwr53dsdxQGXRMOZr3BqIY3Xt9AA=.27b17ca3-ccd0-46c1-99a2-55d5c4a785d0@github.com>

On Mon, 29 Sep 2025 10:35:53 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Tests changed in this PR: 
>> 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java
>> 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java
>> 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java
>> 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java
>> 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
>> 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
>> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java
>> 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java
>> 12. test/jdk/sun/security/rsa/InvalidBitString.java
>> 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java
>> 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java
>> 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java
>> 
>> PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326)
>
> Mikhail Yankelevich has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   removed pemrecord usage

Changes look good.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27194#pullrequestreview-3361958786

From kcr at openjdk.org  Tue Oct 21 17:52:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 17:52:43 GMT
Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7
In-Reply-To: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
References: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
Message-ID: <fyG38fgvkUuFBkAdHTKGi9V1iAeQTaPshVxuEnNttfg=.8cbe021f-7f8a-44ec-b1a1-9f42f8748456@github.com>

On Tue, 21 Oct 2025 17:32:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu25_10 changes.

Marked as reviewed by kcr (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27922#pullrequestreview-3361993121

From kcr at openjdk.org  Tue Oct 21 17:52:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Oct 2025 17:52:44 GMT
Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7
In-Reply-To: <Hxy49RusqR0DUef_wVpRAEUWdrtv7xeHwm3pe4KboAk=.06e11611-28a7-424d-a48a-9950efbc9b9a@github.com>
References: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
 <Hxy49RusqR0DUef_wVpRAEUWdrtv7xeHwm3pe4KboAk=.06e11611-28a7-424d-a48a-9950efbc9b9a@github.com>
Message-ID: <mLeT8Vs0Yto7libRK8HIrV3-zwJMljGLvtVfip9a03s=.e8692be5-639c-4af6-b9b9-5d3f35c1eefa@github.com>

On Tue, 21 Oct 2025 17:39:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> the PR title should be:
> 
> ```
> Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7
> ```

nm. it is correct (not sure what I saw earlier).

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

PR Comment: https://git.openjdk.org/jdk/pull/27922#issuecomment-3428289570

From prr at openjdk.org  Tue Oct 21 18:09:04 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Oct 2025 18:09:04 GMT
Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7
In-Reply-To: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
References: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
Message-ID: <5ENfgCBS3J-p3Y5MeFKr9iS3qeynVdYaVuCaBBqDqFA=.fea0376f-2eb3-47c4-af3b-a33e79a21456@github.com>

On Tue, 21 Oct 2025 17:32:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu25_10 changes.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27922#pullrequestreview-3362065525

From abarashev at openjdk.org  Tue Oct 21 18:14:06 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 21 Oct 2025 18:14:06 GMT
Subject: RFR: 8370082: Intermediate objects clean up in DHKEM and HKDF
In-Reply-To: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
Message-ID: <Y_iv_csV8v-zAGaHKzo8HA2fuJ7I51DHaeE0s4Q6TlU=.2dd343a5-d757-415a-b511-aef2fdee9353@github.com>

On Tue, 21 Oct 2025 17:17:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Clean up more intermediate objects created during HKDF and DHKEM operations.

LGTM

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

Marked as reviewed by abarashev (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27921#pullrequestreview-3362088066

From valeriep at openjdk.org  Tue Oct 21 18:22:20 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 21 Oct 2025 18:22:20 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v13]
In-Reply-To: <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
Message-ID: <45hkD8RQ3TH-4dvjl_bN9dG0B4BSE3d1wXZAPMxeDSA=.84597563-35d7-43c4-bd7c-cad7da7e9277@github.com>

On Tue, 21 Oct 2025 00:05:31 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

Changes look fine, thanks~

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27807#pullrequestreview-3362117409

From bchristi at openjdk.org  Tue Oct 21 18:44:07 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 21 Oct 2025 18:44:07 GMT
Subject: Integrated: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7
In-Reply-To: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
References: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
Message-ID: <sMnY1gUq4LSAhT2WM5BFlTeBzo2S4mWBLEWwjhzJmso=.3fd3723f-d313-405f-a528-9cba4bffb296@github.com>

On Tue, 21 Oct 2025 17:32:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu25_10 changes.

This pull request has now been integrated.

Changeset: b68fa435
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b68fa4354c1ba1826ec0bb8b6e0a81e2c01de6b0
Stats:     225 lines in 15 files changed: 174 ins; 9 del; 42 mod

Merge

Reviewed-by: kcr, prr

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

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

From bchristi at openjdk.org  Tue Oct 21 18:44:06 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 21 Oct 2025 18:44:06 GMT
Subject: RFR: Merge e1d1fa91cf2670b171e64ad79b88f5d1ad3e51f7 [v2]
In-Reply-To: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
References: <CRg65JvGluxK9Hr8KbG1d2qKPOuqA-WC5GAFic302D0=.d80e0117-9680-4774-a730-c5508b93549c@github.com>
Message-ID: <aBh69w-3JG75PJ19fVBFyfVVqSacymbygxHUSOUe6mI=.7d9fad4d-f0f8-4120-945b-104e490253cf@github.com>

> This brings in cpu25_10 changes.

Brent Christian 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27922/files
  - new: https://git.openjdk.org/jdk/pull/27922/files/e1d1fa91..e1d1fa91

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

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

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

From fandreuzzi at openjdk.org  Tue Oct 21 18:55:28 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 18:55:28 GMT
Subject: RFR: 8370082: Intermediate objects clean up in DHKEM and HKDF
In-Reply-To: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
Message-ID: <Zyvtrem-jaa56_Vr-4H-Pc5cP1e0r-J7KH0yPTSHueM=.b1ba5229-096c-4f25-b7bc-4fa917cc28ad@github.com>

On Tue, 21 Oct 2025 17:17:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Clean up more intermediate objects created during HKDF and DHKEM operations.

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27921#pullrequestreview-3362251835

From myankelevich at openjdk.org  Tue Oct 21 21:26:36 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 21 Oct 2025 21:26:36 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v8]
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <SKJxORRyqPbb5QVgdRdJdTskUrw4qMqirOn_CWpnOq0=.52f84912-9cc6-4c36-8b90-232dbbd40122@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:

  removed log check and renamed logs from keymanager to ssl,keymanager

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27851/files
  - new: https://git.openjdk.org/jdk/pull/27851/files/b62fc9aa..a624b17a

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

  Stats: 68 lines in 2 files changed: 5 ins; 42 del; 21 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  Tue Oct 21 21:26:38 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 21 Oct 2025 21:26:38 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v7]
In-Reply-To: <Qc54H46ZvGTyMEm6ZrchXBSqSLbrDKjfmMcVzKi_P1o=.60415deb-1f7f-4521-9615-ab207cddb653@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <4l9AGGYIeqW8AEUMiA7W-Cn7FDb-hxeZWTgYhxLG04g=.8cbea465-8160-45ec-9318-c7a33ab8f577@github.com>
 <Qc54H46ZvGTyMEm6ZrchXBSqSLbrDKjfmMcVzKi_P1o=.60415deb-1f7f-4521-9615-ab207cddb653@github.com>
Message-ID: <y3l82KUG6CfYNVXIFA8O_pvJ54nY5uGfEzY5mdPA4gI=.a64e866a-96c2-4ea4-a8bc-3845a6abb860@github.com>

On Mon, 20 Oct 2025 20:44:22 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments
>
> test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 223:
> 
>> 221: 
>> 222:     @ParameterizedTest
>> 223:     @ValueSource(strings = {"1..",".1.", "..1", ".9.123456789"})
> 
> You still miss the test string with `..` in the middle.

done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2449733548

From abarashev at openjdk.org  Tue Oct 21 22:09:06 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 21 Oct 2025 22:09:06 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v8]
In-Reply-To: <SKJxORRyqPbb5QVgdRdJdTskUrw4qMqirOn_CWpnOq0=.52f84912-9cc6-4c36-8b90-232dbbd40122@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <SKJxORRyqPbb5QVgdRdJdTskUrw4qMqirOn_CWpnOq0=.52f84912-9cc6-4c36-8b90-232dbbd40122@github.com>
Message-ID: <QSij4cp1lozE6wjDekyZyNKr5mMi5nLueCeyrzBYJhE=.7b18cd1d-bc20-41fd-a5cf-97f5de3ac300@github.com>

On Tue, 21 Oct 2025 21:26:36 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:
> 
>   removed log check and renamed logs from keymanager to ssl,keymanager

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 260:

> 258:             if (SSLLogger.isOn && SSLLogger.isOn("ssl,keymanager")) {
> 259:                 SSLLogger.warning(
> 260:                         "Exception thrown while getting an alias" +

This line can be moved up.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 301:

> 299:                             if (SSLLogger.isOn
> 300:                                     && SSLLogger
> 301:                                         .isOn("ssl,keymanager")) {

This line can be moved up

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2449820495
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2449819654

From myankelevich at openjdk.org  Tue Oct 21 22:12:54 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 21 Oct 2025 22:12:54 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v8]
In-Reply-To: <QSij4cp1lozE6wjDekyZyNKr5mMi5nLueCeyrzBYJhE=.7b18cd1d-bc20-41fd-a5cf-97f5de3ac300@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <SKJxORRyqPbb5QVgdRdJdTskUrw4qMqirOn_CWpnOq0=.52f84912-9cc6-4c36-8b90-232dbbd40122@github.com>
 <QSij4cp1lozE6wjDekyZyNKr5mMi5nLueCeyrzBYJhE=.7b18cd1d-bc20-41fd-a5cf-97f5de3ac300@github.com>
Message-ID: <W6OYtWVobQmwfuVMTCyARTtxRFwyN2SnBqtO8l3eOWE=.64591359-898c-4ebd-ad66-f05a07c3a25d@github.com>

On Tue, 21 Oct 2025 22:05:49 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed log check and renamed logs from keymanager to ssl,keymanager
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 301:
> 
>> 299:                             if (SSLLogger.isOn
>> 300:                                     && SSLLogger
>> 301:                                         .isOn("ssl,keymanager")) {
> 
> This line can be moved up

Just trying to keep the line within 80 characters. The same for the comment on line 259

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2449826598

From myankelevich at openjdk.org  Tue Oct 21 23:07:01 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 21 Oct 2025 23:07:01 GMT
Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v4]
In-Reply-To: <AvdZ7nHV3ZDtLIsuwr53dsdxQGXRMOZr3BqIY3Xt9AA=.27b17ca3-ccd0-46c1-99a2-55d5c4a785d0@github.com>
References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
 <d3_ynxSPnUY6SaTIBAKL4xsH-f5fqq8EPVbjqj8dmVo=.2364c858-4d57-4bbf-b83c-2bbb3523cd23@github.com>
 <AvdZ7nHV3ZDtLIsuwr53dsdxQGXRMOZr3BqIY3Xt9AA=.27b17ca3-ccd0-46c1-99a2-55d5c4a785d0@github.com>
Message-ID: <97d284kJzNZUlXEWtE5BsSg1d2_C6plgMmyeR_IpTUE=.dd04b115-e34e-458a-a370-edad09fb4ebf@github.com>

On Tue, 21 Oct 2025 17:40:47 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Mikhail Yankelevich has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   removed pemrecord usage
>
> Changes look good.

@ascarpino Thank you for your review!  /integrate

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

PR Comment: https://git.openjdk.org/jdk/pull/27194#issuecomment-3429870823

From liach at openjdk.org  Wed Oct 22 02:24:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Oct 2025 02:24:10 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
Message-ID: <-czbEuOCg7MyDiAr7PJ94Wrp-ycdaRFGBWOC-Z6rAK4=.e1bf40b6-d5e7-4505-959b-c32d22513532@github.com>

On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>> 
>> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update NPE per roger review

Keep alive; is this not a good minimal unit for hotspot reviewers to review? I intentionally avoided including changes to Objects.requireNonNull directly to minimize hotspot review efforts.

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

PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3430251443

From dholmes at openjdk.org  Wed Oct 22 02:42:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 02:42:08 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
Message-ID: <M-Q5y1kspwQl2U7mjsr6tRwi91F54r_owZgXWzXfFQc=.42fb1143-69c0-490a-9082-dc72e6ccea2f@github.com>

On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>> 
>> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update NPE per roger review

As I said earlier the hotspot changes seem reasonable. I find the enum usage a bit clunky but that is just me.

I will approve for hotspot side - though as hotspot requires two reviews you should wait for a second hotspot review. Thanks.

test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullCheckAPITest.java line 65:

> 63:     }
> 64: 
> 65:     static void throwNpe() {

Nit: `throwNPE`

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26600#pullrequestreview-3363495671
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2450252079

From ascarpino at openjdk.org  Wed Oct 22 04:21:02 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 22 Oct 2025 04:21:02 GMT
Subject: RFR: 8370082: Intermediate objects clean up in DHKEM and HKDF
In-Reply-To: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
Message-ID: <89v7-0le6M5cjXEn3j_uA0JgL8C_cd_Y-V984mpPmqc=.54fcf3eb-6753-4863-b55f-afcfb63ae972@github.com>

On Tue, 21 Oct 2025 17:17:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Clean up more intermediate objects created during HKDF and DHKEM operations.

Looks good.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27921#pullrequestreview-3363654985

From ascarpino at openjdk.org  Wed Oct 22 04:42:08 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 22 Oct 2025 04:42:08 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <KyHAEYA31aLE29W_JXSG9ac-01Y5xYfU8_kMM3rX6Gk=.a04a361d-9953-4d52-b812-1ee1706bca15@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
 <wCRpZq2cbt6YKgRjpAbmErgaNiY23CfOtnJ7mmmjPKo=.ac7e7e9e-2b01-4fef-8439-cf2a117e78ba@github.com>
 <KyHAEYA31aLE29W_JXSG9ac-01Y5xYfU8_kMM3rX6Gk=.a04a361d-9953-4d52-b812-1ee1706bca15@github.com>
Message-ID: <fBjrHsfqFtfneZOueWuSb7OWNM2zSP9Qn5R1w1fIDvI=.72a3a791-96a6-427e-af03-48bd2ff234f3@github.com>

On Tue, 21 Oct 2025 15:33:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 315:
>> 
>>> 313:         }
>>> 314:         byte[] result = pkcs8Key.generateEncoding().clone();
>>> 315:         pkcs8Key.clear();
>> 
>> Put this in a finally block so it gets cleared even if `generateEncoding` throws an exception. You should also clear the return value of `generateEncoding` (before you clone it). Although I don't think you need the clone, since `generateEncoding` returns a new array each time.
>
> Unfortunately `generateEncoding` also assigned the result to the internal field `encodedKey`.

@wangweij is correct, `generateEncoding()` is setting the instance variable `encodedKey`.    A finally-block is likely necessary if an exception happens after `privateKeyMaterial` is set in `generateEncoding()`

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

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

From serb at openjdk.org  Wed Oct 22 06:42:31 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 22 Oct 2025 06:42:31 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in java.security.jgss
Message-ID: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>

Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.security.jgss module to enable stricter compile-time checking of serialization-related declarations.

Example of a similar change https://github.com/openjdk/jdk/pull/24891.

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

Commit messages:
 - 8370368: Apply java.io.Serial annotations in java.security.jgss

Changes: https://git.openjdk.org/jdk/pull/27925/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27925&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370368
  Stats: 33 lines in 10 files changed: 25 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27925.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27925/head:pull/27925

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

From serb at openjdk.org  Wed Oct 22 06:42:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 22 Oct 2025 06:42:32 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in
 java.security.jgss
In-Reply-To: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
Message-ID: <P8Kit_Nkjv7HA82mstXdqlQA62ZXIrCIvVJZHIkS26o=.d5bf6a75-0d7f-405b-9735-579145a3d96e@github.com>

On Wed, 22 Oct 2025 01:10:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.security.jgss module to enable stricter compile-time checking of serialization-related declarations.
> 
> Example of a similar change https://github.com/openjdk/jdk/pull/24891.

src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 87:

> 85:         @java.io.Serial
> 86:         private static final long serialVersionUID = 0L;
> 87:         private final int errorCode;

Note that `private` will not affect the behavior of the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2450593596

From pminborg at openjdk.org  Wed Oct 22 07:51:30 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Oct 2025 07:51:30 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v19]
In-Reply-To: <7R8km2ZfztfyDcrUvjd_5P85J7pBMsxAIY-tP76jnTc=.d4311603-0098-4f89-84b3-f073bec00a4d@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>
 <7R8km2ZfztfyDcrUvjd_5P85J7pBMsxAIY-tP76jnTc=.d4311603-0098-4f89-84b3-f073bec00a4d@github.com>
Message-ID: <SZG9akO_FmxK6_FBPcAuwPB27AYW1r-37FbmjgMXWIA=.239c773e-c65e-40dd-9617-9a38c34ae1b0@github.com>

On Sat, 18 Oct 2025 01:04:37 GMT, ExE Boss <duke at openjdk.org> wrote:

>> 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.

There could be a chain: `static final` -> record component -> lazy list element -> record component, for example, and this would be a trusted chain. There are other constucts that could be in the chain as well and that are not mentioned (e.g. a `List.of()`) so perhaps we should do some change here. Easiest is to just remove the mention of lazy*.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2450745732

From myankelevich at openjdk.org  Wed Oct 22 07:54:11 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 22 Oct 2025 07:54:11 GMT
Subject: Integrated: 8365072: Refactor tests to use PEM API (Phase 2)
In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com>
Message-ID: <kjnJBZhoJfaeNR_zYlk5rkgyEQNwiePNZiSjKS5vaJo=.44309f93-1ecd-4641-b80f-5604edabad87@github.com>

On Wed, 10 Sep 2025 15:18:59 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Tests changed in this PR: 
> 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java
> 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java
> 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java
> 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java
> 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
> 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java
> 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java
> 12. test/jdk/sun/security/rsa/InvalidBitString.java
> 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java
> 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java
> 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java
> 
> PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326)

This pull request has now been integrated.

Changeset: 8d9b2fa6
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d9b2fa6af5d0f601168abbc24510a4e9eed785b
Stats:     818 lines in 14 files changed: 171 ins; 258 del; 389 mod

8365072: Refactor tests to use PEM API (Phase 2)

Reviewed-by: ascarpino

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

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

From weijun at openjdk.org  Wed Oct 22 11:46:20 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 22 Oct 2025 11:46:20 GMT
Subject: RFR: 8370082: Intermediate objects clean up in ECDH, XDH, DHKEM, 
 and HKDF [v2]
In-Reply-To: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
Message-ID: <wp3i0tNI0o_siasmF7PUQlD5oMHmmdG5p6tzcW45xmQ=.9c923d33-087a-4230-ba8b-84695f7ba9ba@github.com>

> Clean up more intermediate objects created during these operations.

Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:

 - do not store key as bytes in XDH
 - add ECDH and XDH

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27921/files
  - new: https://git.openjdk.org/jdk/pull/27921/files/e84cf5c5..cdd81505

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

  Stats: 21 lines in 2 files changed: 15 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27921.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27921/head:pull/27921

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

From mullan at openjdk.org  Wed Oct 22 12:45:21 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 22 Oct 2025 12:45:21 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <fBjrHsfqFtfneZOueWuSb7OWNM2zSP9Qn5R1w1fIDvI=.72a3a791-96a6-427e-af03-48bd2ff234f3@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
 <wCRpZq2cbt6YKgRjpAbmErgaNiY23CfOtnJ7mmmjPKo=.ac7e7e9e-2b01-4fef-8439-cf2a117e78ba@github.com>
 <KyHAEYA31aLE29W_JXSG9ac-01Y5xYfU8_kMM3rX6Gk=.a04a361d-9953-4d52-b812-1ee1706bca15@github.com>
 <fBjrHsfqFtfneZOueWuSb7OWNM2zSP9Qn5R1w1fIDvI=.72a3a791-96a6-427e-af03-48bd2ff234f3@github.com>
Message-ID: <aBn-R_E4oOG9rOcou3cpHWCzJSA6AZaaRJ6bejrbf2Q=.17f7ff61-84b0-4080-bc38-b745d0161461@github.com>

On Wed, 22 Oct 2025 04:38:53 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Unfortunately `generateEncoding` also assigned the result to the internal field `encodedKey`.
>
> @wangweij is correct, `generateEncoding()` is setting the instance variable `encodedKey`.    A finally-block is likely necessary if an exception happens after `privateKeyMaterial` is set in `generateEncoding()`

Ok, that could be fixed by creating another method that just does the encoding (and change `generateEncoding` to call that), but maybe we can fix that later.

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

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

From abarashev at openjdk.org  Wed Oct 22 13:19:02 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 22 Oct 2025 13:19:02 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v8]
In-Reply-To: <W6OYtWVobQmwfuVMTCyARTtxRFwyN2SnBqtO8l3eOWE=.64591359-898c-4ebd-ad66-f05a07c3a25d@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <SKJxORRyqPbb5QVgdRdJdTskUrw4qMqirOn_CWpnOq0=.52f84912-9cc6-4c36-8b90-232dbbd40122@github.com>
 <QSij4cp1lozE6wjDekyZyNKr5mMi5nLueCeyrzBYJhE=.7b18cd1d-bc20-41fd-a5cf-97f5de3ac300@github.com>
 <W6OYtWVobQmwfuVMTCyARTtxRFwyN2SnBqtO8l3eOWE=.64591359-898c-4ebd-ad66-f05a07c3a25d@github.com>
Message-ID: <khWybWROiD8Koev-rkD9EsbH595ZOAO7aQZAC6R87e4=.53ce9595-3145-4ad0-8eac-b2382cf9c6be@github.com>

On Tue, 21 Oct 2025 22:10:34 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 301:
>> 
>>> 299:                             if (SSLLogger.isOn
>>> 300:                                     && SSLLogger
>>> 301:                                         .isOn("ssl,keymanager")) {
>> 
>> This line can be moved up
>
> Just trying to keep the line within 80 characters. The same for the comment on line 259

It won't be more than 80 characters if you do `&& SSLLogger.isOn("ssl,keymanager")) {`. The same for other comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2452069461

From abarashev at openjdk.org  Wed Oct 22 14:05:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 22 Oct 2025 14:05:48 GMT
Subject: RFR: 8370082: Intermediate objects clean up in ECDH, XDH, DHKEM, 
 and HKDF [v2]
In-Reply-To: <wp3i0tNI0o_siasmF7PUQlD5oMHmmdG5p6tzcW45xmQ=.9c923d33-087a-4230-ba8b-84695f7ba9ba@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
 <wp3i0tNI0o_siasmF7PUQlD5oMHmmdG5p6tzcW45xmQ=.9c923d33-087a-4230-ba8b-84695f7ba9ba@github.com>
Message-ID: <s08rEPuHBv4eFtGfZnR6RvJu6tDo3UXYQKM6tkuUxGY=.27b3eeb8-c304-4a0f-b78e-f6eeff96ad1e@github.com>

On Wed, 22 Oct 2025 11:46:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Clean up more intermediate objects created during these operations.
>
> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - do not store key as bytes in XDH
>  - add ECDH and XDH

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

> 90:             } finally {
> 91:                 if (key != null) {
> 92:                     Arrays.fill(key, (byte)0);

It's not immediately obvious to the caller that the key is being cloned in `SecretKeySpec` constructor. I think a short comment explaining what we are doing would be helpful here and below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27921#discussion_r2452216944

From myankelevich at openjdk.org  Wed Oct 22 14:06:12 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 22 Oct 2025 14:06:12 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v9]
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <NC4G6B4KghscpwWOEFOmbzNp7nGRkiFr-9BLA6GKTdg=.2870d74f-683d-4ab2-8692-f7cbc3246b0e@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:

  line length changed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27851/files
  - new: https://git.openjdk.org/jdk/pull/27851/files/a624b17a..92486022

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

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 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 weijun at openjdk.org  Wed Oct 22 14:38:03 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 22 Oct 2025 14:38:03 GMT
Subject: RFR: 8370082: Intermediate objects clean up in ECDH, XDH, DHKEM, 
 and HKDF [v2]
In-Reply-To: <s08rEPuHBv4eFtGfZnR6RvJu6tDo3UXYQKM6tkuUxGY=.27b3eeb8-c304-4a0f-b78e-f6eeff96ad1e@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
 <wp3i0tNI0o_siasmF7PUQlD5oMHmmdG5p6tzcW45xmQ=.9c923d33-087a-4230-ba8b-84695f7ba9ba@github.com>
 <s08rEPuHBv4eFtGfZnR6RvJu6tDo3UXYQKM6tkuUxGY=.27b3eeb8-c304-4a0f-b78e-f6eeff96ad1e@github.com>
Message-ID: <VGpQbvhM3SnmzBiwGlfUNa6B41EdXKwI4yY71VjDxHk=.3a66a420-3185-4285-b8c7-bedecf1d14b3@github.com>

On Wed, 22 Oct 2025 14:02:32 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - do not store key as bytes in XDH
>>  - add ECDH and XDH
>
> src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java line 92:
> 
>> 90:             } finally {
>> 91:                 if (key != null) {
>> 92:                     Arrays.fill(key, (byte)0);
> 
> It's not immediately obvious to the caller that the key is being cloned in `SecretKeySpec` constructor. I think a short comment explaining what we are doing would be helpful here and below.

// `key` has been cloned into the `SecretKeySpec` within the
// returned `KEM.Encapsulated`, so it can now be cleared.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27921#discussion_r2452326250

From weijun at openjdk.org  Wed Oct 22 14:43:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 22 Oct 2025 14:43:51 GMT
Subject: RFR: 8370082: Intermediate objects clean up in ECDH, XDH, DHKEM, 
 and HKDF [v3]
In-Reply-To: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
Message-ID: <ysDfYCcFldXnGNnmwP0skVDxEhG-oApjzPdB9-qsiHg=.bc48702d-b930-4f6e-958d-7b84f1e3f703@github.com>

> Clean up more intermediate objects created during these operations.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  comment from Artur

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27921/files
  - new: https://git.openjdk.org/jdk/pull/27921/files/cdd81505..ac90b17e

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

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

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

From abarashev at openjdk.org  Wed Oct 22 14:53:02 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 22 Oct 2025 14:53:02 GMT
Subject: RFR: 8370082: Intermediate objects clean up in ECDH, XDH, DHKEM, 
 and HKDF [v3]
In-Reply-To: <ysDfYCcFldXnGNnmwP0skVDxEhG-oApjzPdB9-qsiHg=.bc48702d-b930-4f6e-958d-7b84f1e3f703@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
 <ysDfYCcFldXnGNnmwP0skVDxEhG-oApjzPdB9-qsiHg=.bc48702d-b930-4f6e-958d-7b84f1e3f703@github.com>
Message-ID: <colCeadkdadiYWhi5YY61WQf6SjZxgWAwiqjg1Q5gu4=.34ca2c41-56f8-4f02-8a9b-da594272c292@github.com>

On Wed, 22 Oct 2025 14:43:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Clean up more intermediate objects created during these operations.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment from Artur

LGTM

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

Marked as reviewed by abarashev (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27921#pullrequestreview-3366185381

From abarashev at openjdk.org  Wed Oct 22 14:56:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 22 Oct 2025 14:56:34 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v9]
In-Reply-To: <NC4G6B4KghscpwWOEFOmbzNp7nGRkiFr-9BLA6GKTdg=.2870d74f-683d-4ab2-8692-f7cbc3246b0e@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <NC4G6B4KghscpwWOEFOmbzNp7nGRkiFr-9BLA6GKTdg=.2870d74f-683d-4ab2-8692-f7cbc3246b0e@github.com>
Message-ID: <VTpMk86jtFzmbcHuaH6Quh-RuQ0qqQ_wsP4IHSL2ycY=.6bd8efad-926e-418e-adc0-583224a8e728@github.com>

On Wed, 22 Oct 2025 14:06:12 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:
> 
>   line length changed

LGTM

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

Marked as reviewed by abarashev (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27851#pullrequestreview-3366198729

From weijun at openjdk.org  Wed Oct 22 15:07:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 22 Oct 2025 15:07:06 GMT
Subject: RFR: 8370082: Intermediate objects clean up in ECDH, EdDSA, XDH, 
 DHKEM, and HKDF [v4]
In-Reply-To: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
Message-ID: <55tojvC29VibCtDSsbfB2J0uFX2epcDN6Jgs77AfzY4=.65f1665a-13dc-442d-bdb0-d9bc5fd4ea59@github.com>

> Clean up more intermediate objects created during these operations.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  add EdDSA

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27921/files
  - new: https://git.openjdk.org/jdk/pull/27921/files/ac90b17e..a539d8c1

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

  Stats: 20 lines in 1 file changed: 10 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27921.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27921/head:pull/27921

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

From mpowers at openjdk.org  Wed Oct 22 15:56:06 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 22 Oct 2025 15:56:06 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v2]
In-Reply-To: <SVulG6fAF0X-IewOOiMstqBsgUMksSJuCQBKtalFD5M=.205eb431-0148-492d-b8e5-09b430a9397d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <YOq-ujxXAh4byuMZP_EfttVOzdws-M2Q0In5Jk8ga0w=.17d00785-783a-42e6-b541-51d496394332@github.com>
 <SVulG6fAF0X-IewOOiMstqBsgUMksSJuCQBKtalFD5M=.205eb431-0148-492d-b8e5-09b430a9397d@github.com>
Message-ID: <-jCWQtOSfoKFpbfges6R4M01CxaotZGVwa4mEogUYfE=.ea148df7-d96e-4b85-8c29-0351cc5af2be@github.com>

On Tue, 16 Sep 2025 18:48:43 GMT, Bernd <duke at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - merge
>>  - removed changes to PBMAC1Core and addressed some comments from Valerie
>>  - small changes
>>  - not used
>>  - refresh index
>>  - Merge
>>  - rework to eliminate PBMAC1ParameterSpec
>>  - merge
>>  - comments from Valerie
>>  - missed this new file
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/075ebb4e...624ef92e
>
> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 106:
> 
>> 104:             macSalt = pbeSpec.getSalt();
>> 105:             String ps = digestAlgorithmParams.toString();
>> 106:             kdfHmac = getKdfHmac(ps);
> 
> Are the macs always the same? (The encoder serializes them Independent)

The macs can be different.

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

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

From ascarpino at openjdk.org  Wed Oct 22 16:33:37 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 22 Oct 2025 16:33:37 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <aBn-R_E4oOG9rOcou3cpHWCzJSA6AZaaRJ6bejrbf2Q=.17f7ff61-84b0-4080-bc38-b745d0161461@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
 <wCRpZq2cbt6YKgRjpAbmErgaNiY23CfOtnJ7mmmjPKo=.ac7e7e9e-2b01-4fef-8439-cf2a117e78ba@github.com>
 <KyHAEYA31aLE29W_JXSG9ac-01Y5xYfU8_kMM3rX6Gk=.a04a361d-9953-4d52-b812-1ee1706bca15@github.com>
 <fBjrHsfqFtfneZOueWuSb7OWNM2zSP9Qn5R1w1fIDvI=.72a3a791-96a6-427e-af03-48bd2ff234f3@github.com>
 <aBn-R_E4oOG9rOcou3cpHWCzJSA6AZaaRJ6bejrbf2Q=.17f7ff61-84b0-4080-bc38-b745d0161461@github.com>
Message-ID: <bX9WpQBfetLgQ4fnsaOA0MpAm8GtrH3VEshgHSakc_g=.2a70c2f9-97a2-4f8d-b99e-c8454784c66d@github.com>

On Wed, 22 Oct 2025 12:42:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> @wangweij is correct, `generateEncoding()` is setting the instance variable `encodedKey`.    A finally-block is likely necessary if an exception happens after `privateKeyMaterial` is set in `generateEncoding()`
>
> Ok, that could be fixed by creating another method that just does the encoding (and change `generateEncoding` to call that), but maybe we can fix that later.

There are generic changes to PKCS8Key outside of PEM that I'd like to do, I can look at it then.

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

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

From mpowers at openjdk.org  Wed Oct 22 16:45:58 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 22 Oct 2025 16:45: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: <2q8dF1UaPHP7Y2i7PCMIlTEPTXViDmTrBlzAj3O_I6U=.3aa148e5-b57e-46c0-8bb6-315fa813c774@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>
 <2q8dF1UaPHP7Y2i7PCMIlTEPTXViDmTrBlzAj3O_I6U=.3aa148e5-b57e-46c0-8bb6-315fa813c774@github.com>
Message-ID: <s4Iyqz0MNtgbuqojH4IqjYwngdqHI-r9F3F_2duCS34=.79d3b607-6dab-4884-841a-1e456cd1b34a@github.com>

On Mon, 6 Oct 2025 19:56:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> 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.

The `PBKDF2Parameters` object does both decoding and encoding now. Same for `PBMAC1Parameters`. The only thing that's slightly odd (or maybe not), is there is no constructor from components. The `encode` method combines "construct with components" with encoding. This was suggested in a comment.

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

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

From mpowers at openjdk.org  Wed Oct 22 16:53:52 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 22 Oct 2025 16:53:52 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: <EbfwMgnp0LLT0TZdlxFSo2CE4U3FfF77tJcyfJ-V1VI=.faad0796-8f00-4c6b-8dd2-c5b430cdfa46@github.com>

On Thu, 16 Oct 2025 13:02:22 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/MacData.java line 229:
> 
>> 227:         } else {
>> 228:             throw new ParsingException("unexpected algorithm '"
>> 229:                     +macAlgorithm+ "'");
> 
> add spaces around `+`.

fixed

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

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

From mullan at openjdk.org  Wed Oct 22 18:29:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 22 Oct 2025 18:29:50 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
Message-ID: <aWJeIE0LgmW4og_WPmupj5aucDmyL4TkPjvRycn9Tjc=.5c9bdcf9-a1b8-4011-a4ea-0d21f8145dbb@github.com>

On Mon, 20 Oct 2025 22:19:41 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 two additional commits since the last revision:
> 
>  - fix non-pbe
>  - doc updates, zeroing, fix unencrypted keypair encoding, exception mods

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

> 1: /*

In the javadoc, I notice the `equals` and `hashCode` methods are marked final (which is done by the compiler I guess), but the other methods are not. Since records are always final, maybe it would be clearer to mark the other methods as `final` too.

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

> 296:      * @param str a String containing PEM data
> 297:      * @return a {@code DEREncodable}
> 298:      * @throws IllegalArgumentException on error in decoding or no PEM data found

It looks like this method will throw `EOFException` and not `IllegalArgumentException` if there is no PEM data because it calls decode with a `ByteArrayInputStream` so uses that method which throws an `EOFException`.

Same comment for method that takes a `Class` argument.

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

> 282:      *                 stored in the new instance.
> 283:      * @return a new {@code PEMEncoder} instance configured for encryption
> 284:      * @throws NullPointerException when password is {@code null}

s/when/if/

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

> 283:      * @return a new {@code PEMEncoder} instance configured for encryption
> 284:      * @throws NullPointerException when password is {@code null}
> 285:      * @throws ProviderException if generating the encryption key fails.

No period needed at end.

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

> 283:      * @return a new {@code PEMEncoder} instance configured for encryption
> 284:      * @throws NullPointerException when password is {@code null}
> 285:      * @throws ProviderException if generating the encryption key fails.

This actually throws an `IllegalArgumentException` if the key derivation fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2452395054
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2452972189
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2452790848
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2452794999
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2452948135

From mdonovan at openjdk.org  Wed Oct 22 18:33:30 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 22 Oct 2025 18:33:30 GMT
Subject: RFR: 8368493: Disable most test JSSE debug output by default,
 and increase the test default maximum output log size [v2]
In-Reply-To: <5hwoLpZ68DndKJfKLXqzv0rgmt2qHg9dVtIRA3ksJqo=.94bc5bf3-e52d-457b-954c-4ff7eda8f20d@github.com>
References: <zcd0Bt3gLzyvL1N9Ky4xhh2FgvneDHW0qBIQYZNkG5o=.a37e1689-6d92-4dd8-8153-44788c605f62@github.com>
 <5hwoLpZ68DndKJfKLXqzv0rgmt2qHg9dVtIRA3ksJqo=.94bc5bf3-e52d-457b-954c-4ff7eda8f20d@github.com>
Message-ID: <mx77ft6vcFZR-pocQLCeHOif-tYTJqITZyqL_G-NSR4=.c36cb95b-1725-4c46-887f-4e295f612e28@github.com>

On Wed, 15 Oct 2025 17:19:42 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> 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

test/jdk/javax/net/ssl/HttpsURLConnection/Equals.java line 50:

> 48:      * after gaining some familiarity with this application.
> 49:      */
> 50:     private static final boolean debug = false;

Instead of hardcoding this, it's more flexible to use `Boolean.getBoolean("test.debug")` so you can run a test with debug output but not have to recompile the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27455#discussion_r2452966479

From mullan at openjdk.org  Wed Oct 22 19:41:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 22 Oct 2025 19:41:56 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
Message-ID: <12-8qe1LL2Ce-i6VmfWp-MF_Y4m-ljGFsWUanKEJUH8=.c1ff5d19-0cf4-4b25-97d7-434e5d9d32ce@github.com>

On Mon, 20 Oct 2025 22:19:41 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 two additional commits since the last revision:
> 
>  - fix non-pbe
>  - doc updates, zeroing, fix unencrypted keypair encoding, exception mods

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

> 1: /*

Some inconsistency in parameter definitions that are the same across different methods. Please check and use consistent wording.

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

> 366:      * @throws RuntimeException if encryption of the encoding fails
> 367:      *
> 368:      * @implNote The {@code jdk.epkcs8.defaultAlgorithm} security property

You can remove this impl note since algorithm param is required now.

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

> 533:      * decryption key and provider.
> 534:      *
> 535:      * @param decryptKey the decryption key. Must not be {@code null}

Missing period.

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

> 536:      * @param provider the {@code Provider} used for {@link Cipher} decryption
> 537:      *                and {@link PrivateKey} generation. If {@code null}, the
> 538:      *                default provider configuration is used

Missing period.

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

> 602:      * @param decryptKey the decryption key; must not be {@code null}
> 603:      * @param provider the {@code Provider} used for {@link Cipher} decryption
> 604:      *                 and key generation. If {@code null} the default provider

comma after "if null".

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

> 603:      * @param provider the {@code Provider} used for {@link Cipher} decryption
> 604:      *                 and key generation. If {@code null} the default provider
> 605:      *                 configuration is used

Missing period.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2453163439
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2453121482
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2453162122
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2453157490
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2453160035
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2453158818

From wetmore at openjdk.org  Wed Oct 22 19:45:36 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 22 Oct 2025 19:45:36 GMT
Subject: RFR: 8368493: Disable most test JSSE debug output by default,
 and increase the test default maximum output log size [v2]
In-Reply-To: <mx77ft6vcFZR-pocQLCeHOif-tYTJqITZyqL_G-NSR4=.c36cb95b-1725-4c46-887f-4e295f612e28@github.com>
References: <zcd0Bt3gLzyvL1N9Ky4xhh2FgvneDHW0qBIQYZNkG5o=.a37e1689-6d92-4dd8-8153-44788c605f62@github.com>
 <5hwoLpZ68DndKJfKLXqzv0rgmt2qHg9dVtIRA3ksJqo=.94bc5bf3-e52d-457b-954c-4ff7eda8f20d@github.com>
 <mx77ft6vcFZR-pocQLCeHOif-tYTJqITZyqL_G-NSR4=.c36cb95b-1725-4c46-887f-4e295f612e28@github.com>
Message-ID: <eJZCbHh3Rr10br1-iSGLfP3Dvq7p_nI05Tt8mF1RZyo=.302351bb-01cc-4419-a622-7d1553896438@github.com>

On Wed, 22 Oct 2025 18:20:36 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusted sizes to be more reasonable
>
> test/jdk/javax/net/ssl/HttpsURLConnection/Equals.java line 50:
> 
>> 48:      * after gaining some familiarity with this application.
>> 49:      */
>> 50:     private static final boolean debug = false;
> 
> Instead of hardcoding this, it's more flexible to use `Boolean.getBoolean("test.debug")` so you can run a test with debug output but not have to recompile the test.

I don't see much difference between adding a System Property to the invocation vs. recompiling the test which is automatically done when running jtreg.

There are only 8 tests currently using `test.debug` out of just under 400 tests.  If SQE is interested in switching to this model, let's consider fixing throughout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27455#discussion_r2453174709

From duke at openjdk.org  Wed Oct 22 20:43:27 2025
From: duke at openjdk.org (duke)
Date: Wed, 22 Oct 2025 20:43:27 GMT
Subject: RFR: 8367008: Algorithm identifiers for HmacSHA* should always
 have NULL as params [v10]
In-Reply-To: <3cWnWUg_mjp4TXU536P_UzPemz5GqCs9rrVzIqGyPU8=.6598fa4e-f732-49c1-911c-d145618fb1d1@github.com>
References: <UJJibSbfh07nx8npJpnIzq3dtZAaDyRHvbI3YJMxWFU=.9074f4af-8a21-4895-835e-fe45596c3cbc@github.com>
 <3cWnWUg_mjp4TXU536P_UzPemz5GqCs9rrVzIqGyPU8=.6598fa4e-f732-49c1-911c-d145618fb1d1@github.com>
Message-ID: <FnHEVa2G0BYmHdsSewBlTi2t0fnYqjjw9WPkZDVrKMI=.c15d43ba-728d-4197-a170-d66c0e74a569@github.com>

On Mon, 20 Oct 2025 20:47:48 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: Added bug id

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27700#issuecomment-3434138754

From duke at openjdk.org  Wed Oct 22 21:03:46 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 22 Oct 2025 21:03:46 GMT
Subject: Integrated: 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: <hur5XgNYXIXhkXV7pfg_GjdFxasjUHEqJ2izO-fwMns=.3fca0561-975d-44ce-a927-b9c15cb78741@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.

This pull request has now been integrated.

Changeset: 4377e7c9
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4377e7c9e8399037c66799e99825c56bebbee68e
Stats:     142 lines in 3 files changed: 76 ins; 31 del; 35 mod

8367008: Algorithm identifiers for HmacSHA* should always have NULL as params

Reviewed-by: weijun

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

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

From mpowers at openjdk.org  Wed Oct 22 22:02:50 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 22 Oct 2025 22:02:50 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v14]
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <HgRaTELVlUrwHDlYHEg-991pzPoORrq9w2rbyRj9sCM=.3671e28b-94bd-4447-a6e1-c3cde3e20fb3@github.com>

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

Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - merge
 - stragglers
 - checkpoint
 - remaining comments
 - more review comments from Sean and Weijun
 - more review comments from Weijun and Sean
 - another day another iteration
 - move algorithm-specific code into MacData and no change to SunJCE
 - fix behavior with keytool
 - default salt length and one other comment from Weijun
 - ... and 21 more: https://git.openjdk.org/jdk/compare/d8ebe387...8f0b0d02

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

Changes: https://git.openjdk.org/jdk/pull/24429/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=13
  Stats: 1516 lines in 10 files changed: 1237 ins; 176 del; 103 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 23 02:58:14 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 23 Oct 2025 02:58:14 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v13]
In-Reply-To: <cf2ubdsBgwpTHq-tN_v-btCKegyRqxi1e8mCNDYvUN8=.a9daade3-4740-4010-9e5a-d9b8d98d7742@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>
 <cf2ubdsBgwpTHq-tN_v-btCKegyRqxi1e8mCNDYvUN8=.a9daade3-4740-4010-9e5a-d9b8d98d7742@github.com>
Message-ID: <AvcofER_w6o-pGv-3Lz8ARu3MO5UHw_xdMhZiuxgx4s=.4668d5c9-2dd7-46c2-8475-de9048e2e098@github.com>

On Thu, 16 Oct 2025 13:29:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> 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`.

I believe it is fixed now. The "else block" not about PBMAC1 has been moved back into MacData.

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

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

From duke at openjdk.org  Thu Oct 23 03:24:08 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 23 Oct 2025 03:24:08 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v13]
In-Reply-To: <45hkD8RQ3TH-4dvjl_bN9dG0B4BSE3d1wXZAPMxeDSA=.84597563-35d7-43c4-bd7c-cad7da7e9277@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
 <45hkD8RQ3TH-4dvjl_bN9dG0B4BSE3d1wXZAPMxeDSA=.84597563-35d7-43c4-bd7c-cad7da7e9277@github.com>
Message-ID: <rTQYPPSgaDKWJX_WfasiM94eRXXdkYtd5yk9nar3TkY=.8f6ccdbc-9b96-4ca5-a051-d0ed875bbcff@github.com>

On Tue, 21 Oct 2025 18:19:18 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
>
> Changes look fine, thanks~

Thank you @valeriepeng, @iwanowww, and @eme64 for your comments.  After code review comment updates, all recommended regression tests have been executed and have passed (with all known failures).  Benchmarks have been reran in each of the modes supported by intrinsics and these results have matched to those of pre-code review update.

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

PR Comment: https://git.openjdk.org/jdk/pull/27807#issuecomment-3434921841

From duke at openjdk.org  Thu Oct 23 03:24:09 2025
From: duke at openjdk.org (duke)
Date: Thu, 23 Oct 2025 03:24:09 GMT
Subject: RFR: 8326609: New AES implementation with updates specified in
 FIPS 197 [v13]
In-Reply-To: <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
 <zdLwM4TCZj_ixhyDnAScaIaxTAytslA732cmCp3Pyh0=.95bc5718-d2cd-45d6-bfa5-7c525ce90aee@github.com>
Message-ID: <K6fZMfg9ZQRhOrX43ljA8EoWhtvQrt7mdefDtTQ6dG8=.e701db3d-4590-4545-b12b-e6dce984033f@github.com>

On Tue, 21 Oct 2025 00:05:31 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

@smemery 
Your change (at version fdfd38929d3c7b725cf44312eba5d2f0d7da7b0a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27807#issuecomment-3434923911

From ascarpino at openjdk.org  Thu Oct 23 04:14:26 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 23 Oct 2025 04:14:26 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v8]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <vV8yci_2B3kXaY8MfUOf1rPEyz5bqH_308bfOufc-_k=.d3352969-b164-4123-879f-c00b83d06629@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:

  more doc updates and zeroing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/2e9332b9..45f30dd3

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

  Stats: 178 lines in 9 files changed: 60 ins; 34 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/27147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147

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

From mdonovan at openjdk.org  Thu Oct 23 11:20:04 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 23 Oct 2025 11:20:04 GMT
Subject: RFR: 8368493: Disable most test JSSE debug output by default,
 and increase the test default maximum output log size [v2]
In-Reply-To: <eJZCbHh3Rr10br1-iSGLfP3Dvq7p_nI05Tt8mF1RZyo=.302351bb-01cc-4419-a622-7d1553896438@github.com>
References: <zcd0Bt3gLzyvL1N9Ky4xhh2FgvneDHW0qBIQYZNkG5o=.a37e1689-6d92-4dd8-8153-44788c605f62@github.com>
 <5hwoLpZ68DndKJfKLXqzv0rgmt2qHg9dVtIRA3ksJqo=.94bc5bf3-e52d-457b-954c-4ff7eda8f20d@github.com>
 <mx77ft6vcFZR-pocQLCeHOif-tYTJqITZyqL_G-NSR4=.c36cb95b-1725-4c46-887f-4e295f612e28@github.com>
 <eJZCbHh3Rr10br1-iSGLfP3Dvq7p_nI05Tt8mF1RZyo=.302351bb-01cc-4419-a622-7d1553896438@github.com>
Message-ID: <fF9EXSUjFXRN_K8cxirWEFZVemL3trAQWHN7L5hS1Mw=.0a983a08-d5bd-488f-af3f-a599eee6219f@github.com>

On Wed, 22 Oct 2025 19:43:13 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/HttpsURLConnection/Equals.java line 50:
>> 
>>> 48:      * after gaining some familiarity with this application.
>>> 49:      */
>>> 50:     private static final boolean debug = false;
>> 
>> Instead of hardcoding this, it's more flexible to use `Boolean.getBoolean("test.debug")` so you can run a test with debug output but not have to recompile the test.
>
> I don't see much difference between adding a System Property to the invocation vs. recompiling the test which is automatically done when running jtreg.
> 
> There are only 8 tests currently using `test.debug` out of just under 400 tests.  If SQE is interested in switching to this model, let's consider fixing throughout.

SQE is interested in removing the hardcoded `debug` flags but it's been lower priority. When a test fails on a specific build, it's nice to be able to run the test on that build with enabled debugging without making any changes or having to remember the correct command line incantation. As I thought about this more, I realized that we can specify the `javax.net.debug` property on the command line as well. So is this pattern necessary at all?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27455#discussion_r2454775251

From mdonovan at openjdk.org  Thu Oct 23 11:32:04 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 23 Oct 2025 11:32:04 GMT
Subject: RFR: 8361894:
 sun/security/krb5/config/native/TestDynamicStore.java ensure that the test is
 run with sudo [v4]
In-Reply-To: <YzwCd4wKnDsA72Qt4MDm6vFaClBWaMtuYwmWgg7ZYUI=.5e6fca73-8c8e-450e-9755-b8efee16b859@github.com>
References: <78whX4UN6lwESBM5rEK0qXZqt3_zGalKTEkcgWceVn8=.bbae0b43-5a94-491b-93ec-3310236e6b45@github.com>
 <YzwCd4wKnDsA72Qt4MDm6vFaClBWaMtuYwmWgg7ZYUI=.5e6fca73-8c8e-450e-9755-b8efee16b859@github.com>
Message-ID: <ihDBpLadhpozVKLELEh0kjSZgtqXlgh-ivc9ihbxcRk=.cc74c948-5ed7-4b30-abbb-6bc67cc83f16@github.com>

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

>> sun/security/krb5/config/native/TestDynamicStore.java is commonly run without sudo, which leads to the access related failure. 
>> Added a ui popup reminding to run the test with sudo, making instructions clearer and more noticeable
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments

test/jdk/sun/security/krb5/config/native/TestDynamicStore.java line 65:

> 63:         if (!"root".equals(System.getProperty("user.name"))) {
> 64: 
> 65:             JOptionPane.showMessageDialog(null, """

Is this dialog box necessary if the test will fail with the same message?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26293#discussion_r2454808353

From myankelevich at openjdk.org  Thu Oct 23 11:41:06 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 23 Oct 2025 11:41:06 GMT
Subject: RFR: 8361894:
 sun/security/krb5/config/native/TestDynamicStore.java ensure that the test is
 run with sudo [v4]
In-Reply-To: <ihDBpLadhpozVKLELEh0kjSZgtqXlgh-ivc9ihbxcRk=.cc74c948-5ed7-4b30-abbb-6bc67cc83f16@github.com>
References: <78whX4UN6lwESBM5rEK0qXZqt3_zGalKTEkcgWceVn8=.bbae0b43-5a94-491b-93ec-3310236e6b45@github.com>
 <YzwCd4wKnDsA72Qt4MDm6vFaClBWaMtuYwmWgg7ZYUI=.5e6fca73-8c8e-450e-9755-b8efee16b859@github.com>
 <ihDBpLadhpozVKLELEh0kjSZgtqXlgh-ivc9ihbxcRk=.cc74c948-5ed7-4b30-abbb-6bc67cc83f16@github.com>
Message-ID: <-trtfEnycXuShsjfL9KJMoKQRXaqITl31QmCkHUI3r4=.d0d6109a-9273-4772-84cc-1e7f558fee0e@github.com>

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

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments
>
> test/jdk/sun/security/krb5/config/native/TestDynamicStore.java line 65:
> 
>> 63:         if (!"root".equals(System.getProperty("user.name"))) {
>> 64: 
>> 65:             JOptionPane.showMessageDialog(null, """
> 
> Is this dialog box necessary if the test will fail with the same message?

Yes, I believe so. The exception messages proved to be easy to miss for this test. Dialog box makes spotting the issue much easier imo

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26293#discussion_r2454828938

From weijun at openjdk.org  Thu Oct 23 14:36:46 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 23 Oct 2025 14:36:46 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v14]
In-Reply-To: <HgRaTELVlUrwHDlYHEg-991pzPoORrq9w2rbyRj9sCM=.3671e28b-94bd-4447-a6e1-c3cde3e20fb3@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <HgRaTELVlUrwHDlYHEg-991pzPoORrq9w2rbyRj9sCM=.3671e28b-94bd-4447-a6e1-c3cde3e20fb3@github.com>
Message-ID: <OlQ2AorM5A70wgd5FxTHtuAYjqiQa_FWSU-9sjsiba4=.c9407e11-9f4d-4e8d-86cf-5e87d6750401@github.com>

On Wed, 22 Oct 2025 22:02:50 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - merge
>  - stragglers
>  - checkpoint
>  - remaining comments
>  - more review comments from Sean and Weijun
>  - more review comments from Weijun and Sean
>  - another day another iteration
>  - move algorithm-specific code into MacData and no change to SunJCE
>  - fix behavior with keytool
>  - default salt length and one other comment from Weijun
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/d8ebe387...8f0b0d02

Some comments.

src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 244:

> 242:         }
> 243:         DerValue pBKDF2_params = kdf.data.getDerValue();
> 244:         if (pBKDF2_params.tag != DerValue.tag_Sequence) {

This check seems like it should belong to the `PBKDF2Parameters` constructor.

src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 309:

> 307:         pBES2_params.write(DerValue.tag_Sequence,
> 308:                 // keysize encoded as octets
> 309:                 PBKDF2Parameters.encode(salt, iCount, keysize/8, kdfAlgo_OID));

If you make the change I suggested in `PBKDF2Parameters.encode`, the line above should be

pBES2_params.writeBytes(PBKDF2Parameters.encode(salt, iCount, keysize/8, kdfAlgo_OID));

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

> 1: /*

In this class, there are several places where `startsWith("pbewith")` is called. Add a comment to the method that the algorithm names are guaranteed to be using lowercase letters (at least for the prefix).

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

> 75:     private final int keyLength;
> 76:     private final String kdfHmac;
> 77:     private final String hmac;

Add a comment that the 3 fields above are only for PBMAC1.

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

> 133:     }
> 134: 
> 135:     private static byte[] getMac(String macAlgorithm, char[] password,

Why the difference in the names `getMac` and `calculateMac`?

This method is the basic one for calculation, and `processMacData` is verification and `calculateMac` is generation. Add more comments.

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

> 158:             keySpec = new PBEKeySpec(password);
> 159:         }
> 160:         pbeKey = skf.generateSecret(keySpec);

If the line above fails, there is no chance to clean `keySpec`. Create a big try-finally block.

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

> 168:         } finally {
> 169:             keySpec.clearPassword();
> 170:             sun.security.util.KeyUtil.destroySecretKeys(pbeKey);

Here, `pbeKey` is cleared before `m.update` and `m.doFinal` are called. This might be unsafe because `m` could be still using `pbeKey`.

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

> 246:     }
> 247: 
> 248:     byte[] getSalt() {

This method is not used anywhere.

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

> 255: 
> 256:     /**
> 257:      * Returns the ASN.1 encoding of this object.

This is a `static` method. There is no "this object".

src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 136:

> 134:         // keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}
> 135:         tmp3.write(DerValue.tag_Sequence, PBKDF2Parameters.encode(salt,
> 136:                 iterationCount, keyLength, kdfHmac));

If you make the change I suggested in `PBKDF2Parameters.encode`, the line above should be

tmp3.writeBytes(PBKDF2Parameters.encode(salt,
                 iterationCount, keyLength, kdfHmac));

src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 137:

> 135:         tmp3.write(DerValue.tag_Sequence, PBKDF2Parameters.encode(salt,
> 136:                 iterationCount, keyLength, kdfHmac));
> 137:         tmp3.write(DerValue.tag_Sequence, tmp4);

Now that Koushik's JDK-8367008 has been integrated, there is no need to construct `tmp4`. Just call `tmp3.write(AlgorithmId.get(hmac))`. It's OK for this method to throw a NSAE.

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 353:

> 351:                     cipher.init(Cipher.DECRYPT_MODE, skey, algParams);
> 352:                 } finally {
> 353:                     sun.security.util.KeyUtil.destroySecretKeys(skey);

No need for the package name `sun.security.util.KeyUtil`. All classes have already been imported. The are several such cases in this file and one in `MacData`.

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 162:

> 160:         tmp0.putInteger(iterationCount);
> 161:         tmp0.putInteger(keyLength);
> 162:         tmp0.write(DerValue.tag_Sequence, tmp1);

After Koushik's JDK-8367008, no need for `tmp1`. This can be just `tmp0.write(new AlgorithmId(prf))`.

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 168:

> 166:         out.write(DerValue.tag_Sequence, tmp0);
> 167: 
> 168:         return out.toByteArray();

`out` is just a concatenation of OID and `tmp0`, which needs to be wrapped inside an ASN.1 SEQUENCE. The return value should be

new DerOutputStream().write(DerValue.tag_Sequence, out).toByteArray();


This makes sure the output of `encode` is the same as the input of the `new PBKDF2Parameters()` constructor.

Once this is updated, the other places that call `encode` do not need to add the ASN.1 SEQUENCE wrapper.

src/java.base/share/conf/security/java.security line 1344:

> 1342: 
> 1343: # The algorithm used to calculate the optional MacData at the end of a PKCS12
> 1344: # file. This can be any HmacPBE or PBEWith<mac> algorithm defined in the

I know `HmacPBE` has been like this from the beginning, but to be consistent and precise, suggest changing it to `HmacPBE<digest>`.

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

PR Review: https://git.openjdk.org/jdk/pull/24429#pullrequestreview-3370108106
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455246107
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455321557
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455341868
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455250023
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455260394
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455262798
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455266129
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455267245
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455333333
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455324888
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455284291
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455287363
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455295271
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455313609
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2455352943

From duke at openjdk.org  Thu Oct 23 15:37:57 2025
From: duke at openjdk.org (Neha Joshi)
Date: Thu, 23 Oct 2025 15:37:57 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap
Message-ID: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>

This PR contain changes to handle skipped exception for below test cases. 

* test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
* test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
* test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java

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

Commit messages:
 - JDK-8368524 : Review comment changes.
 - JDK-8368524 : Removed commented imports.
 - JDK-8368524 : Review comment changes.
 - JDK-8368524 : Removed wildcard imports
 - JDK-8368524 : Updated Skipped exception message
 - JDK-8368524 : Copyright date updated.
 - JDK-8368524 : Handle skipped exceptions.

Changes: https://git.openjdk.org/jdk/pull/27847/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27847&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368524
  Stats: 63 lines in 3 files changed: 39 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/27847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27847/head:pull/27847

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

From myankelevich at openjdk.org  Thu Oct 23 15:38:05 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 23 Oct 2025 15:38:05 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap
In-Reply-To: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
Message-ID: <XQM3B5Lb7mMR2xEZvkWKHWDwXzkFSrWH4YFR6ikfbIo=.e4d40bd4-6c68-4de9-b608-971f79a0440d@github.com>

On Thu, 16 Oct 2025 13:52:58 GMT, Neha Joshi <duke at openjdk.org> wrote:

> This PR contain changes to handle skipped exception for below test cases. 
> 
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java

Looks good, just a few questions

Looks good, just 2 questions

Marked as reviewed by myankelevich (Committer).

Looks good to me

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2024, Oracle and/or its affiliates. All rights reserved.

Nit: Please update to copyright to 
` * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.`

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java line 37:

> 35: import java.security.AlgorithmParameters;
> 36: import java.security.Provider;
> 37: import javax.crypto.*;

nit: wildcard imports

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java line 49:

> 47: public class NISTWrapKAT extends PKCS11Test {
> 48: 
> 49:     private static List<String> skippedAlgoList = new ArrayList<>();

nit: 
```suggestion 
    private static final List<String> skippedAlgoList = new ArrayList<>();

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java line 325:

> 323:         int allowed = Cipher.getMaxAllowedKeyLength("AES");
> 324:         if (keyLen > allowed) {
> 325:             throw new SkippedException("Skip, exceeds max allowed size " + allowed);

I think it's better to keep this as is, as in case this throws skipped exception it will stop the rest of the tests and they will not run. This could cause the error to be thrown. 

One of the options that come to mind is to have the line 399 `testEnc(algo, (String)td[1], (int)td[2], (String)td[3],` catch skipped exception and add to the `skippedAlgoList`. 
Another option could be to pass boolean/status out the method and use it to check if test actually run. 
Another option could be to keep the skipped list as a global var and append it from here directly.

These are not the only options, so if you think of something better - it's your call.

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java line 415:

> 413:             System.out.println("All Tests Passed");
> 414:         } else {
> 415:             System.err.println("Some tests were skipped : " + skippedAlgoList);

This will only log a skip this way. Please throw an exception in the end.

```suggestion 
            throw new SkippedException("Some tests were skipped : " + skippedAlgoList);

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2024, Oracle and/or its affiliates. All rights reserved.

Nit: copyright

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

nit: copyright

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java line 37:

> 35: import java.security.AlgorithmParameters;
> 36: import java.security.Provider;
> 37: import javax.crypto.*;

minor: could you please change wildcard imports to explicit ones in all the tests that were touched

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java line 37:

> 35: import java.security.AlgorithmParameters;
> 36: import java.security.Provider;
> 37: //import javax.crypto.*;

`//` :)

test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java line 135:

> 133:         String wrapAlg = "AESWrap";
> 134:         if (p.getService("Cipher", wrapAlg) == null) {
> 135:             throw new SkippedException("Skip, due to no support:  " + wrapAlg);

Minor: Could you please change the wording to something like `"No support:  " + wrapAlg);`

Also, is there any particular reason that lines 132 and 137 were removed? Don't you think it was a bit easier to read? If you like it as it is, I don't mind if you keep it as it is

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

PR Review: https://git.openjdk.org/jdk/pull/27847#pullrequestreview-3345856568
PR Review: https://git.openjdk.org/jdk/pull/27847#pullrequestreview-3359722784
PR Review: https://git.openjdk.org/jdk/pull/27847#pullrequestreview-3359950319
PR Comment: https://git.openjdk.org/jdk/pull/27847#issuecomment-3425928748
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2436679850
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2436715573
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2447520187
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2436706643
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2447517742
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2436680702
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2436681563
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2436683968
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2447507012
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2436714251

From duke at openjdk.org  Thu Oct 23 15:38:06 2025
From: duke at openjdk.org (Neha Joshi)
Date: Thu, 23 Oct 2025 15:38:06 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap
In-Reply-To: <XQM3B5Lb7mMR2xEZvkWKHWDwXzkFSrWH4YFR6ikfbIo=.e4d40bd4-6c68-4de9-b608-971f79a0440d@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
 <XQM3B5Lb7mMR2xEZvkWKHWDwXzkFSrWH4YFR6ikfbIo=.e4d40bd4-6c68-4de9-b608-971f79a0440d@github.com>
Message-ID: <j5l-otQnYoHjfMlOq8LQgdQdV8MKBHWIzXxN5kkoiNs=.109d7529-8da3-4776-868f-48f4f699eb5c@github.com>

On Thu, 16 Oct 2025 16:37:00 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> This PR contain changes to handle skipped exception for below test cases. 
>> 
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/TestGeneral.java
>> * test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java
>
> test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Nit: Please update to copyright to 
> ` * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.`

Do we need to remove 2024 from the copyright ?

> test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java line 325:
> 
>> 323:         int allowed = Cipher.getMaxAllowedKeyLength("AES");
>> 324:         if (keyLen > allowed) {
>> 325:             throw new SkippedException("Skip, exceeds max allowed size " + allowed);
> 
> I think it's better to keep this as is, as in case this throws skipped exception it will stop the rest of the tests and they will not run. This could cause the error to be thrown. 
> 
> One of the options that come to mind is to have the line 399 `testEnc(algo, (String)td[1], (int)td[2], (String)td[3],` catch skipped exception and add to the `skippedAlgoList`. 
> Another option could be to pass boolean/status out the method and use it to check if test actually run. 
> Another option could be to keep the skipped list as a global var and append it from here directly.
> 
> These are not the only options, so if you think of something better - it's your call.

I kept the return statement as it is and made skippedAlgoList a global variable. 
For each skip , we will add the element in the list .

> test/jdk/sun/security/pkcs11/Cipher/KeyWrap/XMLEncKAT.java line 135:
> 
>> 133:         String wrapAlg = "AESWrap";
>> 134:         if (p.getService("Cipher", wrapAlg) == null) {
>> 135:             throw new SkippedException("Skip, due to no support:  " + wrapAlg);
> 
> Minor: Could you please change the wording to something like `"No support:  " + wrapAlg);`
> 
> Also, is there any particular reason that lines 132 and 137 were removed? Don't you think it was a bit easier to read? If you like it as it is, I don't mind if you keep it as it is

The method itself is not that long and after the very first line, having spaces was reducing readability to me , that was the reason I removed the extra lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2436723302
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2447504600
PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2439272723

From myankelevich at openjdk.org  Thu Oct 23 15:38:07 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 23 Oct 2025 15:38:07 GMT
Subject: RFR: 8368524: Tests are skipped and shown as passed in
 test/jdk/sun/security/pkcs11/Cipher/KeyWrap
In-Reply-To: <j5l-otQnYoHjfMlOq8LQgdQdV8MKBHWIzXxN5kkoiNs=.109d7529-8da3-4776-868f-48f4f699eb5c@github.com>
References: <K7RbTVtP0RTtxnp6A57DB3fEGlSzfBzuDjwBd0UU9po=.436f5cae-daac-41a2-aca3-6980c27d5872@github.com>
 <XQM3B5Lb7mMR2xEZvkWKHWDwXzkFSrWH4YFR6ikfbIo=.e4d40bd4-6c68-4de9-b608-971f79a0440d@github.com>
 <j5l-otQnYoHjfMlOq8LQgdQdV8MKBHWIzXxN5kkoiNs=.109d7529-8da3-4776-868f-48f4f699eb5c@github.com>
Message-ID: <YTBj1_YJcfi04npLM_upoO-PuzQVPbVjRyy0n4mzbHc=.aff8baa3-65eb-4c3f-a08c-eed43d1a9504@github.com>

On Thu, 16 Oct 2025 16:53:36 GMT, Neha Joshi <duke at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs11/Cipher/KeyWrap/NISTWrapKAT.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2021, 2024, Oracle and/or its affiliates. All rights reserved.
>> 
>> Nit: Please update to copyright to 
>> ` * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.`
>
> Do we need to remove 2024 from the copyright ?

Yes, the first date is the creation date, the second is the last update

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27847#discussion_r2436735442

From wetmore at openjdk.org  Thu Oct 23 16:13:47 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 23 Oct 2025 16:13:47 GMT
Subject: RFR: 8368493: Disable most test JSSE debug output by default,
 and increase the test default maximum output log size [v2]
In-Reply-To: <fF9EXSUjFXRN_K8cxirWEFZVemL3trAQWHN7L5hS1Mw=.0a983a08-d5bd-488f-af3f-a599eee6219f@github.com>
References: <zcd0Bt3gLzyvL1N9Ky4xhh2FgvneDHW0qBIQYZNkG5o=.a37e1689-6d92-4dd8-8153-44788c605f62@github.com>
 <5hwoLpZ68DndKJfKLXqzv0rgmt2qHg9dVtIRA3ksJqo=.94bc5bf3-e52d-457b-954c-4ff7eda8f20d@github.com>
 <mx77ft6vcFZR-pocQLCeHOif-tYTJqITZyqL_G-NSR4=.c36cb95b-1725-4c46-887f-4e295f612e28@github.com>
 <eJZCbHh3Rr10br1-iSGLfP3Dvq7p_nI05Tt8mF1RZyo=.302351bb-01cc-4419-a622-7d1553896438@github.com>
 <fF9EXSUjFXRN_K8cxirWEFZVemL3trAQWHN7L5hS1Mw=.0a983a08-d5bd-488f-af3f-a599eee6219f@github.com>
Message-ID: <lFAlF5_4EsZ00gTVBmguJgY-JGg6DTHDpWUHM_kwmoA=.26e65079-f8a7-44c3-a78a-d6aeb53208ea@github.com>

On Thu, 23 Oct 2025 11:17:11 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> I don't see much difference between adding a System Property to the invocation vs. recompiling the test which is automatically done when running jtreg.
>> 
>> There are only 8 tests currently using `test.debug` out of just under 400 tests.  If SQE is interested in switching to this model, let's consider fixing throughout.
>
> SQE is interested in removing the hardcoded `debug` flags but it's been lower priority. When a test fails on a specific build, it's nice to be able to run the test on that build with enabled debugging without making any changes or having to remember the correct command line incantation. As I thought about this more, I realized that we can specify the `javax.net.debug` property on the command line as well. So is this pattern necessary at all?

We added it 20+ years ago for ease of development, as it's a common mode to want to enable during dev, but not necessarily keep on full time.  A simple false->true->false change is all that's needed, vs. remembering `System.setProperty("javax.net.debug, ...)`

Most current instances can do either option, as the code just does `if (debug) System.setProperty(); `

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27455#discussion_r2455824277

From ascarpino at openjdk.org  Thu Oct 23 16:25:58 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 23 Oct 2025 16:25:58 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <aWJeIE0LgmW4og_WPmupj5aucDmyL4TkPjvRycn9Tjc=.5c9bdcf9-a1b8-4011-a4ea-0d21f8145dbb@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
 <aWJeIE0LgmW4og_WPmupj5aucDmyL4TkPjvRycn9Tjc=.5c9bdcf9-a1b8-4011-a4ea-0d21f8145dbb@github.com>
Message-ID: <J0AhZ2syJv1vJdRmKfdBZabGwpsu8gBdMj7x80O5rJY=.5e50c121-c822-43f3-8046-219d4b2e2f61@github.com>

On Wed, 22 Oct 2025 18:22:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix non-pbe
>>  - doc updates, zeroing, fix unencrypted keypair encoding, exception mods
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 298:
> 
>> 296:      * @param str a String containing PEM data
>> 297:      * @return a {@code DEREncodable}
>> 298:      * @throws IllegalArgumentException on error in decoding or no PEM data found
> 
> It looks like this method will throw `EOFException` and not `IllegalArgumentException` if there is no PEM data because it calls decode with a `ByteArrayInputStream` so uses that method which throws an `EOFException`.
> 
> Same comment for method that takes a `Class` argument.

EOFException is a child of IOException, so the catch covers this.

> src/java.base/share/classes/java/security/PEMEncoder.java line 285:
> 
>> 283:      * @return a new {@code PEMEncoder} instance configured for encryption
>> 284:      * @throws NullPointerException when password is {@code null}
>> 285:      * @throws ProviderException if generating the encryption key fails.
> 
> This actually throws an `IllegalArgumentException` if the key derivation fails.

Yes, I wrote the javadoc based on a suggestion, then didn't update when the constructor was changed.

> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 1:
> 
>> 1: /*
> 
> Some inconsistency in parameter definitions that are the same across different methods. Please check and use consistent wording.

I cleaned up the inconsistencies I found in encrypt, getKey, and getKeyPair.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2453138454
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2453074907
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2453811060

From ascarpino at openjdk.org  Thu Oct 23 16:26:00 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 23 Oct 2025 16:26:00 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v4]
In-Reply-To: <M99WUGoHj3vkWDqv-9jm-68BgID__FUi8CQAtOOiQRM=.f4cd743c-d89e-430c-b4d9-b60f979d4a98@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>
 <rHFGR4pcQnwe-m9EZrfEC4t3bHf7wTvWnJQfaJRtyg0=.4dab2967-4533-4766-96f1-3878987b1680@github.com>
 <M99WUGoHj3vkWDqv-9jm-68BgID__FUi8CQAtOOiQRM=.f4cd743c-d89e-430c-b4d9-b60f979d4a98@github.com>
Message-ID: <B8resUOFhr8sn-ss44l41QR5arm-TUaU0Hrcuu16MOQ=.d36f9c26-79f8-4047-818b-acc68924fb48@github.com>

On Fri, 17 Oct 2025 03:02:26 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> 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.
>
> If I remember correctly, in the preview 1 code review this was `GeneralSecurityException` and there was a comment to change it.  I'm happy to go back to GSE.

Sorry, `SecurityException` was the plan.

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

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

From rhalade at openjdk.org  Thu Oct 23 16:26:55 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 23 Oct 2025 16:26:55 GMT
Subject: RFR: 8360395: sun/security/tools/keytool/i18n.java user country is
 current user location instead of the language
In-Reply-To: <RhPO5u_2ArMs5xdcJ8vRnTmi8t0PtVdzQAopkKpHPEc=.590d7d13-3756-45ed-9973-4ecc3f683dcb@github.com>
References: <RhPO5u_2ArMs5xdcJ8vRnTmi8t0PtVdzQAopkKpHPEc=.590d7d13-3756-45ed-9973-4ecc3f683dcb@github.com>
Message-ID: <KbtzKccRS92AHXh7fj8mB-VPs5x5x4t3Bmsfoctrnkk=.bcb6df3c-8a9e-4ec9-bfc6-28127fa958b2@github.com>

On Tue, 14 Oct 2025 11:26:35 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> User location would now follow the language location, not the current location of the test machine

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27799#pullrequestreview-3370990265

From rhalade at openjdk.org  Thu Oct 23 16:31:05 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 23 Oct 2025 16:31:05 GMT
Subject: RFR: 8368982: Test sun/security/tools/jarsigner/EC.java completed
 and timed out [v2]
In-Reply-To: <2t4aFYJt5stJGbYfTJAWfroOKyqZJzv9dR3XOixOnHA=.c636993a-9f22-4bd2-be56-3cf87f6bae07@github.com>
References: <sIQCKm-XGEghN_mfOHChULMIrWOgjCvEidb56SM6suM=.2a708c5e-45ed-41b6-bc81-78e5b60afed5@github.com>
 <2t4aFYJt5stJGbYfTJAWfroOKyqZJzv9dR3XOixOnHA=.c636993a-9f22-4bd2-be56-3cf87f6bae07@github.com>
Message-ID: <3BAlvcdrhtM2PS81DpRyZH90H1JYlltLVt9GUAeb7r8=.c14d00e3-cf21-4b5c-b91b-41e5213e3178@github.com>

On Thu, 9 Oct 2025 13:22:31 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.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27695#pullrequestreview-3371019561

From rhalade at openjdk.org  Thu Oct 23 16:53:39 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 23 Oct 2025 16:53:39 GMT
Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass
 when they should skip [v3]
In-Reply-To: <LMLDnDU--pCT5UhpoSK-30hRZdhCuLGOLwZ5f2vmOT0=.cf47cb7a-81f4-4d44-874e-01b0ef9f7036@github.com>
References: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
 <LMLDnDU--pCT5UhpoSK-30hRZdhCuLGOLwZ5f2vmOT0=.cf47cb7a-81f4-4d44-874e-01b0ef9f7036@github.com>
Message-ID: <oYPS0kHDhC_p3kS5QrVzob-Qm4ciU5KZhV58f49mbf8=.070514a8-731a-4fa1-b249-db5c05fb4046@github.com>

On Wed, 24 Sep 2025 13:56:01 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java
>> * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
>> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java
>> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java
>> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java
>> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java
>> * test/jdk/sun/security/pkcs11/Signature/TestDSA.java
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   name changes for arrays

Changes requested by rhalade (Reviewer).

test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 146:

> 144:                         mgfHash,
> 145:                         s);
> 146:                 skipTest = true;

I think skipTest logic in this test needs further updates. It starts with true as default value, should be false and only set skipTest to true when we encounter a test scenario that is not supported. I think there is also a case where skipTest value is overwritten at line 153 when called in a loop at line 95.

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

PR Review: https://git.openjdk.org/jdk/pull/27367#pullrequestreview-3371158131
PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2456025395

From mpowers at openjdk.org  Thu Oct 23 16:54:54 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 23 Oct 2025 16:54:54 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v14]
In-Reply-To: <OlQ2AorM5A70wgd5FxTHtuAYjqiQa_FWSU-9sjsiba4=.c9407e11-9f4d-4e8d-86cf-5e87d6750401@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <HgRaTELVlUrwHDlYHEg-991pzPoORrq9w2rbyRj9sCM=.3671e28b-94bd-4447-a6e1-c3cde3e20fb3@github.com>
 <OlQ2AorM5A70wgd5FxTHtuAYjqiQa_FWSU-9sjsiba4=.c9407e11-9f4d-4e8d-86cf-5e87d6750401@github.com>
Message-ID: <buHo9w5NK-X5J1MgfSIMABF0eh2Joi_d5LFlA1Nmj9s=.62e19caa-405c-4cfa-be65-6926cb39e65e@github.com>

On Thu, 23 Oct 2025 13:59:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
>> 
>>  - merge
>>  - stragglers
>>  - checkpoint
>>  - remaining comments
>>  - more review comments from Sean and Weijun
>>  - more review comments from Weijun and Sean
>>  - another day another iteration
>>  - move algorithm-specific code into MacData and no change to SunJCE
>>  - fix behavior with keytool
>>  - default salt length and one other comment from Weijun
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/d8ebe387...8f0b0d02
>
> src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 244:
> 
>> 242:         }
>> 243:         DerValue pBKDF2_params = kdf.data.getDerValue();
>> 244:         if (pBKDF2_params.tag != DerValue.tag_Sequence) {
> 
> This check seems like it should belong to the `PBKDF2Parameters` constructor.

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 77:
> 
>> 75:     private final int keyLength;
>> 76:     private final String kdfHmac;
>> 77:     private final String hmac;
> 
> Add a comment that the 3 fields above are only for PBMAC1.

done

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 135:
> 
>> 133:     }
>> 134: 
>> 135:     private static byte[] getMac(String macAlgorithm, char[] password,
> 
> Why the difference in the names `getMac` and `calculateMac`?
> 
> This method is the basic one for calculation, and `processMacData` is verification and `calculateMac` is generation. Add more comments.

What about this:
`getMac` -> `calculateMac`
`calculateMac` -> `generateMac`
`processMacData` ->`verifyMac`

I'll add more comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2456039764
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2456039311
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2456038719

From ascarpino at openjdk.org  Thu Oct 23 16:57:47 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 23 Oct 2025 16:57:47 GMT
Subject: RFR: 8370082: Intermediate objects clean up in ECDH, EdDSA, XDH, 
 DHKEM, and HKDF [v4]
In-Reply-To: <55tojvC29VibCtDSsbfB2J0uFX2epcDN6Jgs77AfzY4=.65f1665a-13dc-442d-bdb0-d9bc5fd4ea59@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
 <55tojvC29VibCtDSsbfB2J0uFX2epcDN6Jgs77AfzY4=.65f1665a-13dc-442d-bdb0-d9bc5fd4ea59@github.com>
Message-ID: <lVMA_iO86_M2XgaV9UR3jVLGbk7DAmE-WBz2CExKGII=.a3095438-b508-4c6f-b2b1-bb2e74c9e014@github.com>

On Wed, 22 Oct 2025 15:07:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Clean up more intermediate objects created during these operations.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add EdDSA

updates look good.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27921#pullrequestreview-3371195136

From rhalade at openjdk.org  Thu Oct 23 16:57:50 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 23 Oct 2025 16:57:50 GMT
Subject: RFR: 8365608: Test is skipped without skip exception
 /test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java
In-Reply-To: <81RTa1GhPSbSgtcaHJJjafgj1MvfI10jYGKa8pJnBO8=.febc1fa5-c406-4bed-832d-fec249446a5c@github.com>
References: <pKQHmZhhKAlI92KpUp9NQBxRiNz1Tm0prC5mh2fb5G4=.8ec9f6f6-727f-4530-880a-3a43369437be@github.com>
 <81RTa1GhPSbSgtcaHJJjafgj1MvfI10jYGKa8pJnBO8=.febc1fa5-c406-4bed-832d-fec249446a5c@github.com>
Message-ID: <OyhecatHpDcCevWYoUh95kwLkvUey301MbnCWLaYvho=.96ece716-b874-40a8-a80c-3154fd74dd79@github.com>

On Fri, 15 Aug 2025 18:19:11 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This should be checked in details. Each CA test exercises multiple certificates. Once expired certificate or a network error shouldn't skip the entire test from execution after SkippedException. You should also check CAInterop test as it would also need test/lib dependency.

This review comment is still to be addressed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26804#issuecomment-3438090274

From rhalade at openjdk.org  Thu Oct 23 16:58:49 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 23 Oct 2025 16:58:49 GMT
Subject: RFR: 8361894:
 sun/security/krb5/config/native/TestDynamicStore.java ensure that the test is
 run with sudo [v4]
In-Reply-To: <YzwCd4wKnDsA72Qt4MDm6vFaClBWaMtuYwmWgg7ZYUI=.5e6fca73-8c8e-450e-9755-b8efee16b859@github.com>
References: <78whX4UN6lwESBM5rEK0qXZqt3_zGalKTEkcgWceVn8=.bbae0b43-5a94-491b-93ec-3310236e6b45@github.com>
 <YzwCd4wKnDsA72Qt4MDm6vFaClBWaMtuYwmWgg7ZYUI=.5e6fca73-8c8e-450e-9755-b8efee16b859@github.com>
Message-ID: <LsLnkd4xwp-r1HtNP2n_4dHQg-YxuGIkjEaMzrDuCJ4=.19592956-f643-4873-a627-e6089020d658@github.com>

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

>> sun/security/krb5/config/native/TestDynamicStore.java is commonly run without sudo, which leads to the access related failure. 
>> Added a ui popup reminding to run the test with sudo, making instructions clearer and more noticeable
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26293#pullrequestreview-3371200885

From myankelevich at openjdk.org  Thu Oct 23 17:12:14 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 23 Oct 2025 17:12:14 GMT
Subject: Integrated: 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: <YH2Cn8C2XB8Wln0ExmpfnECSejJiFg6DOx9DQGdBieE=.3bdd1d58-1f4d-44f4-a023-f11d790a2e1c@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.

This pull request has now been integrated.

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

8368982: Test sun/security/tools/jarsigner/EC.java completed and timed out

Reviewed-by: rhalade

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

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

From rhalade at openjdk.org  Thu Oct 23 17:29:51 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 23 Oct 2025 17:29:51 GMT
Subject: RFR: 8366182: Some PKCS11Tests are being skipped when they
 shouldn't [v3]
In-Reply-To: <0MVFVyZ7hY41WsFQptwLnK2rrbnfmLDz55-UBsTf5go=.bbccdd59-67a3-4d8e-a354-fd27d9c9d73a@github.com>
References: <pAO9vS4lx7s-rNl2Qk5TpN_KKnlPXVMmvUhTi4r1WnE=.b1d635c4-a541-4fe7-89a7-ad7faddafff4@github.com>
 <0MVFVyZ7hY41WsFQptwLnK2rrbnfmLDz55-UBsTf5go=.bbccdd59-67a3-4d8e-a354-fd27d9c9d73a@github.com>
Message-ID: <589ONQ3_N53dMNGVs54rXJo7pLqqweW0woOD4WqcKG0=.1f15840c-f65d-4b6d-be88-ceb7738a79ca@github.com>

On Wed, 17 Sep 2025 12:29:36 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates PKCS11 tests to better handle NSS version numbers. The previous code treated the version numbers as double values and used comparison operators. The problem is that it incorrectly treats 3.111 as between 3.11 and 3.12. This update parses and compares the major and minor version numbers separately.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into nss-skipped
>  - refactored to encapsulate the version as a record instead of doing repeated string parsing
>  - 8366182: Some PKCS11Tests are being skipped when they shouldn't

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27095#pullrequestreview-3371448458

From mullan at openjdk.org  Thu Oct 23 18:44:29 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 23 Oct 2025 18:44:29 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in
 java.security.jgss
In-Reply-To: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
Message-ID: <K61DmaA-3X5631fsR6Bjwbhjxb0Fg_YGmGZ2mVnOsd8=.ce1e3244-f5cc-4e28-88c8-c286e9a6f7f7@github.com>

On Wed, 22 Oct 2025 01:10:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.security.jgss module to enable stricter compile-time checking of serialization-related declarations.
> 
> Example of a similar change https://github.com/openjdk/jdk/pull/24891.

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 1:

> 1: /*

The `majorMessage` field of `GSSExceptionImpl` should have `@Serial` too.

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 1:

> 1: /*

Change `java.io.Serial` annotation on `readObject` method to `@Serial`.

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 1:

> 1: /*

The `state` field should also have `@Serial`.

src/java.security.jgss/share/classes/sun/security/krb5/KrbException.java line 45:

> 43:     private static final long serialVersionUID = -4993302876451928596L;
> 44: 
> 45:     private int returnCode;

I think these two fields should also be marked with `@Serial` since they are not `transient`.

src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java line 128:

> 126:     }
> 127: 
> 128:     @Serial

Can you also change `java.io.Serial` to `Serial` on the `readObject` method?

src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 87:

> 85:         @java.io.Serial
> 86:         private static final long serialVersionUID = 0L;
> 87:         private final int errorCode;

`errorCode` should have `@Serial` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2456655753
PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2456663954
PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2456672452
PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2456638167
PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2456621785
PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2456694847

From duke at openjdk.org  Thu Oct 23 19:40:38 2025
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 23 Oct 2025 19:40:38 GMT
Subject: Integrated: 8326609: New AES implementation with updates specified in
 FIPS 197
In-Reply-To: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
References: <T1l_TrhTCKDaysf1mqUaDmgwViPwHWzpydzKr92yybI=.3a331ec2-0343-470f-86ff-cb42dc979417@github.com>
Message-ID: <pnPsOxs9SC5eAXkufc-jBvQTKmjQLAyVTCXU_3oXyOE=.26cff75d-d268-4835-9fa1-b793dc2ae26a@github.com>

On Tue, 14 Oct 2025 19:33:41 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 results:
> 
> i) Default (no JVM options, non-intrinsics) mode:
> 
> a) Encryption:  the new code performed better for b...

This pull request has now been integrated.

Changeset: 62f11cd4
Author:    Shawn M Emery <shawn.emery at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62f11cd4070f21ad82eebbb5319bdbbf4e13f9cf
Stats:     2991 lines in 18 files changed: 1476 ins; 1473 del; 42 mod

8326609: New AES implementation with updates specified in FIPS 197

Reviewed-by: valeriep

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

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

From weijun at openjdk.org  Thu Oct 23 20:47:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 23 Oct 2025 20:47:53 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v8]
In-Reply-To: <vV8yci_2B3kXaY8MfUOf1rPEyz5bqH_308bfOufc-_k=.d3352969-b164-4123-879f-c00b83d06629@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <vV8yci_2B3kXaY8MfUOf1rPEyz5bqH_308bfOufc-_k=.d3352969-b164-4123-879f-c00b83d06629@github.com>
Message-ID: <8o3rhst9M4t_hU0BJrDKWZBmVBSm25bpqjEP-Bm79eU=.47d2288d-704a-491d-bcd5-ea664eddee45@github.com>

On Thu, 23 Oct 2025 04:14:26 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:
> 
>   more doc updates and zeroing

Very minor comments.

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

> 115:  * If an encrypted private key PEM is processed by a decoder not configured
> 116:  * for decryption, an {@link EncryptedPrivateKeyInfo} object is returned.
> 117:  * A PEMDecoder configured for decryption will decode unencrypted PEM.

Put `PEMDecoder` in `{@code}`.

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

> 132:  * }
> 133:  *
> 134:  * @implNote This implementation decodes {@code RSA PRIVATE KEY} as {@code PRIVATE KEY},

Shall we say "decodes as" or "treat the same as"? You decode "RSA PRIVATE KEY" to `PrivateKey` and not "PRIVATE KEY".

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

> 294:      * {@link java.nio.charset.StandardCharsets#UTF_8 UTF-8}.
> 295:      *
> 296:      * @param str a String containing PEM data

`string`, or `{@code String}`. Same for `decode(String, tClass)`.

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

> 329:      * <p> If no PEM data is found, an {@code EOFException} is thrown.
> 330:      *
> 331:      * @param is InputStream containing PEM data

`{@code InputStream}`. Same for the other method.

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

> 362:      * {@link java.nio.charset.StandardCharsets#UTF_8 UTF-8}.
> 363:      *
> 364:      * @param <S> Class type parameter that extends {@code DEREncodable}

Maybe `class`? Same with the other method.

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

> 511:      *
> 512:      * @param provider the factory provider
> 513:      * @return a new PEMDecoder instance configured with the {@code Provider}

`{code PEMDecoder}`. Same with `withDecryption`.

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

> 51:  * <p> Encoding can be performed on cryptographic objects that
> 52:  * implement {@link DEREncodable}. The {@link #encode(DEREncodable)}
> 53:  * and {@link #encodeToString(DEREncodable)} methods encode a DEREncodable

`DEREncodable` should be in `{@code}`.

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

> 52:  * implement {@link DEREncodable}. The {@link #encode(DEREncodable)}
> 53:  * and {@link #encodeToString(DEREncodable)} methods encode a DEREncodable
> 54:  * into PEM and return the data in a byte array or String.

If `String`, put in `{@code}`; or, `string`.

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

PR Review: https://git.openjdk.org/jdk/pull/27147#pullrequestreview-3372477930
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2457223956
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2457229113
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2457235405
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2457250468
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2457257641
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2457263167
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2457168711
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2457172299

From wetmore at openjdk.org  Thu Oct 23 20:50:34 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 23 Oct 2025 20:50:34 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v9]
In-Reply-To: <NC4G6B4KghscpwWOEFOmbzNp7nGRkiFr-9BLA6GKTdg=.2870d74f-683d-4ab2-8692-f7cbc3246b0e@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <NC4G6B4KghscpwWOEFOmbzNp7nGRkiFr-9BLA6GKTdg=.2870d74f-683d-4ab2-8692-f7cbc3246b0e@github.com>
Message-ID: <ccZpGrFwIHSlDyt-fNEOTBxQynMvR3iusjpi7w_3TS4=.95b3cec4-4a79-4cec-88c7-3ea783c2b8d2@github.com>

On Wed, 22 Oct 2025 14:06:12 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:
> 
>   line length changed

Some issues to address, thanks.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 256:

> 254:                  NumberFormatException |
> 255:                  NoSuchAlgorithmException |
> 256:                  IndexOutOfBoundsException e) {

I always worry about enumerating all possible checked exceptions, as we might now start throwing new `RuntimeException`s that were previously caught/ignored.  Was there a reason to drive the change to all checked?

More importantly, will this change now cause new behavior due to RTEs?

test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 103:

> 101:         final X509KeyManager km = generateNullKm();
> 102: 
> 103:         km.getServerAliases(null, null);

I know that this section is not part of this change, but shouldn't we be testing that all these are indeed returning null?  

It's done in spots later on, but I feel it should be done here also to test all of the APIs.

test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 203:

> 201:                         "Should return null if the alias is invalid <%s>",
> 202:                         alias));
> 203:     }

Based on the description of the bug, I was expecting to see checking of the debug output (`Implement extra logging...`), but appears that this is not the primary focus.  Maybe change the ordering of the bug description.  (`...and also implement extra logging`)

test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 70:

> 68: 
> 69:         exceptionThrowingKMF
> 70:                 .init((KeyStore) exceptionThrowingKS, null);

This cast seems unnecessary.

(Test runs without it.)

test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 83:

> 81:     @Test
> 82:     public void ksExceptionTest() {
> 83:         // recording logs to the output stream

I don't understand this comment.  There doesn't seem to be any recording to the debug log stream in this test.

test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 103:

> 101:         @Override
> 102:         public KeyStore.Entry engineGetEntry(String alias,
> 103:                                              KeyStore.ProtectionParameter param) {

A line <= 80. 

All the other lines are fine, thanks!

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

Changes requested by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27851#pullrequestreview-3372319617
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2457035908
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2457098558
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2457170495
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2457180801
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2457249393
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2457206166

From serb at openjdk.org  Thu Oct 23 21:57:23 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Oct 2025 21:57:23 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in
 java.security.jgss [v2]
In-Reply-To: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
Message-ID: <Q-FpZSpNqYRmUZIBxetzDn5O7Imhs-yp0DUpJRfq3w0=.6720149f-88bb-4844-a2b0-82131a6d5248@github.com>

> Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.security.jgss module to enable stricter compile-time checking of serialization-related declarations.
> 
> Example of a similar change https://github.com/openjdk/jdk/pull/24891.

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

 - Merge branch 'openjdk:master' into JDK-8370368
 - 8370368: Apply java.io.Serial annotations in java.security.jgss

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27925/files
  - new: https://git.openjdk.org/jdk/pull/27925/files/71c9c1c8..a410e847

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

  Stats: 9837 lines in 174 files changed: 6123 ins; 2537 del; 1177 mod
  Patch: https://git.openjdk.org/jdk/pull/27925.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27925/head:pull/27925

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

From abarashev at openjdk.org  Thu Oct 23 22:00:16 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 23 Oct 2025 22:00:16 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object returned
 by SSLConfiguration#getSSLParameters() call
Message-ID: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>

We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call:
- For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
- namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters.

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

Commit messages:
 - 8366364: Address inconsistencies in SSLParameters object returned by SSLConfiguration#getSSLParameters() call

Changes: https://git.openjdk.org/jdk/pull/27961/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27961&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366364
  Stats: 108 lines in 10 files changed: 47 ins; 35 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/27961.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27961/head:pull/27961

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

From serb at openjdk.org  Thu Oct 23 22:38:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Oct 2025 22:38:21 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in
 java.security.jgss [v3]
In-Reply-To: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
Message-ID: <JJ7uv6KuVPR6vkRX_hgY7mlA8xVFoLPxZm99GIEVFGs=.0efd6185-d988-42e6-91a5-1e061e7f6d8a@github.com>

> Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.security.jgss module to enable stricter compile-time checking of serialization-related declarations.
> 
> Example of a similar change https://github.com/openjdk/jdk/pull/24891.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Replace java.io.Serial annotations with @Serial

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27925/files
  - new: https://git.openjdk.org/jdk/pull/27925/files/a410e847..89b4abe2

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

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

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

From serb at openjdk.org  Thu Oct 23 22:38:23 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Oct 2025 22:38:23 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in
 java.security.jgss [v3]
In-Reply-To: <K61DmaA-3X5631fsR6Bjwbhjxb0Fg_YGmGZ2mVnOsd8=.ce1e3244-f5cc-4e28-88c8-c286e9a6f7f7@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
 <K61DmaA-3X5631fsR6Bjwbhjxb0Fg_YGmGZ2mVnOsd8=.ce1e3244-f5cc-4e28-88c8-c286e9a6f7f7@github.com>
Message-ID: <rfWodps5xazwF4gEHNPq57xzRkF4h2y665JJupafG78=.be08cb2c-beb5-409b-a2be-085ae8ea2f3f@github.com>

On Thu, 23 Oct 2025 18:23:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace java.io.Serial annotations with @Serial
>
> src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java line 128:
> 
>> 126:     }
>> 127: 
>> 128:     @Serial
> 
> Can you also change `java.io.Serial` to `Serial` on the `readObject` method?

done

> `errorCode` should have `@Serial` too.

I think you may have confused it with the `@serial` tag in Javadoc. This annotation can be applied to these methods/fields.
  * private void writeObject(java.io.ObjectOutputStream stream) throws IOException
  * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
  * private void readObjectNoData() throws ObjectStreamException 
   * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
   * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
   * private static final ObjectStreamField[] serialPersistentFields
   * private static final long serialVersionUID

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2457693746
PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2457684126

From mullan at openjdk.org  Thu Oct 23 22:55:01 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 23 Oct 2025 22:55:01 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in
 java.security.jgss [v3]
In-Reply-To: <JJ7uv6KuVPR6vkRX_hgY7mlA8xVFoLPxZm99GIEVFGs=.0efd6185-d988-42e6-91a5-1e061e7f6d8a@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
 <JJ7uv6KuVPR6vkRX_hgY7mlA8xVFoLPxZm99GIEVFGs=.0efd6185-d988-42e6-91a5-1e061e7f6d8a@github.com>
Message-ID: <Zit7cLXz297G0BXV_fhZ68sQ62zbitHl5UdI8ynbyXs=.7debe54b-8941-4bef-8c8d-1e9631ebaac8@github.com>

On Thu, 23 Oct 2025 22:38:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.security.jgss module to enable stricter compile-time checking of serialization-related declarations.
>> 
>> Example of a similar change https://github.com/openjdk/jdk/pull/24891.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace java.io.Serial annotations with @Serial

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27925#pullrequestreview-3373197784

From mullan at openjdk.org  Thu Oct 23 22:55:02 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 23 Oct 2025 22:55:02 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in
 java.security.jgss [v3]
In-Reply-To: <hMr2cFnMzgjltLqXlS3b8OpknqdnpS-fXKS5vRhgzYs=.790c6dbe-d65d-4f6f-81e0-93a96cf57c26@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
 <K61DmaA-3X5631fsR6Bjwbhjxb0Fg_YGmGZ2mVnOsd8=.ce1e3244-f5cc-4e28-88c8-c286e9a6f7f7@github.com>
 <rfWodps5xazwF4gEHNPq57xzRkF4h2y665JJupafG78=.be08cb2c-beb5-409b-a2be-085ae8ea2f3f@github.com>
 <hMr2cFnMzgjltLqXlS3b8OpknqdnpS-fXKS5vRhgzYs=.790c6dbe-d65d-4f6f-81e0-93a96cf57c26@github.com>
Message-ID: <DBTyxm4O0-8HBn4Wwr3CTOh-I9lXjzw9r0SCj2EdQkQ=.e153afe2-067c-4967-a930-acec2a7b43f7@github.com>

On Thu, 23 Oct 2025 22:47:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> `errorCode` should have `@Serial` too.
>> 
>> I think you may have confused it with the `@serial` tag in Javadoc. This annotation can be applied to these methods/fields.
>>   * private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>>   * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>>   * private void readObjectNoData() throws ObjectStreamException 
>>    * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>>    * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>>    * private static final ObjectStreamField[] serialPersistentFields
>>    * private static final long serialVersionUID
>
> Yes, you are right, easy to mistake those two since they have the same name!

Since these are internal classes, I guess it is ok if the fields don't have the serial javadoc tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2457759976

From mullan at openjdk.org  Thu Oct 23 22:51:04 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 23 Oct 2025 22:51:04 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in
 java.security.jgss [v3]
In-Reply-To: <rfWodps5xazwF4gEHNPq57xzRkF4h2y665JJupafG78=.be08cb2c-beb5-409b-a2be-085ae8ea2f3f@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
 <K61DmaA-3X5631fsR6Bjwbhjxb0Fg_YGmGZ2mVnOsd8=.ce1e3244-f5cc-4e28-88c8-c286e9a6f7f7@github.com>
 <rfWodps5xazwF4gEHNPq57xzRkF4h2y665JJupafG78=.be08cb2c-beb5-409b-a2be-085ae8ea2f3f@github.com>
Message-ID: <hMr2cFnMzgjltLqXlS3b8OpknqdnpS-fXKS5vRhgzYs=.790c6dbe-d65d-4f6f-81e0-93a96cf57c26@github.com>

On Thu, 23 Oct 2025 22:33:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Ktab.java line 87:
>> 
>>> 85:         @java.io.Serial
>>> 86:         private static final long serialVersionUID = 0L;
>>> 87:         private final int errorCode;
>> 
>> `errorCode` should have `@Serial` too.
>
>> `errorCode` should have `@Serial` too.
> 
> I think you may have confused it with the `@serial` tag in Javadoc. This annotation can be applied to these methods/fields.
>   * private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>   * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>   * private void readObjectNoData() throws ObjectStreamException 
>    * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>    * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>    * private static final ObjectStreamField[] serialPersistentFields
>    * private static final long serialVersionUID

Yes, you are right, easy to mistake those two since they have the same name!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27925#discussion_r2457745621

From ascarpino at openjdk.org  Fri Oct 24 01:03:50 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 24 Oct 2025 01:03:50 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v9]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <y2KnmUaLcyy8vhXQML_9Uo3lFm9txO52n9nfMwMI4hE=.1d7a6699-87c8-48fb-9078-91769251fbc5@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:

  docs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/45f30dd3..682bfa17

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

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

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

From ascarpino at openjdk.org  Fri Oct 24 01:58:44 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 24 Oct 2025 01:58:44 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v10]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <vC7VcLCn2inzJExAT6CcI0hLGqaKoSXW-dnrcnP6fc4=.725d6fb4-38ac-4042-9393-8cdd7925b21a@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:

  EKPI has a lot of @link's

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/682bfa17..e08d0626

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

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

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

From ascarpino at openjdk.org  Fri Oct 24 03:53:08 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 24 Oct 2025 03:53:08 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v8]
In-Reply-To: <8o3rhst9M4t_hU0BJrDKWZBmVBSm25bpqjEP-Bm79eU=.47d2288d-704a-491d-bcd5-ea664eddee45@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <vV8yci_2B3kXaY8MfUOf1rPEyz5bqH_308bfOufc-_k=.d3352969-b164-4123-879f-c00b83d06629@github.com>
 <8o3rhst9M4t_hU0BJrDKWZBmVBSm25bpqjEP-Bm79eU=.47d2288d-704a-491d-bcd5-ea664eddee45@github.com>
Message-ID: <E4pckp7_wNAuWONvOG4sZwcbS6nZ20cCMKMWlsgRtb8=.9edccba9-473b-47d3-9be5-424f35a7a6fa@github.com>

On Thu, 23 Oct 2025 20:36:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more doc updates and zeroing
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 134:
> 
>> 132:  * }
>> 133:  *
>> 134:  * @implNote This implementation decodes {@code RSA PRIVATE KEY} as {@code PRIVATE KEY},
> 
> Shall we say "decodes as" or "treat the same as"? You decode "RSA PRIVATE KEY" to `PrivateKey` and not "PRIVATE KEY".

I think the list is incorrect.  It should not have @code for the types, as I don't do that anywhere else.  Also, the "as" should be the class, not the other type.

> src/java.base/share/classes/java/security/PEMEncoder.java line 53:
> 
>> 51:  * <p> Encoding can be performed on cryptographic objects that
>> 52:  * implement {@link DEREncodable}. The {@link #encode(DEREncodable)}
>> 53:  * and {@link #encodeToString(DEREncodable)} methods encode a DEREncodable
> 
> `DEREncodable` should be in `{@code}`.

I think it's useful here to have a link because it is mentioned in the methods in the next sentence and below in the tables.  Similar to PEMDecoder has a link before the table.

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

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

From fandreuzzi at openjdk.org  Fri Oct 24 08:36:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 24 Oct 2025 08:36:02 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call
In-Reply-To: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
Message-ID: <N4MQAuTWgcpTT0A4eGD14obftuvMFNEf9ulmqMUDxe4=.a967adf1-f43c-4ebc-a417-9bc088621256@github.com>

On Thu, 23 Oct 2025 21:54:24 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call:
> - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
> - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters.

src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 422:

> 420:                         || config.signatureSchemes == null ?
> 421:                     Arrays.asList(SignatureScheme.values()) :
> 422:                         Arrays.stream(config.signatureSchemes)

The formatting makes this assignment a bit hard to follow. Perhaps a simple `if` statement would behave better?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2459322058

From pminborg at openjdk.org  Fri Oct 24 08:51:06 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 24 Oct 2025 08:51:06 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: <Xt4EoyR6z7N1QZnAKFvO-Q-OXmGep73BQfqdPFshot0=.681078bf-3473-4f12-a505-62d1a2d14914@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

After some discussion, we have concluded that we need to rework how `toString()` works for `LazyConstant`, lazy maps, and lists:

#### For `LazyConstant`
In order to align with other comput-later constructs like `Future`, we'd like to provide something like this:

java.lang.LazyConstant at 5ed828d[computing function = $Lambda/0x00000ffe000d6550 at 4d3167f4]  // Uninitialized
java.lang.LazyConstant at 4ad92aa[42] // Initialized


#### For lazy list, map, and all their derivatives (e.g., `subList()`, `values()`)
There is a tension between the willingness to keep the `toString()` methods lazy during debugging and the compatibility with the existing `List` and `Map` implementations.  It would be very surprising if a lazy list would output something different from a normal list for `toString()`.  We think it is more important that lazy constructs are compatible with their corresponding eager constructs. Hence, we propose to make `toString()` trigger initialization of all elements/values.

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

PR Comment: https://git.openjdk.org/jdk/pull/27605#issuecomment-3441894953

From pminborg at openjdk.org  Fri Oct 24 09:01:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 24 Oct 2025 09:01:10 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
Message-ID: <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@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:

  Rework toString implementations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27605/files
  - new: https://git.openjdk.org/jdk/pull/27605/files/6721ca4a..c3278e0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27605&range=18-19

  Stats: 271 lines in 5 files changed: 27 ins; 211 del; 33 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 24 09:17:19 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 24 Oct 2025 09:17:19 GMT
Subject: Integrated: 8361894:
 sun/security/krb5/config/native/TestDynamicStore.java ensure that the test is
 run with sudo
In-Reply-To: <78whX4UN6lwESBM5rEK0qXZqt3_zGalKTEkcgWceVn8=.bbae0b43-5a94-491b-93ec-3310236e6b45@github.com>
References: <78whX4UN6lwESBM5rEK0qXZqt3_zGalKTEkcgWceVn8=.bbae0b43-5a94-491b-93ec-3310236e6b45@github.com>
Message-ID: <yWAz3U07QM2zIHQQEtfqk9IlC0xou_5pbXoQxLS9EOI=.fa435c9d-c1a1-47be-b564-aeb0d5735341@github.com>

On Mon, 14 Jul 2025 12:53:55 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> sun/security/krb5/config/native/TestDynamicStore.java is commonly run without sudo, which leads to the access related failure. 
> Added a ui popup reminding to run the test with sudo, making instructions clearer and more noticeable

This pull request has now been integrated.

Changeset: f73e56e2
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f73e56e24f0edfaeb99e2106a56725ea033bd6d6
Stats:     15 lines in 1 file changed: 13 ins; 0 del; 2 mod

8361894: sun/security/krb5/config/native/TestDynamicStore.java ensure that the test is run with sudo

Reviewed-by: rhalade

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

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

From djelinski at openjdk.org  Fri Oct 24 09:20:16 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 24 Oct 2025 09:20:16 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v9]
In-Reply-To: <ccZpGrFwIHSlDyt-fNEOTBxQynMvR3iusjpi7w_3TS4=.95b3cec4-4a79-4cec-88c7-3ea783c2b8d2@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <NC4G6B4KghscpwWOEFOmbzNp7nGRkiFr-9BLA6GKTdg=.2870d74f-683d-4ab2-8692-f7cbc3246b0e@github.com>
 <ccZpGrFwIHSlDyt-fNEOTBxQynMvR3iusjpi7w_3TS4=.95b3cec4-4a79-4cec-88c7-3ea783c2b8d2@github.com>
Message-ID: <qgksSRtmfs1b0C8SKQTSbmqmUmComdwauRkw4P5hvS8=.322bc1d4-0e92-4482-ac6b-5b0352acffe1@github.com>

On Thu, 23 Oct 2025 19:53:12 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   line length changed
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 256:
> 
>> 254:                  NumberFormatException |
>> 255:                  NoSuchAlgorithmException |
>> 256:                  IndexOutOfBoundsException e) {
> 
> I always worry about enumerating all possible checked exceptions, as we might now start throwing new `RuntimeException`s that were previously caught/ignored.  Was there a reason to drive the change to all checked?
> 
> More importantly, will this change now cause new behavior due to RTEs?

Are you more interested in practical or dogmatic reasons?

For practical reasons, see [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667); there was a bug in Keystore implementation that was hidden by this catch block, and impossible to investigate without changing it.

For dogmatic, see our own secure coding guidelines, point 1-4 Implement robust exception handling. KeyManager is not equipped to handle the runtime exceptions thrown by KeyStores and Builders, and should propagate these exceptions to the caller instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2459467367

From myankelevich at openjdk.org  Fri Oct 24 10:07:15 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 24 Oct 2025 10:07:15 GMT
Subject: RFR: 8369995: Implement extra logging and/or propagate errors in
 X509KeyManagerImpl and fix StringIndexOutOfBoundsException [v9]
In-Reply-To: <ccZpGrFwIHSlDyt-fNEOTBxQynMvR3iusjpi7w_3TS4=.95b3cec4-4a79-4cec-88c7-3ea783c2b8d2@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <NC4G6B4KghscpwWOEFOmbzNp7nGRkiFr-9BLA6GKTdg=.2870d74f-683d-4ab2-8692-f7cbc3246b0e@github.com>
 <ccZpGrFwIHSlDyt-fNEOTBxQynMvR3iusjpi7w_3TS4=.95b3cec4-4a79-4cec-88c7-3ea783c2b8d2@github.com>
Message-ID: <dt1-bidINMuFRgmJJxRETbUDeAt0huS0QFShy0PxYKw=.b5b72e6a-7797-43da-b91b-aaf366361116@github.com>

On Thu, 23 Oct 2025 20:06:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   line length changed
>
> test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 103:
> 
>> 101:         final X509KeyManager km = generateNullKm();
>> 102: 
>> 103:         km.getServerAliases(null, null);
> 
> I know that this section is not part of this change, but shouldn't we be testing that all these are indeed returning null?  
> 
> It's done in spots later on, but I feel it should be done here also to test all of the APIs.

I don't think this test focuses on this, but in any case it's easy to add a null verification, so I think it would be better to have it. Done in the next commit

> test/jdk/sun/security/ssl/X509KeyManager/NullCases.java line 203:
> 
>> 201:                         "Should return null if the alias is invalid <%s>",
>> 202:                         alias));
>> 203:     }
> 
> Based on the description of the bug, I was expecting to see checking of the debug output (`Implement extra logging...`), but appears that this is not the primary focus.  Maybe change the ordering of the bug description.  (`...and also implement extra logging`)

I have removed log verification from the tests. I agree, changing the title might be a good idea

> test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 70:
> 
>> 68: 
>> 69:         exceptionThrowingKMF
>> 70:                 .init((KeyStore) exceptionThrowingKS, null);
> 
> This cast seems unnecessary.
> 
> (Test runs without it.)

Yes, I've removed it in the next commit, thanks.

> test/jdk/sun/security/ssl/X509KeyManager/X509KeyManagerNegativeTests.java line 83:
> 
>> 81:     @Test
>> 82:     public void ksExceptionTest() {
>> 83:         // recording logs to the output stream
> 
> I don't understand this comment.  There doesn't seem to be any recording to the debug log stream in this test.

That's a typo, I have modified a test which used to verify logs. Removed in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2459620637
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2459632554
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2459627208
PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2459636148

From myankelevich at openjdk.org  Fri Oct 24 10:13:48 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 24 Oct 2025 10:13:48 GMT
Subject: RFR: 8369995: Fix StringIndexOutOfBoundsException and implement
 extra logging and/or propagate errors in X509KeyManagerImpl [v10]
In-Reply-To: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
Message-ID: <Vq5Kjqa5Kn3VqYLFdiK4DyrnCScRhk64g4TUj0JpPu8=.c9f46612-8e75-415a-a268-9c18cb6b874f@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:

  Bradford's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27851/files
  - new: https://git.openjdk.org/jdk/pull/27851/files/92486022..c23a0a4f

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

  Stats: 31 lines in 2 files changed: 21 ins; 2 del; 8 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 mdonovan at openjdk.org  Fri Oct 24 11:14:12 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 24 Oct 2025 11:14:12 GMT
Subject: Integrated: 8366182: Some PKCS11Tests are being skipped when they
 shouldn't
In-Reply-To: <pAO9vS4lx7s-rNl2Qk5TpN_KKnlPXVMmvUhTi4r1WnE=.b1d635c4-a541-4fe7-89a7-ad7faddafff4@github.com>
References: <pAO9vS4lx7s-rNl2Qk5TpN_KKnlPXVMmvUhTi4r1WnE=.b1d635c4-a541-4fe7-89a7-ad7faddafff4@github.com>
Message-ID: <-Tn2QKknJUIqDnUO2WZlGyk4iIIZoTKD1PW-KWPUCQU=.83ba1650-0ea8-4c94-a1b7-7161b7b55aaf@github.com>

On Thu, 4 Sep 2025 13:59:22 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates PKCS11 tests to better handle NSS version numbers. The previous code treated the version numbers as double values and used comparison operators. The problem is that it incorrectly treats 3.111 as between 3.11 and 3.12. This update parses and compares the major and minor version numbers separately.

This pull request has now been integrated.

Changeset: cc9483b4
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc9483b4da1a0f65f8773d0c7f35f2e6a7e1bd4f
Stats:     92 lines in 6 files changed: 27 ins; 19 del; 46 mod

8366182: Some PKCS11Tests are being skipped when they shouldn't

Reviewed-by: rhalade

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

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

From weijun at openjdk.org  Fri Oct 24 11:58:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 24 Oct 2025 11:58:09 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v8]
In-Reply-To: <E4pckp7_wNAuWONvOG4sZwcbS6nZ20cCMKMWlsgRtb8=.9edccba9-473b-47d3-9be5-424f35a7a6fa@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <vV8yci_2B3kXaY8MfUOf1rPEyz5bqH_308bfOufc-_k=.d3352969-b164-4123-879f-c00b83d06629@github.com>
 <8o3rhst9M4t_hU0BJrDKWZBmVBSm25bpqjEP-Bm79eU=.47d2288d-704a-491d-bcd5-ea664eddee45@github.com>
 <E4pckp7_wNAuWONvOG4sZwcbS6nZ20cCMKMWlsgRtb8=.9edccba9-473b-47d3-9be5-424f35a7a6fa@github.com>
Message-ID: <INYxwoIoS72X1oN2ET_bllWs_5Zl41O1x5MxuWSzNjA=.edca497e-5191-4691-a78a-a0ade7b65878@github.com>

On Thu, 23 Oct 2025 22:19:09 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/PEMEncoder.java line 53:
>> 
>>> 51:  * <p> Encoding can be performed on cryptographic objects that
>>> 52:  * implement {@link DEREncodable}. The {@link #encode(DEREncodable)}
>>> 53:  * and {@link #encodeToString(DEREncodable)} methods encode a DEREncodable
>> 
>> `DEREncodable` should be in `{@code}`.
>
> I think it's useful here to have a link because it is mentioned in the methods in the next sentence and below in the tables.  Similar to PEMDecoder has a link before the table.

Oh, I meant the one at the end of line 53.

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

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

From weijun at openjdk.org  Fri Oct 24 15:48:39 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 24 Oct 2025 15:48:39 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v10]
In-Reply-To: <vC7VcLCn2inzJExAT6CcI0hLGqaKoSXW-dnrcnP6fc4=.725d6fb4-38ac-4042-9393-8cdd7925b21a@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <vC7VcLCn2inzJExAT6CcI0hLGqaKoSXW-dnrcnP6fc4=.725d6fb4-38ac-4042-9393-8cdd7925b21a@github.com>
Message-ID: <S1AhsMwbwAltU0h3tshYoviTHmLbYUbJ9zWj7nDnZUs=.623c54ee-28dc-49c2-86ee-0e71448210c6@github.com>

On Fri, 24 Oct 2025 01:58:44 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:
> 
>   EKPI has a lot of @link's

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

> 496:             throw new IllegalArgumentException(e);
> 497:         } catch (IllegalBlockSizeException | BadPaddingException |
> 498:                  InvalidKeyException e) {

In the `encrypt(de, key,...)` API, you said IAE is thrown if the key is invalid. But here `InvalidKeyException` ends up with a RE.

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

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

From wetmore at openjdk.org  Fri Oct 24 16:43:07 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 24 Oct 2025 16:43:07 GMT
Subject: RFR: 8369995: Fix StringIndexOutOfBoundsException and implement
 extra logging and/or propagate errors in X509KeyManagerImpl [v9]
In-Reply-To: <qgksSRtmfs1b0C8SKQTSbmqmUmComdwauRkw4P5hvS8=.322bc1d4-0e92-4482-ac6b-5b0352acffe1@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <NC4G6B4KghscpwWOEFOmbzNp7nGRkiFr-9BLA6GKTdg=.2870d74f-683d-4ab2-8692-f7cbc3246b0e@github.com>
 <ccZpGrFwIHSlDyt-fNEOTBxQynMvR3iusjpi7w_3TS4=.95b3cec4-4a79-4cec-88c7-3ea783c2b8d2@github.com>
 <qgksSRtmfs1b0C8SKQTSbmqmUmComdwauRkw4P5hvS8=.322bc1d4-0e92-4482-ac6b-5b0352acffe1@github.com>
Message-ID: <p3dFgABIrGO2TOjMc996UpoawxOFpI9QZxV4EKcW6iY=.d0118970-baa6-4051-bca4-08f3eddeafc1@github.com>

On Fri, 24 Oct 2025 09:17:59 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 256:
>> 
>>> 254:                  NumberFormatException |
>>> 255:                  NoSuchAlgorithmException |
>>> 256:                  IndexOutOfBoundsException e) {
>> 
>> I always worry about enumerating all possible checked exceptions, as we might now start throwing new `RuntimeException`s that were previously caught/ignored.  Was there a reason to drive the change to all checked?
>> 
>> More importantly, will this change now cause new behavior due to RTEs?
>
> Are you more interested in practical or dogmatic reasons?
> 
> For practical reasons, see [JDK-8309667](https://bugs.openjdk.org/browse/JDK-8309667); there was a bug in Keystore implementation that was hidden by this catch block, and impossible to investigate without changing it.
> 
> For dogmatic, see our own secure coding guidelines, point 1-4 Implement robust exception handling. KeyManager is not equipped to handle the runtime exceptions thrown by KeyStores and Builders, and should propagate these exceptions to the caller instead.

Ok, comment withdrawn.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27851#discussion_r2461248831

From wetmore at openjdk.org  Fri Oct 24 17:15:07 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 24 Oct 2025 17:15:07 GMT
Subject: RFR: 8369995: Fix StringIndexOutOfBoundsException and implement
 extra logging and/or propagate errors in X509KeyManagerImpl [v10]
In-Reply-To: <Vq5Kjqa5Kn3VqYLFdiK4DyrnCScRhk64g4TUj0JpPu8=.c9f46612-8e75-415a-a268-9c18cb6b874f@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <Vq5Kjqa5Kn3VqYLFdiK4DyrnCScRhk64g4TUj0JpPu8=.c9f46612-8e75-415a-a268-9c18cb6b874f@github.com>
Message-ID: <ccObPsYSs8EnJ3lQkjyq0PoH3Nnm51Jlj279tZAD-9U=.52208357-c1a8-436b-8d85-03590e6cced4@github.com>

On Fri, 24 Oct 2025 10:13:48 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:
> 
>   Bradford's comments

LGTM.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27851#pullrequestreview-3377942776

From ascarpino at openjdk.org  Fri Oct 24 19:06:33 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 24 Oct 2025 19:06:33 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v11]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@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:

  more docs, remove runtimeexception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/e08d0626..4bf48dda

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

  Stats: 18 lines in 2 files changed: 1 ins; 6 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27147.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27147/head:pull/27147

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

From abarashev at openjdk.org  Fri Oct 24 19:36:01 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 24 Oct 2025 19:36:01 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call
In-Reply-To: <N4MQAuTWgcpTT0A4eGD14obftuvMFNEf9ulmqMUDxe4=.a967adf1-f43c-4ebc-a417-9bc088621256@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <N4MQAuTWgcpTT0A4eGD14obftuvMFNEf9ulmqMUDxe4=.a967adf1-f43c-4ebc-a417-9bc088621256@github.com>
Message-ID: <K25PS7HUljJdbFuEEWelhd_VL0uGzZZ7GOFbdqryDIw=.0de87783-6af7-4179-839b-66c86fee9c01@github.com>

On Fri, 24 Oct 2025 08:33:30 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call:
>> - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
>> - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters.
>
> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 422:
> 
>> 420:                         || config.signatureSchemes == null ?
>> 421:                     Arrays.asList(SignatureScheme.values()) :
>> 422:                         Arrays.stream(config.signatureSchemes)
> 
> The formatting makes this assignment a bit hard to follow. Perhaps a simple `if` statement would behave better?

Indeed, replaced with `if-else` statement. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2461766887

From mpowers at openjdk.org  Fri Oct 24 19:48:27 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 24 Oct 2025 19:48:27 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v14]
In-Reply-To: <OlQ2AorM5A70wgd5FxTHtuAYjqiQa_FWSU-9sjsiba4=.c9407e11-9f4d-4e8d-86cf-5e87d6750401@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <HgRaTELVlUrwHDlYHEg-991pzPoORrq9w2rbyRj9sCM=.3671e28b-94bd-4447-a6e1-c3cde3e20fb3@github.com>
 <OlQ2AorM5A70wgd5FxTHtuAYjqiQa_FWSU-9sjsiba4=.c9407e11-9f4d-4e8d-86cf-5e87d6750401@github.com>
Message-ID: <xp9tPLejseMbmNZRnzuihxRigyV7HKkOwhKF8HOWFo0=.a5a6f128-58f6-405e-be3c-aa0afb13e09c@github.com>

On Thu, 23 Oct 2025 14:20:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
>> 
>>  - merge
>>  - stragglers
>>  - checkpoint
>>  - remaining comments
>>  - more review comments from Sean and Weijun
>>  - more review comments from Weijun and Sean
>>  - another day another iteration
>>  - move algorithm-specific code into MacData and no change to SunJCE
>>  - fix behavior with keytool
>>  - default salt length and one other comment from Weijun
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/d8ebe387...8f0b0d02
>
> src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java line 309:
> 
>> 307:         pBES2_params.write(DerValue.tag_Sequence,
>> 308:                 // keysize encoded as octets
>> 309:                 PBKDF2Parameters.encode(salt, iCount, keysize/8, kdfAlgo_OID));
> 
> If you make the change I suggested in `PBKDF2Parameters.encode`, the line above should be
> 
> pBES2_params.writeBytes(PBKDF2Parameters.encode(salt, iCount, keysize/8, kdfAlgo_OID));

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 1:
> 
>> 1: /*
> 
> In this class, there are several places where `startsWith("pbewith")` is called. Add a comment to the method that the algorithm names are guaranteed to be using lowercase letters (at least for the prefix).

fixed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 160:
> 
>> 158:             keySpec = new PBEKeySpec(password);
>> 159:         }
>> 160:         pbeKey = skf.generateSecret(keySpec);
> 
> If the line above fails, there is no chance to clean `keySpec`. Create a big try-finally block.

I assume you mean to put line 160 in the existing try-finally block rather than create another try-finally block just for this.

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 170:
> 
>> 168:         } finally {
>> 169:             keySpec.clearPassword();
>> 170:             sun.security.util.KeyUtil.destroySecretKeys(pbeKey);
> 
> Here, `pbeKey` is cleared before `m.update` and `m.doFinal` are called. This might be unsafe because `m` could be still using `pbeKey`.

Putting `m.update` and `m.doFinal` into the existing try-finally block.

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 248:
> 
>> 246:     }
>> 247: 
>> 248:     byte[] getSalt() {
> 
> This method is not used anywhere.

removed

> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 257:
> 
>> 255: 
>> 256:     /**
>> 257:      * Returns the ASN.1 encoding of this object.
> 
> This is a `static` method. There is no "this object".

Duh! Fixed.

> src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 136:
> 
>> 134:         // keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}}
>> 135:         tmp3.write(DerValue.tag_Sequence, PBKDF2Parameters.encode(salt,
>> 136:                 iterationCount, keyLength, kdfHmac));
> 
> If you make the change I suggested in `PBKDF2Parameters.encode`, the line above should be
> 
> tmp3.writeBytes(PBKDF2Parameters.encode(salt,
>                  iterationCount, keyLength, kdfHmac));

fixed

> src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 137:
> 
>> 135:         tmp3.write(DerValue.tag_Sequence, PBKDF2Parameters.encode(salt,
>> 136:                 iterationCount, keyLength, kdfHmac));
>> 137:         tmp3.write(DerValue.tag_Sequence, tmp4);
> 
> Now that Koushik's JDK-8367008 has been integrated, there is no need to construct `tmp4`. Just call `tmp3.write(AlgorithmId.get(hmac))`. It's OK for this method to throw a NSAE.

Good idea. Fixed.

> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 353:
> 
>> 351:                     cipher.init(Cipher.DECRYPT_MODE, skey, algParams);
>> 352:                 } finally {
>> 353:                     sun.security.util.KeyUtil.destroySecretKeys(skey);
> 
> No need for the package name `sun.security.util.KeyUtil`. All classes have already been imported. The are several such cases in this file and one in `MacData`.

fixed

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 162:
> 
>> 160:         tmp0.putInteger(iterationCount);
>> 161:         tmp0.putInteger(keyLength);
>> 162:         tmp0.write(DerValue.tag_Sequence, tmp1);
> 
> After Koushik's JDK-8367008, no need for `tmp1`. This can be just `tmp0.write(new AlgorithmId(prf))`.

fixed

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 168:
> 
>> 166:         out.write(DerValue.tag_Sequence, tmp0);
>> 167: 
>> 168:         return out.toByteArray();
> 
> `out` is just a concatenation of OID and `tmp0`, which needs to be wrapped inside an ASN.1 SEQUENCE. The return value should be
> 
> new DerOutputStream().write(DerValue.tag_Sequence, out).toByteArray();
> 
> 
> This makes sure the output of `encode` is the same as the input of the `new PBKDF2Parameters()` constructor.
> 
> Once this is updated, the other places that call `encode` do not need to add the ASN.1 SEQUENCE wrapper.

fixed

> src/java.base/share/conf/security/java.security line 1344:
> 
>> 1342: 
>> 1343: # The algorithm used to calculate the optional MacData at the end of a PKCS12
>> 1344: # file. This can be any HmacPBE or PBEWith<mac> algorithm defined in the
> 
> I know `HmacPBE` has been like this from the beginning, but to be consistent and precise, suggest changing it to `HmacPBE<digest>`.

Good Idea. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461790972
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461793840
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461788435
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461788610
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461788819
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461793450
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461791388
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461788952
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461789192
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461789643
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461790340
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2461794211

From abarashev at openjdk.org  Fri Oct 24 19:49:37 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 24 Oct 2025 19:49:37 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v2]
In-Reply-To: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
Message-ID: <Ib206yfUnRihalo93BAx5k96mIpUokXh4ljQa_j1hRY=.9b6af308-0fe0-4d43-96bb-b6b68715174d@github.com>

> We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call:
> - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
> - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Adjust formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27961/files
  - new: https://git.openjdk.org/jdk/pull/27961/files/6540317b..ecc95437

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

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

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

From weijun at openjdk.org  Fri Oct 24 21:47:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 24 Oct 2025 21:47:12 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v14]
In-Reply-To: <xp9tPLejseMbmNZRnzuihxRigyV7HKkOwhKF8HOWFo0=.a5a6f128-58f6-405e-be3c-aa0afb13e09c@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <HgRaTELVlUrwHDlYHEg-991pzPoORrq9w2rbyRj9sCM=.3671e28b-94bd-4447-a6e1-c3cde3e20fb3@github.com>
 <OlQ2AorM5A70wgd5FxTHtuAYjqiQa_FWSU-9sjsiba4=.c9407e11-9f4d-4e8d-86cf-5e87d6750401@github.com>
 <xp9tPLejseMbmNZRnzuihxRigyV7HKkOwhKF8HOWFo0=.a5a6f128-58f6-405e-be3c-aa0afb13e09c@github.com>
Message-ID: <TXG8ncLd6-6JLhvw2UFsNVgwkOY1mbYnESpth7i8xAo=.b277c005-0abe-45a0-afc0-34b49ce02fab@github.com>

On Fri, 24 Oct 2025 19:44:02 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 160:
>> 
>>> 158:             keySpec = new PBEKeySpec(password);
>>> 159:         }
>>> 160:         pbeKey = skf.generateSecret(keySpec);
>> 
>> If the line above fails, there is no chance to clean `keySpec`. Create a big try-finally block.
>
> I assume you mean to put line 160 in the existing try-finally block rather than create another try-finally block just for this.

Yes.

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

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

From mpowers at openjdk.org  Sat Oct 25 01:34:54 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Sat, 25 Oct 2025 01:34:54 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v15]
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <5onjbYrUruSKWpeOQKDfLzKzaRRuMRykfdErhr4gVIc=.cc457a46-3589-49b7-ac73-ae95ccc2712f@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:

  Weijun code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24429/files
  - new: https://git.openjdk.org/jdk/pull/24429/files/8f0b0d02..69d7c291

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

  Stats: 327 lines in 7 files changed: 266 ins; 24 del; 37 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 duke at openjdk.org  Sat Oct 25 02:53:01 2025
From: duke at openjdk.org (Josiah Noel)
Date: Sat, 25 Oct 2025 02:53:01 GMT
Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver
 [v13]
In-Reply-To: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
References: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
Message-ID: <QBwjoRxK6LU0NYy3le6TAPBxXOQ3wd3Cd2AYVzLMq6w=.65496765-65ef-471b-ac18-7cdd8d6c72b9@github.com>

> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request
> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream`

Josiah Noel has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Update ExchangeImpl.java
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - reduce diff
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - add exception test
 - Create UpgradeOutputStream.java
 - close raw streams
 - ... and 8 more: https://git.openjdk.org/jdk/compare/32697bf6...ae2b1184

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

Changes: https://git.openjdk.org/jdk/pull/27751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=12
  Stats: 25304 lines in 632 files changed: 6529 ins; 14641 del; 4134 mod
  Patch: https://git.openjdk.org/jdk/pull/27751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751

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

From duke at openjdk.org  Sat Oct 25 02:53:02 2025
From: duke at openjdk.org (Josiah Noel)
Date: Sat, 25 Oct 2025 02:53:02 GMT
Subject: Withdrawn: 8368695: Support 101 switching protocol in jdk.httpserver
In-Reply-To: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
References: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
Message-ID: <xzMm3alltKr_uQFUr-WnPiY0p0n-oXxvx0JY9OcrdHc=.8e9e00b5-731a-41e4-9fe2-68bca97f4413@github.com>

On Fri, 10 Oct 2025 19:45:57 GMT, Josiah Noel <duke at openjdk.org> wrote:

> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request
> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream`

This pull request has been closed without being integrated.

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

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

From weijun at openjdk.org  Sat Oct 25 13:21:07 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 25 Oct 2025 13:21:07 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v11]
In-Reply-To: <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@github.com>
Message-ID: <LVofU-C7CqV5zjnlHmeZg38Ve7f0spvP2rpsZzAcPkw=.9e83772e-8542-4020-8447-bf0cdd684695@github.com>

On Fri, 24 Oct 2025 19:06:33 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:
> 
>   more docs, remove runtimeexception

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

> 403:      * @implNote The {@code jdk.epkcs8.defaultAlgorithm} security property
> 404:      * defines the default encryption algorithm. The {@code AlgorithmParameterSpec}
> 405:      * defaults are determined by the provider.*

A star at the end of line.

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

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

From myankelevich at openjdk.org  Sat Oct 25 15:30:15 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Sat, 25 Oct 2025 15:30:15 GMT
Subject: Integrated: 8360395: sun/security/tools/keytool/i18n.java user country
 is current user location instead of the language
In-Reply-To: <RhPO5u_2ArMs5xdcJ8vRnTmi8t0PtVdzQAopkKpHPEc=.590d7d13-3756-45ed-9973-4ecc3f683dcb@github.com>
References: <RhPO5u_2ArMs5xdcJ8vRnTmi8t0PtVdzQAopkKpHPEc=.590d7d13-3756-45ed-9973-4ecc3f683dcb@github.com>
Message-ID: <7em5q-vdV8f5neqWkwo_l82B5sds-DIEYgPL1w_I080=.a98df31d-4435-4fa5-993c-103666a5e2db@github.com>

On Tue, 14 Oct 2025 11:26:35 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> User location would now follow the language location, not the current location of the test machine

This pull request has now been integrated.

Changeset: c3449de2
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3449de23f4fa74590494b8677f6832d47f12dea
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8360395: sun/security/tools/keytool/i18n.java user country is current user location instead of the language

Reviewed-by: rhalade

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

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

From serb at openjdk.org  Sun Oct 26 22:49:43 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 26 Oct 2025 22:49:43 GMT
Subject: RFR: 8370368: Apply java.io.Serial annotations in
 java.security.jgss [v4]
In-Reply-To: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
Message-ID: <JpYf4exlyl-z7oqkxP7w152x96Ekyx87GAMwVGENjls=.ccc63e11-d25b-4171-9f9c-45a13fc6886b@github.com>

> Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.security.jgss module to enable stricter compile-time checking of serialization-related declarations.
> 
> Example of a similar change https://github.com/openjdk/jdk/pull/24891.

Sergey Bylokhov 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 four additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8370368
 - Replace java.io.Serial annotations with @Serial
 - Merge branch 'openjdk:master' into JDK-8370368
 - 8370368: Apply java.io.Serial annotations in java.security.jgss

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27925/files
  - new: https://git.openjdk.org/jdk/pull/27925/files/89b4abe2..10ac32e5

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

  Stats: 1779 lines in 52 files changed: 1101 ins; 454 del; 224 mod
  Patch: https://git.openjdk.org/jdk/pull/27925.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27925/head:pull/27925

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

From xuelei at openjdk.org  Mon Oct 27 02:43:12 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Oct 2025 02:43:12 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: <mp9gUW-8y8ptv42yDrYC8npMLK9B8pL9H4T50QyL6aQ=.2c15ba44-e8a3-40a2-85c2-2251fe657729@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/sun/security/util/Hybrid.java line 230:

> 228:             }
> 229: 
> 230:             throw new InvalidKeySpecException(keySpec.toString());

Please check null keySpec, and  `throw new InvalidKeySpecException("keySpec must not be null")`.

For non-null keySpec, I may use:
`throw new InvalidKeySpecException(keySpec.getClass().getName() + " not supported.");
`

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

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

From xuelei at openjdk.org  Mon Oct 27 02:52:08 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Oct 2025 02:52:08 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: <9W7IE13CTQC8WF8239p05fovkC2IRVazTK9VxWUCq8A=.6ad8a6dc-fcf1-4b35-8c50-7cb110b4898c@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/sun/security/util/Hybrid.java line 60:

> 58:         @Override
> 59:         public String getAlgorithm() {
> 60:             return "Hybrid";

Will this name be added to CSR and Java Security Standard Algorithm Names doc?

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

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

From xuelei at openjdk.org  Mon Oct 27 02:57:06 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Oct 2025 02:57:06 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: <2jw9vzhL3PTErFMaS0rDxOTG0mT3DRNTe0q6ttVHW4Y=.19415f62-c657-4ebf-aaf4-39a42170b6ae@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

test/jdk/java/security/spec/TestNamedParameterSpec.java line 44:

> 42:         "ML_DSA_44", "ML_DSA_65", "ML_DSA_87",
> 43:         "ML_KEM_512", "ML_KEM_768", "ML_KEM_1024",
> 44:         "X25519MLKEM768", "SecP256r1MLKEM768", "SecP384r1MLKEM1024",

Does it sound like an option to use the similar naming style like "ML_KEM_512" for the new names?  for example, X25519MLKEM768 -> X25519_ML_KEM_768

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

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

From xuelei at openjdk.org  Mon Oct 27 03:47:07 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Oct 2025 03:47:07 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: <uUMZKMrdqiWeSDD8knA4Vm3H453yo4My9uhnAzY3Wd4=.7be6502e-b463-4c6b-93bb-285493760426@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/sun/security/util/Hybrid.java line 107:

> 105:     private static KEM getKEM(String name) throws NoSuchAlgorithmException {
> 106:         if (APS.isGenericEC(name) || APS.isXDH(name)) {
> 107:             return KEM.getInstance("DH", DH.PROVIDER);

May I get more information about the hard-coded provider DH.PROVIDER?  Could it be more general so that other KEM provider can also be used?

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

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

From xuelei at openjdk.org  Mon Oct 27 04:02:07 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Oct 2025 04:02:07 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: <Xn5fgBEoZezVWRO8PVXWfyLXMowqEa3dlmoY8czBPD0=.2e8b93c8-7f49-4791-822f-cb61989f3292@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/com/sun/crypto/provider/DH.java line 71:

> 69:     public static final Provider PROVIDER = new ProviderImpl();
> 70: 
> 71:     private static class ProviderImpl extends Provider {

Why not expose the Provider to public?

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

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

From xuelei at openjdk.org  Mon Oct 27 04:05:10 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Oct 2025 04:05:10 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: <-M7FwZXlPOI1aP9_b-2WXv6oyrvAvjPv1UtLtLhtLcg=.9574cf9f-0df8-4270-ba02-1f405ec82602@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/sun/security/util/Hybrid.java line 178:

> 176:                 throws InvalidKeySpecException {
> 177:             if (keySpec instanceof RawKeySpec rks) {
> 178:                 byte[] key = rks.getKeyArr();

null check on key may be missed.  If the API expose to public in the future, the key length checking may be good before Arrays.copyOfRange.

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

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

From xuelei at openjdk.org  Mon Oct 27 04:16:07 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Oct 2025 04:16:07 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: <UIiOIjJcZZH2e8GdRKH7m1J3xu7TtyxGLrwPfyZ5wYU=.86bbbaa3-bd02-4ea6-9c2a-3bb694fa2e33@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/sun/security/util/Hybrid.java line 197:

> 195:                         } catch (Exception e) {
> 196:                             leftKey = left.generatePublic(new X509EncodedKeySpec(
> 197:                                     leftKeyBytes));

Fall-back is not good for performance.  Does it have to support two key spec?

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

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

From xuelei at openjdk.org  Mon Oct 27 04:19:08 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Oct 2025 04:19:08 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: <YWEzKsmEJUiMUfcrGBXJth-Nm7SwflkX7GOLrERFzjw=.e5347676-95ce-4ce1-ba10-6f58c22ecf04@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/sun/security/util/Hybrid.java line 134:

> 132:                 right.initialize(rightSpec, random);
> 133:                 initialized = true;
> 134:             } catch (Exception e) {

It may be nice if not wrap InvalidParameterException twice.

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

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

From xuelei at openjdk.org  Mon Oct 27 04:32:11 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 27 Oct 2025 04:32:11 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: <EugAM_b9rgChqW9fhIzKVwAmXLdjEc8ui5zG7xMLwZc=.6de41963-41cc-4531-880d-d99e819b1b91@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/sun/security/util/Hybrid.java line 149:

> 147:                     throw new ProviderException(e);
> 148:                 }
> 149:             }

The initialization block could be saved if call initialize in the constructor.  See sun/security/ec/ECKeyPairGenerator.java

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

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

From iklam at openjdk.org  Mon Oct 27 06:27:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 27 Oct 2025 06:27:01 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
 <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>
 <OX-wQE2nG9P-Z0-oPjLlWzZO3Sl0Wrkj8moXNPaHQug=.4efa2e49-c6b6-463d-861e-369ebad5970b@github.com>
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
Message-ID: <y6NYOWeZb2VJX0BxDNE0yNNg0d2db7_nYjbbtO5GRNQ=.becb9811-ad5a-4100-9f63-905ec8841463@github.com>

On Mon, 20 Oct 2025 17:40:20 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise?
>
> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?
> 
> Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null?
> 
> The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem

I looked at all the calls of the pattern `SharedSecrets.set.*::`


java/io/ObjectInputFilter.java: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);
java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray);
java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString);
javax/crypto/SealedObject.java: SharedSecrets.setJavaxCryptoSealedObjectAccess(SealedObject::getExtObjectInputStream);


These calls are all done inside a `<clinit>`. In the four cases, only the first class (`java.io.ObjectInputFilter.Config`) has environment-dependent code inside its `<clinit>`.

Maybe we should mark the `java.io.ObjectInputFilter.Config` class with a new annotation `AOTUnsafeClassInitializer` (the opposite of the existing `AOTSafeClassInitializer`). If this class is initialized in the assembly phase, the VM will exit.

I think we can leave the other 3 cases alone.

An alternative is to rewrite the first case from:


SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);


to


SharedSecrets.setJavaObjectInputFilterAccess(new JavaObjectInputFilterAccess() {
    ObjectInputFilter createFilter2(String pattern) {
        return Config.createFilter2(pattern);
    }
});

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2464550244

From serb at openjdk.org  Mon Oct 27 07:41:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Oct 2025 07:41:13 GMT
Subject: Integrated: 8370368: Apply java.io.Serial annotations in
 java.security.jgss
In-Reply-To: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
References: <FqQU-2gicc5jX-aDsjr6Bbx8CQLcTA_-bgcYWfw319M=.c9e16c0d-254d-40f8-af96-3ecbd90b44b4@github.com>
Message-ID: <p-YllUUscqwUhgiyc_3EEkH8vcXxTRV7orKrNr7gzV8=.a3f20724-1275-460d-a7ac-22d920c0642a@github.com>

On Wed, 22 Oct 2025 01:10:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.security.jgss module to enable stricter compile-time checking of serialization-related declarations.
> 
> Example of a similar change https://github.com/openjdk/jdk/pull/24891.

This pull request has now been integrated.

Changeset: f5ef01d4
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5ef01d4bfcf960b6a46844818138ee798532d45
Stats:     38 lines in 11 files changed: 26 ins; 0 del; 12 mod

8370368: Apply java.io.Serial annotations in java.security.jgss

Reviewed-by: mullan

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

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

From pminborg at openjdk.org  Mon Oct 27 08:52:04 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 27 Oct 2025 08:52:04 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: <g9ureI2i_-WbZgE3rx8CKkhIFU9h8lmhCKmzkgUWLZg=.74988d0e-12a0-43fa-9d1e-0ec1bcc12388@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/hotspot/share/cds/cdsHeapVerifier.cpp line 186:

> 184:     if (fd->signature()->starts_with("Ljdk/internal/access/") &&
> 185:         fd->signature()->ends_with("Access;")) {
> 186:       // The jdk/internal/access/*Access classes carry no states so they can be safely

This might be true for the time being, but adding such an assumption is a constraint for the future and should be documented. Perhaps we should have an interface `Access` that the various access classes implement, and where we could document this and other constraints of the access classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2464838946

From weijun at openjdk.org  Mon Oct 27 13:24:23 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 27 Oct 2025 13:24:23 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v11]
In-Reply-To: <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@github.com>
Message-ID: <kPdVoCI-lZYeU3S1XnZP0RghzigPHzxdV1Vns9vrtfg=.e7a8b2b3-c51d-4578-abeb-fd1a04df724a@github.com>

On Fri, 24 Oct 2025 19:06:33 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:
> 
>   more docs, remove runtimeexception

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

> 432:      *               {@code null}, the provider?s default parameters are applied.
> 433:      * @param random the {@code SecureRandom} instance used during encryption.
> 434:      *               If {@code null}, the default is used

This method does not include an `@implNote` talking about what "the default" `SecureRandom` means. Shall we just say here that the provider would choose one?

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

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

From duke at openjdk.org  Mon Oct 27 13:28:10 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 27 Oct 2025 13:28:10 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets
In-Reply-To: <y6NYOWeZb2VJX0BxDNE0yNNg0d2db7_nYjbbtO5GRNQ=.becb9811-ad5a-4100-9f63-905ec8841463@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
 <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>
 <OX-wQE2nG9P-Z0-oPjLlWzZO3Sl0Wrkj8moXNPaHQug=.4efa2e49-c6b6-463d-861e-369ebad5970b@github.com>
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
 <y6NYOWeZb2VJX0BxDNE0yNNg0d2db7_nYjbbtO5GRNQ=.becb9811-ad5a-4100-9f63-905ec8841463@github.com>
Message-ID: <FsceKc9CJ1poYYrpDNi8Ubc2rbtyxD3FIA1TSADAUcA=.4e53b04b-49eb-4ca4-b135-06a31cc1beae@github.com>

On Mon, 27 Oct 2025 06:23:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?
>> 
>> Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null?
>> 
>> The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem
>
> I looked at all the calls of the pattern `SharedSecrets.set.*::`
> 
> 
> java/io/ObjectInputFilter.java: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);
> java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray);
> java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString);
> javax/crypto/SealedObject.java: SharedSecrets.setJavaxCryptoSealedObjectAccess(SealedObject::getExtObjectInputStream);
> 
> 
> These calls are all done inside a `<clinit>`. In the four cases, only the first class (`java.io.ObjectInputFilter.Config`) has environment-dependent code inside its `<clinit>`.
> 
> Maybe we should mark the `java.io.ObjectInputFilter.Config` class with a new annotation `AOTUnsafeClassInitializer` (the opposite of the existing `AOTSafeClassInitializer`). If this class is initialized in the assembly phase, the VM will exit.
> 
> I think we can leave the other 3 cases alone.
> 
> An alternative is to rewrite the first case from:
> 
> 
> SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);
> 
> 
> to
> 
> 
> SharedSecrets.setJavaObjectInputFilterAccess(new JavaObjectInputFilterAccess() {
>     ObjectInputFilter createFilter2(String pattern) {
>         return Config.createFilter2(pattern);
>     }
> });

The?`ObjectInputStreamReadString` interface should?just be?merged into?`ObjectInputStreamAccess`:

SharedSecrets.setJavaObjectInputStreamAccess(new ObjectInputStreamAccess() {
	public void checkArray(ObjectInputStream ois, Class<?> arrayType, int arrayLength) throws ObjectStreamException {
		ois.checkArray(arrayType, arrayLength);
	}

	public String readString(ObjectInputStream ois) throws IOException {
		return ois.readString();
	}
});

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2465667143

From weijun at openjdk.org  Mon Oct 27 13:30:11 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 27 Oct 2025 13:30:11 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v11]
In-Reply-To: <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@github.com>
Message-ID: <8awXNzilfs-5F_7QH1DbEngfSo9GGe_AW-2DnbsmkNo=.74fd88f0-d436-4bbc-9398-4d2aa8761e27@github.com>

On Fri, 24 Oct 2025 19:06:33 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:
> 
>   more docs, remove runtimeexception

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

> 550:         try {
> 551:             encoding = decryptData(decryptKey, provider);
> 552:             return PKCS8Key.parseKey(encoding, null);

The spec says `provider` is used in private key generation but `null` is used above.

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

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

From weijun at openjdk.org  Mon Oct 27 13:57:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 27 Oct 2025 13:57:50 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v11]
In-Reply-To: <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@github.com>
Message-ID: <TEioJ6FR11aIxA6vpLl5mgZHrWz0AQD_mdlZctcK23M=.445dba7b-e2b1-4f47-9ab8-bbae3a8942c4@github.com>

On Fri, 24 Oct 2025 19:06:33 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:
> 
>   more docs, remove runtimeexception

Some tiny comments.

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

> 332:      * @return a {@code DEREncodable}
> 333:      * @throws IOException on IO or PEM syntax error where the
> 334:      * {@code InputStream} did not complete decoding.

Period at end.

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

> 401:      * <p> If no PEM data is found, an {@code EOFException} is thrown.
> 402:      *
> 403:      * @param <S> class type parameter that extends {@code DEREncodable}.

Period at end.

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

> 404:      * @param is an {@code InputStream} containing PEM data
> 405:      * @param tClass the returned object class that extends or implements
> 406:      *   {@code DEREncodable}.

Period at end.

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

> 407:      * @return a {@code DEREncodable} typecast to {@code tClass}
> 408:      * @throws IOException on IO or PEM syntax error where the
> 409:      *   {@code InputStream} did not complete decoding.

Period at end.

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

> 351:      * @param password the password used for PBE encryption. This array is cloned
> 352:      *                 before use.
> 353:      * @param algorithm the PBE encryption algorithm.

Period at end.

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

> 356:      * @param provider the {@code Provider} for {@code SecretKeyFactory} and
> 357:      *                 {@code Cipher} operations. If {@code null}, provider
> 358:      *                 defaults are used

No period at end.

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

> 426:      * @param de the {@code DEREncodable} to encrypt. Supported types include
> 427:      *           {@code PrivateKey}, {@code KeyPair}, and {@code PKCS8EncodedKeySpec}.
> 428:      * @param encryptKey the key used to encrypt the encoding.

Period at end.

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

> 428:      * @param encryptKey the key used to encrypt the encoding.
> 429:      * @param algorithm the encryption algorithm, such as a password-based
> 430:      *                  encryption (PBE) algorithm.

Period at end.

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

> 432:      *               {@code null}, the provider?s default parameters are applied.
> 433:      * @param random the {@code SecureRandom} instance used during encryption.
> 434:      *               If {@code null}, the default is used

No period at end.

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

> 441:      *         {@code DEREncodable}, if {@code encryptKey} is invalid, if
> 442:      *         {@code algorithm} or {@code params} are not supported by any
> 443:      *         provider, or if an error occurs during encryption.

Period at end.

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

PR Review: https://git.openjdk.org/jdk/pull/27147#pullrequestreview-3383608457
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465770029
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465771881
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465773174
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465774479
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465755364
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465756500
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465759253
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465760463
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465761669
PR Review Comment: https://git.openjdk.org/jdk/pull/27147#discussion_r2465763501

From abarashev at openjdk.org  Mon Oct 27 15:19:30 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 27 Oct 2025 15:19:30 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
Message-ID: <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>

> We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call:
> - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
> - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Log unavailable configured signature scheme

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27961/files
  - new: https://git.openjdk.org/jdk/pull/27961/files/ecc95437..f8721c93

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

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

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

From mdonovan at openjdk.org  Mon Oct 27 16:06:55 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 27 Oct 2025 16:06:55 GMT
Subject: RFR: 8356544: Implement additional tests for ciphersuites disabled
 with wildcards
Message-ID: <je_VCMu-DDtmPzrrRawpZGSXmsPv6ttLD6-k4QORWVc=.e83e6d61-1494-4c28-88fa-8d8d202ce87d@github.com>

This PR extends the tests from JDK-8341964 and verifies a TLS server (or client) will not negotiate a ciphersuite requested by the remote peer but disabled with a wildcard.

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

Commit messages:
 - 8356544: Implement additional tests for ciphersuites disabled with wildcards

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

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

From mdonovan at openjdk.org  Mon Oct 27 16:37:09 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 27 Oct 2025 16:37:09 GMT
Subject: RFR: 8323999: KeyAgreement cannot be initiated again after a failed
 initialization
Message-ID: <Bg5Ko12jUKCaotOkF04mwV512OvQM8qNsMEIWFnQI0w=.c1d6d9a3-1e97-4f75-914c-5ae11deacd56@github.com>

This PR updates KeyAgreement to re-initialize the `serviceIterator` field when chooseProvider() is called and serviceIterator.hasNext() returns false. This can happen if KeyAgreement object has been initialized with an invalid key and then initialized with a valid key. (See accompanying test.)

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

Commit messages:
 - 8323999: KeyAgreement cannot be initiated again after a failed initialization

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

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

From prappo at openjdk.org  Mon Oct 27 17:51:36 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 27 Oct 2025 17:51:36 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
Message-ID: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>

Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.

Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/27972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370568
  Stats: 207 lines in 77 files changed: 0 ins; 0 del; 207 mod
  Patch: https://git.openjdk.org/jdk/pull/27972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972

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

From ascarpino at openjdk.org  Mon Oct 27 18:56:21 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 27 Oct 2025 18:56:21 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v11]
In-Reply-To: <kPdVoCI-lZYeU3S1XnZP0RghzigPHzxdV1Vns9vrtfg=.e7a8b2b3-c51d-4578-abeb-fd1a04df724a@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <sNfvl_dWDfvUyjpxynccfMQOwyZRC24dLVOwIRMYK9Y=.bb6b46db-e414-4413-b2b8-1a477412c121@github.com>
 <kPdVoCI-lZYeU3S1XnZP0RghzigPHzxdV1Vns9vrtfg=.e7a8b2b3-c51d-4578-abeb-fd1a04df724a@github.com>
Message-ID: <s-yS5ouwVrDSLRTQE3DoJk3lBrwPRp6Yr1QLhqqk98c=.cfba5c63-7ab5-49f9-aa4c-5a4d227ae896@github.com>

On Mon, 27 Oct 2025 13:21:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more docs, remove runtimeexception
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 434:
> 
>> 432:      *               {@code null}, the provider?s default parameters are applied.
>> 433:      * @param random the {@code SecureRandom} instance used during encryption.
>> 434:      *               If {@code null}, the default is used
> 
> This method does not include an `@implNote` talking about what "the default" `SecureRandom` means. Shall we just say here that the provider would choose one?

I don't feel we need to be precise here.  Very little is mentioned in methods that don't take `SecureRandom`, but use it internally.  If there was some `@implNote`, it should be in the `SecureRandom` javadoc so every API didn't have to explain it's usage.

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

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

From mullan at openjdk.org  Mon Oct 27 19:41:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 27 Oct 2025 19:41:11 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions
In-Reply-To: <MuR9VSyvlMyr0kAhcBa2g7tce-HOlYf1Q9TFdi4uzR4=.e650723a-d351-4193-8db0-5ec00335276b@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>
 <MuR9VSyvlMyr0kAhcBa2g7tce-HOlYf1Q9TFdi4uzR4=.e650723a-d351-4193-8db0-5ec00335276b@github.com>
Message-ID: <mDxHjy4Fr4F7WPcBADeQPDldGV96Gwgm6LETZxx_xjo=.5a567b9c-032b-4a13-9204-0c1fbd15c3c7@github.com>

On Mon, 1 Sep 2025 12:12:51 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>>> @AlanBateman are you ok with letting the original [c6f1d5f](https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab) reviewers know of this fix and take a look? Or do you think further discussion is needed somewhere else?
>> 
>> Have you had time to try using the file key to detect the recursive include case?
>
> Hi @AlanBateman, have you had time to review my previous message?

@franferrax Have you tried Alan's suggestion?

Also, since this is a regression, and you think it will take longer to come up with a fix, can I suggest as a temporary fix you revert to using `FileInputStream` to load the security properties file (in the default location or via the -Djava.security.properties system property), and only call `loadFromPath` if an include directive is specified? Is that feasible? If so, you can then address this issue separately. This should at least fix the common case where no include directive is specified. It would be good to get the primary use case fixed in 26.

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3453003241

From duke at openjdk.org  Mon Oct 27 20:24:43 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Mon, 27 Oct 2025 20:24:43 GMT
Subject: RFR: 8368301: sun/security/util/math/intpoly compiler warnings
Message-ID: <qwlt_PttmkLy21-4fEtX37Teg__YPRZhlgkFM_E78wg=.7d861593-ef44-4ad3-a55c-2df6f70e7b5d@github.com>

The classes are all generated; the actual bug is on line 631 of make/jdk/src/classes/build/tools/intpoly/FieldGen.java.

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

Commit messages:
 - 8368301: sun/security/util/math/intpoly compiler warnings
 - 8368301: sun/security/util/math/intpoly compiler warnings
 - 8368301: sun/security/util/math/intpoly compiler warnings

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

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

From duke at openjdk.org  Mon Oct 27 20:24:44 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 27 Oct 2025 20:24:44 GMT
Subject: RFR: 8368301: sun/security/util/math/intpoly compiler warnings
In-Reply-To: <qwlt_PttmkLy21-4fEtX37Teg__YPRZhlgkFM_E78wg=.7d861593-ef44-4ad3-a55c-2df6f70e7b5d@github.com>
References: <qwlt_PttmkLy21-4fEtX37Teg__YPRZhlgkFM_E78wg=.7d861593-ef44-4ad3-a55c-2df6f70e7b5d@github.com>
Message-ID: <syMTQdL-mMhPlXNu2I_rYZ3oStprf8kf4TLQ2symrOY=.15bb59b6-5b59-48aa-ae9b-39d7a8f1419a@github.com>

On Fri, 24 Oct 2025 02:35:03 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The classes are all generated; the actual bug is on line 631 of make/jdk/src/classes/build/tools/intpoly/FieldGen.java.

Looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/27967#issuecomment-3453135964

From mullan at openjdk.org  Mon Oct 27 20:33:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 27 Oct 2025 20:33:07 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v7]
In-Reply-To: <J0AhZ2syJv1vJdRmKfdBZabGwpsu8gBdMj7x80O5rJY=.5e50c121-c822-43f3-8046-219d4b2e2f61@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <-hmSCg-kSq6gDwenVvvHhpuNrSDTpa6F30ZQ4jtojO4=.dbbec60d-cfd6-4bfb-af32-33cd4dd03f7b@github.com>
 <aWJeIE0LgmW4og_WPmupj5aucDmyL4TkPjvRycn9Tjc=.5c9bdcf9-a1b8-4011-a4ea-0d21f8145dbb@github.com>
 <J0AhZ2syJv1vJdRmKfdBZabGwpsu8gBdMj7x80O5rJY=.5e50c121-c822-43f3-8046-219d4b2e2f61@github.com>
Message-ID: <fAHneu4Qls0M3VHY7B9fXxceBwEFC5CL7I90nfKgzCE=.552126f0-5f2b-42b7-b8ed-593cbd0a4c06@github.com>

On Wed, 22 Oct 2025 19:25:43 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/PEMDecoder.java line 298:
>> 
>>> 296:      * @param str a String containing PEM data
>>> 297:      * @return a {@code DEREncodable}
>>> 298:      * @throws IllegalArgumentException on error in decoding or no PEM data found
>> 
>> It looks like this method will throw `EOFException` and not `IllegalArgumentException` if there is no PEM data because it calls decode with a `ByteArrayInputStream` so uses that method which throws an `EOFException`.
>> 
>> Same comment for method that takes a `Class` argument.
>
> EOFException is a child of IOException, so the catch covers this.

Ah, ok, although I think it is odd for `EOFException` (or even `IOException`) to be the cause for reading from a String or byte array.

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

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

From rriggs at openjdk.org  Mon Oct 27 20:45:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Oct 2025 20:45:02 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <Cgql6iI8JuqqSOun9twdTUyH58EbM3FM_jaKF_a8iys=.f58c06ff-2c6b-41fb-bbc7-ae4f92d91401@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3385391439

From weijun at openjdk.org  Mon Oct 27 21:03:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 27 Oct 2025 21:03:50 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: <Vu01NOGFXVqAz7OfaiapneSLyZqO8OR_vl2qMn-1_3w=.9008cd15-2a33-4f2d-9102-723b99dcc55f@github.com>

On Wed, 1 Oct 2025 16:50:16 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/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?

Not the IDE, but I keep hearing people saying wildcard import is evil.

> 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?

Yes, so when JDK-8325513: Export method for Cipher is integrated, I only need to uncomment this.

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

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

From weijun at openjdk.org  Mon Oct 27 21:10:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 27 Oct 2025 21:10:12 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v44]
In-Reply-To: <QFSI_cvhO3laH7hCIYsoI9E6MgZQSaIRyHtxkgDNHx4=.5ba9a81d-738d-42db-8560-238bc532037b@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>
 <QFSI_cvhO3laH7hCIYsoI9E6MgZQSaIRyHtxkgDNHx4=.5ba9a81d-738d-42db-8560-238bc532037b@github.com>
Message-ID: <l7afNXdzx2zfCnpgUWvgoHhqQLsPqDAHAOUzYZg89lQ=.fa58e884-61ac-4ef5-9f08-912c56527f18@github.com>

On Fri, 3 Oct 2025 18:57:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> 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()`

Updated most. `engineInit()` has only if-else and not worth rewriting.

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

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

From weijun at openjdk.org  Mon Oct 27 21:15:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 27 Oct 2025 21:15:50 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v45]
In-Reply-To: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
Message-ID: <oHmcDgomBdprG7SpuId-XG5pOJ0jxouRLWGuJmZ78Cw=.8bab7f1c-857e-41bb-8d28-b54db9aa8e12@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains 61 commits:

 - Merge branch 'master' into 8325448
 - Tony's comment
 - more key checks; some small spec change
 - Merge branch 'master' into 8325448
 - about transformation
 - cannot reset with withMethods
 - algorithm identifier
 - withMethods
 - duplicated "value" words
 - receiver to recipient; different to specified
 - ... and 51 more: https://git.openjdk.org/jdk/compare/a9254613...8c6cffa4

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

Changes: https://git.openjdk.org/jdk/pull/18411/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=44
  Stats: 2160 lines in 12 files changed: 1963 ins; 74 del; 123 mod
  Patch: https://git.openjdk.org/jdk/pull/18411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411

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

From fferrari at openjdk.org  Mon Oct 27 22:00:09 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 27 Oct 2025 22:00:09 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions
In-Reply-To: <iw4NcdhA6TkUsoHcdrKXsQsG2d9CtBrXBobuXyUT0QY=.cad72c9d-ac36-4b65-a915-381a864f10ff@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>
 <iw4NcdhA6TkUsoHcdrKXsQsG2d9CtBrXBobuXyUT0QY=.cad72c9d-ac36-4b65-a915-381a864f10ff@github.com>
Message-ID: <t_TRG_b382yzyfRY7hl5TmmSNYNvlL4ffeTOfH_OV9w=.da337672-2acd-4a26-b4cd-d2bad2fd12dd@github.com>

On Fri, 17 Oct 2025 10:07:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @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..

@AlanBateman: I will try it, but please let me insist on the fact that the circular include detection is a secondary problem here (it's solved for any of the alternatives and the current mainline code). However, we still need a reliable way to determine the base directory for relative includes.

@seanjmullan: that would be more or less the franferrax at fbec2fd80a9930cf4cb00f4f35684f2e2cc2fbf1 alternative from [this comment](https://github.com/openjdk/jdk/pull/24465#issuecomment-3114241142) (instead of using `FileInputStream`, just avoid `java.nio.file.Path::toRealPath`, not only if there isn't any `include`, but also for all the `include` statements that are absolute). Please also refer to the table in the comment, as that alternative doesn't solve the 7abb62c069ad35f4ec34f6cd9b9f6d05febceecc variant.

This PR has been opened for 205 days now, and I've put a considerable effort:

* Debugging and documenting the underlying OS APIs ([here](https://github.com/openjdk/jdk/pull/24465#issue-2973770332) and [here](https://github.com/openjdk/jdk/pull/24465#issuecomment-2803609222))
* Thinking and testing possible problematic scenarios ([here](https://github.com/openjdk/jdk/pull/24465#issuecomment-2835992962))
* Analyzing and developing a test for a variant of the original issue (7abb62c069ad35f4ec34f6cd9b9f6d05febceecc)
* Providing and testing several alternatives ([here](https://github.com/openjdk/jdk/pull/24465#issuecomment-3114241142))

I understand there is more rush now because we found more customers affected by it, but that doesn't change my position, I'm still convinced that the currently proposed fix is the best option among the analyzed alternatives (or perhaps franferrax at c9a3985c7d11335f3c9b8ab67d166bdc2a16289f, if we prefer to be conservative at the cost of a slightly less simple code).

I don't believe it should take longer to come up with a fix.

[JDK-8352728]: https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions"

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3453483597

From mpowers at openjdk.org  Mon Oct 27 23:36:43 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 27 Oct 2025 23:36:43 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v16]
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@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:

  A4-A6 from RFC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24429/files
  - new: https://git.openjdk.org/jdk/pull/24429/files/69d7c291..9d2f61f6

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

  Stats: 725 lines in 2 files changed: 24 ins; 701 del; 0 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 28 01:30:15 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 28 Oct 2025 01:30:15 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v16]
In-Reply-To: <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@github.com>
Message-ID: <k0bH8607GG5erOdA7Yh3ywUHP-BYeVFJC7_MjDlMXmE=.89895b94-bb46-4de6-aad0-45af1a4ee386@github.com>

On Mon, 27 Oct 2025 23:36:43 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:
> 
>   A4-A6 from RFC

Everything looks fine.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24429#pullrequestreview-3386145911

From iklam at openjdk.org  Tue Oct 28 04:06:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:06:41 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v2]
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: <ATbhW05Bi-PFrFNbWXnMhUxHuEsFa9Tc6o8Dg-P-jiY=.2d8bead8-faf4-4d83-b1de-345c64b40524@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.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Added StatelessOopsFinder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27880/files
  - new: https://git.openjdk.org/jdk/pull/27880/files/a886aa85..c6ea93c3

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

  Stats: 217 lines in 4 files changed: 211 ins; 6 del; 0 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 iklam at openjdk.org  Tue Oct 28 04:06:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:06:41 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v2]
In-Reply-To: <g9ureI2i_-WbZgE3rx8CKkhIFU9h8lmhCKmzkgUWLZg=.74988d0e-12a0-43fa-9d1e-0ec1bcc12388@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <g9ureI2i_-WbZgE3rx8CKkhIFU9h8lmhCKmzkgUWLZg=.74988d0e-12a0-43fa-9d1e-0ec1bcc12388@github.com>
Message-ID: <QBfV4BMICGILTz-vLHREHyqm4V1CFBVJ0cxbAV_efc4=.8a5ecbb1-0221-4e7e-bbeb-e4f0402d5da8@github.com>

On Mon, 27 Oct 2025 08:48:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added StatelessOopsFinder
>
> src/hotspot/share/cds/cdsHeapVerifier.cpp line 186:
> 
>> 184:     if (fd->signature()->starts_with("Ljdk/internal/access/") &&
>> 185:         fd->signature()->ends_with("Access;")) {
>> 186:       // The jdk/internal/access/*Access classes carry no states so they can be safely
> 
> This might be true for the time being, but adding such an assumption is a constraint for the future and should be documented. Perhaps we should have an interface `Access` that the various access classes implement, and where we could document this and other constraints of the access classes.

I removed this hard-coded check and instead added `CDSHeapVerifier::add_shared_secret_accessors()`, which requires all AOT-initialized accessors to be stateless.

I also added a negative test case for `SharedSecrets::javaObjectInputFilterAccess`, which is not stateless so it cannot be initialized in the AOT assembly phase.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467807545

From iklam at openjdk.org  Tue Oct 28 04:06:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:06:41 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v2]
In-Reply-To: <FsceKc9CJ1poYYrpDNi8Ubc2rbtyxD3FIA1TSADAUcA=.4e53b04b-49eb-4ca4-b135-06a31cc1beae@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
 <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>
 <OX-wQE2nG9P-Z0-oPjLlWzZO3Sl0Wrkj8moXNPaHQug=.4efa2e49-c6b6-463d-861e-369ebad5970b@github.com>
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
 <y6NYOWeZb2VJX0BxDNE0yNNg0d2db7_nYjbbtO5GRNQ=.becb9811-ad5a-4100-9f63-905ec8841463@github.com>
 <FsceKc9CJ1poYYrpDNi8Ubc2rbtyxD3FIA1TSADAUcA=.4e53b04b-49eb-4ca4-b135-06a31cc1beae@github.com>
Message-ID: <gCHojoxWDS4EbVrCfCOVguthRzpMA6LCcY67V5dR_b8=.654ea71c-1613-45a2-b10c-e21d4656f559@github.com>

On Mon, 27 Oct 2025 13:25:56 GMT, ExE Boss <duke at openjdk.org> wrote:

> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess.

I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467809826

From iklam at openjdk.org  Tue Oct 28 04:10:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:10:01 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v2]
In-Reply-To: <gCHojoxWDS4EbVrCfCOVguthRzpMA6LCcY67V5dR_b8=.654ea71c-1613-45a2-b10c-e21d4656f559@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
 <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>
 <OX-wQE2nG9P-Z0-oPjLlWzZO3Sl0Wrkj8moXNPaHQug=.4efa2e49-c6b6-463d-861e-369ebad5970b@github.com>
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
 <y6NYOWeZb2VJX0BxDNE0yNNg0d2db7_nYjbbtO5GRNQ=.becb9811-ad5a-4100-9f63-905ec8841463@github.com>
 <FsceKc9CJ1poYYrpDNi8Ubc2rbtyxD3FIA1TSADAUcA=.4e53b04b-49eb-4ca4-b135-06a31cc1beae@github.com>
 <gCHojoxWDS4EbVrCfCOVguthRzpMA6LCcY67V5dR_b8=.654ea71c-1613-45a2-b10c-e21d4656f559@github.com>
Message-ID: <HMXjm10-zLEnOXG0WkPU-d1yV4v30GlG6CzqXe2l_Lo=.9763d29f-78e2-468c-a05d-83d05f4b7714@github.com>

On Tue, 28 Oct 2025 04:03:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The?`ObjectInputStreamReadString` interface should?just be?merged into?`ObjectInputStreamAccess`:
>> 
>> SharedSecrets.setJavaObjectInputStreamAccess(new ObjectInputStreamAccess() {
>> 	public void checkArray(ObjectInputStream ois, Class<?> arrayType, int arrayLength) throws ObjectStreamException {
>> 		ois.checkArray(arrayType, arrayLength);
>> 	}
>> 
>> 	public String readString(ObjectInputStream ois) throws IOException {
>> 		return ois.readString();
>> 	}
>> });
>
>> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess.
> 
> I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE?

> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?

@DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467814022

From iklam at openjdk.org  Tue Oct 28 04:15:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 04:15:39 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v3]
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: <STzfZappcnAmi0f36aXlm0zpNVuarJ_Z4_CZ2D9IYM4=.fb2c1fb6-475f-4000-90da-ef7ea1e2e017@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.

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

 - Merge branch 'master' into 8368199-add-aot-safe-class-initializer-annotation-to-shared-secrets
 - Added StatelessOopsFinder
 - 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27880/files
  - new: https://git.openjdk.org/jdk/pull/27880/files/c6ea93c3..6ae1172a

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

  Stats: 20837 lines in 485 files changed: 12666 ins; 4954 del; 3217 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 alanb at openjdk.org  Tue Oct 28 07:00:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 07:00:03 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <QV5x3ifu4W23G6ObLyr0N87dJl42FMVMrbhQfxCLnlg=.1e26456b-b77d-44b3-94ec-d2956abadd59@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1044:

> 1042:      * already cancelled. This interrupts the threads executing unfinished subtasks. This
> 1043:      * method then waits for all threads to finish. If interrupted while waiting then it
> 1044:      * will continue to wait until the threads finish, before completing with the interrupted

Can you drop the change to this file from the PR as we have reworded this paragraph as part of the updated for JEP 525.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468133283

From alanb at openjdk.org  Tue Oct 28 07:52:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 07:52:03 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <lkMcK5XyH2Y_la8uIGT2EbV_PfVSagbCirDpFoiPhNI=.218bbaec-0ad7-48be-9909-29668893d58d@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

I skimmed through the replace and it looks okay. There are several places where we should be linking as "interrupted status" will look like a grammatical error with the change. We do that as needed, not this PR.

This is the first update to some of these files in 2025 so you will need to update the copyright header of those files.

src/java.base/share/classes/java/net/DatagramSocket.java line 614:

> 612:      *        interrupting a thread receiving a datagram packet will close the
> 613:      *        underlying channel and cause this method to throw {@link
> 614:      *        java.nio.channels.ClosedByInterruptException} with the interrupted

Can you change this to "the thread's interrupted status set"?

src/java.base/share/classes/java/net/DatagramSocket.java line 620:

> 618:      *        datagram packet. In that case, interrupting the virtual thread will
> 619:      *        cause it to wakeup and close the socket. This method will then throw
> 620:      *        {@code SocketException} with the interrupted status set.

Same thing here, and in ServerSocket and Socket.

test/jdk/java/lang/Thread/virtual/CustomScheduler.java line 207:

> 205: 
> 206:     /**
> 207:      * Test running task with the carrier interrupted status set.

We can change this to "the carrier's interrupted status set".

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387081610
PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468253205
PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468257078
PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468273763

From vyazici at openjdk.org  Tue Oct 28 08:47:31 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 28 Oct 2025 08:47:31 GMT
Subject: RFR: 8366575: Remove SDP support
Message-ID: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>

Remove support for [SDP] (Sockets Direct Protocol), which has been obsolete for more than a decade ? see [JDK-8366575] for details. Tier1-2 is clear.

[SDP]: https://docs.oracle.com/javase/tutorial/sdp/sockets/overview.html
[JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

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

Commit messages:
 - Remove SDP support

Changes: https://git.openjdk.org/jdk/pull/28012/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28012&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366575
  Stats: 732 lines in 13 files changed: 0 ins; 732 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28012.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28012/head:pull/28012

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

From alanb at openjdk.org  Tue Oct 28 09:01:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 09:01:01 GMT
Subject: RFR: 8366575: Remove SDP support
In-Reply-To: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
References: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
Message-ID: <GKDB0dUTqK7yqlaqlGjnL711m7zTtd6QHHg4t6BZe_w=.ab01ef9f-524c-4381-945d-efa5cceeb03d@github.com>

On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Remove support for [SDP] (Sockets Direct Protocol), which has been obsolete for more than a decade ? see [JDK-8366575] for details. Tier1-2 is clear.
> 
> [SDP]: https://docs.oracle.com/javase/tutorial/sdp/sockets/overview.html
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

The tests for this feature were removed by "JEP 381: Remove the Solaris and SPARC Ports" and I don't think there are any other tests to purge.

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

PR Comment: https://git.openjdk.org/jdk/pull/28012#issuecomment-3455289444

From prappo at openjdk.org  Tue Oct 28 10:06:36 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Oct 2025 10:06:36 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v2]
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <yc7z0Iro9HRJNOfaF6av4z0ZeBJ7UAG2lKTz7k21h68=.88323ef5-6349-4360-8306-442113ec3de0@github.com>

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision:

 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
    + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
    + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
    + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
    + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
    + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf
    + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d
    + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d
 - Reword for clarity as suggested
 - Drop to ease upcoming merge from loom repo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27972/files
  - new: https://git.openjdk.org/jdk/pull/27972/files/a10f8b43..89dbafe0

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

  Stats: 67 lines in 47 files changed: 4 ins; 0 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/27972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972

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

From alanb at openjdk.org  Tue Oct 28 10:10:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 10:10:11 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v2]
In-Reply-To: <yc7z0Iro9HRJNOfaF6av4z0ZeBJ7UAG2lKTz7k21h68=.88323ef5-6349-4360-8306-442113ec3de0@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <yc7z0Iro9HRJNOfaF6av4z0ZeBJ7UAG2lKTz7k21h68=.88323ef5-6349-4360-8306-442113ec3de0@github.com>
Message-ID: <lepfhtvr9Gy7c6wi7Lww4O5l_Fc9HqBdmYsTqOe51Pc=.0e9c56fd-40bc-460c-87f3-aa34f659d111@github.com>

On Tue, 28 Oct 2025 10:06:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
>     + update test/...

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387827557

From mullan at openjdk.org  Tue Oct 28 12:05:03 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 Oct 2025 12:05:03 GMT
Subject: RFR: 8368301: sun/security/util/math/intpoly compiler warnings
In-Reply-To: <qwlt_PttmkLy21-4fEtX37Teg__YPRZhlgkFM_E78wg=.7d861593-ef44-4ad3-a55c-2df6f70e7b5d@github.com>
References: <qwlt_PttmkLy21-4fEtX37Teg__YPRZhlgkFM_E78wg=.7d861593-ef44-4ad3-a55c-2df6f70e7b5d@github.com>
Message-ID: <1Z0cbxkKc67VRI19O0bBvHBzNIP_dhw5zuraLN3h2yE=.e8a0cc92-50ca-430b-bbad-7519ff5f8ed2@github.com>

On Fri, 24 Oct 2025 02:35:03 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The classes are all generated; the actual bug is on line 631 of make/jdk/src/classes/build/tools/intpoly/FieldGen.java.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27967#pullrequestreview-3388423636

From weijun at openjdk.org  Tue Oct 28 13:31:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 28 Oct 2025 13:31:58 GMT
Subject: RFR: 8325513: Export method for Cipher [v6]
In-Reply-To: <BwloSiI6cpATvQIc-BrAjeQ2ciooWABjZqSmhbFzpnk=.d960f6e7-6836-4a52-93a8-1905c57585a5@github.com>
References: <BwloSiI6cpATvQIc-BrAjeQ2ciooWABjZqSmhbFzpnk=.d960f6e7-6836-4a52-93a8-1905c57585a5@github.com>
Message-ID: <7JHIMPxyIa_q5bdIliMK3t8JEG0tYyHwWHbesLrEtvU=.550a2e05-d5c5-4910-a1a0-c90ca5641071@github.com>

> Add `Cipher::exportKey` API.

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

 - Merge branch 'master' into 8325513
 - new since, more UOE cases
 - Merge branch 'master' into 8325513
 - exportData
 - plural
 - Merge branch 'master' into 8325513
 - small update
 - Merge branch 'master' into 8325513
 - change new method to non final
 - rename
 - ... and 8 more: https://git.openjdk.org/jdk/compare/09946dbd...9f9cd651

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18409/files
  - new: https://git.openjdk.org/jdk/pull/18409/files/cd02570c..9f9cd651

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18409&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18409&range=04-05

  Stats: 616694 lines in 9446 files changed: 413711 ins; 137944 del; 65039 mod
  Patch: https://git.openjdk.org/jdk/pull/18409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18409/head:pull/18409

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

From mdonovan at openjdk.org  Tue Oct 28 13:45:36 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 28 Oct 2025 13:45:36 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <Fh8T3z8h0nSIy9d-KuCmNw277ReGv3tatAEFSdk5OGY=.a1364cb2-5e4b-432c-95a5-07e6472f1c3a@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

I'm still looking for a reviewer for this PR. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27342#issuecomment-3456540544

From abarashev at openjdk.org  Tue Oct 28 13:57:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 13:57:48 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <PbS8cZVmSo5vuXgmIR6s-oIV3GC4CgDrM2-bMYKdLS0=.d0d683b9-27d2-417a-b101-bb3fe96244ca@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 100:

> 98:                         getServerDname(),
> 99:                         serverKeys.getPublic(), caKeys.getPublic(),
> 100:                         CertificateBuilder.KeyUsage.DIGITAL_SIGNATURE, CertificateBuilder.KeyUsage.NONREPUDIATION, CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)

Line length > 80 here and below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2469675945

From heidinga at openjdk.org  Tue Oct 28 14:01:34 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 28 Oct 2025 14:01:34 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v3]
In-Reply-To: <HMXjm10-zLEnOXG0WkPU-d1yV4v30GlG6CzqXe2l_Lo=.9763d29f-78e2-468c-a05d-83d05f4b7714@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
 <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>
 <OX-wQE2nG9P-Z0-oPjLlWzZO3Sl0Wrkj8moXNPaHQug=.4efa2e49-c6b6-463d-861e-369ebad5970b@github.com>
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
 <y6NYOWeZb2VJX0BxDNE0yNNg0d2db7_nYjbbtO5GRNQ=.becb9811-ad5a-4100-9f63-905ec8841463@github.com>
 <FsceKc9CJ1poYYrpDNi8Ubc2rbtyxD3FIA1TSADAUcA=.4e53b04b-49eb-4ca4-b135-06a31cc1beae@github.com>
 <gCHojoxWDS4EbVrCfCOVguthRzpMA6LCcY67V5dR_b8=.654ea71c-1613-45a2-b10c-e21d4656f559@github.com>
 <HMXjm10-zLEnOXG0WkPU-d1yV4v30GlG6CzqXe2l_Lo=.9763d29f-78e2-468c-a05d-83d05f4b7714@github.com>
Message-ID: <AxVXUcqd3KWLl9NrYGEJiLBvmpOSmEz2lrKORJUcjLE=.9a2172ca-8ab0-4a5c-9e29-427154df3b11@github.com>

On Tue, 28 Oct 2025 04:06:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess.
>> 
>> I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE?
>
>> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?
> 
> @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors.

Can you update the comment on `SharedSecrets.java` to indicate that lambdas aren't safe to pre-initialize in this context?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2469685015

From abarashev at openjdk.org  Tue Oct 28 14:04:19 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 14:04:19 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <qc56pPUfOmwW6R26o7kQoyJRxJ88RdxDjwZLfyiR4Yw=.f48b61db-fca4-4e52-8bb8-565e2a498055@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

What about `javax/management/security/SecurityTest.java` unit test mentioned in the ticket?

test/jdk/javax/management/security/keystoreAgent line 1:

> 1: 0?

Why do we need this and other binary key stores if we generate certificates on the fly?

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

PR Comment: https://git.openjdk.org/jdk/pull/27342#issuecomment-3456634618
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2469688660

From prappo at openjdk.org  Tue Oct 28 14:25:06 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Oct 2025 14:25:06 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

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

 - Merge remote-tracking branch 'jdk/master' into 8370568
 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
    + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
    + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
    + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
    + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
    + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf
    + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d
    + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d
 - Reword for clarity as suggested
 - Drop to ease upcoming merge from loom repo
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27972/files
  - new: https://git.openjdk.org/jdk/pull/27972/files/89dbafe0..b3297337

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

  Stats: 3639 lines in 160 files changed: 1891 ins; 1140 del; 608 mod
  Patch: https://git.openjdk.org/jdk/pull/27972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972

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

From mdonovan at openjdk.org  Tue Oct 28 14:31:34 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 28 Oct 2025 14:31:34 GMT
Subject: RFR: 8359978: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java failed
 again with java.net.SocketException: An established connection was aborted by
 the software in your host machine
Message-ID: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>

This PR updates the TLS13PacketSize test so the client-side of the connection also reads any available data from the socket before closing. I have been unable to recreate the SocketException after 1000s of test iterations.

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

Commit messages:
 - 8359978: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java failed again with java.net.SocketException: An established connection was aborted by the software in your host machine

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

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

From fandreuzzi at openjdk.org  Tue Oct 28 14:31:35 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 28 Oct 2025 14:31:35 GMT
Subject: RFR: 8359978: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java
 failed again with java.net.SocketException: An established connection was
 aborted by the software in your host machine
In-Reply-To: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
References: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
Message-ID: <QyTNFUNVFJ1bJ3Xr0ajupAztKm4o4o_0TIxdwfUUNs4=.7fce711b-87c1-4c90-a666-d154358c33fb@github.com>

On Tue, 28 Oct 2025 14:24:59 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates the TLS13PacketSize test so the client-side of the connection also reads any available data from the socket before closing. I have been unable to recreate the SocketException after 1000s of test iterations.

test/jdk/javax/net/ssl/SSLSocket/Tls13PacketSize.java line 39:

> 37: import java.io.InputStream;
> 38: import java.io.OutputStream;
> 39: import java.util.concurrent.CountDownLatch;

This does not seem to be used in the diff

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28020#discussion_r2469798350

From abarashev at openjdk.org  Tue Oct 28 14:34:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 14:34:34 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <Knhrf0qPwT11jA-3ssyRE-BvAP7VmfABoIpxpolXt88=.c7ca5ca9-ca2d-4f1b-8fbe-3738458fc11b@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 42:

> 40: 
> 41: /*
> 42:  * @test id=tls13

What's the reason for having 2 separate `@test id=tls12` and `@test id=tls13` JTREG instructions blocks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2469814283

From myankelevich at openjdk.org  Tue Oct 28 15:14:46 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 28 Oct 2025 15:14:46 GMT
Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass
 when they should skip [v4]
In-Reply-To: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
References: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
Message-ID: <cZ4PMYo0FpEddQsTwVqDrAu1-nDYzePE0vIMNXfrZrU=.a761242e-4e5a-4b79-aa05-296994da658f@github.com>

> * test/jdk/sun/security/pkcs11/Signature/InitAgainPSS.java
> * test/jdk/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SigInteropPSS2.java
> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java
> * test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS2.java
> * test/jdk/sun/security/pkcs11/Signature/TestDSA.java

Mikhail Yankelevich has updated the pull request 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:

 - skip reworked
 - Merge branch 'master' into JDK-8367994
 - name changes for arrays
 - renamed  id
 - JDK-8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass when they should skip

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27367/files
  - new: https://git.openjdk.org/jdk/pull/27367/files/e4f20a3e..234aa5d0

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

  Stats: 196041 lines in 2592 files changed: 152809 ins; 26947 del; 16285 mod
  Patch: https://git.openjdk.org/jdk/pull/27367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27367/head:pull/27367

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

From myankelevich at openjdk.org  Tue Oct 28 15:14:48 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 28 Oct 2025 15:14:48 GMT
Subject: RFR: 8367994: test/jdk/sun/security/pkcs11/Signature/ tests pass
 when they should skip [v3]
In-Reply-To: <oYPS0kHDhC_p3kS5QrVzob-Qm4ciU5KZhV58f49mbf8=.070514a8-731a-4fa1-b249-db5c05fb4046@github.com>
References: <aJ-V4SR1B6xc9SiuPec0bQhTitVf2t9VlKcaaq4v0iY=.bc414457-6202-42b4-a38a-c0aaf23131f9@github.com>
 <LMLDnDU--pCT5UhpoSK-30hRZdhCuLGOLwZ5f2vmOT0=.cf47cb7a-81f4-4d44-874e-01b0ef9f7036@github.com>
 <oYPS0kHDhC_p3kS5QrVzob-Qm4ciU5KZhV58f49mbf8=.070514a8-731a-4fa1-b249-db5c05fb4046@github.com>
Message-ID: <I8_2Z90kbgyzNTPMuV5VrT618qxBCXrYuJoZaa0VsPI=.27e07ecc-4fae-47ed-92e4-f98d4a05ece0@github.com>

On Thu, 23 Oct 2025 16:49:06 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   name changes for arrays
>
> test/jdk/sun/security/pkcs11/Signature/SignatureTestPSS.java line 146:
> 
>> 144:                         mgfHash,
>> 145:                         s);
>> 146:                 skipTest = true;
> 
> I think skipTest logic in this test needs further updates. It starts with true as default value, should be false and only set skipTest to true when we encounter a test scenario that is not supported. I think there is also a case where skipTest value is overwritten at line 153 when called in a loop at line 95.

Done in the next commit. I have reworked it to be a list for easier debug in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27367#discussion_r2469957331

From jnimeh at openjdk.org  Tue Oct 28 16:33:57 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 28 Oct 2025 16:33:57 GMT
Subject: RFR: 8359978: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java
 failed again with java.net.SocketException: An established connection was
 aborted by the software in your host machine
In-Reply-To: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
References: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
Message-ID: <5iK-9K5YaHVHGhGZ_PZciE9QJz4R6HefmK9LgSL2eVk=.31dc3e86-7bb0-4de0-88b1-6ed51d0a6197@github.com>

On Tue, 28 Oct 2025 14:24:59 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates the TLS13PacketSize test so the client-side of the connection also reads any available data from the socket before closing. I have been unable to recreate the SocketException after 1000s of test iterations.

Looks good to me, taking into account the other comment.

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

Marked as reviewed by jnimeh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28020#pullrequestreview-3389734027

From jnimeh at openjdk.org  Tue Oct 28 16:46:28 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 28 Oct 2025 16:46:28 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <uUMZKMrdqiWeSDD8knA4Vm3H453yo4My9uhnAzY3Wd4=.7be6502e-b463-4c6b-93bb-285493760426@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <uUMZKMrdqiWeSDD8knA4Vm3H453yo4My9uhnAzY3Wd4=.7be6502e-b463-4c6b-93bb-285493760426@github.com>
Message-ID: <V-jl2voykmPgK8LSzT2NODaaQaYbCovKEkuHTe8NMig=.03e392f2-9ee2-473b-acd5-41f7e6263b3d@github.com>

On Mon, 27 Oct 2025 03:44:45 GMT, Xue-Lei Andrew Fan <xuelei 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
>
> src/java.base/share/classes/sun/security/util/Hybrid.java line 107:
> 
>> 105:     private static KEM getKEM(String name) throws NoSuchAlgorithmException {
>> 106:         if (APS.isGenericEC(name) || APS.isXDH(name)) {
>> 107:             return KEM.getInstance("DH", DH.PROVIDER);
> 
> May I get more information about the hard-coded provider DH.PROVIDER?  Could it be more general so that other KEM provider can also be used?

the DH provider is there give a KEM-like face on the NIST curves, x25519/448, etc., mainly for the purposes of assisting the work done within the hybrid KEM.  The underlying work being done by the internal DH provider still ends up doing KeyAgreement, KeyPairGenerator and KeyFactory operations, and those should go through the usual provider selection process.

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

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

From myankelevich at openjdk.org  Tue Oct 28 16:54:17 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 28 Oct 2025 16:54:17 GMT
Subject: RFR: 8369995: Fix StringIndexOutOfBoundsException and implement
 extra logging and/or propagate errors in X509KeyManagerImpl [v6]
In-Reply-To: <Qu6IFrBthtEW52W1o5AyRO6gF0rPwzg8xB_YN4RnHPs=.70cc5ebe-a2d0-40e6-91c5-d19c2238a46e@github.com>
References: <gaxEackG-mrQttFUVpkZ2sRzcrNUcRgTpkc6LLLsnxc=.6657f674-bf37-42eb-b5db-3f9cc1de64d9@github.com>
 <iqhH8MPGw9DIVAAbixaspt-9NuqvMa6iDGiwG-M9pIY=.da147df6-8ac6-460a-b627-74d29d27f94e@github.com>
 <Qu6IFrBthtEW52W1o5AyRO6gF0rPwzg8xB_YN4RnHPs=.70cc5ebe-a2d0-40e6-91c5-d19c2238a46e@github.com>
Message-ID: <Ms58GTnFEyUfFbTX8NjCbuUmaWvfOKx1y5xeaXXpTNg=.415a0712-1b38-4a4f-b62f-14ed15363688@github.com>

On Mon, 20 Oct 2025 08:11:21 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:
>> 
>>   Artur's comments
>
> Marked as reviewed by djelinski (Reviewer).

@djelinski @artur-oracle @bradfordwetmore Thank you for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/27851#issuecomment-3457485258

From myankelevich at openjdk.org  Tue Oct 28 16:54:19 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 28 Oct 2025 16:54:19 GMT
Subject: Integrated: 8369995: Fix StringIndexOutOfBoundsException and 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: <PUsJKQcatHHLGpIB62D_jeEx_BGhSfZjSkNnpP4JdWw=.ed5deabe-62f3-44f3-bf6f-9109efbfb6c1@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.
> 
> 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.

This pull request has now been integrated.

Changeset: 5ebc2c72
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ebc2c7212b21efe54c198f62f06e5edc68e8ec3
Stats:     401 lines in 3 files changed: 352 ins; 5 del; 44 mod

8369995: Fix StringIndexOutOfBoundsException and implement extra logging and/or propagate errors in X509KeyManagerImpl

Co-authored-by: Daniel Jeli?ski <djelinski at openjdk.org>
Reviewed-by: wetmore, djelinski, abarashev

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

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

From mdonovan at openjdk.org  Tue Oct 28 17:43:16 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 28 Oct 2025 17:43:16 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v2]
In-Reply-To: <qc56pPUfOmwW6R26o7kQoyJRxJ88RdxDjwZLfyiR4Yw=.f48b61db-fca4-4e52-8bb8-565e2a498055@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <qc56pPUfOmwW6R26o7kQoyJRxJ88RdxDjwZLfyiR4Yw=.f48b61db-fca4-4e52-8bb8-565e2a498055@github.com>
Message-ID: <6ZbsYB6U-1wWQ-Zhp6F-6tjCNxnPS27vUIEKjdzunXc=.5ca48952-3f96-4239-9b2a-b426709542be@github.com>

On Tue, 28 Oct 2025 13:58:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - fixed indents and copyright year
>>  - Merge branch 'master' into update-md5-certs
>>  - 8353738: Update TLS unit tests to not use certificates with MD5 signatures
>
> test/jdk/javax/management/security/keystoreAgent line 1:
> 
>> 1: 0?
> 
> Why do we need this and other binary key stores if we generate certificates on the fly?

This is related to your question about SecurityTest.java. 

SecurityTest.java has about 24 different @run instructions with different flags for each. Setting up keys and certificates programmatically looked like it would make the code more complicated and keeping the binary files seemed like the lesser of two evils.

> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 42:
> 
>> 40: 
>> 41: /*
>> 42:  * @test id=tls13
> 
> What's the reason for having 2 separate `@test id=tls12` and `@test id=tls13` JTREG instructions blocks?

I think it helps with organization and troubleshooting tests. Without it, you have to read fairly dense logs to see which @run command failed. With separate @test blocks, it's more obvious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470468093
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470461925

From mdonovan at openjdk.org  Tue Oct 28 17:43:12 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 28 Oct 2025 17:43:12 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v2]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <SreGhzKi-QWLcx0uQ1Z6yGUd0UAaJUswOlh4J1cm9Ns=.a860d13d-5f32-41df-bb77-8ab3fde048a9@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

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

 - fixed indents and copyright year
 - Merge branch 'master' into update-md5-certs
 - 8353738: Update TLS unit tests to not use certificates with MD5 signatures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/affe0fc9..a1933313

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

  Stats: 213159 lines in 2786 files changed: 164071 ins; 31722 del; 17366 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

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

From mdonovan at openjdk.org  Tue Oct 28 17:57:49 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 28 Oct 2025 17:57:49 GMT
Subject: RFR: 8359978: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java
 failed again with java.net.SocketException: An established connection was
 aborted by the software in your host machine [v2]
In-Reply-To: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
References: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
Message-ID: <ia1aWAW2le_xCj4rgZByUr0hxGOp_pa8moT0NxflB6g=.b67d61fe-7ae7-407a-b7b4-34d131ed06c3@github.com>

> This PR updates the TLS13PacketSize test so the client-side of the connection also reads any available data from the socket before closing. I have been unable to recreate the SocketException after 1000s of test iterations.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  removed unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28020/files
  - new: https://git.openjdk.org/jdk/pull/28020/files/4819c66f..54c435d2

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

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

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

From mullan at openjdk.org  Tue Oct 28 18:21:33 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 Oct 2025 18:21:33 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v16]
In-Reply-To: <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@github.com>
Message-ID: <qzECgjifzwpOAnpj2CT-KyDV3gugh4Yq5s4TiBY6VMc=.9efbdc6d-55e0-45f2-ba30-db0d434994f4@github.com>

On Mon, 27 Oct 2025 23:36:43 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:
> 
>   A4-A6 from RFC

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 153:

> 151:      * Encode PBKDF2 parameters from components.
> 152:      */
> 153:     public static byte[] encode(byte[] salt, int iterationCount,

This method actually encodes more than the parameters. It also encodes the outer algorithm id. I guess that's ok, but I suggest adding a comment that says that.

src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 159:

> 157:         DerOutputStream out = new DerOutputStream();
> 158:         DerOutputStream tmp0 = new DerOutputStream();
> 159:         DerOutputStream tmp1 = new DerOutputStream();

unused variable.

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

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

From jnimeh at openjdk.org  Tue Oct 28 18:30:15 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 28 Oct 2025 18:30:15 GMT
Subject: RFR: 8359978: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java
 failed again with java.net.SocketException: An established connection was
 aborted by the software in your host machine [v2]
In-Reply-To: <ia1aWAW2le_xCj4rgZByUr0hxGOp_pa8moT0NxflB6g=.b67d61fe-7ae7-407a-b7b4-34d131ed06c3@github.com>
References: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
 <ia1aWAW2le_xCj4rgZByUr0hxGOp_pa8moT0NxflB6g=.b67d61fe-7ae7-407a-b7b4-34d131ed06c3@github.com>
Message-ID: <xFBqZKDsrAkv90DyQVzuLkA4uxjkh4BZ_jZsGRLbdPI=.c2c5ad44-2b33-4150-ab48-1679471e3c21@github.com>

On Tue, 28 Oct 2025 17:57:49 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the TLS13PacketSize test so the client-side of the connection also reads any available data from the socket before closing. I have been unable to recreate the SocketException after 1000s of test iterations.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused import

Marked as reviewed by jnimeh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28020#pullrequestreview-3390248179

From mullan at openjdk.org  Tue Oct 28 18:33:32 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 Oct 2025 18:33:32 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v16]
In-Reply-To: <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@github.com>
Message-ID: <54AmW1yQHXl7Lg_oylTssnfk68YQDX5Gwu_CYELgeyc=.c958e2e1-d132-44e0-ad54-e73eb354af5e@github.com>

On Mon, 27 Oct 2025 23:36:43 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:
> 
>   A4-A6 from RFC

src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 118:

> 116:      * Encode PBMAC1 parameters from components.
> 117:      */
> 118:     static byte[] encode(byte[] salt, int iterationCount, int keyLength,

This is encoding more than the PBMAC1 parameters, it is also encoding the `DigestInfo` structure of the `MacData`. That should really be in the `MacData` class.

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

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

From djelinski at openjdk.org  Tue Oct 28 18:37:32 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 28 Oct 2025 18:37:32 GMT
Subject: RFR: 8359978: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java
 failed again with java.net.SocketException: An established connection was
 aborted by the software in your host machine [v2]
In-Reply-To: <ia1aWAW2le_xCj4rgZByUr0hxGOp_pa8moT0NxflB6g=.b67d61fe-7ae7-407a-b7b4-34d131ed06c3@github.com>
References: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
 <ia1aWAW2le_xCj4rgZByUr0hxGOp_pa8moT0NxflB6g=.b67d61fe-7ae7-407a-b7b4-34d131ed06c3@github.com>
Message-ID: <6EroSYnzCkC6AhkhhemD08mFyaLeUUvrHICza5bU9Ms=.c891178c-5e36-40a5-982e-0ea5b6deb73d@github.com>

On Tue, 28 Oct 2025 17:57:49 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the TLS13PacketSize test so the client-side of the connection also reads any available data from the socket before closing. I have been unable to recreate the SocketException after 1000s of test iterations.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused import

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28020#pullrequestreview-3390275206

From abarashev at openjdk.org  Tue Oct 28 18:40:26 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 18:40:26 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v2]
In-Reply-To: <6ZbsYB6U-1wWQ-Zhp6F-6tjCNxnPS27vUIEKjdzunXc=.5ca48952-3f96-4239-9b2a-b426709542be@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <qc56pPUfOmwW6R26o7kQoyJRxJ88RdxDjwZLfyiR4Yw=.f48b61db-fca4-4e52-8bb8-565e2a498055@github.com>
 <6ZbsYB6U-1wWQ-Zhp6F-6tjCNxnPS27vUIEKjdzunXc=.5ca48952-3f96-4239-9b2a-b426709542be@github.com>
Message-ID: <XzJpBFzVgu2ZhiThl6hjlOaux2Zst5dTATTLMqt6XAc=.56f7ea86-97b5-438b-8ebf-49ccbe899491@github.com>

On Tue, 28 Oct 2025 17:39:56 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> test/jdk/javax/management/security/keystoreAgent line 1:
>> 
>>> 1: 0?
>> 
>> Why do we need this and other binary key stores if we generate certificates on the fly?
>
> This is related to your question about SecurityTest.java. 
> 
> SecurityTest.java has about 24 different @run instructions with different flags for each. Setting up keys and certificates programmatically looked like it would make the code more complicated and keeping the binary files seemed like the lesser of two evils.

Oh, I see, it's a specific JMX test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470662409

From iklam at openjdk.org  Tue Oct 28 18:51:40 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 18:51:40 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
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: <roKMJDdhclGHzZdYASrcMiILtXbznHmEOK7cL5bySsI=.d64400d0-d4b2-434f-8107-b31a6773c7f5@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.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Updated comments about @AOTSafeClassInitializer in SharedSecrets.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27880/files
  - new: https://git.openjdk.org/jdk/pull/27880/files/6ae1172a..3121fd11

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

  Stats: 15 lines in 1 file changed: 12 ins; 3 del; 0 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 iklam at openjdk.org  Tue Oct 28 18:51:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Oct 2025 18:51:41 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
In-Reply-To: <AxVXUcqd3KWLl9NrYGEJiLBvmpOSmEz2lrKORJUcjLE=.9a2172ca-8ab0-4a5c-9e29-427154df3b11@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <Voz23MtDNgerq8y8HtX72dGS8-AK1VPxdKJQYHWSwNU=.eb101ad5-3fe2-43f4-8741-31b58757da2e@github.com>
 <O4BEICl3Y41-YTahUnelmioa7YL7E_WWwa86lM7GFkk=.55e05fe8-4fce-46e5-9b8a-8fe296d4d865@github.com>
 <OX-wQE2nG9P-Z0-oPjLlWzZO3Sl0Wrkj8moXNPaHQug=.4efa2e49-c6b6-463d-861e-369ebad5970b@github.com>
 <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com>
 <y6NYOWeZb2VJX0BxDNE0yNNg0d2db7_nYjbbtO5GRNQ=.becb9811-ad5a-4100-9f63-905ec8841463@github.com>
 <FsceKc9CJ1poYYrpDNi8Ubc2rbtyxD3FIA1TSADAUcA=.4e53b04b-49eb-4ca4-b135-06a31cc1beae@github.com>
 <gCHojoxWDS4EbVrCfCOVguthRzpMA6LCcY67V5dR_b8=.654ea71c-1613-45a2-b10c-e21d4656f559@github.com>
 <HMXjm10-zLEnOXG0WkPU-d1yV4v30GlG6CzqXe2l_Lo=.9763d29f-78e2-468c-a05d-83d05f4b7714@github.com>
 <AxVXUcqd3KWLl9NrYGEJiLBvmpOSmEz2lrKORJUcjLE=.9a2172ca-8ab0-4a5c-9e29-427154df3b11@github.com>
Message-ID: <w9CTlTzJICW3LWV3dwt5iau5h4d9MfzAh-zZ9fn6rqg=.f098ad0f-d1f2-497a-b49d-0dc03032ac17@github.com>

On Tue, 28 Oct 2025 13:57:46 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>>> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?
>> 
>> @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors.
>
> Can you update the comment on `SharedSecrets.java` to indicate that lambdas aren't safe to pre-initialize in this context?

I updated the comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2470693374

From heidinga at openjdk.org  Tue Oct 28 18:57:01 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 28 Oct 2025 18:57:01 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
In-Reply-To: <roKMJDdhclGHzZdYASrcMiILtXbznHmEOK7cL5bySsI=.d64400d0-d4b2-434f-8107-b31a6773c7f5@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <roKMJDdhclGHzZdYASrcMiILtXbznHmEOK7cL5bySsI=.d64400d0-d4b2-434f-8107-b31a6773c7f5@github.com>
Message-ID: <j4uoee3j33EHYYVu_wkBEiurXGnaCLRN7-U4Q3vSEHQ=.2a519f2f-2cad-48a8-9d0f-a5eb9284091b@github.com>

On Tue, 28 Oct 2025 18:51:40 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.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments about @AOTSafeClassInitializer in SharedSecrets.java

Marked as reviewed by heidinga (no project role).

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

PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3390359439

From jnimeh at openjdk.org  Tue Oct 28 19:03:57 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 28 Oct 2025 19:03:57 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
Message-ID: <ibWe7M2H-6eySrVoM2yVgsUrMuiMBRDm45D0J--GGME=.e61fbaec-517a-46d4-9b57-9f3ddf57aa7e@github.com>

On Mon, 27 Oct 2025 15:19:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call:
>> - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
>> - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Log unavailable configured signature scheme

src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 427:

> 425:                         var ss = SignatureScheme.nameOf(name);
> 426:                         if (ss == null && SSLLogger.isOn
> 427:                                 && SSLLogger.isOn("ssl,handshake")) {

Do you need both `SSLLogger.isOn` and the isOn check for ssl,handshake?  The latter check appears to only return true if it is both on and those flags have been set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2470709609

From abarashev at openjdk.org  Tue Oct 28 19:57:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 19:57:10 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <ibWe7M2H-6eySrVoM2yVgsUrMuiMBRDm45D0J--GGME=.e61fbaec-517a-46d4-9b57-9f3ddf57aa7e@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <ibWe7M2H-6eySrVoM2yVgsUrMuiMBRDm45D0J--GGME=.e61fbaec-517a-46d4-9b57-9f3ddf57aa7e@github.com>
Message-ID: <wsyhRoYzaFcsuaJs36e90ZTT0zl6jcqyBNMvbpbiEdU=.e4e8dd11-083c-4745-a82a-ce66b7b98eeb@github.com>

On Tue, 28 Oct 2025 18:52:44 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Log unavailable configured signature scheme
>
> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 427:
> 
>> 425:                         var ss = SignatureScheme.nameOf(name);
>> 426:                         if (ss == null && SSLLogger.isOn
>> 427:                                 && SSLLogger.isOn("ssl,handshake")) {
> 
> Do you need both `SSLLogger.isOn` and the isOn check for ssl,handshake?  The latter check appears to only return true if it is both on and those flags have been set.

Good catch! That's how we do it throughout SSL code and I just followed that :) Coincidently, I recently was thinking why we need to do all this checks every time we log instead of specifying the log options as a parameter, and here I have just found `SSLLogger.logWarning` method that does just that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2470865475

From weijun at openjdk.org  Tue Oct 28 20:02:26 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 28 Oct 2025 20:02:26 GMT
Subject: Integrated: 8370082: Intermediate objects clean up in ECDH, EdDSA,
 XDH, DHKEM, and HKDF
In-Reply-To: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
References: <xrwYJymt5xXnsk6jQim8Bg72ZiacGZwZANfxV8I0ZSc=.bb57acad-7c34-49e5-9f30-050b24a3d0f4@github.com>
Message-ID: <QtsXmfqOPHdUVYW37JoO0quMym_4NJUT21xwx56kwkc=.af30b622-d727-403b-ba45-a2d50f126959@github.com>

On Tue, 21 Oct 2025 17:17:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Clean up more intermediate objects created during these operations.

This pull request has now been integrated.

Changeset: 012b4eb6
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/012b4eb6cea6e1756a589a6c17a805867ed60686
Stats:     75 lines in 8 files changed: 52 ins; 3 del; 20 mod

8370082: Intermediate objects clean up in ECDH, EdDSA, XDH, DHKEM, and HKDF

Reviewed-by: ascarpino, abarashev, fandreuzzi

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

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

From jnimeh at openjdk.org  Tue Oct 28 20:27:25 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 28 Oct 2025 20:27:25 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <wsyhRoYzaFcsuaJs36e90ZTT0zl6jcqyBNMvbpbiEdU=.e4e8dd11-083c-4745-a82a-ce66b7b98eeb@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <ibWe7M2H-6eySrVoM2yVgsUrMuiMBRDm45D0J--GGME=.e61fbaec-517a-46d4-9b57-9f3ddf57aa7e@github.com>
 <wsyhRoYzaFcsuaJs36e90ZTT0zl6jcqyBNMvbpbiEdU=.e4e8dd11-083c-4745-a82a-ce66b7b98eeb@github.com>
Message-ID: <s-n_f3393nfyNVnYLI1ZznsAV1YX_AZu9Dc2zOqBbq0=.3c962da6-4027-41f0-948e-5e4aaa72f764@github.com>

On Tue, 28 Oct 2025 19:54:28 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 427:
>> 
>>> 425:                         var ss = SignatureScheme.nameOf(name);
>>> 426:                         if (ss == null && SSLLogger.isOn
>>> 427:                                 && SSLLogger.isOn("ssl,handshake")) {
>> 
>> Do you need both `SSLLogger.isOn` and the isOn check for ssl,handshake?  The latter check appears to only return true if it is both on and those flags have been set.
>
> Good catch! That's how we do it throughout SSL code and I just followed that :) Coincidently, I recently was thinking why we need to do all this checks every time we log instead of specifying the log options as a parameter, and here I have just found `SSLLogger.logWarning` method that does just that.

I agree, it would be nice to at least have a single method that does the enabled-or-not checking and can have the look and feel of either a println or a format.  But that's something to be done in another fix.  If you want to leave it as-is to follow convention I'm fine with that, and we can examine a friendlier way to do logging separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2470938885

From mullan at openjdk.org  Tue Oct 28 20:31:20 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 Oct 2025 20:31:20 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
Message-ID: <RqOWp2KgZGTJvReRUQl0qEgX37RynQAR__mLVCrM4VQ=.ca083d5a-120c-475a-a893-5b6d6834cf8a@github.com>

On Mon, 27 Oct 2025 15:19:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call:
>> - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
>> - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Log unavailable configured signature scheme

In the JBS issue, can you also add that you are enhancing java -XshowSettings:security:tls to show the enabled signature schemes?

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

PR Comment: https://git.openjdk.org/jdk/pull/27961#issuecomment-3458355121

From mullan at openjdk.org  Tue Oct 28 20:52:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 Oct 2025 20:52:54 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
Message-ID: <QLUr4oMNlel4RHYzklSlhKa4PCEHFLFyQFCoXXEmPMI=.fbae48c5-dcdf-4780-a014-92c54d71e2dd@github.com>

On Mon, 27 Oct 2025 15:19:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call:
>> - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
>> - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Log unavailable configured signature scheme

test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java line 101:

> 99:             runAndCheckException(() -> new RestrictNamedGroup().run(),
> 100:                     ex -> assertTrue(ex instanceof NoClassDefFoundError
> 101:                             || ex instanceof ExceptionInInitializerError));

I don't understand this change, can you help me understand this better? Why would these exceptions be thrown now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2471000408

From abarashev at openjdk.org  Tue Oct 28 21:15:33 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 21:15:33 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <QLUr4oMNlel4RHYzklSlhKa4PCEHFLFyQFCoXXEmPMI=.fbae48c5-dcdf-4780-a014-92c54d71e2dd@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <QLUr4oMNlel4RHYzklSlhKa4PCEHFLFyQFCoXXEmPMI=.fbae48c5-dcdf-4780-a014-92c54d71e2dd@github.com>
Message-ID: <8EEEQOnOXHyKopYxBzcMOIw7g4j_Iym61czy2GhgUAw=.2e13e116-96f4-4a71-b28f-5938f600bb77@github.com>

On Tue, 28 Oct 2025 20:49:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Log unavailable configured signature scheme
>
> test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java line 101:
> 
>> 99:             runAndCheckException(() -> new RestrictNamedGroup().run(),
>> 100:                     ex -> assertTrue(ex instanceof NoClassDefFoundError
>> 101:                             || ex instanceof ExceptionInInitializerError));
> 
> I don't understand this change, can you help me understand this better? Why would these exceptions be thrown now?

We do `NamedGroup` constraints check in `NamedGroup.SupportedGroups` now, so the test fails during `SSLConfiguration` object construction and not during TLS handshake as before. One exception is thrown with TLSv1.2 and another with TLSv1.3.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2471051783

From abarashev at openjdk.org  Tue Oct 28 21:23:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 21:23:58 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <s-n_f3393nfyNVnYLI1ZznsAV1YX_AZu9Dc2zOqBbq0=.3c962da6-4027-41f0-948e-5e4aaa72f764@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <ibWe7M2H-6eySrVoM2yVgsUrMuiMBRDm45D0J--GGME=.e61fbaec-517a-46d4-9b57-9f3ddf57aa7e@github.com>
 <wsyhRoYzaFcsuaJs36e90ZTT0zl6jcqyBNMvbpbiEdU=.e4e8dd11-083c-4745-a82a-ce66b7b98eeb@github.com>
 <s-n_f3393nfyNVnYLI1ZznsAV1YX_AZu9Dc2zOqBbq0=.3c962da6-4027-41f0-948e-5e4aaa72f764@github.com>
Message-ID: <Rm7r_FNBhgKgCRMdLhGwmRkIYNWrKpRS_BLaaX7ZpXs=.50ad405a-81a5-4f8d-af7b-a632afde08b8@github.com>

On Tue, 28 Oct 2025 20:24:36 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Good catch! That's how we do it throughout SSL code and I just followed that :) Coincidently, I recently was thinking why we need to do all these checks every time we log, instead we can specify the log options as a parameter. And here I have just found `SSLLogger.logWarning` method that does just that.
>
> I agree, it would be nice to at least have a single method that does the enabled-or-not checking and can have the look and feel of either a println or a format.  But that's something to be done in another fix.  If you want to leave it as-is to follow convention I'm fine with that, and we can examine a friendlier way to do logging separately.

Sounds good! I'll use `SSLLogger.logWarning` here and we can deal with logging separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2471070211

From mullan at openjdk.org  Tue Oct 28 21:27:41 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 28 Oct 2025 21:27:41 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <8EEEQOnOXHyKopYxBzcMOIw7g4j_Iym61czy2GhgUAw=.2e13e116-96f4-4a71-b28f-5938f600bb77@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <QLUr4oMNlel4RHYzklSlhKa4PCEHFLFyQFCoXXEmPMI=.fbae48c5-dcdf-4780-a014-92c54d71e2dd@github.com>
 <8EEEQOnOXHyKopYxBzcMOIw7g4j_Iym61czy2GhgUAw=.2e13e116-96f4-4a71-b28f-5938f600bb77@github.com>
Message-ID: <ioIZche4BnLIeRuabzo8U7wZSXdtzGoBWWGz_Om-tfQ=.a5f71be0-3ac4-47c3-b793-5eece65e1a42@github.com>

On Tue, 28 Oct 2025 21:13:02 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java line 101:
>> 
>>> 99:             runAndCheckException(() -> new RestrictNamedGroup().run(),
>>> 100:                     ex -> assertTrue(ex instanceof NoClassDefFoundError
>>> 101:                             || ex instanceof ExceptionInInitializerError));
>> 
>> I don't understand this change, can you help me understand this better? Why would these exceptions be thrown now?
>
> We do `NamedGroup` constraints check in `NamedGroup.SupportedGroups` now, so the test fails during `SSLConfiguration` object construction and not during TLS handshake as before. One exception is thrown with TLSv1.2 and another with TLSv1.3.

Hmm, I still need more info. Is this a behavior or specification change? Does a standard JSSE API now throw these exceptions instead of `SSLException`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2471083500

From ascarpino at openjdk.org  Tue Oct 28 21:57:21 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 28 Oct 2025 21:57:21 GMT
Subject: RFR: 8365069: Refactor tests to use PEM API (Phase 1)
In-Reply-To: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
References: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
Message-ID: <XprxRR_Jt1DrsOmHgfJ_NQwoL21lfeC6-qOVFSV3K1g=.31b17a1c-4b45-4987-bff4-d1e915de3975@github.com>

On Sat, 13 Sep 2025 04:44:13 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The following tests have been identified as candidates for phase 1 of this change.
> 2. test/jdk/javax/net/ssl/TLSCommon/TLSTest.java
> 3. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java
> 4. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilderWithMD5.java
> 5. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java
> 9. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java
> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
> 11. test/jdk/sun/security/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
> 13. test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java
> 16. test/jdk/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java
> 17. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java
> 18. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java
> 20. test/jdk/java/security/KeyStore/PKCS12/WriteP12Test.java
> 21. test/jdk/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java
> 22. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java
> 23. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java
> 24. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java
> 25. test/jdk/java/security/cert/CertPathValidator/trustAnchor/ValWithAnchorByName.java
> 30. test/jdk/java/security/KeyStore/TestKeyStoreBasic.java

test/jdk/java/security/KeyStore/PKCS12/WriteP12Test.java line 127:

> 125:     private final Certificate caCert;
> 126: 
> 127:     WriteP12Test() throws CertificateException {

As decode() only throws RuntimeExceptions, you don't need the throws anymore.  Also calling methods calling won't need to handle the exception either.

test/jdk/java/security/KeyStore/TestKeyStoreBasic.java line 40:

> 38: public class TestKeyStoreBasic {
> 39: 
> 40:     private static final String PRIVATE_KEY_PKCS8_BASE64 = """

nit:  this should probably be indented 4 chars from `private`.  Same location as the old code.

test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java line 202:

> 200: 
> 201:         // generate certificate from certificate string
> 202:         DEREncodable cert = PEM_DECODER.decode(targetCertStr, X509Certificate.class);

nit:  there is little value storing the decode() in a variable that is then added to `entries()`. You could do `entries.add(PEM_DECODER...)`

test/jdk/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java line 238:

> 236:         Collection<DEREncodable> crls = new HashSet<>();
> 237: 
> 238:         DEREncodable crl  = PEM_DECODER.decode(crlStr, X509CRL.class);

nit: similar to that storing in `crl` is not necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27267#discussion_r2456316474
PR Review Comment: https://git.openjdk.org/jdk/pull/27267#discussion_r2456332014
PR Review Comment: https://git.openjdk.org/jdk/pull/27267#discussion_r2461897266
PR Review Comment: https://git.openjdk.org/jdk/pull/27267#discussion_r2461943735

From ascarpino at openjdk.org  Tue Oct 28 22:00:56 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 28 Oct 2025 22:00:56 GMT
Subject: RFR: 8365069: Refactor tests to use PEM API (Phase 1)
In-Reply-To: <XprxRR_Jt1DrsOmHgfJ_NQwoL21lfeC6-qOVFSV3K1g=.31b17a1c-4b45-4987-bff4-d1e915de3975@github.com>
References: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
 <XprxRR_Jt1DrsOmHgfJ_NQwoL21lfeC6-qOVFSV3K1g=.31b17a1c-4b45-4987-bff4-d1e915de3975@github.com>
Message-ID: <Vn1XFAB4JLvKbgEcVtwo2TvLBfppPulm8wSUoi986hA=.0b23664a-f03e-4777-9379-7c1b2ad35b62@github.com>

On Fri, 24 Oct 2025 20:28:35 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> The following tests have been identified as candidates for phase 1 of this change.
>> 2. test/jdk/javax/net/ssl/TLSCommon/TLSTest.java
>> 3. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java
>> 4. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilderWithMD5.java
>> 5. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java
>> 9. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java
>> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
>> 11. test/jdk/sun/security/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
>> 13. test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java
>> 16. test/jdk/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java
>> 17. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java
>> 18. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java
>> 20. test/jdk/java/security/KeyStore/PKCS12/WriteP12Test.java
>> 21. test/jdk/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java
>> 22. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java
>> 23. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java
>> 24. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java
>> 25. test/jdk/java/security/cert/CertPathValidator/trustAnchor/ValWithAnchorByName.java
>> 30. test/jdk/java/security/KeyStore/TestKeyStoreBasic.java
>
> test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java line 202:
> 
>> 200: 
>> 201:         // generate certificate from certificate string
>> 202:         DEREncodable cert = PEM_DECODER.decode(targetCertStr, X509Certificate.class);
> 
> nit:  there is little value storing the decode() in a variable that is then added to `entries()`. You could do `entries.add(PEM_DECODER...)`

Note: there are a lot of these situation in the PR.  I'm fine if these are not changed, but I wanted to bring it to your attention.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27267#discussion_r2471172300

From abarashev at openjdk.org  Tue Oct 28 22:34:07 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 22:34:07 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <ioIZche4BnLIeRuabzo8U7wZSXdtzGoBWWGz_Om-tfQ=.a5f71be0-3ac4-47c3-b793-5eece65e1a42@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <QLUr4oMNlel4RHYzklSlhKa4PCEHFLFyQFCoXXEmPMI=.fbae48c5-dcdf-4780-a014-92c54d71e2dd@github.com>
 <8EEEQOnOXHyKopYxBzcMOIw7g4j_Iym61czy2GhgUAw=.2e13e116-96f4-4a71-b28f-5938f600bb77@github.com>
 <ioIZche4BnLIeRuabzo8U7wZSXdtzGoBWWGz_Om-tfQ=.a5f71be0-3ac4-47c3-b793-5eece65e1a42@github.com>
Message-ID: <LS3C3ysxgoR92VpCSe-todedAPMvYzPXtnurs3WzmAY=.f1b01da1-ad35-4b1c-b0f2-7096f4b2e11f@github.com>

On Tue, 28 Oct 2025 21:25:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We do `NamedGroup` constraints check in `NamedGroup.SupportedGroups` now, so the test fails during `SSLConfiguration` object construction and not during TLS handshake as before. One exception is thrown with TLSv1.2 and another with TLSv1.3.
>
> Hmm, I still need more info. Is this a behavior or specification change? Does a standard JSSE API now throw these exceptions instead of `SSLException`?

Correction: `ExceptionInInitializerError` is thrown on the first test iteration and `NoClassDefFoundError` is thrown on the subsequent iterations because the test runs all iterations in the same VM. The exception cause is [still the same](https://github.com/openjdk/jdk/blob/73f93920b950b4ce5fa177db50010e95265d6a7f/src/java.base/share/classes/sun/security/ssl/NamedGroup.java#L780), we would throw the same exception if the named group were unavailable instead of being algorithm-constrained.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2471233800

From abarashev at openjdk.org  Wed Oct 29 00:36:25 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 00:36:25 GMT
Subject: RFR: 8366364: Address inconsistencies in SSLParameters object
 returned by SSLConfiguration#getSSLParameters() call [v4]
In-Reply-To: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
Message-ID: <opSg8uOjAh76NmwJE-217j7zfR-dDvNhq8dXX5oAgvc=.00041d70-f1d2-46fe-8504-7b31d0361974@github.com>

> We need to address the following inconsistencies in SSLConfiguration#getSSLParameters() call:
> - For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
> - namedGroups return value is not being filtered against algorithm constraints, unlike other SSLParameters.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  - Use better logging method
  - Remove now unnecessary null check for config.signatureSchemes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27961/files
  - new: https://git.openjdk.org/jdk/pull/27961/files/f8721c93..a2235e0b

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

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

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

From rriggs at openjdk.org  Wed Oct 29 01:49:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Oct 2025 01:49:05 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
Message-ID: <v3sPAyJyhuAw4LHK4-chOQbBYB7dYiwWKkEywWCr9XM=.1215b812-d7f6-4217-af78-e753b53dd64d@github.com>

On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test...

Nice cleanup.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3391422490

From abarashev at openjdk.org  Wed Oct 29 02:00:06 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 02:00:06 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v2]
In-Reply-To: <SreGhzKi-QWLcx0uQ1Z6yGUd0UAaJUswOlh4J1cm9Ns=.a860d13d-5f32-41df-bb77-8ab3fde048a9@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <SreGhzKi-QWLcx0uQ1Z6yGUd0UAaJUswOlh4J1cm9Ns=.a860d13d-5f32-41df-bb77-8ab3fde048a9@github.com>
Message-ID: <_Uj-IKCUyXk183vz3D8_3dfUKA8NwrFxm5dRGbsgmfQ=.25bcae37-6622-4ce6-86f5-54abd430f312@github.com>

On Tue, 28 Oct 2025 17:43:12 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - fixed indents and copyright year
>  - Merge branch 'master' into update-md5-certs
>  - 8353738: Update TLS unit tests to not use certificates with MD5 signatures

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 222:

> 220:                     "MD2, RSA keySize < 1024");
> 221:             Security.setProperty("jdk.tls.disabledAlgorithms",
> 222:                     "SSLv3, RC4, DH keySize < 768");

I think we should remove only `MD5`, here and in all other tests:

            // If MD5 is used in this test case, don't disable MD5 algorithm.
            SecurityUtils.removeFromDisabledTlsAlgs("MD5");
            SecurityUtils.removeFromDisabledAlgs(
                          "jdk.certpath.disabledAlgorithms", List.of("MD5"));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2471528938

From dholmes at openjdk.org  Wed Oct 29 02:33:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Oct 2025 02:33:52 GMT
Subject: Integrated: 8370854: Add
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java to the ProblemList
Message-ID: <iFLXO-bINQ6Grc3djQAgJlFWtTrq2XKjDqFUtzuZb6o=.3aa877e0-807b-4ea0-b727-ff66fa40205a@github.com>

This new failure is causing a lot of noise in our CI.

Thanks

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

Commit messages:
 - 8370854: Add sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java to the ProblemList

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

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

From weijun at openjdk.org  Wed Oct 29 02:33:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 29 Oct 2025 02:33:53 GMT
Subject: Integrated: 8370854: Add
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java to the ProblemList
In-Reply-To: <iFLXO-bINQ6Grc3djQAgJlFWtTrq2XKjDqFUtzuZb6o=.3aa877e0-807b-4ea0-b727-ff66fa40205a@github.com>
References: <iFLXO-bINQ6Grc3djQAgJlFWtTrq2XKjDqFUtzuZb6o=.3aa877e0-807b-4ea0-b727-ff66fa40205a@github.com>
Message-ID: <x6XPqoRV0Tmb1mhAgs9BLe1nzaphrWrQJ8PslzP_uLw=.20030bbc-e468-414b-b4a9-d48673cc38d2@github.com>

On Wed, 29 Oct 2025 02:12:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This new failure is causing a lot of noise in our CI.
> 
> Thanks

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28034#pullrequestreview-3391471127

From dholmes at openjdk.org  Wed Oct 29 02:33:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Oct 2025 02:33:54 GMT
Subject: Integrated: 8370854: Add
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java to the ProblemList
In-Reply-To: <x6XPqoRV0Tmb1mhAgs9BLe1nzaphrWrQJ8PslzP_uLw=.20030bbc-e468-414b-b4a9-d48673cc38d2@github.com>
References: <iFLXO-bINQ6Grc3djQAgJlFWtTrq2XKjDqFUtzuZb6o=.3aa877e0-807b-4ea0-b727-ff66fa40205a@github.com>
 <x6XPqoRV0Tmb1mhAgs9BLe1nzaphrWrQJ8PslzP_uLw=.20030bbc-e468-414b-b4a9-d48673cc38d2@github.com>
Message-ID: <r20vX24ij4zKUJQVJtzMl93-ZfYR1z5CsRJy8bST-Lk=.3f1af8c1-8a8d-4027-b789-96193d84c55e@github.com>

On Wed, 29 Oct 2025 02:25:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This new failure is causing a lot of noise in our CI.
>> 
>> Thanks
>
> Marked as reviewed by weijun (Reviewer).

Thanks for the review @wangweij !

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

PR Comment: https://git.openjdk.org/jdk/pull/28034#issuecomment-3459379762

From dholmes at openjdk.org  Wed Oct 29 02:33:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Oct 2025 02:33:55 GMT
Subject: Integrated: 8370854: Add
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java to the ProblemList
In-Reply-To: <iFLXO-bINQ6Grc3djQAgJlFWtTrq2XKjDqFUtzuZb6o=.3aa877e0-807b-4ea0-b727-ff66fa40205a@github.com>
References: <iFLXO-bINQ6Grc3djQAgJlFWtTrq2XKjDqFUtzuZb6o=.3aa877e0-807b-4ea0-b727-ff66fa40205a@github.com>
Message-ID: <KeCDXMD_Ct1xHoRqJzgL5Zfz-bbippkX0O1FGA391A0=.f7b329cb-5854-41df-b8f7-cb8a250df790@github.com>

On Wed, 29 Oct 2025 02:12:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This new failure is causing a lot of noise in our CI.
> 
> Thanks

This pull request has now been integrated.

Changeset: 297a625f
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/297a625f1977a395ee9774772814924dbc79e708
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8370854: Add sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java to the ProblemList

Reviewed-by: weijun

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

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

From iklam at openjdk.org  Wed Oct 29 02:53:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 29 Oct 2025 02:53:09 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
In-Reply-To: <roKMJDdhclGHzZdYASrcMiILtXbznHmEOK7cL5bySsI=.d64400d0-d4b2-434f-8107-b31a6773c7f5@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <roKMJDdhclGHzZdYASrcMiILtXbznHmEOK7cL5bySsI=.d64400d0-d4b2-434f-8107-b31a6773c7f5@github.com>
Message-ID: <u-yE3mZUo8jGs74hHaKsLnKtKiiubXsslEA8FRvHYxA=.24283159-3602-4226-b702-c0d91ec1f5d7@github.com>

On Tue, 28 Oct 2025 18:51:40 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.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments about @AOTSafeClassInitializer in SharedSecrets.java

Thanks everyone for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27880#issuecomment-3459415761

From liach at openjdk.org  Wed Oct 29 03:23:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Oct 2025 03:23:04 GMT
Subject: RFR: 8368199: Add @AOTSafeClassInitializer to
 jdk.internal.access.SharedSecrets [v4]
In-Reply-To: <roKMJDdhclGHzZdYASrcMiILtXbznHmEOK7cL5bySsI=.d64400d0-d4b2-434f-8107-b31a6773c7f5@github.com>
References: <vyOZxtO2-tkLvC-fYZ4UYa2bJUfXJNp6AusmWoJWanU=.665074a0-4d38-4e27-ae8f-ecfd4100768c@github.com>
 <roKMJDdhclGHzZdYASrcMiILtXbznHmEOK7cL5bySsI=.d64400d0-d4b2-434f-8107-b31a6773c7f5@github.com>
Message-ID: <Yjt7BSbU7tX8UOlafu66EFjt5UyTmzr8ZqwgC7NuQRE=.631b79ae-27bd-4286-acf8-869c7c13b180@github.com>

On Tue, 28 Oct 2025 18:51:40 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.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments about @AOTSafeClassInitializer in SharedSecrets.java

The updated comments look very clear. Thanks!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3391539750

From iklam at openjdk.org  Wed Oct 29 03:26:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 29 Oct 2025 03:26:16 GMT
Subject: Integrated: 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: <Ucxfd3cNEEJUs5yLBD7bqx60EJaIH3q8p5W50QiN1MA=.1b3a221b-f30b-4870-b32b-c880a92de40c@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.

This pull request has now been integrated.

Changeset: 0687f120
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0687f120cc324f35fe43d811b6beb4184fd854ec
Stats:     260 lines in 10 files changed: 224 ins; 35 del; 1 mod

8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets

Reviewed-by: liach, heidinga

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

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

From abarashev at openjdk.org  Wed Oct 29 03:43:40 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 03:43:40 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v5]
In-Reply-To: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
Message-ID: <WR_HVpJzPDg4rlh730Qb9YTqzaytudTvEylAeuf9ekg=.da6a9cb3-5d58-44d3-a412-487021abe246@github.com>

> For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
> Also enhancing "java -XshowSettings:security:tls" option to show the enabled signature schemes.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Revert NamedGroup constraints filtering

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27961/files
  - new: https://git.openjdk.org/jdk/pull/27961/files/a2235e0b..f7052e03

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

  Stats: 27 lines in 3 files changed: 7 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27961.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27961/head:pull/27961

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

From abarashev at openjdk.org  Wed Oct 29 03:48:01 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 03:48:01 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <LS3C3ysxgoR92VpCSe-todedAPMvYzPXtnurs3WzmAY=.f1b01da1-ad35-4b1c-b0f2-7096f4b2e11f@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <QLUr4oMNlel4RHYzklSlhKa4PCEHFLFyQFCoXXEmPMI=.fbae48c5-dcdf-4780-a014-92c54d71e2dd@github.com>
 <8EEEQOnOXHyKopYxBzcMOIw7g4j_Iym61czy2GhgUAw=.2e13e116-96f4-4a71-b28f-5938f600bb77@github.com>
 <ioIZche4BnLIeRuabzo8U7wZSXdtzGoBWWGz_Om-tfQ=.a5f71be0-3ac4-47c3-b793-5eece65e1a42@github.com>
 <LS3C3ysxgoR92VpCSe-todedAPMvYzPXtnurs3WzmAY=.f1b01da1-ad35-4b1c-b0f2-7096f4b2e11f@github.com>
Message-ID: <qf-Zllg-IzwYtj3483TUneOrUmSQKJ8YA8Tfs29D8Og=.4b02d97a-f02a-4d0c-b3cb-e0cc2468f42a@github.com>

On Tue, 28 Oct 2025 22:31:49 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hmm, I still need more info. Is this a behavior or specification change? Does a standard JSSE API now throw these exceptions instead of `SSLException`?
>
> Correction: `ExceptionInInitializerError` is thrown on the first test iteration and `NoClassDefFoundError` is thrown on the subsequent iterations because the test runs all iterations in the same VM. The exception cause is [still the same](https://github.com/openjdk/jdk/blob/73f93920b950b4ce5fa177db50010e95265d6a7f/src/java.base/share/classes/sun/security/ssl/NamedGroup.java#L780), we would throw the same exception if the named group were unavailable instead of being algorithm-constrained.

On the closer look, I think filtering named groups is better to be dealt with as a separate issue. Removing namedGroup changes and renaming the ticket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2471646995

From jnimeh at openjdk.org  Wed Oct 29 04:11:07 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 29 Oct 2025 04:11:07 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: <tl-GneWhZEAEZuavgOja8mcUATtc3SF0OH8LazWN48E=.e8d22865-36d8-4941-b6f3-844c5996ee80@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

src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java line 1631:

> 1629:                     && (!tc.sslConfig.isClientMode
> 1630:                     || !tc.handshakeContext.statelessResumption
> 1631:                     || hasCompleted(SSLHandshake.NEW_SESSION_TICKET.id));

Stylistically this is a bit weird putting the comment mid-stream into a complex logical comparison.  I get why you're doing it here, but I think it will be easier to read things if the comment goes above the return statement.

src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 551:

> 549:                 if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
> 550:                     SSLLogger.info(
> 551:                             "Server doesn't support stateless resumption");

Would it be more accurate to indicate that the client is disabling stateless resumption due to the missing message?  Because, up to that point, the assumption is that the server does support this kind of resumption and now it's being turned off.
I'm curious, does this get run and the stateless resumption disabled if this scenario occurs:

- server receives client finish and verifies successfully
- server sends NST, but it goes AWOL
- server sends CCS
- server resends the lost NST
- server sends finish

Not sure if that scenario can happen since the CCS moves us onto the next epoch, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2471640638
PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2471652428

From duke at openjdk.org  Wed Oct 29 04:39:02 2025
From: duke at openjdk.org (duke)
Date: Wed, 29 Oct 2025 04:39:02 GMT
Subject: RFR: 8368301: sun/security/util/math/intpoly compiler warnings
In-Reply-To: <qwlt_PttmkLy21-4fEtX37Teg__YPRZhlgkFM_E78wg=.7d861593-ef44-4ad3-a55c-2df6f70e7b5d@github.com>
References: <qwlt_PttmkLy21-4fEtX37Teg__YPRZhlgkFM_E78wg=.7d861593-ef44-4ad3-a55c-2df6f70e7b5d@github.com>
Message-ID: <s37RmBUTuoHY3zgnqMB2NWtOJ1w-nI6GoUGPOCeVBdk=.c650a24c-09e8-4612-bf7c-a12b920ef01d@github.com>

On Fri, 24 Oct 2025 02:35:03 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The classes are all generated; the actual bug is on line 631 of make/jdk/src/classes/build/tools/intpoly/FieldGen.java.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27967#issuecomment-3459593424

From jpai at openjdk.org  Wed Oct 29 09:42:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 09:42:22 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
Message-ID: <qLpdKhKbOfwPeA1gneRLcXvylaEegFkQvElsKZsh-_k=.a1b88ff7-f4e9-4bcd-a0d4-52dccfa43b02@github.com>

On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test...

Hello Pavel, these changes look OK to me.

Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392430217

From prappo at openjdk.org  Wed Oct 29 10:25:59 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 10:25:59 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v4]
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <gg6TPlCojBnZ8qcFe6BtzrZ55ugS4EVLPBn-Yhjkv6A=.3904d4d5-bafe-4cc4-b566-2b3f8c2e01c4@github.com>

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

Pavel Rappo 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:

 - Fix one more occurrence
 - Merge remote-tracking branch 'jdk/master' into 8370568
 - Merge remote-tracking branch 'jdk/master' into 8370568
 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
    + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
    + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
    + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
    + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
    + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf
    + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d
    + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d
 - Reword for clarity as suggested
 - Drop to ease upcoming merge from loom repo
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27972/files
  - new: https://git.openjdk.org/jdk/pull/27972/files/b3297337..32e4c36a

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

  Stats: 2165 lines in 89 files changed: 1112 ins; 785 del; 268 mod
  Patch: https://git.openjdk.org/jdk/pull/27972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972

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

From prappo at openjdk.org  Wed Oct 29 10:26:00 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 10:26:00 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <qLpdKhKbOfwPeA1gneRLcXvylaEegFkQvElsKZsh-_k=.a1b88ff7-f4e9-4bcd-a0d4-52dccfa43b02@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
 <qLpdKhKbOfwPeA1gneRLcXvylaEegFkQvElsKZsh-_k=.a1b88ff7-f4e9-4bcd-a0d4-52dccfa43b02@github.com>
Message-ID: <OsOSZtU1oXKFaS2JB5H0w4E8zTaQKAM6felDUtAFfzQ=.a8af697e-0420-40a4-862a-c9582f8dca85@github.com>

On Wed, 29 Oct 2025 09:39:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Pavel, these changes look OK to me.
> 
> Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text.

Moving from "interrupted" to "interrupt" was a slow drift rather than a landslide. I think it's okay to repair it once. _Loom_ is already in and once _structured concurrency_ is in, I don't expect many new occurrences of "interrupt" in the foreseeable future. But you are right, the important bit is the specification, not the code comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/27972#issuecomment-3460767516

From jpai at openjdk.org  Wed Oct 29 10:29:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 10:29:34 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v4]
In-Reply-To: <gg6TPlCojBnZ8qcFe6BtzrZ55ugS4EVLPBn-Yhjkv6A=.3904d4d5-bafe-4cc4-b566-2b3f8c2e01c4@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <gg6TPlCojBnZ8qcFe6BtzrZ55ugS4EVLPBn-Yhjkv6A=.3904d4d5-bafe-4cc4-b566-2b3f8c2e01c4@github.com>
Message-ID: <scuwz6xRGZcJJf4dzvgO3vy1WipJBC3I3S4tA-0EcuU=.c4b8faf2-5638-4d92-8e3f-2aff06338e1e@github.com>

On Wed, 29 Oct 2025 10:25:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo 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:
> 
>  - Fix one more occurrence
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
> ...

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392609024

From mdonovan at openjdk.org  Wed Oct 29 11:08:02 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 29 Oct 2025 11:08:02 GMT
Subject: Integrated: 8359978: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java
 failed again with java.net.SocketException: An established connection was
 aborted by the software in your host machine
In-Reply-To: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
References: <2JqM_3o1lnDno5cXdVybqQQqFAoop1GJmvV4YU6xqD0=.103ce62c-6bcf-4a14-bce4-1c28249040bb@github.com>
Message-ID: <a8Q2csopLz4VO_qMGD-xTWGVo4FECMtf3mYgXRaD-RE=.033e650b-7b4c-4913-ba75-f4ebc01d3435@github.com>

On Tue, 28 Oct 2025 14:24:59 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates the TLS13PacketSize test so the client-side of the connection also reads any available data from the socket before closing. I have been unable to recreate the SocketException after 1000s of test iterations.

This pull request has now been integrated.

Changeset: 3cbcda5f
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3cbcda5ff3d86d65554a470571c5d72047e8d7f6
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8359978: Test javax/net/ssl/SSLSocket/Tls13PacketSize.java failed again with java.net.SocketException: An established connection was aborted by the software in your host machine

Reviewed-by: jnimeh, djelinski

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

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

From mdonovan at openjdk.org  Wed Oct 29 11:57:45 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 29 Oct 2025 11:57:45 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v3]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  changed tests to use SecurityUtils.removeDisabled*Algs methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/a1933313..4804c90d

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

  Stats: 35 lines in 5 files changed: 10 ins; 8 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

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

From mullan at openjdk.org  Wed Oct 29 13:52:32 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 29 Oct 2025 13:52:32 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <qf-Zllg-IzwYtj3483TUneOrUmSQKJ8YA8Tfs29D8Og=.4b02d97a-f02a-4d0c-b3cb-e0cc2468f42a@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <QLUr4oMNlel4RHYzklSlhKa4PCEHFLFyQFCoXXEmPMI=.fbae48c5-dcdf-4780-a014-92c54d71e2dd@github.com>
 <8EEEQOnOXHyKopYxBzcMOIw7g4j_Iym61czy2GhgUAw=.2e13e116-96f4-4a71-b28f-5938f600bb77@github.com>
 <ioIZche4BnLIeRuabzo8U7wZSXdtzGoBWWGz_Om-tfQ=.a5f71be0-3ac4-47c3-b793-5eece65e1a42@github.com>
 <LS3C3ysxgoR92VpCSe-todedAPMvYzPXtnurs3WzmAY=.f1b01da1-ad35-4b1c-b0f2-7096f4b2e11f@github.com>
 <qf-Zllg-IzwYtj3483TUneOrUmSQKJ8YA8Tfs29D8Og=.4b02d97a-f02a-4d0c-b3cb-e0cc2468f42a@github.com>
Message-ID: <uXVIomrHJQtQ2F4nzXUwwr3JVjPrZOSm67uzFyGI3YA=.4e601102-a130-40c7-9a10-a5cf4e610d87@github.com>

On Wed, 29 Oct 2025 03:45:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> On the closer look, I think filtering named groups is better to be dealt with as a separate issue. Removing namedGroup changes and renaming the ticket.

Ok, that's a good idea.

Would it be possible to add, or extend an existing test to check that `SSLParameters.getSignatureSchemes()` now returns the default schemes if the property is not set, and excludes schemes that are disabled?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2473186433

From weijun at openjdk.org  Wed Oct 29 13:56:25 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 29 Oct 2025 13:56:25 GMT
Subject: RFR: 8325513: Export method for Cipher [v7]
In-Reply-To: <BwloSiI6cpATvQIc-BrAjeQ2ciooWABjZqSmhbFzpnk=.d960f6e7-6836-4a52-93a8-1905c57585a5@github.com>
References: <BwloSiI6cpATvQIc-BrAjeQ2ciooWABjZqSmhbFzpnk=.d960f6e7-6836-4a52-93a8-1905c57585a5@github.com>
Message-ID: <x40ewU67yRZVVqcdgNdTte48BxrqR3w0ye33VN2W9Rw=.da1ef10a-08b1-42a8-bd9c-88b486635881@github.com>

> Add `Cipher::exportKey` API.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  state check; arg check; much more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18409/files
  - new: https://git.openjdk.org/jdk/pull/18409/files/9f9cd651..2da969c0

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

  Stats: 113 lines in 3 files changed: 82 ins; 3 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/18409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18409/head:pull/18409

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

From abarashev at openjdk.org  Wed Oct 29 14:30:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 14:30:49 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <uXVIomrHJQtQ2F4nzXUwwr3JVjPrZOSm67uzFyGI3YA=.4e601102-a130-40c7-9a10-a5cf4e610d87@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <QLUr4oMNlel4RHYzklSlhKa4PCEHFLFyQFCoXXEmPMI=.fbae48c5-dcdf-4780-a014-92c54d71e2dd@github.com>
 <8EEEQOnOXHyKopYxBzcMOIw7g4j_Iym61czy2GhgUAw=.2e13e116-96f4-4a71-b28f-5938f600bb77@github.com>
 <ioIZche4BnLIeRuabzo8U7wZSXdtzGoBWWGz_Om-tfQ=.a5f71be0-3ac4-47c3-b793-5eece65e1a42@github.com>
 <LS3C3ysxgoR92VpCSe-todedAPMvYzPXtnurs3WzmAY=.f1b01da1-ad35-4b1c-b0f2-7096f4b2e11f@github.com>
 <qf-Zllg-IzwYtj3483TUneOrUmSQKJ8YA8Tfs29D8Og=.4b02d97a-f02a-4d0c-b3cb-e0cc2468f42a@github.com>
 <uXVIomrHJQtQ2F4nzXUwwr3JVjPrZOSm67uzFyGI3YA=.4e601102-a130-40c7-9a10-a5cf4e610d87@github.com>
Message-ID: <dZyc_HoknFMq9lZDiD83kvjglNJHdwXO7WBI23tsrCM=.17eb4c62-738f-444b-9564-651cbb795392@github.com>

On Wed, 29 Oct 2025 13:48:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> On the closer look, I think filtering named groups is better to be dealt with as a separate issue. Removing namedGroup changes and renaming the ticket.
>
>> On the closer look, I think filtering named groups is better to be dealt with as a separate issue. Removing namedGroup changes and renaming the ticket.
> 
> Ok, that's a good idea.
> 
> Would it be possible to add, or extend an existing test to check that `SSLParameters.getSignatureSchemes()` now returns the default schemes if the property is not set, and excludes schemes that are disabled?

Sure, good idea to add a test. Basically we are replacing `null` pointer with `SupportedSigSchemes.DEFAULT` pointer but those values are not being used other than to return with `SSLConfiguration#getSSLParameters()` call. This is unlike `NamedGroup.SupportedGroups.namedGroups` values which are being (needlessly) looked up again and used in `NamedGroup` class. I've created JDK-8370885 to deal with it separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2473451711

From myankelevich at openjdk.org  Wed Oct 29 14:33:12 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 29 Oct 2025 14:33:12 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995
Message-ID: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>

Updated test to require `ssl,keymanager`, as it changed from `keymanager`.

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

Commit messages:
 - JDK-8370852: Test sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after JDK-8369995

Changes: https://git.openjdk.org/jdk/pull/28045/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28045&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370852
  Stats: 42 lines in 2 files changed: 11 ins; 4 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/28045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28045/head:pull/28045

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

From myankelevich at openjdk.org  Wed Oct 29 14:37:46 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 29 Oct 2025 14:37:46 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v2]
In-Reply-To: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
Message-ID: <DnLftmsOY_lJ4MP1c_aMdY8tkQEG9yzppBQnaezLUBw=.a323e5df-5dfd-4f79-8221-f510115da7ba@github.com>

> Updated test to require `ssl,keymanager`, as it changed from `keymanager`.

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

  JDK-8370852: Test sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after JDK-8369995

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28045/files
  - new: https://git.openjdk.org/jdk/pull/28045/files/1f82e22b..73c7346d

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

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

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

From abarashev at openjdk.org  Wed Oct 29 14:47:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 14:47:34 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v7]
In-Reply-To: <tl-GneWhZEAEZuavgOja8mcUATtc3SF0OH8LazWN48E=.e8d22865-36d8-4941-b6f3-844c5996ee80@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <3NyWRChxFJ0TOzOSX9oYNxoiYb0OM1SbcTHHArBueEE=.6f390963-ef3a-40c4-b01e-3fe5b0c5cf79@github.com>
 <tl-GneWhZEAEZuavgOja8mcUATtc3SF0OH8LazWN48E=.e8d22865-36d8-4941-b6f3-844c5996ee80@github.com>
Message-ID: <aj0WWIYgRfR301rl6BUYG9PTyJ0jPD0RsforcrD51Yc=.62c57f51-3ab6-4484-aa4e-980b5cd7280c@github.com>

On Wed, 29 Oct 2025 03:39:52 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> 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
>
> src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java line 1631:
> 
>> 1629:                     && (!tc.sslConfig.isClientMode
>> 1630:                     || !tc.handshakeContext.statelessResumption
>> 1631:                     || hasCompleted(SSLHandshake.NEW_SESSION_TICKET.id));
> 
> Stylistically this is a bit weird putting the comment mid-stream into a complex logical comparison.  I get why you're doing it here, but I think it will be easier to read things if the comment goes above the return statement.

Sounds good, I'll make the change, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2473555499

From abarashev at openjdk.org  Wed Oct 29 15:34:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 15:34:08 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v7]
In-Reply-To: <tl-GneWhZEAEZuavgOja8mcUATtc3SF0OH8LazWN48E=.e8d22865-36d8-4941-b6f3-844c5996ee80@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <3NyWRChxFJ0TOzOSX9oYNxoiYb0OM1SbcTHHArBueEE=.6f390963-ef3a-40c4-b01e-3fe5b0c5cf79@github.com>
 <tl-GneWhZEAEZuavgOja8mcUATtc3SF0OH8LazWN48E=.e8d22865-36d8-4941-b6f3-844c5996ee80@github.com>
Message-ID: <1UqZoDl3fdQsQkUbV6Jb8eQCwrYFNIL0_Gi3EYqf3Co=.46eba997-e3fd-4ff3-99c7-8da6a2b5251f@github.com>

On Wed, 29 Oct 2025 03:51:13 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> 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
>
> src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 551:
> 
>> 549:                 if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
>> 550:                     SSLLogger.info(
>> 551:                             "Server doesn't support stateless resumption");
> 
> Would it be more accurate to indicate that the client is disabling stateless resumption due to the missing message?  Because, up to that point, the assumption is that the server does support this kind of resumption and now it's being turned off.
> I'm curious, does this get run and the stateless resumption disabled if this scenario occurs:
> 
> - server receives client finish and verifies successfully
> - server sends NST, but it goes AWOL
> - server sends CCS
> - server resends the lost NST
> - server sends finish
> 
> Not sure if that scenario can happen since the CCS moves us onto the next epoch, right?

- Do you mean to use a different log message? The stateless session resumption is enabled by default, so if server doesn't send "session_ticket" extension we disable it on the client side. 
- We support DTLSv1.2 only and in v1.2 NST must come before CCS and finished, so verifying Finished would fail if NST goes missing (server and client would have different handshake hashes) - that's exactly what happens in this ticket we are fixing. And yes, CCS would set a new epoch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2473828413

From prappo at openjdk.org  Wed Oct 29 15:39:31 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 15:39:31 GMT
Subject: Integrated: 8370568: Refer to Thread.interrupted as
 "interrupted status" consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <uaeBmYjuxH0uTzmwhhHFy2gkyLBM1oT6f9PTUvlLIYs=.1da2ac77-fc8c-473a-8f67-dee5c28b327c@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

This pull request has now been integrated.

Changeset: 28f2591b
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28f2591bad49c4d1590325c3d315d850ab6bcc7d
Stats:     260 lines in 77 files changed: 4 ins; 0 del; 256 mod

8370568: Refer to Thread.interrupted as "interrupted status" consistently

Reviewed-by: jpai, rriggs, alanb

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

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

From abarashev at openjdk.org  Wed Oct 29 16:08:40 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 16:08:40 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v8]
In-Reply-To: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
Message-ID: <hUeOtJmjvHNQL4jvbGDa_lTUwLgL0xJFI-M3zkGrOAE=.ad55f5a2-d0fb-4a34-a29b-bd78de17865d@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:

  Place the comment goes above the return statement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27677/files
  - new: https://git.openjdk.org/jdk/pull/27677/files/13271c2e..fd39853d

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

  Stats: 5 lines in 1 file changed: 0 ins; 1 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 jnimeh at openjdk.org  Wed Oct 29 16:39:15 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 29 Oct 2025 16:39:15 GMT
Subject: RFR: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure [v8]
In-Reply-To: <hUeOtJmjvHNQL4jvbGDa_lTUwLgL0xJFI-M3zkGrOAE=.ad55f5a2-d0fb-4a34-a29b-bd78de17865d@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
 <hUeOtJmjvHNQL4jvbGDa_lTUwLgL0xJFI-M3zkGrOAE=.ad55f5a2-d0fb-4a34-a29b-bd78de17865d@github.com>
Message-ID: <ocdDI5piA6S7qVnkIGBwwVxhvS6CWyBMvsPppvsgavA=.e8c5f4ca-8a5e-4664-8440-a969da87bb41@github.com>

On Wed, 29 Oct 2025 16:08:40 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:
> 
>   Place the comment goes above the return statement

Marked as reviewed by jnimeh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27677#pullrequestreview-3394777862

From abarashev at openjdk.org  Wed Oct 29 17:29:35 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 17:29:35 GMT
Subject: Integrated: 8367059: DTLS: loss of NewSessionTicket message results in
 handshake failure
In-Reply-To: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
References: <KvHEPqdjh3ZXGaeX5gla0FlXHZVzY75KAb5RPGoC_EE=.971d4cec-d028-4475-aa25-45f447acec13@github.com>
Message-ID: <Tnz3eUjq2EAAeyG7SkudNsIcCCzdPO4LGGPUcQwsPhY=.09cfecd4-ec53-408d-b212-0dbacf84ed70@github.com>

On Tue, 7 Oct 2025 15:51: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.

This pull request has now been integrated.

Changeset: 436dc687
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/436dc687ba2ead1662a4e0125cea0966fac825e5
Stats:     348 lines in 6 files changed: 303 ins; 16 del; 29 mod

8367059: DTLS: loss of NewSessionTicket message results in handshake failure

Reviewed-by: jnimeh, djelinski

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

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

From mpowers at openjdk.org  Wed Oct 29 17:33:44 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 29 Oct 2025 17:33:44 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v16]
In-Reply-To: <54AmW1yQHXl7Lg_oylTssnfk68YQDX5Gwu_CYELgeyc=.c958e2e1-d132-44e0-ad54-e73eb354af5e@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@github.com>
 <54AmW1yQHXl7Lg_oylTssnfk68YQDX5Gwu_CYELgeyc=.c958e2e1-d132-44e0-ad54-e73eb354af5e@github.com>
Message-ID: <lERW86Dp8rg8eGBx0eyHFeGst7KpmdJeIHk9V1J2ULg=.9e595906-42fe-4e47-921b-9078fd82ebcb@github.com>

On Tue, 28 Oct 2025 18:30:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   A4-A6 from RFC
>
> src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 118:
> 
>> 116:      * Encode PBMAC1 parameters from components.
>> 117:      */
>> 118:     static byte[] encode(byte[] salt, int iterationCount, int keyLength,
> 
> This is encoding more than the PBMAC1 parameters, it is also encoding the `MacData` structure. That should really be in the `MacData` class.

I moved it to the `MacData` class as you suggest. `macSalt` ("NOT USED") and `iterations` (1) also belong in `MacData` and have been moved.

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 153:
> 
>> 151:      * Encode PBKDF2 parameters from components.
>> 152:      */
>> 153:     public static byte[] encode(byte[] salt, int iterationCount,
> 
> This method actually encodes more than the parameters. It also encodes the outer algorithm id. I guess that's ok, but I suggest adding a comment that says that.

added

> src/java.base/share/classes/sun/security/util/PBKDF2Parameters.java line 159:
> 
>> 157:         DerOutputStream out = new DerOutputStream();
>> 158:         DerOutputStream tmp0 = new DerOutputStream();
>> 159:         DerOutputStream tmp1 = new DerOutputStream();
> 
> unused variable.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2474349234
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2474348526
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2474348262

From myankelevich at openjdk.org  Wed Oct 29 17:58:12 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 29 Oct 2025 17:58:12 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs
In-Reply-To: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
Message-ID: <NpvSdBWcJFGBOd1wvIzUfpIcc1OtMQwW5MmYFk2ZAAk=.c51bbac5-136f-4ab0-8c1f-2346977de78f@github.com>

On Thu, 4 Sep 2025 16:20:18 GMT, Kirill Shirokov <duke at openjdk.org> wrote:

> The new tests cover only NPE scenarios.

~~Just 1 minor comment~~ scratch that, I'm confused :D

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

PR Review: https://git.openjdk.org/jdk/pull/27105#pullrequestreview-3186187295

From duke at openjdk.org  Wed Oct 29 17:58:11 2025
From: duke at openjdk.org (Kirill Shirokov)
Date: Wed, 29 Oct 2025 17:58:11 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs
Message-ID: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>

The new tests cover only NPE scenarios.

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

Commit messages:
 - 8366522: CodeSource.getCodeSigners() throws NPE within empty certs

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

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

From mpowers at openjdk.org  Wed Oct 29 20:40:17 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 29 Oct 2025 20:40:17 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v17]
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <foLNKesBTMCoy_NvJiuPalTntTvabqqlsyk_ktJ10iY=.3dd82c03-5044-40de-9980-a6777c82cbab@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:

  three comments and OID name change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24429/files
  - new: https://git.openjdk.org/jdk/pull/24429/files/9d2f61f6..e55d79f8

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

  Stats: 72 lines in 7 files changed: 26 ins; 28 del; 18 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 duke at openjdk.org  Wed Oct 29 20:54:56 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 29 Oct 2025 20:54:56 GMT
Subject: RFR: 8365069: Refactor tests to use PEM API (Phase 1) [v2]
In-Reply-To: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
References: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
Message-ID: <i3Taxyyib8yXlhpNIWA96sHLRJp0yvwaDMqm4q-_0EA=.8ee1a188-953b-4063-b70b-f85533ee3bc8@github.com>

> The following tests have been identified as candidates for phase 1 of this change.
> 2. test/jdk/javax/net/ssl/TLSCommon/TLSTest.java
> 3. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java
> 4. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilderWithMD5.java
> 5. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java
> 9. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java
> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
> 11. test/jdk/sun/security/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
> 13. test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java
> 16. test/jdk/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java
> 17. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java
> 18. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java
> 20. test/jdk/java/security/KeyStore/PKCS12/WriteP12Test.java
> 21. test/jdk/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java
> 22. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java
> 23. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java
> 24. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java
> 25. test/jdk/java/security/cert/CertPathValidator/trustAnchor/ValWithAnchorByName.java
> 30. test/jdk/java/security/KeyStore/TestKeyStoreBasic.java

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

 - 8365069: Addressing review comments
 - Merge branch 'master' into 8365069
 - 8365069: Refactor tests to use PEM API (Phase 1)
 - 8365069: Refactor tests to use PEM API (Phase 1)
 - 8365069: Refactor tests to use PEM API (Phase 1)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27267/files
  - new: https://git.openjdk.org/jdk/pull/27267/files/6b3ff25e..9c958e51

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

  Stats: 293693 lines in 4713 files changed: 210711 ins; 54294 del; 28688 mod
  Patch: https://git.openjdk.org/jdk/pull/27267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27267/head:pull/27267

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

From duke at openjdk.org  Wed Oct 29 20:54:59 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 29 Oct 2025 20:54:59 GMT
Subject: RFR: 8365069: Refactor tests to use PEM API (Phase 1) [v2]
In-Reply-To: <Vn1XFAB4JLvKbgEcVtwo2TvLBfppPulm8wSUoi986hA=.0b23664a-f03e-4777-9379-7c1b2ad35b62@github.com>
References: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
 <XprxRR_Jt1DrsOmHgfJ_NQwoL21lfeC6-qOVFSV3K1g=.31b17a1c-4b45-4987-bff4-d1e915de3975@github.com>
 <Vn1XFAB4JLvKbgEcVtwo2TvLBfppPulm8wSUoi986hA=.0b23664a-f03e-4777-9379-7c1b2ad35b62@github.com>
Message-ID: <bKG42o-n4FUwztK3pf1jNTGvQ3OLL4P0GDBdFoLsf4Y=.d41bd584-5a48-43c0-b97b-a2ce806f1f89@github.com>

On Tue, 28 Oct 2025 21:58:00 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java line 202:
>> 
>>> 200: 
>>> 201:         // generate certificate from certificate string
>>> 202:         DEREncodable cert = PEM_DECODER.decode(targetCertStr, X509Certificate.class);
>> 
>> nit:  there is little value storing the decode() in a variable that is then added to `entries()`. You could do `entries.add(PEM_DECODER...)`
>
> Note: there are a lot of these situation in the PR.  I'm fine if these are not changed, but I wanted to bring it to your attention.

Changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27267#discussion_r2475422341

From mullan at openjdk.org  Wed Oct 29 21:03:45 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 29 Oct 2025 21:03:45 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v17]
In-Reply-To: <foLNKesBTMCoy_NvJiuPalTntTvabqqlsyk_ktJ10iY=.3dd82c03-5044-40de-9980-a6777c82cbab@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <foLNKesBTMCoy_NvJiuPalTntTvabqqlsyk_ktJ10iY=.3dd82c03-5044-40de-9980-a6777c82cbab@github.com>
Message-ID: <LqfoWk3CRC2ijU7kia0QTN4ZMcfQ-7cScYZ12u8ysLw=.26d537c8-076d-4cdb-8ddc-e5cfb5a7ad60@github.com>

On Wed, 29 Oct 2025 20:40:17 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:
> 
>   three comments and OID name change

Looks good!

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24429#pullrequestreview-3396226107

From weijun at openjdk.org  Wed Oct 29 21:22:32 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 29 Oct 2025 21:22:32 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v16]
In-Reply-To: <lERW86Dp8rg8eGBx0eyHFeGst7KpmdJeIHk9V1J2ULg=.9e595906-42fe-4e47-921b-9078fd82ebcb@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@github.com>
 <54AmW1yQHXl7Lg_oylTssnfk68YQDX5Gwu_CYELgeyc=.c958e2e1-d132-44e0-ad54-e73eb354af5e@github.com>
 <lERW86Dp8rg8eGBx0eyHFeGst7KpmdJeIHk9V1J2ULg=.9e595906-42fe-4e47-921b-9078fd82ebcb@github.com>
Message-ID: <r-N1oQJd_CKCmOGO_4N2XA83wV6nn7ViNALlNdvQzYc=.e2f3a395-563d-43b1-8921-199f297d5670@github.com>

On Wed, 29 Oct 2025 17:30:17 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/PBMAC1Parameters.java line 118:
>> 
>>> 116:      * Encode PBMAC1 parameters from components.
>>> 117:      */
>>> 118:     static byte[] encode(byte[] salt, int iterationCount, int keyLength,
>> 
>> This is encoding more than the PBMAC1 parameters, it is also encoding the `MacData` structure. That should really be in the `MacData` class.
>
> I moved it to the `MacData` class as you suggest. `macSalt` ("NOT USED") and `iterations` (1) also belong in `MacData` and have been moved.

The latest `encode` returns two algorithm identifiers concatenated together without any frame. I suggest we follow the `PBKDF2Parameters.java` style you described below ("The outer algorithm ID is also encoded in addition to the parameters"), which means moving the code around `tmp2` and `tmp3` from `MacData::encode` here and back there a simple `tmp1.writeBytes(PBMAC1Parameters.encode(...))`.

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

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

From abarashev at openjdk.org  Wed Oct 29 23:00:38 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 23:00:38 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v6]
In-Reply-To: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
Message-ID: <YBtsy5ZziJ9vRePFLu9i8XiSE3bT4J18d4WgtaESglM=.d65e7e3f-12d0-419f-a721-2ac7833d8f46@github.com>

> For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
> Also enhancing "java -XshowSettings:security:tls" option to show the enabled signature schemes.

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

 - Adding a unit test
 - Merge branch 'master' into JDK-8366364
 - Revert NamedGroup constraints filtering
 - - Use better logging method
   - Remove now unnecessary null check for config.signatureSchemes
 - Log unavailable configured signature scheme
 - Adjust formatting
 - 8366364: Address inconsistencies in SSLParameters object returned by SSLConfiguration#getSSLParameters() call

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27961/files
  - new: https://git.openjdk.org/jdk/pull/27961/files/f7052e03..ef4877b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27961&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27961&range=04-05

  Stats: 19225 lines in 530 files changed: 12062 ins; 4716 del; 2447 mod
  Patch: https://git.openjdk.org/jdk/pull/27961.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27961/head:pull/27961

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

From abarashev at openjdk.org  Wed Oct 29 23:00:39 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 23:00:39 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v3]
In-Reply-To: <dZyc_HoknFMq9lZDiD83kvjglNJHdwXO7WBI23tsrCM=.17eb4c62-738f-444b-9564-651cbb795392@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <z_vhf5Jba2k2P5iVQV1b-v8wbIiCnqy6w_ObLkt-R3Y=.5517e3be-f534-4d88-848e-8fda6e7ae0f6@github.com>
 <QLUr4oMNlel4RHYzklSlhKa4PCEHFLFyQFCoXXEmPMI=.fbae48c5-dcdf-4780-a014-92c54d71e2dd@github.com>
 <8EEEQOnOXHyKopYxBzcMOIw7g4j_Iym61czy2GhgUAw=.2e13e116-96f4-4a71-b28f-5938f600bb77@github.com>
 <ioIZche4BnLIeRuabzo8U7wZSXdtzGoBWWGz_Om-tfQ=.a5f71be0-3ac4-47c3-b793-5eece65e1a42@github.com>
 <LS3C3ysxgoR92VpCSe-todedAPMvYzPXtnurs3WzmAY=.f1b01da1-ad35-4b1c-b0f2-7096f4b2e11f@github.com>
 <qf-Zllg-IzwYtj3483TUneOrUmSQKJ8YA8Tfs29D8Og=.4b02d97a-f02a-4d0c-b3cb-e0cc2468f42a@github.com>
 <uXVIomrHJQtQ2F4nzXUwwr3JVjPrZOSm67uzFyGI3YA=.4e601102-a130-40c7-9a10-a5cf4e610d87@github.com>
 <dZyc_HoknFMq9lZDiD83kvjglNJHdwXO7WBI23tsrCM=.17eb4c62-738f-444b-9564-651cbb795392@github.com>
Message-ID: <S0Zo-pLo-SlPIUDPTtxajCWnk05ZT-HLkmoIjs4L7hw=.5ac90cc1-9364-4935-bd75-51db3dd1b1c3@github.com>

On Wed, 29 Oct 2025 14:28:08 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>>> On the closer look, I think filtering named groups is better to be dealt with as a separate issue. Removing namedGroup changes and renaming the ticket.
>> 
>> Ok, that's a good idea.
>> 
>> Would it be possible to add, or extend an existing test to check that `SSLParameters.getSignatureSchemes()` now returns the default schemes if the property is not set, and excludes schemes that are disabled?
>
> Sure, good idea to add a test. Basically we are replacing `null` pointer with `SupportedSigSchemes.DEFAULT` pointer but those values are not being used other than to return with `SSLConfiguration#getSSLParameters()` call. This is unlike `NamedGroup.SupportedGroups.namedGroups` values which are being (needlessly) looked up again and used in `NamedGroup` class. I've created JDK-8370885 to deal with it separately.

Unit test added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2475875263

From aturbanov at openjdk.org  Thu Oct 30 09:06:29 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 30 Oct 2025 09:06:29 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v2]
In-Reply-To: <DnLftmsOY_lJ4MP1c_aMdY8tkQEG9yzppBQnaezLUBw=.a323e5df-5dfd-4f79-8221-f510115da7ba@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
 <DnLftmsOY_lJ4MP1c_aMdY8tkQEG9yzppBQnaezLUBw=.a323e5df-5dfd-4f79-8221-f510115da7ba@github.com>
Message-ID: <Q2GuBY15gHyg7jKM6Lw6IuhlOAi48wGBzgXtsNee0eU=.ed9ff9a9-13ea-46f1-bb3b-cd90c1568560@github.com>

On Wed, 29 Oct 2025 14:37:46 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Updated test to require `ssl,keymanager`, as it changed from `keymanager`.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8370852: Test sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after JDK-8369995

test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 182:

> 180:                         "-Djava.util.logging.config.file=" + LOG_FILE),
> 181:                         List.of("handshake", "javax.net.debug.logger",
> 182:                                 "ssl,keymanager", "packet",  "plaintext",

Suggestion:

                                "ssl,keymanager", "packet", "plaintext",

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28045#discussion_r2476965411

From coffeys at openjdk.org  Thu Oct 30 09:47:54 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 30 Oct 2025 09:47:54 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v2]
In-Reply-To: <DnLftmsOY_lJ4MP1c_aMdY8tkQEG9yzppBQnaezLUBw=.a323e5df-5dfd-4f79-8221-f510115da7ba@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
 <DnLftmsOY_lJ4MP1c_aMdY8tkQEG9yzppBQnaezLUBw=.a323e5df-5dfd-4f79-8221-f510115da7ba@github.com>
Message-ID: <3iVWbx_uHqQ1gJXXbqSW7Xey6hjsiPuQyZsXrZOxuJQ=.e25a9b47-fa28-44af-ad1a-0fb88bf76ce0@github.com>

On Wed, 29 Oct 2025 14:37:46 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Updated test to require `ssl,keymanager`, as it changed from `keymanager`.
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8370852: Test sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after JDK-8369995

test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @bug 8350582 8340312

no bug ID should be inserted for test only fixes (AFAIK)

test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 61:

> 59:                 List.of("Produced ClientHello handshake message",
> 60:                         "supported_versions"));
> 61:         debugMessages.put("keymanager", List.of("choosing key:"));

I believe this is your root cause. Needs to change to "Choosing key:" since you changed case in 8369995

test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 111:

> 109:                 // all should print everything
> 110:                 Arguments.of(List.of("-Djavax.net.debug=all"),
> 111:                         List.of("handshake", "ssl,keymanager", "packet",

These string values are keys in to the `debugMessages` Map. Please revert. The upper case letter change is all that's required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28045#discussion_r2477150033
PR Review Comment: https://git.openjdk.org/jdk/pull/28045#discussion_r2477155327
PR Review Comment: https://git.openjdk.org/jdk/pull/28045#discussion_r2477170614

From myankelevich at openjdk.org  Thu Oct 30 10:16:20 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 30 Oct 2025 10:16:20 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v3]
In-Reply-To: <3iVWbx_uHqQ1gJXXbqSW7Xey6hjsiPuQyZsXrZOxuJQ=.e25a9b47-fa28-44af-ad1a-0fb88bf76ce0@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
 <DnLftmsOY_lJ4MP1c_aMdY8tkQEG9yzppBQnaezLUBw=.a323e5df-5dfd-4f79-8221-f510115da7ba@github.com>
 <3iVWbx_uHqQ1gJXXbqSW7Xey6hjsiPuQyZsXrZOxuJQ=.e25a9b47-fa28-44af-ad1a-0fb88bf76ce0@github.com>
Message-ID: <SYbFMU1bYdGKa9PdtsY95Whv65HwxHGK7m2LAQx7H8s=.746a6468-3f53-4855-b0d6-5c89f9216f62@github.com>

On Thu, 30 Oct 2025 09:41:09 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - turbanoff's comment
>>  - choosing -> Choosing
>
> test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 26:
> 
>> 24: /**
>> 25:  * @test
>> 26:  * @bug 8350582 8340312
> 
> no bug ID should be inserted for test only fixes (AFAIK)

In this case I didn't put the current bug ID (test only one), only the product bug id which caused the error to occur. So I believe it's justified in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28045#discussion_r2477300098

From myankelevich at openjdk.org  Thu Oct 30 10:16:16 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 30 Oct 2025 10:16:16 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v3]
In-Reply-To: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
Message-ID: <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>

> Updated test to require `ssl,keymanager`, as it changed from `keymanager`.

Mikhail Yankelevich has updated the pull request incrementally with two additional commits since the last revision:

 - turbanoff's comment
 - choosing -> Choosing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28045/files
  - new: https://git.openjdk.org/jdk/pull/28045/files/73c7346d..1691d64f

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

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

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

From abarashev at openjdk.org  Thu Oct 30 10:20:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 30 Oct 2025 10:20:46 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v7]
In-Reply-To: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
Message-ID: <7MH_44Xrt4I0kElHTpadtbUS95EjzFyjA_ChdkTZrCY=.f32f1588-2dd0-4a97-83cc-3362e9a699d0@github.com>

> For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
> Also enhancing "java -XshowSettings:security:tls" option to show the enabled signature schemes.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Add null custom value test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27961/files
  - new: https://git.openjdk.org/jdk/pull/27961/files/ef4877b9..691048f1

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

  Stats: 25 lines in 1 file changed: 17 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27961.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27961/head:pull/27961

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

From mdonovan at openjdk.org  Thu Oct 30 12:00:31 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 30 Oct 2025 12:00:31 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v3]
In-Reply-To: <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
 <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>
Message-ID: <SizTtg0mqzEDKIgBemMq8pkolxGPLm6QMihVS0Iy10Y=.5f557fe7-742c-4047-99ec-e7f527b3b7b5@github.com>

On Thu, 30 Oct 2025 10:16:16 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Updated test to require `ssl,keymanager`, as it changed from `keymanager`.
>
> Mikhail Yankelevich has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - turbanoff's comment
>  - choosing -> Choosing

test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 61:

> 59:                 List.of("Produced ClientHello handshake message",
> 60:                         "supported_versions"));
> 61:         debugMessages.put("keymanager", List.of("Choosing key:"));

Is this what caused the test to fail? everything else looks like formatting changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28045#discussion_r2477827768

From myankelevich at openjdk.org  Thu Oct 30 12:00:32 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 30 Oct 2025 12:00:32 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v3]
In-Reply-To: <SizTtg0mqzEDKIgBemMq8pkolxGPLm6QMihVS0Iy10Y=.5f557fe7-742c-4047-99ec-e7f527b3b7b5@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
 <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>
 <SizTtg0mqzEDKIgBemMq8pkolxGPLm6QMihVS0Iy10Y=.5f557fe7-742c-4047-99ec-e7f527b3b7b5@github.com>
Message-ID: <W6ZUXdszrp9aPjl030gJBkivnco1a_qzcNOTQGrY6xs=.2a30ce67-2779-4160-865c-c931c2d81a77@github.com>

On Thu, 30 Oct 2025 11:55:54 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - turbanoff's comment
>>  - choosing -> Choosing
>
> test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 61:
> 
>> 59:                 List.of("Produced ClientHello handshake message",
>> 60:                         "supported_versions"));
>> 61:         debugMessages.put("keymanager", List.of("Choosing key:"));
> 
> Is this what caused the test to fail? everything else looks like formatting changes.

Yes, it was changed in JDK-8369995

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28045#discussion_r2477837498

From coffeys at openjdk.org  Thu Oct 30 12:31:55 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 30 Oct 2025 12:31:55 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v3]
In-Reply-To: <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
 <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>
Message-ID: <lB3t__KidUp8uB0bCrPnbVKxINDAke5AAO4IQ95gmI8=.7fa91092-7fdc-4ffb-b264-2a54685f1bdd@github.com>

On Thu, 30 Oct 2025 10:16:16 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Updated test to require `ssl,keymanager`, as it changed from `keymanager`.
>
> Mikhail Yankelevich has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - turbanoff's comment
>  - choosing -> Choosing

changes look good to me

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28045#pullrequestreview-3399360301

From coffeys at openjdk.org  Thu Oct 30 12:31:57 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 30 Oct 2025 12:31:57 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v3]
In-Reply-To: <SYbFMU1bYdGKa9PdtsY95Whv65HwxHGK7m2LAQx7H8s=.746a6468-3f53-4855-b0d6-5c89f9216f62@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
 <DnLftmsOY_lJ4MP1c_aMdY8tkQEG9yzppBQnaezLUBw=.a323e5df-5dfd-4f79-8221-f510115da7ba@github.com>
 <3iVWbx_uHqQ1gJXXbqSW7Xey6hjsiPuQyZsXrZOxuJQ=.e25a9b47-fa28-44af-ad1a-0fb88bf76ce0@github.com>
 <SYbFMU1bYdGKa9PdtsY95Whv65HwxHGK7m2LAQx7H8s=.746a6468-3f53-4855-b0d6-5c89f9216f62@github.com>
Message-ID: <OpW70OenbT0Z2WwXzEbcjtyre9z5eLHukmo6orjfMDI=.3aff355a-13bf-4880-853e-7e2dbf16665f@github.com>

On Thu, 30 Oct 2025 10:11:06 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 26:
>> 
>>> 24: /**
>>> 25:  * @test
>>> 26:  * @bug 8350582 8340312
>> 
>> no bug ID should be inserted for test only fixes (AFAIK)
>
> In this case I didn't put the current bug ID (test only one), only the product bug id which caused the error to occur. So I believe it's justified in this case.

ah, I see - yes, that seems fine then

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28045#discussion_r2477916230

From mullan at openjdk.org  Thu Oct 30 15:13:27 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 30 Oct 2025 15:13:27 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: <w4viPpBniC6pmXxhTPTKGTu5bJNgyOyECe_yRNiqOEI=.8e0eb096-f5ba-494b-84f1-0313efe466b8@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

test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java line 27:

> 25: /*
> 26:  * @test
> 27:  * @bug 8029661 8325164 8368073 8368514 8368520 8314323

This isn't specifically testing Hybrid Key Exchange, so I don't think the bugid should be added.

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

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

From mullan at openjdk.org  Thu Oct 30 15:35:58 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 30 Oct 2025 15:35:58 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: <beaFDJQPEi68X4bwLST2O6B7FqEUZYXk2jBKog-oP-k=.4f2190e8-8027-4d85-aa2d-e31627844a82@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

test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java line 1:

> 1: /*

Question: does disabling "x25519" also disable "X25519MLKEM768"? It probably should not. I think both groups would need to be specified in order to disable both. Please add a test for this case.

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

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

From jnimeh at openjdk.org  Thu Oct 30 15:53:56 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 30 Oct 2025 15:53:56 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <beaFDJQPEi68X4bwLST2O6B7FqEUZYXk2jBKog-oP-k=.4f2190e8-8027-4d85-aa2d-e31627844a82@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <beaFDJQPEi68X4bwLST2O6B7FqEUZYXk2jBKog-oP-k=.4f2190e8-8027-4d85-aa2d-e31627844a82@github.com>
Message-ID: <pcOUTK2m9SRD20TE0hW53WJKN3voOSha5ECdKmv9IRc=.f2cf13fc-965a-4f2c-9775-b579edcb1f6b@github.com>

On Thu, 30 Oct 2025 15:33:17 GMT, Sean Mullan <mullan 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/sun/security/ssl/CipherSuite/RestrictNamedGroup.java line 1:
> 
>> 1: /*
> 
> Question: does disabling "x25519" also disable "X25519MLKEM768"? It probably should not. I think both groups would need to be specified in order to disable both. Please add a test for this case.

It might depend on which level we're disabling things at.  If we're talking about knocking out x25519 in the namedGroups property then no, it won't disable the hybrid.  The client will just choose a different key share to use with X25519MLKEM768 in the initial client hello.  I know I've tried knocking out x25519 as a disabled algorithm in the past and I believe it will knock out the hybrid as well since the lower-level KeyAgreement operation in the DH provider that the hybrid uses should be blocked.  I can test that again to make sure my memory is correct on that point.

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

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

From jnimeh at openjdk.org  Thu Oct 30 16:21:27 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Thu, 30 Oct 2025 16:21:27 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <pcOUTK2m9SRD20TE0hW53WJKN3voOSha5ECdKmv9IRc=.f2cf13fc-965a-4f2c-9775-b579edcb1f6b@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <beaFDJQPEi68X4bwLST2O6B7FqEUZYXk2jBKog-oP-k=.4f2190e8-8027-4d85-aa2d-e31627844a82@github.com>
 <pcOUTK2m9SRD20TE0hW53WJKN3voOSha5ECdKmv9IRc=.f2cf13fc-965a-4f2c-9775-b579edcb1f6b@github.com>
Message-ID: <PF9fk6Tb0Bat851I6gb93O8JrosMVSWsbm1yBo6FSNo=.d1e19691-caec-4f9c-8f01-c4f6f03131d4@github.com>

On Thu, 30 Oct 2025 15:51:29 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java line 1:
>> 
>>> 1: /*
>> 
>> Question: does disabling "x25519" also disable "X25519MLKEM768"? It probably should not. I think both groups would need to be specified in order to disable both. Please add a test for this case.
>
> It might depend on which level we're disabling things at.  If we're talking about knocking out x25519 in the namedGroups property then no, it won't disable the hybrid.  The client will just choose a different key share to use with X25519MLKEM768 in the initial client hello.  I know I've tried knocking out x25519 as a disabled algorithm in the past and I believe it will knock out the hybrid as well since the lower-level KeyAgreement operation in the DH provider that the hybrid uses should be blocked.  I can test that again to make sure my memory is correct on that point.

Update: I was only half-right.  Via the `jdk.tls.namedGroups` property or SSLParameters, each named group stands on its own.  You can add or remove them without impacting the others.  When I took `x25519` out, it sent `X25519MLKEM768` and `secp256r1` key shares in the initial client hello.

Adding `x25519` to java.security (`jdk.tls.disabledAlgorithms`) does not prevent a hybrid with that component from functioning.  I just tested that a few moments ago.  I went back through some notes from a few months ago and I had that behavior documented there as well.

That seems consistent with what we say in the JEP about hybrid schemes: "... and is secure as long as one of the algorithms remains unbroken."

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

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

From mullan at openjdk.org  Thu Oct 30 16:29:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 30 Oct 2025 16:29:11 GMT
Subject: RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]
In-Reply-To: <PF9fk6Tb0Bat851I6gb93O8JrosMVSWsbm1yBo6FSNo=.d1e19691-caec-4f9c-8f01-c4f6f03131d4@github.com>
References: <8ehOGUhHt2onfe18iZGoE13WIM0SSQthqo6_qq5NHVU=.085f2554-76ae-408a-a4eb-9ec12cd4c43b@github.com>
 <aXXEMm8RBivud6zVmygpiRW0w3-c07Ji4bWAJoiK5iM=.a3810536-5eb4-461b-905c-2505b8a7c22f@github.com>
 <beaFDJQPEi68X4bwLST2O6B7FqEUZYXk2jBKog-oP-k=.4f2190e8-8027-4d85-aa2d-e31627844a82@github.com>
 <pcOUTK2m9SRD20TE0hW53WJKN3voOSha5ECdKmv9IRc=.f2cf13fc-965a-4f2c-9775-b579edcb1f6b@github.com>
 <PF9fk6Tb0Bat851I6gb93O8JrosMVSWsbm1yBo6FSNo=.d1e19691-caec-4f9c-8f01-c4f6f03131d4@github.com>
Message-ID: <jnNJmMGCrC4ILDwXRJElLJJSC-PfuCpPlA27YPC-c6I=.a806c2c4-e0f0-4a41-91c6-1feb87b0e612@github.com>

On Thu, 30 Oct 2025 16:18:11 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> It might depend on which level we're disabling things at.  If we're talking about knocking out x25519 in the namedGroups property then no, it won't disable the hybrid.  The client will just choose a different key share to use with X25519MLKEM768 in the initial client hello.  I know I've tried knocking out x25519 as a disabled algorithm in the past and I believe it will knock out the hybrid as well since the lower-level KeyAgreement operation in the DH provider that the hybrid uses should be blocked.  I can test that again to make sure my memory is correct on that point.
>
> Update: I was only half-right.  Via the `jdk.tls.namedGroups` property or SSLParameters, each named group stands on its own.  You can add or remove them without impacting the others.  When I took `x25519` out, it sent `X25519MLKEM768` and `secp256r1` key shares in the initial client hello.
> 
> Adding `x25519` to java.security (`jdk.tls.disabledAlgorithms`) does not prevent a hybrid with that component from functioning.  I just tested that a few moments ago.  I went back through some notes from a few months ago and I had that behavior documented there as well.
> 
> That seems consistent with what we say in the JEP about hybrid schemes: "... and is secure as long as one of the algorithms remains unbroken."

Good, the latter behavior was what I was questioning and I agree that is the way it should work.

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

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

From weijun at openjdk.org  Thu Oct 30 16:34:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 30 Oct 2025 16:34:12 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v4]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <HzlJasxY_-Jt_BEEylRbPJFnX0BupAcgABWr0lmN2Js=.a3202c8a-70e5-4dfd-ba24-146d190b3684@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into 8349732
 - rfc; test
 - some rename
 - Merge branch 'master' into 8349732
 - the fix

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

Changes: https://git.openjdk.org/jdk/pull/26563/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=03
  Stats: 555 lines in 9 files changed: 476 ins; 21 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/26563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26563/head:pull/26563

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

From rhalade at openjdk.org  Thu Oct 30 16:37:35 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Thu, 30 Oct 2025 16:37:35 GMT
Subject: RFR: 8366817:
 test/jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java and
 JdkProcClient.java should not delete logs [v2]
In-Reply-To: <bTuL1eZBqylP_sGNnQbCrudbn1PhDmv1nI1BObZzH6U=.e0a296a2-b69a-4ac2-af27-20f5a76b1be7@github.com>
References: <168uceKQ-mqaigIebpwYvP0GaL2d0uynUzSqiHd6M-Q=.4a48511e-cc1b-44be-9019-407612df2e25@github.com>
 <bTuL1eZBqylP_sGNnQbCrudbn1PhDmv1nI1BObZzH6U=.e0a296a2-b69a-4ac2-af27-20f5a76b1be7@github.com>
Message-ID: <jLJlU_HsgzXFmf5YhuBSFvPGqZGM6Yzl5fezVfzQ1cg=.787f77ff-e250-4822-a796-3a8a4cbe2cb6@github.com>

On Fri, 5 Sep 2025 13:57:29 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> The following test helpers delete logs after the test completes:
>> jdk/javax/net/ssl/TLSCommon/interop/JdkProcServer.java
>> jdk/javax/net/ssl/TLSCommon/interop/JdkProcClient.java
>> 
>> These helpers are used by tests located in jdk/javax/net/ssl/compatibility/*.java. Instead of explicitly deleting logs, cleanup should be handled by JTREG, as with other tests.
>> 
>> It is possible that the server process is still writing to this log when it tries to delete it, which could cause :
>>  
>> `java.nio.file.FileSystemException: server.log: The process cannot access the file because it is being used by another process`
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27076#pullrequestreview-3400592228

From mdonovan at openjdk.org  Thu Oct 30 16:57:33 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 30 Oct 2025 16:57:33 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v4]
In-Reply-To: <HzlJasxY_-Jt_BEEylRbPJFnX0BupAcgABWr0lmN2Js=.a3202c8a-70e5-4dfd-ba24-146d190b3684@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <HzlJasxY_-Jt_BEEylRbPJFnX0BupAcgABWr0lmN2Js=.a3202c8a-70e5-4dfd-ba24-146d190b3684@github.com>
Message-ID: <CU5Pv0gblNrlkPpy7-IuYxaWONt4t29LHhET96IUFcQ=.69aebfe3-86d8-4890-ac87-ec75ae12ec52@github.com>

On Thu, 30 Oct 2025 16:34:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add support for ML-DSA signing of JAR files.
>> 
>> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.
>> 
>> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into 8349732
>  - rfc; test
>  - some rename
>  - Merge branch 'master' into 8349732
>  - the fix

test/lib/jdk/test/lib/security/DataFetcher.java line 78:

> 76:         } else {
> 77:             try {
> 78:                 Path p = ArtifactResolver.resolve(klass).entrySet().stream()

You don't need to introduce a new property. `ArtifactResolver.resolve()` already looks for a System property of the form `jdk.test.lib.artifacts.NAME` (where NAME = the name from the @Artifact class). If the property is specified, its value is returned from `resolve()` unmodified. You can get the URL from there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2478847521

From mdonovan at openjdk.org  Thu Oct 30 17:07:41 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 30 Oct 2025 17:07:41 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v4]
In-Reply-To: <HzlJasxY_-Jt_BEEylRbPJFnX0BupAcgABWr0lmN2Js=.a3202c8a-70e5-4dfd-ba24-146d190b3684@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <HzlJasxY_-Jt_BEEylRbPJFnX0BupAcgABWr0lmN2Js=.a3202c8a-70e5-4dfd-ba24-146d190b3684@github.com>
Message-ID: <GQ-E9Hi0ehjm8LvxHCmOIVDIx3U_8xmHMsDQTkPmPEU=.5ad15dd6-4c5c-431b-bc64-c2260130f633@github.com>

On Thu, 30 Oct 2025 16:34:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add support for ML-DSA signing of JAR files.
>> 
>> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.
>> 
>> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into 8349732
>  - rfc; test
>  - some rename
>  - Merge branch 'master' into 8349732
>  - the fix

test/lib/jdk/test/lib/security/DataFetcher.java line 59:

> 57:     /// @param zipPrefix the common prefix for each entry in the ZIP file
> 58:     /// @param entry the entry name without `zipPrefix`
> 59:     public static byte[] fetchData(Class<?> klass, String zipPrefix, String entry)

Should this method be in `ArtifactResolver` instead or maybe just in the test itself? I don't see a general use for this based on other tests that use external "artifacts."

test/lib/jdk/test/lib/security/DataFetcher.java line 101:

> 99:             extension = "zip",
> 100:             unpack = false)
> 101:     public static class DILITHIUM_CERTIFICATES {

I think these should be defined in the tests where they are used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2478860158
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2478863336

From ascarpino at openjdk.org  Thu Oct 30 17:12:31 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 30 Oct 2025 17:12:31 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v12]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <j7SU3QnhGC9MjSGeyRn99lMVbBAt00L0--WqiwsQxqo=.81d021e1-2cef-4a70-959f-c90a8fc032c3@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:

  minor doc updates, fix some bugs, PEM set to 26

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/4bf48dda..e1405c06

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

  Stats: 159 lines in 7 files changed: 75 ins; 16 del; 68 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 mullan at openjdk.org  Thu Oct 30 17:18:38 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 30 Oct 2025 17:18:38 GMT
Subject: RFR: 8366522: CodeSource.getCodeSigners() throws NPE within empty
 certs
In-Reply-To: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
References: <I5O8fQD0GPZl96Pj80aeZ8t66bb1-qEtI6yiRWFeXes=.71ec33f9-96e1-4dc5-aaac-a1a0e26d72a9@github.com>
Message-ID: <iuC820AsZWHhQh5RuFAMS5oeCvZcvKp9L_8L4djIyzQ=.6d4c8925-8aad-456b-93b4-825978a328bb@github.com>

On Thu, 4 Sep 2025 16:20:18 GMT, Kirill Shirokov <duke at openjdk.org> wrote:

> The new tests cover only NPE scenarios.

src/java.base/share/classes/java/security/CodeSource.java line 241:

> 239:             // Convert the certs to code signers
> 240:             signers = convertCertArrayToSignerArray(certs);
> 241:             if (signers != null) {

I think this should return an empty array, and not null. This would make it consistent with `CodeSource.getCertificates()` which returns an empty array when a `CodeSource` object is constructed with an empty array of `CodeSigner`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27105#discussion_r2478909622

From duke at openjdk.org  Thu Oct 30 17:27:40 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 30 Oct 2025 17:27:40 GMT
Subject: Integrated: 8368301: sun/security/util/math/intpoly compiler warnings
In-Reply-To: <qwlt_PttmkLy21-4fEtX37Teg__YPRZhlgkFM_E78wg=.7d861593-ef44-4ad3-a55c-2df6f70e7b5d@github.com>
References: <qwlt_PttmkLy21-4fEtX37Teg__YPRZhlgkFM_E78wg=.7d861593-ef44-4ad3-a55c-2df6f70e7b5d@github.com>
Message-ID: <6zSoDXjJE5D82l2GitUdJKItq6r540wmJMjM6Kh0RPc=.2105b477-c10e-4c30-96ba-b2935948760c@github.com>

On Fri, 24 Oct 2025 02:35:03 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The classes are all generated; the actual bug is on line 631 of make/jdk/src/classes/build/tools/intpoly/FieldGen.java.

This pull request has now been integrated.

Changeset: d18e815b
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d18e815b94854406113344547f36358b5b5f6bb7
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8368301: sun/security/util/math/intpoly compiler warnings

Reviewed-by: mullan

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

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

From weijun at openjdk.org  Thu Oct 30 18:00:46 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 30 Oct 2025 18:00:46 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v4]
In-Reply-To: <GQ-E9Hi0ehjm8LvxHCmOIVDIx3U_8xmHMsDQTkPmPEU=.5ad15dd6-4c5c-431b-bc64-c2260130f633@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <HzlJasxY_-Jt_BEEylRbPJFnX0BupAcgABWr0lmN2Js=.a3202c8a-70e5-4dfd-ba24-146d190b3684@github.com>
 <GQ-E9Hi0ehjm8LvxHCmOIVDIx3U_8xmHMsDQTkPmPEU=.5ad15dd6-4c5c-431b-bc64-c2260130f633@github.com>
Message-ID: <7YmfaBg-AC1UZHR7WhS-upiKolPsh91n9jB1vIzVu64=.5ba1c17a-a71b-42cf-bdb7-5dc7032a212e@github.com>

On Thu, 30 Oct 2025 16:59:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into 8349732
>>  - rfc; test
>>  - some rename
>>  - Merge branch 'master' into 8349732
>>  - the fix
>
> test/lib/jdk/test/lib/security/DataFetcher.java line 59:
> 
>> 57:     /// @param zipPrefix the common prefix for each entry in the ZIP file
>> 58:     /// @param entry the entry name without `zipPrefix`
>> 59:     public static byte[] fetchData(Class<?> klass, String zipPrefix, String entry)
> 
> Should this method be in `ArtifactResolver` instead or maybe just in the test itself? I don't see a general use for this based on other tests that use external "artifacts."

If we have more similar ZIP bundles from GitHub repos, it could be general. I don't want to put it in `ArtifactResolver` yet.

> test/lib/jdk/test/lib/security/DataFetcher.java line 78:
> 
>> 76:         } else {
>> 77:             try {
>> 78:                 Path p = ArtifactResolver.resolve(klass).entrySet().stream()
> 
> You don't need to introduce a new property. `ArtifactResolver.resolve()` already looks for a System property of the form `jdk.test.lib.artifacts.NAME` (where NAME = the name from the @Artifact class). If the property is specified, its value is returned from `resolve()` unmodified. You can get the URL from there.

Yes, but that means I need to download the ZIP bundles somewhere. This new property allows me to work with local or remote repositories directly. Maybe not many people will use it.

> test/lib/jdk/test/lib/security/DataFetcher.java line 101:
> 
>> 99:             extension = "zip",
>> 100:             unpack = false)
>> 101:     public static class DILITHIUM_CERTIFICATES {
> 
> I think these should be defined in the tests where they are used.

Soon, `DILITHIUM_CERTIFICATES` will be used by KAT for RFC 9881 and whatever [draft-ietf-lamps-kyber-certificates](https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/) will be. We can revise the structure later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2479018342
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2479015653
PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2479021588

From abarashev at openjdk.org  Thu Oct 30 18:10:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 30 Oct 2025 18:10:59 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v8]
In-Reply-To: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
Message-ID: <NN8zPtICyMG_P2cvSC-HFT2NJQeshOdpJHWcTFQ-faw=.52a567e6-261b-45fa-ab15-0b5f3b300910@github.com>

> For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
> Also enhancing "java -XshowSettings:security:tls" option to show the enabled signature schemes.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Signatures schemes using sha224 are not available on Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27961/files
  - new: https://git.openjdk.org/jdk/pull/27961/files/691048f1..ae6aecbc

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

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

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

From mdonovan at openjdk.org  Thu Oct 30 18:28:45 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 30 Oct 2025 18:28:45 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v4]
In-Reply-To: <7YmfaBg-AC1UZHR7WhS-upiKolPsh91n9jB1vIzVu64=.5ba1c17a-a71b-42cf-bdb7-5dc7032a212e@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
 <HzlJasxY_-Jt_BEEylRbPJFnX0BupAcgABWr0lmN2Js=.a3202c8a-70e5-4dfd-ba24-146d190b3684@github.com>
 <GQ-E9Hi0ehjm8LvxHCmOIVDIx3U_8xmHMsDQTkPmPEU=.5ad15dd6-4c5c-431b-bc64-c2260130f633@github.com>
 <7YmfaBg-AC1UZHR7WhS-upiKolPsh91n9jB1vIzVu64=.5ba1c17a-a71b-42cf-bdb7-5dc7032a212e@github.com>
Message-ID: <ZoxnuLAb2asWIsQrjBR_PRnzv2Mhd6bsmPAhK7qDyMA=.1584a779-da85-4b4a-8a84-08b0fe4846bd@github.com>

On Thu, 30 Oct 2025 17:54:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/lib/jdk/test/lib/security/DataFetcher.java line 78:
>> 
>>> 76:         } else {
>>> 77:             try {
>>> 78:                 Path p = ArtifactResolver.resolve(klass).entrySet().stream()
>> 
>> You don't need to introduce a new property. `ArtifactResolver.resolve()` already looks for a System property of the form `jdk.test.lib.artifacts.NAME` (where NAME = the name from the @Artifact class). If the property is specified, its value is returned from `resolve()` unmodified. You can get the URL from there.
>
> Yes, but that means I need to download the ZIP bundles somewhere. This new property allows me to work with local or remote repositories directly. Maybe not many people will use it.

The other option is to set `unpack=true` on the artifact class and then walk the directory returned from `ArtifactResolver.resolve()` to find the files you need. That would require people to have the files on their local machine but makes it easier to run the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26563#discussion_r2479102456

From wetmore at openjdk.org  Thu Oct 30 18:40:01 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 30 Oct 2025 18:40:01 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v3]
In-Reply-To: <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
 <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>
Message-ID: <mJnQb2IWDb0tfvRpVv3e99qye2slUXIfDkH1cdJNz9c=.9508782d-db2d-46a1-ab71-76d236bc2b84@github.com>

On Thu, 30 Oct 2025 10:16:16 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Updated test to require `ssl,keymanager`, as it changed from `keymanager`.
>
> Mikhail Yankelevich has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - turbanoff's comment
>  - choosing -> Choosing

Took way to long to figure out that a capital letter changed in the SSL debug output, and that was causing the problem.   :)

Thank you for cleaning up the formatting.  Having lines <=80 sure helps with side/side comparisons like here in github.  

LGTM.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28045#pullrequestreview-3401109018

From alanb at openjdk.org  Thu Oct 30 18:48:23 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Oct 2025 18:48:23 GMT
Subject: RFR: 8366178: Implement JEP 526: Lazy Constants (Second Preview)
 [v20]
In-Reply-To: <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
References: <cgCEUSXiAdIu8XJxS_hmCwHevIkUDM8PYftCC9z8XnE=.8a6e191e-5574-47c3-a3a0-bd31b6fc3c98@github.com>
 <VwXBDgnb4wOJS9MTzrBNHzzRVvlkpysZrcrT0IIOutA=.fc1fd8ba-f415-490e-9adb-980daa25e67d@github.com>
Message-ID: <g_fFZjJl0S7uMAmyRjBqzs6-oP-M3n_-HGOWwv4_1rM=.04dfc4a8-9af6-482a-b016-aa1347e50bf3@github.com>

On Fri, 24 Oct 2025 09:01:10 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:
> 
>   Rework toString implementations

src/java.base/share/classes/java/util/List.java line 1200:

> 1198: 
> 1199:     /**
> 1200:      * {@return a new lazily computed list with the provided {@code size}}

A minor comment here is that  "of the given size" might be a bit clearer than "with the provided size".

src/java.base/share/classes/java/util/List.java line 1240:

> 1238:      * function used to compute elements only so long as there are uncomputed elements
> 1239:      * after which the computing function is not strongly referenced
> 1240:      * anymore and may be collected.

I think it's okay to say that the computing function is kept strongly reachable until at least all elements have been computed. I'm less sure about the second part being normative text and wonder if it would be better to move that part to an implNote.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2479172995
PR Review Comment: https://git.openjdk.org/jdk/pull/27605#discussion_r2479168408

From fferrari at openjdk.org  Thu Oct 30 19:32:15 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 30 Oct 2025 19:32:15 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v7]
In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
Message-ID: <KHapgqdbvkNuTLUAPcoctC8spD2ZF84uoelq1AQpwv0=.ffdcfd39-0729-4cdf-ae8b-cd0c600da614@github.com>

> 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/java.base/windows/native/libjava/c...

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

 - Merge openjdk:master into franferrax:JDK-8352728
 - 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.
 - Merge openjdk:master into franferrax:JDK-8352728
 - Fix typo
 - Merge openjdk:master into franferrax:JDK-8352728
 - Reintroduce links test using directory junctions
   
   Junctions do not require elevation, so this is a way of testing
   soft-links are resolved without requiring elevation. This is useful
   because we need to avoid elevation in order to reproduce the parent
   directories permission issue.
   
   This is testing directories structure:
   
    ? JDK-8352728-tmp-*/
    ??? jdk-parent-dir/         (ACL with REMOVED-PERMISSIONS)
    ? ??? jdk/
    ?   ??? conf/
    ?   ? ??? security/
    ?   ? ? ??? java.security
    ?   ? ? ?    ? include link-to-other-dir/other.properties
    ?   ? ? ??? link-to-other-dir/ ? ? JDK-8352728-tmp-*/other-dir
    ?   ? ? ??...               (JUNCTION)
    ?   ? ??...
    ?   ??...
    ??? other-dir/
    ? ??? other.properties
    ?      ? include ../relatively.included.properties
    ??? relatively.included.properties
         ? test.property.name=test_property_value
 - Do minor adjustments
   
   Update copyright year, improve comments and use File::toPath to convert
   back to Path.
 - Merge openjdk/master into JDK-8352728
 - 8352728: InternalError loading java.security due to Windows parent folder permissions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24465/files
  - new: https://git.openjdk.org/jdk/pull/24465/files/71718e52..4e77fb36

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

  Stats: 355945 lines in 5286 files changed: 245773 ins; 77995 del; 32177 mod
  Patch: https://git.openjdk.org/jdk/pull/24465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24465/head:pull/24465

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

From mpowers at openjdk.org  Thu Oct 30 21:09:57 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 30 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) [v18]
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <tjpxHB3mA2FyL4HonJzpaqXr2Z39TzH8_QfkDoaK57I=.263370c0-1c4b-40fe-99e4-4ad1da76f821@github.com>

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

Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - two algorithm identifiers concatenated together without any frame
 - merge
 - three comments and OID name change
 - A4-A6 from RFC
 - Weijun code review comments
 - merge
 - stragglers
 - checkpoint
 - remaining comments
 - more review comments from Sean and Weijun
 - ... and 26 more: https://git.openjdk.org/jdk/compare/a2196e20...409f34c5

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

Changes: https://git.openjdk.org/jdk/pull/24429/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24429&range=17
  Stats: 1079 lines in 11 files changed: 800 ins; 175 del; 104 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 ascarpino at openjdk.org  Thu Oct 30 21:26:06 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 30 Oct 2025 21:26:06 GMT
Subject: RFR: 8365069: Refactor tests to use PEM API (Phase 1) [v2]
In-Reply-To: <i3Taxyyib8yXlhpNIWA96sHLRJp0yvwaDMqm4q-_0EA=.8ee1a188-953b-4063-b70b-f85533ee3bc8@github.com>
References: <DsqvWZPzfHTHzZcUBlyHs6txGU41R38xovx3ZLsl2zM=.9752f9e0-1c05-4d4b-9b2e-3c4cd6e9b6a5@github.com>
 <i3Taxyyib8yXlhpNIWA96sHLRJp0yvwaDMqm4q-_0EA=.8ee1a188-953b-4063-b70b-f85533ee3bc8@github.com>
Message-ID: <2VtqLtqn8YMCbVGydBQ1JqOCK8D-PYUqB1_zrPo2SYg=.f6a2d64c-9c21-4af8-9aea-8c3f00e082a2@github.com>

On Wed, 29 Oct 2025 20:54:56 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The following tests have been identified as candidates for phase 1 of this change.
>> 2. test/jdk/javax/net/ssl/TLSCommon/TLSTest.java
>> 3. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java
>> 4. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPBuilderWithMD5.java
>> 5. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java
>> 9. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java
>> 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/PKIXExtendedTM.java
>> 11. test/jdk/sun/security/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java
>> 13. test/jdk/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java
>> 16. test/jdk/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java
>> 17. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java
>> 18. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java
>> 20. test/jdk/java/security/KeyStore/PKCS12/WriteP12Test.java
>> 21. test/jdk/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java
>> 22. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java
>> 23. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java
>> 24. test/jdk/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java
>> 25. test/jdk/java/security/cert/CertPathValidator/trustAnchor/ValWithAnchorByName.java
>> 30. test/jdk/java/security/KeyStore/TestKeyStoreBasic.java
>
> Koushik Muthukrishnan Thirupattur has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8365069: Addressing review comments
>  - Merge branch 'master' into 8365069
>  - 8365069: Refactor tests to use PEM API (Phase 1)
>  - 8365069: Refactor tests to use PEM API (Phase 1)
>  - 8365069: Refactor tests to use PEM API (Phase 1)

Looks good

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27267#pullrequestreview-3401718472

From mpowers at openjdk.org  Thu Oct 30 21:47:15 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 30 Oct 2025 21:47:15 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v16]
In-Reply-To: <r-N1oQJd_CKCmOGO_4N2XA83wV6nn7ViNALlNdvQzYc=.e2f3a395-563d-43b1-8921-199f297d5670@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <-Z70mhN5Ag5w-4sxMHntx7-uhBWmrRgKH98cWhbd36o=.98114790-6d5b-445b-9cc5-fd437cf2243d@github.com>
 <54AmW1yQHXl7Lg_oylTssnfk68YQDX5Gwu_CYELgeyc=.c958e2e1-d132-44e0-ad54-e73eb354af5e@github.com>
 <lERW86Dp8rg8eGBx0eyHFeGst7KpmdJeIHk9V1J2ULg=.9e595906-42fe-4e47-921b-9078fd82ebcb@github.com>
 <r-N1oQJd_CKCmOGO_4N2XA83wV6nn7ViNALlNdvQzYc=.e2f3a395-563d-43b1-8921-199f297d5670@github.com>
Message-ID: <K6qZYSeT6WTNNWEZWBwX19iDQ0GcP7zBrOfviDaV8lw=.cd61b304-9789-4057-bcfd-51f7ce314846@github.com>

On Wed, 29 Oct 2025 21:19:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I moved it to the `MacData` class as you suggest. `macSalt` ("NOT USED") and `iterations` (1) also belong in `MacData` and have been moved.
>
> The latest `encode` returns two algorithm identifiers concatenated together without any frame. I suggest we follow the `PBKDF2Parameters.java` style you described below ("The outer algorithm ID is also encoded in addition to the parameters"), which means moving the code around `tmp2` and `tmp3` from `MacData::encode` here simply call `tmp1.writeBytes(PBMAC1Parameters.encode(...))` in `MacData::encode`.
> 
> Or, if you prefer to encode the PBMAC1 OID outside (which follows most `AlgorithmParametersSpi` classes), put the concatenation inside a SEQUENCE and return it. This is similar to https://github.com/openjdk/jdk/pull/24429#discussion_r2455313609.

I choose the latter.

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

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

From weijun at openjdk.org  Thu Oct 30 21:47:16 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 30 Oct 2025 21:47:16 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v12]
In-Reply-To: <j7SU3QnhGC9MjSGeyRn99lMVbBAt00L0--WqiwsQxqo=.81d021e1-2cef-4a70-959f-c90a8fc032c3@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <j7SU3QnhGC9MjSGeyRn99lMVbBAt00L0--WqiwsQxqo=.81d021e1-2cef-4a70-959f-c90a8fc032c3@github.com>
Message-ID: <3Mhy_opzuPYlWDLkJRh8xRbbCp9JDdywvWdEL2jfgBc=.452ba093-558c-42e9-abfe-d8de3bb65ff5@github.com>

On Thu, 30 Oct 2025 17:12:31 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:
> 
>   minor doc updates, fix some bugs, PEM set to 26

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

> 207:                 byte[] encoding = null;
> 208:                 if (key != null) {
> 209:                     throw new IllegalArgumentException("Certificates " +

Typo. Not `Certificates`.

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

> 193:                     } else {
> 194:                         while (hyphen > 0) {
> 195:                             os.write('-');

The `-`s have already been written into `os` on line 202.

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

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

From abarashev at openjdk.org  Thu Oct 30 21:59:07 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 30 Oct 2025 21:59:07 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v3]
In-Reply-To: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
Message-ID: <yPWwJegDaYzBn06lxaRYkSoNK4QD2DEJjIcJW-VE1C8=.565a8769-a0be-45cb-a9d0-255a1e1f71ae@github.com>

On Wed, 29 Oct 2025 11:57:45 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed tests to use SecurityUtils.removeDisabled*Algs methods

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 221:

> 219:         if (args[1].contains("MD5")) {
> 220:             // MD5 is used in this test case, don't disable MD5 algorithm.
> 221:             SecurityUtils.removeFromDisabledAlgs("jdk.certpath.disabledAlgorithms",

Line length > 80. Also, I think `If MD5 is used ..` comment would be better because we don't always use MD5. Here and in other tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2479623980

From abarashev at openjdk.org  Thu Oct 30 22:05:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 30 Oct 2025 22:05:04 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v3]
In-Reply-To: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
Message-ID: <QnXF3VHsCgccp7EQT-ipTIJ4D0GWC-cyc1TaZWEhDzo=.d7f9c0db-80c4-45d6-b333-dfc4607ad343@github.com>

On Wed, 29 Oct 2025 11:57:45 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed tests to use SecurityUtils.removeDisabled*Algs methods

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 184:

> 182:         SSLContext ctx = SSLContext.getInstance(protocol);
> 183: 
> 184:         if (keyCert != null) {

Why do we check for keyCert being `null`? Do we expect some future tests to make use of it? BTW, in such case `CertificateBuilder.printCertificate` would fail first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2479633177

From Nick.Hall at deshaw.com  Thu Oct 30 22:16:35 2025
From: Nick.Hall at deshaw.com (Hall, Nick)
Date: Thu, 30 Oct 2025 22:16:35 +0000
Subject: Linux support for java.security.jgss "nativeccache" functionality
In-Reply-To: <8F150178-43BB-4C87-93E0-11B2E81D3CD7@oracle.com>
References: <LO4P123MB65312348A74C7898A8E43B1D91E82@LO4P123MB6531.GBRP123.PROD.OUTLOOK.COM>
 <6f0f0e19-5305-4d2f-99ab-9199caaf8c6e@oracle.com>
 <LO4P123MB6531DFC78694B143D30608FE91F52@LO4P123MB6531.GBRP123.PROD.OUTLOOK.COM>
 <8F150178-43BB-4C87-93E0-11B2E81D3CD7@oracle.com>
Message-ID: <LO4P123MB65310D10D349079CD65C708191FBA@LO4P123MB6531.GBRP123.PROD.OUTLOOK.COM>

Hi,

I?ve raised the PR as discussed at https://github.com/openjdk/jdk/pull/28075.  Sorry this took a little longer than expected due to other projects getting in the way!

I?ve added autoconf and build system changes that deal with whether the target system has krb5 or not, plus a suitable jtreg test using OneKDC.  The changes and testing work on both Linux and MacOS and the CI runs successfully on my fork, although only the MacOS builds enable krb5 ? but the other builds get through autoconf and successfully disable the feature.

After familiarizing myself with the build system a bit, I found a slightly neater way of implementing the conditionally compiled code approach I mentioned below which avoids changing the library name on MacOS ? although if it was preferable to have a consistent library name on both platforms, it would be easy to go back to the approach below.  Given the library name on Windows is different anyway, it didn?t seem that bad to have separate library names for each platform.

Thanks,
Nick

From: Wei-Jun Wang <weijun.wang at oracle.com>
Sent: Thursday, February 6, 2025 2:12 PM
To: Hall, Nick <Nick.Hall at deshaw.com>
Cc: Sean Mullan <sean.mullan at oracle.com>; security-dev at openjdk.org
Subject: Re: Linux support for java.security.jgss "nativeccache" functionality


This message was sent by an external party.

Hi Nick,

I?ve filed https://bugs.openjdk.org/browse/JDK-8349546. It will be great if the same code could support nativeccache on both Mac and Linux.

If the test cannot be automated, feel free to add some instructions for manual testing.

Looking forward to your first OpenJDK contribution!

Thanks,
Weijun


On Feb 3, 2025, at 19:04, Hall, Nick <Nick.Hall at deshaw.com<mailto:Nick.Hall at deshaw.com>> wrote:

Hi Sean,

Thanks for your response - I confirm that my company is D. E. Shaw & Co.

Let me know if I can provide any further information!

Nick
________________________________
From: Sean Mullan <sean.mullan at oracle.com<mailto:sean.mullan at oracle.com>>
Sent: Monday, February 3, 2025 11:03 pm
To: Hall, Nick <Nick.Hall at deshaw.com<mailto:Nick.Hall at deshaw.com>>; security-dev at openjdk.org<mailto:security-dev at openjdk.org> <security-dev at openjdk.org<mailto:security-dev at openjdk.org>>
Subject: Re: Linux support for java.security.jgss "nativeccache" functionality

This message was sent by an external party.


Hi Nick,

This proposal does sound like it would be useful, so I think we can
start some more discussions about it. Once we go a bit further in the
discussions and we decide it is worthwhile, we can open a JBS issue for
tracking purposes. For starters, can you confirm that your company is
"D. E. Shaw & Co., LP"?

--Sean

On 1/31/25 12:04 PM, Hall, Nick wrote:
> Hi,
>
> The current OpenJDK code has ?native? ccache support for both Windows/
> Mac, allowing native Kerberos credential acquisition on those platforms
> via the usual system library calls rather than the pure Java code.  It
> does not support Linux, meaning that only file based ccaches are
> supported on that platform.  I couldn?t find any other similar bug
> reports/fixes/submissions, so have developed a patch that I?d like to
> contribute to improve this support (for full disclosure, this is a
> corporate submission approved by my employer, and the OCA has been
> appropriately signed; this is my first time contributing to the OpenJDK).
>
> The motivation for doing this is that the Linux Kerberos / GSS-API
> system libraries support more than just file-based Kerberos credential
> caches ? in particular, we?re interested in supporting KCM, which is a
> standard protocol for acquiring credentials via a service based cache ?
> there are two existing implementations in Heimdal Kerberos and the
> RedHat SSSD.  As it stands now, supporting KCM for Java processes means
> running them inside a ?kstart? shell which copies a KCM cache to a file
> ccache for the process to use initially.  This is an unergonomic
> approach that we would like to avoid, as it?s a source of errors in our
> environment.
>
> The patch generalizes the Mac support to include Linux ? the C code (ref
> src/java.security.jgss/macosx/native/libosxkrb5/nativeccache.c) required
> here is identical to the Mac version other than the header files (and
> includes a bug fix to avoid a segfault caused by a null pointer deref,
> which I suspect is a dormant bug on MacOSX too).  The only other
> required changes are in the Java code which loads the relevant libraries
> and calls them, in both cases these are just changes to an existing
> conditional.
>
> I?d be interested in feedback, and had some questions about how to
> approach the shared nature of the code between MacOSX and Linux based on
> the options I?ve tried here:
>
>   * Option 1: duplicate the code, fix the headers and build a separate
>     Linux shared object.  This has the disadvantage of a lot of
>     duplicated code, but keeps each platform?s libraries separate/distinct.
>   * Option 2: build a common shared object on both MacOSX and Linux for
>     the nativeccache functionality, using pre-processor directives to
>     select the correct set of header files for each platform.  This has
>     the advantage of a smaller patch (lines of code), but introduces a
>     (no-op) change on MacOSX as a result.  MacOSX has one additional
>     source file (SCDynamicStoreConfig) compiled into the library that
>     Linux does not have.
>
> The draft code for option 2 can be found at https://github.com/nrhall/
> jdk/commit/7b57a48afff77ef80dbb6cd947bd0d0581c439c1 <https://github.com/
<https://github.com/%0b>> nrhall/jdk/commit/7b57a48afff77ef80dbb6cd947bd0d0581c439c1> (note that
> the GH Actions jobs currently fail on Linux because the runner needs to
> have at least libkrb5-dev installed, and that changes to autoconf/
> dependencies will be needed to ensure these libs/headers are installed
> at compile time at least ? with some careful handling at library load
> time to handle the error if not).
>
> If there?s interest in pursuing this, I?d be happy to raise a PR  -
> please let me know if there are any questions!
>
> Thanks,
>
> Nick
>


________________________________
D. E. Shaw & Co. (London), LLP, which is authorised and regulated by the Financial Conduct Authority (firm reference number 590179), may record telephone calls made to or from our members and employees and otherwise gather personal information that you may share in the course of our dealings with you. This information will be used for the purposes of providing services, keeping records, processing applications for employment, and regulatory compliance and, accordingly, may be transferred outside of the European Economic Area to other D. E. Shaw group companies. D. E. Shaw & Co. (London), LLP is a limited liability partnership registered in England and Wales with company number OC377872.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20251030/fd3108e3/attachment-0001.htm>

From duke at openjdk.org  Thu Oct 30 22:39:13 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 30 Oct 2025 22:39:13 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality
Message-ID: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>

_Purpose_

This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.

_Rationale_

Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.

The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).

Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.

_Implementation Detail_

Note that there were multiple possible ways of doing this:

1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.

2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.

3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.

I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.

Interested to hear if anyone else has any suggestions for better ideas!

_Notes_

It wasn't clear to me what I should do with copyright headers/updating dates in headers.  I've added similar boilerplate headers seen in other files to some of the new files, but please let me know what the usual form is here.

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

Commit messages:
 - Fix permissions on build.sh
 - Add support for native Kerberos credential acquisition on Linux

Changes: https://git.openjdk.org/jdk/pull/28075/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349546
  Stats: 824 lines in 11 files changed: 811 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075

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

From erikj at openjdk.org  Thu Oct 30 22:58:01 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 30 Oct 2025 22:58:01 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>

On Thu, 30 Oct 2025 22:04:52 GMT, Nick Hall <duke at openjdk.org> wrote:

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3470596144

From duke at openjdk.org  Thu Oct 30 23:05:56 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 30 Oct 2025 23:05:56 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v2]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <RhL_OhjW5T9Er0fo8OVJOGD_pMPiiXIzigdKv38ia0k=.083b0025-0da2-4972-a08a-3cd64970b5b7@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Tidy up comments/docs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/2e6cd029..307c3f28

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

  Stats: 44 lines in 3 files changed: 6 ins; 9 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/28075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075

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

From duke at openjdk.org  Thu Oct 30 23:05:58 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 30 Oct 2025 23:05:58 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality
In-Reply-To: <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
Message-ID: <VjbmA1L9qEJr7_kRRb6Qolvl6-9Kx-tCuZlR3xfpTFI=.dcd78460-3c32-4cce-9a63-e7dbb55d5af5@github.com>

On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`.

Definitely the unfamiliar bit, although the build.sh was useful for doing some quick test runs.  Is there an example you could point me at - I'd be happy to fix that.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3470640699

From fferrari at openjdk.org  Thu Oct 30 23:07:23 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 30 Oct 2025 23:07:23 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions [v8]
In-Reply-To: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
Message-ID: <0iLyQFtldK7kJHvRpdXwcMXoNrjWKfFCJfo_a5BhJpM=.290016fd-53f4-4303-b665-8f31e4e19cd2@github.com>

> 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/java.base/windows/native/libjava/c...

Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:

  Detect cyclic includes with Files::isSameFile
  
  checkCyclicInclude() is invoked after we successfully get an InputStream
  for the path to avoid skipping the same IOException several times inside
  checkCyclicInclude() if the path doesn't exist.
  
  Also, perform symlinks resolution only in the following cases:
   ? When we need to resolve a relative include
   ? For clarity to the user in logging messages
   ? For clarity to the user in exception messages
  
  In the first case, the resolution is a requirement, in the last two
  cases it is a nice-to-have. But given the last two are exceptional
  cases anyway, we let any resolution error bubble up.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24465/files
  - new: https://git.openjdk.org/jdk/pull/24465/files/4e77fb36..a8d865c4

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

  Stats: 41 lines in 1 file changed: 26 ins; 9 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24465/head:pull/24465

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

From fferrari at openjdk.org  Thu Oct 30 23:07:24 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 30 Oct 2025 23:07:24 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions
In-Reply-To: <iw4NcdhA6TkUsoHcdrKXsQsG2d9CtBrXBobuXyUT0QY=.cad72c9d-ac36-4b65-a915-381a864f10ff@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>
 <iw4NcdhA6TkUsoHcdrKXsQsG2d9CtBrXBobuXyUT0QY=.cad72c9d-ac36-4b65-a915-381a864f10ff@github.com>
Message-ID: <lZARurvRiaB-weLqU6nReitT7emsWSvRZzf4axc3JrA=.82932235-a6fc-4f72-afc6-b78b29a00451@github.com>

On Fri, 17 Oct 2025 10:07:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @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..

@AlanBateman: `Files::isSameFile` works well for circular includes detection (in both _Linux_ and _Windows_). I've updated the code to use it (see a8d865c4985e6660655b27df28e76882855b2087).

The new code also avoids resolving a path, except in the following cases:
* When we need to resolve a relative include
* For clarity to the user, in logging messages
* For clarity to the user, in exception messages

In those cases, I kept `File::getCanonicalPath` as the resolution method, because is the only one that is able to handle the 7abb62c069ad35f4ec34f6cd9b9f6d05febceecc variant.

@seanjmullan: the new code avoids path resolution whenever possible (except logging and exception messages), so it represents the most conservative approach (except for any possible regression of the new `Files::isSameFile` usage).

Please give it a look (or let Weijun/Valerie know).

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3470640775

From duke at openjdk.org  Thu Oct 30 23:37:50 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 30 Oct 2025 23:37:50 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v3]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <JfFWrcdut9WkO07d2tc7ns_LYDulDW4g8eYx0_SMc7s=.60ef7a9d-8b3e-49f4-9c78-d1baf09da337@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with two additional commits since the last revision:

 - more comment fixes
 - eliminate build.sh in favour of jtreg primitives

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/307c3f28..33407d4a

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

  Stats: 101 lines in 5 files changed: 3 ins; 91 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075

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

From duke at openjdk.org  Thu Oct 30 23:37:51 2025
From: duke at openjdk.org (Nick Hall)
Date: Thu, 30 Oct 2025 23:37:51 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality
In-Reply-To: <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
Message-ID: <y91sYqXu4y3lgep8hxKjvaV1iiZvcWqZM12TrNS6Dpo=.d46d84d0-c0fb-4cc0-8449-9deb5d2f927a@github.com>

On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`.

@erikj79 I've had a go at the suggested changes - hope that's more what you were looking for?

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3470708643

From duke at openjdk.org  Fri Oct 31 00:07:35 2025
From: duke at openjdk.org (Nick Hall)
Date: Fri, 31 Oct 2025 00:07:35 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v4]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <fHIROBCx9sq3jmSsQyco_TCCyEYbuxLQ8rD2FEserYw=.f52f4c12-a9fc-4187-9a8c-ee37430c596c@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Add specific MacOS jtreg compiler flags to fix deprecation warnings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/33407d4a..1a28cee2

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

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

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

From duke at openjdk.org  Fri Oct 31 00:53:56 2025
From: duke at openjdk.org (Nick Hall)
Date: Fri, 31 Oct 2025 00:53:56 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v5]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <Lg1peKpnbPm6c8NBPKj5xxyMdGDZQzHS4PQbC4-ikbQ=.bdb7ab99-19eb-48de-a23e-7dbbf4df226e@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Add missing .h file to PR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/1a28cee2..5cad1e41

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

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

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

From duke at openjdk.org  Fri Oct 31 01:16:01 2025
From: duke at openjdk.org (Nick Hall)
Date: Fri, 31 Oct 2025 01:16:01 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v6]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <kIdmj45o-6LHK1QvqnC8pvlj1BGhLMwL6z3vA7IQPZ8=.16dcecf6-c7e4-497e-8b52-6797ae2c1fe3@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Fixes to ensure that the jtreg test is not built or executed if krb5 is not installed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/5cad1e41..bc904b0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=04-05

  Stats: 15 lines in 2 files changed: 9 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075

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

From weijun at openjdk.org  Fri Oct 31 01:19:18 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 31 Oct 2025 01:19:18 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v18]
In-Reply-To: <tjpxHB3mA2FyL4HonJzpaqXr2Z39TzH8_QfkDoaK57I=.263370c0-1c4b-40fe-99e4-4ad1da76f821@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <tjpxHB3mA2FyL4HonJzpaqXr2Z39TzH8_QfkDoaK57I=.263370c0-1c4b-40fe-99e4-4ad1da76f821@github.com>
Message-ID: <-VUowp-RPkSvC1Tjc4dcpr_zAa4KebG9NgNmhE-1Uhc=.567b472b-da91-4dc9-b0fb-4701a153071d@github.com>

On Thu, 30 Oct 2025 21:09:57 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> [JDK-8343232](https://bugs.openjdk.org/browse/JDK-8343232)
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - two algorithm identifiers concatenated together without any frame
>  - merge
>  - three comments and OID name change
>  - A4-A6 from RFC
>  - Weijun code review comments
>  - merge
>  - stragglers
>  - checkpoint
>  - remaining comments
>  - more review comments from Sean and Weijun
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/a2196e20...409f34c5

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

> 325:             // id-PBMAC1 OBJECT IDENTIFIER ::= { pkcs-5 14 }
> 326:             tmp2.putOID(ObjectIdentifier.of(KnownOIDs.PBMAC1));
> 327:             tmp2.write(tmp3);

Since there is only one raw byte array in `tmp3`, the following lines

DerOutputStream tmp3 = new DerOutputStream();
tmp3.writeBytes(PBMAC1Parameters.encode(macSalt, iterations, keyLength, kdfHmac, hmac));
tmp2.write(tmp3);

is equivalent to

tmp2.writeBytes(PBMAC1Parameters.encode(macSalt, iterations, keyLength, kdfHmac, hmac));

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

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

From myankelevich at openjdk.org  Fri Oct 31 09:54:26 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 31 Oct 2025 09:54:26 GMT
Subject: RFR: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995 [v3]
In-Reply-To: <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
 <DIeU2vbsv8wmgMEp2h7H_PU38q6dw2jJ1yMrnak0s0U=.c56413c3-4eea-4ae9-9a54-b984f7839cde@github.com>
Message-ID: <Z1lEdBuS3hC2_3vMj0l2hTnvOHOW3iEfEHN6B-gLJLI=.9bee391c-6f0d-4a2b-b8e3-2357e34ae537@github.com>

On Thu, 30 Oct 2025 10:16:16 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Updated test to require `ssl,keymanager`, as it changed from `keymanager`.
>
> Mikhail Yankelevich has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - turbanoff's comment
>  - choosing -> Choosing

Thank you for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28045#issuecomment-3472197137

From myankelevich at openjdk.org  Fri Oct 31 09:54:27 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 31 Oct 2025 09:54:27 GMT
Subject: Integrated: 8370852: Test
 sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after
 JDK-8369995
In-Reply-To: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
References: <KmdJQp_UIxjb_HAKEA5Hp4J1tpkAjnRQyn7L-m6pBJk=.8515f91b-9976-4c99-8e05-cd7da8b1563d@github.com>
Message-ID: <WxHK9krskewogGmiTKm0nsQOhe23oY2o_aiaFidbHOg=.3d61c909-e60a-45b7-97a5-fd516209c106@github.com>

On Wed, 29 Oct 2025 14:25:05 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Updated test to require `ssl,keymanager`, as it changed from `keymanager`.

This pull request has now been integrated.

Changeset: 4ca88aa2
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ca88aa2e8f486ffa7c6f4050ca3462e5e6f3418
Stats:     38 lines in 2 files changed: 11 ins; 4 del; 23 mod

8370852: Test sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java fails after JDK-8369995

Reviewed-by: coffeys, wetmore

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

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

From mdonovan at openjdk.org  Fri Oct 31 13:09:23 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 31 Oct 2025 13:09:23 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v4]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <oHRWMceW2NNAIA0Dxy9STpzKril7N2pkfz2PJEYIiys=.7ddc36a7-7160-4011-aa15-14e6b681fcf2@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  removed unnecessary comment and made getSSLContext(...) private

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/4804c90d..94ea9ba7

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

  Stats: 22 lines in 6 files changed: 0 ins; 13 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

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

From mdonovan at openjdk.org  Fri Oct 31 13:09:26 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 31 Oct 2025 13:09:26 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v3]
In-Reply-To: <yPWwJegDaYzBn06lxaRYkSoNK4QD2DEJjIcJW-VE1C8=.565a8769-a0be-45cb-a9d0-255a1e1f71ae@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
 <yPWwJegDaYzBn06lxaRYkSoNK4QD2DEJjIcJW-VE1C8=.565a8769-a0be-45cb-a9d0-255a1e1f71ae@github.com>
Message-ID: <edmvh8dOSb7xx_GAECqL_0F2fP3sazh76bqtZW3o3oA=.bd13b7b2-131f-4f19-8131-dafea1ee5e81@github.com>

On Thu, 30 Oct 2025 21:56:15 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed tests to use SecurityUtils.removeDisabled*Algs methods
>
> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 221:
> 
>> 219:         if (args[1].contains("MD5")) {
>> 220:             // MD5 is used in this test case, don't disable MD5 algorithm.
>> 221:             SecurityUtils.removeFromDisabledAlgs("jdk.certpath.disabledAlgorithms",
> 
> Line length > 80. Also, I think `If MD5 is used ..` comment would be better because we don't always use MD5. Here and in other tests.

I removed the comment entirely. It seemed redundant to say "if MD5 is used" right below the `if(args[0].equals("MD5")`

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 184:
> 
>> 182:         SSLContext ctx = SSLContext.getInstance(protocol);
>> 183: 
>> 184:         if (keyCert != null) {
> 
> Why do we check for keyCert being `null`? Do we expect some future tests to make use of it? BTW, in such case `CertificateBuilder.printCertificate` would fail first.

I think that was leftover from refactoring the code. I removed the null checks and made the method private for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2481353898
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2481352676

From abarashev at openjdk.org  Fri Oct 31 14:24:21 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 31 Oct 2025 14:24:21 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v3]
In-Reply-To: <edmvh8dOSb7xx_GAECqL_0F2fP3sazh76bqtZW3o3oA=.bd13b7b2-131f-4f19-8131-dafea1ee5e81@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
 <yPWwJegDaYzBn06lxaRYkSoNK4QD2DEJjIcJW-VE1C8=.565a8769-a0be-45cb-a9d0-255a1e1f71ae@github.com>
 <edmvh8dOSb7xx_GAECqL_0F2fP3sazh76bqtZW3o3oA=.bd13b7b2-131f-4f19-8131-dafea1ee5e81@github.com>
Message-ID: <ToXHmo4yq_pBrHGYZD4ZjyuH27YZ0GyLInzBwbQlFK0=.734538a5-ea87-4e03-a8f6-d1d5e22986be@github.com>

On Fri, 31 Oct 2025 13:06:48 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 221:
>> 
>>> 219:         if (args[1].contains("MD5")) {
>>> 220:             // MD5 is used in this test case, don't disable MD5 algorithm.
>>> 221:             SecurityUtils.removeFromDisabledAlgs("jdk.certpath.disabledAlgorithms",
>> 
>> Line length > 80. Also, I think `If MD5 is used ..` comment would be better because we don't always use MD5. Here and in other tests.
>
> I removed the comment entirely. It seemed redundant to say "if MD5 is used" right below the `if(args[0].equals("MD5")`

Yes, makes sense. Please also fix the line length.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2481598670

From mdonovan at openjdk.org  Fri Oct 31 15:02:42 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 31 Oct 2025 15:02:42 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  changed line wrapping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/94ea9ba7..1aaf4247

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

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

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

From mpowers at openjdk.org  Fri Oct 31 15:05:30 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 31 Oct 2025 15:05:30 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v18]
In-Reply-To: <-VUowp-RPkSvC1Tjc4dcpr_zAa4KebG9NgNmhE-1Uhc=.567b472b-da91-4dc9-b0fb-4701a153071d@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <tjpxHB3mA2FyL4HonJzpaqXr2Z39TzH8_QfkDoaK57I=.263370c0-1c4b-40fe-99e4-4ad1da76f821@github.com>
 <-VUowp-RPkSvC1Tjc4dcpr_zAa4KebG9NgNmhE-1Uhc=.567b472b-da91-4dc9-b0fb-4701a153071d@github.com>
Message-ID: <Vqjagf4Ll1YKT8H_EEfytlMdzPwpXdoZyr03USu3EZo=.7b8f9c56-d0b9-40ad-84a0-3d3e1f326aa7@github.com>

On Fri, 31 Oct 2025 01:16:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
>> 
>>  - two algorithm identifiers concatenated together without any frame
>>  - merge
>>  - three comments and OID name change
>>  - A4-A6 from RFC
>>  - Weijun code review comments
>>  - merge
>>  - stragglers
>>  - checkpoint
>>  - remaining comments
>>  - more review comments from Sean and Weijun
>>  - ... and 26 more: https://git.openjdk.org/jdk/compare/a2196e20...409f34c5
>
> src/java.base/share/classes/sun/security/pkcs12/MacData.java line 327:
> 
>> 325:             // id-PBMAC1 OBJECT IDENTIFIER ::= { pkcs-5 14 }
>> 326:             tmp2.putOID(ObjectIdentifier.of(KnownOIDs.PBMAC1));
>> 327:             tmp2.write(tmp3);
> 
> Since there is only one raw byte array in `tmp3`, the following lines
> 
> DerOutputStream tmp3 = new DerOutputStream();
> tmp3.writeBytes(PBMAC1Parameters.encode(macSalt, iterations, keyLength, kdfHmac, hmac));
> tmp2.write(tmp3);
> 
> is equivalent to
> 
> tmp2.writeBytes(PBMAC1Parameters.encode(macSalt, iterations, keyLength, kdfHmac, hmac));

fixed

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

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

From mpowers at openjdk.org  Fri Oct 31 15:09:24 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 31 Oct 2025 15:09:24 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v19]
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <_y8Js_CjMPdr3WBrQ_VvJ4wG8c_ZWZzNvhBbrW2-oBY=.fc6ab99b-49ca-4654-8579-ed264c16f04a@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:

  unnecessary DER output stream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24429/files
  - new: https://git.openjdk.org/jdk/pull/24429/files/409f34c5..ba2c0719

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

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

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

From abarashev at openjdk.org  Fri Oct 31 16:08:40 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 31 Oct 2025 16:08:40 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
Message-ID: <QRCLhchA_FrVJbR7ZeO5n-CZpjud-FLV_qIqkMmyIH4=.b57b9265-3eea-4523-97e2-04d78d4bb39c@github.com>

On Fri, 31 Oct 2025 15:02:42 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed line wrapping

LGTM

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

Marked as reviewed by abarashev (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3405000667

From mullan at openjdk.org  Fri Oct 31 17:19:08 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 31 Oct 2025 17:19:08 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v8]
In-Reply-To: <NN8zPtICyMG_P2cvSC-HFT2NJQeshOdpJHWcTFQ-faw=.52a567e6-261b-45fa-ab15-0b5f3b300910@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <NN8zPtICyMG_P2cvSC-HFT2NJQeshOdpJHWcTFQ-faw=.52a567e6-261b-45fa-ab15-0b5f3b300910@github.com>
Message-ID: <pjrIwR4LPlBEiuGZtwFHu5l2l3YUH7ErmoLbQVr14sU=.27eca3ab-36bf-43c8-8259-512fd44282d2@github.com>

On Thu, 30 Oct 2025 18:10:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
>> Also enhancing "java -XshowSettings:security:tls" option to show the enabled signature schemes.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Signatures schemes using sha224 are not available on Windows

src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 424:

> 422:             for (String name : config.signatureSchemes) {
> 423:                 var ss = SignatureScheme.nameOf(name);
> 424:                 if (ss != null) {

The previous code (in `namesOfAvailable()`) also checked if the scheme was available before adding it. Did you remove that check because it was redundant as the next loop checks that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2482164603

From abarashev at openjdk.org  Fri Oct 31 17:24:05 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 31 Oct 2025 17:24:05 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v8]
In-Reply-To: <pjrIwR4LPlBEiuGZtwFHu5l2l3YUH7ErmoLbQVr14sU=.27eca3ab-36bf-43c8-8259-512fd44282d2@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <NN8zPtICyMG_P2cvSC-HFT2NJQeshOdpJHWcTFQ-faw=.52a567e6-261b-45fa-ab15-0b5f3b300910@github.com>
 <pjrIwR4LPlBEiuGZtwFHu5l2l3YUH7ErmoLbQVr14sU=.27eca3ab-36bf-43c8-8259-512fd44282d2@github.com>
Message-ID: <3kZq__UZgUvjoU2l4eO1rzJis21cXzfQbwMMeXP6sr4=.22d51310-7cf7-4d83-b356-ef2c3b502ef3@github.com>

On Fri, 31 Oct 2025 17:16:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Signatures schemes using sha224 are not available on Windows
>
> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 424:
> 
>> 422:             for (String name : config.signatureSchemes) {
>> 423:                 var ss = SignatureScheme.nameOf(name);
>> 424:                 if (ss != null) {
> 
> The previous code (in `namesOfAvailable()`) also checked if the scheme was available before adding it. Did you remove that check because it was redundant as the next loop checks that?

Yes, it is redundant, we check it below anyhow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27961#discussion_r2482175352

From mullan at openjdk.org  Fri Oct 31 17:37:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 31 Oct 2025 17:37:06 GMT
Subject: RFR: 8366364: Return enabled signature schemes with
 SSLConfiguration#getSSLParameters() call [v8]
In-Reply-To: <NN8zPtICyMG_P2cvSC-HFT2NJQeshOdpJHWcTFQ-faw=.52a567e6-261b-45fa-ab15-0b5f3b300910@github.com>
References: <c1ZHacNJsJddZzxyEbSRM6enFeNx_vAxBxxfFBPP9Y8=.28f6041b-f53e-4169-84b1-7be237523443@github.com>
 <NN8zPtICyMG_P2cvSC-HFT2NJQeshOdpJHWcTFQ-faw=.52a567e6-261b-45fa-ab15-0b5f3b300910@github.com>
Message-ID: <DOCr21-ZBrPMr5LzzhdRIoaQ4ZoP4VQ6BC8M7w9XQ_o=.dfadff29-ab4d-40d9-99bf-5c1f462ebbf4@github.com>

On Thu, 30 Oct 2025 18:10:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> For the signatureSchemes we return only what's been set by the user, the default values are not being returned like for other SSLParameters.
>> Also enhancing "java -XshowSettings:security:tls" option to show the enabled signature schemes.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Signatures schemes using sha224 are not available on Windows

Looks good. Please add a release note.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27961#pullrequestreview-3405362011

From erikj at openjdk.org  Fri Oct 31 17:42:17 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 31 Oct 2025 17:42:17 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v6]
In-Reply-To: <kIdmj45o-6LHK1QvqnC8pvlj1BGhLMwL6z3vA7IQPZ8=.16dcecf6-c7e4-497e-8b52-6797ae2c1fe3@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <kIdmj45o-6LHK1QvqnC8pvlj1BGhLMwL6z3vA7IQPZ8=.16dcecf6-c7e4-497e-8b52-6797ae2c1fe3@github.com>
Message-ID: <1xU5oKp5ucBqN3EufMyfc_sFeEro69PfescAK4ZJ4kk=.ecfe6582-bcb1-416b-8260-2bc8574ff301@github.com>

On Fri, 31 Oct 2025 01:16:01 GMT, Nick Hall <duke at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes to ensure that the jtreg test is not built or executed if krb5 is not installed

make/autoconf/lib-krb5.m4 line 32:

> 30: [
> 31:   AC_ARG_WITH(krb5, [AS_HELP_STRING([--with-krb5],
> 32:       [enable krb5 support (default=yes), or "no" to disable])])

If this is an optional dependency, this option should take three values: yes/no/auto. The default should be "auto".

- yes: Fail if the library cannot be found
- no: Disable the feature
- auto: Look for the library and enable if found, otherwise disable

Also the help text should make it clear that this is Linux only.

For other library dependency options, the with-<lib> option can also be used to point to the location of the installation, usually combined with individual --with-<lib>-include and --with-<lib>-lib. I think something like this might be good to support, but I'm not familiar with this lib and possible installation options.

make/autoconf/lib-krb5.m4 line 39:

> 37:     AC_MSG_NOTICE([krb5 explicitly disabled])
> 38:     KRB5_DISABLED=yes
> 39:   elif test "x$NEEDS_LIB_KRB5" = xfalse; then

Since this is an optional dependency, perhaps use a different variable name?

make/autoconf/lib-krb5.m4 line 52:

> 50:   else
> 51:     # First try pkg-config (most modern approach)
> 52:     AC_PATH_TOOL([PKG_CONFIG], [pkg-config], [no])

PKG_CONFIG should already be setup in pkg.m4.

make/autoconf/lib-krb5.m4 line 55:

> 53:     use_pkgconfig_for_krb5=no
> 54: 
> 55:     if test "x$PKG_CONFIG" != "xno"; then

If `SYSROOT` is set, we should not try to use pkg-config or any other similar tool, as that would try to pick it up from the build host rather than the target sysroot. See how other external dependencies handle this.

make/autoconf/lib-krb5.m4 line 78:

> 76:     else
> 77:       # Fallback: try krb5-config
> 78:       AC_PATH_TOOL([KRB5CONF], [krb5-config], [no])

We have our own internal macro `UTIL_LOOKUP_PROGS` that is preferred over the AC variants.

make/autoconf/libraries.m4 line 87:

> 85:   # Check if krb5 is needed
> 86:   if test "x$OPENJDK_TARGET_OS" = xlinux -o "x$OPENJDK_TARGET_OS" = xmacosx; then
> 87:     NEEDS_LIB_KRB5=true

My understanding is that this external dependency is only needed on Linux. The resulting variable even has linux in the name.

make/autoconf/spec.gmk.template line 440:

> 438: KRB5_LIBS := @KRB5_LIBS@
> 439: KRB5_CFLAGS := @KRB5_CFLAGS@
> 440: ENABLE_LIBLINUXKRB5 := @ENABLE_LIBLINUXKRB5@

A better name would perhaps be `ENABLE_LIBKRB5_LINUX` or `ENABLE_LINUX_LIBKRB5`, maybe even just `ENABLE_LIBKRB5`?

make/test/JtregNativeJdk.gmk line 121:

> 119:     # On macOS, disable deprecation warnings for krb5 API
> 120:     BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libNativeCredentialCacheHelper += -Wno-deprecated-declarations
> 121:   endif

Isn't this enabled and should be tested on macos regardless of `ENABLE_LIBLINUXKRB5` as support was there already?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2481585933
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2481626000
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2481600747
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2482215190
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2481617382
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2481572420
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2481631167
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2482218069

From weijun at openjdk.org  Fri Oct 31 17:43:27 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 31 Oct 2025 17:43:27 GMT
Subject: RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1) [v19]
In-Reply-To: <_y8Js_CjMPdr3WBrQ_VvJ4wG8c_ZWZzNvhBbrW2-oBY=.fc6ab99b-49ca-4654-8579-ed264c16f04a@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
 <_y8Js_CjMPdr3WBrQ_VvJ4wG8c_ZWZzNvhBbrW2-oBY=.fc6ab99b-49ca-4654-8579-ed264c16f04a@github.com>
Message-ID: <dc42WrhCasCogpaI-Q_1OIa_O3miegyv29N9QqGo7qU=.7719fe16-81d5-4a6a-9351-5037ac61fae3@github.com>

On Fri, 31 Oct 2025 15:09:24 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:
> 
>   unnecessary DER output stream

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24429#pullrequestreview-3405377693

From mpowers at openjdk.org  Fri Oct 31 17:56:29 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 31 Oct 2025 17:56:29 GMT
Subject: Integrated: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of
 Password-Based Message Authentication Code 1 (PBMAC1)
In-Reply-To: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
References: <dOe7339aLvlZPZ2wbnXgiMg6KN4mvovZ-FeXKd0gOg4=.01ab81cf-1ccf-47a9-bced-e4c566287fcc@github.com>
Message-ID: <uwODDq01xALG6luo5fn_1qanXJpv4jnvHYms8Vukud4=.b1a6c49f-e5f8-4dfb-9557-1e899d3555b0@github.com>

On Thu, 3 Apr 2025 22:58:39 GMT, Mark Powers <mpowers at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 1781b186
Author:    Mark Powers <mpowers at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1781b186b51900b758dd55cc356eaaf12b28481b
Stats:     1077 lines in 11 files changed: 798 ins; 176 del; 103 mod

8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1)

Reviewed-by: weijun, mullan

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

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

From weijun at openjdk.org  Fri Oct 31 19:05:41 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 31 Oct 2025 19:05:41 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v5]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <zRUE9Ji7iBg97NYR3rDfpVtcFY2-dhBy261U3A2b964=.983e0f4e-d70e-4c27-a423-f35ff41f0848@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  man page change; slight test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/6ff3a069..fc1c36b8

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

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

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

From weijun at openjdk.org  Fri Oct 31 20:19:21 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 31 Oct 2025 20:19:21 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v6]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <RW7jh7Y9Rs7VyE-f7PU-ypMOYBMNlLVhJuEc2ao3BwA=.dd34d5ef-a087-4f6f-8f81-b7756261fcfb@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more man page change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/fc1c36b8..704d2286

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26563&range=04-05

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

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

From weijun at openjdk.org  Fri Oct 31 20:30:39 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 31 Oct 2025 20:30:39 GMT
Subject: RFR: 8349732: Add support for JARs signed with ML-DSA [v7]
In-Reply-To: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
References: <pwrp3w-KdobSO5Bp_OpiXmPiNXiZTate0_j57J1FivI=.d4fde7ff-b62e-4c8b-bc63-c9dfb5a97b91@github.com>
Message-ID: <o1kKUzqcMfxW-V7IPoZ538FBqzY53IiA2uTJ_qOVJD4=.f1a7a194-41dd-4b17-810f-8f801f2c2834@github.com>

> Add support for ML-DSA signing of JAR files.
> 
> Note: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/ is not finalized.
> 
> Update: it is published as https://datatracker.ietf.org/doc/rfc9882/.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  data source

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26563/files
  - new: https://git.openjdk.org/jdk/pull/26563/files/704d2286..989027cb

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

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

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

From ascarpino at openjdk.org  Fri Oct 31 21:51:11 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 31 Oct 2025 21:51:11 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v12]
In-Reply-To: <3Mhy_opzuPYlWDLkJRh8xRbbCp9JDdywvWdEL2jfgBc=.452ba093-558c-42e9-abfe-d8de3bb65ff5@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
 <j7SU3QnhGC9MjSGeyRn99lMVbBAt00L0--WqiwsQxqo=.81d021e1-2cef-4a70-959f-c90a8fc032c3@github.com>
 <3Mhy_opzuPYlWDLkJRh8xRbbCp9JDdywvWdEL2jfgBc=.452ba093-558c-42e9-abfe-d8de3bb65ff5@github.com>
Message-ID: <dP37luCJSEH8Nkwme86fAeoY6mCH-iPKwbfRlBBy8DE=.1044b633-bfae-4d76-a5a8-3117bd0ba293@github.com>

On Thu, 30 Oct 2025 20:18: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:
>> 
>>   minor doc updates, fix some bugs, PEM set to 26
>
> src/java.base/share/classes/java/security/PEMEncoder.java line 209:
> 
>> 207:                 byte[] encoding = null;
>> 208:                 if (key != null) {
>> 209:                     throw new IllegalArgumentException("Certificates " +
> 
> Typo. Not `Certificates`.

Bad cut-n-paste

> src/java.base/share/classes/sun/security/util/Pem.java line 195:
> 
>> 193:                     } else {
>> 194:                         while (hyphen > 0) {
>> 195:                             os.write('-');
> 
> The `-`s have already been written into `os` on line 202.

Yep.. this code is pretty useless.

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

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

From ascarpino at openjdk.org  Fri Oct 31 21:57:56 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 31 Oct 2025 21:57:56 GMT
Subject: RFR: 8360564: Implement JEP 524: PEM Encodings of Cryptographic
 Objects (Second Preview) [v13]
In-Reply-To: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
References: <SE3GK6ptX6WyRwpFcKqga4n4IOy4mP7sj9UIofam3VI=.22793bd5-54b8-43ab-8cf7-0a0c1eaeef60@github.com>
Message-ID: <xSFJKTO7f9E8RzpwWRuUZWL0MEBSZlAfL7XQLG9vXoQ=.0615c53c-f29c-442c-9b53-2f99f25fe80c@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 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 25 additional commits since the last revision:

 - mistakes
 - Merge branch 'master' into pem26
 - minor doc updates, fix some bugs, PEM set to 26
 - more docs, remove runtimeexception
 - EKPI has a lot of @link's
 - docs
 - more doc updates and zeroing
 - fix non-pbe
 - doc updates, zeroing, fix unencrypted keypair encoding, exception mods
 - updates
 - ... and 15 more: https://git.openjdk.org/jdk/compare/c8aec9a3...0d95043c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27147/files
  - new: https://git.openjdk.org/jdk/pull/27147/files/e1405c06..0d95043c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27147&range=11-12

  Stats: 107595 lines in 2015 files changed: 60449 ins; 35343 del; 11803 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 duke at openjdk.org  Fri Oct 31 22:21:30 2025
From: duke at openjdk.org (Nick Hall)
Date: Fri, 31 Oct 2025 22:21:30 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v7]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <VMDUMKVfso37s5SdDn4JCeR_GJEaI66wwKq4is7JTXc=.0bbb8dd6-b5e7-45d8-834b-6c764db14f20@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Attend to @erikj79's code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/bc904b0e..3ea97938

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

  Stats: 159 lines in 4 files changed: 81 ins; 19 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/28075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075

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

From duke at openjdk.org  Fri Oct 31 22:24:02 2025
From: duke at openjdk.org (Nick Hall)
Date: Fri, 31 Oct 2025 22:24:02 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality
In-Reply-To: <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
Message-ID: <oqMALY6dsSDSZgxq7E16_L0DCYrTwHz7im5lt6XzW6U=.35252f29-4867-4af8-a62c-6db93e82c724@github.com>

On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`.

Thanks for all the help and pointers @erikj79 - I've pushed a commit to (hopefully) address all of your comments!

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3475064317

From duke at openjdk.org  Fri Oct 31 22:45:33 2025
From: duke at openjdk.org (Nick Hall)
Date: Fri, 31 Oct 2025 22:45:33 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v8]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <4Wap4VTtEC0l2I-_GIDpLZDCkKg78iclW3tW9trkxwk=.21ceb5f9-1d7f-4d3c-8703-5df82d475c1d@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Minor variable/function name and comment clean-ups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/3ea97938..d58d4172

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

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

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

From duke at openjdk.org  Fri Oct 31 22:48:53 2025
From: duke at openjdk.org (Nick Hall)
Date: Fri, 31 Oct 2025 22:48:53 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v9]
In-Reply-To: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
Message-ID: <V-BNOBiMS7EhU2yfL0NQNJdGu590cpvEST7UBQ-MFz0=.941bae9c-cefd-43c3-bf82-fadaa82d2b02@github.com>

> _Purpose_
> 
> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
> 
> _Rationale_
> 
> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
> 
> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
> 
> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
> 
> _Implementation Detail_
> 
> Note that there were multiple possible ways of doing this:
> 
> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
> 
> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
> 
> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
> 
> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensate for this.
> 
> Interested to hear if anyone else...

Nick Hall has updated the pull request incrementally with one additional commit since the last revision:

  Minor doc/comment clean-ups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28075/files
  - new: https://git.openjdk.org/jdk/pull/28075/files/d58d4172..47968fe7

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

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

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