From duke at openjdk.org  Sat Mar  1 00:34:55 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 1 Mar 2025 00:34:55 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v9]
In-Reply-To: <nAPBZpXVMX51_LaFPG-hbZG66Xci4qlVHkMIttJCLFo=.3df8388f-4f91-4336-bfb1-0c904c423471@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <u9UswQ9Imkd5x9DVBDyDsruqOrC9ZZxr6Yl9uINi55k=.a698190e-fd1a-4064-8b67-757102523c58@github.com>
 <6ThXIled5v2oPqFKndDzxjXw0GOptsX7fVWex2anyvw=.3340328f-0d74-4c5f-b28b-744bf0c5f4a7@github.com>
 <kdLNgVFrmCx2aYqUwHUyfcQthAlATX-aRut8vFZh-8M=.05f469d5-799f-4df2-84ee-9a6be7ec3818@github.com>
 <qz-IBAIYj109gew6OPc-sf76Qg5sy6aI9RgWgB4CrK8=.ee177886-420e-4e0d-83e1-ed32bee02436@github.com>
 <nAPBZpXVMX51_LaFPG-hbZG66Xci4qlVHkMIttJCLFo=.3df8388f-4f91-4336-bfb1-0c904c423471@github.com>
Message-ID: <4MjSMW92Kv1dmkRcP_f5JfGbjNp4GjnRNiuU3b2m_CQ=.f2021b22-687d-41b3-892e-034e41adbf5e@github.com>

On Fri, 28 Feb 2025 21:30:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ok, so I don't like "Security-Related System Property" because you would not need a title like that for one property. The overall intent of this document is to use it as a place to document more system properties, but if we have no immediate plans to do that within the JDK 25 timeframe, then maybe a more specific title like what Weijun is suggesting is more appropriate.
>> 
>> There are many other security related system properties which are worth documenting but more of them are in the TLS and Kerberos areas, which are in different packages or modules. I'm not sure if we need different html pages for each of those areas. I was really hoping we would have one page for all security library areas.
>> 
>> Let me think about this more first.
>
> Ok, so for now, since we are only documenting one property I think it makes sense (as Weijun suggested) to change the title of this to "The java.security.debug system property". Remove the paragraph starting with "There are several system properties ..."
> 
> As a followup, let's open another issue to add the JSSE system properties to this file, and then it can become more of what was originally intended. So think of this as a temporary title.

Updated. Created new bug to track that [JDK-8350979](https://bugs.openjdk.org/browse/JDK-8350979)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1976167401

From duke at openjdk.org  Sat Mar  1 00:34:56 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 1 Mar 2025 00:34:56 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v10]
In-Reply-To: <j9WWfnENe1OVlQ5GYHIizEHs9RUDpKJjRMnNI_IlGkA=.41e2e16a-4f01-47cc-ba9d-81ece630698e@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <SHSLHuzELP-S3vJf1ClUkvY5E6yNIEEUiYeUTJAkl28=.75a6d756-f793-44a4-9048-2822d4f98a7c@github.com>
 <j9WWfnENe1OVlQ5GYHIizEHs9RUDpKJjRMnNI_IlGkA=.41e2e16a-4f01-47cc-ba9d-81ece630698e@github.com>
Message-ID: <x4KznFTDSrhy5Rl1FIlqCy8Mv7RcDWUzbscKG6kWTl8=.85ab8aab-8ef1-43d3-be83-818389f38c7f@github.com>

On Fri, 28 Feb 2025 21:31:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8328914: Document the java.security.debug property in javadoc
>
> src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 75:
> 
>> 73:     set the <code>java.security.debug</code> system property on the command line as follows:
>> 74:     <pre><code>java -Djava.security.debug=all+thread+timestamp MyApp</code></pre>
>> 75:         <p> To monitor security access, you can set the <code>java.security.debug</code> system property,
> 
> This paragraph should be first, before the "Printing Thread and Timestamp Information" section. It describe the general syntax of the property, whereas the thread and timestamp are more specific options.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1976168412

From ecki at zusammenkunft.net  Sat Mar  1 14:42:32 2025
From: ecki at zusammenkunft.net (Bernd)
Date: Sat, 1 Mar 2025 15:42:32 +0100
Subject: 8245545: TLS_RSA roadmap
In-Reply-To: <7f9731ad-ac6b-40a8-b8d2-1dac71b8b1eb@oracle.com>
References: <5F6B9BDF-E769-FF40-BEB7-D7E93517D02D@hxcore.ol>,
 <7f9731ad-ac6b-40a8-b8d2-1dac71b8b1eb@oracle.com>
Message-ID: <F6F66821-CAE1-F14F-99AE-AA5E0F0F8453@hxcore.ol>

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

From weijun at openjdk.org  Sat Mar  1 15:19:39 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 1 Mar 2025 15:19:39 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v6]
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: <j0TKwhKL3qLM38yJZx6WBCOFcBCYWoZQ0yu6M9YG270=.8d3eac74-6a9b-4ca8-968c-0d0c88b6e89b@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> 
> ![HPKEParameterSpec](https://github.com/user-attachments/assets/4f64567a-59b0-473e-8a3b-416565f5bca5)

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

  typo, and other cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/92712652..8342e7d4

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

  Stats: 20 lines in 2 files changed: 4 ins; 2 del; 14 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 jamil.j.nimeh at oracle.com  Sat Mar  1 17:36:34 2025
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Sat, 1 Mar 2025 09:36:34 -0800
Subject: =?UTF-8?Q?Re=3A_Certificate_Transparency=E2=80=94basic_support_for_?=
 =?UTF-8?Q?the_TLS_extension=3F?=
In-Reply-To: <CANHgQ8Gkrj2BdstCQ5h6vNNL+pF-U5_9ALb84NE6zXseXt6iqw@mail.gmail.com>
References: <CANHgQ8Gkrj2BdstCQ5h6vNNL+pF-U5_9ALb84NE6zXseXt6iqw@mail.gmail.com>
Message-ID: <ffc5789c-3b27-4db9-bcf8-38317d87755d@oracle.com>

Hello Ivan,

You bring up an interesting idea, and it comes at a good time because 
we've been going back and taking another look at CT and SunJSSE.? What 
you are suggesting would be a useful addition, and could also be a step 
towards a full implementation.? I have created 
https://bugs.openjdk.org/browse/JDK-8351001 to track this.? It will need 
a CSR if we decide to go the ExtendedSSLSession route as you were 
suggesting.

A question, since we're on the topic: Is there any value to separating 
out somehow 1.0 and 2.0 SCTs?? Or would a simple List<byte[]> that just 
contains each SCT be sufficient?

Thanks,

--Jamil

On 2/28/2025 12:35 AM, Ivan Ristic wrote:
> Hello group,
>
> From what I can tell, it's currently not possible to consume CT 
> information from Java reliably because there is no way to indicate 
> support for the CT TLS extension [1] in the handshake as well as get 
> the data sent back by a compatible server.
>
> The work involved would be small, for example just grab the raw data 
> and expose it via ExtendedSSLSession, in the same way stapled OCSP 
> responses are currently handled.
>
> However, the improvements would be significant, as this change would 
> enable Java applications to use CT if they so wish.
>
> Apologies as I am not familiar with how things are done; what's the 
> process to make this happen?
>
> [1] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3
>
> -- 
> Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250301/5161f117/attachment-0001.htm>

From duke at openjdk.org  Mon Mar  3 11:18:32 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 3 Mar 2025 11:18:32 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA
Message-ID: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>

By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

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

Commit messages:
 - JDK-8351034 Add AVX-512 intrinsics for ML-DSA

Changes: https://git.openjdk.org/jdk/pull/23860/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351034
  Stats: 2530 lines in 18 files changed: 2445 ins; 9 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/23860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860

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

From weijun at openjdk.org  Mon Mar  3 14:29:15 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 3 Mar 2025 14:29:15 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v7]
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: <I7SbbUyp8tCHUyqvHZsuAulojwtJoNkSWWflqX3_vsU=.09463d90-719f-467d-a1a3-3110a08095e5@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> 
> ![HPKEParameterSpec](https://github.com/user-attachments/assets/4f64567a-59b0-473e-8a3b-416565f5bca5)

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

  unspecified id is -1 now

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/8342e7d4..1839c739

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

  Stats: 78 lines in 4 files changed: 22 ins; 2 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/18411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411

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

From weijun at openjdk.org  Mon Mar  3 15:57:49 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 3 Mar 2025 15:57:49 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v8]
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: <oQNDxVW64uL_Fx9JA89jawXiUvjUhco0S7ydaQ_jKNE=.4eefe68f-9bbd-467e-8420-6daab658835a@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> 
> ![HPKEParameterSpec](https://github.com/user-attachments/assets/3f00d234-e92c-4a5f-8d2f-15f668a7ff08)

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

  add mode_auth and mode_auth_psk, tiny spec change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/1839c739..5b0f319c

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

  Stats: 164 lines in 6 files changed: 88 ins; 36 del; 40 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 abarashev at openjdk.org  Mon Mar  3 16:09:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 3 Mar 2025 16:09:34 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v11]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <1nVKeI7INHcismTXCBGXUAokHVSdhc4IKyL9-ZsQgCQ=.6482df9f-bd9c-4a49-a43b-58a5ff182610@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
> 
> Also fixing JDK-8350807 on the server side just as a side-effect, not a dedicated fix for that issue.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update 2 more copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/748cbb55..bc8d933e

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

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

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

From weijun at openjdk.org  Mon Mar  3 16:42:33 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 3 Mar 2025 16:42:33 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?"
Message-ID: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>

Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.

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

Commit messages:
 - another fix
 - the fix

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

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

From abarashev at openjdk.org  Mon Mar  3 18:30:57 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 3 Mar 2025 18:30:57 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?"
In-Reply-To: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
Message-ID: <FceaY6EwhW1ld3HEtLu09eLAsTmAiSl1z4RphD-kz8I=.34e7b44c-9de6-4d4f-97cf-6bb73109bb1f@github.com>

On Mon, 3 Mar 2025 16:26:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.

test/jdk/sun/security/krb5/MicroTime.java line 48:

> 46:         }
> 47:         // We believe a nice KerberosTime can at least tell the
> 48:         // difference of 100 musec.

What's "musec"? Should it be "nanoseconds"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23867#discussion_r1977982378

From abarashev at openjdk.org  Mon Mar  3 18:35:53 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 3 Mar 2025 18:35:53 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?"
In-Reply-To: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
Message-ID: <5VaBrxseYt1gyqKZ0YwgF0OEcJ9JLh5lYwMrR9TY6NQ=.4200852a-d745-4823-8616-5dd14f38cede@github.com>

On Mon, 3 Mar 2025 16:26:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.

test/jdk/sun/security/krb5/MicroTime.java line 49:

> 47:         // Before this change, KerberosTime was implemented in milliseconds.
> 48:         // Now there should be more.
> 49:         if (count < 1001) {

Why 1001 and not 1000?

test/jdk/sun/security/krb5/MicroTime.java line 50:

> 48:         // Now there should be more.
> 49:         if (count < 1001) {
> 50:             throw new Exception("What? only " + (1000000/count) +

Shouldn't we add a zero to "1000000/count" as well to account for the measured precision change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23867#discussion_r1977988750
PR Review Comment: https://git.openjdk.org/jdk/pull/23867#discussion_r1977988447

From abarashev at openjdk.org  Mon Mar  3 18:58:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 3 Mar 2025 18:58:58 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?"
In-Reply-To: <FceaY6EwhW1ld3HEtLu09eLAsTmAiSl1z4RphD-kz8I=.34e7b44c-9de6-4d4f-97cf-6bb73109bb1f@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
 <FceaY6EwhW1ld3HEtLu09eLAsTmAiSl1z4RphD-kz8I=.34e7b44c-9de6-4d4f-97cf-6bb73109bb1f@github.com>
Message-ID: <0cUFOQXvC9r7VeW-Anw7ODn78kiP-tz3zd2EbFU-Ulk=.79ee9488-cc92-4ca9-833a-a2cdbb32427e@github.com>

On Mon, 3 Mar 2025 18:28:27 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.
>
> test/jdk/sun/security/krb5/MicroTime.java line 48:
> 
>> 46:         }
>> 47:         // We believe a nice KerberosTime can at least tell the
>> 48:         // difference of 100 musec.
> 
> What's "musec"? Should it be "nanoseconds"?

Nevermind, I see that it's actually microsecond.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23867#discussion_r1978024627

From duke at openjdk.org  Mon Mar  3 19:00:59 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 3 Mar 2025 19:00:59 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v2]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <Ona146wzT7py7EoMfS_4weGixbRkxvw0OsnNeDt2yl8=.179adb54-62f0-4d77-b5ec-865d1924c627@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Added comments, removed debugging printfs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/1ff58512..fe50e0d8

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

  Stats: 12 lines in 2 files changed: 9 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860

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

From abarashev at openjdk.org  Mon Mar  3 19:02:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 3 Mar 2025 19:02:52 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?"
In-Reply-To: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
Message-ID: <opezUT-rCRNDjkfSOXq2utD2sjQsdX9bvzLozCEep2k=.c6939d8f-cc07-42c5-95e8-27b6d45a0683@github.com>

On Mon, 3 Mar 2025 16:26:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.

LGTM

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

Marked as reviewed by abarashev (Author).

PR Review: https://git.openjdk.org/jdk/pull/23867#pullrequestreview-2655001271

From abarashev at openjdk.org  Mon Mar  3 19:02:53 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 3 Mar 2025 19:02:53 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?"
In-Reply-To: <5VaBrxseYt1gyqKZ0YwgF0OEcJ9JLh5lYwMrR9TY6NQ=.4200852a-d745-4823-8616-5dd14f38cede@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
 <5VaBrxseYt1gyqKZ0YwgF0OEcJ9JLh5lYwMrR9TY6NQ=.4200852a-d745-4823-8616-5dd14f38cede@github.com>
Message-ID: <AzcmxdblZ1Ma9CobFvHk_Miy8kIGBNzcUkyG6KZmasQ=.3269f294-c168-4d10-ade3-20fff705f6ba@github.com>

On Mon, 3 Mar 2025 18:32:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.
>
> test/jdk/sun/security/krb5/MicroTime.java line 49:
> 
>> 47:         // Before this change, KerberosTime was implemented in milliseconds.
>> 48:         // Now there should be more.
>> 49:         if (count < 1001) {
> 
> Why 1001 and not 1000?

Nevermind that, 1001 is needed to make sure we have a precision at least better than 1 millisecond. So 1001 unique timestamps out of of 1M gives us just that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23867#discussion_r1978028835

From sviswanathan at openjdk.org  Tue Mar  4 00:02:08 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 4 Mar 2025 00:02:08 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64
In-Reply-To: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
Message-ID: <mslvF8kyj4JXXAZ2BuocJiUEP9MGmKHnWuupmMOGH2A=.3899f12f-a6fd-4a5e-98ad-6cd001c0dd23@github.com>

On Thu, 20 Feb 2025 21:49:42 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
> 
> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
> 
> Before (no AVX512)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
> 
> After (with AVX2)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
> 
> 
> Before (with AVX512):
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        102...

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Intel Corporation. All rights reserved.

This should be:
Copyright (c) 2024, 2025, Intel Corporation. All rights reserved.

Also please check that the copyright year is appropriately updated in all the files.

src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 259:

> 257:     }
> 258:     __ vpaddq(Acc1, Acc1, Carry, Assembler::AVX_256bit);
> 259:   }

A comment here on what this block is doing would help.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1978309062
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1978398909

From hchao at openjdk.org  Tue Mar  4 00:45:33 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 4 Mar 2025 00:45:33 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between CEN
 and LOC
Message-ID: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>

The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

Commit messages:
 - Test on large entry
 - Add cross checking in jarsigner instead of accessing ZIP internals
 - Revert changes to Resources.java
 - Revert changes to Main.java
 - Revert changes to Test.java
 - Revert changes to LowerCaseManifest.java
 - Revert changes to PreserveRawManifestEntryAndDigest.java
 - Remove subclass TrackPushbackInputStream.java
 - Revert changes to JavaUtilZipFileAccess.java
 - Revert changes to ZipInputStream.java
 - ... and 10 more: https://git.openjdk.org/jdk/compare/64bd8d25...d5fe503a

Changes: https://git.openjdk.org/jdk/pull/23532/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339280
  Stats: 268 lines in 4 files changed: 268 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

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

From weijun at openjdk.org  Tue Mar  4 01:04:56 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Mar 2025 01:04:56 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v8]
In-Reply-To: <oQNDxVW64uL_Fx9JA89jawXiUvjUhco0S7ydaQ_jKNE=.4eefe68f-9bbd-467e-8420-6daab658835a@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <oQNDxVW64uL_Fx9JA89jawXiUvjUhco0S7ydaQ_jKNE=.4eefe68f-9bbd-467e-8420-6daab658835a@github.com>
Message-ID: <jR7WGE9Ox5s63m5K95ANxjCOcp92TbKoPLGIyU5hDQo=.0d716a72-df66-49a6-90ba-e27d23908c99@github.com>

On Mon, 3 Mar 2025 15:57:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> 
>> ![HPKEParameterSpec](https://github.com/user-attachments/assets/3f00d234-e92c-4a5f-8d2f-15f668a7ff08)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add mode_auth and mode_auth_psk, tiny spec change

Initially, I was unsure whether to support `mode_auth` and `mode_auth_psk` since our `KEM` API does not support authenticated encapsulation. However, after looking at HPKE implementations from other vendors -- such as OpenSSL, Go, and Rust -- I found that most of them support it. In the latest commit, I?ve added support by directly invoking newly added methods in the `DHKEM` private class.

Note that DHKEM is a higher-level cryptographic algorithm built on lower-level primitives like DH key agreement and HKDF. As a result, even though it is implemented only in the SunJCE provider, it can handle keys or IKM values from other providers by leveraging DH and HKDF from those providers.

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

PR Comment: https://git.openjdk.org/jdk/pull/18411#issuecomment-2695918278

From alanb at openjdk.org  Tue Mar  4 08:56:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Mar 2025 08:56:54 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <gyVf9gWfZIc0M-SWSaPfea_TI7Q99YkcOQLAOMeHtug=.44b8ecf9-5551-4014-8065-feca1275ba85@github.com>

On Sun, 9 Feb 2025 05:02:07 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

I think we need to stand back from all this validation and consider what validation/checking should be done by jar tool vs. jarsigner tool. I think there is a strong argument to expand what `jar --validate` does (or add a new option) so that the jar tool can do the integrity checks that include the checks to ensure that the CEN and LOC entries are consistent.  The `jarsigner -verify` option could augment that with focus on the signing rather than on ZIP or JAR file integrity issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/23532#issuecomment-2696686476

From duke at openjdk.org  Tue Mar  4 11:14:01 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 4 Mar 2025 11:14:01 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v7]
In-Reply-To: <dDw877tmMKNbdKSXIoAookE9CPwydOtWM8N1OIj4q7A=.1e26c53e-5ae0-4c1e-a22b-9d7ca284aa68@github.com>
References: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
 <bGF_OqX377tbkkgzkwww0GZfE40OxsOf4uU3X_8KPHE=.9bb9cd5a-49c4-470b-8fa4-44bc81e05928@github.com>
 <dDw877tmMKNbdKSXIoAookE9CPwydOtWM8N1OIj4q7A=.1e26c53e-5ae0-4c1e-a22b-9d7ca284aa68@github.com>
Message-ID: <SIhQXbXG9IqkQq9ldhGZCRb_ut0LYKUBetOnkRpR7SE=.d2381ce3-365e-4337-8772-491193e89e55@github.com>

On Thu, 27 Feb 2025 09:53:21 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Oops. sorry - cut and paste error -- the new setting should be
> 
> ```
> do_arch_blob(compiler, 55000 ZGC_ONLY(+5000))
> ```

@adinn, I have done this change, but that erased your approval. Could you reapprove?

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

PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2697145316

From adinn at openjdk.org  Tue Mar  4 11:21:00 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 4 Mar 2025 11:21:00 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v8]
In-Reply-To: <Kkfzgfg4Op3XpVBv4QezdDMS43v1mwyzN9UI47q3asE=.1a7edee1-0500-43c6-a0f8-b430e88150dc@github.com>
References: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
 <Kkfzgfg4Op3XpVBv4QezdDMS43v1mwyzN9UI47q3asE=.1a7edee1-0500-43c6-a0f8-b430e88150dc@github.com>
Message-ID: <LqHBJamypDpKlBflkBZ6svodvuRe07Oe01rCH06viaI=.acff5ac0-b7b6-4fcf-827c-60cccb67604a@github.com>

On Fri, 28 Feb 2025 06:22:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merged master.
>  - Added more comments, mainly as suggested by Andrew Dinn
>  - Changed aarch64-asmtest.py as suggested by Bhavana-Kilambi
>  - Accepting suggested change from Andrew Dinn
>  - Added comments suggested by Andrew Dinn
>  - Fixed copyright years
>  - renaming a couple of functions
>  - Adding comments + some code reorganization
>  - removed debugging code
>  - merging master
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/ab4b0ef9...d82dfb2f

Still good.

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23300#pullrequestreview-2657047714

From mdonovan at openjdk.org  Tue Mar  4 12:59:02 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 4 Mar 2025 12:59:02 GMT
Subject: RFR: 8219408: Tests should handle ${} in the view of jtreg
 "smart action"
Message-ID: <YOGQ8ZDmWhFPNdfPkpRG5BaiqkniwSUsigE-L1FitXo=.7e01ef4d-cb65-4729-9394-7dc014c8ecfd@github.com>

In this PR I removed TEST.properties files that disabled smart action tags. It is safe to remove the entire file: the smart action tags was the only directive in them. I verified the affected tests pass successfully.

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

Commit messages:
 - 8219408: Tests should handle ${} in the view of jtreg "smart action"

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

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

From adinn at openjdk.org  Tue Mar  4 14:04:03 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 4 Mar 2025 14:04:03 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v7]
In-Reply-To: <SIhQXbXG9IqkQq9ldhGZCRb_ut0LYKUBetOnkRpR7SE=.d2381ce3-365e-4337-8772-491193e89e55@github.com>
References: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
 <bGF_OqX377tbkkgzkwww0GZfE40OxsOf4uU3X_8KPHE=.9bb9cd5a-49c4-470b-8fa4-44bc81e05928@github.com>
 <dDw877tmMKNbdKSXIoAookE9CPwydOtWM8N1OIj4q7A=.1e26c53e-5ae0-4c1e-a22b-9d7ca284aa68@github.com>
 <SIhQXbXG9IqkQq9ldhGZCRb_ut0LYKUBetOnkRpR7SE=.d2381ce3-365e-4337-8772-491193e89e55@github.com>
Message-ID: <UpZNmeK8RjbujG3sSVgop5ewyxRCjMDw4zJmRuPF03w=.166c18b6-613e-4730-a969-5f77cefc094d@github.com>

On Tue, 4 Mar 2025 11:11:44 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Oops. sorry - cut and paste error -- the new setting should be
>> 
>> do_arch_blob(compiler, 55000 ZGC_ONLY(+5000))
>
>> Oops. sorry - cut and paste error -- the new setting should be
>> 
>> ```
>> do_arch_blob(compiler, 55000 ZGC_ONLY(+5000))
>> ```
> 
> @adinn, I have done this change, but that erased your approval. Could you reapprove?

@ferakocz Feel free to integrate and I will sponsor

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

PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2697719261

From fguallini at openjdk.org  Tue Mar  4 14:04:43 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Tue, 4 Mar 2025 14:04:43 GMT
Subject: RFR: 8249825: Tests sun/security/ssl/SSLSocketImpl/SetClientMode.java
 and NonAutoClose.java marked with @ignore
Message-ID: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>

The following tests are marked with @ignore (not running):

- sun/security/ssl/SSLSocketImpl/SetClientMode.java: it checks that setting the clientMode after the handshake has begun is not permitted, but this was failing intermittently due to a race condition, it was possible that SetClientMode was called before the client socket was updated with handshake isNegotiated = true. The fix is to introduce a latch to sync between client and main threads. Included additional refactoring to ensure test stability.

- sun/security/ssl/SSLSocketImpl/NonAutoClose.java: This test should only run in TLS <= 1.2, as TLSv1.3 changes the behaviour of close_notify. Included additional refactoring to ensure test stability.

Executed both tests 10K times, no test flakiness found

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

Commit messages:
 - Merge branch 'master' into 8249825
 - SetClientMode minor cleanup
 - NonAutoClose.java and SetClientMode.java passing
 - removed @ignore from NonAutoClose and SetClientMode

Changes: https://git.openjdk.org/jdk/pull/23898/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23898&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8249825
  Stats: 354 lines in 2 files changed: 30 ins; 179 del; 145 mod
  Patch: https://git.openjdk.org/jdk/pull/23898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23898/head:pull/23898

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

From duke at openjdk.org  Tue Mar  4 14:13:05 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Mar 2025 14:13:05 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v8]
In-Reply-To: <Kkfzgfg4Op3XpVBv4QezdDMS43v1mwyzN9UI47q3asE=.1a7edee1-0500-43c6-a0f8-b430e88150dc@github.com>
References: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
 <Kkfzgfg4Op3XpVBv4QezdDMS43v1mwyzN9UI47q3asE=.1a7edee1-0500-43c6-a0f8-b430e88150dc@github.com>
Message-ID: <4goExO2NlWn1wVnu0eYddpXAN4h_t9F7VG4b-MHI_sE=.74de8ba0-eec5-401e-9aa5-6bda6a4e74a5@github.com>

On Fri, 28 Feb 2025 06:22:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merged master.
>  - Added more comments, mainly as suggested by Andrew Dinn
>  - Changed aarch64-asmtest.py as suggested by Bhavana-Kilambi
>  - Accepting suggested change from Andrew Dinn
>  - Added comments suggested by Andrew Dinn
>  - Fixed copyright years
>  - renaming a couple of functions
>  - Adding comments + some code reorganization
>  - removed debugging code
>  - merging master
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/ab4b0ef9...d82dfb2f

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

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

PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2697751091

From duke at openjdk.org  Tue Mar  4 14:13:05 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 4 Mar 2025 14:13:05 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v7]
In-Reply-To: <SIhQXbXG9IqkQq9ldhGZCRb_ut0LYKUBetOnkRpR7SE=.d2381ce3-365e-4337-8772-491193e89e55@github.com>
References: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
 <bGF_OqX377tbkkgzkwww0GZfE40OxsOf4uU3X_8KPHE=.9bb9cd5a-49c4-470b-8fa4-44bc81e05928@github.com>
 <dDw877tmMKNbdKSXIoAookE9CPwydOtWM8N1OIj4q7A=.1e26c53e-5ae0-4c1e-a22b-9d7ca284aa68@github.com>
 <SIhQXbXG9IqkQq9ldhGZCRb_ut0LYKUBetOnkRpR7SE=.d2381ce3-365e-4337-8772-491193e89e55@github.com>
Message-ID: <WUYBI649aucd85gNsd8MmWUsqhRObH9tcKbKq7woLXw=.3e0fa35a-7725-442f-a8eb-8dc11f444e89@github.com>

On Tue, 4 Mar 2025 11:11:44 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Oops. sorry - cut and paste error -- the new setting should be
>> 
>> do_arch_blob(compiler, 55000 ZGC_ONLY(+5000))
>
>> Oops. sorry - cut and paste error -- the new setting should be
>> 
>> ```
>> do_arch_blob(compiler, 55000 ZGC_ONLY(+5000))
>> ```
> 
> @adinn, I have done this change, but that erased your approval. Could you reapprove?

> @ferakocz Feel free to integrate and I will sponsor

@adinn thanks a lot for the review and the sponsoring, too!

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

PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2697761033

From mullan at openjdk.org  Tue Mar  4 14:32:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 4 Mar 2025 14:32:55 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?"
In-Reply-To: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
Message-ID: <BesEXyXK4Wvy-Ha7mve3KBEdY5LKz7oQHPUEpCOcLT4=.06149e18-8139-46e0-b3fc-fc4e6639d130@github.com>

On Mon, 3 Mar 2025 16:26:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.

test/jdk/sun/security/krb5/MicroTime.java line 49:

> 47:         // Before this change, KerberosTime was implemented in milliseconds.
> 48:         // Now there should be more.
> 49:         if (count < 1001) {

Can you make this comment more specific? What change was this? And what is the precision after the change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23867#discussion_r1979577596

From mullan at openjdk.org  Tue Mar  4 14:36:04 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 4 Mar 2025 14:36:04 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v8]
In-Reply-To: <Kkfzgfg4Op3XpVBv4QezdDMS43v1mwyzN9UI47q3asE=.1a7edee1-0500-43c6-a0f8-b430e88150dc@github.com>
References: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
 <Kkfzgfg4Op3XpVBv4QezdDMS43v1mwyzN9UI47q3asE=.1a7edee1-0500-43c6-a0f8-b430e88150dc@github.com>
Message-ID: <fBcbOxblqmweHUM4cYEqnwAajvnDW1ShjIGsTgNhlsw=.f1a40611-a6a1-4f87-8d1c-dd7d0e10502d@github.com>

On Fri, 28 Feb 2025 06:22:09 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merged master.
>  - Added more comments, mainly as suggested by Andrew Dinn
>  - Changed aarch64-asmtest.py as suggested by Bhavana-Kilambi
>  - Accepting suggested change from Andrew Dinn
>  - Added comments suggested by Andrew Dinn
>  - Fixed copyright years
>  - renaming a couple of functions
>  - Adding comments + some code reorganization
>  - removed debugging code
>  - merging master
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/ab4b0ef9...d82dfb2f

I think it would be nice to add a release note for this describing the approximate performance improvement.

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

PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2697841749

From duke at openjdk.org  Tue Mar  4 14:44:00 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 4 Mar 2025 14:44:00 GMT
Subject: Integrated: 8348561: Add aarch64 intrinsics for ML-DSA
In-Reply-To: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
References: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
Message-ID: <G9MmPgHVVXuK5m_r37j25HLQwa_y324m6Ww-RkDavmU=.6ee17042-fda9-4096-b995-121665dbd22f@github.com>

On Fri, 24 Jan 2025 14:24:23 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> By using the aarch64 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

This pull request has now been integrated.

Changeset: 3230894b
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3230894bdd8ab4183b83ad4c942eb6acad4acce6
Stats:     2611 lines in 22 files changed: 2030 ins; 92 del; 489 mod

8348561: Add aarch64 intrinsics for ML-DSA

Reviewed-by: adinn

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

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

From ivan.ristic at gmail.com  Tue Mar  4 15:39:04 2025
From: ivan.ristic at gmail.com (Ivan Ristic)
Date: Tue, 4 Mar 2025 15:39:04 +0000
Subject: =?UTF-8?Q?Re=3A_Certificate_Transparency=E2=80=94basic_support_for_the?=
 =?UTF-8?Q?_TLS_extension=3F?=
In-Reply-To: <ffc5789c-3b27-4db9-bcf8-38317d87755d@oracle.com>
References: <CANHgQ8Gkrj2BdstCQ5h6vNNL+pF-U5_9ALb84NE6zXseXt6iqw@mail.gmail.com>
 <ffc5789c-3b27-4db9-bcf8-38317d87755d@oracle.com>
Message-ID: <CANHgQ8E4+aTL_bx-VG15gZMh0SbVnPuVsvwafdZNVUz4EL0KHQ@mail.gmail.com>

Hi Jamil,

Thanks for opening that ticket. I notice that the wording is generic to
SCTs, which might indicate that you want to include the ones embedded in
certificates and OCSP responses. Did you meant that? If so, they will
absolutely need a wrapper to indicate the source. In that case, you must
just as well include a version number so that the wrapper is generic and
future-compatible.

It probably makes sense to include all SCTs because?I am guessing?it will
not be possible for non-JDK code to observe OCSP responses that are not
stapled by obtained as part of TLS auth? In this case the source would not
be a stapled OCSP response, but one fetched directly from the responder.

If we're talking only about the TLS extension, if you include the raw
extension bytes they will contain the extension ID, which may be sufficient
if CT 2.0 is ever implemented. (CT 2.0 uses the transparency_info
extension.)


On Sat, Mar 1, 2025 at 5:43?PM Jamil Nimeh <jamil.j.nimeh at oracle.com> wrote:

> Hello Ivan,
>
> You bring up an interesting idea, and it comes at a good time because
> we've been going back and taking another look at CT and SunJSSE.  What you
> are suggesting would be a useful addition, and could also be a step towards
> a full implementation.  I have created
> https://bugs.openjdk.org/browse/JDK-8351001 to track this.  It will need
> a CSR if we decide to go the ExtendedSSLSession route as you were
> suggesting.
>
> A question, since we're on the topic: Is there any value to separating out
> somehow 1.0 and 2.0 SCTs?  Or would a simple List<byte[]> that just
> contains each SCT be sufficient?
>
> Thanks,
>
> --Jamil
> On 2/28/2025 12:35 AM, Ivan Ristic wrote:
>
> Hello group,
>
> From what I can tell, it's currently not possible to consume CT
> information from Java reliably because there is no way to indicate support
> for the CT TLS extension [1] in the handshake as well as get the data sent
> back by a compatible server.
>
> The work involved would be small, for example just grab the raw data and
> expose it via ExtendedSSLSession, in the same way stapled OCSP responses
> are currently handled.
>
> However, the improvements would be significant, as this change would
> enable Java applications to use CT if they so wish.
>
> Apologies as I am not familiar with how things are done; what's the
> process to make this happen?
>
> [1] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3
>
> --
> Ivan
>
>

-- 
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250304/7e29e0d6/attachment.htm>

From jamil.j.nimeh at oracle.com  Tue Mar  4 16:53:46 2025
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 4 Mar 2025 08:53:46 -0800
Subject: =?UTF-8?Q?Re=3A_=5BExternal=5D_=3A_Re=3A_Certificate_Transparency?=
 =?UTF-8?Q?=E2=80=94basic_support_for_the_TLS_extension=3F?=
In-Reply-To: <CANHgQ8E4+aTL_bx-VG15gZMh0SbVnPuVsvwafdZNVUz4EL0KHQ@mail.gmail.com>
References: <CANHgQ8Gkrj2BdstCQ5h6vNNL+pF-U5_9ALb84NE6zXseXt6iqw@mail.gmail.com>
 <ffc5789c-3b27-4db9-bcf8-38317d87755d@oracle.com>
 <CANHgQ8E4+aTL_bx-VG15gZMh0SbVnPuVsvwafdZNVUz4EL0KHQ@mail.gmail.com>
Message-ID: <2d2fbdcd-355c-4cc8-8152-ae9c0c8c2cbf@oracle.com>

Hi Ivan,

Thanks for the feedback.? Yes, it was my intent to include extensions 
that come in from all potential sources, be it via the hello extension, 
embedded in certs, or via OCSP responses.? The source did seem 
important.? And I did want to be sensitive to 1.0 and 2.0 formats since 
both are in RFC form, not drafts.? Or at least design things with 
forward compatibility in mind.

I had one other question in going through both RFCs (6962 and 9162).? 
Both of those specifications seem to focus on the end-entity TLS 
certificate.? In looking at the CAB baseline requirements, it appears 
that signed certificate timestamp lists can exist in subordinate CA 
certificates too.? I just don't know how common that is, since it is a 
"MAY" in the baseline requirements.? So I'm wondering if it will be 
helpful in presenting to the Java consumer the list of SCTs also grouped 
by certificate in some fashion.? Do you think that would be helpful? It 
could be simply ordered in the same ordering as the chain is presented, 
or it could be ordered by X509Certificate or maybe a certificate hash.? 
Not sure.? I would love to hear your thoughts on that.

I wasn't thinking along the lines of including the raw extension bytes.? 
That certainly would be one way to expose 1.0 vs. 2.0, but there may be 
other ways to present the data to the user that lessens the work on the 
user's side in terms of parsing the data. I'm still chewing on that one 
because presenting the SCTs as objects rather than opaque byte arrays 
means a larger API change. But I'm also looking at how much we can pave 
the way with this RFE towards a full implementation in the future.? The 
CSR would be explicit about all of these public, API changes and while 
in draft form there can be discussion and changes/improvements to any 
proposed API.

Thanks,

--Jamil

On 3/4/2025 7:39 AM, Ivan Ristic wrote:
> Hi Jamil,
>
> Thanks for opening that ticket. I notice that the wording is generic 
> to SCTs, which might indicate that you want to include the ones 
> embedded in certificates and OCSP responses. Did you meant that? If 
> so, they will absolutely need a wrapper to indicate the source. In 
> that case, you must just as well include a version number so that the 
> wrapper is generic and future-compatible.
>
> It probably makes sense to include all SCTs because?I am guessing?it 
> will not be possible for non-JDK code to observe OCSP responses that 
> are not stapled by obtained as part of TLS auth? In this case the 
> source would not be a stapled OCSP response, but one fetched directly 
> from the responder.
>
> If we're talking only about the TLS extension, if you include the raw 
> extension bytes they will contain the extension ID, which may be 
> sufficient if CT 2.0 is ever implemented. (CT 2.0 uses the 
> transparency_info extension.)
>
>
> On Sat, Mar 1, 2025 at 5:43?PM Jamil Nimeh <jamil.j.nimeh at oracle.com> 
> wrote:
>
>     Hello Ivan,
>
>     You bring up an interesting idea, and it comes at a good time
>     because we've been going back and taking another look at CT and
>     SunJSSE.? What you are suggesting would be a useful addition, and
>     could also be a step towards a full implementation.? I have
>     created https://bugs.openjdk.org/browse/JDK-8351001 to track
>     this.? It will need a CSR if we decide to go the
>     ExtendedSSLSession route as you were suggesting.
>
>     A question, since we're on the topic: Is there any value to
>     separating out somehow 1.0 and 2.0 SCTs?? Or would a simple
>     List<byte[]> that just contains each SCT be sufficient?
>
>     Thanks,
>
>     --Jamil
>
>     On 2/28/2025 12:35 AM, Ivan Ristic wrote:
>>     Hello group,
>>
>>     From what I can tell, it's currently not possible to consume CT
>>     information from Java reliably because there is no way to
>>     indicate support for the CT TLS extension [1] in the handshake as
>>     well as get the data sent back by a compatible server.
>>
>>     The work involved would be small, for example just grab the raw
>>     data and expose it via ExtendedSSLSession, in the same way
>>     stapled OCSP responses are currently handled.
>>
>>     However, the improvements would be significant, as this change
>>     would enable Java applications to use CT if they so wish.
>>
>>     Apologies as I am not familiar with how things are done; what's
>>     the process to make this happen?
>>
>>     [1] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3
>>     <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc6962*section-3.3__;Iw!!ACWV5N9M2RV99hQ!KIjWS6IHmhoDGv9tfyCSWMgzO-npdeXAxxTQG_s33nlcSE-1pfSaJwn8VVfEWUCHr3yHRBCy0GRmUkTxqSBjvmSW$>
>>
>>     -- 
>>     Ivan
>
>
>
> -- 
> Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250304/de431b80/attachment-0001.htm>

From weijun at openjdk.org  Tue Mar  4 18:12:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Mar 2025 18:12:09 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?" [v2]
In-Reply-To: <BesEXyXK4Wvy-Ha7mve3KBEdY5LKz7oQHPUEpCOcLT4=.06149e18-8139-46e0-b3fc-fc4e6639d130@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
 <BesEXyXK4Wvy-Ha7mve3KBEdY5LKz7oQHPUEpCOcLT4=.06149e18-8139-46e0-b3fc-fc4e6639d130@github.com>
Message-ID: <1JAphbcZ8af9rT_FyxS6Dh4p12jmSZsgwTYe2o2eji8=.dbf1ad08-1c6b-4d89-8011-7a17a446e665@github.com>

On Tue, 4 Mar 2025 14:29:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarified comment
>
> test/jdk/sun/security/krb5/MicroTime.java line 49:
> 
>> 47:         // Before this change, KerberosTime was implemented in milliseconds.
>> 48:         // Now there should be more.
>> 49:         if (count < 1001) {
> 
> Can you make this comment more specific? What change was this? And what is the precision after the change?

Updated. I was pretending the comment was written right when the bug was fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23867#discussion_r1979964164

From weijun at openjdk.org  Tue Mar  4 18:12:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Mar 2025 18:12:09 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?" [v2]
In-Reply-To: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
Message-ID: <vVLsWcN38DZCrNyLLXEsqr8JUJzYsGMZCr16DYAuc3M=.d2e3b893-f152-4d70-af87-d5180b04400a@github.com>

> Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.

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

  clarified comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23867/files
  - new: https://git.openjdk.org/jdk/pull/23867/files/2c569f4c..e8c3355a

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

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

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

From valeriep at openjdk.org  Tue Mar  4 18:34:07 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 4 Mar 2025 18:34:07 GMT
Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider
 services map [v5]
In-Reply-To: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
References: <fkJRJjb6eiFCZkmopox2b_YJALJMDOxX6zk8iQcud0k=.ef06e29f-3b21-42a9-beb9-7e5dedd06b02@github.com>
 <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
Message-ID: <5OAu5Fh8x-zD6rqfcncojGflCjDyt9Y4fL45Tp4VfDk=.2168327d-fbcd-4a15-b401-87b36299943a@github.com>

On Wed, 12 Feb 2025 20:46:31 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map").
>> 
>> #### New services map design
>> 
>> Here is the high-level hierarchy of the new services map design:
>> 
>> * `servicesMap` (`ServicesMap`)
>>     * Instances (fields)
>>         * `services` (`Map<ServiceKey, Service>`): unifies the previous `serviceMap` and `legacyMap`
>>         * `legacySvcKeys` (`Set<ServiceKey>`): set indicating which keys in `services` correspond to the Legacy API
>>         * `serviceProps` (`Map<ServiceKey, String>`): keeps track of the _provider Hashtable entries_ that originated services entries <sup>(1)</sup>
>>         * `serviceAttrProps` (`Map<ServiceKey, Map<UString, String>>`): keeps track of the _provider Hashtable entries_ that originated service attributes <sup>(1)</sup>
>>         * `serviceSet` (`AtomicReference<Set<Service>>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method
>>     * Writers' methods (for providers registering services through the Current or the Legacy API)
>>         * `boolean putService(Service svc)`
>>         * `boolean removeService(Service svc)`
>>         * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)`
>>         * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)`
>>         * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)`
>>         * `boolean removeLegacy(ServiceKey key, String className)`
>>         * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)`
>>         * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)`
>>     * Readers' methods (for services users and `GetInstance` APIs)
>>         * `Set<Service> getServices()`
>>         * `Service getService(ServiceKey key)`
>>     * Other methods: default and copy constructors, `void clear()`
>> 
>> (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms.
>> 
>> #### Testing
>> 
>> As part of our testing, we observed all the tests pass in the following categories:
>> 
>> * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398))
>> * `jdk/com/sun/crypto`
>> * `jd...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear ServicesMap fields in the declared order
>   
>   Constructors assign the fields in the same order.

src/java.base/share/classes/java/security/Provider.java line 637:

> 635:     // let javadoc show doc from superclass
> 636:     @Override
> 637:     public synchronized Object get(Object key) {

How about the getProperty(String) method on line 675? Add `@Override` tag and `synchronized` keyword there also? And the `keySet()` and `values()` methods on line 432 and 444 respectively? What is the criteria for synchronizing the method of the `Provider` class?

src/java.base/share/classes/java/security/Provider.java line 713:

> 711:          */
> 712:         private record MappingInfo(Service svc, ServiceKey algKey,
> 713:                 Boolean isLegacy) {}

There is comment states that `isLegacy` may be null, but then I also see a few if-cond using `isLegacy` directly like its a boolean, wouldn't it lead to NPE if `isLegacy` is `null`?

src/java.base/share/classes/java/security/Provider.java line 735:

> 733:         // with the Legacy API. The absence of a service key on this set is an
> 734:         // indication that the service was either not added or added with the
> 735:         // Current API. Only algorithm service keys are added to this set.

nit: I find the sentence "The absence of a service key on this set ... added with Current API" is somewhat redundant. I suppose you mean "not added with the Legacy API or added with the Current API". The first sentence is clear enough and the second sentence doesn't add much value.

src/java.base/share/classes/java/security/Provider.java line 750:

> 748:         private final Map<ServiceKey, Map<UString, String>> serviceAttrProps;
> 749: 
> 750:         ServicesMap() {

nit: add comment for this constructor?

src/java.base/share/classes/java/security/Provider.java line 988:

> 986:                         // The service was added with the Current API. Overwrite
> 987:                         // the alias entry on the services map without modifying
> 988:                         // the service that is currently using it.

Is the "service" in the above line really means the provider `service` entry? If so, may be "associated with" is better than "using". Also there is no code under this comment block, where is the action of "overwrite the alias entry on the services map"?

src/java.base/share/classes/java/security/Provider.java line 1037:

> 1035:             }
> 1036: 
> 1037:             if (mi.isLegacy) {

For legacy entry, there is no check on the `legacyApiCall` value, is this due to the call path from `resolveKeyConflict` method? However, should a legacy entry be removed by the `removeService` method? If not, then additional check may be needed?

src/java.base/share/classes/java/security/Provider.java line 1654:

> 1652:     }
> 1653: 
> 1654:     // used as key in the serviceMap and legacyMap HashMaps

This comment is obsolete with the new impl and should be updated.

src/java.base/share/classes/java/security/Provider.java line 2071:

> 2069:         // For services added to a ServicesMap, their algorithm service key.
> 2070:         // This value derives from the algorithm field. For services (still)
> 2071:         // not added to a ServicesMap, value is null.

The current comment is a bit hard to read.
How about "The mapping key of this service when added to a `ServiceMap`; null if not yet added to a `ServiceMap`"?
The value is derived from the type and algorithm and this is straightforward enough that probably need not be commented.

src/java.base/share/classes/java/security/Provider.java line 2078:

> 2076:         // entries derive from the aliases field, keys are not repeated
> 2077:         // (case-insensitive comparison) and not equal to the algorithm. For
> 2078:         // services (still) not added to a ServicesMap, value is an empty map.

Could we re-write it to summarize the conditions for empty map? It could be easier to read/understand.
For example: empty map if no aliases or if this service is not yet added to a `ServiceMap`.
The part of case-insensitive comparision, it's due to the impl of `ServiceKey`, right? Maybe we can simply refer to that no need to describe it here.

src/java.base/share/classes/java/security/Provider.java line 2110:

> 2108: 
> 2109:         /*
> 2110:          * Constructor used from the ServicesMap Legacy API.

nit: "used **by**"? Same goes for other places.

src/java.base/share/classes/java/security/Provider.java line 2149:

> 2147:                 attributes = new HashMap<>(svc.attributes);
> 2148:             }
> 2149:             registered = false;

I didn't see it's set to `true` in any of the constructors; also the default value is already `false`, why only explicitly set it to `false` here?

src/java.base/share/classes/java/security/Provider.java line 2158:

> 2156:             hasKeyAttributes = null;
> 2157:             supportedFormats = null;
> 2158:             supportedClasses = null;

Are these necessary? The other constructor didn't set them.

src/java.base/share/classes/java/security/Provider.java line 2202:

> 2200:                     "Attribute value expected to exist with the same identity.";
> 2201:             attributes.remove(attrKey, attrValue);
> 2202:         }

Is the new impl assuming `attrValue` should never be `null`? Based on javadoc of `Map.remove(Object key, Object value)`, the new impl removes the entry when the associated value is `null` vs the original impl removes the entry regardless of the associated value.

src/java.base/share/classes/java/security/Provider.java line 2241:

> 2239:                 this.attributes = Collections.emptyMap();
> 2240:             } else {
> 2241:                 this.attributes = new HashMap<>();

Initialize with `attributes.size()` and load factor 1.0 if both are the same size?

src/java.base/share/classes/java/security/Provider.java line 2256:

> 2254:          * keys with Service::addAliasKey.
> 2255:          */
> 2256:         private void generateServiceKeys() {

nit: move this private method to be with other private methods?

src/java.base/share/classes/java/security/Provider.java line 2268:

> 2266:                     }
> 2267:                 }
> 2268:                 aliasKeys = Collections.unmodifiableMap(aliasKeys);

if `aliases` are empty, then we can skip line 2261-2268 and no need to update `aliasKeys`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1977987224
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1978378764
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970776267
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970784237
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1978485726
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1978488877
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970753720
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970723732
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970720272
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970724166
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970437584
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970428109
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970698200
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970710298
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970740763
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1970736998

From mullan at openjdk.org  Tue Mar  4 18:38:03 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 4 Mar 2025 18:38:03 GMT
Subject: RFR: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?" [v2]
In-Reply-To: <vVLsWcN38DZCrNyLLXEsqr8JUJzYsGMZCr16DYAuc3M=.d2e3b893-f152-4d70-af87-d5180b04400a@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
 <vVLsWcN38DZCrNyLLXEsqr8JUJzYsGMZCr16DYAuc3M=.d2e3b893-f152-4d70-af87-d5180b04400a@github.com>
Message-ID: <zoRkv-KHw-hcyh5mrm4MSc6OTOAh7fONxTM4j0XSRYk=.9dd5cf2c-e207-4806-8a1d-792366e2f059@github.com>

On Tue, 4 Mar 2025 18:12:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarified comment

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23867#pullrequestreview-2658600612

From mpowers at openjdk.org  Tue Mar  4 19:28:02 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 4 Mar 2025 19:28:02 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v2]
In-Reply-To: <Ona146wzT7py7EoMfS_4weGixbRkxvw0OsnNeDt2yl8=.179adb54-62f0-4d77-b5ec-865d1924c627@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <Ona146wzT7py7EoMfS_4weGixbRkxvw0OsnNeDt2yl8=.179adb54-62f0-4d77-b5ec-865d1924c627@github.com>
Message-ID: <wMkeLWMfMobrG8a5rF-5j8rbqkXpqmhhiqb5pcBGnyw=.18aaf547-918d-4f2a-93a0-bb5e27f71167@github.com>

On Mon, 3 Mar 2025 19:00:59 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comments, removed debugging printfs

ML-DSA benchmark results for this PR

keygen    ML-DSA-44    96 us/op
keygen    ML-DSA-65   200 us/op
keygen    ML-DSA-87   272 us/op
siggen    ML-DSA-44   297 us/op
siggen    ML-DSA-65   452 us/op
siggen    ML-DSA-87   728 us/op
sigver    ML-DSA-44   115 us/op
sigver    ML-DSA-65   176 us/op
sigver    ML-DSA-87   290 us/op


ML-DSA no intrinsics

keygen    ML-DSA-44   169 us/op
keygen    ML-DSA-65   302 us/op
keygen    ML-DSA-87   444 us/op
siggen    ML-DSA-44   696 us/op
siggen    ML-DSA-65  1114 us/op
siggen    ML-DSA-87  1828 us/op
sigver    ML-DSA-44   187 us/op
sigver    ML-DSA-65   295 us/op
sigver    ML-DSA-87   473 us/op

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

PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2698691038

From weijun at openjdk.org  Tue Mar  4 19:35:01 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 4 Mar 2025 19:35:01 GMT
Subject: Integrated: 8297531: sun/security/krb5/MicroTime.java fails with
 "Exception: What? only 100 musec precision?"
In-Reply-To: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
References: <ZaZjrWbGiU_4KPddy4gCxvDOgzop9gyfnjBGejLbm9E=.3c8d6eb2-d785-421f-9c8b-211353e9bc05@github.com>
Message-ID: <aEPXxjTVFnmnIufKJ65jDdctIz4l1NWdR9KxMXVRJMg=.bcea1b58-713f-4571-b918-4b680329c666@github.com>

On Mon, 3 Mar 2025 16:26:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Loosen the check; the modified test is sufficient to demonstrate sub-millisecond precision.

This pull request has now been integrated.

Changeset: 0753376b
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0753376b0c3d0d98e3db14d26020b23822176557
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8297531: sun/security/krb5/MicroTime.java fails with "Exception: What? only 100 musec precision?"

Reviewed-by: mullan, abarashev

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

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

From vpaprotski at openjdk.org  Tue Mar  4 21:16:14 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 4 Mar 2025 21:16:14 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v2]
In-Reply-To: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
Message-ID: <Bi70hlF4ArfpXkS5gsbqwWhhzQ5uxeBw0JntBsKiI-8=.09f99dcf-0bda-4d63-96cf-bcadef8f64cf@github.com>

> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
> 
> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
> 
> Before (no AVX512)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
> 
> After (with AVX2)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
> 
> 
> Before (with AVX512):
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        102...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  comments from Sandhya

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23719/files
  - new: https://git.openjdk.org/jdk/pull/23719/files/e0803952..1bc0b8c8

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

  Stats: 100 lines in 5 files changed: 61 ins; 7 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/23719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23719/head:pull/23719

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

From vpaprotski at openjdk.org  Tue Mar  4 21:16:15 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 4 Mar 2025 21:16:15 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v2]
In-Reply-To: <7wEGLF0MOmtHAl_cwEOOXNPy_Ckz8j0WmabDR_asitM=.7e772dad-8e67-402f-bdc4-9dad0925f20c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <7wEGLF0MOmtHAl_cwEOOXNPy_Ckz8j0WmabDR_asitM=.7e772dad-8e67-402f-bdc4-9dad0925f20c@github.com>
Message-ID: <Tpp-CtWJltYp9_B8vuq9zwGBGM2AZ7QoXQSyfwdAB1s=.2bf6b4fa-82b2-4e4e-9b95-239896d5d7c4@github.com>

On Thu, 27 Feb 2025 19:05:50 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments from Sandhya
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 397:
> 
>> 395:         __ xorq(acc2, acc2);
>> 396:         __ addq(acc1, tmp_rax);
>> 397:         __ adcq(acc2, tmp_rdx);
> 
> Why adcq here instead of addq? The vector code doesn't do that.

Its a difference in multiply instruction, how the 'high' and 'low' parts are handled.
i.e. Given that inputs a and b are 52 bits:
- mulq a * b = 40:64 bits in high/low
- vpmadd52{l,h}uq = 52:52

vpmadd52 (by design) leaves upper 12 bits for carry propagation, whereas with mulq, we have to do the propagation 'immediately;.

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 424:
> 
>> 422:       __ shrq(acc1, 52); // low 52 of acc1 ignored, is zero, because Montgomery
>> 423: 
>> 424:       // Acc2[0] += carry
> 
> This is more like shift in carry into lower bits of Acc2[0] so comment could be updated.

Hmm. Shift implies (to me?) overriding Acc2, which isn't the case entirely (there is a slight overlap). But.. what is happening here is also not 100% obvious. 

acc2 (i.e. Acc2[0]) is the upper 40+ bits of the multiply result and acc1 is here the 12+ bit carry (leftover); It is not correctly lined up (yet) because how vpmaddq vs mulq produce high/low parts. (its actually overlapping 13 and 41 bits, to get 54 bits, but we have 12 bits to spare in 64bit reg so no need to be exact)

I tried adjusting the 'heading' comment to the function to explain this flow better; hope its better?

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 441:
> 
>> 439:   __ subq(acc2, modulus);
>> 440:   __ vpsubq(Acc2, Acc1, Modulus, Assembler::AVX_256bit);
>> 441:   __ vmovdqu(Address(rsp, -32), Acc2); //Assembler::AVX_256bit
> 
> Need to first create space on stack and then store temp.

Done. Also added stack alignment so I can use aligned spill. Also using just one spill slot instead of two. Re-ran fuzzing tests

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 465:
> 
>> 463: 
>> 464:   // Now carry propagate the multiply result and (constant-time) select correct
>> 465:   // output digit
> 
> Carry propagate multiply result is done before subtracting modulus in the Java code.

That was intentional.. I believe this is faster..

While in vector 'domain', subtract is essentially one vector operation and one scalar operation.. first carry propagation is expensive chain, but second 'hides' within the first propagation.

Conversely, with Java ordering: (1) carry propagate Acc1, (2) scalar subtract Acc2, (3) carry propagate Acc2; the critical path is longer (and subtract isnt vectorized)

PS: "why didn't you do java the same way" :) I chose clarity for the java code; also java jitted code is in 'scalar domain', so there are plenty of partial sums for out-of-order execution to keep the pipeline fed. Its the vector-to-scalar crossover here that requires the special handling

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 467:
> 
>> 465:   // output digit
>> 466:   Register digit = acc1;
>> 467:   __ vmovdqu(Address(rsp, -64), Acc1); //Assembler::AVX_256bit
> 
> Need to first create space on stack and then store.

done

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 475:
> 
>> 473:     }
>> 474:     __ movq(carry, digit);
>> 475:     __ sarq(carry, 52);
> 
> This was unsigned or logical shift in Java code.

For Acc1, the limbs are all positive, around 54-bits. sarq is important for the Acc2 propagation (I added a comment there). I used sarq here mostly for symmetry since it really doesnt matter mathematically

> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp line 556:
> 
>> 554: //  - constant time (i.e. no branches)
>> 555: //  - no-side channel (i.e. all memory must always be accessed, and in same order)
>> 556: void assign_avx(Register aBase, Register bBase, int offset, XMMRegister select, XMMRegister tmp, XMMRegister aTmp, int vector_len, MacroAssembler* _masm) {
> 
> Good to add the comment from assign_scalar here as well:
> // Original java:
>   // long dummyLimbs = maskValue & (a[i] ^ b[i]);
>   // a[i] = dummyLimbs ^ a[i];

done

> src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java line 423:
> 
>> 421:         r[2] = ((c7 & mask) | (c2 & ~mask));
>> 422:         r[3] = ((c8 & mask) | (c3 & ~mask));
>> 423:         r[4] = ((c9 & mask) | (c4 & ~mask));
> 
> It would be good to add a comment here indicating that if the result (c9 - c5) had overflown by one modulus, result - modulus (c4-c0) would be positive else it would be negative.  i.e. Upper bits of c4 would be all zeroes on overflow otherwise upper bits of c4 would be all ones.  Thus on overflow, return value "r" should be set to result - modulus (c4 - c0) else it should be set to result (c9-c5).

done (I think.. please double-check if my version of the comment is helpful)

> test/jdk/com/sun/security/util/math/intpoly/MontgomeryPolynomialFuzzTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Intel Corporation. All rights reserved.
> 
> This should be Copyright (c) 2024, 2025, Intel Corporation. All rights reserved.

done, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1978375998
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1980186231
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1980187534
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1980204172
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1980194853
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1980209434
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1980226208
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1978307783
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1978307045

From vpaprotski at openjdk.org  Tue Mar  4 22:03:14 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 4 Mar 2025 22:03:14 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v3]
In-Reply-To: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
Message-ID: <51kTbZfxDMQ9XAHRt23O8mYkUjCeg3Wbrp9WtYkiYYU=.6eb73f3c-c78d-43e0-a51b-17f64c8ad669@github.com>

> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
> 
> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
> 
> Before (no AVX512)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
> 
> After (with AVX2)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
> 
> 
> Before (with AVX512):
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        102...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  whitespace, correct vpxor, missed comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23719/files
  - new: https://git.openjdk.org/jdk/pull/23719/files/1bc0b8c8..bb450137

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

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

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

From duke at openjdk.org  Tue Mar  4 22:04:26 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 4 Mar 2025 22:04:26 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v4]
In-Reply-To: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
Message-ID: <s1i_jDlsrQSGx-cx7O4uE_qwU8L1uxhANZEqG4oXclM=.bf657af0-9c8e-4b4f-a275-43a7ce118c6a@github.com>

> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Fixed mismerge.
 - Merged master.
 - A little cleanup
 - Merged master
 - removing trailing spaces
 - kyber aarch64 intrinsics

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

Changes: https://git.openjdk.org/jdk/pull/23663/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23663&range=03
  Stats: 2508 lines in 18 files changed: 2464 ins; 16 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/23663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23663/head:pull/23663

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

From jlu at openjdk.org  Wed Mar  5 00:32:00 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Mar 2025 00:32:00 GMT
Subject: RFR: 8351223: Update localized resources in keytool and jarsigner
Message-ID: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>

Please review this PR which provides localization updates for resources in `jarsigner` and `keytool`.
The key/vals in this PR are updated to match the changes made in the English source files.
Further context is provided on the JBS issue.

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

Commit messages:
 - zh_CN l10n
 - ja l10n
 - de l10n

Changes: https://git.openjdk.org/jdk/pull/23911/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23911&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351223
  Stats: 75 lines in 6 files changed: 12 ins; 12 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/23911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23911/head:pull/23911

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

From valeriep at openjdk.org  Wed Mar  5 01:04:54 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Mar 2025 01:04:54 GMT
Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider
 services map [v5]
In-Reply-To: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
References: <fkJRJjb6eiFCZkmopox2b_YJALJMDOxX6zk8iQcud0k=.ef06e29f-3b21-42a9-beb9-7e5dedd06b02@github.com>
 <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
Message-ID: <xLvC8G5khI9LFmtyp6kkipxx63EGrK0jS6_K1pquJq8=.3e7327de-fe6f-4b8b-8ec6-1a0601a1f491@github.com>

On Wed, 12 Feb 2025 20:46:31 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map").
>> 
>> #### New services map design
>> 
>> Here is the high-level hierarchy of the new services map design:
>> 
>> * `servicesMap` (`ServicesMap`)
>>     * Instances (fields)
>>         * `services` (`Map<ServiceKey, Service>`): unifies the previous `serviceMap` and `legacyMap`
>>         * `legacySvcKeys` (`Set<ServiceKey>`): set indicating which keys in `services` correspond to the Legacy API
>>         * `serviceProps` (`Map<ServiceKey, String>`): keeps track of the _provider Hashtable entries_ that originated services entries <sup>(1)</sup>
>>         * `serviceAttrProps` (`Map<ServiceKey, Map<UString, String>>`): keeps track of the _provider Hashtable entries_ that originated service attributes <sup>(1)</sup>
>>         * `serviceSet` (`AtomicReference<Set<Service>>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method
>>     * Writers' methods (for providers registering services through the Current or the Legacy API)
>>         * `boolean putService(Service svc)`
>>         * `boolean removeService(Service svc)`
>>         * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)`
>>         * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)`
>>         * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)`
>>         * `boolean removeLegacy(ServiceKey key, String className)`
>>         * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)`
>>         * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)`
>>     * Readers' methods (for services users and `GetInstance` APIs)
>>         * `Set<Service> getServices()`
>>         * `Service getService(ServiceKey key)`
>>     * Other methods: default and copy constructors, `void clear()`
>> 
>> (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms.
>> 
>> #### Testing
>> 
>> As part of our testing, we observed all the tests pass in the following categories:
>> 
>> * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398))
>> * `jdk/com/sun/crypto`
>> * `jd...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear ServicesMap fields in the declared order
>   
>   Constructors assign the fields in the same order.

src/java.base/share/classes/java/security/Provider.java line 1125:

> 1123:                 if (oldMi.svc != null) {
> 1124:                     // The service exists. Get its Properties map entry. Note:
> 1125:                     // Services added through an alias or an attribute may don't

"may don't"? Maybe you mean "may not" or simply "don't"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1980499152

From abarashev at openjdk.org  Wed Mar  5 01:14:40 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 5 Mar 2025 01:14:40 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v12]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <gpU93oFx4aeQPyKo0h3L6PWcJHNrYz448j0MQLk3M-E=.52c97e2b-66a5-465a-974f-d1286652c667@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
> 
> Also fixing JDK-8350807 on the server side just as a side-effect, not a dedicated fix for that issue.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update documentation and unit tests to signal TLS scope case-insensitivity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/bc8d933e..efb11851

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

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

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

From valeriep at openjdk.org  Wed Mar  5 01:44:14 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Mar 2025 01:44:14 GMT
Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider
 services map [v5]
In-Reply-To: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
References: <fkJRJjb6eiFCZkmopox2b_YJALJMDOxX6zk8iQcud0k=.ef06e29f-3b21-42a9-beb9-7e5dedd06b02@github.com>
 <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
Message-ID: <zKYsR2LKPUHs0yX4yNcSMoTNOO1UaphOyHrzuDl36G0=.e6dbf4be-c4af-48d8-bfd9-3dfafe36adc1@github.com>

On Wed, 12 Feb 2025 20:46:31 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map").
>> 
>> #### New services map design
>> 
>> Here is the high-level hierarchy of the new services map design:
>> 
>> * `servicesMap` (`ServicesMap`)
>>     * Instances (fields)
>>         * `services` (`Map<ServiceKey, Service>`): unifies the previous `serviceMap` and `legacyMap`
>>         * `legacySvcKeys` (`Set<ServiceKey>`): set indicating which keys in `services` correspond to the Legacy API
>>         * `serviceProps` (`Map<ServiceKey, String>`): keeps track of the _provider Hashtable entries_ that originated services entries <sup>(1)</sup>
>>         * `serviceAttrProps` (`Map<ServiceKey, Map<UString, String>>`): keeps track of the _provider Hashtable entries_ that originated service attributes <sup>(1)</sup>
>>         * `serviceSet` (`AtomicReference<Set<Service>>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method
>>     * Writers' methods (for providers registering services through the Current or the Legacy API)
>>         * `boolean putService(Service svc)`
>>         * `boolean removeService(Service svc)`
>>         * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)`
>>         * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)`
>>         * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)`
>>         * `boolean removeLegacy(ServiceKey key, String className)`
>>         * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)`
>>         * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)`
>>     * Readers' methods (for services users and `GetInstance` APIs)
>>         * `Set<Service> getServices()`
>>         * `Service getService(ServiceKey key)`
>>     * Other methods: default and copy constructors, `void clear()`
>> 
>> (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms.
>> 
>> #### Testing
>> 
>> As part of our testing, we observed all the tests pass in the following categories:
>> 
>> * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398))
>> * `jdk/com/sun/crypto`
>> * `jd...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear ServicesMap fields in the declared order
>   
>   Constructors assign the fields in the same order.

src/java.base/share/classes/java/security/Provider.java line 1370:

> 1368:          * Algorithm and alias based entries pointing to the old version of the
> 1369:          * service are overwritten.
> 1370:          */

Comment for this method should note that this method is only for the Legacy registration...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1980528410

From valeriep at openjdk.org  Wed Mar  5 07:08:54 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 5 Mar 2025 07:08:54 GMT
Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider
 services map [v5]
In-Reply-To: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
References: <fkJRJjb6eiFCZkmopox2b_YJALJMDOxX6zk8iQcud0k=.ef06e29f-3b21-42a9-beb9-7e5dedd06b02@github.com>
 <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
Message-ID: <YvbOcQ6ACml_CmgRBCUdDQp-PHlc2jKv2R3y3Kz1KIg=.f281e9f9-8190-4f27-966f-c71b8e3d6055@github.com>

On Wed, 12 Feb 2025 20:46:31 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map").
>> 
>> #### New services map design
>> 
>> Here is the high-level hierarchy of the new services map design:
>> 
>> * `servicesMap` (`ServicesMap`)
>>     * Instances (fields)
>>         * `services` (`Map<ServiceKey, Service>`): unifies the previous `serviceMap` and `legacyMap`
>>         * `legacySvcKeys` (`Set<ServiceKey>`): set indicating which keys in `services` correspond to the Legacy API
>>         * `serviceProps` (`Map<ServiceKey, String>`): keeps track of the _provider Hashtable entries_ that originated services entries <sup>(1)</sup>
>>         * `serviceAttrProps` (`Map<ServiceKey, Map<UString, String>>`): keeps track of the _provider Hashtable entries_ that originated service attributes <sup>(1)</sup>
>>         * `serviceSet` (`AtomicReference<Set<Service>>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method
>>     * Writers' methods (for providers registering services through the Current or the Legacy API)
>>         * `boolean putService(Service svc)`
>>         * `boolean removeService(Service svc)`
>>         * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)`
>>         * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)`
>>         * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)`
>>         * `boolean removeLegacy(ServiceKey key, String className)`
>>         * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)`
>>         * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)`
>>     * Readers' methods (for services users and `GetInstance` APIs)
>>         * `Set<Service> getServices()`
>>         * `Service getService(ServiceKey key)`
>>     * Other methods: default and copy constructors, `void clear()`
>> 
>> (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms.
>> 
>> #### Testing
>> 
>> As part of our testing, we observed all the tests pass in the following categories:
>> 
>> * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398))
>> * `jdk/com/sun/crypto`
>> * `jd...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear ServicesMap fields in the declared order
>   
>   Constructors assign the fields in the same order.

src/java.base/share/classes/java/security/Provider.java line 1374:

> 1372:                 ServiceUpdateCallback updateCb) {
> 1373:             Service newSvc;
> 1374:             MappingInfo oldMi = find(key);

`oldMi` could just simply be `mi`? There is no `newMi` in the same method anywhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1980818623

From duke at openjdk.org  Wed Mar  5 11:33:06 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 5 Mar 2025 11:33:06 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v3]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <xYDRgjvW5AksXcXKUBnx7LlB4PmGEjEITKA27iHs4rE=.e69744e8-2fe9-4b0c-a49d-25177a2e8daf@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merged master.
 - Added comments, removed debugging printfs
 - JDK-8351034 Add AVX-512 intrinsics for ML-DSA

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

Changes: https://git.openjdk.org/jdk/pull/23860/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=02
  Stats: 1642 lines in 8 files changed: 1636 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860

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

From jbhateja at openjdk.org  Wed Mar  5 11:38:52 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 5 Mar 2025 11:38:52 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v2]
In-Reply-To: <Ona146wzT7py7EoMfS_4weGixbRkxvw0OsnNeDt2yl8=.179adb54-62f0-4d77-b5ec-865d1924c627@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <Ona146wzT7py7EoMfS_4weGixbRkxvw0OsnNeDt2yl8=.179adb54-62f0-4d77-b5ec-865d1924c627@github.com>
Message-ID: <y6k-dj9j91M8yH4OQiQtvKjnOht1EfdYxr6X5rzDd1s=.074ab025-f97a-4281-993a-448d822a7196@github.com>

On Mon, 3 Mar 2025 19:00:59 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comments, removed debugging printfs

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 420:

> 418:   __ movptr(constant2use, round_consts);
> 419: 
> 420:   __ BIND(rounds24_loop);

For Icache alignment, please use __ align64() before the loop entry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1978822704

From jbhateja at openjdk.org  Wed Mar  5 11:42:01 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 5 Mar 2025 11:42:01 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v3]
In-Reply-To: <xYDRgjvW5AksXcXKUBnx7LlB4PmGEjEITKA27iHs4rE=.e69744e8-2fe9-4b0c-a49d-25177a2e8daf@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xYDRgjvW5AksXcXKUBnx7LlB4PmGEjEITKA27iHs4rE=.e69744e8-2fe9-4b0c-a49d-25177a2e8daf@github.com>
Message-ID: <0E2AqFpNPjDjP6jqCXn8toePBcW2SIHw1kFXlZX4W_U=.8d692bfa-0598-4969-b480-4a285366e0bb@github.com>

On Wed, 5 Mar 2025 11:33:06 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merged master.
>  - Added comments, removed debugging printfs
>  - JDK-8351034 Add AVX-512 intrinsics for ML-DSA

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 292:

> 290:   __ movl(iterations, 2);
> 291: 
> 292:   __ BIND(L_loop);

Please align loop entry address using __align64().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1981242267

From duke at openjdk.org  Wed Mar  5 13:10:34 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 5 Mar 2025 13:10:34 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v4]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <nmN_TxNaqRqSAVqYzrUhO9NXpzzixG6d1OsvBArpLsA=.857b5aa3-694a-4528-a922-c3fdab141ffa@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Added alignment to loop entries.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/331f1ecb..3aaa106f

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

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

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

From duke at openjdk.org  Wed Mar  5 13:10:35 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 5 Mar 2025 13:10:35 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v3]
In-Reply-To: <0E2AqFpNPjDjP6jqCXn8toePBcW2SIHw1kFXlZX4W_U=.8d692bfa-0598-4969-b480-4a285366e0bb@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xYDRgjvW5AksXcXKUBnx7LlB4PmGEjEITKA27iHs4rE=.e69744e8-2fe9-4b0c-a49d-25177a2e8daf@github.com>
 <0E2AqFpNPjDjP6jqCXn8toePBcW2SIHw1kFXlZX4W_U=.8d692bfa-0598-4969-b480-4a285366e0bb@github.com>
Message-ID: <V62AuLpV4oPamF6hi7zMdqs21tyw9i4ug_9UlNCQpNE=.2d6e0fcf-3e2c-406f-a336-bb2dedd923e8@github.com>

On Wed, 5 Mar 2025 11:39:05 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merged master.
>>  - Added comments, removed debugging printfs
>>  - JDK-8351034 Add AVX-512 intrinsics for ML-DSA
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 292:
> 
>> 290:   __ movl(iterations, 2);
>> 291: 
>> 292:   __ BIND(L_loop);
> 
> Hi @ferakocz , Kindly align loop entry address using __align64() here and at all the places before __BIND(LOOP)

Hi, @jatin-bhateja, thanks for the suggestion. I have added __ align(OptoLoopAlignment); before all loop entries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1981364481

From mdonovan at openjdk.org  Wed Mar  5 13:35:53 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 5 Mar 2025 13:35:53 GMT
Subject: RFR: 8351223: Update localized resources in keytool and jarsigner
In-Reply-To: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
References: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
Message-ID: <sccrYhMnmbd99iCTUm2w7SwPrj5cN_CKX0d8K6n_qjU=.5ae08c7c-249d-41f9-ba0a-b43c88f17d0c@github.com>

On Wed, 5 Mar 2025 00:23:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides localization updates for resources in `jarsigner` and `keytool`.
> The key/vals in this PR are updated to match the changes made in the English source files.
> Further context is provided on the JBS issue.

looks good to me, thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23911#issuecomment-2700945530

From jbhateja at openjdk.org  Wed Mar  5 14:05:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 5 Mar 2025 14:05:53 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v3]
In-Reply-To: <V62AuLpV4oPamF6hi7zMdqs21tyw9i4ug_9UlNCQpNE=.2d6e0fcf-3e2c-406f-a336-bb2dedd923e8@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xYDRgjvW5AksXcXKUBnx7LlB4PmGEjEITKA27iHs4rE=.e69744e8-2fe9-4b0c-a49d-25177a2e8daf@github.com>
 <0E2AqFpNPjDjP6jqCXn8toePBcW2SIHw1kFXlZX4W_U=.8d692bfa-0598-4969-b480-4a285366e0bb@github.com>
 <V62AuLpV4oPamF6hi7zMdqs21tyw9i4ug_9UlNCQpNE=.2d6e0fcf-3e2c-406f-a336-bb2dedd923e8@github.com>
Message-ID: <M5Z8mk-KZoytxUmhzRWKqUFtHRWoxY28Bfv8h_ijjMg=.351389d9-57d1-4589-a853-41125858760a@github.com>

On Wed, 5 Mar 2025 13:07:54 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 292:
>> 
>>> 290:   __ movl(iterations, 2);
>>> 291: 
>>> 292:   __ BIND(L_loop);
>> 
>> Hi @ferakocz , Kindly align loop entry address using __align64() here and at all the places before __BIND(LOOP)
>
> Hi, @jatin-bhateja, thanks for the suggestion. I have added __ align(OptoLoopAlignment); before all loop entries.

Hi @ferakocz , 

Thanks!, for efficient utilization of Decode ICache (please refer to Intel SDM section 3.4.2.5), code blocks should be aligned to 32-byte boundaries; a 64-byte aligned code is a superset of both 16 and 32 byte aligned addresses and also matches with the cacheline size. However, I can noticed that we have been using OptoLoopAlignment at places in AES-GCM also.

I introduced some errors in generate_dilithiumAlmostInverseNtt_avx512 implementation in anticipation of catching it through existing ML_DSA_Tests under 
test/jdk/sun/security/provider/acvp

But all the tests passed for me.
`java  -jar /home/jatinbha/sandboxes/jtreg/build/images/jtreg/lib/jtreg.jar -jdk:$JAVA_HOME -Djdk.test.lib.artifacts.ACVP-Server=/home/jatinbha/softwares/v1.1.0.38.zip -va -timeout:4 Launcher.java`

Can you please point out a test I need to use for validation

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1981468903

From mdonovan at openjdk.org  Wed Mar  5 14:47:59 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 5 Mar 2025 14:47:59 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore
In-Reply-To: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
Message-ID: <Wzlp3Xez58leZhyJDIFzT7QX7f_iBb6QHgyBuRoIrRA=.6adf4938-e370-44db-a4bd-f65a80b7021d@github.com>

On Tue, 4 Mar 2025 13:07:37 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

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

test/jdk/sun/security/ssl/SSLSocketImpl/NonAutoClose.java line 58:

> 56:      */
> 57:     private final static String pathToStores = "../../../../javax/net/ssl/etc";
> 58:     private final static String keyStoreFile = "keystore";

This isn't in the changeset, but we're trying to move away from the binary {key|trust}store files. We have two template classes, SSLContextTemplate and SSLSocketTemplate, that set up key and trust stores and does the context setup. Can you take a look and see if one of them can be used here?

test/jdk/sun/security/ssl/SSLSocketImpl/NonAutoClose.java line 70:

> 68:      * Turn on SSL debugging?
> 69:      */
> 70:     private final static boolean DEBUG = false;

I know this isn't technically in the change set but when I see this I change it to `DEBUG = Boolean.getBoolean("test.debug")` so the flag can be toggled without rebuilding the code.

test/jdk/sun/security/ssl/SSLSocketImpl/NonAutoClose.java line 77:

> 75:     private final static int TLS_CLIENT_VAL = 4;
> 76: 
> 77:     private void expectValue(int got, int expected, String msg) throws IOException {

Can you just use the Asserts class instead?

test/jdk/sun/security/ssl/SSLSocketImpl/SetClientMode.java line 66:

> 64:      * Where do we find the keystores?
> 65:      */
> 66:     private final static String pathToStores = "../../../../javax/net/ssl/etc";

Could you use either SSLContextTemplate or SSLSocketTemplate for this test?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r1981466359
PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r1981448111
PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r1981443329
PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r1981542780

From weijun at openjdk.org  Wed Mar  5 14:52:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 5 Mar 2025 14:52:57 GMT
Subject: RFR: 8351223: Update localized resources in keytool and jarsigner
In-Reply-To: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
References: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
Message-ID: <GwSSF1FHvbkh6dbbyO_pOgNMi4NaOe2SriDi68IsDgA=.20ef14c0-7023-4d13-9abc-53eb0ecf14a1@github.com>

On Wed, 5 Mar 2025 00:23:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides localization updates for resources in `jarsigner` and `keytool`.
> The key/vals in this PR are updated to match the changes made in the English source files.
> Further context is provided on the JBS issue.

src/java.base/share/classes/sun/security/tools/keytool/Resources_de.java line 310:

> 308:                 "%1$d-Bit %2$s"},
> 309:         {"Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for",
> 310:                 "Schl\u00FCsselpaar {0} und selbstsigniertes Zertifikat ({1}) werden mit einer G\u00FCltigkeit von {2} Tagen generiert\n\tf\u00FCr: {3}"},

Putting `{0}` (which is size and type) after "Schl?sselpaar" sounds strange. I understand you don't want to put `{0}` in parentheses because the value itself might contain parentheses (For example, `384-Bit EC (secp384r1)`). Maybe we can add a "mit" in between?

Also, Why change from active voice in the present continuous tense to passive voice in the simple present tense?

src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 312:

> 310:                 "\u6B63\u5728\u4E3A {3} \u751F\u6210\u6709\u6548\u671F\u4E3A {2} \u5929\u7684 {0} \u5BC6\u94A5\u5BF9\u548C\u81EA\u7B7E\u540D\u8BC1\u4E66 ({1})\n"},
> 311:         {"Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for",
> 312:                 "\u751F\u6210 {0} \u5BC6\u94A5\u5BF9\u548C <{2}> \u9881\u53D1\u7684\u8BC1\u4E66 ({1})\uFF0C\u6709\u6548\u671F\u4E3A {3} \u5929 \n\t \u5BF9\u4E8E\uFF1A{4}"},

Why not make the two strings consistent?

I think the 1st one "??? {3} ?????? {2} ?? {0} ????????? ({1})\n" is very good, and suggest the 2nd one to be "??? {4} ?????? {3} ?? {0} ????? <{3}> ????? ({2})\n".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23911#discussion_r1981516207
PR Review Comment: https://git.openjdk.org/jdk/pull/23911#discussion_r1981546844

From ivan.ristic at gmail.com  Wed Mar  5 17:46:02 2025
From: ivan.ristic at gmail.com (Ivan Ristic)
Date: Wed, 5 Mar 2025 17:46:02 +0000
Subject: =?UTF-8?Q?Re=3A_=5BExternal=5D_=3A_Re=3A_Certificate_Transparency=E2=80=94basi?=
 =?UTF-8?Q?c_support_for_the_TLS_extension=3F?=
In-Reply-To: <2d2fbdcd-355c-4cc8-8152-ae9c0c8c2cbf@oracle.com>
References: <CANHgQ8Gkrj2BdstCQ5h6vNNL+pF-U5_9ALb84NE6zXseXt6iqw@mail.gmail.com>
 <ffc5789c-3b27-4db9-bcf8-38317d87755d@oracle.com>
 <CANHgQ8E4+aTL_bx-VG15gZMh0SbVnPuVsvwafdZNVUz4EL0KHQ@mail.gmail.com>
 <2d2fbdcd-355c-4cc8-8152-ae9c0c8c2cbf@oracle.com>
Message-ID: <CANHgQ8GFOOoAqubi8Sw2UW7JuVR96cft3W3xebLb3uP0OCUO5w@mail.gmail.com>

Yes, the source is important as different policy rules can apply, depending
on the source.

I think that, if aiming for a complete SCT support, it would be absolutely
prudent to include a reference to the relevant certificate from the
handshake.

That said, I don't think anyone is including SCTs in CA certificates at
present. In fact, I have a collection of roots and intermediates extracted
from CT and, checking just now, I didn't find any SCTs. If you'd like to do
a sanity check at some point, a good collection of intermediates can be
downloaded from https://www.ccadb.org/resources

AFAIK, CT policies all apply only to end-entity certificates.
Interemediates are "logged" implicitly as they're supplied by CAs in the
chain with the leaves.

I am not sure of anyone is using OCSP for delivery of SCTs, but, IIRC,
Cloudflare uses the TLS extension. Google might, too.


On Tue, Mar 4, 2025 at 4:53?PM Jamil Nimeh <jamil.j.nimeh at oracle.com> wrote:

> Hi Ivan,
>
> Thanks for the feedback.  Yes, it was my intent to include extensions that
> come in from all potential sources, be it via the hello extension, embedded
> in certs, or via OCSP responses.  The source did seem important.  And I did
> want to be sensitive to 1.0 and 2.0 formats since both are in RFC form, not
> drafts.  Or at least design things with forward compatibility in mind.
>
> I had one other question in going through both RFCs (6962 and 9162).  Both
> of those specifications seem to focus on the end-entity TLS certificate.
> In looking at the CAB baseline requirements, it appears that signed
> certificate timestamp lists can exist in subordinate CA certificates too.
> I just don't know how common that is, since it is a "MAY" in the baseline
> requirements.  So I'm wondering if it will be helpful in presenting to the
> Java consumer the list of SCTs also grouped by certificate in some
> fashion.  Do you think that would be helpful?  It could be simply ordered
> in the same ordering as the chain is presented, or it could be ordered by
> X509Certificate or maybe a certificate hash.  Not sure.  I would love to
> hear your thoughts on that.
>
> I wasn't thinking along the lines of including the raw extension bytes.
> That certainly would be one way to expose 1.0 vs. 2.0, but there may be
> other ways to present the data to the user that lessens the work on the
> user's side in terms of parsing the data.  I'm still chewing on that one
> because presenting the SCTs as objects rather than opaque byte arrays means
> a larger API change.  But I'm also looking at how much we can pave the way
> with this RFE towards a full implementation in the future.  The CSR would
> be explicit about all of these public, API changes and while in draft form
> there can be discussion and changes/improvements to any proposed API.
>
> Thanks,
>
> --Jamil
> On 3/4/2025 7:39 AM, Ivan Ristic wrote:
>
> Hi Jamil,
>
> Thanks for opening that ticket. I notice that the wording is generic to
> SCTs, which might indicate that you want to include the ones embedded in
> certificates and OCSP responses. Did you meant that? If so, they will
> absolutely need a wrapper to indicate the source. In that case, you must
> just as well include a version number so that the wrapper is generic and
> future-compatible.
>
> It probably makes sense to include all SCTs because?I am guessing?it will
> not be possible for non-JDK code to observe OCSP responses that are not
> stapled by obtained as part of TLS auth? In this case the source would not
> be a stapled OCSP response, but one fetched directly from the responder.
>
> If we're talking only about the TLS extension, if you include the raw
> extension bytes they will contain the extension ID, which may be sufficient
> if CT 2.0 is ever implemented. (CT 2.0 uses the transparency_info
> extension.)
>
>
> On Sat, Mar 1, 2025 at 5:43?PM Jamil Nimeh <jamil.j.nimeh at oracle.com>
> wrote:
>
>> Hello Ivan,
>>
>> You bring up an interesting idea, and it comes at a good time because
>> we've been going back and taking another look at CT and SunJSSE.  What you
>> are suggesting would be a useful addition, and could also be a step towards
>> a full implementation.  I have created
>> https://bugs.openjdk.org/browse/JDK-8351001 to track this.  It will need
>> a CSR if we decide to go the ExtendedSSLSession route as you were
>> suggesting.
>>
>> A question, since we're on the topic: Is there any value to separating
>> out somehow 1.0 and 2.0 SCTs?  Or would a simple List<byte[]> that just
>> contains each SCT be sufficient?
>>
>> Thanks,
>>
>> --Jamil
>> On 2/28/2025 12:35 AM, Ivan Ristic wrote:
>>
>> Hello group,
>>
>> From what I can tell, it's currently not possible to consume CT
>> information from Java reliably because there is no way to indicate support
>> for the CT TLS extension [1] in the handshake as well as get the data sent
>> back by a compatible server.
>>
>> The work involved would be small, for example just grab the raw data and
>> expose it via ExtendedSSLSession, in the same way stapled OCSP responses
>> are currently handled.
>>
>> However, the improvements would be significant, as this change would
>> enable Java applications to use CT if they so wish.
>>
>> Apologies as I am not familiar with how things are done; what's the
>> process to make this happen?
>>
>> [1] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc6962*section-3.3__;Iw!!ACWV5N9M2RV99hQ!KIjWS6IHmhoDGv9tfyCSWMgzO-npdeXAxxTQG_s33nlcSE-1pfSaJwn8VVfEWUCHr3yHRBCy0GRmUkTxqSBjvmSW$>
>>
>> --
>> Ivan
>>
>>
>
> --
> Ivan
>
>

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

From jlu at openjdk.org  Wed Mar  5 18:14:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Mar 2025 18:14:59 GMT
Subject: RFR: 8351223: Update localized resources in keytool and jarsigner
In-Reply-To: <GwSSF1FHvbkh6dbbyO_pOgNMi4NaOe2SriDi68IsDgA=.20ef14c0-7023-4d13-9abc-53eb0ecf14a1@github.com>
References: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
 <GwSSF1FHvbkh6dbbyO_pOgNMi4NaOe2SriDi68IsDgA=.20ef14c0-7023-4d13-9abc-53eb0ecf14a1@github.com>
Message-ID: <bAxyW7h2DWg4oY1Mzi8l_7rehhBqVwfFVm5wiPOsCLo=.8961339b-0199-4993-8b94-b50da6e0421a@github.com>

On Wed, 5 Mar 2025 14:45:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this PR which provides localization updates for resources in `jarsigner` and `keytool`.
>> The key/vals in this PR are updated to match the changes made in the English source files.
>> Further context is provided on the JBS issue.
>
> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 312:
> 
>> 310:                 "\u6B63\u5728\u4E3A {3} \u751F\u6210\u6709\u6548\u671F\u4E3A {2} \u5929\u7684 {0} \u5BC6\u94A5\u5BF9\u548C\u81EA\u7B7E\u540D\u8BC1\u4E66 ({1})\n"},
>> 311:         {"Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for",
>> 312:                 "\u751F\u6210 {0} \u5BC6\u94A5\u5BF9\u548C <{2}> \u9881\u53D1\u7684\u8BC1\u4E66 ({1})\uFF0C\u6709\u6548\u671F\u4E3A {3} \u5929 \n\t \u5BF9\u4E8E\uFF1A{4}"},
> 
> Why not make the two strings consistent?
> 
> I think the 1st one "??? {3} ?????? {2} ?? {0} ????????? ({1})\n" is very good, and suggest the 2nd one to be "??? {4} ?????? {3} ?? {0} ????? <{3}> ????? ({2})\n".

As we discussed, we'll address any translation quality improvements in the JDK25 L10N drop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23911#discussion_r1981924963

From duke at openjdk.org  Wed Mar  5 18:30:03 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 5 Mar 2025 18:30:03 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v3]
In-Reply-To: <M5Z8mk-KZoytxUmhzRWKqUFtHRWoxY28Bfv8h_ijjMg=.351389d9-57d1-4589-a853-41125858760a@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xYDRgjvW5AksXcXKUBnx7LlB4PmGEjEITKA27iHs4rE=.e69744e8-2fe9-4b0c-a49d-25177a2e8daf@github.com>
 <0E2AqFpNPjDjP6jqCXn8toePBcW2SIHw1kFXlZX4W_U=.8d692bfa-0598-4969-b480-4a285366e0bb@github.com>
 <V62AuLpV4oPamF6hi7zMdqs21tyw9i4ug_9UlNCQpNE=.2d6e0fcf-3e2c-406f-a336-bb2dedd923e8@github.com>
 <M5Z8mk-KZoytxUmhzRWKqUFtHRWoxY28Bfv8h_ijjMg=.351389d9-57d1-4589-a853-41125858760a@github.com>
Message-ID: <wBKHcU8T9cMhYxLItWJ62IocCpPm9t8C4H_Ky4my9Fo=.fac18f07-5383-4333-b68e-031d376be1e2@github.com>

On Wed, 5 Mar 2025 14:03:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi, @jatin-bhateja, thanks for the suggestion. I have added __ align(OptoLoopAlignment); before all loop entries.
>
> Hi @ferakocz , 
> 
> Thanks!, for efficient utilization of Decode ICache (please refer to Intel SDM section 3.4.2.5), code blocks should be aligned to 32-byte boundaries; a 64-byte aligned code is a superset of both 16 and 32 byte aligned addresses and also matches with the cacheline size. However, I can noticed that we have been using OptoLoopAlignment at places in AES-GCM also.
> 
> I introduced some errors in generate_dilithiumAlmostInverseNtt_avx512 implementation in anticipation of catching it through existing ML_DSA_Tests under 
> test/jdk/sun/security/provider/acvp
> 
> But all the tests passed for me.
> `java  -jar /home/jatinbha/sandboxes/jtreg/build/images/jtreg/lib/jtreg.jar -jdk:$JAVA_HOME -Djdk.test.lib.artifacts.ACVP-Server=/home/jatinbha/softwares/v1.1.0.38.zip -va -timeout:4 Launcher.java`
> 
> Can you please point out a test I need to use for validation

I think the easiest is to put a for (int i = 0; i < 1000; i++) loop around  the switch statement in the run() method of  the ML_DSA_Test class (test/jdk/sun/security/provider/acvp/ML_DSA_Test.java). (This is because the intrinsics kick in after a few thousand calls of the method.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1981945490

From mdonovan at openjdk.org  Wed Mar  5 19:23:05 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 5 Mar 2025 19:23:05 GMT
Subject: RFR: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version [v5]
In-Reply-To: <MjxmH6TzVXuC_4-ugNXnv1KviSWZtc9BTuY-66Bhw4Q=.d228fcc7-9b71-43ae-b315-88f42a6e2d4b@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
 <MjxmH6TzVXuC_4-ugNXnv1KviSWZtc9BTuY-66Bhw4Q=.d228fcc7-9b71-43ae-b315-88f42a6e2d4b@github.com>
Message-ID: <oj6h6x0huq9iEfvfbQbmJD1NSEQ26bIBrlSOnx9Cc9Q=.11b5c13e-45cb-41e8-b77c-1a6ca58cdc89@github.com>

On Wed, 19 Feb 2025 17:03:02 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). 
>> There are some differences between the 1.1.x and the current OpenSSL version:
>> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it.  Additionally, It is also required to specify the path location of the legacy provider.
>> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated wording of openssl version

test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java line 79:

> 77:             }
> 78:         }
> 79:         return verifyOpensslVersion(path, OPENSSL_BUNDLE_VERSION) ? path : null;

Do we want to keep this version check? On the one hand, it ensures that the system binaries or binaries specified via the system property will be a specific, known version, but on the other hand, the only way to run this test with a different version of the library is to change the code. Instead, can we just log the version that is used when the test is run?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1982056864

From weijun at openjdk.org  Wed Mar  5 19:36:07 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 5 Mar 2025 19:36:07 GMT
Subject: RFR: 8351223: Update localized resources in keytool and jarsigner
In-Reply-To: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
References: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
Message-ID: <-b-CBbvf0JwBhSUf7LEYgQSBSzD617JAuiTT5AG6S5Y=.0f37234d-2926-437e-8ede-6a9ddcd8c197@github.com>

On Wed, 5 Mar 2025 00:23:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides localization updates for resources in `jarsigner` and `keytool`.
> The key/vals in this PR are updated to match the changes made in the English source files.
> Further context is provided on the JBS issue.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23911#pullrequestreview-2662296449

From mdonovan at openjdk.org  Wed Mar  5 19:47:53 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 5 Mar 2025 19:47:53 GMT
Subject: RFR: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version [v5]
In-Reply-To: <MjxmH6TzVXuC_4-ugNXnv1KviSWZtc9BTuY-66Bhw4Q=.d228fcc7-9b71-43ae-b315-88f42a6e2d4b@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
 <MjxmH6TzVXuC_4-ugNXnv1KviSWZtc9BTuY-66Bhw4Q=.d228fcc7-9b71-43ae-b315-88f42a6e2d4b@github.com>
Message-ID: <2HGfihxD_eEeB_YZO6o3r47uF6WbW4Axk6RS0W4SUlE=.72e1bce0-53c1-40c6-b83a-c135025ac967@github.com>

On Wed, 19 Feb 2025 17:03:02 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). 
>> There are some differences between the 1.1.x and the current OpenSSL version:
>> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it.  Additionally, It is also required to specify the path location of the legacy provider.
>> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated wording of openssl version

test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 78:

> 76:             testWithOpensslCommands(opensslPath);
> 77:         } else {
> 78:             // since the current version of openssl is not available, skip all

If this test is to check interoperability with OpenSSL, shouldn't we throw a skippedexception or an error instead of just running with java?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1982088842

From ascarpino at openjdk.org  Wed Mar  5 20:20:10 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 5 Mar 2025 20:20:10 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v4]
In-Reply-To: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
Message-ID: <c5KF8wFufjEbuAeFj2Mpc7M60j8jTyns-XP5iY8K194=.283efa1e-f662-4592-b1ba-0ea25a6c0bfb@github.com>

> Hi,
> 
> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
> 
> thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  rename getNamedCurveFromKey

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23647/files
  - new: https://git.openjdk.org/jdk/pull/23647/files/3cbee6a2..b26118a5

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

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

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

From fguallini at openjdk.org  Wed Mar  5 21:24:56 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 5 Mar 2025 21:24:56 GMT
Subject: RFR: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version [v5]
In-Reply-To: <2HGfihxD_eEeB_YZO6o3r47uF6WbW4Axk6RS0W4SUlE=.72e1bce0-53c1-40c6-b83a-c135025ac967@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
 <MjxmH6TzVXuC_4-ugNXnv1KviSWZtc9BTuY-66Bhw4Q=.d228fcc7-9b71-43ae-b315-88f42a6e2d4b@github.com>
 <2HGfihxD_eEeB_YZO6o3r47uF6WbW4Axk6RS0W4SUlE=.72e1bce0-53c1-40c6-b83a-c135025ac967@github.com>
Message-ID: <XsTfWEma-tBtCIgcHHCNCWe2pqROGqTpXbo19KWF7Os=.2c4edc6a-ae9e-4a42-8a00-262745006f03@github.com>

On Wed, 5 Mar 2025 19:45:14 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated wording of openssl version
>
> test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 78:
> 
>> 76:             testWithOpensslCommands(opensslPath);
>> 77:         } else {
>> 78:             // since the current version of openssl is not available, skip all
> 
> If this test is to check interoperability with OpenSSL, shouldn't we throw a skippedexception or an error instead of just running with java?

Well, the test is also checking with java commands if openssl is available (line 75), then it makes sense to keep it when it is not available as it does not rely on Openssl.

> test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java line 79:
> 
>> 77:             }
>> 78:         }
>> 79:         return verifyOpensslVersion(path, OPENSSL_BUNDLE_VERSION) ? path : null;
> 
> Do we want to keep this version check? On the one hand, it ensures that the system binaries or binaries specified via the system property will be a specific, known version, but on the other hand, the only way to run this test with a different version of the library is to change the code. Instead, can we just log the version that is used when the test is run?

I considered removing this check as it seems redundant, but then I realised it was introduced to ensure the bundle version matches the version specified by the artifact name. It's possible that the artifact's filename could show a different version than the actual binaries with `-version`. On the other hand, most tests don't run this extra verification, that could be a good reason to remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1982115420
PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1982136351

From mullan at openjdk.org  Wed Mar  5 21:33:03 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 5 Mar 2025 21:33:03 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v11]
In-Reply-To: <K1pUE6rox1v36O2C8OH09hpOd3vzT5HuEczYK3c60O4=.ce36a8bb-1bc7-4564-8943-37f5edc982ea@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <K1pUE6rox1v36O2C8OH09hpOd3vzT5HuEczYK3c60O4=.ce36a8bb-1bc7-4564-8943-37f5edc982ea@github.com>
Message-ID: <Tkfoo2nRyAwnRFSi1EPZ-3TfoWFeWfahoz3mR_kkXB4=.c03bbb8e-5f56-4a94-9121-55fbe2224b2f@github.com>

On Sat, 1 Mar 2025 00:00:21 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc.
>> 
>> ![image](https://github.com/user-attachments/assets/0c9a79f3-4cb2-414c-af1d-eac2590740ea)
>> 
>> 
>> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8328914: Document the java.security.debug property in javadoc

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 1:

> 1: <!doctype html>

General comment - try to keep the length of lines to about 80 characters.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 58:

> 56:     which determines what trace messages are printed during execution. The value of the property is one or more options separated by a comma.
> 57:     Some options also have additional sub-options. Sub-options are specified by appending a ":" to the option, followed by a list of one more sub-options separated by a comma.
> 58:     For example, to specify the <code>ocsp</code> and <code>verbose</code> options with the <code>certpath</code> option: set the property to "<code>certpath:ocsp,verbose</code>".

I think a ',' instead of a ':' after 'option' would read better.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 63:

> 61: <H3>Printing Thread and Timestamp Information</H3>
> 62: <p>
> 63:     You can append the following strings to the value specified in the <code>java.security.debug</code>

s/the value/any option/

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 66:

> 64:     system property to print additional information:
> 65: <ul>
> 66:     <li><code>+thread</code>:Print thread and caller information</li>

Add space after ':'.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 67:

> 65: <ul>
> 66:     <li><code>+thread</code>:Print thread and caller information</li>
> 67:     <li><code>+timestamp</code>:Print timestamp information</li>

Add space after ':'.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 70:

> 68: </ul>
> 69: <p>
> 70:     For example, to add thread, caller, and timestamp information to all debuging output,

s/debuging/debugging/

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 74:

> 72:     <pre><code>java -Djava.security.debug=all+thread+timestamp MyApp</code></pre>
> 73: 
> 74: <p>The following table lists <code>java.security.debug</code> options table:</p>

s/lists/lists the/

Remove "table" at the end, you already have that word at the beginning.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 91:

> 89:     <tr>
> 90:         <th scope="row"><code>certpath</code></th>
> 91:         <td>Turns on debugging for the PKIX <code>CertPathValidator</code> and <code>CertPathBuilder</code> implementations. Use the <code>ocsp</code> sub-option with the <code>certpath</code> option for OCSP protocol tracing. A hexadecimal dump of the OCSP request and response bytes is displayed.

Remove the last 2 sentences ("Use the ..." and "A hexadecimal ..."). Add similar text to the sub-option section where it makes more sense. Reword the section as "Dump OCSP protocol exchanges. A hexadecimal dump of the OCSP request and response bytes is displayed."

(I think that is all that as needed - the other text was redundant.)

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 92:

> 90:         <th scope="row"><code>certpath</code></th>
> 91:         <td>Turns on debugging for the PKIX <code>CertPathValidator</code> and <code>CertPathBuilder</code> implementations. Use the <code>ocsp</code> sub-option with the <code>certpath</code> option for OCSP protocol tracing. A hexadecimal dump of the OCSP request and response bytes is displayed.
> 92:             You can use the following sub-options with the <code>certpath</code> option:

Change this to: "The following sub-options can be used with the <code>certpath</code> option:"

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 149:

> 147:     <tr>
> 148:         <th scope="row"><code>provider</code></th>
> 149:         <td>Security provider debugging. The following engines can be used with the <code>provider</code> sub-option:

Change second sentence to: "The following sub-option can be used with the <code>provider</code> option:

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 150:

> 148:         <th scope="row"><code>provider</code></th>
> 149:         <td>Security provider debugging. The following engines can be used with the <code>provider</code> sub-option:
> 150:             <code>engine=(engines)</code> : The output is displayed only for a specified list of JCA engines.

s/JCA engines/one or more JCA engines, separated by a comma/

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 151:

> 149:         <td>Security provider debugging. The following engines can be used with the <code>provider</code> sub-option:
> 150:             <code>engine=(engines)</code> : The output is displayed only for a specified list of JCA engines.
> 151:             The supported values for (engines) are:

Add "KDF" to this list.

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 183:

> 181:     <tr>
> 182:         <th scope="row"><code>x509</code></th>
> 183:         <td>X.509 certificate debugging. You can use the following sub-option with <code>X.509</code>

Change the second sentence to "The following sub-option can be used with the <code>X.509</code> option:"

src/java.base/share/classes/java/security/package-info.java line 77:

> 75:  * <ul>
> 76:  *   <li><a href="doc-files/security-related-system-properties.html">
> 77:  *     Security-Related System Properties</a></li>

For now change this to "The {@code java.security.debug} System Property".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982192240
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982181081
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982187987
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982188630
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982188810
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982189198
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982190366
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982195794
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982201726
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982201136
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982207469
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982203574
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982209097
PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1982210022

From vpaprotski at openjdk.org  Wed Mar  5 23:03:23 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 5 Mar 2025 23:03:23 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
Message-ID: <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>

> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
> 
> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
> 
> Before (no AVX512)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
> 
> After (with AVX2)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
> 
> 
> Before (with AVX512):
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        102...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  more comment improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23719/files
  - new: https://git.openjdk.org/jdk/pull/23719/files/bb450137..9d13cefa

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

  Stats: 72 lines in 2 files changed: 45 ins; 5 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/23719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23719/head:pull/23719

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

From duke at openjdk.org  Wed Mar  5 23:57:59 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 5 Mar 2025 23:57:59 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v12]
In-Reply-To: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
Message-ID: <XEX3bo4ktTAfdBxbYU07Myk7HSYjcDruYw1Vy1fqOF8=.994c87ba-c1f2-4341-a1f5-a9ffb147b227@github.com>

> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc.
> 
> ![image](https://github.com/user-attachments/assets/0c9a79f3-4cb2-414c-af1d-eac2590740ea)
> 
> 
> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page.

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

  8328914: Document the java.security.debug property in javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23569/files
  - new: https://git.openjdk.org/jdk/pull/23569/files/e40dcd7f..c8597cf1

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

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

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

From sviswanathan at openjdk.org  Thu Mar  6 01:02:17 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 6 Mar 2025 01:02:17 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
Message-ID: <FRoxIoCBF5NT4hTDG23IauUpXSn-9OyW6sR9DTXZouA=.fb3aceaf-eaca-4b52-9718-a290f2af7b2a@github.com>

On Wed, 5 Mar 2025 23:03:23 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comment improvements

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23719#pullrequestreview-2662829592

From valeriep at openjdk.org  Thu Mar  6 06:12:54 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 6 Mar 2025 06:12:54 GMT
Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider
 services map [v5]
In-Reply-To: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
References: <fkJRJjb6eiFCZkmopox2b_YJALJMDOxX6zk8iQcud0k=.ef06e29f-3b21-42a9-beb9-7e5dedd06b02@github.com>
 <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
Message-ID: <rDsx5wIz6_0raBGWLzZG1JpvZvT6bYQqo0O4jcii2Hg=.90edb312-dfda-4993-ab42-3780aef82315@github.com>

On Wed, 12 Feb 2025 20:46:31 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map").
>> 
>> #### New services map design
>> 
>> Here is the high-level hierarchy of the new services map design:
>> 
>> * `servicesMap` (`ServicesMap`)
>>     * Instances (fields)
>>         * `services` (`Map<ServiceKey, Service>`): unifies the previous `serviceMap` and `legacyMap`
>>         * `legacySvcKeys` (`Set<ServiceKey>`): set indicating which keys in `services` correspond to the Legacy API
>>         * `serviceProps` (`Map<ServiceKey, String>`): keeps track of the _provider Hashtable entries_ that originated services entries <sup>(1)</sup>
>>         * `serviceAttrProps` (`Map<ServiceKey, Map<UString, String>>`): keeps track of the _provider Hashtable entries_ that originated service attributes <sup>(1)</sup>
>>         * `serviceSet` (`AtomicReference<Set<Service>>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method
>>     * Writers' methods (for providers registering services through the Current or the Legacy API)
>>         * `boolean putService(Service svc)`
>>         * `boolean removeService(Service svc)`
>>         * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)`
>>         * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)`
>>         * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)`
>>         * `boolean removeLegacy(ServiceKey key, String className)`
>>         * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)`
>>         * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)`
>>     * Readers' methods (for services users and `GetInstance` APIs)
>>         * `Set<Service> getServices()`
>>         * `Service getService(ServiceKey key)`
>>     * Other methods: default and copy constructors, `void clear()`
>> 
>> (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms.
>> 
>> #### Testing
>> 
>> As part of our testing, we observed all the tests pass in the following categories:
>> 
>> * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398))
>> * `jdk/com/sun/crypto`
>> * `jd...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear ServicesMap fields in the declared order
>   
>   Constructors assign the fields in the same order.

src/java.base/share/classes/java/security/Provider.java line 1486:

> 1484:      * case, Properties map entries are synchronized. In the latter, Properties
> 1485:      * map entries are not modified.
> 1486:      */

I am not too sure I get this comment block. Judging from the impl, this enum seems to be used to indicate whether the Properties map is updated. The part about ServiceMap is especially confusing. Is this enum for Properties map or ServicesMap? In addition, instead of stating "an entry that is not a service, alias or attribute.", can we just state the remaining types? Is "In the former case" refer to the UPDATE? In that paragraph. there is only one case. Lastly, there is only 2 values to this enum, can't this be replaced with a boolean?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1982747199

From valeriep at openjdk.org  Thu Mar  6 06:18:00 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 6 Mar 2025 06:18:00 GMT
Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider
 services map [v5]
In-Reply-To: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
References: <fkJRJjb6eiFCZkmopox2b_YJALJMDOxX6zk8iQcud0k=.ef06e29f-3b21-42a9-beb9-7e5dedd06b02@github.com>
 <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
Message-ID: <tS9_EN7fVYa-o-r4S65tjSk7wuNO3_tSUtwkAPRrxiM=.dd5f3063-ce16-45c6-846a-bef4bc9b36df@github.com>

On Wed, 12 Feb 2025 20:46:31 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map").
>> 
>> #### New services map design
>> 
>> Here is the high-level hierarchy of the new services map design:
>> 
>> * `servicesMap` (`ServicesMap`)
>>     * Instances (fields)
>>         * `services` (`Map<ServiceKey, Service>`): unifies the previous `serviceMap` and `legacyMap`
>>         * `legacySvcKeys` (`Set<ServiceKey>`): set indicating which keys in `services` correspond to the Legacy API
>>         * `serviceProps` (`Map<ServiceKey, String>`): keeps track of the _provider Hashtable entries_ that originated services entries <sup>(1)</sup>
>>         * `serviceAttrProps` (`Map<ServiceKey, Map<UString, String>>`): keeps track of the _provider Hashtable entries_ that originated service attributes <sup>(1)</sup>
>>         * `serviceSet` (`AtomicReference<Set<Service>>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method
>>     * Writers' methods (for providers registering services through the Current or the Legacy API)
>>         * `boolean putService(Service svc)`
>>         * `boolean removeService(Service svc)`
>>         * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)`
>>         * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)`
>>         * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)`
>>         * `boolean removeLegacy(ServiceKey key, String className)`
>>         * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)`
>>         * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)`
>>     * Readers' methods (for services users and `GetInstance` APIs)
>>         * `Set<Service> getServices()`
>>         * `Service getService(ServiceKey key)`
>>     * Other methods: default and copy constructors, `void clear()`
>> 
>> (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms.
>> 
>> #### Testing
>> 
>> As part of our testing, we observed all the tests pass in the following categories:
>> 
>> * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398))
>> * `jdk/com/sun/crypto`
>> * `jd...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear ServicesMap fields in the declared order
>   
>   Constructors assign the fields in the same order.

src/java.base/share/classes/java/security/Provider.java line 1502:

> 1500:                 return parseLegacy(servicesMap, ks, vs, opType);
> 1501:             } else if (value != null && oldValue instanceof String oldValueS &&
> 1502:                     opType == OPType.ADD) {

Which method is this else-block for? `value` is not null and not instanceof `String` and `oldValue` is instanceof `String` and `opType` is ADD?

src/java.base/share/classes/java/security/Provider.java line 1508:

> 1506:                 // to a removal. In any case, let the caller proceed with the
> 1507:                 // Properties map update.
> 1508:                 parseLegacy(servicesMap, ks, oldValueS, OPType.REMOVE);

no return here and falls through to the line 1512? Is this really intended?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1982749780
PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1982751287

From valeriep at openjdk.org  Thu Mar  6 07:08:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 6 Mar 2025 07:08:55 GMT
Subject: RFR: 8345139: Fix bugs and inconsistencies in the Provider
 services map [v5]
In-Reply-To: <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
References: <fkJRJjb6eiFCZkmopox2b_YJALJMDOxX6zk8iQcud0k=.ef06e29f-3b21-42a9-beb9-7e5dedd06b02@github.com>
 <-Ku_-bAwU3qr8jGdPvIpGOPVDgF23Q5jLyrQ1JDvxwE=.a3ea2030-a9a3-4134-9431-b25461ee365e@github.com>
Message-ID: <BOdLlw3cCozCycphFmZDAEHiVW-p_lkfZwKLt93pjHA=.cea63654-0cfa-4e45-a0d7-69c1a33b4f7f@github.com>

On Wed, 12 Feb 2025 20:46:31 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map").
>> 
>> #### New services map design
>> 
>> Here is the high-level hierarchy of the new services map design:
>> 
>> * `servicesMap` (`ServicesMap`)
>>     * Instances (fields)
>>         * `services` (`Map<ServiceKey, Service>`): unifies the previous `serviceMap` and `legacyMap`
>>         * `legacySvcKeys` (`Set<ServiceKey>`): set indicating which keys in `services` correspond to the Legacy API
>>         * `serviceProps` (`Map<ServiceKey, String>`): keeps track of the _provider Hashtable entries_ that originated services entries <sup>(1)</sup>
>>         * `serviceAttrProps` (`Map<ServiceKey, Map<UString, String>>`): keeps track of the _provider Hashtable entries_ that originated service attributes <sup>(1)</sup>
>>         * `serviceSet` (`AtomicReference<Set<Service>>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method
>>     * Writers' methods (for providers registering services through the Current or the Legacy API)
>>         * `boolean putService(Service svc)`
>>         * `boolean removeService(Service svc)`
>>         * `boolean putClassNameLegacy(ServiceKey key, String className, String propKey)`
>>         * `boolean putAliasLegacy(ServiceKey key, ServiceKey aliasKey, String propKey)`
>>         * `boolean putAttributeLegacy(ServiceKey key, String attrName, String attrValue, String propKey)`
>>         * `boolean removeLegacy(ServiceKey key, String className)`
>>         * `boolean removeAliasLegacy(ServiceKey key, ServiceKey aliasKey)`
>>         * `boolean removeAttributeLegacy(ServiceKey key, String attrName, String attrValue)`
>>     * Readers' methods (for services users and `GetInstance` APIs)
>>         * `Set<Service> getServices()`
>>         * `Service getService(ServiceKey key)`
>>     * Other methods: default and copy constructors, `void clear()`
>> 
>> (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms.
>> 
>> #### Testing
>> 
>> As part of our testing, we observed all the tests pass in the following categories:
>> 
>> * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk/actions/runs/12193211398))
>> * `jdk/com/sun/crypto`
>> * `jd...
>
> Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clear ServicesMap fields in the declared order
>   
>   Constructors assign the fields in the same order.

src/java.base/share/classes/java/security/Provider.java line 1536:

> 1534: 
> 1535:     private Object implRemove(Object key) {
> 1536:         Object oldValue = super.get(key);

`oldValue` isn't really old value, is it? Naming it `oldValue` and pass it to `doLegacyOp()` as `value` is very confusing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22613#discussion_r1982802851

From jbhateja at openjdk.org  Thu Mar  6 09:34:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 6 Mar 2025 09:34:53 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v3]
In-Reply-To: <wBKHcU8T9cMhYxLItWJ62IocCpPm9t8C4H_Ky4my9Fo=.fac18f07-5383-4333-b68e-031d376be1e2@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xYDRgjvW5AksXcXKUBnx7LlB4PmGEjEITKA27iHs4rE=.e69744e8-2fe9-4b0c-a49d-25177a2e8daf@github.com>
 <0E2AqFpNPjDjP6jqCXn8toePBcW2SIHw1kFXlZX4W_U=.8d692bfa-0598-4969-b480-4a285366e0bb@github.com>
 <V62AuLpV4oPamF6hi7zMdqs21tyw9i4ug_9UlNCQpNE=.2d6e0fcf-3e2c-406f-a336-bb2dedd923e8@github.com>
 <M5Z8mk-KZoytxUmhzRWKqUFtHRWoxY28Bfv8h_ijjMg=.351389d9-57d1-4589-a853-41125858760a@github.com>
 <wBKHcU8T9cMhYxLItWJ62IocCpPm9t8C4H_Ky4my9Fo=.fac18f07-5383-4333-b68e-031d376be1e2@github.com>
Message-ID: <v0R-8kNylqKabqUJFfrIc8vcJ4tNMEfFm00stOcCxlo=.37519051-674e-41fe-80c8-60167e82f86b@github.com>

On Wed, 5 Mar 2025 18:27:44 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Hi @ferakocz , 
>> 
>> Thanks!, for efficient utilization of Decode ICache (please refer to Intel SDM section 3.4.2.5), code blocks should be aligned to 32-byte boundaries; a 64-byte aligned code is a superset of both 16 and 32 byte aligned addresses and also matches with the cacheline size. However, I can noticed that we have been using OptoLoopAlignment at places in AES-GCM also.
>> 
>> I introduced some errors in generate_dilithiumAlmostInverseNtt_avx512 implementation in anticipation of catching it through existing ML_DSA_Tests under 
>> test/jdk/sun/security/provider/acvp
>> 
>> But all the tests passed for me.
>> `java  -jar /home/jatinbha/sandboxes/jtreg/build/images/jtreg/lib/jtreg.jar -jdk:$JAVA_HOME -Djdk.test.lib.artifacts.ACVP-Server=/home/jatinbha/softwares/v1.1.0.38.zip -va -timeout:4 Launcher.java`
>> 
>> Can you please point out a test I need to use for validation
>
> I think the easiest is to put a for (int i = 0; i < 1000; i++) loop around  the switch statement in the run() method of  the ML_DSA_Test class (test/jdk/sun/security/provider/acvp/ML_DSA_Test.java). (This is because the intrinsics kick in after a few thousand calls of the method.)

Hi @ferakocz , Yes, we should modify the test or lower the compilation threshold with -Xbatch -XX:TieredCompileThreshold=0.1.

Alternatively, since the tests has a depedency on Automatic Cryptographic Validation Test server I have created a simplified test which cover all the security levels.

Kindly include [test/hotspot/jtreg/compiler/intrinsics/signature/TestModuleLatticeDSA.java
](https://github.com/ferakocz/jdk/pull/1)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1983009390

From jbhateja at openjdk.org  Thu Mar  6 09:34:55 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 6 Mar 2025 09:34:55 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v4]
In-Reply-To: <nmN_TxNaqRqSAVqYzrUhO9NXpzzixG6d1OsvBArpLsA=.857b5aa3-694a-4528-a922-c3fdab141ffa@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <nmN_TxNaqRqSAVqYzrUhO9NXpzzixG6d1OsvBArpLsA=.857b5aa3-694a-4528-a922-c3fdab141ffa@github.com>
Message-ID: <Tt_EK6dquzqjnrcKkoLH1aLcXODeLsjaL7TrRelfBkw=.85fe1fa7-08fb-4b85-bef3-bfc963ebdd5e@github.com>

On Wed, 5 Mar 2025 13:10:34 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added alignment to loop entries.

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 85:

> 83:   if (UseSHA3Intrinsics) {
> 84:     StubRoutines::_sha3_implCompress   = generate_sha3_implCompress(StubGenStubId::sha3_implCompress_id);
> 85:     StubRoutines::_double_keccak         = generate_double_keccak();

Should UseDilithiumIntrinsics guard double_keccak generation ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1982922845

From duke at openjdk.org  Thu Mar  6 09:49:12 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 6 Mar 2025 09:49:12 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v4]
In-Reply-To: <Tt_EK6dquzqjnrcKkoLH1aLcXODeLsjaL7TrRelfBkw=.85fe1fa7-08fb-4b85-bef3-bfc963ebdd5e@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <nmN_TxNaqRqSAVqYzrUhO9NXpzzixG6d1OsvBArpLsA=.857b5aa3-694a-4528-a922-c3fdab141ffa@github.com>
 <Tt_EK6dquzqjnrcKkoLH1aLcXODeLsjaL7TrRelfBkw=.85fe1fa7-08fb-4b85-bef3-bfc963ebdd5e@github.com>
Message-ID: <ZSL7xZxzHn6Y7QG-QZJR8MtSgxWnQXZiws2AaciR83g=.04fc97c3-e287-421b-ba8b-14fd04852b37@github.com>

On Thu, 6 Mar 2025 08:37:57 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added alignment to loop entries.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 85:
> 
>> 83:   if (UseSHA3Intrinsics) {
>> 84:     StubRoutines::_sha3_implCompress   = generate_sha3_implCompress(StubGenStubId::sha3_implCompress_id);
>> 85:     StubRoutines::_double_keccak         = generate_double_keccak();
> 
> Should UseDilithiumIntrinsics guard double_keccak generation ?

No, that is more of a SHA3 thing, other algorithms can take advantage of it, too (e.g. ML-KEM).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1983033331

From michaelm at openjdk.org  Thu Mar  6 10:28:20 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Mar 2025 10:28:20 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
Message-ID: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>

Hi,

Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
addresses from exception message strings, unless the enhanced mode for the specific category 
has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
updated in 8207846.

This PR aims to increase the coverage of enhanced exception messages in the networking code.
A limited number of exceptions are already hidden (restricted) by default. The new categories and 
exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
(while preserving the existing behavior).

The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
a comma separated list of category names, which identify groups of exceptions where the exception
message may be enhanced. Any category not listed is "restricted" which means that potentially
sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.

The changes to the java.security conf file describe the exact changes in terms of the categories now
supported and any changes in behavior.

Thanks,
Michael

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

Commit messages:
 - remove file added by mistake
 - whitespace
 - moved test
 - Merge branch 'master' into 8348986-exceptions
 - update
 - update
 - Merge branch 'master' into 8348986-exceptions
 - update
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - ... and 3 more: https://git.openjdk.org/jdk/compare/b1a21b56...c4419860

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348986
  Stats: 1002 lines in 42 files changed: 762 ins; 104 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From michaelm at openjdk.org  Thu Mar  6 10:46:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Mar 2025 10:46:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v2]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <ReTVIq4Jzm7ki_mb0YnWVS_arlFB7mbFPPZTNvMlSU8=.11efccac-16a5-4862-acca-07f280a487e2@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  doc + copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/c4419860..074da251

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

  Stats: 23 lines in 3 files changed: 10 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From myankelevich at openjdk.org  Thu Mar  6 11:13:52 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 6 Mar 2025 11:13:52 GMT
Subject: RFR: 8219408: Tests should handle ${} in the view of jtreg
 "smart action"
In-Reply-To: <YOGQ8ZDmWhFPNdfPkpRG5BaiqkniwSUsigE-L1FitXo=.7e01ef4d-cb65-4729-9394-7dc014c8ecfd@github.com>
References: <YOGQ8ZDmWhFPNdfPkpRG5BaiqkniwSUsigE-L1FitXo=.7e01ef4d-cb65-4729-9394-7dc014c8ecfd@github.com>
Message-ID: <Xzf233Omb6HE2k-9KoXQxtoqSd1FibXiM2vonG7De40=.752f7c06-5605-42c9-a783-1e4722e34a50@github.com>

On Tue, 4 Mar 2025 12:53:16 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR I removed TEST.properties files that disabled smart action tags. It is safe to remove the entire file: the smart action tags was the only directive in them. I verified the affected tests pass successfully.

Looks good to me ?

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

PR Review: https://git.openjdk.org/jdk/pull/23896#pullrequestreview-2664119991

From jpai at openjdk.org  Thu Mar  6 11:26:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Mar 2025 11:26:10 GMT
Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to
 run fully in java [v2]
In-Reply-To: <Xnb4JtgmSk3jOukZ4xL6TfIIuRoNeiOlZc-I_SDqxJo=.812b83e1-7c73-4a1d-8a5f-42f9f13655bb@github.com>
References: <cOug7QtPpMMTGQ7GTl9V0XrsDqnPQuHJDFDdsMQcKOY=.30857b35-d005-45c9-9a68-87766a35d6d3@github.com>
 <Xnb4JtgmSk3jOukZ4xL6TfIIuRoNeiOlZc-I_SDqxJo=.812b83e1-7c73-4a1d-8a5f-42f9f13655bb@github.com>
Message-ID: <48bAbcAmOcprWkUwFc7z37F1JOTpEv046okz8mpQxS4=.e1da5b45-e085-4bae-8f49-2a27affd40b9@github.com>

On Thu, 27 Feb 2025 17:49:48 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Refactor the following to run fully in java:
>> test/java/security//Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
>> test/java/security//Security/ClassLoaderDeadlock/Deadlock.sh
>
> 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 three additional commits since the last revision:
> 
>  - typo
>  - Merge branch 'master' into JDK-8349348
>  - JDK-8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java

test/jdk/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java line 28:

> 26: * @bug 5094825
> 27: * @summary verify no deadlock if crypto provider in other classloader is used to verify signed jars
> 28: * @modules java.base/java.security

Hello Mikhail, `java.security` package is an exported package from `java.base`. So you don't need this `@modules` declaration.

test/jdk/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java line 30:

> 28: * @modules java.base/java.security
> 29: * @library ./Deadlock.jar
> 30: * @compile -g provider/HashProvider.java

Is the `-g` needed?

test/jdk/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java line 31:

> 29: * @library ./Deadlock.jar
> 30: * @compile -g provider/HashProvider.java
> 31: * @run main/othervm/timeout=30 -Djava.awt.headless=true ClassLoaderDeadlock

The `-Djava.awt.headless=true` is likely not needed but since it was used in the original test script, I think it's OK to carry it over.

test/jdk/java/security/Security/ClassLoaderDeadlock/Deadlock.java line 29:

> 27:  * @summary make sure we do not deadlock loading signed JAR with getInstance()
> 28:  * @library ./Deadlock.jar
> 29:  * @build Deadlock

`Deadlock` here is the class name of the test itself. So you don't need to `@build` it explicitly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23440#discussion_r1983175334
PR Review Comment: https://git.openjdk.org/jdk/pull/23440#discussion_r1983177523
PR Review Comment: https://git.openjdk.org/jdk/pull/23440#discussion_r1983177327
PR Review Comment: https://git.openjdk.org/jdk/pull/23440#discussion_r1983179883

From myankelevich at openjdk.org  Thu Mar  6 11:42:05 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 6 Mar 2025 11:42:05 GMT
Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to
 run fully in java [v2]
In-Reply-To: <48bAbcAmOcprWkUwFc7z37F1JOTpEv046okz8mpQxS4=.e1da5b45-e085-4bae-8f49-2a27affd40b9@github.com>
References: <cOug7QtPpMMTGQ7GTl9V0XrsDqnPQuHJDFDdsMQcKOY=.30857b35-d005-45c9-9a68-87766a35d6d3@github.com>
 <Xnb4JtgmSk3jOukZ4xL6TfIIuRoNeiOlZc-I_SDqxJo=.812b83e1-7c73-4a1d-8a5f-42f9f13655bb@github.com>
 <48bAbcAmOcprWkUwFc7z37F1JOTpEv046okz8mpQxS4=.e1da5b45-e085-4bae-8f49-2a27affd40b9@github.com>
Message-ID: <m9b4J_6z9qn_FH_mtaYzqtIkM-rRUPDyzKvAY_A84_E=.ce0cb3da-5cc6-4e86-b77f-f49f6073c51c@github.com>

On Thu, 6 Mar 2025 11:20:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - typo
>>  - Merge branch 'master' into JDK-8349348
>>  - JDK-8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java
>
> test/jdk/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java line 28:
> 
>> 26: * @bug 5094825
>> 27: * @summary verify no deadlock if crypto provider in other classloader is used to verify signed jars
>> 28: * @modules java.base/java.security
> 
> Hello Mikhail, `java.security` package is an exported package from `java.base`. So you don't need this `@modules` declaration.

Removed in the next commit, thanks

> test/jdk/java/security/Security/ClassLoaderDeadlock/Deadlock.java line 29:
> 
>> 27:  * @summary make sure we do not deadlock loading signed JAR with getInstance()
>> 28:  * @library ./Deadlock.jar
>> 29:  * @build Deadlock
> 
> `Deadlock` here is the class name of the test itself. So you don't need to `@build` it explicitly.

Removed in the next commit, thanks for noticing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23440#discussion_r1983200862
PR Review Comment: https://git.openjdk.org/jdk/pull/23440#discussion_r1983201527

From myankelevich at openjdk.org  Thu Mar  6 11:46:00 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 6 Mar 2025 11:46:00 GMT
Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to
 run fully in java [v2]
In-Reply-To: <48bAbcAmOcprWkUwFc7z37F1JOTpEv046okz8mpQxS4=.e1da5b45-e085-4bae-8f49-2a27affd40b9@github.com>
References: <cOug7QtPpMMTGQ7GTl9V0XrsDqnPQuHJDFDdsMQcKOY=.30857b35-d005-45c9-9a68-87766a35d6d3@github.com>
 <Xnb4JtgmSk3jOukZ4xL6TfIIuRoNeiOlZc-I_SDqxJo=.812b83e1-7c73-4a1d-8a5f-42f9f13655bb@github.com>
 <48bAbcAmOcprWkUwFc7z37F1JOTpEv046okz8mpQxS4=.e1da5b45-e085-4bae-8f49-2a27affd40b9@github.com>
Message-ID: <74lRkDL6JAbcaYR2Rlxg_N0f9ZuVPfmIaeyY25iYG3g=.443f2dd7-468c-4a1f-ab44-e62ded3fc9b0@github.com>

On Thu, 6 Mar 2025 11:21:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - typo
>>  - Merge branch 'master' into JDK-8349348
>>  - JDK-8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to run fully in java
>
> test/jdk/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java line 30:
> 
>> 28: * @modules java.base/java.security
>> 29: * @library ./Deadlock.jar
>> 30: * @compile -g provider/HashProvider.java
> 
> Is the `-g` needed?

This was a carry over from the script, same as `-Djava.awt.headless=true`. Just tried removing them, they both indeed seem to do nothing when used with jtreg. Should be removed in the next commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23440#discussion_r1983206286

From myankelevich at openjdk.org  Thu Mar  6 11:49:12 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 6 Mar 2025 11:49:12 GMT
Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to
 run fully in java [v3]
In-Reply-To: <cOug7QtPpMMTGQ7GTl9V0XrsDqnPQuHJDFDdsMQcKOY=.30857b35-d005-45c9-9a68-87766a35d6d3@github.com>
References: <cOug7QtPpMMTGQ7GTl9V0XrsDqnPQuHJDFDdsMQcKOY=.30857b35-d005-45c9-9a68-87766a35d6d3@github.com>
Message-ID: <JhRv5QjhteYJVmqNmF2xXaaO-NBfE0YeMJhQgWYKma0=.7e33c724-d431-4ed6-b49e-c050351f15c8@github.com>

> Refactor the following to run fully in java:
> test/java/security//Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
> test/java/security//Security/ClassLoaderDeadlock/Deadlock.sh

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

  Jaikiran's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23440/files
  - new: https://git.openjdk.org/jdk/pull/23440/files/92de4d99..e1056f95

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

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

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

From aturbanov at openjdk.org  Thu Mar  6 12:05:59 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 6 Mar 2025 12:05:59 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v2]
In-Reply-To: <ReTVIq4Jzm7ki_mb0YnWVS_arlFB7mbFPPZTNvMlSU8=.11efccac-16a5-4862-acca-07f280a487e2@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <ReTVIq4Jzm7ki_mb0YnWVS_arlFB7mbFPPZTNvMlSU8=.11efccac-16a5-4862-acca-07f280a487e2@github.com>
Message-ID: <MfyWdrSkY3fNayMvdrwI7jzBqk69E_yzNN02Am4Wcfo=.9f58de64-7f59-4633-af24-0a2d8f65a075@github.com>

On Thu, 6 Mar 2025 10:46:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc + copyright update

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 103:

> 101:      * the output is the replacement string.
> 102:      */
> 103:     public static abstract class SensitiveInfo  {

Let's sort modifiers in blessed order
Suggestion:

    public abstract static class SensitiveInfo {

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 338:

> 336:                                       | hostCompatFlag;
> 337:         enhancedUserExceptionText = SecurityProperties.includedInExceptions("userInfo");
> 338:         enhancedJarExceptionText =  SecurityProperties.INCLUDE_JAR_NAME_IN_EXCEPTIONS;

Suggestion:

        enhancedJarExceptionText = SecurityProperties.INCLUDE_JAR_NAME_IN_EXCEPTIONS;

test/jdk/sun/net/util/ExceptionsTest.java line 47:

> 45: 
> 46:     static boolean netEnabled() {
> 47:         System.out.printf("netEnabled = %b\n",  enhancedNetExceptions());

Suggestion:

        System.out.printf("netEnabled = %b\n", enhancedNetExceptions());

test/jdk/sun/net/util/ExceptionsTest.java line 52:

> 50: 
> 51:     static boolean dnsEnabled() {
> 52:         System.out.printf("dnsEnabled = %b\n",  enhancedLookupExceptions());

Suggestion:

        System.out.printf("dnsEnabled = %b\n", enhancedLookupExceptions());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983229570
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983232405
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983232786
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983232968

From fguallini at openjdk.org  Thu Mar  6 12:28:19 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 6 Mar 2025 12:28:19 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v2]
In-Reply-To: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
Message-ID: <XIEwj4lNiDE5AykPybPEl-_Mp_ZiyZzKi0qqFrFff1c=.4184f3d6-10d5-4e17-8946-880ddf0e5871@github.com>

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

Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:

  SSLContextTemplate and using asserts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23898/files
  - new: https://git.openjdk.org/jdk/pull/23898/files/837ddd1b..b6ac1491

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

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

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

From fguallini at openjdk.org  Thu Mar  6 12:28:19 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 6 Mar 2025 12:28:19 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v2]
In-Reply-To: <Wzlp3Xez58leZhyJDIFzT7QX7f_iBb6QHgyBuRoIrRA=.6adf4938-e370-44db-a4bd-f65a80b7021d@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 <Wzlp3Xez58leZhyJDIFzT7QX7f_iBb6QHgyBuRoIrRA=.6adf4938-e370-44db-a4bd-f65a80b7021d@github.com>
Message-ID: <82P3DRaKPj9iAQuRyvX-5R8wJUsFdKUlyTCM0cPCe6k=.11c1076e-038e-406e-af95-84e5d6ec657b@github.com>

On Wed, 5 Mar 2025 13:48:37 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   SSLContextTemplate and using asserts
>
> test/jdk/sun/security/ssl/SSLSocketImpl/NonAutoClose.java line 77:
> 
>> 75:     private final static int TLS_CLIENT_VAL = 4;
>> 76: 
>> 77:     private void expectValue(int got, int expected, String msg) throws IOException {
> 
> Can you just use the Asserts class instead?

Updated the old code with all suggestions, thanks

> test/jdk/sun/security/ssl/SSLSocketImpl/SetClientMode.java line 66:
> 
>> 64:      * Where do we find the keystores?
>> 65:      */
>> 66:     private final static String pathToStores = "../../../../javax/net/ssl/etc";
> 
> Could you use either SSLContextTemplate or SSLSocketTemplate for this test?

Sure, SSLContextTemplate is a better fit for these tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r1983264318
PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r1983264051

From michaelm at openjdk.org  Thu Mar  6 12:32:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Mar 2025 12:32:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v3]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <9L8DA7kJW6gXoCrbx4Gkn7hGk_3h8FmARRPHqzbHNs8=.6dc91725-b519-45c4-aa20-618df1155a91@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  from turbanoff review
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/074da251..41d1ef82

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

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

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

From jpai at openjdk.org  Thu Mar  6 12:42:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Mar 2025 12:42:54 GMT
Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to
 run fully in java [v3]
In-Reply-To: <JhRv5QjhteYJVmqNmF2xXaaO-NBfE0YeMJhQgWYKma0=.7e33c724-d431-4ed6-b49e-c050351f15c8@github.com>
References: <cOug7QtPpMMTGQ7GTl9V0XrsDqnPQuHJDFDdsMQcKOY=.30857b35-d005-45c9-9a68-87766a35d6d3@github.com>
 <JhRv5QjhteYJVmqNmF2xXaaO-NBfE0YeMJhQgWYKma0=.7e33c724-d431-4ed6-b49e-c050351f15c8@github.com>
Message-ID: <e8kKeR4slJe6VJvREHgq-XfQIj0XhjLLiZ5_2vCQal4=.afda001f-a38f-4b36-9e10-b91333ebdde6@github.com>

On Thu, 6 Mar 2025 11:49:12 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Refactor the following to run fully in java:
>> test/java/security//Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
>> test/java/security//Security/ClassLoaderDeadlock/Deadlock.sh
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Jaikiran's comments

Thank you for the updates, Mikhail. This looks good to me. Given the background of these tests, please have it approved from security-libs team too before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23440#pullrequestreview-2664326634

From mdonovan at openjdk.org  Thu Mar  6 13:16:59 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 6 Mar 2025 13:16:59 GMT
Subject: RFR: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version [v5]
In-Reply-To: <XsTfWEma-tBtCIgcHHCNCWe2pqROGqTpXbo19KWF7Os=.2c4edc6a-ae9e-4a42-8a00-262745006f03@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
 <MjxmH6TzVXuC_4-ugNXnv1KviSWZtc9BTuY-66Bhw4Q=.d228fcc7-9b71-43ae-b315-88f42a6e2d4b@github.com>
 <2HGfihxD_eEeB_YZO6o3r47uF6WbW4Axk6RS0W4SUlE=.72e1bce0-53c1-40c6-b83a-c135025ac967@github.com>
 <XsTfWEma-tBtCIgcHHCNCWe2pqROGqTpXbo19KWF7Os=.2c4edc6a-ae9e-4a42-8a00-262745006f03@github.com>
Message-ID: <EOv0eSs9Eanxtz8in1u3eHtsI94VfICcck47RrL6NTg=.7b0b579c-3947-427b-8c19-5524cbe4ce2f@github.com>

On Wed, 5 Mar 2025 20:05:53 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 78:
>> 
>>> 76:             testWithOpensslCommands(opensslPath);
>>> 77:         } else {
>>> 78:             // since the current version of openssl is not available, skip all
>> 
>> If this test is to check interoperability with OpenSSL, shouldn't we throw a skippedexception or an error instead of just running with java?
>
> Well, the test is also checking with java commands if openssl is available (line 75), then it makes sense to keep it when it is not available as it does not rely on Openssl.

My concern is that a Pass result is ambiguous: we may or may not have verified interoperability with openssl. If the Java portion of the test is valid and tests functionality not covered in other tests then it should be its own test. This test should either run with openssl or throw a SkippedException because openssl is not available.

>> test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java line 79:
>> 
>>> 77:             }
>>> 78:         }
>>> 79:         return verifyOpensslVersion(path, OPENSSL_BUNDLE_VERSION) ? path : null;
>> 
>> Do we want to keep this version check? On the one hand, it ensures that the system binaries or binaries specified via the system property will be a specific, known version, but on the other hand, the only way to run this test with a different version of the library is to change the code. Instead, can we just log the version that is used when the test is run?
>
> I considered removing this check as it seems redundant, but then I realised it was introduced to ensure the bundle version matches the version specified by the artifact name. It's possible that the artifact's filename could show a different version than the actual binaries with `-version`. On the other hand, most tests don't run this extra verification, that could be a good reason to remove it.

I don't have as strong an opinion about this check. If you want to keep it, though, then test really needs to be skipped or failed if the correct version of openssl isn't available. There are a lot of other versions of openssl that I could run this test with and I'd see Pass results when I wasn't actually running openssl at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1983305018
PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1983334180

From abarashev at openjdk.org  Thu Mar  6 14:49:57 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 6 Mar 2025 14:49:57 GMT
Subject: RFR: 8351223: Update localized resources in keytool and jarsigner
In-Reply-To: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
References: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
Message-ID: <MCVlsZBT5tM0jKMdeJToZ2CkCXdRzOIS8A4Qbj72n0g=.1ad867bb-b942-4cb6-8695-b849fad70340@github.com>

On Wed, 5 Mar 2025 00:23:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides localization updates for resources in `jarsigner` and `keytool`.
> The key/vals in this PR are updated to match the changes made in the English source files.
> Further context is provided on the JBS issue.

Hi @justin-curtis-lu! Just curious how urgent is this change? I'm going to finish the .java -> .properties conversion draft soon and then you can modify the properties files in plain UTF-8 text:
https://github.com/openjdk/jdk/pull/22774

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

PR Comment: https://git.openjdk.org/jdk/pull/23911#issuecomment-2704060755

From kdriver at openjdk.org  Thu Mar  6 16:22:54 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 6 Mar 2025 16:22:54 GMT
Subject: RFR: 8350582: Correct the parsing of the ssl value in
 javax.net.debug [v2]
In-Reply-To: <OOLlwC-5awewp5F6QRySWx1SOCQXFu9U5lJjNy2XjAU=.1f642d1d-5973-487c-8bef-c9fec05b41d7@github.com>
References: <nRKMTCnVVd9RZ0Y7peTyVlxOTmHUFHY7znOXXfX1x7Y=.18357cce-9edb-4544-8ecb-300c04dcf630@github.com>
 <OOLlwC-5awewp5F6QRySWx1SOCQXFu9U5lJjNy2XjAU=.1f642d1d-5973-487c-8bef-c9fec05b41d7@github.com>
Message-ID: <fpWyiS06OY3zuLSz48VpmkIokD6OrwNeuAzs9Fr99Io=.cfc11781-9a5a-4ea1-a43e-094f29f0b2b2@github.com>

On Thu, 27 Feb 2025 20:21:28 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Breaking the parent JDK-8044609 JBS issue into sub tasks. 
>> 
>> This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced.  This patch should be easier for backporting also.
>> 
>> Wider corrections can be followed up via parent bug.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Mikhail

test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 72:

> 70:                                 "supported_versions"),
> 71:                         null),
> 72:                 // ssl should print most details expect verbose details

nit: expect -> except

test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 105:

> 103:                                 "supported_versions"),
> 104:                         List.of("Plaintext before ENCRYPTION")),
> 105:                 // ssltypo contains "ssl". Treat like "ssl"

This is surprising behavior. We want it to behave as if there was no suffix after ssl?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r1983668452
PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r1983672768

From jbhateja at openjdk.org  Thu Mar  6 16:38:57 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 6 Mar 2025 16:38:57 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v4]
In-Reply-To: <nmN_TxNaqRqSAVqYzrUhO9NXpzzixG6d1OsvBArpLsA=.857b5aa3-694a-4528-a922-c3fdab141ffa@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <nmN_TxNaqRqSAVqYzrUhO9NXpzzixG6d1OsvBArpLsA=.857b5aa3-694a-4528-a922-c3fdab141ffa@github.com>
Message-ID: <P32zEjQp0CL9wYkVJU9i8pZa_VphYse1dv-DDOXE580=.30b087eb-29ca-40a2-bc34-6e802940bead@github.com>

On Wed, 5 Mar 2025 13:10:34 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added alignment to loop entries.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 2:

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

Please update copyright year

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 96:

> 94:       StubRoutines::_dilithiumMontMulByConstant = generate_dilithiumMontMulByConstant_avx512();
> 95:       StubRoutines::_dilithiumDecomposePoly = generate_dilithiumDecomposePoly_avx512();
> 96:     }

Indentation fix needed

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 362:

> 360:   const Register roundsLeft = r11;
> 361: 
> 362:   __ align(OptoLoopAlignment);

Redundant alignment before label should be before it's bind

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1983463096
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1983464620
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1983477681

From coffeys at openjdk.org  Thu Mar  6 16:51:54 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 6 Mar 2025 16:51:54 GMT
Subject: RFR: 8350582: Correct the parsing of the ssl value in
 javax.net.debug [v2]
In-Reply-To: <fpWyiS06OY3zuLSz48VpmkIokD6OrwNeuAzs9Fr99Io=.cfc11781-9a5a-4ea1-a43e-094f29f0b2b2@github.com>
References: <nRKMTCnVVd9RZ0Y7peTyVlxOTmHUFHY7znOXXfX1x7Y=.18357cce-9edb-4544-8ecb-300c04dcf630@github.com>
 <OOLlwC-5awewp5F6QRySWx1SOCQXFu9U5lJjNy2XjAU=.1f642d1d-5973-487c-8bef-c9fec05b41d7@github.com>
 <fpWyiS06OY3zuLSz48VpmkIokD6OrwNeuAzs9Fr99Io=.cfc11781-9a5a-4ea1-a43e-094f29f0b2b2@github.com>
Message-ID: <catzTn-xqJYeN6w0VrZM1caURa-KvLO9ODCdarLOCpI=.198467e5-026f-4ee3-b36f-7a3c5a0f028b@github.com>

On Thu, 6 Mar 2025 16:20:19 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback from Mikhail
>
> test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 105:
> 
>> 103:                                 "supported_versions"),
>> 104:                         List.of("Plaintext before ENCRYPTION")),
>> 105:                 // ssltypo contains "ssl". Treat like "ssl"
> 
> This is surprising behavior. We want it to behave as if there was no suffix after ssl?

yes, the javax.net.debug property doesn't specify any delimiter between options. Quite strange. It's also had the historical behaviour of printing all ssl details once the string property contains "ssl" with the exception that "sslctx" may be present.

Might target more behavioural changes via the  JDK-8044609 parent bug but for now, this patch is mimimal to aid backporting to update releases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r1983720961

From myankelevich at openjdk.org  Thu Mar  6 17:20:52 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 6 Mar 2025 17:20:52 GMT
Subject: RFR: 8349348: Refactor ClassLoaderDeadlock.sh and Deadlock.sh to
 run fully in java [v3]
In-Reply-To: <e8kKeR4slJe6VJvREHgq-XfQIj0XhjLLiZ5_2vCQal4=.afda001f-a38f-4b36-9e10-b91333ebdde6@github.com>
References: <cOug7QtPpMMTGQ7GTl9V0XrsDqnPQuHJDFDdsMQcKOY=.30857b35-d005-45c9-9a68-87766a35d6d3@github.com>
 <JhRv5QjhteYJVmqNmF2xXaaO-NBfE0YeMJhQgWYKma0=.7e33c724-d431-4ed6-b49e-c050351f15c8@github.com>
 <e8kKeR4slJe6VJvREHgq-XfQIj0XhjLLiZ5_2vCQal4=.afda001f-a38f-4b36-9e10-b91333ebdde6@github.com>
Message-ID: <1l9MkRK1YJbx8Y3kUoMY_55I4jn3EirYolEJ6mjU4rY=.f8a90eff-3fd7-4bb9-8794-e6b440cc0168@github.com>

On Thu, 6 Mar 2025 12:40:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Thank you for the updates, Mikhail. This looks good to me. Given the background of these tests, please have it approved from security-libs team too before integrating.

Thank you

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

PR Comment: https://git.openjdk.org/jdk/pull/23440#issuecomment-2704463936

From duke at openjdk.org  Thu Mar  6 17:37:33 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 6 Mar 2025 17:37:33 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v5]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <3bphXKLpIpxAZP-FEOeob6AaHbv0BAoEceJka64vMW8=.3e4f74e0-9479-4926-b365-b08d8d702692@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Accepted review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/3aaa106f..64135f29

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

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

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

From jlu at openjdk.org  Thu Mar  6 17:43:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Mar 2025 17:43:08 GMT
Subject: RFR: 8351223: Update localized resources in keytool and jarsigner
In-Reply-To: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
References: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
Message-ID: <Y6B91ntttkoHbiCnD3ND7dHlvhSLevL9B8LiNQHl5Y4=.5c77de4e-887e-4509-a7aa-0b6b8a6e18fb@github.com>

On Wed, 5 Mar 2025 00:23:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides localization updates for resources in `jarsigner` and `keytool`.
> The key/vals in this PR are updated to match the changes made in the English source files.
> Further context is provided on the JBS issue.

> Hi @justin-curtis-lu! Just curious how urgent is this change? I'm going to finish the .java -> .properties conversion draft soon and then you can modify the properties files in plain UTF-8 text: #22774

We want to get this into `24.0.2` . I think it would be preferable to get this change in now, as review has already been completed. Any updates for these files that occur in the next L10n update can be reviewed under the properties format as UTF-8 native. But please let me know otherwise.

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

PR Comment: https://git.openjdk.org/jdk/pull/23911#issuecomment-2704528445

From abarashev at openjdk.org  Thu Mar  6 18:05:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 6 Mar 2025 18:05:58 GMT
Subject: RFR: 8351223: Update localized resources in keytool and jarsigner
In-Reply-To: <Y6B91ntttkoHbiCnD3ND7dHlvhSLevL9B8LiNQHl5Y4=.5c77de4e-887e-4509-a7aa-0b6b8a6e18fb@github.com>
References: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
 <Y6B91ntttkoHbiCnD3ND7dHlvhSLevL9B8LiNQHl5Y4=.5c77de4e-887e-4509-a7aa-0b6b8a6e18fb@github.com>
Message-ID: <H5Ii6i4LtSryVKu62CzGTEU7ZWJ3pO8agC9AXMTn8fc=.a2868d8a-a10c-46ae-98d6-b3c5fbee27ce@github.com>

On Thu, 6 Mar 2025 17:40:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> > Hi @justin-curtis-lu! Just curious how urgent is this change? I'm going to finish the .java -> .properties conversion draft soon and then you can modify the properties files in plain UTF-8 text: #22774
> 
> We want to get this into `24.0.2` . I think it would be preferable to get this change in now, as review has already been completed. Any updates for these files that occur in the next L10n update can be reviewed under the properties format as UTF-8 native. But please let me know otherwise.

The thing is that my draft is pretty much ready and it's converting the same Resources files that you are modifying here. So if it's urgent I'll wait until you integrate this PR and then re-convert the files being changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23911#issuecomment-2704577039

From mullan at openjdk.org  Thu Mar  6 18:26:57 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Mar 2025 18:26:57 GMT
Subject: RFR: 8348309: MultiNST tests need more debugging and timing [v2]
In-Reply-To: <xvQb5pqgzcEG4UuYtQcrQn2rrLMxU8xRWaJnmck7vA8=.09c14121-e37a-4a6d-846a-dffe44f207b9@github.com>
References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com>
 <xvQb5pqgzcEG4UuYtQcrQn2rrLMxU8xRWaJnmck7vA8=.09c14121-e37a-4a6d-846a-dffe44f207b9@github.com>
Message-ID: <zo6P2USoP1SdSXuJK2t8tLp13559sZMhuTSh2FgPjMY=.cf014d5d-1d56-49b0-ae56-bedd1fb5ceda@github.com>

On Thu, 20 Feb 2025 00:20:30 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I need a review of this change that adds new timing controls for the initial server setup.  On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect.  Additional debugging is added to help identify if there are other timing issues.
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Looks ok to me. Bug needs a `noreg-self` label.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23407#pullrequestreview-2665295331

From fguallini at openjdk.org  Thu Mar  6 18:33:58 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 6 Mar 2025 18:33:58 GMT
Subject: RFR: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version [v5]
In-Reply-To: <EOv0eSs9Eanxtz8in1u3eHtsI94VfICcck47RrL6NTg=.7b0b579c-3947-427b-8c19-5524cbe4ce2f@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
 <MjxmH6TzVXuC_4-ugNXnv1KviSWZtc9BTuY-66Bhw4Q=.d228fcc7-9b71-43ae-b315-88f42a6e2d4b@github.com>
 <2HGfihxD_eEeB_YZO6o3r47uF6WbW4Axk6RS0W4SUlE=.72e1bce0-53c1-40c6-b83a-c135025ac967@github.com>
 <XsTfWEma-tBtCIgcHHCNCWe2pqROGqTpXbo19KWF7Os=.2c4edc6a-ae9e-4a42-8a00-262745006f03@github.com>
 <EOv0eSs9Eanxtz8in1u3eHtsI94VfICcck47RrL6NTg=.7b0b579c-3947-427b-8c19-5524cbe4ce2f@github.com>
Message-ID: <WXttoPUfL71ctH3wij_6ITEkOyGFZdRHtOGBAr6o7Lo=.377ebb42-2da1-4f5f-8256-28dd6f1042d3@github.com>

On Thu, 6 Mar 2025 12:54:03 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Well, the test is also checking with java commands if openssl is available (line 75), then it makes sense to keep it when it is not available as it does not rely on Openssl.
>
> My concern is that a Pass result is ambiguous: we may or may not have verified interoperability with openssl. If the Java portion of the test is valid and tests functionality not covered in other tests then it should be its own test. This test should either run with openssl or throw a SkippedException because openssl is not available.

If Openssl is not available in the instance, this test is using preexisting PKCS12 files generated with an older Openssl version for testing compatibility between openssl and keytool, these files are located in the ./params directory.
As discussed with Matthew, I will separate both paths adding an extra "test" tag, one test will generate the PKCS12 on the fly and throw an SkippedException if Openssl is not available, and the other will use the preexisting files for the verifications.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23613#discussion_r1983865578

From myankelevich at openjdk.org  Thu Mar  6 18:53:56 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 6 Mar 2025 18:53:56 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v3]
In-Reply-To: <CvYBKWdfLP9pI6wTgF1N1m-2oB3wfu5Q91yWJwHRIvk=.d2be164d-a095-4faa-ab49-a30a611904fb@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <CvYBKWdfLP9pI6wTgF1N1m-2oB3wfu5Q91yWJwHRIvk=.d2be164d-a095-4faa-ab49-a30a611904fb@github.com>
Message-ID: <ZdL9kVNzRTO1gcMNBZ-xA6nCuljztV2PFftam4aA1Hk=.cfa6e9af-01df-4af5-833e-952fe85a8481@github.com>

On Thu, 6 Feb 2025 15:54:47 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

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

Still in review

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

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

From hchao at openjdk.org  Thu Mar  6 19:12:54 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 6 Mar 2025 19:12:54 GMT
Subject: RFR: 8350582: Correct the parsing of the ssl value in
 javax.net.debug [v2]
In-Reply-To: <OOLlwC-5awewp5F6QRySWx1SOCQXFu9U5lJjNy2XjAU=.1f642d1d-5973-487c-8bef-c9fec05b41d7@github.com>
References: <nRKMTCnVVd9RZ0Y7peTyVlxOTmHUFHY7znOXXfX1x7Y=.18357cce-9edb-4544-8ecb-300c04dcf630@github.com>
 <OOLlwC-5awewp5F6QRySWx1SOCQXFu9U5lJjNy2XjAU=.1f642d1d-5973-487c-8bef-c9fec05b41d7@github.com>
Message-ID: <IvxRj6DqxHDXFjSpffSxVbfetBKY1JTQaIh-tDYm7U8=.15efa8a9-1c5a-4bb7-a7a2-67cd3608fd0f@github.com>

On Thu, 27 Feb 2025 20:21:28 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Breaking the parent JDK-8044609 JBS issue into sub tasks. 
>> 
>> This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced.  This patch should be easier for backporting also.
>> 
>> Wider corrections can be followed up via parent bug.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Mikhail

src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 1:

> 1: /*

Nit: copyright year update

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r1983916173

From hchao at openjdk.org  Thu Mar  6 19:16:54 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 6 Mar 2025 19:16:54 GMT
Subject: RFR: 8350582: Correct the parsing of the ssl value in
 javax.net.debug [v2]
In-Reply-To: <OOLlwC-5awewp5F6QRySWx1SOCQXFu9U5lJjNy2XjAU=.1f642d1d-5973-487c-8bef-c9fec05b41d7@github.com>
References: <nRKMTCnVVd9RZ0Y7peTyVlxOTmHUFHY7znOXXfX1x7Y=.18357cce-9edb-4544-8ecb-300c04dcf630@github.com>
 <OOLlwC-5awewp5F6QRySWx1SOCQXFu9U5lJjNy2XjAU=.1f642d1d-5973-487c-8bef-c9fec05b41d7@github.com>
Message-ID: <Q_yf_-pE-dpHX5k_r5qCLicP178HMzsOL3IAN5qmQ0M=.b40aac15-d26a-44e6-a803-6b29784f3090@github.com>

On Thu, 27 Feb 2025 20:21:28 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Breaking the parent JDK-8044609 JBS issue into sub tasks. 
>> 
>> This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced.  This patch should be easier for backporting also.
>> 
>> Wider corrections can be followed up via parent bug.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback from Mikhail

test/jdk/sun/security/ssl/SSLLogger/DebugPropertyValuesTest.java line 1:

> 1: /*

Suggest we add verifying debug output when setting different javax.net.debug properties to the test summary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23781#discussion_r1983920412

From mullan at openjdk.org  Thu Mar  6 20:08:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Mar 2025 20:08:07 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v12]
In-Reply-To: <gpU93oFx4aeQPyKo0h3L6PWcJHNrYz448j0MQLk3M-E=.52c97e2b-66a5-465a-974f-d1286652c667@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <gpU93oFx4aeQPyKo0h3L6PWcJHNrYz448j0MQLk3M-E=.52c97e2b-66a5-465a-974f-d1286652c667@github.com>
Message-ID: <P001ZgF9r-5vaUu8OUtsz0z4scGSJIbyhog0IcD6kKA=.303310a7-168c-4296-93c3-75e78e28790a@github.com>

On Wed, 5 Mar 2025 01:14:40 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>> 
>> Also fixing JDK-8350807 on the server side just as a side-effect, not a dedicated fix for that issue.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update documentation and unit tests to signal TLS scope case-insensitivity

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

> 745: #
> 746: #     HANDSHAKE restricts algorithm to be used for signing TLS handshake.
> 747: #     CERTIFICATE restricts algorithm to be used for signatures in certificates.

s/HANDSHAKE/'Handshake'/
s/CERTIFICATE/'Certificate'/

Suggest slight rewording: "Handshake restricts the use of the algorithm in TLS handshake signatures." and "Certificate restricts the use of the algorithm in certificate signatures."

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

> 746: #     HANDSHAKE restricts algorithm to be used for signing TLS handshake.
> 747: #     CERTIFICATE restricts algorithm to be used for signatures in certificates.
> 748: #     These constraints can't be mixed with any other usage constraints for the

s/can't/cannot/ (sounds more formal).

The word "any" seems redundant, suggest removing.

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

> 750: #     ampersand '&'.
> 751: #     See https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 for more
> 752: #     information on signatures used in TLS handshake and in certificates.

I suggest we don't include a reference to the TLS 1.3 RFC. Something like this might be fine for the developer's guide though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1983972328
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1983974557
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1983981814

From coffeys at openjdk.org  Thu Mar  6 20:10:58 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 6 Mar 2025 20:10:58 GMT
Subject: RFR: 8350582: Correct the parsing of the ssl value in
 javax.net.debug [v3]
In-Reply-To: <nRKMTCnVVd9RZ0Y7peTyVlxOTmHUFHY7znOXXfX1x7Y=.18357cce-9edb-4544-8ecb-300c04dcf630@github.com>
References: <nRKMTCnVVd9RZ0Y7peTyVlxOTmHUFHY7znOXXfX1x7Y=.18357cce-9edb-4544-8ecb-300c04dcf630@github.com>
Message-ID: <a85HHwLC05V0ORSzUJhQ7GJQhzpOjewUMQaFzVCvBUM=.bd405a8f-e753-4ef0-9f7c-fbe4dc66bd1b@github.com>

> Breaking the parent JDK-8044609 JBS issue into sub tasks. 
> 
> This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced.  This patch should be easier for backporting also.
> 
> Wider corrections can be followed up via parent bug.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate latest review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23781/files
  - new: https://git.openjdk.org/jdk/pull/23781/files/6262e539..0cf24eda

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

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

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

From abarashev at openjdk.org  Thu Mar  6 20:30:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 6 Mar 2025 20:30:58 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v12]
In-Reply-To: <P001ZgF9r-5vaUu8OUtsz0z4scGSJIbyhog0IcD6kKA=.303310a7-168c-4296-93c3-75e78e28790a@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <gpU93oFx4aeQPyKo0h3L6PWcJHNrYz448j0MQLk3M-E=.52c97e2b-66a5-465a-974f-d1286652c667@github.com>
 <P001ZgF9r-5vaUu8OUtsz0z4scGSJIbyhog0IcD6kKA=.303310a7-168c-4296-93c3-75e78e28790a@github.com>
Message-ID: <243Wy6HTiZ4x4rs2XTl9w6iwwzX0NaEUdEdT9bsrC2E=.5b40b787-35a7-4081-8ad2-e7a62378bef2@github.com>

On Thu, 6 Mar 2025 19:57:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update documentation and unit tests to signal TLS scope case-insensitivity
>
> src/java.base/share/conf/security/java.security line 747:
> 
>> 745: #
>> 746: #     HANDSHAKE restricts algorithm to be used for signing TLS handshake.
>> 747: #     CERTIFICATE restricts algorithm to be used for signatures in certificates.
> 
> s/HANDSHAKE/'Handshake'/
> s/CERTIFICATE/'Certificate'/
> 
> Suggest slight rewording: "Handshake restricts the use of the algorithm in TLS handshake signatures." and "Certificate restricts the use of the algorithm in certificate signatures."

Done.

> src/java.base/share/conf/security/java.security line 748:
> 
>> 746: #     HANDSHAKE restricts algorithm to be used for signing TLS handshake.
>> 747: #     CERTIFICATE restricts algorithm to be used for signatures in certificates.
>> 748: #     These constraints can't be mixed with any other usage constraints for the
> 
> s/can't/cannot/ (sounds more formal).
> 
> The word "any" seems redundant, suggest removing.

Done.

> src/java.base/share/conf/security/java.security line 752:
> 
>> 750: #     ampersand '&'.
>> 751: #     See https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 for more
>> 752: #     information on signatures used in TLS handshake and in certificates.
> 
> I suggest we don't include a reference to the TLS 1.3 RFC. Something like this might be fine for the developer's guide though.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1984007711
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1984007560
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1984007354

From abarashev at openjdk.org  Thu Mar  6 20:36:24 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 6 Mar 2025 20:36:24 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v13]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <2tFC5QQRCMC8SX3fQpoEL2HEz-9VNO6WPo592mtMjm0=.97f982cc-a888-463f-827e-22d00f95adb4@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
> 
> Also fixing JDK-8350807 on the server side just as a side-effect, not a dedicated fix for that issue.

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 15 additional commits since the last revision:

 - Merge branch 'master' into JDK-8349583
 - Remove the fix for JDK-8350807. Update documentation.
 - Update documentation and unit tests to signal TLS scope case-insensitivity
 - Update 2 more copyrights
 - Update TLS version in one more unit test
 - - Check signature schemes that are enabled specifically for the handshake when HANDSHAKE_SCOPE is specified
   - Update copyright
   - Update HTTPS tests that are broken because we also fix JDK-8350807 on the server side as a side-effect
 - Revert "Restore original arguments for getSupportedAlgorithms() calls"
   
   This reverts commit 4b335619ee6a79a6f609fe98c5339588a6a1342a.
 - Restore original arguments for getSupportedAlgorithms() calls
 - - Refactor code to use existing "usage" constraint.
   - Rename SSLCryptoScope to SSLScope, make it public.
 - Merge branch 'master' into JDK-8349583
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8e95f066...7a786e0d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/efb11851..7a786e0d

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

  Stats: 7401 lines in 193 files changed: 3664 ins; 3082 del; 655 mod
  Patch: https://git.openjdk.org/jdk/pull/23681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681

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

From mullan at openjdk.org  Thu Mar  6 21:26:03 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Mar 2025 21:26:03 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v13]
In-Reply-To: <aMNW8W0v2nD1BXxtRvneD3amuM1SviEQXLQj7FDo7To=.a779c943-f51d-468b-9898-563bdb57624b@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <aMNW8W0v2nD1BXxtRvneD3amuM1SviEQXLQj7FDo7To=.a779c943-f51d-468b-9898-563bdb57624b@github.com>
Message-ID: <78FwzmPWUOBKwibbgxwDswWJhxSfuU0Y6VtdgZt4T10=.ac2b9dc2-6fed-4a55-842f-6c114a44e284@github.com>

On Thu, 6 Mar 2025 00:01:17 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc.
>> 
>> <img width="1033" alt="image" src="https://github.com/user-attachments/assets/3b2e0827-899e-4b2d-b588-0abd508abc13" />
>> 
>> 
>> 
>> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8328914: Document the java.security.debug property in javadoc

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 178:

> 176:         <th scope="row"><code>scl</code></th>
> 177:         <td>Permissions that <code>SecureClassLoader</code> assigns</td>
> 178:     </tr>

Please remove the "scl" option. With JEP 486, this option no longer has any value. I have filed a separate bug to have it removed from the code: https://bugs.openjdk.org/browse/JDK-8351366

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1984070083

From kdriver at openjdk.org  Thu Mar  6 21:43:59 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 6 Mar 2025 21:43:59 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v6]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <C0Jd6Eh2Ocu-iTioeAtn2sHJERemhm1xdUKot57YDNc=.9538266e-06cd-4fbc-beb9-193be764744e@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
> 
> **Note**: We cannot (so far) pass whether the verbose flag is set to the class that does this processing. We may want to add a property to the builder for this. As-is, the message will be printed via `System.err` whether verbose is set or not.

Kevin Driver 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:

 - Merge remote-tracking branch 'origin/master' into 8341775
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge branch 'master' of github.com:openjdk/jdk into 8341775
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge branch '8341775' of gh:driverkt/jdk into 8341775
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8341775
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge branch 'master' of github.com:openjdk/jdk into 8341775
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge branch 'master' of github.com:openjdk/jdk into 8341775
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/e39390aa..2b133a31

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

  Stats: 229902 lines in 5423 files changed: 114349 ins; 90681 del; 24872 mod
  Patch: https://git.openjdk.org/jdk/pull/22222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22222/head:pull/22222

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

From mullan at openjdk.org  Thu Mar  6 21:59:05 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Mar 2025 21:59:05 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v13]
In-Reply-To: <2tFC5QQRCMC8SX3fQpoEL2HEz-9VNO6WPo592mtMjm0=.97f982cc-a888-463f-827e-22d00f95adb4@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <2tFC5QQRCMC8SX3fQpoEL2HEz-9VNO6WPo592mtMjm0=.97f982cc-a888-463f-827e-22d00f95adb4@github.com>
Message-ID: <Q_FzSXaw6viPMwNpaxTX4NF3-mc0GBXUATyLlFBsWcU=.861751fd-846e-4f4e-8797-d9e0c4e4b990@github.com>

On Thu, 6 Mar 2025 20:36:24 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8349583
>  - Remove the fix for JDK-8350807. Update documentation.
>  - Update documentation and unit tests to signal TLS scope case-insensitivity
>  - Update 2 more copyrights
>  - Update TLS version in one more unit test
>  - - Check signature schemes that are enabled specifically for the handshake when HANDSHAKE_SCOPE is specified
>    - Update copyright
>    - Update HTTPS tests that are broken because we also fix JDK-8350807 on the server side as a side-effect
>  - Revert "Restore original arguments for getSupportedAlgorithms() calls"
>    
>    This reverts commit 4b335619ee6a79a6f609fe98c5339588a6a1342a.
>  - Restore original arguments for getSupportedAlgorithms() calls
>  - - Refactor code to use existing "usage" constraint.
>    - Rename SSLCryptoScope to SSLScope, make it public.
>  - Merge branch 'master' into JDK-8349583
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3c2b5ff5...7a786e0d

src/java.base/share/classes/sun/security/ssl/SSLScope.java line 28:

> 26: /*
> 27:  * Scopes defining different parts of TLS protocol.
> 28:  */

Can you move the class description below the package?

src/java.base/share/classes/sun/security/ssl/SSLScope.java line 39:

> 37: 
> 38:     // Note: the SSLScope is case-insensitive.
> 39:     public static SSLScope nameOf(String name) {

`valueOf` is probably a better name, and used by other Enum classes for this pattern.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1984099438
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1984106156

From hchao at openjdk.org  Thu Mar  6 22:38:57 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 6 Mar 2025 22:38:57 GMT
Subject: RFR: 8350582: Correct the parsing of the ssl value in
 javax.net.debug [v3]
In-Reply-To: <a85HHwLC05V0ORSzUJhQ7GJQhzpOjewUMQaFzVCvBUM=.bd405a8f-e753-4ef0-9f7c-fbe4dc66bd1b@github.com>
References: <nRKMTCnVVd9RZ0Y7peTyVlxOTmHUFHY7znOXXfX1x7Y=.18357cce-9edb-4544-8ecb-300c04dcf630@github.com>
 <a85HHwLC05V0ORSzUJhQ7GJQhzpOjewUMQaFzVCvBUM=.bd405a8f-e753-4ef0-9f7c-fbe4dc66bd1b@github.com>
Message-ID: <6nMe12VRA8mBXbsInTK2KegwTucnUjCMslO7bpocxdk=.26fa1ee0-8fd6-43ac-803f-f10c335272e1@github.com>

On Thu, 6 Mar 2025 20:10:58 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Breaking the parent JDK-8044609 JBS issue into sub tasks. 
>> 
>> This patch addresses the main issue which is that `javax.net.debug=ssl ` option is completely broken since TLSv1.3 support was introduced.  This patch should be easier for backporting also.
>> 
>> Wider corrections can be followed up via parent bug.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate latest review feedback

Marked as reviewed by hchao (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23781#pullrequestreview-2665786512

From jlu at openjdk.org  Thu Mar  6 22:57:06 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Mar 2025 22:57:06 GMT
Subject: Integrated: 8351223: Update localized resources in keytool and
 jarsigner
In-Reply-To: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
References: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
Message-ID: <o1dmAb_aTnDvLzRCtEeYiWT3PGqUFxMobRX0dbPRDsI=.90a9fa96-3273-4699-979d-0249f4bda8c8@github.com>

On Wed, 5 Mar 2025 00:23:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which provides localization updates for resources in `jarsigner` and `keytool`.
> The key/vals in this PR are updated to match the changes made in the English source files.
> Further context is provided on the JBS issue.

This pull request has now been integrated.

Changeset: 7c9a7840
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c9a7840ea75a9a7df3f240d063e9833f535e6ec
Stats:     75 lines in 6 files changed: 12 ins; 12 del; 51 mod

8351223: Update localized resources in keytool and jarsigner

Reviewed-by: weijun

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

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

From jlu at openjdk.org  Thu Mar  6 22:57:04 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Mar 2025 22:57:04 GMT
Subject: RFR: 8351223: Update localized resources in keytool and jarsigner
In-Reply-To: <H5Ii6i4LtSryVKu62CzGTEU7ZWJ3pO8agC9AXMTn8fc=.a2868d8a-a10c-46ae-98d6-b3c5fbee27ce@github.com>
References: <298QyDwqpnvdMrzONcf3IW9S8uYfVR_6AeCj5F4lwPI=.51b4e918-2646-4144-8485-fdc4973b5947@github.com>
 <Y6B91ntttkoHbiCnD3ND7dHlvhSLevL9B8LiNQHl5Y4=.5c77de4e-887e-4509-a7aa-0b6b8a6e18fb@github.com>
 <H5Ii6i4LtSryVKu62CzGTEU7ZWJ3pO8agC9AXMTn8fc=.a2868d8a-a10c-46ae-98d6-b3c5fbee27ce@github.com>
Message-ID: <4LeUsBSYxeOT3BSz-dauOC9FyTYFchgXGAs9Ds-jTe8=.f0b2879e-d751-47ad-beb6-dfcfdc6fb5e8@github.com>

On Thu, 6 Mar 2025 18:03:25 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>>> Hi @justin-curtis-lu! Just curious how urgent is this change? I'm going to finish the .java -> .properties conversion draft soon and then you can modify the properties files in plain UTF-8 text: #22774
>> 
>> We want to get this into `24.0.2` . I think it would be preferable to get this change in now, as review has already been completed. Any updates for these files that occur in the next L10n update can be reviewed under the properties format as UTF-8 native. But please let me know otherwise.
>
>> > Hi @justin-curtis-lu! Just curious how urgent is this change? I'm going to finish the .java -> .properties conversion draft soon and then you can modify the properties files in plain UTF-8 text: #22774
>> 
>> We want to get this into `24.0.2` . I think it would be preferable to get this change in now, as review has already been completed. Any updates for these files that occur in the next L10n update can be reviewed under the properties format as UTF-8 native. But please let me know otherwise.
> 
> The thing is that my draft is pretty much ready and it's converting the same Resources files that you are modifying here. So if it's urgent I'll wait until you integrate this PR and then re-convert the files being changed.

@artur-oracle and I discussed offline that we will integrate this PR first, then https://github.com/openjdk/jdk/pull/22774.

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

PR Comment: https://git.openjdk.org/jdk/pull/23911#issuecomment-2705120107

From duke at openjdk.org  Thu Mar  6 23:32:17 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 6 Mar 2025 23:32:17 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v14]
In-Reply-To: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
Message-ID: <WQ6rqY6lCrp8LwXGifoFvw8PDpmPcrfTGjhTb4OYP28=.ecbf5b5d-5de8-4aea-85e0-accd3bf7b72f@github.com>

> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc.
> 
> <img width="1033" alt="image" src="https://github.com/user-attachments/assets/3b2e0827-899e-4b2d-b588-0abd508abc13" />
> 
> 
> 
> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page.

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

  8328914: Document the java.security.debug property in javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23569/files
  - new: https://git.openjdk.org/jdk/pull/23569/files/76669c40..a365c04d

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

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

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

From ihse at openjdk.org  Fri Mar  7 12:03:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 12:03:13 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <UZ7o3EbaKrcToWfCY395VnTBwtGPRqTeLVcOqElj1Es=.8ebac174-c9de-4289-a44b-7a05febe252b@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
 <UZ7o3EbaKrcToWfCY395VnTBwtGPRqTeLVcOqElj1Es=.8ebac174-c9de-4289-a44b-7a05febe252b@github.com>
Message-ID: <uTD53V9aGqZELThLytg9BqOOGuuAUnDkoTh5o20AYPc=.621c48f6-78b9-49b4-bbf4-0bef04dc625b@github.com>

On Sat, 11 Mar 2023 16:07:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AccessBridgeJavaEntryPoints.cpp
>
> Oops, didn't mean to do that. Oh well, will update this again later

@TheShermanTanker This seems like a good fix to make VSC++ behave according to standard. I think it should be resurrected.

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706274916

From fguallini at openjdk.org  Fri Mar  7 12:43:34 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Fri, 7 Mar 2025 12:43:34 GMT
Subject: RFR: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version [v6]
In-Reply-To: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
Message-ID: <xs2qyNSu00wFkhLov6Z2c1yL0h4KSzodkiq1BuCgovI=.4fb0558b-b5e0-4114-82d9-bd52d39dc263@github.com>

> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). 
> There are some differences between the 1.1.x and the current OpenSSL version:
> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it.  Additionally, It is also required to specify the path location of the legacy provider.
> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead.

Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:

  based on suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23613/files
  - new: https://git.openjdk.org/jdk/pull/23613/files/ad998433..621e5d9d

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

  Stats: 41 lines in 1 file changed: 21 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/23613.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23613/head:pull/23613

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

From jwaters at openjdk.org  Fri Mar  7 13:46:05 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Mar 2025 13:46:05 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <uTD53V9aGqZELThLytg9BqOOGuuAUnDkoTh5o20AYPc=.621c48f6-78b9-49b4-bbf4-0bef04dc625b@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
 <UZ7o3EbaKrcToWfCY395VnTBwtGPRqTeLVcOqElj1Es=.8ebac174-c9de-4289-a44b-7a05febe252b@github.com>
 <uTD53V9aGqZELThLytg9BqOOGuuAUnDkoTh5o20AYPc=.621c48f6-78b9-49b4-bbf4-0bef04dc625b@github.com>
Message-ID: <rrQ2DSyYQwWJBpRkdqEIIknncKirOCwvPw_9zv9Yjtg=.3ff9dc28-7c13-4c53-b8d2-745caa54b9d7@github.com>

On Fri, 7 Mar 2025 12:00:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Oops, didn't mean to do that. Oh well, will update this again later
>
> @TheShermanTanker This seems like a good fix to make VSC++ behave according to standard. I think it should be resurrected.

@magicus I think this was closed by GitHub itself since I messed up somewhere along the line with switching to a new branch to work on this. I could reopen a new Pull Request, but Daniel's concerns were what prevented me from doing so last time. Also, I think Skara may have a bug, since it seems to think that this closed Pull Request is open now

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706486932

From mdonovan at openjdk.org  Fri Mar  7 15:04:52 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 7 Mar 2025 15:04:52 GMT
Subject: RFR: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version [v6]
In-Reply-To: <xs2qyNSu00wFkhLov6Z2c1yL0h4KSzodkiq1BuCgovI=.4fb0558b-b5e0-4114-82d9-bd52d39dc263@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
 <xs2qyNSu00wFkhLov6Z2c1yL0h4KSzodkiq1BuCgovI=.4fb0558b-b5e0-4114-82d9-bd52d39dc263@github.com>
Message-ID: <7tw1dV4gxjYaSPKJpXrfD-vyG88DHVnOOc7k2t17UUk=.0083cdd0-8c8f-49bd-ae45-d15c38d49f97@github.com>

On Fri, 7 Mar 2025 12:43:34 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). 
>> There are some differences between the 1.1.x and the current OpenSSL version:
>> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it.  Additionally, It is also required to specify the path location of the legacy provider.
>> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   based on suggestions

Looks good to me, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23613#issuecomment-2706672889

From ihse at openjdk.org  Fri Mar  7 15:14:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 15:14:09 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
Message-ID: <ISPINGcBTcDkUB1ZkQMGtrGKCHS5hQqtyLV-PqXoamk=.87c840b9-ca27-466e-9cb6-888f19c2d153@github.com>

On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Was: sunmscapi.dll cannot compile with Visual C++
>> 
>> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AccessBridgeJavaEntryPoints.cpp

So, Daniel pointed out some irrelevant changes that you tried to sneak in. :) I think he is right that these should be reverted. I don't see anyone complaining about removing `-Zc:wchar_t-` though, or the necessary follow-up fixes for this. 

But this PR has indeed gotten a bit messy, so it's maybe better to open a new and just bring over the relevant fixes.

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706696288

From jwaters at openjdk.org  Fri Mar  7 15:17:19 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 7 Mar 2025 15:17:19 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <ISPINGcBTcDkUB1ZkQMGtrGKCHS5hQqtyLV-PqXoamk=.87c840b9-ca27-466e-9cb6-888f19c2d153@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
 <ISPINGcBTcDkUB1ZkQMGtrGKCHS5hQqtyLV-PqXoamk=.87c840b9-ca27-466e-9cb6-888f19c2d153@github.com>
Message-ID: <nnvJxJ9574F8HwX9bL-K5cnCiKdnwEhj8-sejQNK5Ho=.59a3e194-eb54-4ede-b9d7-e2d37f38c6ec@github.com>

On Fri, 7 Mar 2025 15:11:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> So, Daniel pointed out some irrelevant changes that you tried to sneak in. :) I think he is right that these should be reverted. I don't see anyone complaining about removing `-Zc:wchar_t-` though, or the necessary follow-up fixes for this.
> 
> But this PR has indeed gotten a bit messy, so it's maybe better to open a new and just bring over the relevant fixes.

I don't think Daniel's concerns stopped at the irrelevant changes though. I recall he was worried about removing the switch causing everywhere a jchar is passed to a WINAPI method needing a reinterpret cast, which is dangerous. I still don't know if that concern has been addressed yet

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706705837

From djelinski at openjdk.org  Fri Mar  7 15:27:08 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Mar 2025 15:27:08 GMT
Subject: RFR: 8303764: Enable -Zc:wchar_t for Visual C++ [v5]
In-Reply-To: <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
References: <I8BVTQZF4eG9l9UKghzEjm9O97byW3XPL-6C_UV_mkM=.24caf5fc-502f-4768-a56f-a8f740fa0c3e@github.com>
 <nufclII2qixlkNk8K6srN0x8rEhYjh0ugVU0OCJZfP4=.793a60c2-9f85-4dc8-b865-d2a5d2e15e89@github.com>
Message-ID: <7kBnYGrIMJOk_HHsxrFqkVus4rLt0DkWRLsHyAsMmps=.55561218-81fe-4d28-9ef0-39f837ab84e6@github.com>

On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Was: sunmscapi.dll cannot compile with Visual C++
>> 
>> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a distinct C++ type when compiling with Visual C++ so jchar and wchar_t are typedef'd to shorts on Windows. After some examination it appears this flag is not actually needed for almost every source file that we have, barring security.cpp, so we could try to remove it and make Windows code behave more like regular C++, since casting between wchar_t and jchar does not appear to happen very often (only appearing in one file!). wchar_t in Standard C is a typedef and is never affected by this flag, and if `-Zc:wchar_t` is enabled for C code, it is simply ignored
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AccessBridgeJavaEntryPoints.cpp

If the changes in this PR are all that is required to enable the option, I think we can live with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/12907#issuecomment-2706727799

From weijun at openjdk.org  Fri Mar  7 15:48:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Mar 2025 15:48:58 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v9]
In-Reply-To: <n3Zt2cUVWce7sLDl51aPeGWrL0TROx4RknPb29EBna4=.35508b82-1b62-4ea0-89b8-1835a3c68f10@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <u9UswQ9Imkd5x9DVBDyDsruqOrC9ZZxr6Yl9uINi55k=.a698190e-fd1a-4064-8b67-757102523c58@github.com>
 <6ThXIled5v2oPqFKndDzxjXw0GOptsX7fVWex2anyvw=.3340328f-0d74-4c5f-b28b-744bf0c5f4a7@github.com>
 <n3Zt2cUVWce7sLDl51aPeGWrL0TROx4RknPb29EBna4=.35508b82-1b62-4ea0-89b8-1835a3c68f10@github.com>
Message-ID: <6QG_vBJ1MeDnEeXc5NMAohP3USqA_RAghbpA2FiVgWI=.86cdcc62-7e15-4f14-83ce-e81d9e3e5cd5@github.com>

On Tue, 25 Feb 2025 19:37:54 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 68:
>> 
>>> 66:     system property to print additional information:
>>> 67: <ul>
>>> 68:     <li><code>+thread:</code>Print thread and caller information</li>
>> 
>> Put `:` outside `<code>`.
>> 
>> Hi @coffeys and @seanjmullan, now that we have a formal format for options and sub-options, shall we have one for these modifiers? Should it always be appended after the sub-option(s)? Like
>> 
>> x509:ava+thread,certpath:ocsp,verbose+timestamp+thread
>> 
>> On the other hand, I'm a little suspicious on the line above. If there is a comma between `oscp` and `verbose`, will it break away from `certpath`? Will `+timestamp` and `+thread` only apply to the `verbose` sub-option?
>> 
>> Also, how do we specify multiple engines in `provider`? Should it look like this?
>> 
>> provider:engine=Cipher,Mac
>> 
>> 
>> While this PR is about the doc, I really think we need a test to ensure the format is correctly described.
>
> I'd probably have to point to the CSR that introduced the +thread, +timestamp options :
> https://bugs.openjdk.org/browse/JDK-8327569
> 
> The "+" symbol should directly follow a valid debug option to be legitimate IMO. It's probably the most intuitive assumption also. 
> 
> note that I'd like to switch on `timestamp `and `thread `options by default in a JDK feature release (maybe JDK 25)
> They made more sense for the backport (JDK Update) release lines where addition of such meta data might have caused issue for some frameworks parsing this data.
> 
> I just logged https://bugs.openjdk.org/browse/JDK-8350689 to track that effort.

Anyone still cares about this comment?

I've tried `-Djava.security.debug=certpath:ocsp,verbose+timestamp` (which follows the grammar in this PR) and there is no timestamp shown. Obviously, it's broken into `certpath:ocsp` and `verbose+timestamp` at https://github.com/openjdk/jdk/blob/940aa7c4cf1bf770690660c8bb21fb3ddc5186e4/src/java.base/share/classes/sun/security/util/Debug.java#L192 and the `+timestamp` modifier is not applied to the `certpath` option.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1985290873

From abarashev at openjdk.org  Fri Mar  7 15:50:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Mar 2025 15:50:58 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v13]
In-Reply-To: <Q_FzSXaw6viPMwNpaxTX4NF3-mc0GBXUATyLlFBsWcU=.861751fd-846e-4f4e-8797-d9e0c4e4b990@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <2tFC5QQRCMC8SX3fQpoEL2HEz-9VNO6WPo592mtMjm0=.97f982cc-a888-463f-827e-22d00f95adb4@github.com>
 <Q_FzSXaw6viPMwNpaxTX4NF3-mc0GBXUATyLlFBsWcU=.861751fd-846e-4f4e-8797-d9e0c4e4b990@github.com>
Message-ID: <mu0C1OqUIQxmE1-VBBYguu4pnRnqz-l_tz-JGc9KhOs=.f87ace28-e08c-4bc2-a791-1e403e9adb0c@github.com>

On Thu, 6 Mar 2025 21:49:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> 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 15 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8349583
>>  - Remove the fix for JDK-8350807. Update documentation.
>>  - Update documentation and unit tests to signal TLS scope case-insensitivity
>>  - Update 2 more copyrights
>>  - Update TLS version in one more unit test
>>  - - Check signature schemes that are enabled specifically for the handshake when HANDSHAKE_SCOPE is specified
>>    - Update copyright
>>    - Update HTTPS tests that are broken because we also fix JDK-8350807 on the server side as a side-effect
>>  - Revert "Restore original arguments for getSupportedAlgorithms() calls"
>>    
>>    This reverts commit 4b335619ee6a79a6f609fe98c5339588a6a1342a.
>>  - Restore original arguments for getSupportedAlgorithms() calls
>>  - - Refactor code to use existing "usage" constraint.
>>    - Rename SSLCryptoScope to SSLScope, make it public.
>>  - Merge branch 'master' into JDK-8349583
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3466582c...7a786e0d
>
> src/java.base/share/classes/sun/security/ssl/SSLScope.java line 28:
> 
>> 26: /*
>> 27:  * Scopes defining different parts of TLS protocol.
>> 28:  */
> 
> Can you move the class description below the package?

Done.

> src/java.base/share/classes/sun/security/ssl/SSLScope.java line 39:
> 
>> 37: 
>> 38:     // Note: the SSLScope is case-insensitive.
>> 39:     public static SSLScope nameOf(String name) {
> 
> `valueOf` is probably a better name, and used by other Enum classes for this pattern.

Actually I couldn't find a single example of using `valueOf` with String argument in `sun/security/ssl`, while there are plenty of example of using `nameOf`. So I just followed the established convention:

src/java.base/share/classes/sun/security/ssl/SSLScope.java:39:
src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java:214: 
src/java.base/share/classes/sun/security/ssl/CipherSuite.java:925: 
src/java.base/share/classes/sun/security/ssl/NamedGroup.java:352:
src/java.base/share/classes/sun/security/ssl/SignatureScheme.java:349:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1985293588
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1985290573

From abarashev at openjdk.org  Fri Mar  7 16:31:33 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Mar 2025 16:31:33 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v14]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <LSV96eSyxH-Jjdh7WBlGK8w5K4Skr3GWhJp9-PuPyE0=.deb56e53-d089-43a4-bfaf-1065dc5cd914@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Move SSLScope class description below the package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/7a786e0d..0c8d6d81

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

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

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

From ascarpino at openjdk.org  Fri Mar  7 17:16:59 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 7 Mar 2025 17:16:59 GMT
Subject: Integrated: 8348309: MultiNST tests need more debugging and timing
In-Reply-To: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com>
References: <-SNNdU9KtV9MuxiM9j52OrCHjbdMdIbS8F-Brmx6a6U=.b2979544-a90a-4630-b822-1af9d8ef264e@github.com>
Message-ID: <SHerlnjZJghjl25m05nE1Fjj4DnvryZeLKAWbzxo-eI=.27347e1e-21e2-4ab2-a651-13dff4ffbf85@github.com>

On Sat, 1 Feb 2025 04:20:36 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> I need a review of this change that adds new timing controls for the initial server setup.  On rare occasions, more so on certain architectures, the server may not fully start before the client tries to connect.  Additional debugging is added to help identify if there are other timing issues.
> 
> Thanks
> 
> Tony

This pull request has now been integrated.

Changeset: 5cd4fe63
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cd4fe63768715ec7be32e248e05e611ea9b557d
Stats:     68 lines in 5 files changed: 19 ins; 12 del; 37 mod

8348309: MultiNST tests need more debugging and timing

Reviewed-by: hchao, mullan

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

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

From mullan at openjdk.org  Fri Mar  7 17:22:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Mar 2025 17:22:55 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v9]
In-Reply-To: <6QG_vBJ1MeDnEeXc5NMAohP3USqA_RAghbpA2FiVgWI=.86cdcc62-7e15-4f14-83ce-e81d9e3e5cd5@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <u9UswQ9Imkd5x9DVBDyDsruqOrC9ZZxr6Yl9uINi55k=.a698190e-fd1a-4064-8b67-757102523c58@github.com>
 <6ThXIled5v2oPqFKndDzxjXw0GOptsX7fVWex2anyvw=.3340328f-0d74-4c5f-b28b-744bf0c5f4a7@github.com>
 <n3Zt2cUVWce7sLDl51aPeGWrL0TROx4RknPb29EBna4=.35508b82-1b62-4ea0-89b8-1835a3c68f10@github.com>
 <6QG_vBJ1MeDnEeXc5NMAohP3USqA_RAghbpA2FiVgWI=.86cdcc62-7e15-4f14-83ce-e81d9e3e5cd5@github.com>
Message-ID: <WLk_VsCZK4ioqVZEX5anVmdifLduALPQcM6Kvv0ocd0=.c42a606a-d1ac-4804-a960-6472ca09377a@github.com>

On Fri, 7 Mar 2025 15:46:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I'd probably have to point to the CSR that introduced the +thread, +timestamp options :
>> https://bugs.openjdk.org/browse/JDK-8327569
>> 
>> The "+" symbol should directly follow a valid debug option to be legitimate IMO. It's probably the most intuitive assumption also. 
>> 
>> note that I'd like to switch on `timestamp `and `thread `options by default in a JDK feature release (maybe JDK 25)
>> They made more sense for the backport (JDK Update) release lines where addition of such meta data might have caused issue for some frameworks parsing this data.
>> 
>> I just logged https://bugs.openjdk.org/browse/JDK-8350689 to track that effort.
>
> Anyone still cares about this comment?
> 
> I've tried `-Djava.security.debug=certpath:ocsp,verbose+timestamp` (which follows the grammar in this PR) and there is no timestamp shown. Obviously, it's broken into `certpath:ocsp` and `verbose+timestamp` at https://github.com/openjdk/jdk/blob/940aa7c4cf1bf770690660c8bb21fb3ddc5186e4/src/java.base/share/classes/sun/security/util/Debug.java#L192 and the `+timestamp` modifier is not applied to the `certpath` option.

I think we should look into it. I think we can handle this as a follow-on bug so that we keep this issue just about the docs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1985427298

From mullan at openjdk.org  Fri Mar  7 18:15:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Mar 2025 18:15:54 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v13]
In-Reply-To: <mu0C1OqUIQxmE1-VBBYguu4pnRnqz-l_tz-JGc9KhOs=.f87ace28-e08c-4bc2-a791-1e403e9adb0c@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <2tFC5QQRCMC8SX3fQpoEL2HEz-9VNO6WPo592mtMjm0=.97f982cc-a888-463f-827e-22d00f95adb4@github.com>
 <Q_FzSXaw6viPMwNpaxTX4NF3-mc0GBXUATyLlFBsWcU=.861751fd-846e-4f4e-8797-d9e0c4e4b990@github.com>
 <mu0C1OqUIQxmE1-VBBYguu4pnRnqz-l_tz-JGc9KhOs=.f87ace28-e08c-4bc2-a791-1e403e9adb0c@github.com>
Message-ID: <53q32kYL1VdvaPlqTwLHFIvN4wv9uytWgNZxUAf2bGQ=.4f8c2a41-aefd-4453-8e31-83369b34efc6@github.com>

On Fri, 7 Mar 2025 15:46:05 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLScope.java line 39:
>> 
>>> 37: 
>>> 38:     // Note: the SSLScope is case-insensitive.
>>> 39:     public static SSLScope nameOf(String name) {
>> 
>> `valueOf` is probably a better name, and used by other Enum classes for this pattern.
>
> Actually I couldn't find a single example of using `valueOf` with String argument in `sun/security/ssl`, while there are plenty of examples of using `nameOf`. So I just followed the established convention:
> 
> src/java.base/share/classes/sun/security/ssl/SSLScope.java:39:
> src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java:214: 
> src/java.base/share/classes/sun/security/ssl/CipherSuite.java:925: 
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java:352:
> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java:349:

Sure, that's fine. I was thinking that the name was more consistent with the `Enum.valuesOf` method. But these are names or types rather than values, and this class is internal, so we don't have to follow that convention.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1985488104

From valeriep at openjdk.org  Fri Mar  7 18:36:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 7 Mar 2025 18:36:52 GMT
Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with
 TLS1.2 TlsKeyMaterialParameterSpec
In-Reply-To: <JeXFl3kGqy_SRIdQ-GeWtlCXCQ19OE-yPW13XDIWbfs=.e891c0c9-5339-4bc0-a2fa-cfb20b29d5ae@github.com>
References: <JeXFl3kGqy_SRIdQ-GeWtlCXCQ19OE-yPW13XDIWbfs=.e891c0c9-5339-4bc0-a2fa-cfb20b29d5ae@github.com>
Message-ID: <uRJsT2sSMJ2Xlc-ZPGqBbrRbbY2xjhPRhfI2NWlsxMo=.198b5ab2-9a2a-4bfd-8f97-009482639705@github.com>

On Wed, 12 Feb 2025 10:02:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this trivial fix that ensures that the mechanism always matches the parameter class type.
> 
> I added a new test case that crashes without the fix, passes with the fix. Existing tier1-3 test cases continue to pass.

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23583#pullrequestreview-2668039112

From valeriep at openjdk.org  Fri Mar  7 18:36:53 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 7 Mar 2025 18:36:53 GMT
Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with
 TLS1.2 TlsKeyMaterialParameterSpec
In-Reply-To: <_jv-TAFGqtsNnCQovDjKJVc1g-kfJ-MJY4Aw1cmEpVE=.9b4cb54f-8abc-44db-9ed1-d872205b3fab@github.com>
References: <JeXFl3kGqy_SRIdQ-GeWtlCXCQ19OE-yPW13XDIWbfs=.e891c0c9-5339-4bc0-a2fa-cfb20b29d5ae@github.com>
 <oU2oame11_eweZnk0uGYPApXLK75DAAexzRubUavSM0=.f5d3b8d3-ac35-49f0-a7cd-b6c3dc84f358@github.com>
 <WV8Et72tq_yoMqI6itPoGwTnhKpv_O1GNkxN18N8-Ak=.816aae1b-6ba2-40c8-9063-036081c9f614@github.com>
 <0Cnl_2GC5sPNo5SUTyI0ziEC7tQ44LvYwSXkOthntnI=.692670c4-12ad-4d83-87ba-b443221b35c0@github.com>
 <DDVArpxG5pdXJxohLkC-2iSCKKkMFNLgsBRugdH__W0=.266b0d22-fa3a-4d52-9da9-aafbe600a8e8@github.com>
 <U-SsKQo84Oqxv28MIre6Kjw8mGTXCl9G4EYmqsPZG5o=.a64d1920-4ee0-48ee-bfda-c933850789e0@github.com>
 <_jv-TAFGqtsNnCQovDjKJVc1g-kfJ-MJY4Aw1cmEpVE=.9b4cb54f-8abc-44db-9ed1-d872205b3fab@github.com>
Message-ID: <yaYNZONqU3wNhX80WrRoqWzp2A-72aCz9fDSEg1BJus=.1bc53920-a854-46dd-8bc1-e9bd54b61955@github.com>

On Mon, 24 Feb 2025 16:51:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I'd like to clarify the usage of `SunTlsKeyMaterial` and `SunTls12KeyMaterial` KGs first.
>> 
>> Is `SunTlsKeyMaterial` KG expected to handle specs indicating TLS1.2 version?
>> Is `SunTls12KeyMaterial` KeyGenerator expected to handle specs indicating SSL3.0 version?
>> 
>> Looking at SunJCE provider's impls, `SunTlsKeyMaterial` and `SunTls12KeyMaterial` KGs are considered equivalent, e.g. one being the alias of the other. SunPKCS11 provider defines them separately mapping to different native mechs, however sharing the same impl class. Looking at the current code, it seems that `SunTls12KeyMaterial` will always set `supportSSLv3` to false which should reject specs indicating SSL3.0 version. 
>> 
>> There seems to be an inconsistency between SunJCE provider and SunPKCS11 provider?
>> 
>> In addition, we should check that the particular mechanism is supported?
>
> `SunTls12KeyMaterial` is only expected to handle TLS 1.2, and `SunTlsKeyMaterial` is only expected to handle earlier versions (SSL 3.0, TLS 1.0, and TLS 1.1), at least that's how they are used by SunJSSE. 
> 
> The implementation does not verify that the KG name matches the TLS version provided in the algorithm parameters, which in one case can lead to a crash. We could add code to perform that verification instead, but that would involve more code than the fix I proposed.
> 
> `KeyGenerator.getInstance` verifies that at the necessary mechanisms are present. If incorrect TLS version is used, we may get a ProviderException if the mechanism corresponding to the selected TLS version is unavailable.

I see, thanks for the clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23583#discussion_r1985520635

From mullan at openjdk.org  Fri Mar  7 18:51:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Mar 2025 18:51:56 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v14]
In-Reply-To: <LSV96eSyxH-Jjdh7WBlGK8w5K4Skr3GWhJp9-PuPyE0=.deb56e53-d089-43a4-bfaf-1065dc5cd914@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <LSV96eSyxH-Jjdh7WBlGK8w5K4Skr3GWhJp9-PuPyE0=.deb56e53-d089-43a4-bfaf-1065dc5cd914@github.com>
Message-ID: <Ymzw8oHKd3fKRqJm7_sImXpbkc56sLwhDcerhmGAD1U=.f6d6a368-afcd-4587-8f6d-5e6ccf171429@github.com>

On Fri, 7 Mar 2025 16:31:33 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move SSLScope class description below the package

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

> 745: #
> 746: #     Handshake restricts the use of the algorithm in TLS handshake signatures.
> 747: #     Certificate restricts the use of the algorithm in certificate signatures.

I think we should repeat this sentence from the "UsageConstraint" definition in the `jdk.certpath.disabledAlgorithms` property: "The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter."

(This will also help address Joe's comment on the CSR).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1985540008

From weijun at openjdk.org  Fri Mar  7 19:10:55 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Mar 2025 19:10:55 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v4]
In-Reply-To: <c5KF8wFufjEbuAeFj2Mpc7M60j8jTyns-XP5iY8K194=.283efa1e-f662-4592-b1ba-0ea25a6c0bfb@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <c5KF8wFufjEbuAeFj2Mpc7M60j8jTyns-XP5iY8K194=.283efa1e-f662-4592-b1ba-0ea25a6c0bfb@github.com>
Message-ID: <Z0-G2-rRsTESI2O9BOQHsAXjeVIloZ4T3--0dkm2EiU=.b5b1f7e1-6e8e-4a8b-82d1-ae6c7c09d996@github.com>

On Wed, 5 Mar 2025 20:20:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename getNamedCurveFromKey

src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 274:

> 272:                     yield List.of();
> 273:                 }
> 274:                 yield List.of(nc.getNameAndAliases());

Do you want to add `EC` itself to the list? I am asking because for EdDSA you added both the algorithm name and the parameter set name.

src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 276:

> 274:                 yield List.of(nc.getNameAndAliases());
> 275:             }
> 276:             default -> List.of(key.getAlgorithm(), KeyUtil.getAlgorithm(key));

What if these 2 are the same string?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1985559677
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1985560326

From weijun at openjdk.org  Fri Mar  7 19:20:55 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Mar 2025 19:20:55 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v4]
In-Reply-To: <c5KF8wFufjEbuAeFj2Mpc7M60j8jTyns-XP5iY8K194=.283efa1e-f662-4592-b1ba-0ea25a6c0bfb@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <c5KF8wFufjEbuAeFj2Mpc7M60j8jTyns-XP5iY8K194=.283efa1e-f662-4592-b1ba-0ea25a6c0bfb@github.com>
Message-ID: <4j-bCihvB7dGYkbGdKaCR3jLbm53Br_JxJS2ISvpr0I=.8407668f-c25d-4d06-ad0c-0218c3913363@github.com>

On Wed, 5 Mar 2025 20:20:10 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename getNamedCurveFromKey

test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 86:

> 84:                 Arrays.asList(
> 85:                     new TestCase("EdDSA", false),
> 86:                     new TestCase("Ed25519", true),

Why should the above pass? If you disable `EdDSA` and you are still allowed `Signature.getInstance("Ed25519")`? If this is because it will reject whatever EdDSA key later? Why both check `CryptoPrimitive.SIGNATURE` at all?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1985568746

From weijun at openjdk.org  Fri Mar  7 19:27:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Mar 2025 19:27:58 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v14]
In-Reply-To: <WQ6rqY6lCrp8LwXGifoFvw8PDpmPcrfTGjhTb4OYP28=.ecbf5b5d-5de8-4aea-85e0-accd3bf7b72f@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <WQ6rqY6lCrp8LwXGifoFvw8PDpmPcrfTGjhTb4OYP28=.ecbf5b5d-5de8-4aea-85e0-accd3bf7b72f@github.com>
Message-ID: <RajxbPSgcatXKx-XR7vZNAL4_x7flOaR9uOK7BItOXA=.386aeac3-f721-468d-89b1-8cbe15794a5a@github.com>

On Thu, 6 Mar 2025 23:32:17 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc.
>> 
>> <img width="1034" alt="image" src="https://github.com/user-attachments/assets/657bcbd8-f5dd-4f6a-bd9f-8b6daa254573" />
>> 
>> 
>> 
>> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8328914: Document the java.security.debug property in javadoc

src/java.base/share/classes/java/security/doc-files/security-related-system-properties.html line 59:

> 57:     execution. The value of the property is one or more options separated by a
> 58:     comma. Some options also have additional sub-options. Sub-options are
> 59:     specified by appending a ":" to the option, followed by a list of one more

s/one more/one or more/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1985578974

From weijun at openjdk.org  Fri Mar  7 19:27:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Mar 2025 19:27:58 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v9]
In-Reply-To: <WLk_VsCZK4ioqVZEX5anVmdifLduALPQcM6Kvv0ocd0=.c42a606a-d1ac-4804-a960-6472ca09377a@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <u9UswQ9Imkd5x9DVBDyDsruqOrC9ZZxr6Yl9uINi55k=.a698190e-fd1a-4064-8b67-757102523c58@github.com>
 <6ThXIled5v2oPqFKndDzxjXw0GOptsX7fVWex2anyvw=.3340328f-0d74-4c5f-b28b-744bf0c5f4a7@github.com>
 <n3Zt2cUVWce7sLDl51aPeGWrL0TROx4RknPb29EBna4=.35508b82-1b62-4ea0-89b8-1835a3c68f10@github.com>
 <6QG_vBJ1MeDnEeXc5NMAohP3USqA_RAghbpA2FiVgWI=.86cdcc62-7e15-4f14-83ce-e81d9e3e5cd5@github.com>
 <WLk_VsCZK4ioqVZEX5anVmdifLduALPQcM6Kvv0ocd0=.c42a606a-d1ac-4804-a960-6472ca09377a@github.com>
Message-ID: <nMIjlfa058-6JvjMxC4qUfc0HrD3uIPOnFZBz_Peoig=.a86b8be6-0e9a-472e-aa1c-1d8c645c31d6@github.com>

On Fri, 7 Mar 2025 17:19:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Anyone still cares about this comment?
>> 
>> I've tried `-Djava.security.debug=certpath:ocsp,verbose+timestamp` (which follows the grammar in this PR) and there is no timestamp shown. Obviously, it's broken into `certpath:ocsp` and `verbose+timestamp` at https://github.com/openjdk/jdk/blob/940aa7c4cf1bf770690660c8bb21fb3ddc5186e4/src/java.base/share/classes/sun/security/util/Debug.java#L192 and the `+timestamp` modifier is not applied to the `certpath` option.
>
> I think we should look into it. I think we can handle this as a follow-on bug so that we keep this issue just about the docs.

I?m not suggesting any source changes, but this documentation update explicitly states:
> Sub-options are specified by appending a ":" to the option, followed by a list of one more sub-options separated by a comma.

This breaks existing usages. In fact, unless (as Se?n C suggested) we drop the 2 modifiers entirely and make them always on, I don?t see a good way to fix it later if we keep the current grammar.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1985576977

From abarashev at openjdk.org  Fri Mar  7 19:31:27 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Mar 2025 19:31:27 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes to
 properties files
Message-ID: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>

These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.

./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
./src/java.base/share/classes/sun/security/util/Resources.java
./src/java.base/share/classes/sun/security/util/AuthResources.java
./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

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

Commit messages:
 - - Remove all the Resources files and MigrationCheck unit test
 - Update translations after merging with master branch
 - Merge branch 'master' into JDK-8345940
 - Merge branch 'master' into JDK-8345940
 - The rest of Jarsigner translations
 - Jarsigner initial setup
 - Remove keytool zh_HK properties because it's being replaced with zh_TW internally
 - We copy keytool_zh_TW.java to keytool_zh_HK.java internally after we compile the properties files
 - Uncomment key
 - The rest of keytool translations
 - ... and 16 more: https://git.openjdk.org/jdk/compare/5cd4fe63...98e3c810

Changes: https://git.openjdk.org/jdk/pull/22774/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345940
  Stats: 16240 lines in 79 files changed: 6060 ins; 10165 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/22774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22774/head:pull/22774

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

From abarashev at openjdk.org  Fri Mar  7 19:31:27 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Mar 2025 19:31:27 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <WsH6xQw86539E7MQzpwljxrf-1VTYGGDEnzfoJWfWXQ=.a763378c-e3ce-4d84-85d0-0d5d4efa6d65@github.com>

On Mon, 16 Dec 2024 22:03:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

Work in progress, low priority.

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

PR Comment: https://git.openjdk.org/jdk/pull/22774#issuecomment-2650525455

From mullan at openjdk.org  Fri Mar  7 19:34:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Mar 2025 19:34:00 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v9]
In-Reply-To: <nMIjlfa058-6JvjMxC4qUfc0HrD3uIPOnFZBz_Peoig=.a86b8be6-0e9a-472e-aa1c-1d8c645c31d6@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <u9UswQ9Imkd5x9DVBDyDsruqOrC9ZZxr6Yl9uINi55k=.a698190e-fd1a-4064-8b67-757102523c58@github.com>
 <6ThXIled5v2oPqFKndDzxjXw0GOptsX7fVWex2anyvw=.3340328f-0d74-4c5f-b28b-744bf0c5f4a7@github.com>
 <n3Zt2cUVWce7sLDl51aPeGWrL0TROx4RknPb29EBna4=.35508b82-1b62-4ea0-89b8-1835a3c68f10@github.com>
 <6QG_vBJ1MeDnEeXc5NMAohP3USqA_RAghbpA2FiVgWI=.86cdcc62-7e15-4f14-83ce-e81d9e3e5cd5@github.com>
 <WLk_VsCZK4ioqVZEX5anVmdifLduALPQcM6Kvv0ocd0=.c42a606a-d1ac-4804-a960-6472ca09377a@github.com>
 <nMIjlfa058-6JvjMxC4qUfc0HrD3uIPOnFZBz_Peoig=.a86b8be6-0e9a-472e-aa1c-1d8c645c31d6@github.com>
Message-ID: <iW5HP3NC-f3zEGixysL2yyhNERSnRKq0mznO91D3H60=.7c5b24ad-7d45-4df7-b0ce-0a8dfc1b3630@github.com>

On Fri, 7 Mar 2025 19:23:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I think we should look into it. I think we can handle this as a follow-on bug so that we keep this issue just about the docs.
>
> I?m not suggesting any source changes, but this documentation update explicitly states:
>> Sub-options are specified by appending a ":" to the option, followed by a list of one more sub-options separated by a comma.
> 
> This breaks existing usages. In fact, unless (as Se?n C suggested) we drop the 2 modifiers entirely and make them always on, I don?t see a good way to fix it later if we keep the current grammar. For example, we might have to hardcode what are options and what are sub-options, so that we can detect that `verbose` here is a sub-option of `certpath` and the comma before it is ignored in the 1st round of string splitting. This would add significant complexity.

Well we are dealing with a syntax that was never specified and is very loosely defined. Either we remove some of the syntax and leave it undefined, or we make sure the syntax works and add more constraints or delimiters, which could break existing usages. But I'm also not sure how much we need to really accommodate corner cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1985585511

From abarashev at openjdk.org  Fri Mar  7 19:39:17 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Mar 2025 19:39:17 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v2]
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <5NVodrAh6KMLB7uz5PSAo1AwPE4YBr-fRhKKy0-R08Q=.a272deb1-8e3a-4299-a64e-67a3378d5415@github.com>

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Restore ResourcesMgr.java deleted by mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22774/files
  - new: https://git.openjdk.org/jdk/pull/22774/files/98e3c810..15c4b64e

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

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

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

From mullan at openjdk.org  Fri Mar  7 19:42:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Mar 2025 19:42:55 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v9]
In-Reply-To: <iW5HP3NC-f3zEGixysL2yyhNERSnRKq0mznO91D3H60=.7c5b24ad-7d45-4df7-b0ce-0a8dfc1b3630@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
 <u9UswQ9Imkd5x9DVBDyDsruqOrC9ZZxr6Yl9uINi55k=.a698190e-fd1a-4064-8b67-757102523c58@github.com>
 <6ThXIled5v2oPqFKndDzxjXw0GOptsX7fVWex2anyvw=.3340328f-0d74-4c5f-b28b-744bf0c5f4a7@github.com>
 <n3Zt2cUVWce7sLDl51aPeGWrL0TROx4RknPb29EBna4=.35508b82-1b62-4ea0-89b8-1835a3c68f10@github.com>
 <6QG_vBJ1MeDnEeXc5NMAohP3USqA_RAghbpA2FiVgWI=.86cdcc62-7e15-4f14-83ce-e81d9e3e5cd5@github.com>
 <WLk_VsCZK4ioqVZEX5anVmdifLduALPQcM6Kvv0ocd0=.c42a606a-d1ac-4804-a960-6472ca09377a@github.com>
 <nMIjlfa058-6JvjMxC4qUfc0HrD3uIPOnFZBz_Peoig=.a86b8be6-0e9a-472e-aa1c-1d8c645c31d6@github.com>
 <iW5HP3NC-f3zEGixysL2yyhNERSnRKq0mznO91D3H60=.7c5b24ad-7d45-4df7-b0ce-0a8dfc1b3630@github.com>
Message-ID: <BOadpHg_VBO7SIElu2H3e3zwqgghaorCOcUXHmshLXw=.87dff66a-314e-41a8-87af-10f1f37c1dbf@github.com>

On Fri, 7 Mar 2025 19:31:47 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I?m not suggesting any source changes, but this documentation update explicitly states:
>>> Sub-options are specified by appending a ":" to the option, followed by a list of one more sub-options separated by a comma.
>> 
>> This breaks existing usages. In fact, unless (as Se?n C suggested) we drop the 2 modifiers entirely and make them always on, I don?t see a good way to fix it later if we keep the current grammar. For example, we might have to hardcode what are options and what are sub-options, so that we can detect that `verbose` here is a sub-option of `certpath` and the comma before it is ignored in the 1st round of string splitting. This would add significant complexity.
>
> Well we are dealing with a syntax that was never specified and is very loosely defined. Either we remove some of the syntax and leave it undefined, or we make sure the syntax works and add more constraints or delimiters, which could break existing usages. But I'm also not sure how much we need to really accommodate corner cases.

I don't see any way to specify the syntax of sub-options without also causing the issue in your example above and preserving compatibility. I think we would need to break compatibility. Maybe something like: 

-Djava.security.debug=certpath+timestamp[ocsp,verbose]

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23569#discussion_r1985594440

From abarashev at openjdk.org  Fri Mar  7 20:17:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Mar 2025 20:17:08 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v3]
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <Sfc0O104kvWboe7GrEobTlXKxskR6ZJQSETSEDZVvZk=.0e003c33-42a8-49a4-9c7a-8fffb4e9cd37@github.com>

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update LocalizedMessage.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22774/files
  - new: https://git.openjdk.org/jdk/pull/22774/files/15c4b64e..209d7eb3

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

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

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

From abarashev at openjdk.org  Fri Mar  7 21:42:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Mar 2025 21:42:13 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v4]
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update keytool and jarsigner resources location

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22774/files
  - new: https://git.openjdk.org/jdk/pull/22774/files/209d7eb3..7aa2706b

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

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

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

From ascarpino at openjdk.org  Fri Mar  7 22:07:55 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 7 Mar 2025 22:07:55 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v4]
In-Reply-To: <Z0-G2-rRsTESI2O9BOQHsAXjeVIloZ4T3--0dkm2EiU=.b5b1f7e1-6e8e-4a8b-82d1-ae6c7c09d996@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <c5KF8wFufjEbuAeFj2Mpc7M60j8jTyns-XP5iY8K194=.283efa1e-f662-4592-b1ba-0ea25a6c0bfb@github.com>
 <Z0-G2-rRsTESI2O9BOQHsAXjeVIloZ4T3--0dkm2EiU=.b5b1f7e1-6e8e-4a8b-82d1-ae6c7c09d996@github.com>
Message-ID: <gFOi2wc0zFdeRd3NEKBBvTJ64LhHm6uDFKtDrO5JXQ0=.ec6bbbe6-3767-494d-9ad1-5bb1f1930bad@github.com>

On Fri, 7 Mar 2025 19:07:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename getNamedCurveFromKey
>
> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 274:
> 
>> 272:                     yield List.of();
>> 273:                 }
>> 274:                 yield List.of(nc.getNameAndAliases());
> 
> Do you want to add `EC` itself to the list? I am asking because for EdDSA you added both the algorithm name and the parameter set name.

No, "EC" isn't an alias for a particular curve.

> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 276:
> 
>> 274:                 yield List.of(nc.getNameAndAliases());
>> 275:             }
>> 276:             default -> List.of(key.getAlgorithm(), KeyUtil.getAlgorithm(key));
> 
> What if these 2 are the same string?

Are you concerned about duplicate checks?

> test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 86:
> 
>> 84:                 Arrays.asList(
>> 85:                     new TestCase("EdDSA", false),
>> 86:                     new TestCase("Ed25519", true),
> 
> Why should the above pass? If you disable `EdDSA` and you are still allowed `Signature.getInstance("Ed25519")`? If this is because it will reject whatever EdDSA key later? Why both check `CryptoPrimitive.SIGNATURE` at all?

I'm confused by this comment.  With removing the hardcoded aliases in AbstractAlgorithmConstraints, which is what I thought you had suggested, EdDSA and Ed25519 are now separate as the check is effectively a string compare check against the disabledAlgorithm list

The second half of that case statement has a key that can check against both EdDSA and the NPS.

With respect to `CryptoPrimitive.SIGNATURE`, it just a value used in the test, it can't be null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1985768201
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1985768272
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1985768304

From weijun at openjdk.org  Fri Mar  7 22:07:56 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 7 Mar 2025 22:07:56 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v4]
In-Reply-To: <gFOi2wc0zFdeRd3NEKBBvTJ64LhHm6uDFKtDrO5JXQ0=.ec6bbbe6-3767-494d-9ad1-5bb1f1930bad@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <c5KF8wFufjEbuAeFj2Mpc7M60j8jTyns-XP5iY8K194=.283efa1e-f662-4592-b1ba-0ea25a6c0bfb@github.com>
 <Z0-G2-rRsTESI2O9BOQHsAXjeVIloZ4T3--0dkm2EiU=.b5b1f7e1-6e8e-4a8b-82d1-ae6c7c09d996@github.com>
 <gFOi2wc0zFdeRd3NEKBBvTJ64LhHm6uDFKtDrO5JXQ0=.ec6bbbe6-3767-494d-9ad1-5bb1f1930bad@github.com>
Message-ID: <Iv1BpfM3_cDcbXWk6glCIYVY5nk1JEAqCbcoyZnVL14=.da034f6d-bf2d-4584-9cd9-72293638329b@github.com>

On Fri, 7 Mar 2025 22:03:54 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 276:
>> 
>>> 274:                 yield List.of(nc.getNameAndAliases());
>>> 275:             }
>>> 276:             default -> List.of(key.getAlgorithm(), KeyUtil.getAlgorithm(key));
>> 
>> What if these 2 are the same string?
>
> Are you concerned about duplicate checks?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1985769790

From jlu at openjdk.org  Fri Mar  7 22:11:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Mar 2025 22:11:54 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v4]
In-Reply-To: <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>
Message-ID: <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>

On Fri, 7 Mar 2025 21:42:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update keytool and jarsigner resources location

Thanks for this conversion, left a few comments.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1:

> 1: /*

In this file, the method `fullDisplayKeyName` can have its comment updated to no longer mention Resources.java.

src/java.base/share/classes/sun/security/util/LocalizedMessage.java line 1:

> 1: /*

Latter copyright year on this file can be bumped.

src/java.base/share/classes/sun/security/util/LocalizedMessage.java line 92:

> 90:      * Return a non-localized string corresponding to the provided key, and
> 91:      * formatted with the provided arguments. All strings are obtained from
> 92:      * sun.security.util.resources, and the formatting only supports

The method above can have the same adjustment right?

src/java.base/share/classes/sun/security/util/ResourcesMgr.java line 1:

> 1: /*

Copyright year as well.

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

> 38: If.keystore.is.not.password.protected.then.storepass.and.keypass.must.not.be.specified=Wenn der Keystore nicht kennwortgesch?tzt ist, d?rfen -storepass und -keypass nicht angegeben werden
> 39: Usage.jarsigner.options.jar.file.alias=Verwendung: jarsigner [options] jar-file alias
> 40: .jarsigner.verify.options.jar.file.alias.=\u0020      jarsigner -verify [options] jar-file [alias...]

We have generally kept `\u0020` in these properties files for the purpose of making it clear that trailing white space in a value is intentional. Can we convert these non trailing `\u0020` to just ` `?

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

> 1: #

Looks like this file didn't get the escape sequence to native conversion.

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

PR Review: https://git.openjdk.org/jdk/pull/22774#pullrequestreview-2668455720
PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1985771621
PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1985767745
PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1985768748
PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1985769694
PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1985756147
PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1985754527

From abarashev at openjdk.org  Fri Mar  7 22:17:32 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Mar 2025 22:17:32 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v5]
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <v32MPulHv15elvjLtIgB5LJijMAjV4kCP3y2YsQDCns=.071e76ae-7fff-4cb8-9df5-f0b497fc3d41@github.com>

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Fix MessageFormatting test. Update Copyright.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22774/files
  - new: https://git.openjdk.org/jdk/pull/22774/files/7aa2706b..a386342a

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

  Stats: 8 lines in 3 files changed: 1 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22774/head:pull/22774

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

From abarashev at openjdk.org  Fri Mar  7 23:06:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 7 Mar 2025 23:06:55 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v4]
In-Reply-To: <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>
 <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
Message-ID: <RwPv4FqNJGO2AAS3yNk9WzlyiGF84ZRsZMuNbEmD5jM=.98e55a55-b202-425d-85b9-a6fc9c9b870c@github.com>

On Fri, 7 Mar 2025 22:03:20 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update keytool and jarsigner resources location
>
> src/java.base/share/classes/sun/security/util/LocalizedMessage.java line 1:
> 
>> 1: /*
> 
> Latter copyright year on this file can be bumped.

Done.

> src/java.base/share/classes/sun/security/util/LocalizedMessage.java line 92:
> 
>> 90:      * Return a non-localized string corresponding to the provided key, and
>> 91:      * formatted with the provided arguments. All strings are obtained from
>> 92:      * sun.security.util.resources, and the formatting only supports
> 
> The method above can have the same adjustment right?

Done.

> src/java.base/share/classes/sun/security/util/ResourcesMgr.java line 1:
> 
>> 1: /*
> 
> Copyright year as well.

Done, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1985825899
PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1985825758
PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1985825650

From duke at openjdk.org  Fri Mar  7 23:38:43 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 7 Mar 2025 23:38:43 GMT
Subject: RFR: 8328914: Document the java.security.debug property in javadoc
 [v15]
In-Reply-To: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
References: <KlyfeAxdZrgZb-SKbxb7qIIzuU9v23RI9SmOnhAXGlQ=.c8c329be-8e99-4e62-9b1f-d8d5e23de05d@github.com>
Message-ID: <_xpXEvZJzMsGMTjQEP2R7caQundxnXZ7MErAeOeUXqc=.e1339e85-e4e6-4e7e-9d37-4d48b5e1440b@github.com>

> java.security.debug is a widely used debug system property for JDK security libs. It's time to capture details about this property via javadoc.
> 
> <img width="1034" alt="image" src="https://github.com/user-attachments/assets/657bcbd8-f5dd-4f6a-bd9f-8b6daa254573" />
> 
> 
> 
> NOTE : We are adding a new html file (similar to the Networking Properties [here](https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/net/doc-files/net-properties.html#networking-properties-heading)) for documenting security-related properties, and over time, we will add more properties to this page.

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

  8328914: Document the java.security.debug property in javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23569/files
  - new: https://git.openjdk.org/jdk/pull/23569/files/a365c04d..ba6caeb6

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

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

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

From jwaters at openjdk.org  Sun Mar  9 18:30:01 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 9 Mar 2025 18:30:01 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <6n7W6MsSzG06DWdin8ZYslKSPueuSMB0l5s6hQb2DPg=.f10d6056-9560-4835-8380-0b54df417426@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

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

Keep open please. I will integrate this as soon as possible when I get approval for all the respective Pull Requests

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

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

From lmesnik at openjdk.org  Mon Mar 10 03:03:00 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 10 Mar 2025 03:03:00 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v5]
In-Reply-To: <3bphXKLpIpxAZP-FEOeob6AaHbv0BAoEceJka64vMW8=.3e4f74e0-9479-4926-b365-b08d8d702692@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <3bphXKLpIpxAZP-FEOeob6AaHbv0BAoEceJka64vMW8=.3e4f74e0-9479-4926-b365-b08d8d702692@github.com>
Message-ID: <qlwb4JKyY446ZQz5ZBdMN6SOblRZNQQ2gbNntRjiL2o=.8f5c1cb4-74d7-4005-832c-a44e170d3e33@github.com>

On Thu, 6 Mar 2025 17:37:33 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accepted review comments.

There are no any new tests in the PR. How fix has been tested by openjdk tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2709309387

From djelinski at openjdk.org  Mon Mar 10 07:55:11 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 10 Mar 2025 07:55:11 GMT
Subject: RFR: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with
 TLS1.2 TlsKeyMaterialParameterSpec
In-Reply-To: <JeXFl3kGqy_SRIdQ-GeWtlCXCQ19OE-yPW13XDIWbfs=.e891c0c9-5339-4bc0-a2fa-cfb20b29d5ae@github.com>
References: <JeXFl3kGqy_SRIdQ-GeWtlCXCQ19OE-yPW13XDIWbfs=.e891c0c9-5339-4bc0-a2fa-cfb20b29d5ae@github.com>
Message-ID: <RDiA6q6Ziq_vKjqLw5b6uaqQTZnE-RKCrSqYQ3Tivt0=.74626624-6d94-4cd0-b9e3-1b84a5384f38@github.com>

On Wed, 12 Feb 2025 10:02:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this trivial fix that ensures that the mechanism always matches the parameter class type.
> 
> I added a new test case that crashes without the fix, passes with the fix. Existing tier1-3 test cases continue to pass.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23583#issuecomment-2709702496

From djelinski at openjdk.org  Mon Mar 10 07:55:12 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 10 Mar 2025 07:55:12 GMT
Subject: Integrated: 8349849: PKCS11 SunTlsKeyMaterial crashes when used with
 TLS1.2 TlsKeyMaterialParameterSpec
In-Reply-To: <JeXFl3kGqy_SRIdQ-GeWtlCXCQ19OE-yPW13XDIWbfs=.e891c0c9-5339-4bc0-a2fa-cfb20b29d5ae@github.com>
References: <JeXFl3kGqy_SRIdQ-GeWtlCXCQ19OE-yPW13XDIWbfs=.e891c0c9-5339-4bc0-a2fa-cfb20b29d5ae@github.com>
Message-ID: <r4d0KN2POQbYTNAunHg0X--bYQ25Ig4hGfJIM0Nq89o=.fad7c9bf-abd7-45d6-8087-16c5bde52aed@github.com>

On Wed, 12 Feb 2025 10:02:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this trivial fix that ensures that the mechanism always matches the parameter class type.
> 
> I added a new test case that crashes without the fix, passes with the fix. Existing tier1-3 test cases continue to pass.

This pull request has now been integrated.

Changeset: 84f71dd6
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84f71dd6247bbaca508e0a6f04c5b201a1974266
Stats:     90 lines in 2 files changed: 89 ins; 0 del; 1 mod

8349849: PKCS11 SunTlsKeyMaterial crashes when used with TLS1.2 TlsKeyMaterialParameterSpec

Reviewed-by: wetmore, valeriep

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

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

From abarashev at openjdk.org  Mon Mar 10 12:50:01 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 12:50:01 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v4]
In-Reply-To: <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>
 <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
Message-ID: <msnjkGU0fvSNcXHDk5f4Ar-XeedUlwln5K1-BhpL6Tw=.9f303511-e705-4f32-9f06-9cbfddc9777b@github.com>

On Fri, 7 Mar 2025 22:07:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update keytool and jarsigner resources location
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1:
> 
>> 1: /*
> 
> In this file, the method `fullDisplayKeyName` can have its comment updated to no longer mention Resources.java.

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1987217922

From abarashev at openjdk.org  Mon Mar 10 14:36:05 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 14:36:05 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v4]
In-Reply-To: <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>
 <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
Message-ID: <z291o0LyFlrFzcn_4SiqlLPiFaY56KCQ8rjEbQXaqzY=.e6d69344-1bd9-47a0-840e-87bcfda710ab@github.com>

On Fri, 7 Mar 2025 21:50:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update keytool and jarsigner resources location
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 40:
> 
>> 38: If.keystore.is.not.password.protected.then.storepass.and.keypass.must.not.be.specified=Wenn der Keystore nicht kennwortgesch?tzt ist, d?rfen -storepass und -keypass nicht angegeben werden
>> 39: Usage.jarsigner.options.jar.file.alias=Verwendung: jarsigner [options] jar-file alias
>> 40: .jarsigner.verify.options.jar.file.alias.=\u0020      jarsigner -verify [options] jar-file [alias...]
> 
> We have generally kept `\u0020` in these properties files for the purpose of making it clear that trailing white space in a value is intentional. Can we convert these non trailing `\u0020` to just ` `?

In properties files the whitespaces after `=` get trimmed when compiled, so when we replace `\u0020` with ` ` we get an incorrect string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1987420604

From abarashev at openjdk.org  Mon Mar 10 14:56:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 14:56:51 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v6]
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <Q4ux508-awdThZmrijqip1VNfpnu34IcTx5rVWpxZUk=.ed6ee11c-42d9-4665-b1ce-4c8c7f095df7@github.com>

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  jarsigner_zh_CN.properties conversion plus a couple of minor fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22774/files
  - new: https://git.openjdk.org/jdk/pull/22774/files/a386342a..652900b4

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

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

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

From abarashev at openjdk.org  Mon Mar 10 15:00:29 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 15:00:29 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v7]
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <MzzkUZt1EpV7fC8i6o91xU3pFE4Lj4tFvbdMtzb5hAs=.002f6ba6-608e-496b-899c-9cb6393cccde@github.com>

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22774/files
  - new: https://git.openjdk.org/jdk/pull/22774/files/652900b4..db9cee30

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

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

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

From abarashev at openjdk.org  Mon Mar 10 15:21:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 15:21:10 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v8]
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <glEEKXcelw9guYDJrX15L9nMzimV1UzQpr9DK9JkDvM=.1471bbd6-aeb3-4d91-8244-2ccf3451541e@github.com>

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Restore missing comma in copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22774/files
  - new: https://git.openjdk.org/jdk/pull/22774/files/db9cee30..ac1c7c3a

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

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

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

From abarashev at openjdk.org  Mon Mar 10 15:46:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 15:46:00 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v4]
In-Reply-To: <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>
 <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
Message-ID: <NLh-y5QWDey8j9UN1N-CBov-d9_QDbyjjzCrKnCjs2c=.6b0a2350-63cb-4b02-9b45-38f71998a29f@github.com>

On Fri, 7 Mar 2025 21:48:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update keytool and jarsigner resources location
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_zh_CN.properties line 1:
> 
>> 1: #
> 
> Looks like this file didn't get the escape sequence to native conversion.

Thanks, I've noticed this too myself. I converted the file and ran it through the migration test again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1987561721

From kdriver at openjdk.org  Mon Mar 10 15:59:23 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 10 Mar 2025 15:59:23 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v7]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <xp7lmV5C-yC3SLTWRDFTpDrieUsAo_N_mNYAtXg8FfA=.4cde439f-58b5-4d26-a346-8abadbc9c06f@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
> 
> **Note**: We cannot (so far) pass whether the verbose flag is set to the class that does this processing. We may want to add a property to the builder for this. As-is, the message will be printed via `System.err` whether verbose is set or not.

Kevin Driver has updated the pull request incrementally with three additional commits since the last revision:

 - force-add jar
 - re-write to make the changes in the jarsigner tool itself, rather than the API
 - Revert "JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest."
   
   This reverts commit 06e90503f3e75b1b432ec0a196716f01ebb7344a.
   
   # Please enter the commit message for your changes. Lines starting
   # with '#' will be kept; you may remove them yourself if you want to.
   # An empty message aborts the commit.
   #
   # On branch 8341775
   # Your branch is up to date with 'origin/8341775'.
   #
   # Changes to be committed:
   #	modified:   src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
   #

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/2b133a31..4c78b9fd

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

  Stats: 114 lines in 5 files changed: 96 ins; 17 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22222/head:pull/22222

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

From kdriver at openjdk.org  Mon Mar 10 15:59:23 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 10 Mar 2025 15:59:23 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing
In-Reply-To: <uVdlqTnx1BWyl6scU_DEC9XfzYg8J7jwr6Mlg717byU=.7dceb4ec-c83c-4608-a14b-a2671cab6a72@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <uVdlqTnx1BWyl6scU_DEC9XfzYg8J7jwr6Mlg717byU=.7dceb4ec-c83c-4608-a14b-a2671cab6a72@github.com>
Message-ID: <LJToMCGyEkob8_63Vzv30LgZgPLIuf1753MYrTzSJ2Y=.7f8e9025-eab6-48e7-922a-ebe698bfc2d4@github.com>

On Thu, 21 Nov 2024 15:53:28 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>> 
>> **Note**: We cannot (so far) pass whether the verbose flag is set to the class that does this processing. We may want to add a property to the builder for this. As-is, the message will be printed via `System.err` whether verbose is set or not.
>
> I?d like to suggest creating a test program (for better long term support) that generates a JAR file with multiple manifest entries and then uses JarSigner.Builder() and JarSigner.sign(). The JarSigner.sign() will ultimately invoke getManifestFile(), ensuring that the new warning about multiple manifest entries is emitted.

@haimaychao: can you please re-review?

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

PR Comment: https://git.openjdk.org/jdk/pull/22222#issuecomment-2711069275

From weijun at openjdk.org  Mon Mar 10 17:04:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 10 Mar 2025 17:04:04 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v7]
In-Reply-To: <xp7lmV5C-yC3SLTWRDFTpDrieUsAo_N_mNYAtXg8FfA=.4cde439f-58b5-4d26-a346-8abadbc9c06f@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <xp7lmV5C-yC3SLTWRDFTpDrieUsAo_N_mNYAtXg8FfA=.4cde439f-58b5-4d26-a346-8abadbc9c06f@github.com>
Message-ID: <egsztSOCHxI0er6khrZHs5J7Gj6gsOl5AmZcg64HwaQ=.9e344fd3-95cc-4346-8f1c-f012c2a4b64a@github.com>

On Mon, 10 Mar 2025 15:59:23 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>> 
>> **Note**: We cannot (so far) pass whether the verbose flag is set to the class that does this processing. We may want to add a property to the builder for this. As-is, the message will be printed via `System.err` whether verbose is set or not.
>
> Kevin Driver has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - force-add jar
>  - re-write to make the changes in the jarsigner tool itself, rather than the API
>  - Revert "JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest."
>    
>    This reverts commit 06e90503f3e75b1b432ec0a196716f01ebb7344a.
>    
>    # Please enter the commit message for your changes. Lines starting
>    # with '#' will be kept; you may remove them yourself if you want to.
>    # An empty message aborts the commit.
>    #
>    # On branch 8341775
>    # Your branch is up to date with 'origin/8341775'.
>    #
>    # Changes to be committed:
>    #	modified:   src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
>    #

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

> 1984:             if(manifestNum > 1) {
> 1985:                 System.out.println();
> 1986:                 System.out.println(rb.getString("Warning."));

Typically, we don?t print a warning immediately when a problem is detected. Instead, we log a flag and display the warnings later in the `displayMessagesAndResult` method. If a warning is printed too early, and there are a lot of additional lines after it (For example, with `-verbose` enabled and many entries), the warning may be overlooked.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1987694092

From weijun at openjdk.org  Mon Mar 10 17:11:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 10 Mar 2025 17:11:04 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v7]
In-Reply-To: <xp7lmV5C-yC3SLTWRDFTpDrieUsAo_N_mNYAtXg8FfA=.4cde439f-58b5-4d26-a346-8abadbc9c06f@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <xp7lmV5C-yC3SLTWRDFTpDrieUsAo_N_mNYAtXg8FfA=.4cde439f-58b5-4d26-a346-8abadbc9c06f@github.com>
Message-ID: <jYrHJ7nc53BuKbDY6fse4UGdEVLRe3OyHJT3nMoY6e4=.32602a3d-b2b0-4c3f-ba81-80648f31cdd4@github.com>

On Mon, 10 Mar 2025 15:59:23 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>> 
>> **Note**: We cannot (so far) pass whether the verbose flag is set to the class that does this processing. We may want to add a property to the builder for this. As-is, the message will be printed via `System.err` whether verbose is set or not.
>
> Kevin Driver has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - force-add jar
>  - re-write to make the changes in the jarsigner tool itself, rather than the API
>  - Revert "JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest."
>    
>    This reverts commit 06e90503f3e75b1b432ec0a196716f01ebb7344a.
>    
>    # Please enter the commit message for your changes. Lines starting
>    # with '#' will be kept; you may remove them yourself if you want to.
>    # An empty message aborts the commit.
>    #
>    # On branch 8341775
>    # Your branch is up to date with 'origin/8341775'.
>    #
>    # Changes to be committed:
>    #	modified:   src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
>    #

test/jdk/sun/security/tools/jarsigner/MultiManifest.jar line 1:

> 1: PKO?rY	META-INF/??PKPKO?rYMETA-INF/MANIFEST.MF?M??LK-.?

We usually do not include a binary file in the code repository. Can you generate one on the fly? Although JDK?s `ZipOutputStream` does not allow duplicate entries, you can add two entries whose names differ only by case. IIRC, when counting the number of manifests using `JUZFA.getManifestNum`, the check is case-insensitive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1987704612

From mullan at openjdk.org  Mon Mar 10 17:20:41 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Mar 2025 17:20:41 GMT
Subject: RFR: 8351349: GSSUtil.createSubject has outdated access control
 context and policy related text
Message-ID: <hWsuhosMWi9X8YjQt3Z0TamRiPDgdURT8j-_19gJwVA=.8eb57c34-3da7-4277-a882-4249b5d47eff@github.com>

Please review this change to remove outdated access control context and policy related text from the `com.sun.security.jgss.GSSUtil` class which no longer applies now that JEP 486 disabled the Security Manager. I have removed the text and not tried to replace it. I think it is better to keep the method description simple and not assume what a server might do with the subject, such as using it to impersonate a client.

I also made a few other minor changes, adding code tags around class names and changing "Sun Microsystem's" to "the JDK" in the class description.

I will also file a CSR.

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

Commit messages:
 - Initial changes.

Changes: https://git.openjdk.org/jdk/pull/23970/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23970&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351349
  Stats: 26 lines in 1 file changed: 1 ins; 4 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/23970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23970/head:pull/23970

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

From abarashev at openjdk.org  Mon Mar 10 17:57:42 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 17:57:42 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v9]
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Keep the original copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22774/files
  - new: https://git.openjdk.org/jdk/pull/22774/files/ac1c7c3a..7d911bce

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

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

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

From weijun at openjdk.org  Mon Mar 10 17:58:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 10 Mar 2025 17:58:58 GMT
Subject: RFR: 8351349: GSSUtil.createSubject has outdated access control
 context and policy related text
In-Reply-To: <hWsuhosMWi9X8YjQt3Z0TamRiPDgdURT8j-_19gJwVA=.8eb57c34-3da7-4277-a882-4249b5d47eff@github.com>
References: <hWsuhosMWi9X8YjQt3Z0TamRiPDgdURT8j-_19gJwVA=.8eb57c34-3da7-4277-a882-4249b5d47eff@github.com>
Message-ID: <seTAH3HopnV5FedcMOOip2M9rKtQNK6PB-FRx1vfrnY=.bd448672-7fe0-4f4f-bf31-7307bbe4d24b@github.com>

On Mon, 10 Mar 2025 17:15:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to remove outdated access control context and policy related text from the `com.sun.security.jgss.GSSUtil` class which no longer applies now that JEP 486 disabled the Security Manager. I have removed the text and not tried to replace it. I think it is better to keep the method description simple and not assume what a server might do with the subject, such as using it to impersonate a client.
> 
> I also made a few other minor changes, adding code tags around class names and changing "Sun Microsystem's" to "the JDK" in the class description.
> 
> I will also file a CSR.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23970#pullrequestreview-2671795021

From abarashev at openjdk.org  Mon Mar 10 18:25:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 18:25:04 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v15]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <JuQhSQVpQ7EHoikRdi5HN-i7mgEWorrVE5HbdvUu0B4=.5b51e705-defd-4646-95f5-9b0d7b9e74d2@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update constraint description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/0c8d6d81..06ebd342

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

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

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

From abarashev at openjdk.org  Mon Mar 10 18:25:07 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 18:25:07 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v14]
In-Reply-To: <Ymzw8oHKd3fKRqJm7_sImXpbkc56sLwhDcerhmGAD1U=.f6d6a368-afcd-4587-8f6d-5e6ccf171429@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <LSV96eSyxH-Jjdh7WBlGK8w5K4Skr3GWhJp9-PuPyE0=.deb56e53-d089-43a4-bfaf-1065dc5cd914@github.com>
 <Ymzw8oHKd3fKRqJm7_sImXpbkc56sLwhDcerhmGAD1U=.f6d6a368-afcd-4587-8f6d-5e6ccf171429@github.com>
Message-ID: <Ie-Jb-k0PyJfPbhNADx28Pa8T1gjuE_2LGcTjqwQoqE=.0095949a-f1f3-4978-a08c-c169259139f4@github.com>

On Fri, 7 Mar 2025 18:48:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move SSLScope class description below the package
>
> src/java.base/share/conf/security/java.security line 747:
> 
>> 745: #
>> 746: #     Handshake restricts the use of the algorithm in TLS handshake signatures.
>> 747: #     Certificate restricts the use of the algorithm in certificate signatures.
> 
> I think we should repeat this sentence from the "UsageConstraint" definition in the `jdk.certpath.disabledAlgorithms` property: "The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter."
> 
> (This will also help address Joe's comment on the CSR).

Done, thanks! Updated CSR as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1987807778

From rhalade at openjdk.org  Mon Mar 10 19:05:59 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 10 Mar 2025 19:05:59 GMT
Subject: RFR: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version [v6]
In-Reply-To: <xs2qyNSu00wFkhLov6Z2c1yL0h4KSzodkiq1BuCgovI=.4fb0558b-b5e0-4114-82d9-bd52d39dc263@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
 <xs2qyNSu00wFkhLov6Z2c1yL0h4KSzodkiq1BuCgovI=.4fb0558b-b5e0-4114-82d9-bd52d39dc263@github.com>
Message-ID: <lYl__xesumMKu0NtAHI1a4wIQgoG_dtha3Dth-Mct9Q=.731ef054-02b5-477d-8c5a-67475356874b@github.com>

On Fri, 7 Mar 2025 12:43:34 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). 
>> There are some differences between the 1.1.x and the current OpenSSL version:
>> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it.  Additionally, It is also required to specify the path location of the legacy provider.
>> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   based on suggestions

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23613#pullrequestreview-2671945587

From mullan at openjdk.org  Mon Mar 10 19:42:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 10 Mar 2025 19:42:54 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v15]
In-Reply-To: <JuQhSQVpQ7EHoikRdi5HN-i7mgEWorrVE5HbdvUu0B4=.5b51e705-defd-4646-95f5-9b0d7b9e74d2@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <JuQhSQVpQ7EHoikRdi5HN-i7mgEWorrVE5HbdvUu0B4=.5b51e705-defd-4646-95f5-9b0d7b9e74d2@github.com>
Message-ID: <tpJRxYU6MSaTos1FiQIeX4fW9cPvnzBocituO7-ZLXM=.18122ba6-445c-4c0a-a991-2fc4879aa631@github.com>

On Mon, 10 Mar 2025 18:25:04 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update constraint description

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

> 750: #     ampersand '&'. The usage type follows the keyword and more than one usage
> 751: #     type can be specified with a whitespace delimiter.
> 752: #     Example: "rsa_pkcs1_sha1 usage handshake"

Can you change "handshake" to "Handshake" to match the format (even though it is case-insensitive).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1987912839

From duke at openjdk.org  Mon Mar 10 19:43:56 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Mar 2025 19:43:56 GMT
Subject: RFR: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version [v6]
In-Reply-To: <xs2qyNSu00wFkhLov6Z2c1yL0h4KSzodkiq1BuCgovI=.4fb0558b-b5e0-4114-82d9-bd52d39dc263@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
 <xs2qyNSu00wFkhLov6Z2c1yL0h4KSzodkiq1BuCgovI=.4fb0558b-b5e0-4114-82d9-bd52d39dc263@github.com>
Message-ID: <0VR_8ycKp5MisRmCWYIhKdQ5OOdS04Lc_DhJmq_pLq0=.390e899d-8739-438d-bef8-462aa3fdbe46@github.com>

On Fri, 7 Mar 2025 12:43:34 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). 
>> There are some differences between the 1.1.x and the current OpenSSL version:
>> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it.  Additionally, It is also required to specify the path location of the legacy provider.
>> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   based on suggestions

@fguallini 
Your change (at version 621e5d9d31afd3bb0ae2da31c288cccde3947b6d) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23613#issuecomment-2711645148

From fguallini at openjdk.org  Mon Mar 10 19:54:04 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Mon, 10 Mar 2025 19:54:04 GMT
Subject: Integrated: 8349492: Update
 sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl
 version
In-Reply-To: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
References: <GV5vN_1OKEgFWUrKdfS-2knXyjeKHvLII0-h_P6G7uU=.3c5a5c53-bc50-41dd-924d-ba6fc1566c64@github.com>
Message-ID: <RxfmrHE9rNPhbdeGSAZAuceTeRZwispDz22eqBXR884=.6611f703-d73d-4154-84d4-60c7548205d8@github.com>

On Thu, 13 Feb 2025 12:44:21 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> This updates the OpenSSL version that is used by test `sun/security/pkcs12/KeytoolOpensslInteropTest.java` to the current LTS version (3.0 series). 
> There are some differences between the 1.1.x and the current OpenSSL version:
> - RC4 is not longer enabled by default, therefore adding the `-legacy` flag when needed to enable it.  Additionally, It is also required to specify the path location of the legacy provider.
> - Unlike the old version that throws an error if the MAC was absent from the PKCS12, the 3.0 series shows a warning instead.

This pull request has now been integrated.

Changeset: 8d8bd0c4
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d8bd0c4b3bfdc7670bba03b01b0a00dac9f9825
Stats:     116 lines in 2 files changed: 62 ins; 7 del; 47 mod

8349492: Update sun/security/pkcs12/KeytoolOpensslInteropTest.java to use a recent Openssl version

Reviewed-by: rhalade

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

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

From abarashev at openjdk.org  Mon Mar 10 20:20:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 20:20:59 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v15]
In-Reply-To: <tpJRxYU6MSaTos1FiQIeX4fW9cPvnzBocituO7-ZLXM=.18122ba6-445c-4c0a-a991-2fc4879aa631@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <JuQhSQVpQ7EHoikRdi5HN-i7mgEWorrVE5HbdvUu0B4=.5b51e705-defd-4646-95f5-9b0d7b9e74d2@github.com>
 <tpJRxYU6MSaTos1FiQIeX4fW9cPvnzBocituO7-ZLXM=.18122ba6-445c-4c0a-a991-2fc4879aa631@github.com>
Message-ID: <t6TVQZNu4RLW-JbL5uEAc0QSbAnaBuw0yXvqqFybD5M=.03c785d8-fb57-4c70-a771-0438dc945ac9@github.com>

On Mon, 10 Mar 2025 19:40:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update constraint description
>
> src/java.base/share/conf/security/java.security line 752:
> 
>> 750: #     ampersand '&'. The usage type follows the keyword and more than one usage
>> 751: #     type can be specified with a whitespace delimiter.
>> 752: #     Example: "rsa_pkcs1_sha1 usage handshake"
> 
> Can you change "handshake" to "Handshake" to match the format (even though it is case-insensitive).

Will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1987963238

From weijun at openjdk.org  Mon Mar 10 20:26:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 10 Mar 2025 20:26:52 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <W8Ei6bAPjN2kOpRw1O5-5dkk6KiqFgZ4-MtTxj-u0BY=.77c5bd7c-5527-4ba9-b76e-e1270823fdc9@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

Marked as reviewed by weijun (Reviewer).

Need more reviewers from build and/or i18n.

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

PR Review: https://git.openjdk.org/jdk/pull/22774#pullrequestreview-2672112889
PR Comment: https://git.openjdk.org/jdk/pull/22774#issuecomment-2711739409

From abarashev at openjdk.org  Mon Mar 10 20:43:49 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 10 Mar 2025 20:43:49 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v16]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <wqDcZICDZ6MjgvTEWaQZ0BbmAs92wZ4Ih8K_0xdBpKU=.fddc4336-428c-4087-9cfd-43d70d4300e1@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Constraint description update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/06ebd342..32ec7810

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

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

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

From kdriver at openjdk.org  Mon Mar 10 21:13:59 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 10 Mar 2025 21:13:59 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v7]
In-Reply-To: <jYrHJ7nc53BuKbDY6fse4UGdEVLRe3OyHJT3nMoY6e4=.32602a3d-b2b0-4c3f-ba81-80648f31cdd4@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <xp7lmV5C-yC3SLTWRDFTpDrieUsAo_N_mNYAtXg8FfA=.4cde439f-58b5-4d26-a346-8abadbc9c06f@github.com>
 <jYrHJ7nc53BuKbDY6fse4UGdEVLRe3OyHJT3nMoY6e4=.32602a3d-b2b0-4c3f-ba81-80648f31cdd4@github.com>
Message-ID: <BhXRtATU6Up-SV8CLjpJIOA3tT3mcc3MoqFlCSLF_gI=.6dda6456-e412-452e-b55e-7e37aeadb106@github.com>

On Mon, 10 Mar 2025 17:08:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - force-add jar
>>  - re-write to make the changes in the jarsigner tool itself, rather than the API
>>  - Revert "JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest."
>>    
>>    This reverts commit 06e90503f3e75b1b432ec0a196716f01ebb7344a.
>>    
>>    # Please enter the commit message for your changes. Lines starting
>>    # with '#' will be kept; you may remove them yourself if you want to.
>>    # An empty message aborts the commit.
>>    #
>>    # On branch 8341775
>>    # Your branch is up to date with 'origin/8341775'.
>>    #
>>    # Changes to be committed:
>>    #	modified:   src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
>>    #
>
> test/jdk/sun/security/tools/jarsigner/MultiManifest.jar line 1:
> 
>> 1: PKO?rY	META-INF/??PKPKO?rYMETA-INF/MANIFEST.MF?M??LK-.?
> 
> We usually do not include a binary file in the code repository. Can you generate one on the fly? Although JDK?s `ZipOutputStream` does not allow duplicate entries, you can add two entries whose names differ only by case. IIRC, when counting the number of manifests using `JUZFA.getManifestNum`, the check is case-insensitive.

I made sure that there were other jars in this directory in the source tree before trying this approach. In fact, there are a few tests taking this same approach. The jar is < 1/2 KB.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1988030196

From kdriver at openjdk.org  Mon Mar 10 21:21:55 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 10 Mar 2025 21:21:55 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v7]
In-Reply-To: <egsztSOCHxI0er6khrZHs5J7Gj6gsOl5AmZcg64HwaQ=.9e344fd3-95cc-4346-8f1c-f012c2a4b64a@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <xp7lmV5C-yC3SLTWRDFTpDrieUsAo_N_mNYAtXg8FfA=.4cde439f-58b5-4d26-a346-8abadbc9c06f@github.com>
 <egsztSOCHxI0er6khrZHs5J7Gj6gsOl5AmZcg64HwaQ=.9e344fd3-95cc-4346-8f1c-f012c2a4b64a@github.com>
Message-ID: <ePgu3SuUG-VQXsNlkNTHLsVr_r5V50ZAdyHLoUQ8V7A=.96dcf234-40f4-4a87-9696-e1b27d85371c@github.com>

On Mon, 10 Mar 2025 17:01:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - force-add jar
>>  - re-write to make the changes in the jarsigner tool itself, rather than the API
>>  - Revert "JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest."
>>    
>>    This reverts commit 06e90503f3e75b1b432ec0a196716f01ebb7344a.
>>    
>>    # Please enter the commit message for your changes. Lines starting
>>    # with '#' will be kept; you may remove them yourself if you want to.
>>    # An empty message aborts the commit.
>>    #
>>    # On branch 8341775
>>    # Your branch is up to date with 'origin/8341775'.
>>    #
>>    # Changes to be committed:
>>    #	modified:   src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
>>    #
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1986:
> 
>> 1984:             if(manifestNum > 1) {
>> 1985:                 System.out.println();
>> 1986:                 System.out.println(rb.getString("Warning."));
> 
> Typically, we don?t print a warning immediately when a problem is detected. Instead, we log a flag and display the warnings later in the `displayMessagesAndResult` method. If a warning is printed too early, and there are a lot of additional lines after it (For example, with `-verbose` enabled and many entries), the warning may be overlooked.

I see. I noted the `error` method but somehow I missed that warnings are collected and displayed via `displayMessagesAndResult`. I was planning to show the message as it happens, since that is what we do with the `error` method calls. This isn't exactly an "error," but I didn't see a `warn` (or similar) method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1988037614

From lancea at openjdk.org  Mon Mar 10 21:21:56 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Mar 2025 21:21:56 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v7]
In-Reply-To: <BhXRtATU6Up-SV8CLjpJIOA3tT3mcc3MoqFlCSLF_gI=.6dda6456-e412-452e-b55e-7e37aeadb106@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <xp7lmV5C-yC3SLTWRDFTpDrieUsAo_N_mNYAtXg8FfA=.4cde439f-58b5-4d26-a346-8abadbc9c06f@github.com>
 <jYrHJ7nc53BuKbDY6fse4UGdEVLRe3OyHJT3nMoY6e4=.32602a3d-b2b0-4c3f-ba81-80648f31cdd4@github.com>
 <BhXRtATU6Up-SV8CLjpJIOA3tT3mcc3MoqFlCSLF_gI=.6dda6456-e412-452e-b55e-7e37aeadb106@github.com>
Message-ID: <t2BlLPGwsNGCCcJUIRSgFwZjs7UONzKUXgxlfmMMQD0=.5f800f54-5762-4f9b-92ef-e7ad5a400cf7@github.com>

On Mon, 10 Mar 2025 21:11:15 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> test/jdk/sun/security/tools/jarsigner/MultiManifest.jar line 1:
>> 
>>> 1: PKO?rY	META-INF/??PKPKO?rYMETA-INF/MANIFEST.MF?M??LK-.?
>> 
>> We usually do not include a binary file in the code repository. Can you generate one on the fly? Although JDK?s `ZipOutputStream` does not allow duplicate entries, you can add two entries whose names differ only by case. IIRC, when counting the number of manifests using `JUZFA.getManifestNum`, the check is case-insensitive.
>
> I made sure that there were other jars in this directory in the source tree before trying this approach. In fact, there are a few tests taking this same approach. The jar is < 1/2 KB.

I agree with max

We have been removing them from the zip/jar area and we do not want more binary files added to the work space

If you need help please ask but please do not move forward checking in a binary file

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1988040874

From hchao at openjdk.org  Mon Mar 10 22:01:54 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 10 Mar 2025 22:01:54 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v7]
In-Reply-To: <ePgu3SuUG-VQXsNlkNTHLsVr_r5V50ZAdyHLoUQ8V7A=.96dcf234-40f4-4a87-9696-e1b27d85371c@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <xp7lmV5C-yC3SLTWRDFTpDrieUsAo_N_mNYAtXg8FfA=.4cde439f-58b5-4d26-a346-8abadbc9c06f@github.com>
 <egsztSOCHxI0er6khrZHs5J7Gj6gsOl5AmZcg64HwaQ=.9e344fd3-95cc-4346-8f1c-f012c2a4b64a@github.com>
 <ePgu3SuUG-VQXsNlkNTHLsVr_r5V50ZAdyHLoUQ8V7A=.96dcf234-40f4-4a87-9696-e1b27d85371c@github.com>
Message-ID: <UxY0f_sQNGScjAeeLZOQxwPskd8vScq6q3igycmxDkE=.127fac6d-bba2-4218-b763-ccdec5c8dfb0@github.com>

On Mon, 10 Mar 2025 21:16:53 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1986:
>> 
>>> 1984:             if(manifestNum > 1) {
>>> 1985:                 System.out.println();
>>> 1986:                 System.out.println(rb.getString("Warning."));
>> 
>> Typically, we don?t print a warning immediately when a problem is detected. Instead, we log a flag and display the warnings later in the `displayMessagesAndResult` method. If a warning is printed too early, and there are a lot of additional lines after it (For example, with `-verbose` enabled and many entries), the warning may be overlooked.
>
> I see. I noted the `error` method but somehow I missed that warnings are collected and displayed via `displayMessagesAndResult`. I was planning to show the message as it happens, since that is what we do with the `error` method calls. This isn't exactly an "error," but I didn't see a `warn` (or similar) method.

It uses displayMessagesAndResult() where it will keep all of the warnings at https://github.com/openjdk/jdk/blob/master/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java#L1134 and emit them as needed later in this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1988084083

From ascarpino at openjdk.org  Mon Mar 10 22:51:58 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 10 Mar 2025 22:51:58 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
Message-ID: <X7zT-DxVzyhXInXudD3F5OYXMwUGQQ1mUrEPNPqZCkY=.15e0bfcd-26e6-4c0b-90ac-67f632ed81ec@github.com>

On Wed, 5 Mar 2025 23:03:23 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comment improvements

test/jdk/com/sun/security/util/math/intpoly/MontgomeryPolynomialFuzzTest.java line 30:

> 28: import sun.security.util.math.intpoly.*;
> 29: 
> 30: /*

It is strange that there are two copies of the `@test` block.  Can you please remove one of them, unless you are seeing a difference that I do not

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1988122873

From vpaprotski at openjdk.org  Mon Mar 10 23:10:54 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 10 Mar 2025 23:10:54 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <X7zT-DxVzyhXInXudD3F5OYXMwUGQQ1mUrEPNPqZCkY=.15e0bfcd-26e6-4c0b-90ac-67f632ed81ec@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
 <X7zT-DxVzyhXInXudD3F5OYXMwUGQQ1mUrEPNPqZCkY=.15e0bfcd-26e6-4c0b-90ac-67f632ed81ec@github.com>
Message-ID: <W26HBW3Wj-oke-vXimRbaWxBvn0cP66GQ1PRNrtnnzI=.cb058a5d-43cb-479e-9766-0202e7f98cfb@github.com>

On Mon, 10 Mar 2025 22:49:06 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more comment improvements
>
> test/jdk/com/sun/security/util/math/intpoly/MontgomeryPolynomialFuzzTest.java line 30:
> 
>> 28: import sun.security.util.math.intpoly.*;
>> 29: 
>> 30: /*
> 
> It is strange that there are two copies of the `@test` block.  Can you please remove one of them, unless you are seeing a difference that I do not

-XX:+/-UseIntPolyIntrinsics (test Java vs BigInt and intrinsic vs BigInt)

Though I think I did this before I knew much about junit.. I think I can just have two @run commands (to make it clearer)? Will give that a try

> test/jdk/com/sun/security/util/math/intpoly/MontgomeryPolynomialFuzzTest.java line 123:
> 
>> 121:         }
>> 122: 
>> 123:         if (rnd.nextBoolean()) {
> 
> Why is this done randomly?  Wouldn't we want to check these situations every time?

I was mostly attempting to test 'random paths' through the code, and this was a way to pseudo-randomly accomplish that. (i.e. a product of a difference, a product of a product.. and so on..)

Since this is looping, we got 50% chance of getting both, without me having to write/think-through all the many permutations of what input/outputs to each operations can be.

(Extend the loop count to run for several hours during development.. and it does wonders to testing corner cases. Have been following this 'template' in most my PRs)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1988136095
PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1988134465

From jlu at openjdk.org  Tue Mar 11 00:37:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Mar 2025 00:37:56 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <dFKNY64YaNuM4dyOdANWxnWFoeMEtfxl9Hm1mT5LM9E=.609167ac-4f2b-46a6-acee-a87b3d0264f7@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

Skimmed some tricky values and the conversions looked correct to me.
Since it was tested that the values are the same before and after, this change looks good to me.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22774#pullrequestreview-2672454949

From jlu at openjdk.org  Tue Mar 11 00:37:57 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Mar 2025 00:37:57 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v4]
In-Reply-To: <z291o0LyFlrFzcn_4SiqlLPiFaY56KCQ8rjEbQXaqzY=.e6d69344-1bd9-47a0-840e-87bcfda710ab@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>
 <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
 <z291o0LyFlrFzcn_4SiqlLPiFaY56KCQ8rjEbQXaqzY=.e6d69344-1bd9-47a0-840e-87bcfda710ab@github.com>
Message-ID: <Xht5uew8BRiPQ24x2llPx98CwaT2R8HRdbLk1iXkZRo=.fd3f725b-89ff-4062-a594-b8118dfbef69@github.com>

On Mon, 10 Mar 2025 14:33:14 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 40:
>> 
>>> 38: If.keystore.is.not.password.protected.then.storepass.and.keypass.must.not.be.specified=Wenn der Keystore nicht kennwortgesch?tzt ist, d?rfen -storepass und -keypass nicht angegeben werden
>>> 39: Usage.jarsigner.options.jar.file.alias=Verwendung: jarsigner [options] jar-file alias
>>> 40: .jarsigner.verify.options.jar.file.alias.=\u0020      jarsigner -verify [options] jar-file [alias...]
>> 
>> We have generally kept `\u0020` in these properties files for the purpose of making it clear that trailing white space in a value is intentional. Can we convert these non trailing `\u0020` to just ` `?
>
> In properties files the whitespaces after `=` get trimmed when compiled, so when we replace `\u0020` with ` ` we get an incorrect string.

Ah, you're right, I am used to seeing those cases starting with `` to preserve the leading white space. Since it's just a stylistic choice, this seems fine then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1988192291

From mullan at openjdk.org  Tue Mar 11 12:49:44 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Mar 2025 12:49:44 GMT
Subject: RFR: 8351349: GSSUtil.createSubject has outdated access control
 context and policy related text [v2]
In-Reply-To: <hWsuhosMWi9X8YjQt3Z0TamRiPDgdURT8j-_19gJwVA=.8eb57c34-3da7-4277-a882-4249b5d47eff@github.com>
References: <hWsuhosMWi9X8YjQt3Z0TamRiPDgdURT8j-_19gJwVA=.8eb57c34-3da7-4277-a882-4249b5d47eff@github.com>
Message-ID: <Er8Pju3EAvqKP8B_M1hMV7KtFtK3nLTmIqmg3m1hw1w=.41c06f8b-2938-4ae6-a658-bfb86aa9a02a@github.com>

> Please review this change to remove outdated access control context and policy related text from the `com.sun.security.jgss.GSSUtil` class which no longer applies now that JEP 486 disabled the Security Manager. 
> 
> I also made a few other minor changes, adding code tags around class names and changing "Sun Microsystem's" to "the JDK" in the class description.
> 
> I will also file a CSR.

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Restore part of second sentence. Move @return to end.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23970/files
  - new: https://git.openjdk.org/jdk/pull/23970/files/c5c20178..3aff705e

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

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

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

From mdonovan at openjdk.org  Tue Mar 11 15:26:04 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 11 Mar 2025 15:26:04 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method
Message-ID: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>

In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.

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

Commit messages:
 - 8350964: Add an ArtifactResolver.fetch(clazz) method

Changes: https://git.openjdk.org/jdk/pull/23989/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23989&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350964
  Stats: 93 lines in 5 files changed: 41 ins; 37 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23989/head:pull/23989

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

From myankelevich at openjdk.org  Tue Mar 11 15:42:55 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 11 Mar 2025 15:42:55 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method
In-Reply-To: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
Message-ID: <0OAiXFUeGf-WMLT67obiWbt0WE-y9VBWA5j5XAZN-Qg=.bdd4803c-9baa-4d08-b5fb-f45052fe6bdc@github.com>

On Tue, 11 Mar 2025 15:21:09 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.

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

> 179:     }
> 180: 
> 181:     private static Path fetchACVPServerTests(Class<?> clazz) {

Is there a point in this method? It's used in 1 spot only it seems and you can just directly call `fetchOne`

test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 100:

> 98:             Throwable cause = e.getCause();
> 99:             if (cause == null) {
> 100:                 // if property doesn't exist

As per our discussion, do you think doing it in a way similar to [this](https://github.com/openjdk/jdk/pull/23988/files#diff-65002682c363b32a2f5bc860ec7482f3682cceb2d2c748e5b9d3aa4aedf88d35R66-R72) would be easier to read during a debug?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1989582660
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1989547147

From erikj at openjdk.org  Tue Mar 11 15:45:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 15:45:56 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <5irTdPcTdpBrzwzWUiAaZqHKbGINiONFtIYDLIguyws=.1f241454-7cae-4f45-9383-57953b37de8b@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

Build changes look good. Thanks for removing this special case in the build!

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22774#pullrequestreview-2675130279

From weijun at openjdk.org  Tue Mar 11 16:04:55 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Mar 2025 16:04:55 GMT
Subject: RFR: 8351349: GSSUtil.createSubject has outdated access control
 context and policy related text [v2]
In-Reply-To: <Er8Pju3EAvqKP8B_M1hMV7KtFtK3nLTmIqmg3m1hw1w=.41c06f8b-2938-4ae6-a658-bfb86aa9a02a@github.com>
References: <hWsuhosMWi9X8YjQt3Z0TamRiPDgdURT8j-_19gJwVA=.8eb57c34-3da7-4277-a882-4249b5d47eff@github.com>
 <Er8Pju3EAvqKP8B_M1hMV7KtFtK3nLTmIqmg3m1hw1w=.41c06f8b-2938-4ae6-a658-bfb86aa9a02a@github.com>
Message-ID: <jw7iZRCDkmBRN8BtHRbfT8QMqSheTS5beZx_2oZIMA8=.e61aa7d8-1224-4f30-af51-e0c0c6d66f50@github.com>

On Tue, 11 Mar 2025 12:49:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Please review this change to remove outdated access control context and policy related text from the `com.sun.security.jgss.GSSUtil` class which no longer applies now that JEP 486 disabled the Security Manager. 
>> 
>> I also made a few other minor changes, adding code tags around class names and changing "Sun Microsystem's" to "the JDK" in the class description.
>> 
>> I will also file a CSR.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore part of second sentence. Move @return to end.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23970#pullrequestreview-2675226044

From fguallini at openjdk.org  Tue Mar 11 16:07:58 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Tue, 11 Mar 2025 16:07:58 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method
In-Reply-To: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
Message-ID: <xJeDQYqlcdNIAuz2QZj4DyZJU02GGrXIrIaf2FxZyXw=.fb991be9-0428-4b10-9a4e-730d6ac758c8@github.com>

On Tue, 11 Mar 2025 15:21:09 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.

test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 90:

> 88:                 generateInitialKeystores(opensslPath);
> 89:                 testWithJavaCommands();
> 90:                 testWithOpensslCommands(opensslPath);

should only `try catch` the Artifact fetching line, as other test methods could potentially throw an IOException and it could get hidden with a SkippedException
Suggestion:

            String opensslPath;
            try {
                opensslPath = OpensslArtifactFetcher.getOpensslPath();
            } catch (IOException exc) {
                String exMsg = "Can't find the version: "
                        + OpensslArtifactFetcher.getTestOpensslBundleVersion()
                        + " of openssl binary on this machine, please install"
                        + " and set openssl path with property 'test.openssl.path'";
                throw new SkippedException(exMsg);
            }
            // if the current version of openssl is available, perform all
            // keytool <-> openssl interop tests
            generateInitialKeystores(opensslPath);
            testWithJavaCommands();
            testWithOpensslCommands(opensslPath);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1989633922

From ascarpino at openjdk.org  Tue Mar 11 16:49:49 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 11 Mar 2025 16:49:49 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v5]
In-Reply-To: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
Message-ID: <_6CxG2DQbtkrtH7oVDI30xwt4_zsJdIMALsjdvPRBM4=.dc1fe2a4-ddba-4d83-9570-b1055e4d251c@github.com>

> Hi,
> 
> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
> 
> thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  check for dup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23647/files
  - new: https://git.openjdk.org/jdk/pull/23647/files/b26118a5..a0fc101f

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

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

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

From mdonovan at openjdk.org  Tue Mar 11 16:53:18 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 11 Mar 2025 16:53:18 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <xJeDQYqlcdNIAuz2QZj4DyZJU02GGrXIrIaf2FxZyXw=.fb991be9-0428-4b10-9a4e-730d6ac758c8@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <xJeDQYqlcdNIAuz2QZj4DyZJU02GGrXIrIaf2FxZyXw=.fb991be9-0428-4b10-9a4e-730d6ac758c8@github.com>
Message-ID: <MMT75QGFi-cdUVzvjUvMRlJzHbfiEL27dLrCPCxh1jg=.cae8f69f-f790-49a6-82b8-3912cac2a338@github.com>

On Tue, 11 Mar 2025 15:59:53 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed exception message in Artifact resolver and fixed logic in keytool test
>
> test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 90:
> 
>> 88:                 generateInitialKeystores(opensslPath);
>> 89:                 testWithJavaCommands();
>> 90:                 testWithOpensslCommands(opensslPath);
> 
> should only `try catch` the Artifact fetching line, as other test methods could potentially throw an IOException and it could get hidden with a SkippedException
> Suggestion:
> 
>             String opensslPath;
>             try {
>                 opensslPath = OpensslArtifactFetcher.getOpensslPath();
>             } catch (IOException exc) {
>                 String exMsg = "Can't find the version: "
>                         + OpensslArtifactFetcher.getTestOpensslBundleVersion()
>                         + " of openssl binary on this machine, please install"
>                         + " and set openssl path with property 'test.openssl.path'";
>                 throw new SkippedException(exMsg);
>             }
>             // if the current version of openssl is available, perform all
>             // keytool <-> openssl interop tests
>             generateInitialKeystores(opensslPath);
>             testWithJavaCommands();
>             testWithOpensslCommands(opensslPath);

Yep, that makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1989731829

From mdonovan at openjdk.org  Tue Mar 11 16:53:17 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 11 Mar 2025 16:53:17 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
Message-ID: <QvHt-NFFoQmDsPyZ3g9kR05hK8hKhaadcrHbBbitSzs=.61d5d08a-bb4a-4a6e-9024-9fcc81272b86@github.com>

> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  Changed exception message in Artifact resolver and fixed logic in keytool test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23989/files
  - new: https://git.openjdk.org/jdk/pull/23989/files/43df6791..83d479cb

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

  Stats: 23 lines in 2 files changed: 7 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23989/head:pull/23989

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

From mdonovan at openjdk.org  Tue Mar 11 16:53:18 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 11 Mar 2025 16:53:18 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <0OAiXFUeGf-WMLT67obiWbt0WE-y9VBWA5j5XAZN-Qg=.bdd4803c-9baa-4d08-b5fb-f45052fe6bdc@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <0OAiXFUeGf-WMLT67obiWbt0WE-y9VBWA5j5XAZN-Qg=.bdd4803c-9baa-4d08-b5fb-f45052fe6bdc@github.com>
Message-ID: <xuh8RRLWcXIt3_Dt0vttkS4xCQaj7e8htf3oAU65z44=.136cfba3-b46a-4305-8d96-c4aa704b935f@github.com>

On Tue, 11 Mar 2025 15:39:17 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed exception message in Artifact resolver and fixed logic in keytool test
>
> test/jdk/sun/security/provider/acvp/Launcher.java line 181:
> 
>> 179:     }
>> 180: 
>> 181:     private static Path fetchACVPServerTests(Class<?> clazz) {
> 
> Is there a point in this method? It's used in 1 spot only it seems and you can just directly call `fetchOne`

It encapsulates all of the logic involved in getting the tests. Specifically, what to do if the tests can't be fetched. It could be done in `main()` but this is a little cleaner.

> test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 100:
> 
>> 98:             Throwable cause = e.getCause();
>> 99:             if (cause == null) {
>> 100:                 // if property doesn't exist
> 
> As per our discussion, do you think doing it in a way similar to [this](https://github.com/openjdk/jdk/pull/23988/files#diff-65002682c363b32a2f5bc860ec7482f3682cceb2d2c748e5b9d3aa4aedf88d35R66-R72) would be easier to read during a debug?

I updated the message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1989684931
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1989733346

From kdriver at openjdk.org  Tue Mar 11 17:30:54 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 11 Mar 2025 17:30:54 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v8]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <-GI15YUilcH7a-cOo2ebAHkRU0UUtN893Py8Vd-OlO8=.36327085-2735-49e7-8581-d219c6511ae5@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/4c78b9fd..64061d98

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

  Stats: 49 lines in 3 files changed: 40 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22222/head:pull/22222

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

From rhalade at openjdk.org  Tue Mar 11 17:34:28 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 11 Mar 2025 17:34:28 GMT
Subject: RFR: 8303770: Remove Baltimore root certificate expiring in May 2025
Message-ID: <Hcsn7pFjVHvetnBbotzYTnWap2tSHc9Tey014rjy9ew=.5ed09b47-667b-4fdf-ac73-6ab934c7316a@github.com>

Removed "_CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE_" root certificate expiring in May 2025 from cacerts truststore. No code signing certificates were issued from CA.

The release-note is at [JDK-8351686](https://bugs.openjdk.org/browse/JDK-8351686)

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

Commit messages:
 - 8303770: Remove Baltimore root certificate expiring in May 2025

Changes: https://git.openjdk.org/jdk/pull/23992/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23992&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303770
  Stats: 34 lines in 2 files changed: 0 ins; 30 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23992.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23992/head:pull/23992

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

From myankelevich at openjdk.org  Tue Mar 11 18:38:35 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 11 Mar 2025 18:38:35 GMT
Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java
 test [v4]
In-Reply-To: <xLs-5ELobHMgCFIm_lQMF_ax6c8EeyIpCS-HQPGCBVc=.47737b0f-9d47-4472-9777-7af5c6de76ff@github.com>
References: <xLs-5ELobHMgCFIm_lQMF_ax6c8EeyIpCS-HQPGCBVc=.47737b0f-9d47-4472-9777-7af5c6de76ff@github.com>
Message-ID: <HMI9_7Xz9BgZM4CcziHSLHR1ooDcmyNQr7fKdAfOxK0=.291c7605-22d4-40f7-9e2e-ac928a0caf25@github.com>

> Moved the sh file logic to jtreg java test.

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

  Multiple logins test now extends PKCS11Test
  
  * Multiple logins test now extends PKCS11Test
  * cleanup
  * skip exceptions are now throws

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23590/files
  - new: https://git.openjdk.org/jdk/pull/23590/files/0969eaea..3dbd4868

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

  Stats: 54 lines in 1 file changed: 3 ins; 32 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23590/head:pull/23590

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

From myankelevich at openjdk.org  Tue Mar 11 18:38:35 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 11 Mar 2025 18:38:35 GMT
Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java
 test [v3]
In-Reply-To: <_mLcbhS52MiucUEc7O_EUQaxen54I8xhfw9eT_vloos=.2d24a5d9-55b4-4a61-b87d-df19adac3c8f@github.com>
References: <xLs-5ELobHMgCFIm_lQMF_ax6c8EeyIpCS-HQPGCBVc=.47737b0f-9d47-4472-9777-7af5c6de76ff@github.com>
 <ybV8naPPTf9P-2T6XmSZHklIaBIwRyElHf2_hRwz4qw=.1bb77a49-5975-4d45-9cd5-3964dcd4af34@github.com>
 <VJYv8dUJ02oRxOmU_G30xI3lLMk-U9xyfjAz8674imw=.3f24af82-6afc-4196-9d3a-5fcc19d5a5fc@github.com>
 <_mLcbhS52MiucUEc7O_EUQaxen54I8xhfw9eT_vloos=.2d24a5d9-55b4-4a61-b87d-df19adac3c8f@github.com>
Message-ID: <FSGryq-PlNmeoftxAtspTZW_XoTW7BYgJKHvcP-bQig=.9f40afe3-7d39-4c1f-b1db-b2f33089ffd6@github.com>

On Tue, 25 Feb 2025 17:50:53 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 63:
>> 
>>> 61:     private static final SunPKCS11[] providers = new SunPKCS11[NUM_PROVIDERS];
>>> 62: 
>>> 63:     private static void copyDbFiles() throws IOException {
>> 
>> We have existing utility method for this at https://github.com/openjdk/jdk/blob/a49f8332edc7da2a9494cd0dc96e5aa7271d9883/test/jdk/sun/security/pkcs11/PKCS11Test.java#L846.
>
> We are looking to refactor the PKCS11Test.java, this will be addressed then. I will hold this review until we decide the right approach.

The new commit has the test extending the PKCS11Test, so this should be changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23590#discussion_r1989921907

From myankelevich at openjdk.org  Tue Mar 11 18:39:00 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 11 Mar 2025 18:39:00 GMT
Subject: RFR: 8349534: Refactor jdk/sun/security/krb5/runNameEquals.sh to
 java test [v4]
In-Reply-To: <wZM8gqLJEnNx_btH_IwDuWruv7Wfpm27a8B23IAqsB0=.89141cff-96a8-46dc-bb0a-cda18d460090@github.com>
References: <eobPPsQSAcjTyqaTKXm_M7ithtwr6bA27Sb2UvFC2W0=.aef7bdf2-b49b-4900-aa28-a77d792a89ec@github.com>
 <wZM8gqLJEnNx_btH_IwDuWruv7Wfpm27a8B23IAqsB0=.89141cff-96a8-46dc-bb0a-cda18d460090@github.com>
Message-ID: <biTy-dwF4v1M_E87pMNuSX16IqDNMd-FZxBEELGK7dM=.0b9ad2e8-2bb0-44a1-b263-0ef287717b23@github.com>

On Tue, 11 Feb 2025 18:46:29 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Refactored the runNameEquals.sh to java test
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

Still needs an approval

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

PR Comment: https://git.openjdk.org/jdk/pull/23542#issuecomment-2715363893

From duke at openjdk.org  Tue Mar 11 19:29:06 2025
From: duke at openjdk.org (duke)
Date: Tue, 11 Mar 2025 19:29:06 GMT
Subject: RFR: 8345940: Migrate security-related resources from Java classes
 to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <joV_S3_Xkms97gK-ZPrW3mA3GyTTDTa0YsRUtuutZ8w=.5bad390d-c0bf-4dfc-9fbf-86c5d3b4882a@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

@artur-oracle 
Your change (at version 7d911bce09aa7ee1684a6f35cdb11e96167a53a3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22774#issuecomment-2715472109

From myankelevich at openjdk.org  Tue Mar 11 19:36:00 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 11 Mar 2025 19:36:00 GMT
Subject: RFR: 8349151: Refactor
 test/java/security/cert/CertificateFactory/slowstream.sh to java test [v2]
In-Reply-To: <YxpkzCsGkG_ZpZxY4EDOSrS15qnO-_cdAzdCSRj7zvw=.9ee33d58-d943-4ca6-aff5-a661184b3587@github.com>
References: <aNFXXgPHvdXyZpWzC-S6zuZffvOyp-y-55mN092KlC8=.4d248a23-f9c9-4aed-960c-3c3e9b4ac2e3@github.com>
 <YxpkzCsGkG_ZpZxY4EDOSrS15qnO-_cdAzdCSRj7zvw=.9ee33d58-d943-4ca6-aff5-a661184b3587@github.com>
Message-ID: <SlB_ioMurAr1NeCGvFzkidGodo6AvsvZU2WpRh_rZ1I=.2de2e15d-d62d-4aef-b3e5-e19868a0a23a@github.com>

On Mon, 3 Feb 2025 19:12:30 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

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

Still needs a review

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

PR Comment: https://git.openjdk.org/jdk/pull/23394#issuecomment-2715494826

From mullan at openjdk.org  Tue Mar 11 20:03:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 11 Mar 2025 20:03:06 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v8]
In-Reply-To: <oQNDxVW64uL_Fx9JA89jawXiUvjUhco0S7ydaQ_jKNE=.4eefe68f-9bbd-467e-8420-6daab658835a@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <oQNDxVW64uL_Fx9JA89jawXiUvjUhco0S7ydaQ_jKNE=.4eefe68f-9bbd-467e-8420-6daab658835a@github.com>
Message-ID: <kGRKaOEIRVyk5GgwdB9-g9XMIxB2qnFRPbRR-mqY1PE=.840c6102-70cc-440a-ab9e-1064fe0153b3@github.com>

On Mon, 3 Mar 2025 15:57:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> 
>> ![HPKEParameterSpec](https://github.com/user-attachments/assets/3f00d234-e92c-4a5f-8d2f-15f668a7ff08)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add mode_auth and mode_auth_psk, tiny spec change

src/java.base/share/classes/sun/security/util/SliceableSecretKey.java line 1:

> 1: /*

I'm not used to the javadoc markdown `///` syntax. Maybe I'll get used to it, but is there a reason you are using it in internal classes?

src/java.base/share/classes/sun/security/util/SliceableSecretKey.java line 29:

> 27: import javax.crypto.SecretKey;
> 28: 
> 29: /// An interface for `SecretKey`s that supports using its slice as a new

s/supports/support/

src/java.base/share/classes/sun/security/util/SliceableSecretKey.java line 32:

> 30: /// `SecretKey`.
> 31: ///
> 32: /// This is mainly used by PKCS #11 implementations that supports the

s/supports/support/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1990047332
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1990036780
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1990037201

From abarashev at openjdk.org  Tue Mar 11 20:10:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 11 Mar 2025 20:10:04 GMT
Subject: Integrated: 8345940: Migrate security-related resources from Java
 classes to properties files
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <FCtiyh0S_yfUYdLgDUGKtOQkoK0lNKLxRlzJbVtCgcQ=.7b72dbba-e11c-4717-a32d-8c1a75b19c42@github.com>

On Mon, 16 Dec 2024 22:03:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

This pull request has now been integrated.

Changeset: 9a494181
Author:    Artur Barashev <abarashev at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a49418138b93bc8ed8879be5c9b9b9c85ef47e1
Stats:     16201 lines in 83 files changed: 6064 ins; 10109 del; 28 mod

8345940: Migrate security-related resources from Java classes to properties files

Reviewed-by: jlu, weijun, erikj

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

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

From weijun at openjdk.org  Tue Mar 11 21:12:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Mar 2025 21:12:54 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v9]
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: <BqaEhBOr52NFBSZDPqBBOV3UoTEK0GLsHcedXv_y8cI=.ff376de5-dc07-4e4c-af7b-156b30fa916d@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> ![HPKEParameterSpec](https://github.com/user-attachments/assets/4a7e6609-fd64-444a-978f-bde1634caa70)

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

  of(kdf_id, aead_id) and constants

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/5b0f319c..9360dfd2

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

  Stats: 229 lines in 4 files changed: 177 ins; 12 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/18411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411

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

From weijun at openjdk.org  Tue Mar 11 21:12:56 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Mar 2025 21:12:56 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v8]
In-Reply-To: <kGRKaOEIRVyk5GgwdB9-g9XMIxB2qnFRPbRR-mqY1PE=.840c6102-70cc-440a-ab9e-1064fe0153b3@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <oQNDxVW64uL_Fx9JA89jawXiUvjUhco0S7ydaQ_jKNE=.4eefe68f-9bbd-467e-8420-6daab658835a@github.com>
 <kGRKaOEIRVyk5GgwdB9-g9XMIxB2qnFRPbRR-mqY1PE=.840c6102-70cc-440a-ab9e-1064fe0153b3@github.com>
Message-ID: <Wwo5gf_8_SvPn6QuczmIwphn-UOA9gs6WVqC93JZohQ=.027fc096-2ceb-494d-b76d-d9c798c696bf@github.com>

On Tue, 11 Mar 2025 19:59:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add mode_auth and mode_auth_psk, tiny spec change
>
> src/java.base/share/classes/sun/security/util/SliceableSecretKey.java line 1:
> 
>> 1: /*
> 
> I'm not used to the javadoc markdown `///` syntax. Maybe I'll get used to it, but is there a reason you are using it in internal classes?

Yes, I try to practice it in internal classes.

> src/java.base/share/classes/sun/security/util/SliceableSecretKey.java line 29:
> 
>> 27: import javax.crypto.SecretKey;
>> 28: 
>> 29: /// An interface for `SecretKey`s that supports using its slice as a new
> 
> s/supports/support/

Oops.

> src/java.base/share/classes/sun/security/util/SliceableSecretKey.java line 32:
> 
>> 30: /// `SecretKey`.
>> 31: ///
>> 32: /// This is mainly used by PKCS #11 implementations that supports the
> 
> s/supports/support/

Oops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1990128208
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1990129373
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1990128859

From weijun at openjdk.org  Tue Mar 11 21:17:07 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Mar 2025 21:17:07 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v9]
In-Reply-To: <BqaEhBOr52NFBSZDPqBBOV3UoTEK0GLsHcedXv_y8cI=.ff376de5-dc07-4e4c-af7b-156b30fa916d@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <BqaEhBOr52NFBSZDPqBBOV3UoTEK0GLsHcedXv_y8cI=.ff376de5-dc07-4e4c-af7b-156b30fa916d@github.com>
Message-ID: <JWexClx7YNdLFMqeTRjdq9kGC_Q-pr15Mv4d_WOdxqM=.7dd8aa06-603c-4b10-a94c-ec76eb73422a@github.com>

On Tue, 11 Mar 2025 21:12:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> ![HPKEParameterSpec](https://github.com/user-attachments/assets/4a7e6609-fd64-444a-978f-bde1634caa70)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   of(kdf_id, aead_id) and constants

I've just added a new `HPKEParameterSpec::of` that only takes KDF and AEAD ids. The reason is that these 2 are really user-choosable and KEM id is usually determined by the key type.

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

PR Comment: https://git.openjdk.org/jdk/pull/18411#issuecomment-2715722524

From duke at openjdk.org  Tue Mar 11 21:39:59 2025
From: duke at openjdk.org (Bernd)
Date: Tue, 11 Mar 2025 21:39:59 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v9]
In-Reply-To: <JWexClx7YNdLFMqeTRjdq9kGC_Q-pr15Mv4d_WOdxqM=.7dd8aa06-603c-4b10-a94c-ec76eb73422a@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <BqaEhBOr52NFBSZDPqBBOV3UoTEK0GLsHcedXv_y8cI=.ff376de5-dc07-4e4c-af7b-156b30fa916d@github.com>
 <JWexClx7YNdLFMqeTRjdq9kGC_Q-pr15Mv4d_WOdxqM=.7dd8aa06-603c-4b10-a94c-ec76eb73422a@github.com>
Message-ID: <-WB7s_SDm1sq3fGWJGMkYODIMRy2dSYORu7l2JCfXRs=.57c48873-8dbd-47c3-aaf9-3f10a2ba7248@github.com>

On Tue, 11 Mar 2025 21:14:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> usually determined by the key type.

Hm, might be a bit more complicated for PQ/T Hybrid KEMs. It can of course be added later on, as the implementations using that (like Xwing for HPKE with JOSE) are still in draft state.

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

PR Comment: https://git.openjdk.org/jdk/pull/18411#issuecomment-2715762541

From weijun at openjdk.org  Tue Mar 11 21:54:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Mar 2025 21:54:57 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v8]
In-Reply-To: <-GI15YUilcH7a-cOo2ebAHkRU0UUtN893Py8Vd-OlO8=.36327085-2735-49e7-8581-d219c6511ae5@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <-GI15YUilcH7a-cOo2ebAHkRU0UUtN893Py8Vd-OlO8=.36327085-2735-49e7-8581-d219c6511ae5@github.com>
Message-ID: <r9S1aTThzF_jiT1ZzDnz1V8JZtbZ830Y8zF2-8laqJM=.93bef905-02f2-43a7-8249-69d5cdf723ff@github.com>

On Tue, 11 Mar 2025 17:30:54 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

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

> 1991:                 hasMultipleManifests = true;
> 1992:             }
> 1993:         }

Can we put everything above in a try-with-resources block?

Also, are you sure we only print out this warning when `verbose != null`?

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java line 160:

> 158:         {"jar.treated.unsigned.see.weak.verbose",
> 159:                 "WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:"},
> 160:         {"multiple.manifest.warning.", "Duplicate manifest entries were detected in the jar file. JarSigner will operate on the first one found and others will be discarded."},

I actually don't know which one will be operated on. If you are sure it is the first one, can you add some lines in the test to check this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1990173274
PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1990174513

From weijun at openjdk.org  Tue Mar 11 23:51:55 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 11 Mar 2025 23:51:55 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v9]
In-Reply-To: <BqaEhBOr52NFBSZDPqBBOV3UoTEK0GLsHcedXv_y8cI=.ff376de5-dc07-4e4c-af7b-156b30fa916d@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <BqaEhBOr52NFBSZDPqBBOV3UoTEK0GLsHcedXv_y8cI=.ff376de5-dc07-4e4c-af7b-156b30fa916d@github.com>
Message-ID: <Y2jnAA5bVWFI9jX-PW6r84DzrrZHcAySE0Jv46VdfP4=.c2ede711-791b-4942-938e-909297e6e006@github.com>

On Tue, 11 Mar 2025 21:12:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> ![HPKEParameterSpec](https://github.com/user-attachments/assets/4a7e6609-fd64-444a-978f-bde1634caa70)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   of(kdf_id, aead_id) and constants

We still have the 3-argument `of`. Also, for future PQ/T Hybrid KEMs, it looks like the trend is that a Hybrid algorithm will have its own `KeyPairGenerator` (so the user does not need to assemble the key themselves) and the key's algorithm (or parameter set name) will also be its own. So it's quite likely that one key type still has only one `kem_id`. Let's wait.

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

PR Comment: https://git.openjdk.org/jdk/pull/18411#issuecomment-2715981698

From shade at openjdk.org  Wed Mar 12 09:46:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Mar 2025 09:46:56 GMT
Subject: RFR: 8303770: Remove Baltimore root certificate expiring in May
 2025
In-Reply-To: <Hcsn7pFjVHvetnBbotzYTnWap2tSHc9Tey014rjy9ew=.5ed09b47-667b-4fdf-ac73-6ab934c7316a@github.com>
References: <Hcsn7pFjVHvetnBbotzYTnWap2tSHc9Tey014rjy9ew=.5ed09b47-667b-4fdf-ac73-6ab934c7316a@github.com>
Message-ID: <6rFNld27sWhH9dgwpJVEfC21HWdY8ajdJWgCt3gydt8=.13b8a24d-2af8-4f0c-8d60-c27b155cbc9c@github.com>

On Tue, 11 Mar 2025 17:28:17 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Removed "_CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE_" root certificate expiring in May 2025 from cacerts truststore. No code signing certificates were issued from CA.
> 
> The release-note is at [JDK-8351686](https://bugs.openjdk.org/browse/JDK-8351686)

Looks fine, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23992#pullrequestreview-2677751579

From myankelevich at openjdk.org  Wed Mar 12 10:39:04 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 12 Mar 2025 10:39:04 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <QvHt-NFFoQmDsPyZ3g9kR05hK8hKhaadcrHbBbitSzs=.61d5d08a-bb4a-4a6e-9024-9fcc81272b86@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <QvHt-NFFoQmDsPyZ3g9kR05hK8hKhaadcrHbBbitSzs=.61d5d08a-bb4a-4a6e-9024-9fcc81272b86@github.com>
Message-ID: <gQeNiOzbQz5HcXwQLjVP-bYnmu2NvuYlDaE3_1uE3jc=.76fb3ba4-25e2-488f-989f-d817cd008adf@github.com>

On Tue, 11 Mar 2025 16:53:17 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed exception message in Artifact resolver and fixed logic in keytool test

LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/23989#issuecomment-2717421676

From weijun at openjdk.org  Wed Mar 12 12:18:22 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Mar 2025 12:18:22 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
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: <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> ![HPKEParameterSpec](https://github.com/user-attachments/assets/4a7e6609-fd64-444a-978f-bde1634caa70)

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

  switch to Asserts.assertThrows in test; use traditional javadoc style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/9360dfd2..4bb17504

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

  Stats: 208 lines in 3 files changed: 8 ins; 79 del; 121 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 fguallini at openjdk.org  Wed Mar 12 12:19:59 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 12 Mar 2025 12:19:59 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <MMT75QGFi-cdUVzvjUvMRlJzHbfiEL27dLrCPCxh1jg=.cae8f69f-f790-49a6-82b8-3912cac2a338@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <xJeDQYqlcdNIAuz2QZj4DyZJU02GGrXIrIaf2FxZyXw=.fb991be9-0428-4b10-9a4e-730d6ac758c8@github.com>
 <MMT75QGFi-cdUVzvjUvMRlJzHbfiEL27dLrCPCxh1jg=.cae8f69f-f790-49a6-82b8-3912cac2a338@github.com>
Message-ID: <8RppYv2Kn7mnzlZzjJLKw1QdKKdTXUcxEZPb4Ylyhp8=.17f4bf9d-43a4-4025-9390-a66e2ab53b7e@github.com>

On Tue, 11 Mar 2025 16:48:03 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 90:
>> 
>>> 88:                 generateInitialKeystores(opensslPath);
>>> 89:                 testWithJavaCommands();
>>> 90:                 testWithOpensslCommands(opensslPath);
>> 
>> should only `try catch` the Artifact fetching line, as other test methods could potentially throw an IOException and it could get hidden with a SkippedException
>> Suggestion:
>> 
>>             String opensslPath;
>>             try {
>>                 opensslPath = OpensslArtifactFetcher.getOpensslPath();
>>             } catch (IOException exc) {
>>                 String exMsg = "Can't find the version: "
>>                         + OpensslArtifactFetcher.getTestOpensslBundleVersion()
>>                         + " of openssl binary on this machine, please install"
>>                         + " and set openssl path with property 'test.openssl.path'";
>>                 throw new SkippedException(exMsg);
>>             }
>>             // if the current version of openssl is available, perform all
>>             // keytool <-> openssl interop tests
>>             generateInitialKeystores(opensslPath);
>>             testWithJavaCommands();
>>             testWithOpensslCommands(opensslPath);
>
> Yep, that makes sense.

looks good thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991370585

From weijun at openjdk.org  Wed Mar 12 13:36:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Mar 2025 13:36:58 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <QvHt-NFFoQmDsPyZ3g9kR05hK8hKhaadcrHbBbitSzs=.61d5d08a-bb4a-4a6e-9024-9fcc81272b86@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <QvHt-NFFoQmDsPyZ3g9kR05hK8hKhaadcrHbBbitSzs=.61d5d08a-bb4a-4a6e-9024-9fcc81272b86@github.com>
Message-ID: <g3WqjgqFIoYZHmIDrdhfkxnvoQgw1qoL6Tc547DQpNc=.1ceb4d4a-8e96-4db1-972d-d00e9da3450d@github.com>

On Tue, 11 Mar 2025 16:53:17 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed exception message in Artifact resolver and fixed logic in keytool test

test/jdk/sun/security/pkcs11/PKCS11Test.java line 718:

> 716:     }
> 717: 
> 718:     private static Path fetchNssLib(String osId, Path libraryName) throws IOException {

Is the `IOException` caught later and wrapped as a `SkippedException`?

test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 103:

> 101:                 message = "Cannot find the artifact " + artifact.name();
> 102:             } else {
> 103:                 message = "Class " + klass.getName() + " missing @Artifact annotation.";

I assume it's a bug if `klass` is not annotated with `@Artifact`. I'd rather throw an NPE here so we can notice it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991504637
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991512616

From weijun at openjdk.org  Wed Mar 12 13:36:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Mar 2025 13:36:59 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <xuh8RRLWcXIt3_Dt0vttkS4xCQaj7e8htf3oAU65z44=.136cfba3-b46a-4305-8d96-c4aa704b935f@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <0OAiXFUeGf-WMLT67obiWbt0WE-y9VBWA5j5XAZN-Qg=.bdd4803c-9baa-4d08-b5fb-f45052fe6bdc@github.com>
 <xuh8RRLWcXIt3_Dt0vttkS4xCQaj7e8htf3oAU65z44=.136cfba3-b46a-4305-8d96-c4aa704b935f@github.com>
Message-ID: <F7zVhmYkAduwQqfKpLsVPUD_t0bkmj-I6-7L12-1jfk=.f8d953a0-6e76-4ed5-bbc0-311ff81f1dd0@github.com>

On Tue, 11 Mar 2025 16:24:23 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> test/jdk/sun/security/provider/acvp/Launcher.java line 181:
>> 
>>> 179:     }
>>> 180: 
>>> 181:     private static Path fetchACVPServerTests(Class<?> clazz) {
>> 
>> Is there a point in this method? It's used in 1 spot only it seems and you can just directly call `fetchOne`
>
> It encapsulates all of the logic involved in getting the tests. Specifically, what to do if the tests can't be fetched. It could be done in `main()` but this is a little cleaner.

I'd rather just let `ArtifactResolver.fetchOne` throw the `SkippedException`. Is that always what we need?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991507310

From duke at openjdk.org  Wed Mar 12 13:42:33 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Mar 2025 13:42:33 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v6]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <CY_w5CM4ZSozDcR8YQp8Bz_kCvv4g57pJlYTnuLma3w=.47f64d0e-2dd3-4785-aed0-254d93b61689@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Added validity test for the intrinsics.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/64135f29..f65ef7c4

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

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

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

From duke at openjdk.org  Wed Mar 12 13:51:58 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Mar 2025 13:51:58 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v5]
In-Reply-To: <qlwb4JKyY446ZQz5ZBdMN6SOblRZNQQ2gbNntRjiL2o=.8f5c1cb4-74d7-4005-832c-a44e170d3e33@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <3bphXKLpIpxAZP-FEOeob6AaHbv0BAoEceJka64vMW8=.3e4f74e0-9479-4926-b365-b08d8d702692@github.com>
 <qlwb4JKyY446ZQz5ZBdMN6SOblRZNQQ2gbNntRjiL2o=.8f5c1cb4-74d7-4005-832c-a44e170d3e33@github.com>
Message-ID: <vHbz488ucPSpzVNYFAI0mnVLcJtwTIq9w-GD2l4stMw=.5f324fd1-6c2c-4a2c-95d7-acb1e01d6780@github.com>

On Mon, 10 Mar 2025 03:00:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are no any new tests in the PR. How fix has been tested by openjdk tests?

I have just added one.

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

PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2717950685

From duke at openjdk.org  Wed Mar 12 13:52:02 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Mar 2025 13:52:02 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v4]
In-Reply-To: <P32zEjQp0CL9wYkVJU9i8pZa_VphYse1dv-DDOXE580=.30b087eb-29ca-40a2-bc34-6e802940bead@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <nmN_TxNaqRqSAVqYzrUhO9NXpzzixG6d1OsvBArpLsA=.857b5aa3-694a-4528-a922-c3fdab141ffa@github.com>
 <P32zEjQp0CL9wYkVJU9i8pZa_VphYse1dv-DDOXE580=.30b087eb-29ca-40a2-bc34-6e802940bead@github.com>
Message-ID: <DsStsOBPwSWrKYqBjHd164OUYUjAjKEJiXva8-OGcPo=.534b97d5-68e7-46d6-ad59-93cf31672026@github.com>

On Thu, 6 Mar 2025 14:30:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added alignment to loop entries.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Please update copyright year

Thanks, fixed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 96:
> 
>> 94:       StubRoutines::_dilithiumMontMulByConstant = generate_dilithiumMontMulByConstant_avx512();
>> 95:       StubRoutines::_dilithiumDecomposePoly = generate_dilithiumDecomposePoly_avx512();
>> 96:     }
> 
> Indentation fix needed

Thanks, fixed.

> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 362:
> 
>> 360:   const Register roundsLeft = r11;
>> 361: 
>> 362:   __ align(OptoLoopAlignment);
> 
> Redundant alignment before label should be before it's bind

Thanks, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1991546308
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1991546488
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1991546606

From duke at openjdk.org  Wed Mar 12 13:52:06 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Mar 2025 13:52:06 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v3]
In-Reply-To: <v0R-8kNylqKabqUJFfrIc8vcJ4tNMEfFm00stOcCxlo=.37519051-674e-41fe-80c8-60167e82f86b@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xYDRgjvW5AksXcXKUBnx7LlB4PmGEjEITKA27iHs4rE=.e69744e8-2fe9-4b0c-a49d-25177a2e8daf@github.com>
 <0E2AqFpNPjDjP6jqCXn8toePBcW2SIHw1kFXlZX4W_U=.8d692bfa-0598-4969-b480-4a285366e0bb@github.com>
 <V62AuLpV4oPamF6hi7zMdqs21tyw9i4ug_9UlNCQpNE=.2d6e0fcf-3e2c-406f-a336-bb2dedd923e8@github.com>
 <M5Z8mk-KZoytxUmhzRWKqUFtHRWoxY28Bfv8h_ijjMg=.351389d9-57d1-4589-a853-41125858760a@github.com>
 <wBKHcU8T9cMhYxLItWJ62IocCpPm9t8C4H_Ky4my9Fo=.fac18f07-5383-4333-b68e-031d376be1e2@github.com>
 <v0R-8kNylqKabqUJFfrIc8vcJ4tNMEfFm00stOcCxlo=.37519051-674e-41fe-80c8-60167e82f86b@github.com>
Message-ID: <74tlAsyoYwN-fvtFyxp3xJYo76U68oF0ES4UVy7S_iY=.01f96647-395e-49bb-9e5a-f047b63460e0@github.com>

On Thu, 6 Mar 2025 09:32:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I think the easiest is to put a for (int i = 0; i < 1000; i++) loop around  the switch statement in the run() method of  the ML_DSA_Test class (test/jdk/sun/security/provider/acvp/ML_DSA_Test.java). (This is because the intrinsics kick in after a few thousand calls of the method.)
>
> Hi @ferakocz , Yes, we should modify the test or lower the compilation threshold with -Xbatch -XX:TieredCompileThreshold=0.1.
> 
> Alternatively, since the tests has a depedency on Automatic Cryptographic Validation Test server I have created a simplified test which cover all the security levels.
> 
> Kindly include [test/hotspot/jtreg/compiler/intrinsics/signature/TestModuleLatticeDSA.java
> ](https://github.com/ferakocz/jdk/pull/1)

I have added a new command to the test test/jdk/sun/security/provider/acvp/Launcher.java. The line with the -Xcomp will invoke the intrinsics on the first call, so they will be tested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1991546056

From mdonovan at openjdk.org  Wed Mar 12 15:29:36 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 12 Mar 2025 15:29:36 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v3]
In-Reply-To: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
Message-ID: <pgpHLoZoD7wB19Wf5sn5Cm1wccPQ6wS-yIj555-PKy0=.6e856341-4511-4a4d-a6d7-09cb76b3cc57@github.com>

> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  Changed ArtifactResolver.fetchOne() to throw a skipped exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23989/files
  - new: https://git.openjdk.org/jdk/pull/23989/files/83d479cb..4791105e

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

  Stats: 28 lines in 4 files changed: 3 ins; 16 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23989/head:pull/23989

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

From mdonovan at openjdk.org  Wed Mar 12 15:29:36 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 12 Mar 2025 15:29:36 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v3]
In-Reply-To: <F7zVhmYkAduwQqfKpLsVPUD_t0bkmj-I6-7L12-1jfk=.f8d953a0-6e76-4ed5-bbc0-311ff81f1dd0@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <0OAiXFUeGf-WMLT67obiWbt0WE-y9VBWA5j5XAZN-Qg=.bdd4803c-9baa-4d08-b5fb-f45052fe6bdc@github.com>
 <xuh8RRLWcXIt3_Dt0vttkS4xCQaj7e8htf3oAU65z44=.136cfba3-b46a-4305-8d96-c4aa704b935f@github.com>
 <F7zVhmYkAduwQqfKpLsVPUD_t0bkmj-I6-7L12-1jfk=.f8d953a0-6e76-4ed5-bbc0-311ff81f1dd0@github.com>
Message-ID: <sYHPbTpOy2yKv_92lzUmPM-vhdDIJ_umlcqoCCIQWhw=.a882a667-464e-43a3-ad9a-05f6d4360f99@github.com>

On Wed, 12 Mar 2025 13:29:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> It encapsulates all of the logic involved in getting the tests. Specifically, what to do if the tests can't be fetched. It could be done in `main()` but this is a little cleaner.
>
> I'd rather just let `ArtifactResolver.fetchOne` throw the `SkippedException`. Is that always what we need?

I can't think of a reason why a test would want to continue if the file wasn't accessible. I moved the skippedexception into the`fetchOne` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991752961

From mdonovan at openjdk.org  Wed Mar 12 15:29:36 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 12 Mar 2025 15:29:36 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <g3WqjgqFIoYZHmIDrdhfkxnvoQgw1qoL6Tc547DQpNc=.1ceb4d4a-8e96-4db1-972d-d00e9da3450d@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <QvHt-NFFoQmDsPyZ3g9kR05hK8hKhaadcrHbBbitSzs=.61d5d08a-bb4a-4a6e-9024-9fcc81272b86@github.com>
 <g3WqjgqFIoYZHmIDrdhfkxnvoQgw1qoL6Tc547DQpNc=.1ceb4d4a-8e96-4db1-972d-d00e9da3450d@github.com>
Message-ID: <Z4XfGIpjwO0l9gw5qxbxz2pinXnvUfNiGWYarcTuhj0=.2e1b409e-6a7a-4dc4-b6ff-ce5ce88479e7@github.com>

On Wed, 12 Mar 2025 13:31:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed exception message in Artifact resolver and fixed logic in keytool test
>
> test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 103:
> 
>> 101:                 message = "Cannot find the artifact " + artifact.name();
>> 102:             } else {
>> 103:                 message = "Class " + klass.getName() + " missing @Artifact annotation.";
> 
> I assume it's a bug if `klass` is not annotated with `@Artifact`. I'd rather throw an NPE here so we can notice it.

Do you mean to just assume `artifact` is never null and let the NPE be thrown if it is?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991548009

From lmesnik at openjdk.org  Wed Mar 12 15:37:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 12 Mar 2025 15:37:12 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v6]
In-Reply-To: <CY_w5CM4ZSozDcR8YQp8Bz_kCvv4g57pJlYTnuLma3w=.47f64d0e-2dd3-4785-aed0-254d93b61689@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <CY_w5CM4ZSozDcR8YQp8Bz_kCvv4g57pJlYTnuLma3w=.47f64d0e-2dd3-4785-aed0-254d93b61689@github.com>
Message-ID: <di5vo1Muk6wtMW-lE-vuZ-Ii9njvH4EYEEO5kQwaKBA=.56e974af-8b57-46fc-aecb-e27834d6bf3f@github.com>

On Wed, 12 Mar 2025 13:42:33 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added validity test for the intrinsics.

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

> 41:  * @modules java.base/sun.security.provider
> 42:  * @run main Launcher
> 43:  * @run main/othervm -Xcomp Launcher

Thank you for adding this case. Please add it as a separate testcase:
/*
 * @test 
 * @summary Test verifies intrinsic implementation. 
 * @library /test/lib
 * @modules java.base/sun.security.provider
 * @run main/othervm -Xcomp Launcher
 */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1991769739

From abarashev at openjdk.org  Wed Mar 12 16:01:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 12 Mar 2025 16:01:55 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v17]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <yuzzImd6k_2hQZPlp2Kq1_HUDzSm976_Gs06hxQIMVg=.dedc5a7f-a741-41c5-943f-46e902cf3d14@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

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 20 additional commits since the last revision:

 - Rename usage constraints to HandshakeSignature and CertificateSignature
 - Merge branch 'master' into JDK-8349583
 - Constraint description update
 - Update constraint description
 - Move SSLScope class description below the package
 - Merge branch 'master' into JDK-8349583
 - Remove the fix for JDK-8350807. Update documentation.
 - Update documentation and unit tests to signal TLS scope case-insensitivity
 - Update 2 more copyrights
 - Update TLS version in one more unit test
 - ... and 10 more: https://git.openjdk.org/jdk/compare/d9d07e80...3320ecbb

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/32ec7810..3320ecbb

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

  Stats: 67886 lines in 1361 files changed: 31053 ins; 24859 del; 11974 mod
  Patch: https://git.openjdk.org/jdk/pull/23681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681

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

From weijun at openjdk.org  Wed Mar 12 16:07:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Mar 2025 16:07:54 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <Z4XfGIpjwO0l9gw5qxbxz2pinXnvUfNiGWYarcTuhj0=.2e1b409e-6a7a-4dc4-b6ff-ce5ce88479e7@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <QvHt-NFFoQmDsPyZ3g9kR05hK8hKhaadcrHbBbitSzs=.61d5d08a-bb4a-4a6e-9024-9fcc81272b86@github.com>
 <g3WqjgqFIoYZHmIDrdhfkxnvoQgw1qoL6Tc547DQpNc=.1ceb4d4a-8e96-4db1-972d-d00e9da3450d@github.com>
 <Z4XfGIpjwO0l9gw5qxbxz2pinXnvUfNiGWYarcTuhj0=.2e1b409e-6a7a-4dc4-b6ff-ce5ce88479e7@github.com>
Message-ID: <fChaWh4lbZ1MX5n8IVLBzzmoCT1i7yR_t2pbP6ajeBo=.354abb99-5391-4f97-87d2-8220af167653@github.com>

On Wed, 12 Mar 2025 13:50:06 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 103:
>> 
>>> 101:                 message = "Cannot find the artifact " + artifact.name();
>>> 102:             } else {
>>> 103:                 message = "Class " + klass.getName() + " missing @Artifact annotation.";
>> 
>> I assume it's a bug if `klass` is not annotated with `@Artifact`. I'd rather throw an NPE here so we can notice it.
>
> Do you mean to just assume `artifact` is never null and let the NPE be thrown if it is?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991830403

From mdonovan at openjdk.org  Wed Mar 12 16:36:54 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 12 Mar 2025 16:36:54 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <g3WqjgqFIoYZHmIDrdhfkxnvoQgw1qoL6Tc547DQpNc=.1ceb4d4a-8e96-4db1-972d-d00e9da3450d@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <QvHt-NFFoQmDsPyZ3g9kR05hK8hKhaadcrHbBbitSzs=.61d5d08a-bb4a-4a6e-9024-9fcc81272b86@github.com>
 <g3WqjgqFIoYZHmIDrdhfkxnvoQgw1qoL6Tc547DQpNc=.1ceb4d4a-8e96-4db1-972d-d00e9da3450d@github.com>
Message-ID: <dF0KqYE1_fl0hcmK4nF7gxQYCfue7juKmytSzIVhPtQ=.4cf79c1f-0b95-4f2e-a4c1-ade22df3f877@github.com>

On Wed, 12 Mar 2025 13:27:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed exception message in Artifact resolver and fixed logic in keytool test
>
> test/jdk/sun/security/pkcs11/PKCS11Test.java line 718:
> 
>> 716:     }
>> 717: 
>> 718:     private static Path fetchNssLib(String osId, Path libraryName) throws IOException {
> 
> Is the `IOException` caught later and wrapped as a `SkippedException`?

I changed `ArtifactResolver.fetchOne()` to throw a SkippedException but this method still throws an IOException if the nss directory/artifact doesn't contain the necessary files. That case is handled by different tests and I didn't want to change it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991882025

From mdonovan at openjdk.org  Wed Mar 12 16:43:14 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 12 Mar 2025 16:43:14 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v2]
In-Reply-To: <fChaWh4lbZ1MX5n8IVLBzzmoCT1i7yR_t2pbP6ajeBo=.354abb99-5391-4f97-87d2-8220af167653@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <QvHt-NFFoQmDsPyZ3g9kR05hK8hKhaadcrHbBbitSzs=.61d5d08a-bb4a-4a6e-9024-9fcc81272b86@github.com>
 <g3WqjgqFIoYZHmIDrdhfkxnvoQgw1qoL6Tc547DQpNc=.1ceb4d4a-8e96-4db1-972d-d00e9da3450d@github.com>
 <Z4XfGIpjwO0l9gw5qxbxz2pinXnvUfNiGWYarcTuhj0=.2e1b409e-6a7a-4dc4-b6ff-ce5ce88479e7@github.com>
 <fChaWh4lbZ1MX5n8IVLBzzmoCT1i7yR_t2pbP6ajeBo=.354abb99-5391-4f97-87d2-8220af167653@github.com>
Message-ID: <aCvWTXVI7n8Aq4PxfQyNRoqouClaDEflrVQn7nln58Q=.5d052c0e-4526-42ea-9bf2-5305b841060e@github.com>

On Wed, 12 Mar 2025 16:05:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Do you mean to just assume `artifact` is never null and let the NPE be thrown if it is?
>
> Yes.

I updated the code to reflect that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991893033

From weijun at openjdk.org  Wed Mar 12 16:43:13 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Mar 2025 16:43:13 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v3]
In-Reply-To: <pgpHLoZoD7wB19Wf5sn5Cm1wccPQ6wS-yIj555-PKy0=.6e856341-4511-4a4d-a6d7-09cb76b3cc57@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <pgpHLoZoD7wB19Wf5sn5Cm1wccPQ6wS-yIj555-PKy0=.6e856341-4511-4a4d-a6d7-09cb76b3cc57@github.com>
Message-ID: <ngF3csuZyd229w_ldh2AYLRiwxGoJyhGCfk0_ChWxFk=.266ad385-925c-474b-9972-277aceae8efe@github.com>

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

>> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed ArtifactResolver.fetchOne() to throw a skipped exception

test/jdk/sun/security/pkcs11/PKCS11Test.java line 749:

> 747:     private static Path fetchNssLib(Class<?> clazz, Path libraryName) throws IOException {
> 748:         Path p = ArtifactResolver.fetchOne(clazz);
> 749:         return findNSSLibrary(p, libraryName);

So this method should never return null. Can we change `fetchNssLib(String osId, Path libraryName)` to also never return null (default throws `SkippedException`)? Then inside `getNSSLibPath(String library)` there is no need for the null check.

test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 85:

> 83:         if (generatePKCS12) {
> 84:             String opensslPath = OpensslArtifactFetcher.getOpensslPath();
> 85:             if (opensslPath == null) {

Can we modify `OpensslArtifactFetcher.getOpensslPath()` so that the `SkippedException` is thrown inside it when the version check fails at the last line? You are already throwing this exception when `fetchOpenssl` is called there.

This makes sure the return value is never null, and it's consistent to `ArtifactResolver.fetchOne`. You can add a `@throws` javadoc there for clarity.

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

> 27: import jtreg.SkippedException;
> 28: 
> 29: import java.io.IOException;

Useless now. The `import jtreg.SkippedException` is also useless.

test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 28:

> 26: import jtreg.SkippedException;
> 27: 
> 28: import java.io.IOException;

Useless now.

test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 78:

> 76:      * <p>
> 77:      * Artifacts are defined with the {@link jdk.test.lib.artifacts.Artifact}
> 78:      * annotation. The file name should have the format ARTIFACT_NAME-VERSION.EXT

It could also be a directory, right? So maybe `path name` is more precise.

Also, you haven't defined what each piece in ARTIFACT_NAME-VERSION.EXT is. On the other hand, the names in `Artifact` are `name`, `revision`, and `extension`.

test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 81:

> 79:      * <p>
> 80:      * If you have a local version of a dependency that you want to use, you can
> 81:      * specify that by setting the System property:

No need to capitalize `system`.

test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 92:

> 90:      * @return the local path to the artifact. If the artifact is a compressed
> 91:      * file that gets unpacked, this path will point to the root
> 92:      * directory of the uncompressed file.

Maybe `file(s)`?

test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java line 26:

> 24: package jdk.test.lib.security;
> 25: 
> 26: import java.io.IOException;

Useless now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991892312
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991851644
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991834832
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991857027
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991859352
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991860392
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991866853
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1991874705

From mullan at openjdk.org  Wed Mar 12 16:45:02 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Mar 2025 16:45:02 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v8]
In-Reply-To: <-GI15YUilcH7a-cOo2ebAHkRU0UUtN893Py8Vd-OlO8=.36327085-2735-49e7-8581-d219c6511ae5@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <-GI15YUilcH7a-cOo2ebAHkRU0UUtN893Py8Vd-OlO8=.36327085-2735-49e7-8581-d219c6511ae5@github.com>
Message-ID: <mtriLgdBudUrNwMvu9GR6fV_2yL6LC3JREJTuQNKxfc=.f65c345f-0208-4ff7-b6a0-0f16b363bb0d@github.com>

On Tue, 11 Mar 2025 17:30:54 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

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

> 1255:             }
> 1256: 
> 1257:             if(hasMultipleManifests) {

Nit: add space after `if`, also on lines 1983, 1990.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1991896538

From mullan at openjdk.org  Wed Mar 12 17:05:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 12 Mar 2025 17:05:55 GMT
Subject: RFR: 8303770: Remove Baltimore root certificate expiring in May
 2025
In-Reply-To: <Hcsn7pFjVHvetnBbotzYTnWap2tSHc9Tey014rjy9ew=.5ed09b47-667b-4fdf-ac73-6ab934c7316a@github.com>
References: <Hcsn7pFjVHvetnBbotzYTnWap2tSHc9Tey014rjy9ew=.5ed09b47-667b-4fdf-ac73-6ab934c7316a@github.com>
Message-ID: <EBzwkNIZDo-ujpQWLIxSuVU6xsqdCP7yX9lXjnNX9NU=.7d380ece-24d2-4d35-9789-90d146dfd546@github.com>

On Tue, 11 Mar 2025 17:28:17 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Removed "_CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE_" root certificate expiring in May 2025 from cacerts truststore. No code signing certificates were issued from CA.
> 
> The release-note is at [JDK-8351686](https://bugs.openjdk.org/browse/JDK-8351686)

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23992#pullrequestreview-2679251211

From rhalade at openjdk.org  Wed Mar 12 17:23:09 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 12 Mar 2025 17:23:09 GMT
Subject: Integrated: 8303770: Remove Baltimore root certificate expiring in May
 2025
In-Reply-To: <Hcsn7pFjVHvetnBbotzYTnWap2tSHc9Tey014rjy9ew=.5ed09b47-667b-4fdf-ac73-6ab934c7316a@github.com>
References: <Hcsn7pFjVHvetnBbotzYTnWap2tSHc9Tey014rjy9ew=.5ed09b47-667b-4fdf-ac73-6ab934c7316a@github.com>
Message-ID: <56MOMXAg6kYy9IVNhcwM0WGfiCdjhW-DlE2yOyIyCeE=.3c773224-bf18-47de-b67e-c8ce6641aa77@github.com>

On Tue, 11 Mar 2025 17:28:17 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Removed "_CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE_" root certificate expiring in May 2025 from cacerts truststore. No code signing certificates were issued from CA.
> 
> The release-note is at [JDK-8351686](https://bugs.openjdk.org/browse/JDK-8351686)

This pull request has now been integrated.

Changeset: 23716967
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2371696781edc040d8fa8133c78b284a2e3de1ed
Stats:     34 lines in 2 files changed: 0 ins; 30 del; 4 mod

8303770: Remove Baltimore root certificate expiring in May 2025

Reviewed-by: shade, mullan

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

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

From abarashev at openjdk.org  Wed Mar 12 17:26:30 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 12 Mar 2025 17:26:30 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v18]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Typo fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/3320ecbb..3f1f4016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=16-17

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

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

From duke at openjdk.org  Wed Mar 12 19:19:08 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 12 Mar 2025 19:19:08 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v7]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <xeGVcNvhb8JogSwnBjlAln9bAiZMAeiOEC5XrH0FVX0=.564addcd-ee9a-4628-8df1-b546e7de45be@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Made the intrinsics test separate from the pure java test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/f65ef7c4..aa2fdf2d

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

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

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

From mdonovan at openjdk.org  Wed Mar 12 20:28:31 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 12 Mar 2025 20:28:31 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v4]
In-Reply-To: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
Message-ID: <LyQBzNaE6-Wz7BWAV0XUREhXHMwIWfvVbXuMRp886rQ=.b29c84f1-d1b0-4789-a285-30905c974f5b@github.com>

> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  updated code to remove extraneous null checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23989/files
  - new: https://git.openjdk.org/jdk/pull/23989/files/4791105e..c1b79738

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

  Stats: 44 lines in 6 files changed: 12 ins; 24 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23989/head:pull/23989

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

From mdonovan at openjdk.org  Wed Mar 12 20:28:32 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 12 Mar 2025 20:28:32 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v3]
In-Reply-To: <ngF3csuZyd229w_ldh2AYLRiwxGoJyhGCfk0_ChWxFk=.266ad385-925c-474b-9972-277aceae8efe@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <pgpHLoZoD7wB19Wf5sn5Cm1wccPQ6wS-yIj555-PKy0=.6e856341-4511-4a4d-a6d7-09cb76b3cc57@github.com>
 <ngF3csuZyd229w_ldh2AYLRiwxGoJyhGCfk0_ChWxFk=.266ad385-925c-474b-9972-277aceae8efe@github.com>
Message-ID: <u6IqaboiP-FVMfLa-eZMBE-iMZKEEzBGf8VpsKOvdWc=.27f7d128-1ad9-4609-831b-642810ab4345@github.com>

On Wed, 12 Mar 2025 16:39:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed ArtifactResolver.fetchOne() to throw a skipped exception
>
> test/jdk/sun/security/pkcs11/PKCS11Test.java line 749:
> 
>> 747:     private static Path fetchNssLib(Class<?> clazz, Path libraryName) throws IOException {
>> 748:         Path p = ArtifactResolver.fetchOne(clazz);
>> 749:         return findNSSLibrary(p, libraryName);
> 
> So this method should never return null. Can we change `fetchNssLib(String osId, Path libraryName)` to also never return null (default throws `SkippedException`)? Then inside `getNSSLibPath(String library)` there is no need for the null check.

Yep, i removed the unnecessary null-checks

> test/lib/jdk/test/lib/artifacts/ArtifactResolver.java line 78:
> 
>> 76:      * <p>
>> 77:      * Artifacts are defined with the {@link jdk.test.lib.artifacts.Artifact}
>> 78:      * annotation. The file name should have the format ARTIFACT_NAME-VERSION.EXT
> 
> It could also be a directory, right? So maybe `path name` is more precise.
> 
> Also, you haven't defined what each piece in ARTIFACT_NAME-VERSION.EXT is. On the other hand, the names in `Artifact` are `name`, `revision`, and `extension`.

This sentence doesn't really belong here anyway so I removed it entirely

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1992239433
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1992239895

From weijun at openjdk.org  Wed Mar 12 20:37:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 12 Mar 2025 20:37:54 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v4]
In-Reply-To: <LyQBzNaE6-Wz7BWAV0XUREhXHMwIWfvVbXuMRp886rQ=.b29c84f1-d1b0-4789-a285-30905c974f5b@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <LyQBzNaE6-Wz7BWAV0XUREhXHMwIWfvVbXuMRp886rQ=.b29c84f1-d1b0-4789-a285-30905c974f5b@github.com>
Message-ID: <4BAikPxMTDF0tjXesiK-JwW7LdW6KdGZ144kybv-XAA=.68ceaba9-373e-4d1c-a836-a473fd8439cf@github.com>

On Wed, 12 Mar 2025 20:28:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated code to remove extraneous null checks

test/jdk/sun/security/pkcs11/PKCS11Test.java line 1:

> 1: /*

There are 2 useless imports now:

import java.nio.file.Paths;
import jdk.test.lib.artifacts.ArtifactResolverException;

test/jdk/sun/security/pkcs11/SecmodTest.java line 1:

> 1: /*

Copyright year.

test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 1:

> 1: /*

`import jtreg.SkippedException;` is useless.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1992250415
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1992251730
PR Review Comment: https://git.openjdk.org/jdk/pull/23989#discussion_r1992248430

From scottslewis at gmail.com  Wed Mar 12 23:57:14 2025
From: scottslewis at gmail.com (Scott Lewis)
Date: Wed, 12 Mar 2025 16:57:14 -0700
Subject: SSLContext instances
Message-ID: <43b0a23e-28ce-4f6c-ad3d-139b53f6197c@gmail.com>

Greets,

I'm not a regular participant on this mailing list, so please forgive 
the newby and point me in the right direction if this has already been 
discussed.

I am a regular configurer [1] and consumer of SSLContext [2] 
instances...e.g. for jdk httpsclient config, apache httpsclient config, 
other https impls, custom sslsocketfactory impls, etc.

The SSLContext.getInstance static methods, along with 
SSLContext.getDefault() static method are the way for SSLContext 
instances to be accessed for configuring https/tls.? In many/most of the 
httpsclient impls, SSLContext.getDefault() is frequently/traditionally used.

There is also a method SSLContext.setDefault(SSLContext) [3], whose jdk 
17 implementation has a permission check (setDefaultSSLContext) to 
prevent access to calling setDefault.

With security manager deprecation/removal,? could this create security 
issues for JVM-based environments???? Particularly modular/dynamic 
systems? (e.g. OSGi, JPMS)

Thanks,

Scott

[1] 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLContext.html#init(javax.net.ssl.KeyManager%5B%5D,javax.net.ssl.TrustManager%5B%5D,java.security.SecureRandom)

[2] 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLContext.html

[3] 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLContext.html#setDefault(javax.net.ssl.SSLContext)



From ascarpino at openjdk.org  Thu Mar 13 01:15:03 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 13 Mar 2025 01:15:03 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v13]
In-Reply-To: <pzQ-OBSQL7n5SbuQwbh6ouivfEKRbfL3pkHN6u1AGZU=.2863ee52-93dc-4530-b4dd-438a88f9699a@github.com>
References: <pzQ-OBSQL7n5SbuQwbh6ouivfEKRbfL3pkHN6u1AGZU=.2863ee52-93dc-4530-b4dd-438a88f9699a@github.com>
Message-ID: <08wmiSxvUmzEN6Xl0DRsYkf-AvWnCHjzcMuLaDL54ZY=.e33d468b-56a2-463f-b466-0aac792b4e92@github.com>

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

Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:

 - merge with master
 - better comment and remove commented out code
 - Merge branch 'master' into pem
 - Merge branch 'pem-merge' into pem
 - merge
 - Merge in PEMRecord as part of the API.
 - Merge branch 'pem-record' into pem-merge
   
   # Conflicts:
   #	src/java.base/share/classes/java/security/PEMDecoder.java
   #	src/java.base/share/classes/java/security/PEMRecord.java
   #	src/java.base/share/classes/sun/security/util/Pem.java
   #	test/jdk/java/security/PEM/PEMData.java
   #	test/jdk/java/security/PEM/PEMDecoderTest.java
   #	test/jdk/java/security/PEM/PEMEncoderTest.java
 - Merge branch 'master' into pem-record
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - test fixes & cleanup
 - Implement stream decoding
   fix StringBuffer/Builder
   X509C* changes
 - ... and 51 more: https://git.openjdk.org/jdk/compare/a347ecde...106788ef

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

Changes: https://git.openjdk.org/jdk/pull/17543/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17543&range=12
  Stats: 3379 lines in 41 files changed: 3061 ins; 129 del; 189 mod
  Patch: https://git.openjdk.org/jdk/pull/17543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17543/head:pull/17543

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

From hchao at openjdk.org  Thu Mar 13 02:43:35 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 13 Mar 2025 02:43:35 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v2]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <ScR262JqgIhyZB5JODoFhwhFQnkqSsyrAiuElBflXR4=.f54956fb-5e46-4eda-97d6-ed00479808cd@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

 - Update with review comment
 - Remove unneeded compressed large jar test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/d5fe503a..28a9038b

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

  Stats: 181 lines in 4 files changed: 16 ins; 140 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

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

From hchao at openjdk.org  Thu Mar 13 02:54:51 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 13 Mar 2025 02:54:51 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC
In-Reply-To: <gyVf9gWfZIc0M-SWSaPfea_TI7Q99YkcOQLAOMeHtug=.44b8ecf9-5551-4014-8065-feca1275ba85@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <gyVf9gWfZIc0M-SWSaPfea_TI7Q99YkcOQLAOMeHtug=.44b8ecf9-5551-4014-8065-feca1275ba85@github.com>
Message-ID: <a0QFSWz9iM-hBTvTJyRhpcyLaKNimF1OoQEbwEqkMvA=.d0504a08-e7b4-4477-9214-2c19e6802b2e@github.com>

On Tue, 4 Mar 2025 08:54:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> I think we need to stand back from all this validation and consider what validation/checking should be done by jar tool vs. jarsigner tool. I think there is a strong argument to expand what `jar --validate` does (or add a new option) so that the jar tool can do the integrity checks that include the checks to ensure that the CEN and LOC entries are consistent.  The `jarsigner -verify` option could augment that with focus on the signing rather than on ZIP or JAR file integrity issues.

@AlanBateman Thanks for the comment. As we had internal discussion, we decided to add a small set of integrity checks to jarsigner. The webrev was updated as needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23532#issuecomment-2719689109

From liach at openjdk.org  Thu Mar 13 11:20:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Mar 2025 11:20:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <5Em3jYkKNERI9WrgRe9zfbEVLK8Gca46V4nL98N2Xmw=.54f09707-856e-4b26-9a03-0ebd17a40b6b@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

FYI we don't usually drop the benchmark scores in the PR description; we usually leave them in comments to indicate which revision the bench results apply to.

src/hotspot/share/ci/ciField.cpp line 255:

> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
> 254:   return signature == vmSymbols::java_lang_StableValue_signature() ||
> 255:          signature == vmSymbols::java_lang_StableValue_array_signature();

This is dubious - a user can declare a `final StableValue[] array;` and modify the array elements, which is totally compliant to the language and the VM rules. Don't know what this serves.

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2711648215
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1987920134

From pminborg at openjdk.org  Thu Mar 13 11:20:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <YdmKW_G534BGnExnfGYDPcdcIqzOxVoOUuk9EA7kj44=.de5507e3-017e-494f-b074-f1f64b8b7e73@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Here are the current benchmarks for Mac M1:


Benchmark                                     Mode  Cnt  Score   Error  Units
StableFunctionBenchmark.function              avgt   10  4.071 ? 0.252  ns/op
StableFunctionBenchmark.stable                avgt   10  4.107 ? 0.065  ns/op
StableFunctionBenchmark.staticIntFunction     avgt   10  2.688 ? 1.647  ns/op
StableFunctionBenchmark.staticStable          avgt   10  1.708 ? 0.278  ns/op
StableIntFunctionBenchmark.intFunction        avgt   10  1.528 ? 0.040  ns/op
StableIntFunctionBenchmark.stable             avgt   10  1.515 ? 0.019  ns/op
StableIntFunctionBenchmark.staticIntFunction  avgt   10  1.047 ? 0.023  ns/op
StableIntFunctionBenchmark.staticStable       avgt   10  1.056 ? 0.045  ns/op
StableSupplierBenchmark.stable                avgt   10  1.411 ? 0.127  ns/op
StableSupplierBenchmark.supplier              avgt   10  1.676 ? 0.055  ns/op
StableValueBenchmark.atomic                   avgt   10  1.404 ? 0.061  ns/op
StableValueBenchmark.dcl                      avgt   10  1.398 ? 0.037  ns/op
StableValueBenchmark.refSupplier              avgt   10  0.498 ? 0.077  ns/op
StableValueBenchmark.stable                   avgt   10  1.406 ? 0.053  ns/op
StableValueBenchmark.stableNull               avgt   10  1.279 ? 0.062  ns/op
StableValueBenchmark.staticAtomic             avgt   10  1.228 ? 0.060  ns/op
StableValueBenchmark.staticDcl                avgt   10  0.342 ? 0.005  ns/op
StableValueBenchmark.staticHolder             avgt   10  0.342 ? 0.006  ns/op
StableValueBenchmark.staticStable             avgt   10  0.348 ? 0.015  ns/op

``

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

PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2713007259

From pminborg at openjdk.org  Thu Mar 13 11:20:10 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
Message-ID: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>

Implement JEP 502.

The PR passes tier1-tier3 tests.

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

Commit messages:
 - Use acquire semantics for reading rather than volatile semantics
 - Add missing null check
 - Simplify handling of sentinel, wrap, and unwrap
 - Fix JavaDoc issues
 - Fix members in StableEnumFunction
 - Address some comments in the PR
 - Merge branch 'master' into implement-jep502
 - Revert change
 - Fix copyright issues
 - Update JEP number
 - ... and 231 more: https://git.openjdk.org/jdk/compare/4cf63160...09ca44e6

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351565
  Stats: 3980 lines in 30 files changed: 3949 ins; 18 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

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

From pminborg at openjdk.org  Thu Mar 13 11:20:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <5Em3jYkKNERI9WrgRe9zfbEVLK8Gca46V4nL98N2Xmw=.54f09707-856e-4b26-9a03-0ebd17a40b6b@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <5Em3jYkKNERI9WrgRe9zfbEVLK8Gca46V4nL98N2Xmw=.54f09707-856e-4b26-9a03-0ebd17a40b6b@github.com>
Message-ID: <UnSr3Bl34SyAZFo4VYHbgz99Oxc5ThMtyNSTfWbz09A=.91708fea-c78d-4dfb-b61a-3fb844584539@github.com>

On Mon, 10 Mar 2025 19:45:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/hotspot/share/ci/ciField.cpp line 255:
> 
>> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
>> 254:   return signature == vmSymbols::java_lang_StableValue_signature() ||
>> 255:          signature == vmSymbols::java_lang_StableValue_array_signature();
> 
> This is dubious - a user can declare a `final StableValue[] array;` and modify the array elements, which is totally compliant to the language and the VM rules. Don't know what this serves.

Fair comment. We should at least remove the array signature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988609781

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/java.base/share/classes/java/lang/StableValue.java line 79:

> 77:  *            logger.trySet(Logger.create(Component.class));
> 78:  *        }
> 79:  *         return logger.orThrow();

Suggestion:

 *         return logger.orElseThrow();

src/java.base/share/classes/java/lang/StableValue.java line 127:

> 125:  * evaluated only once, even when {@code logger.orElseSet()} is invoked concurrently.
> 126:  * This property is crucial as evaluation of the supplier may have side effects,
> 127:  * e.g., the call above to {@code Logger.getLogger()} may result in storage resources

Suggestion:

 * e.g., the call above to {@code Logger.create()} may result in storage resources

src/java.base/share/classes/java/lang/StableValue.java line 344:

> 342:  * {@linkplain java.lang.ref##reachability reachable} stable values will hold their set
> 343:  * content perpetually.
> 344:  * <p>

Should the original functions / mappers (for stable functions and collections) also stay reachable? Kotlin's [`Lazy`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-lazy/) [nulls out](https://github.com/JetBrains/kotlin/blob/c6f337283d59fcede75954eebaa589ad1b479aea/libraries/stdlib/jvm/src/kotlin/util/LazyJVM.kt#L70-L89) the initializer function when it's no longer needed.

src/java.base/share/classes/java/lang/StableValue.java line 423:

> 421:      * {@snippet lang=java:
> 422:      * if (stable.isSet()) {
> 423:      *     return stable.get();

Suggestion:

     *     return stable.orElseThrow();

src/java.base/share/classes/java/lang/StableValue.java line 547:

> 545:                                           IntFunction<? extends R> original) {
> 546:         if (size < 0) {
> 547:             throw new IllegalArgumentException();

This exceptions isn't documented, same for `StableValue.list()`

src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 112:

> 110:         final Class<E> enumType = (Class<E>)inputs.iterator().next().getClass();
> 111:         return (Function<T, R>) new StableEnumFunction<E, R>(enumType, min, StableValueFactories.array(size), (Function<E, R>) original);
> 112:     }

If `inputs` contains the enumuration constants with ordinals 0 and 2, wouldn't this code wrongly cause the enumeration constant with ordinal 1 to be an allowed input?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 141:

> 139:                 ? "(this StableValue)"
> 140:                 : "StableValue" + renderWrapped(t);
> 141:     }

Are deeper cycles of concern? I was thinking of this:

var a = StableValue.of();
var b = StableValue.of();
a.trySet(b);
b.trySet(a);
System.out.println(a);


This would solve deeper cycles for `StableValueImpl`:

@Override
public String toString() {
    final StringBuilder sb = new StringBuilder("StableValue");
    int depth = 0;
    Object t = value;
    while (t instanceof StableValueImpl<?> s) {
        if (s == this) {
            t = "(this StableValue)";
            break;
        }
        sb.append("[StableValue");
        depth++;
        t = s.value;
    }
    sb.append(renderWrapped(t));
    while (depth-- > 0) sb.append(']');
    return sb.toString();
}

This might also apply to stable functions and collections, I haven't thought it through for them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989143787
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989165612
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989265489
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989377859
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989504117
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988064795
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988092230

From liach at openjdk.org  Thu Mar 13 11:20:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
Message-ID: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>

On Tue, 11 Mar 2025 13:22:20 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/java.base/share/classes/java/lang/StableValue.java line 344:
> 
>> 342:  * {@linkplain java.lang.ref##reachability reachable} stable values will hold their set
>> 343:  * content perpetually.
>> 344:  * <p>
> 
> Should the original functions / mappers (for stable functions and collections) also stay reachable? Kotlin's [`Lazy`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-lazy/) [nulls out](https://github.com/JetBrains/kotlin/blob/c6f337283d59fcede75954eebaa589ad1b479aea/libraries/stdlib/jvm/src/kotlin/util/LazyJVM.kt#L70-L89) the initializer function when it's no longer needed.

The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

> src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 112:
> 
>> 110:         final Class<E> enumType = (Class<E>)inputs.iterator().next().getClass();
>> 111:         return (Function<T, R>) new StableEnumFunction<E, R>(enumType, min, StableValueFactories.array(size), (Function<E, R>) original);
>> 112:     }
> 
> If `inputs` contains the enumuration constants with ordinals 0 and 2, wouldn't this code wrongly cause the enumeration constant with ordinal 1 to be an allowed input?

Indeed, a bit set predicate can be used to check input validity if it is necessary - I think for enums, using a `StableFunction.ofEnum` dedicated API might be better just because `StableValue` can access `Class.getEnumConstantsShared` easily.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 141:
> 
>> 139:                 ? "(this StableValue)"
>> 140:                 : "StableValue" + renderWrapped(t);
>> 141:     }
> 
> Are deeper cycles of concern? I was thinking of this:
> 
> var a = StableValue.of();
> var b = StableValue.of();
> a.trySet(b);
> b.trySet(a);
> System.out.println(a);
> 
> 
> This would solve deeper cycles for `StableValueImpl`:
> 
> @Override
> public String toString() {
>     final StringBuilder sb = new StringBuilder("StableValue");
>     int depth = 0;
>     Object t = value;
>     while (t instanceof StableValueImpl<?> s) {
>         if (s == this) {
>             t = "(this StableValue)";
>             break;
>         }
>         sb.append("[StableValue");
>         depth++;
>         t = s.value;
>     }
>     sb.append(renderWrapped(t));
>     while (depth-- > 0) sb.append(']');
>     return sb.toString();
> }
> 
> This might also apply to stable functions and collections, I haven't thought it through for them.

I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989965200
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988159371
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988154881

From pminborg at openjdk.org  Thu Mar 13 11:20:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
Message-ID: <lX1y9g2OirKBvEmg8OerZiPCwbJ65JMDAENvsg2DtNI=.a97af05c-4e13-4568-97b5-f16054aec252@github.com>

On Tue, 11 Mar 2025 19:04:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StableValue.java line 344:
>> 
>>> 342:  * {@linkplain java.lang.ref##reachability reachable} stable values will hold their set
>>> 343:  * content perpetually.
>>> 344:  * <p>
>> 
>> Should the original functions / mappers (for stable functions and collections) also stay reachable? Kotlin's [`Lazy`](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-lazy/) [nulls out](https://github.com/JetBrains/kotlin/blob/c6f337283d59fcede75954eebaa589ad1b479aea/libraries/stdlib/jvm/src/kotlin/util/LazyJVM.kt#L70-L89) the initializer function when it's no longer needed.
>
> The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 141:
>> 
>>> 139:                 ? "(this StableValue)"
>>> 140:                 : "StableValue" + renderWrapped(t);
>>> 141:     }
>> 
>> Are deeper cycles of concern? I was thinking of this:
>> 
>> var a = StableValue.of();
>> var b = StableValue.of();
>> a.trySet(b);
>> b.trySet(a);
>> System.out.println(a);
>> 
>> 
>> This would solve deeper cycles for `StableValueImpl`:
>> 
>> @Override
>> public String toString() {
>>     final StringBuilder sb = new StringBuilder("StableValue");
>>     int depth = 0;
>>     Object t = value;
>>     while (t instanceof StableValueImpl<?> s) {
>>         if (s == this) {
>>             t = "(this StableValue)";
>>             break;
>>         }
>>         sb.append("[StableValue");
>>         depth++;
>>         t = s.value;
>>     }
>>     sb.append(renderWrapped(t));
>>     while (depth-- > 0) sb.append(']');
>>     return sb.toString();
>> }
>> 
>> This might also apply to stable functions and collections, I haven't thought it through for them.
>
> I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.

The `toString()` function for stable value is inspired by `Optional` and some of the collections.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990919074
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988637468

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <lX1y9g2OirKBvEmg8OerZiPCwbJ65JMDAENvsg2DtNI=.a97af05c-4e13-4568-97b5-f16054aec252@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 <lX1y9g2OirKBvEmg8OerZiPCwbJ65JMDAENvsg2DtNI=.a97af05c-4e13-4568-97b5-f16054aec252@github.com>
Message-ID: <D7JiLG5pqp76lszELgo44SdKEVIWNv6uKz7HOBGPGEs=.c92b0e2d-cfa6-4b2f-9158-d3dfd9817da2@github.com>

On Wed, 12 Mar 2025 08:16:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The nulling out is only safe if the write to the value is visible when a nulled-out function is visible. I think SV can ensure this, but an implementation can easily go wrong trying to do this. (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)
>
> This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.

> (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)

You mean [this](https://github.com/openjdk/jdk/blob/a05717d8da8f804003cfb8d6d25b8a5b6cecd473/src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java#L117-L120) is missing `Objects.requireNonNull(supplier);`, right?

>> I think the default Object.toString impl is better here - the type `StableValue` shouldn't really be exposed in a user API endpoint and is just a utility for the users. No need to bikeshed on this mostly useless functionality.
>
> The `toString()` function for stable value is inspired by `Optional` and some of the collections.

`Optional` doesn't have the issue of containing itself.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991649915
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989329168

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/java.base/share/classes/java/util/ImmutableCollections.java line 772:

> 770: 
> 771:     @jdk.internal.ValueBased
> 772:     static final class StableList<E> extends AbstractImmutableList<E> {

Is there significant reuse gained by putting StableList in ImmutableCollection? The back-and-forth between here and SV through SharedSecrets is a little awkward.

src/java.base/share/classes/java/util/ImmutableCollections.java line 1462:

> 1460: 
> 1461:     static final class StableMap<K, V>
> 1462:             extends AbstractImmutableMap<K, V> {

Same question about whether StableMap needs to go here. Though there?s more stuff going on for maps than lists here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988220230
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988222063

From pminborg at openjdk.org  Thu Mar 13 11:20:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <D7JiLG5pqp76lszELgo44SdKEVIWNv6uKz7HOBGPGEs=.c92b0e2d-cfa6-4b2f-9158-d3dfd9817da2@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 <lX1y9g2OirKBvEmg8OerZiPCwbJ65JMDAENvsg2DtNI=.a97af05c-4e13-4568-97b5-f16054aec252@github.com>
 <D7JiLG5pqp76lszELgo44SdKEVIWNv6uKz7HOBGPGEs=.c92b0e2d-cfa6-4b2f-9158-d3dfd9817da2@github.com>
Message-ID: <9eaXze3gUOvuO_dJhn31evFsyUO6zw9z9Dneexn8WKw=.7bd9d254-d8ea-44a5-a57d-a98173ba536f@github.com>

On Wed, 12 Mar 2025 14:38:28 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> This is something we experimented with a bit in the past. It isn't easy to do in the general case. There are pros (the function and its resources that can be collected) and cons (e.g., mutability, visibility, complexity, etc.) with this.
>
>> (Also `orElseSet` does not NPE if the incoming supplier is null but the value is bound)
> 
> You mean [this](https://github.com/openjdk/jdk/blob/a05717d8da8f804003cfb8d6d25b8a5b6cecd473/src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java#L117-L120) is missing `Objects.requireNonNull(supplier);`, right?

Fixed `Objects.requireNonNull()` now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993279982

From duke at openjdk.org  Thu Mar 13 11:20:13 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <Z1MMhJOj7XznWixu8qHnDxlAtewOII15a3g4TnDpqD4=.d955fc88-a97e-4b61-b804-33842f00f56d@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
 <Z1MMhJOj7XznWixu8qHnDxlAtewOII15a3g4TnDpqD4=.d955fc88-a97e-4b61-b804-33842f00f56d@github.com>
Message-ID: <P7AJ5yflgcyJezMdv10XlK0zDDPk6atKzqOookzHjrc=.78583938-7d09-46b5-b72b-4667b9c87f0e@github.com>

On Tue, 11 Mar 2025 07:48:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 772:
>> 
>>> 770: 
>>> 771:     @jdk.internal.ValueBased
>>> 772:     static final class StableList<E> extends AbstractImmutableList<E> {
>> 
>> Is there significant reuse gained by putting StableList in ImmutableCollection? The back-and-forth between here and SV through SharedSecrets is a little awkward.
>
> This allows reuse of `AbstractImmutableList` with list iterators, sub lists and more.

Using the regular AbstractList as a base would also get you implementations of those.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989875430

From pminborg at openjdk.org  Thu Mar 13 11:20:13 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
Message-ID: <Z1MMhJOj7XznWixu8qHnDxlAtewOII15a3g4TnDpqD4=.d955fc88-a97e-4b61-b804-33842f00f56d@github.com>

On Tue, 11 Mar 2025 01:20:16 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 772:
> 
>> 770: 
>> 771:     @jdk.internal.ValueBased
>> 772:     static final class StableList<E> extends AbstractImmutableList<E> {
> 
> Is there significant reuse gained by putting StableList in ImmutableCollection? The back-and-forth between here and SV through SharedSecrets is a little awkward.

This allows reuse of `AbstractImmutableList` with list iterators, sub lists and more.

> src/java.base/share/classes/java/util/ImmutableCollections.java line 1462:
> 
>> 1460: 
>> 1461:     static final class StableMap<K, V>
>> 1462:             extends AbstractImmutableMap<K, V> {
> 
> Same question about whether StableMap needs to go here. Though there?s more stuff going on for maps than lists here.

Same argument as for `StableList`. This allows reuse of several classes including `AbstractImmutableMap`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988605709
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988607732

From liach at openjdk.org  Thu Mar 13 11:20:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Mar 2025 11:20:13 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <P7AJ5yflgcyJezMdv10XlK0zDDPk6atKzqOookzHjrc=.78583938-7d09-46b5-b72b-4667b9c87f0e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <3WF5febSMDQinBZGiaVydeRNCJn-AzZ3oxR1UcLCuyc=.0a921dfe-b807-491d-9b50-008004b30b72@github.com>
 <Z1MMhJOj7XznWixu8qHnDxlAtewOII15a3g4TnDpqD4=.d955fc88-a97e-4b61-b804-33842f00f56d@github.com>
 <P7AJ5yflgcyJezMdv10XlK0zDDPk6atKzqOookzHjrc=.78583938-7d09-46b5-b72b-4667b9c87f0e@github.com>
Message-ID: <C-64owYhIlPvE7u-6OH5P3D0y0CMLyG5xsJG4HshJDI=.36160812-660e-485e-a61f-12ebdd3b5ee4@github.com>

On Tue, 11 Mar 2025 18:08:47 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This allows reuse of `AbstractImmutableList` with list iterators, sub lists and more.
>
> Using the regular AbstractList as a base would also get you implementations of those.

`AbstractList` has non-final fields, which makes it not suitable for `@ValueBased`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989947965

From qamai at openjdk.org  Thu Mar 13 11:20:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/java.base/share/classes/java/util/ImmutableCollections.java line 777:

> 775:         private final IntFunction<? extends E> mapper;
> 776:         @Stable
> 777:         private final StableValueImpl<E>[] backing;

You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:

> 63:     //
> 64:     @Stable
> 65:     private volatile Object value;

Can we use `acquire`/`release` semantics instead of `volatile`?

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 128:

> 126:             final T newValue = supplier.get();
> 127:             // The mutex is reentrant so we need to check if the value was actually set.
> 128:             return wrapAndCas(newValue) ? newValue : orElseThrow();

Reentrancy into here seems really buggy, I would endorse disallowing it instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 159:

> 157:     private boolean wrapAndCas(Object value) {
> 158:         // This upholds the invariant, a `@Stable` field is written to at most once
> 159:         return UNSAFE.compareAndSetReference(this, UNDERLYING_DATA_OFFSET, null, wrap(value));

There is no need for a cas here as all setters have to hold the lock. We should have a dedicated private `set` that asserts `Thread.holdsLock(this)`.

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 168:

> 166:     // Wraps `null` values into a sentinel value
> 167:     @ForceInline
> 168:     private static <T> T wrap(T t) {

Suggestion:

    private static <T> Object wrap(T t) {

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 181:

> 179:     @SuppressWarnings("unchecked")
> 180:     @ForceInline
> 181:     private static <T> T nullSentinel() {

Suggestion:

    private static Object nullSentinel() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988608920
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988612784
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993081551
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988616943
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993110162
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993111723

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
Message-ID: <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>

On Tue, 11 Mar 2025 07:50:38 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 777:
> 
>> 775:         private final IntFunction<? extends E> mapper;
>> 776:         @Stable
>> 777:         private final StableValueImpl<E>[] backing;
> 
> You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.

Can you please elaborate a bit more on your proposal @merykitty?

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:
> 
>> 63:     //
>> 64:     @Stable
>> 65:     private volatile Object value;
> 
> Can we use `acquire`/`release` semantics instead of `volatile`?

Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 128:
> 
>> 126:             final T newValue = supplier.get();
>> 127:             // The mutex is reentrant so we need to check if the value was actually set.
>> 128:             return wrapAndCas(newValue) ? newValue : orElseThrow();
> 
> Reentrancy into here seems really buggy, I would endorse disallowing it instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`

StableValueImpl was carefully designed to minimize memory footprint. Adding a lock would inflate memory usage substantially.

> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 159:
> 
>> 157:     private boolean wrapAndCas(Object value) {
>> 158:         // This upholds the invariant, a `@Stable` field is written to at most once
>> 159:         return UNSAFE.compareAndSetReference(this, UNDERLYING_DATA_OFFSET, null, wrap(value));
> 
> There is no need for a cas here as all setters have to hold the lock. We should have a dedicated private `set` that asserts `Thread.holdsLock(this)`.

This is more of a belt and suspenders solution. It is true that it is redundant. A set volatile would suffice here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989016337
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988630199
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993142117
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988634451

From qamai at openjdk.org  Thu Mar 13 11:20:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
Message-ID: <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>

On Tue, 11 Mar 2025 11:19:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 777:
>> 
>>> 775:         private final IntFunction<? extends E> mapper;
>>> 776:         @Stable
>>> 777:         private final StableValueImpl<E>[] backing;
>> 
>> You can use a backing `@Stable Object[]` instead. It will reduce indirection when accessing this list.
>
> Can you please elaborate a bit more on your proposal @merykitty?

If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:

    ReentrantLock[] locks;

    T get(int idx) {
        Object x = backing[idx];
        if (x == null) {
            return compute(idx);
        }
        return unwrap(x);
    }

    T compute(int idx) {
        ReentrantLock lock = locks[idx];
        lock.lock();
        try {
            Object x = backing[idx];
            if (x != null) {
                return unwrap(x);
            }
            T obj = ...;
            backing[idx] = wrap(obj);
            return obj;
        } finally {
            lock.unlock();
        }
    }

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 65:
>> 
>>> 63:     //
>>> 64:     @Stable
>>> 65:     private volatile Object value;
>> 
>> Can we use `acquire`/`release` semantics instead of `volatile`?
>
> Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.

You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1989664004
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990989622

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
Message-ID: <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>

On Tue, 11 Mar 2025 16:15:10 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Can you please elaborate a bit more on your proposal @merykitty?
>
> If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:
> 
>     ReentrantLock[] locks;
> 
>     T get(int idx) {
>         Object x = backing[idx];
>         if (x == null) {
>             return compute(idx);
>         }
>         return unwrap(x);
>     }
> 
>     T compute(int idx) {
>         ReentrantLock lock = locks[idx];
>         lock.lock();
>         try {
>             Object x = backing[idx];
>             if (x != null) {
>                 return unwrap(x);
>             }
>             T obj = ...;
>             backing[idx] = wrap(obj);
>             return obj;
>         } finally {
>             lock.unlock();
>         }
>     }

What would be the difference between `@Stable StableValueImpl<E>[] backing` and `@Stable Object[] backing`?

>> Yes we can. However, I am uncertain if the added complexity can motivate any performance benefits. Perhaps on ARM? I can do a benchmark on it.
>
> You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.

Yeah. Maybe that could strike a balance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990908235
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991599680

From qamai at openjdk.org  Thu Mar 13 11:20:14 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
 <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
Message-ID: <7hEWpE3GTKhCa15FRQBf6_tzHUsr9mbzv6zh1HeZlXY=.1800d27a-33d9-41de-b8bd-31fd82a3661b@github.com>

On Wed, 12 Mar 2025 08:09:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:
>> 
>>     ReentrantLock[] locks;
>> 
>>     T get(int idx) {
>>         Object x = backing[idx];
>>         if (x == null) {
>>             return compute(idx);
>>         }
>>         return unwrap(x);
>>     }
>> 
>>     T compute(int idx) {
>>         ReentrantLock lock = locks[idx];
>>         lock.lock();
>>         try {
>>             Object x = backing[idx];
>>             if (x != null) {
>>                 return unwrap(x);
>>             }
>>             T obj = ...;
>>             backing[idx] = wrap(obj);
>>             return obj;
>>         } finally {
>>             lock.unlock();
>>         }
>>     }
>
> What would be the difference between `@Stable StableValueImpl<E>[] backing` and `@Stable Object[] backing`?

For an `Object[]`, you only need to load the object from the array and it is probably what you need. For a `StableValueImpl[]`, you need to load the `StableValueImpl` from the array, and load the value from that `StableValueImpl`, which is 2 levels of indirections.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1990993459

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <YLjzElq0n2eivme-qW8tDzUWpFwKaxpzVEI6Gme65Eg=.d390c02b-7de4-4bcb-8681-2abf4b9f69de@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
 <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
 <YLjzElq0n2eivme-qW8tDzUWpFwKaxpzVEI6Gme65Eg=.d390c02b-7de4-4bcb-8681-2abf4b9f69de@github.com>
Message-ID: <8eLNHYCb3NOjDPJhbTd2sT_MxAhlPjI9fC4mr0sSWOU=.51260d3f-6585-4fbb-a367-43f26bc225fb@github.com>

On Wed, 12 Mar 2025 13:28:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> What would be the difference between `@Stable StableValueImpl<E>[] backing` and `@Stable Object[] backing`?
>
> It's true that the storage can be flatter here -- that said, this can also be done as a later refactoring. One advantage of doing things the way @minborg did it here, is that it's fairly easy to prove that the code below is correct -- which makes the initial review easier.

Ahh. Now I see what you mean. This is something we did in a handful of prototypes we explored. While it is true that there will be one indirection less, the complexity of the code is going to grow. Also, if the element is constant folded, it does not matter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991597981

From mcimadamore at openjdk.org  Thu Mar 13 11:20:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
 <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
Message-ID: <YLjzElq0n2eivme-qW8tDzUWpFwKaxpzVEI6Gme65Eg=.d390c02b-7de4-4bcb-8681-2abf4b9f69de@github.com>

On Wed, 12 Mar 2025 08:09:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> If you have an `@Stable Object[]`, then the elements are also considered `@Stable`. Then you can do something like:
>> 
>>     ReentrantLock[] locks;
>> 
>>     T get(int idx) {
>>         Object x = backing[idx];
>>         if (x == null) {
>>             return compute(idx);
>>         }
>>         return unwrap(x);
>>     }
>> 
>>     T compute(int idx) {
>>         ReentrantLock lock = locks[idx];
>>         lock.lock();
>>         try {
>>             Object x = backing[idx];
>>             if (x != null) {
>>                 return unwrap(x);
>>             }
>>             T obj = ...;
>>             backing[idx] = wrap(obj);
>>             return obj;
>>         } finally {
>>             lock.unlock();
>>         }
>>     }
>
> What would be the difference between `@Stable StableValueImpl<E>[] backing` and `@Stable Object[] backing`?

It's true that the storage can be flatter here -- that said, this can also be done as a later refactoring. One advantage of doing things the way @minborg did it here, is that it's fairly easy to prove that the code below is correct -- which makes the initial review easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991505367

From duke at openjdk.org  Thu Mar 13 11:20:14 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
Message-ID: <NPJHGuhm_d-L0aMPmujJxYemfzscgWOAyRM2Kl65lLw=.264a6d1f-a4d2-4d03-b3a5-f8036af7db55@github.com>

On Mon, 10 Mar 2025 23:42:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java line 112:
>> 
>>> 110:         final Class<E> enumType = (Class<E>)inputs.iterator().next().getClass();
>>> 111:         return (Function<T, R>) new StableEnumFunction<E, R>(enumType, min, StableValueFactories.array(size), (Function<E, R>) original);
>>> 112:     }
>> 
>> If `inputs` contains the enumuration constants with ordinals 0 and 2, wouldn't this code wrongly cause the enumeration constant with ordinal 1 to be an allowed input?
>
> Indeed, a bit set predicate can be used to check input validity if it is necessary - I think for enums, using a `StableFunction.ofEnum` dedicated API might be better just because `StableValue` can access `Class.getEnumConstantsShared` easily.

What if instead you had a `@Stable` array of Object of the appropriate size, and populated each cell with a StableValue if the corresponding index was in the set, otherwise used a sentinel value. Then on the lookup, if it was the sentinel you throw, else you use the the SV.

Also there is an awful lot of similarity between the enum function and the int function. Could one possibly be implemented using the other?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988195668

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <NPJHGuhm_d-L0aMPmujJxYemfzscgWOAyRM2Kl65lLw=.264a6d1f-a4d2-4d03-b3a5-f8036af7db55@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 <NPJHGuhm_d-L0aMPmujJxYemfzscgWOAyRM2Kl65lLw=.264a6d1f-a4d2-4d03-b3a5-f8036af7db55@github.com>
Message-ID: <lbdSyXIBqMh038sXLg6ZGf9XoFea69rZwrQ2acYLTSk=.578d74b0-6971-492a-b9dc-099632ca48b7@github.com>

On Tue, 11 Mar 2025 00:40:31 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Indeed, a bit set predicate can be used to check input validity if it is necessary - I think for enums, using a `StableFunction.ofEnum` dedicated API might be better just because `StableValue` can access `Class.getEnumConstantsShared` easily.
>
> What if instead you had a `@Stable` array of Object of the appropriate size, and populated each cell with a StableValue if the corresponding index was in the set, otherwise used a sentinel value. Then on the lookup, if it was the sentinel you throw, else you use the the SV.
> 
> Also there is an awful lot of similarity between the enum function and the int function. Could one possibly be implemented using the other?

Thanks for spotting this glitch. I have fixed the issue and added a test for member sets with "holes".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1988707099

From pminborg at openjdk.org  Thu Mar 13 11:20:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <lbdSyXIBqMh038sXLg6ZGf9XoFea69rZwrQ2acYLTSk=.578d74b0-6971-492a-b9dc-099632ca48b7@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
 <NPJHGuhm_d-L0aMPmujJxYemfzscgWOAyRM2Kl65lLw=.264a6d1f-a4d2-4d03-b3a5-f8036af7db55@github.com>
 <lbdSyXIBqMh038sXLg6ZGf9XoFea69rZwrQ2acYLTSk=.578d74b0-6971-492a-b9dc-099632ca48b7@github.com>
Message-ID: <HMavQ4tdFEZyIM2fFY8dUMvxDLyiixVzGVg1BAbcphs=.d26839a0-dce0-4c76-81fe-33eed1d07ceb@github.com>

On Tue, 11 Mar 2025 08:44:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> What if instead you had a `@Stable` array of Object of the appropriate size, and populated each cell with a StableValue if the corresponding index was in the set, otherwise used a sentinel value. Then on the lookup, if it was the sentinel you throw, else you use the the SV.
>> 
>> Also there is an awful lot of similarity between the enum function and the int function. Could one possibly be implemented using the other?
>
> Thanks for spotting this glitch. I have fixed the issue and added a test for member sets with "holes".

It might be worth exploring using a stable int function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1991590911

From alanb at openjdk.org  Thu Mar 13 11:20:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 13 Mar 2025 11:20:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <zPzP-BI32XaB8BQ4qHALhdtQaIW7bVDDxAHK0_c-9J0=.3823d378-9373-4a62-a68d-94e696d92211@github.com>

On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

src/jdk.unsupported/share/classes/sun/misc/Unsafe.java line 983:

> 981: 
> 982:     @ForceInline
> 983:     private static void assertNotTrusted(Field f) {

I don't think this can be named assertXXX, needs to something like ensureNotTrusted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1987836045

From pminborg at openjdk.org  Thu Mar 13 11:20:15 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 11:20:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
 <fsZI4HuBrhdH0Cq5Idg8QT1Z_rpsLGtuD9oFtueYz7g=.5be6bd78-1e28-4e56-acd2-36b4d002affa@github.com>
 <gggIthlmjMRcoKxjAKTt12PWkgQ4930PVYdXEY0AE4c=.f1664452-56df-41c6-894d-284db532bbd3@github.com>
Message-ID: <1O-QKtK9LBw8YzDDGzJxtBTwYBD3jnoKfXFJYiY1sp4=.dea93da7-bfcd-42ca-98c8-f8e0705bac07@github.com>

On Wed, 12 Mar 2025 14:14:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> You can probably use `acquire` only for the first `get` as it is in the fast path. For other I guess `volatile` is fine.
>
> Yeah. Maybe that could strike a balance.

On an M1 Mac:

Volatile:


StableValueBenchmark.stable        avgt   10  1.373 ? 0.057  ns/op
StableValueBenchmark.stableNull    avgt   10  1.245 ? 0.074  ns/op


Acquire:


StableValueBenchmark.stable        avgt   10  1.339 ? 0.044  ns/op
StableValueBenchmark.stableNull    avgt   10  1.241 ? 0.090  ns/op


We would have to examine the difference on other platforms as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993284760

From mdonovan at openjdk.org  Thu Mar 13 11:25:34 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 13 Mar 2025 11:25:34 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v5]
In-Reply-To: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
Message-ID: <VFTT7vn2zJQDu-cJ4-V3cB7pWEi7NynMhHtDvFS-6sg=.1808f559-b870-4377-ad82-b9580135d18c@github.com>

> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  fixed imports and copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23989/files
  - new: https://git.openjdk.org/jdk/pull/23989/files/c1b79738..76f3b31c

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

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

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

From duke at openjdk.org  Thu Mar 13 12:03:11 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 13 Mar 2025 12:03:11 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
Message-ID: <IdsyS9iV8Ms2QYg30urSJWFLVx63qckCV7PqfAwh0-s=.c5769fcb-ce0f-4c8b-8d42-3d43d80a47e6@github.com>

On Thu, 13 Mar 2025 09:45:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 128:
>> 
>>> 126:             final T newValue = supplier.get();
>>> 127:             // The mutex is reentrant so we need to check if the value was actually set.
>>> 128:             return wrapAndCas(newValue) ? newValue : orElseThrow();
>> 
>> Reentrancy into here seems really buggy, I would endorse disallowing it instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`
>
> StableValueImpl was carefully designed to minimize memory footprint. Adding a lock would inflate memory usage substantially.

There is also `Thread.holdsLock()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993371561

From pminborg at openjdk.org  Thu Mar 13 12:45:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 12:45:50 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v2]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <LAcln0w51aj3S9Tj6lcd5H_Zs8Rd7pD54WhSjzgNb-g=.0950edbd-d11b-4434-ad72-a5e703090dc7@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rework reenterant logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/09ca44e6..1cd1cdb2

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

  Stats: 67 lines in 4 files changed: 56 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

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

From mullan at openjdk.org  Thu Mar 13 12:46:05 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Mar 2025 12:46:05 GMT
Subject: Integrated: 8351349: GSSUtil.createSubject has outdated access control
 context and policy related text
In-Reply-To: <hWsuhosMWi9X8YjQt3Z0TamRiPDgdURT8j-_19gJwVA=.8eb57c34-3da7-4277-a882-4249b5d47eff@github.com>
References: <hWsuhosMWi9X8YjQt3Z0TamRiPDgdURT8j-_19gJwVA=.8eb57c34-3da7-4277-a882-4249b5d47eff@github.com>
Message-ID: <yQvO9zAz_aQKuBCC3DHjzFT5AHMiG6NAgraL0dNJq6M=.5bad0391-c228-47ac-8b5b-59ff2a189b15@github.com>

On Mon, 10 Mar 2025 17:15:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please review this change to remove outdated access control context and policy related text from the `com.sun.security.jgss.GSSUtil` class which no longer applies now that JEP 486 disabled the Security Manager. 
> 
> I also made a few other minor changes, adding code tags around class names and changing "Sun Microsystem's" to "the JDK" in the class description.
> 
> I will also file a CSR.

This pull request has now been integrated.

Changeset: 82eb7806
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82eb78069ffbaf66ae479d41d850d5999055e0e1
Stats:     32 lines in 1 file changed: 4 ins; 6 del; 22 mod

8351349: GSSUtil.createSubject has outdated access control context and policy related text

Reviewed-by: weijun

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

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

From pminborg at openjdk.org  Thu Mar 13 12:52:32 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 12:52:32 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v3]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <OmY4p5JvFpx8pHK-fjG-Xf5B2UvJRpoggxCNnia5_D0=.b3409736-09d5-4a29-801c-7d74a381ca82@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename method and fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/1cd1cdb2..8f6d6bc0

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

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

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

From pminborg at openjdk.org  Thu Mar 13 13:01:58 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 13:01:58 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v4]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <qRT3MNT1BgbTD2FBNuUH6X7gkh66Os2RP_N3Z-64Hgk=.b244bdea-4633-4975-90e9-6749e2b5bb11@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/8f6d6bc0..c648ea2b

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

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

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

From weijun at openjdk.org  Thu Mar 13 13:49:17 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 13:49:17 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <yzZVGiVm3BlSq8WRjOMmm9RzV6xuUa5Nuu8iBJphHtU=.e589a641-10bb-440f-bb08-3f97e7ec5aab@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

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

Actually, you can remove those lines in `security.cpp`. The whole method is for debugging use during my developing work. While the method could still be valuable but those lines are completely useless now.

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

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

From pminborg at openjdk.org  Thu Mar 13 13:52:24 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 13:52:24 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v5]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <INsmeBaaEFRgNdJj_qDqzMbV9cp2V-6gcQ1Ok6o0WgI=.f36bb583-8d1f-4a39-b6c9-bbf52f5b5031@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Clean up exception messages and fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23972/files
  - new: https://git.openjdk.org/jdk/pull/23972/files/c648ea2b..2fe5b0f8

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

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

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

From mullan at openjdk.org  Thu Mar 13 14:00:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Mar 2025 14:00:06 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
Message-ID: <d8LNDrr_6tAigVKOcCr3cH-7f4oICkpBENMjCYB5m-A=.a6537c30-336f-4c9b-b807-146870532a2a@github.com>

On Wed, 12 Mar 2025 12:18:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> ![HPKEParameterSpec](https://github.com/user-attachments/assets/4a7e6609-fd64-444a-978f-bde1634caa70)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   switch to Asserts.assertThrows in test; use traditional javadoc style

Some initial comments.

src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 55:

> 53:  * provided to {@code init()}.
> 54:  * <li> {@link #of(int, int)} creates an instance with explicitly specified
> 55:  * KDF, and AEAD algorithm identifiers, but the KEM algorithm identifier will be

No comma necessary after "KDF".

src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 55:

> 53:  * provided to {@code init()}.
> 54:  * <li> {@link #of(int, int)} creates an instance with explicitly specified
> 55:  * KDF, and AEAD algorithm identifiers, but the KEM algorithm identifier will be

I'd suggest breaking this into two sentences, remove the ", but" from the first sentence, and start the second sentence as "The KEM algorithm identifier ..."

src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 65:

> 63:  * defined in <a href="https://www.rfc-editor.org/rfc/rfc9180.html#section-7">Section 7</a>
> 64:  * of RFC 9180 and the
> 65:  * <a href="https://www.iana.org/assignments/hpke/hpke.xhtml">IANA HPKE page</a>.

I think it would be useful to mention here that there are constants defined for the standard algorithms. My initial reading of this, I thought I would have to lookup the hex values and convert them to integers to use the API.

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

PR Review: https://git.openjdk.org/jdk/pull/18411#pullrequestreview-2679715999
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1992201674
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1992206217
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1993585316

From weijun at openjdk.org  Thu Mar 13 14:42:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 14:42:04 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v3]
In-Reply-To: <205-U85HVrJ4n1R9eEzGBgwX1RQ9OCji-CnbRaIqqGI=.da82387c-f896-4a3c-a94d-a6bd27d7d926@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <jqnpycv2bRivwAKIZxCpPOJNtNyXvJqerAuqu2Xaehk=.6809975d-9f75-4bfd-bc4e-785401f2e778@github.com>
 <B8wtasjjzJ0BTbU4GGFVKcr7qFtnOYVr8qXWkbQ46b4=.20048e16-4bce-4bc6-b2ef-72d1403ce1be@github.com>
 <205-U85HVrJ4n1R9eEzGBgwX1RQ9OCji-CnbRaIqqGI=.da82387c-f896-4a3c-a94d-a6bd27d7d926@github.com>
Message-ID: <zksc72Ss1EwWzQZlRM9hTrr3c2CPUf2Wx8jEZG5lHTI=.0bf427b6-e05e-4d14-912a-9e7dc8c92ef3@github.com>

On Fri, 28 Feb 2025 19:32:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/HPKE.java line 101:
>> 
>>> 99:     @Override
>>> 100:     protected AlgorithmParameters engineGetParameters() {
>>> 101:         return null;
>> 
>> In traditional JCE, wouldn't we return a representation of the `HPKEParameterSpec` which extends `AlgorithmParameters`?
>
> Usually I think `AlgorithmParameters` is used when parameters has a defined ASN.1 encoding starting with an algorithm identifier and ends with the parameters byte. In this case, I am not aware of one. We can consider adding it later if there is one.

I changed my mind. Even if there is no encoding, it's useful to retrieve the actual `HPKEParameterSpec` used by the cipher. This allows the caller to get `kem_id` and other info and pass them to the receiver. For example, [Encrypted ClientHello](https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-23#name-encrypted-clienthello-confi) requires these numbers to be put in a config block.

It's OK if `getEncoded` is not supported now. An `IOException` will be thrown.

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

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

From pminborg at openjdk.org  Thu Mar 13 15:22:43 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 13 Mar 2025 15:22:43 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
Message-ID: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>

> Implement JEP 502.
> 
> The PR passes tier1-tier3 tests.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:

 - Merge branch 'master' into implement-jep502
 - Clean up exception messages and fix comments
 - Rename field
 - Rename method and fix comment
 - Rework reenterant logic
 - Use acquire semantics for reading rather than volatile semantics
 - Add missing null check
 - Simplify handling of sentinel, wrap, and unwrap
 - Fix JavaDoc issues
 - Fix members in StableEnumFunction
 - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

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

Changes: https://git.openjdk.org/jdk/pull/23972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=05
  Stats: 4040 lines in 30 files changed: 4009 ins; 18 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/23972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972

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

From mcimadamore at openjdk.org  Thu Mar 13 15:39:15 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:39:15 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
Message-ID: <MQMqlH-62fZOR02IAAcmYmgKhPLDJL9AsfZWZ1vqxWI=.2cc182f2-051f-4f06-acef-90a27e85d37e@github.com>

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/hotspot/share/ci/ciField.cpp line 254:

> 252: 
> 253: static bool trust_final_non_static_fields_of_type(Symbol* signature) {
> 254:   return signature == vmSymbols::java_lang_StableValue_signature();

Just a note that we will need to decide whether to keep this or not...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993795795

From mcimadamore at openjdk.org  Thu Mar 13 15:52:16 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:52:16 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
Message-ID: <XpnOo9OG0UgG7dNr98Jy8rda2NOSZvNYPA7UQX0FU7c=.cb486622-86f1-4366-91a2-8c1155590801@github.com>

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/lang/StableValue.java line 45:

> 43: 
> 44: /**
> 45:  * A stable value is a shallowly immutable holder of deferred content.

Is this terminology a leftover from previous JEP iterations? The JEP now says: 
>  stable values, which are objects that hold immutable data.

src/java.base/share/classes/java/lang/StableValue.java line 283:

> 281:  * the {@code Foo} does not already exist.
> 282:  * <p>
> 283:  * Here is another example where a more complex dependency graph is created in which

I wonder if just leaving the fibonacci example would be enough here -- as that has a nice dependency graph

src/java.base/share/classes/java/lang/StableValue.java line 330:

> 328:  * thread safe and guarantee at-most-once-per-input invocation.
> 329:  *
> 330:  * <h2 id="miscellaneous">Miscellaneous</h2>

I'm dubious about a section called "misc" :-)

src/java.base/share/classes/java/lang/StableValue.java line 331:

> 329:  *
> 330:  * <h2 id="miscellaneous">Miscellaneous</h2>
> 331:  * Except for a StableValue's content itself, an {@linkplain #orElse(Object) orElse(other)}

missing `{@code}`

src/java.base/share/classes/java/lang/StableValue.java line 335:

> 333:  * parameters must be <em>non-null</em> or a {@link NullPointerException} will be thrown.
> 334:  * <p>
> 335:  * Stable functions and collections are not {@link Serializable} as this would require

Not sure this belongs here. Perhaps the comment on these functions not being serializable should be on their factories. And the point on security vulnerability seems specific and vague at the same time -- better remove it.

src/java.base/share/classes/java/lang/StableValue.java line 339:

> 337:  * which would introduce security vulnerabilities.
> 338:  * <p>
> 339:  * As objects can be set via stable values but never removed, this can be a source

It feels like this could probably be expanded upon -- also covering stable functions (and morphed into a new section)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993819611
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993803509
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993810862
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993805209
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993808888
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993812118

From mcimadamore at openjdk.org  Thu Mar 13 15:52:16 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:52:16 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <XpnOo9OG0UgG7dNr98Jy8rda2NOSZvNYPA7UQX0FU7c=.cb486622-86f1-4366-91a2-8c1155590801@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
 <XpnOo9OG0UgG7dNr98Jy8rda2NOSZvNYPA7UQX0FU7c=.cb486622-86f1-4366-91a2-8c1155590801@github.com>
Message-ID: <HzcTx_inUxv-RYn-J5KglOzZh01D31ILAKBnEb1ICVg=.59b687c8-0c33-43d3-ae3b-f43cb26ba165@github.com>

On Thu, 13 Mar 2025 15:48:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>> 
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - Use acquire semantics for reading rather than volatile semantics
>>  - Add missing null check
>>  - Simplify handling of sentinel, wrap, and unwrap
>>  - Fix JavaDoc issues
>>  - Fix members in StableEnumFunction
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/java/lang/StableValue.java line 45:
> 
>> 43: 
>> 44: /**
>> 45:  * A stable value is a shallowly immutable holder of deferred content.
> 
> Is this terminology a leftover from previous JEP iterations? The JEP now says: 
>>  stable values, which are objects that hold immutable data.

Maybe: `A stable value in an holder for shallowly immutable content`.

> src/java.base/share/classes/java/lang/StableValue.java line 330:
> 
>> 328:  * thread safe and guarantee at-most-once-per-input invocation.
>> 329:  *
>> 330:  * <h2 id="miscellaneous">Miscellaneous</h2>
> 
> I'm dubious about a section called "misc" :-)

We can probably move out some of the contents (I left some suggestions) - then move the remaining into api notes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993822111
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993815323

From mcimadamore at openjdk.org  Thu Mar 13 15:57:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:57:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
Message-ID: <CDrakdC_bHXkOVoDnAh3cpNeXGrHC-n91RO2uJECLeo=.7b01d4a2-e6cd-44a1-8399-7cae080bc153@github.com>

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/java/lang/StableValue.java line 497:

> 495: 
> 496:     /**
> 497:      * {@return a new unset stable supplier}

Should we say "unset" here?

src/java.base/share/classes/java/lang/StableValue.java line 526:

> 524: 
> 525:     /**
> 526:      * {@return a new unset stable int function}

Should we say "unset" here?

src/java.base/share/classes/java/lang/StableValue.java line 564:

> 562: 
> 563:     /**
> 564:      * {@return a new unset stable function}

Should we say "unset" here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993828637
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993829241
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993831680

From mcimadamore at openjdk.org  Thu Mar 13 15:57:10 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 15:57:10 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <CDrakdC_bHXkOVoDnAh3cpNeXGrHC-n91RO2uJECLeo=.7b01d4a2-e6cd-44a1-8399-7cae080bc153@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
 <CDrakdC_bHXkOVoDnAh3cpNeXGrHC-n91RO2uJECLeo=.7b01d4a2-e6cd-44a1-8399-7cae080bc153@github.com>
Message-ID: <wYWFD_7Kqfzt2lTHvWGqk866OmDFLTBOlHn_bBSmtcE=.22efb3e2-2a93-481c-bcd4-fa95fb87bc35@github.com>

On Thu, 13 Mar 2025 15:52:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>> 
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - Use acquire semantics for reading rather than volatile semantics
>>  - Add missing null check
>>  - Simplify handling of sentinel, wrap, and unwrap
>>  - Fix JavaDoc issues
>>  - Fix members in StableEnumFunction
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/java/lang/StableValue.java line 497:
> 
>> 495: 
>> 496:     /**
>> 497:      * {@return a new unset stable supplier}
> 
> Should we say "unset" here?

E.g. we do not define the term "unset supplier" anywhere -- we just define what a stable supplier is -- IMHO that's enough. Also... whether unset or set, that's not really visible by the user?

> src/java.base/share/classes/java/lang/StableValue.java line 564:
> 
>> 562: 
>> 563:     /**
>> 564:      * {@return a new unset stable function}
> 
> Should we say "unset" here?

Same with all the other lazy XYZ factories

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993830847
PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993832264

From mcimadamore at openjdk.org  Thu Mar 13 16:07:14 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Mar 2025 16:07:14 GMT
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
Message-ID: <a7bMFVUZX0bRNKG2fdBG0jE1utnwWWOt7k0ijZkMMyI=.f63c0067-7985-4a25-b3a7-7a372b1eafea@github.com>

On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Implement JEP 502.
>> 
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
> 
>  - Merge branch 'master' into implement-jep502
>  - Clean up exception messages and fix comments
>  - Rename field
>  - Rename method and fix comment
>  - Rework reenterant logic
>  - Use acquire semantics for reading rather than volatile semantics
>  - Add missing null check
>  - Simplify handling of sentinel, wrap, and unwrap
>  - Fix JavaDoc issues
>  - Fix members in StableEnumFunction
>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f

src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 74:

> 72:     @Override
> 73:     public boolean trySet(T value) {
> 74:         if (wrappedContentAcquire() != null) {

IMHO, if our goal is to do:

Object content = this.content;
if (context != null) return content:
synchronized (...) {
    if (context != null) return content:
    this.context = ...
}


Then we might just use a volatile field and synchronized blocks. I don't see an immediate need for using acquire/release semantics -- especially when using a monitor. E.g. this should look more like a classic double checked locking idiom. (but with a stable field to make the first volatile read more efficient in case the field is already set)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993850760

From kdriver at openjdk.org  Thu Mar 13 16:34:49 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Mar 2025 16:34:49 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v9]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <Pjtof8N0_N_6yeJOwg5319RpMHTfoBsythczURyg7pw=.4d0ecb04-3779-48c9-a11c-25282aa000af@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/64061d98..d126d899

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

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

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

From kdriver at openjdk.org  Thu Mar 13 16:46:48 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Mar 2025 16:46:48 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v10]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <NHiaylT3m0TCM7mqJfvUAPmdH44VgoqmNO7r_VvQzOk=.4b7e167b-81da-404c-b422-c34d39f0287d@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/d126d899..9035be7d

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

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

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

From kdriver at openjdk.org  Thu Mar 13 16:46:49 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Mar 2025 16:46:49 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v8]
In-Reply-To: <r9S1aTThzF_jiT1ZzDnz1V8JZtbZ830Y8zF2-8laqJM=.93bef905-02f2-43a7-8249-69d5cdf723ff@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <-GI15YUilcH7a-cOo2ebAHkRU0UUtN893Py8Vd-OlO8=.36327085-2735-49e7-8581-d219c6511ae5@github.com>
 <r9S1aTThzF_jiT1ZzDnz1V8JZtbZ830Y8zF2-8laqJM=.93bef905-02f2-43a7-8249-69d5cdf723ff@github.com>
Message-ID: <Z17xozVI-6SexpiSRchIIFF7J-VDGo7y0GZTOe6e3sI=.4797613d-d191-41d9-be9c-fe738600d22d@github.com>

On Tue, 11 Mar 2025 21:50:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1993:
> 
>> 1991:                 hasMultipleManifests = true;
>> 1992:             }
>> 1993:         }
> 
> Can we put everything above in a try-with-resources block?
> 
> Also, are you sure we only print out this warning when `verbose != null`?

I'll refactor to use try-with-resources.

It was originally described to me as a verbose message, but I don't see anything in the bug description to require it only during verbose. I've removed the check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1993927169

From kdriver at openjdk.org  Thu Mar 13 16:52:57 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Mar 2025 16:52:57 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v8]
In-Reply-To: <r9S1aTThzF_jiT1ZzDnz1V8JZtbZ830Y8zF2-8laqJM=.93bef905-02f2-43a7-8249-69d5cdf723ff@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <-GI15YUilcH7a-cOo2ebAHkRU0UUtN893Py8Vd-OlO8=.36327085-2735-49e7-8581-d219c6511ae5@github.com>
 <r9S1aTThzF_jiT1ZzDnz1V8JZtbZ830Y8zF2-8laqJM=.93bef905-02f2-43a7-8249-69d5cdf723ff@github.com>
Message-ID: <RzCJcQS9hPrOtXaDv7h4sWdlYj3MYcrQUItAnvoTM4o=.a55c1cae-f29a-4b7e-856b-6b1392970cb3@github.com>

On Tue, 11 Mar 2025 21:52:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java line 160:
> 
>> 158:         {"jar.treated.unsigned.see.weak.verbose",
>> 159:                 "WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:"},
>> 160:         {"multiple.manifest.warning.", "Duplicate manifest entries were detected in the jar file. JarSigner will operate on the first one found and others will be discarded."},
> 
> I actually don't know which one will be operated on. If you are sure it is the first one, can you add some lines in the test to check this?

There is another test which checks this behavior: `test/jdk/tools/jar/MultipleManifestTest.java`. Also, it's not really in the scope of the change we're testing here. I've modified the message to be less specific.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1993941458

From kdriver at openjdk.org  Thu Mar 13 17:15:33 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Mar 2025 17:15:33 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v11]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <lYKRabwx7RP5PQYXiOx7b9tFAImnlitw-HMKJO4ol2w=.3e775854-de27-4f35-9c15-d626c44f5d4c@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - merge master
 - merge master
 - code review comments
 - code review comments
 - review comments
 - force-add jar
 - re-write to make the changes in the jarsigner tool itself, rather than the API
 - Revert "JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest."
   
   This reverts commit 06e90503f3e75b1b432ec0a196716f01ebb7344a.
   
   # Please enter the commit message for your changes. Lines starting
   # with '#' will be kept; you may remove them yourself if you want to.
   # An empty message aborts the commit.
   #
   # On branch 8341775
   # Your branch is up to date with 'origin/8341775'.
   #
   # Changes to be committed:
   #	modified:   src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
   #
 - Merge remote-tracking branch 'origin/master' into 8341775
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - Merge branch 'master' of github.com:openjdk/jdk into 8341775
   # Please enter a commit message to explain why this merge is necessary,
   # especially if it merges an updated upstream into a topic branch.
   #
   # Lines starting with '#' will be ignored, and an empty message aborts
   # the commit.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/771e160d...e4677965

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

Changes: https://git.openjdk.org/jdk/pull/22222/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22222&range=10
  Stats: 111 lines in 3 files changed: 111 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22222/head:pull/22222

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

From hchao at openjdk.org  Thu Mar 13 17:31:57 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 13 Mar 2025 17:31:57 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v11]
In-Reply-To: <lYKRabwx7RP5PQYXiOx7b9tFAImnlitw-HMKJO4ol2w=.3e775854-de27-4f35-9c15-d626c44f5d4c@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <lYKRabwx7RP5PQYXiOx7b9tFAImnlitw-HMKJO4ol2w=.3e775854-de27-4f35-9c15-d626c44f5d4c@github.com>
Message-ID: <rYsAIeDQpAGFTjkAM8_j5uyxIcUTPgddk31-3xhc7cY=.58b1dd13-a5b8-4677-a13b-e9966bfbd4d6@github.com>

On Thu, 13 Mar 2025 17:15:33 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - merge master
>  - merge master
>  - code review comments
>  - code review comments
>  - review comments
>  - force-add jar
>  - re-write to make the changes in the jarsigner tool itself, rather than the API
>  - Revert "JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest."
>    
>    This reverts commit 06e90503f3e75b1b432ec0a196716f01ebb7344a.
>    
>    # Please enter the commit message for your changes. Lines starting
>    # with '#' will be kept; you may remove them yourself if you want to.
>    # An empty message aborts the commit.
>    #
>    # On branch 8341775
>    # Your branch is up to date with 'origin/8341775'.
>    #
>    # Changes to be committed:
>    #	modified:   src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
>    #
>  - Merge remote-tracking branch 'origin/master' into 8341775
>    # Please enter a commit message to explain why this merge is necessary,
>    # especially if it merges an updated upstream into a topic branch.
>    #
>    # Lines starting with '#' will be ignored, and an empty message aborts
>    # the commit.
>  - Merge branch 'master' of github.com:openjdk/jdk into 8341775
>    # Please enter a commit message to explain why this merge is necessary,
>    # especially if it merges an updated upstream into a topic branch.
>    #
>    # Lines starting with '#' will be ignored, and an empty message aborts
>    # the commit.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/771e160d...e4677965

test/jdk/sun/security/tools/jarsigner/MultiManifest.java line 2:

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

Change year to 2025

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1994007908

From kdriver at openjdk.org  Thu Mar 13 18:52:11 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Mar 2025 18:52:11 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v12]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <kPH2s7KB7TSI8NJJcWVCXthTVPF3X5vhKZB3Czm9SgY=.97613682-e428-4a95-861c-269133fc28ae@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  test case modifications

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/e4677965..0df41996

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

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

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

From mullan at openjdk.org  Thu Mar 13 18:53:02 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Mar 2025 18:53:02 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
Message-ID: <U9kmiPHFcMEzM5SVXUWu89hRaxssi2b-kpv5spl_v3M=.3d87a2b0-704e-42eb-a8af-f32e417d1994@github.com>

On Wed, 12 Mar 2025 12:18:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> ![HPKEParameterSpec](https://github.com/user-attachments/assets/4a7e6609-fd64-444a-978f-bde1634caa70)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   switch to Asserts.assertThrows in test; use traditional javadoc style

src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 67:

> 65:  * <a href="https://www.iana.org/assignments/hpke/hpke.xhtml">IANA HPKE page</a>.
> 66:  * <p>
> 67:  * Once an {@code HPKEParameterSpec} object is created, additional methods

Are these additional methods commonly called? If so, did you consider using something like a Builder to avoid the extra object creations?

src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 137:

> 135:  * // and the key encapsulation message from the sender
> 136:  * Cipher recipient = Cipher.getInstance("HPKE");
> 137:  * HPKEParameterSpec pr = HPKEParameterSpec.of()

I think it would be useful to give an example with some of the constants.

src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 195:

> 193:      * <a href="https://www.rfc-editor.org/rfc/rfc9180.html#name-key-encapsulation-mechanism">Section 7.1 of RFC 9180</a>.
> 194:      */
> 195:     public static final int KEM_DHKEM_P_256_HKDF_SHA256 = 0x10;

Do we really need `KEM_` at the beginning? Seems redundant since `DHKEM` has "KEM" in it. Same comment for the KDF constants.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1994130149
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1994123059
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1994117322

From kdriver at openjdk.org  Thu Mar 13 18:55:38 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 13 Mar 2025 18:55:38 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v13]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <oXJcOCGreLaTwi_VfgliPzl0eOdZ2GaMZi5vN5pNC50=.7bb96675-2bd9-4875-be90-9b2742d08da2@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  test case modifications

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/0df41996..5bc62324

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

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

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

From sean.mullan at oracle.com  Thu Mar 13 19:03:46 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 13 Mar 2025 15:03:46 -0400
Subject: SSLContext instances
In-Reply-To: <43b0a23e-28ce-4f6c-ad3d-139b53f6197c@gmail.com>
References: <43b0a23e-28ce-4f6c-ad3d-139b53f6197c@gmail.com>
Message-ID: <052f82aa-84d7-479a-95bd-9ab4186f633d@oracle.com>

Hello,

Thanks for your interest in Java Security technology.

> There is also a method SSLContext.setDefault(SSLContext) [3], whose jdk 
> 17 implementation has a permission check (setDefaultSSLContext) to 
> prevent access to calling setDefault.
> 
> With security manager deprecation/removal,? could this create security 
> issues for JVM-based environments???? Particularly modular/dynamic 
> systems? (e.g. OSGi, JPMS)

Have you read JEP 411 [1] and JEP 486 [2]? The motivation explains in 
much more detail that the JDK will no longer be responsible for 
protecting access to operations like this from code in your local 
application (i.e. sandboxing). If you are using code that is calling 
this method or other methods that previously had permission checks, then 
you need to more fully understand the security risks of trusting code 
like that.

--Sean

[1] https://openjdk.org/jeps/411
[2] https://openjdk.org/jeps/486

> 
> Thanks,
> 
> Scott
> 
> [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/ 
> net/ssl/ 
> SSLContext.html#init(javax.net.ssl.KeyManager%5B%5D,javax.net.ssl.TrustManager%5B%5D,java.security.SecureRandom)
> 
> [2] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/ 
> net/ssl/SSLContext.html
> 
> [3] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/ 
> net/ssl/SSLContext.html#setDefault(javax.net.ssl.SSLContext)
> 
> 


From scottslewis at gmail.com  Thu Mar 13 19:44:30 2025
From: scottslewis at gmail.com (Scott Lewis)
Date: Thu, 13 Mar 2025 12:44:30 -0700
Subject: SSLContext instances
In-Reply-To: <052f82aa-84d7-479a-95bd-9ab4186f633d@oracle.com>
References: <43b0a23e-28ce-4f6c-ad3d-139b53f6197c@gmail.com>
 <052f82aa-84d7-479a-95bd-9ab4186f633d@oracle.com>
Message-ID: <751077d2-8a11-42d7-951f-41ca5c366dc9@gmail.com>

Hi Sean,

On 3/13/2025 12:03 PM, Sean Mullan wrote:
> Hello,
>
> Thanks for your interest in Java Security technology.
>
>> There is also a method SSLContext.setDefault(SSLContext) [3], whose 
>> jdk 17 implementation has a permission check (setDefaultSSLContext) 
>> to prevent access to calling setDefault.
>>
>> With security manager deprecation/removal,? could this create 
>> security issues for JVM-based environments???? Particularly 
>> modular/dynamic systems? (e.g. OSGi, JPMS)
>
> Have you read JEP 411 [1] and JEP 486 [2]? 

I am aware of them.

> The motivation explains in much more detail that the JDK will no 
> longer be responsible for protecting access to operations like this 
> from code in your local application (i.e. sandboxing). If you are 
> using code that is calling this method or other methods that 
> previously had permission checks, then you need to more fully 
> understand the security risks of trusting code like that.

Yes I understand that.

But from the point of view of the OSGi framework implementation (for 
example), has there been any discussion to alternatives to leaving 
SSLContext.setDefault open to all code at all times?? e.g. deprecation 
of public static setDefault, or changing the semantics of setDefault so 
that it could only be called successfully once (on startup).? I 
understand that may not be feasible due to api conventions, but was 
wondering if this or other approaches (enhancing JCP) have been 
considered/discussed.

Thanks,

Scott


>
> --Sean
>
> [1] https://openjdk.org/jeps/411
> [2] https://openjdk.org/jeps/486
>
>>
>> Thanks,
>>
>> Scott
>>
>> [1] 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/ 
>> net/ssl/ 
>> SSLContext.html#init(javax.net.ssl.KeyManager%5B%5D,javax.net.ssl.TrustManager%5B%5D,java.security.SecureRandom)
>>
>> [2] 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/ 
>> net/ssl/SSLContext.html
>>
>> [3] 
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/ 
>> net/ssl/SSLContext.html#setDefault(javax.net.ssl.SSLContext)
>>
>>
>

From weijun at openjdk.org  Thu Mar 13 19:55:40 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 19:55:40 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v11]
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: <olSp57rwJ1-hLXJPUrpS-P3trYGByUXgZWxwtyiqR8w=.1576ff4b-a2e1-42fb-ba55-8ab172c7da6b@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> ![HPKEParameterSpec](https://github.com/user-attachments/assets/8cc7101b-92d1-43be-b7b4-24a7ba449231)

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

  getParameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/4bb17504..18e05389

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

  Stats: 226 lines in 6 files changed: 190 ins; 28 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18411/head:pull/18411

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

From weijun at openjdk.org  Thu Mar 13 19:55:41 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 19:55:41 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <U9kmiPHFcMEzM5SVXUWu89hRaxssi2b-kpv5spl_v3M=.3d87a2b0-704e-42eb-a8af-f32e417d1994@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
 <U9kmiPHFcMEzM5SVXUWu89hRaxssi2b-kpv5spl_v3M=.3d87a2b0-704e-42eb-a8af-f32e417d1994@github.com>
Message-ID: <hr2RuHjEy9035kBQRHuGnTuyS7dR_x0lJm9Zw4coY6c=.0bea8f84-6a0d-4ea7-919b-d85890ce792d@github.com>

On Thu, 13 Mar 2025 18:47:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   switch to Asserts.assertThrows in test; use traditional javadoc style
>
> src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 67:
> 
>> 65:  * <a href="https://www.iana.org/assignments/hpke/hpke.xhtml">IANA HPKE page</a>.
>> 66:  * <p>
>> 67:  * Once an {@code HPKEParameterSpec} object is created, additional methods
> 
> Are these additional methods commonly called? If so, did you consider using something like a Builder to avoid the extra object creations?

`info` and `encapsulation` are frequently called. I don't think it's worth using a builder. The final `build()` call is always the same and unnecessary.

> src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 137:
> 
>> 135:  * // and the key encapsulation message from the sender
>> 136:  * Cipher recipient = Cipher.getInstance("HPKE");
>> 137:  * HPKEParameterSpec pr = HPKEParameterSpec.of()
> 
> I think it would be useful to give an example with some of the constants.

I've just pushed a new commit that includes them in the example (the screenshot in the description is also updated). While I haven't used them in `of`, they are compared to values retrieved through `getParameters`.

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

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

From mullan at openjdk.org  Thu Mar 13 19:55:41 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Mar 2025 19:55:41 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
Message-ID: <Sf8_vZmvsUA55xKeRws8uO2sHAbHF4OdLujYJjAzeG4=.9a669ffe-49ac-4246-bf70-7ba8ee995a90@github.com>

On Wed, 12 Mar 2025 12:18:22 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> ![HPKEParameterSpec](https://github.com/user-attachments/assets/8cc7101b-92d1-43be-b7b4-24a7ba449231)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   switch to Asserts.assertThrows in test; use traditional javadoc style

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

> 669: #   jdk.hpke.disabledAlgorithms=kem_id=0x10,kdf_id=0x01,aead_id=0xffff
> 670: #
> 671: jdk.hpke.disabledAlgorithms=

Do you expect that these algorithm ids would be embedded in some higher level network protocols or artifacts and thus could potentially be leveraged that way? Trying to understand the motivation/need for this property, as we have not (as of yet) disabled algorithms at the JCE layer, with the rationale that it is up to the developer to understand the security risks of directly using a weak or crypto algorithm.

There may also be some overlap with Red Hat's proposed Security Providers Filter.

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

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

From mullan at openjdk.org  Thu Mar 13 20:01:09 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Mar 2025 20:01:09 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <hr2RuHjEy9035kBQRHuGnTuyS7dR_x0lJm9Zw4coY6c=.0bea8f84-6a0d-4ea7-919b-d85890ce792d@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
 <U9kmiPHFcMEzM5SVXUWu89hRaxssi2b-kpv5spl_v3M=.3d87a2b0-704e-42eb-a8af-f32e417d1994@github.com>
 <hr2RuHjEy9035kBQRHuGnTuyS7dR_x0lJm9Zw4coY6c=.0bea8f84-6a0d-4ea7-919b-d85890ce792d@github.com>
Message-ID: <qqErsP48FHU_GKyQxOX76BqgyUlj-dpJkS6fcLINB7A=.8d4e20d2-5584-4f95-a4e1-e8d7517d7bac@github.com>

On Thu, 13 Mar 2025 19:45:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 67:
>> 
>>> 65:  * <a href="https://www.iana.org/assignments/hpke/hpke.xhtml">IANA HPKE page</a>.
>>> 66:  * <p>
>>> 67:  * Once an {@code HPKEParameterSpec} object is created, additional methods
>> 
>> Are these additional methods commonly called? If so, did you consider using something like a Builder to avoid the extra object creations?
>
> `info` and `encapsulation` are frequently called. I don't think it's worth using a builder. The final `build()` call is always the same and unnecessary.

If they are common, would it make more sense to include them as parameters to an overloaded version of the static `of` method?

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

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

From weijun at openjdk.org  Thu Mar 13 20:06:56 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 20:06:56 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <U9kmiPHFcMEzM5SVXUWu89hRaxssi2b-kpv5spl_v3M=.3d87a2b0-704e-42eb-a8af-f32e417d1994@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
 <U9kmiPHFcMEzM5SVXUWu89hRaxssi2b-kpv5spl_v3M=.3d87a2b0-704e-42eb-a8af-f32e417d1994@github.com>
Message-ID: <QlfPjuzyviTyLQVcrvLVeo6cnD0Rmpxkqkd6M7WW-8s=.fb0ed8e3-e346-4680-b0a3-424cb698cae9@github.com>

On Thu, 13 Mar 2025 18:37:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   switch to Asserts.assertThrows in test; use traditional javadoc style
>
> src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 195:
> 
>> 193:      * <a href="https://www.rfc-editor.org/rfc/rfc9180.html#name-key-encapsulation-mechanism">Section 7.1 of RFC 9180</a>.
>> 194:      */
>> 195:     public static final int KEM_DHKEM_P_256_HKDF_SHA256 = 0x10;
> 
> Do we really need `KEM_` at the beginning? Seems redundant since `DHKEM` has "KEM" in it. Same comment for the KDF constants.

I was hoping that IDE auto-completion would eliminate the need to type the full name. Adding `KEM` at the beginning could amend the type-unsafety of current algorithm identifiers -- it somehow prevents putting a KDF id as the first argument of an `of` call accidentally. Maybe that is just my wishful thinking?

Also, there will be KEM names like "X_WING" in the future.

I've also thought about defining `enum`s for the three types of algorithm identifiers to finally solve the type-unsafety issue. However, I hesitate to add them since it's such a think layer and users who need it can easily create their own.

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

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

From mullan at openjdk.org  Thu Mar 13 20:18:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 13 Mar 2025 20:18:00 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <QlfPjuzyviTyLQVcrvLVeo6cnD0Rmpxkqkd6M7WW-8s=.fb0ed8e3-e346-4680-b0a3-424cb698cae9@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
 <U9kmiPHFcMEzM5SVXUWu89hRaxssi2b-kpv5spl_v3M=.3d87a2b0-704e-42eb-a8af-f32e417d1994@github.com>
 <QlfPjuzyviTyLQVcrvLVeo6cnD0Rmpxkqkd6M7WW-8s=.fb0ed8e3-e346-4680-b0a3-424cb698cae9@github.com>
Message-ID: <0HaQGrri2R5foiRE-E2aZi5yCnkgGVenrukdko5t3PE=.8c173606-e54d-4c8c-b55f-4005c840264e@github.com>

On Thu, 13 Mar 2025 20:04:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 195:
>> 
>>> 193:      * <a href="https://www.rfc-editor.org/rfc/rfc9180.html#name-key-encapsulation-mechanism">Section 7.1 of RFC 9180</a>.
>>> 194:      */
>>> 195:     public static final int KEM_DHKEM_P_256_HKDF_SHA256 = 0x10;
>> 
>> Do we really need `KEM_` at the beginning? Seems redundant since `DHKEM` has "KEM" in it. Same comment for the KDF constants.
>
> I was hoping that IDE auto-completion would eliminate the need to type the full name. Adding `KEM` at the beginning could amend the type-unsafety of current algorithm identifiers -- it somehow prevents putting a KDF id as the first argument of an `of` call accidentally. Maybe that is just my wishful thinking?
> 
> Also, there will be KEM names like "X_WING" in the future.
> 
> I've also thought about defining `enum`s for the three types of algorithm identifiers to finally solve the type-unsafety issue. However, I hesitate to add them since it's such a think layer and users who need it can easily create their own.

Makes sense. Copy and paste is easy enough as well.

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

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

From weijun at openjdk.org  Thu Mar 13 20:18:02 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 20:18:02 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <Sf8_vZmvsUA55xKeRws8uO2sHAbHF4OdLujYJjAzeG4=.9a669ffe-49ac-4246-bf70-7ba8ee995a90@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
 <Sf8_vZmvsUA55xKeRws8uO2sHAbHF4OdLujYJjAzeG4=.9a669ffe-49ac-4246-bf70-7ba8ee995a90@github.com>
Message-ID: <s7MGvVvEQlANKRDyM8TNvg3_9DpEdB7UtSWy-1bBBUA=.e0f46a32-7f71-43a7-ac2d-bfed4a50cbab@github.com>

On Thu, 13 Mar 2025 19:52:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   switch to Asserts.assertThrows in test; use traditional javadoc style
>
> src/java.base/share/conf/security/java.security line 671:
> 
>> 669: #   jdk.hpke.disabledAlgorithms=kem_id=0x10,kdf_id=0x01,aead_id=0xffff
>> 670: #
>> 671: jdk.hpke.disabledAlgorithms=
> 
> Do you expect that these algorithm ids would be embedded in some higher level network protocols or artifacts and thus could potentially be leveraged that way? Trying to understand the motivation/need for this property, as we have not (as of yet) disabled algorithms at the JCE layer, with the rationale that it is up to the developer to understand the security risks of directly using a weak crypto algorithm.
> 
> There may also be some overlap with Red Hat's proposed Security Providers Filter.

You?re right. I can remove this part if there?s no requirement yet. For TLS, we already enforce constraints through the existing TLS security property. Perhaps another usage scope is enough when we start supporting Encrypted ClientHello.

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

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

From weijun at openjdk.org  Thu Mar 13 20:30:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 20:30:06 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v11]
In-Reply-To: <olSp57rwJ1-hLXJPUrpS-P3trYGByUXgZWxwtyiqR8w=.1576ff4b-a2e1-42fb-ba55-8ab172c7da6b@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <olSp57rwJ1-hLXJPUrpS-P3trYGByUXgZWxwtyiqR8w=.1576ff4b-a2e1-42fb-ba55-8ab172c7da6b@github.com>
Message-ID: <XMl3YZrVLQnBSmX8yfH2d3Olr4Pcs6gg2Xxkokb1j3c=.8c1d770c-c4f2-4d6c-a75a-135986868f89@github.com>

On Thu, 13 Mar 2025 19:55:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> ![HPKEParameterSpec](https://github.com/user-attachments/assets/8cc7101b-92d1-43be-b7b4-24a7ba449231)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   getParameters

I?ve pushed a new commit that allows the sender to retrieve the actual algorithm identifiers used. These identifiers should typically be sent along with the key encapsulation message when establishing an HPKE encryption channel, enabling the receiver to construct the same `HPKEParameterSpec` to initialize their cipher. This is reflected in the updated example in the class spec.

Furthermore, I almost believe the receiver should not be allowed to initialize an HPKE cipher with an `HPKEParameterSpec` that has unspecified algorithm identifiers. This becomes especially important if different HPKE implementations have different defaults. What do you think? Or, we can just leave this to callers?

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

PR Comment: https://git.openjdk.org/jdk/pull/18411#issuecomment-2722616174

From hchao at openjdk.org  Thu Mar 13 21:21:59 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 13 Mar 2025 21:21:59 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v13]
In-Reply-To: <oXJcOCGreLaTwi_VfgliPzl0eOdZ2GaMZi5vN5pNC50=.7bb96675-2bd9-4875-be90-9b2742d08da2@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <oXJcOCGreLaTwi_VfgliPzl0eOdZ2GaMZi5vN5pNC50=.7bb96675-2bd9-4875-be90-9b2742d08da2@github.com>
Message-ID: <d0ONPmsSfBWUL8pKMxwgH__ZppRE7l-IJ5wlEzEsEKY=.e24dc0a3-5eb9-484a-adbb-d560259051e2@github.com>

On Thu, 13 Mar 2025 18:55:38 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test case modifications

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

> 97: jar.treated.unsigned.see.weak=The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled.\n\nRe-run jarsigner with the -verbose option for more details.
> 98: jar.treated.unsigned.see.weak.verbose=WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:
> 99: multiple.manifest.warning.=Duplicate manifest entries were detected in the jar file. JarSigner will operate on only one and the others will be discarded.

Shall we have a a past-tense phrase to make it clearer that the extra entries were actually deleted? Something like:
"Duplicate manifest entries were detected in the JAR file. JarSigner operated on only one, and the others have been discarded."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1994316284

From ascarpino at openjdk.org  Thu Mar 13 21:25:58 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 13 Mar 2025 21:25:58 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v18]
In-Reply-To: <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
Message-ID: <UX2lW9_dZgPvvDdLTHdHp75Ce9PjxNUFCMwrqDbufc4=.052757b2-63bd-4c6d-a970-d0f84db6255c@github.com>

On Wed, 12 Mar 2025 17:26:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix

src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 658:

> 656:             // contain signature schemes supported for both:
> 657:             // handshake signatures and certificate signatures.
> 658:             List<SignatureScheme> certReqSignAlgs =

Are you making a copy in case `shc.localSupportedCertSignAlg` changes?  Since this is coming from a handshake context, I don't see why it would ever change during the lifetime of the connection.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1994320460

From ascarpino at openjdk.org  Thu Mar 13 22:48:54 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 13 Mar 2025 22:48:54 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v18]
In-Reply-To: <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
Message-ID: <1dMAO2jw9Yoz1nUpGml5EoCaTCmYJmVS1uK_qyVwbsc=.9ecca7d7-d65b-41e9-9821-69b2331427e4@github.com>

On Wed, 12 Mar 2025 17:26:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix

src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 198:

> 196:         this.host = hc.conContext.transport.getPeerHost();
> 197:         this.port = hc.conContext.transport.getPeerPort();
> 198:         this.localSupportedSignAlgs = hc.localSupportedCertSignAlgs == null ?

Can we change `this.localSupportedSignAlgs` to something that reflects that it's cert signature algorithms?  With many places having both `localSupportedSignAlgs` and `localSupportedCertSignAlgs`, it's confusing to see the non-cert variable set to the cert list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1994391497

From weijun at openjdk.org  Thu Mar 13 23:20:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 23:20:52 GMT
Subject: RFR: 8350964: Add an ArtifactResolver.fetch(clazz) method [v5]
In-Reply-To: <VFTT7vn2zJQDu-cJ4-V3cB7pWEi7NynMhHtDvFS-6sg=.1808f559-b870-4377-ad82-b9580135d18c@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
 <VFTT7vn2zJQDu-cJ4-V3cB7pWEi7NynMhHtDvFS-6sg=.1808f559-b870-4377-ad82-b9580135d18c@github.com>
Message-ID: <b9aNuWYMR8WzCup2YqrBeb4g5VNXTCKVDjPDhniHej8=.cfa16fd2-b7bb-4dd3-82ab-9e320ad1f7e1@github.com>

On Thu, 13 Mar 2025 11:25:34 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed imports and copyright year

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23989#pullrequestreview-2683571034

From weijun at openjdk.org  Thu Mar 13 23:28:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 23:28:59 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v13]
In-Reply-To: <d0ONPmsSfBWUL8pKMxwgH__ZppRE7l-IJ5wlEzEsEKY=.e24dc0a3-5eb9-484a-adbb-d560259051e2@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <oXJcOCGreLaTwi_VfgliPzl0eOdZ2GaMZi5vN5pNC50=.7bb96675-2bd9-4875-be90-9b2742d08da2@github.com>
 <d0ONPmsSfBWUL8pKMxwgH__ZppRE7l-IJ5wlEzEsEKY=.e24dc0a3-5eb9-484a-adbb-d560259051e2@github.com>
Message-ID: <wCrBbdFFNDVSYEiiQoTKeeFfyXRmd9_3QJt7c_Bks4E=.d0d479b2-0c4c-4b79-b424-3ec6fd064662@github.com>

On Thu, 13 Mar 2025 21:18:31 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test case modifications
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 99:
> 
>> 97: jar.treated.unsigned.see.weak=The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled.\n\nRe-run jarsigner with the -verbose option for more details.
>> 98: jar.treated.unsigned.see.weak.verbose=WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:
>> 99: multiple.manifest.warning.=Duplicate manifest entries were detected in the jar file. JarSigner will operate on only one and the others will be discarded.
> 
> Shall we have a a past-tense phrase to make it clearer that the extra entries were actually deleted? Something like:
> "Duplicate manifest entries were detected in the JAR file. JarSigner operated on only one, and the others have been discarded."

Maybe. When this warning shows up, the extra entries have already been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1994425115

From hchao at openjdk.org  Fri Mar 14 00:36:20 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Mar 2025 00:36:20 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v3]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <GvYe79UUt8hQNN3x-I2bXrCdP2wJJyYb_njBb0Itmk4=.259d2b0e-886b-461c-99e0-05434d503215@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Revert changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/28a9038b..d7f8536b

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

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

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

From hchao at openjdk.org  Fri Mar 14 00:45:11 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Mar 2025 00:45:11 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v4]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <7AsshGS66v2RyVLgoEcxDBq85_3DQsEqQyaxf6HNerE=.b3e249cb-0663-44f4-a0b6-72985713a2a0@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - changes merged
 - Merge
 - Revert changes
 - Update with review comment
 - Remove unneeded compressed large jar test
 - Test on large entry
 - Add cross checking in jarsigner instead of accessing ZIP internals
 - Revert changes to Resources.java
 - Revert changes to Main.java
 - Revert changes to Test.java
 - ... and 15 more: https://git.openjdk.org/jdk/compare/04544064...ad61b35b

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

Changes: https://git.openjdk.org/jdk/pull/23532/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=03
  Stats: 137 lines in 2 files changed: 136 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

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

From weijun at openjdk.org  Fri Mar 14 02:49:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Mar 2025 02:49:59 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <qqErsP48FHU_GKyQxOX76BqgyUlj-dpJkS6fcLINB7A=.8d4e20d2-5584-4f95-a4e1-e8d7517d7bac@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
 <U9kmiPHFcMEzM5SVXUWu89hRaxssi2b-kpv5spl_v3M=.3d87a2b0-704e-42eb-a8af-f32e417d1994@github.com>
 <hr2RuHjEy9035kBQRHuGnTuyS7dR_x0lJm9Zw4coY6c=.0bea8f84-6a0d-4ea7-919b-d85890ce792d@github.com>
 <qqErsP48FHU_GKyQxOX76BqgyUlj-dpJkS6fcLINB7A=.8d4e20d2-5584-4f95-a4e1-e8d7517d7bac@github.com>
Message-ID: <XJgoVxbmn6SewBgxBozWCgEJVNwT-dHvlFJqb6hghqw=.5d200612-a55b-48d1-9c56-b6872b85d737@github.com>

On Thu, 13 Mar 2025 19:58:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> `info` and `encapsulation` are frequently called. I don't think it's worth using a builder. The final `build()` call is always the same and unnecessary.
>
> If they are common, would it make more sense to include them as parameters to an overloaded version of the static `of` method?

I'd rather not. There are already three `of` methods. Adding `info` would make make six, and adding `encapsulation` would be twelve. I cannot say which combination is more popular than another one.

Also,  the arguments of the current `of` methods are all about algorithm identifiers. Adding `info` and `encapsulation` to the argument list could make the API harder to use, as the method signature only includes the types of the parameters but not their meanings. While providing them through the `info` and `encapsulation` methods are very clean. They also have accompanying "getter" methods with the same names.

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

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

From weijun at openjdk.org  Fri Mar 14 13:39:43 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Mar 2025 13:39:43 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v12]
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: <efr4HAgYQsSnp6gKYHhgllmncH7e2vx4u8sPMe6I4c0=.8045308e-9544-47bc-acc7-aef780b4b6e7@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> ![HPKEParameterSpec](https://github.com/user-attachments/assets/8cc7101b-92d1-43be-b7b4-24a7ba449231)

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

  remove disabled identifiers check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/18e05389..25d2fb17

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

  Stats: 178 lines in 3 files changed: 0 ins; 178 del; 0 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 abarashev at openjdk.org  Fri Mar 14 13:41:57 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 14 Mar 2025 13:41:57 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v18]
In-Reply-To: <1dMAO2jw9Yoz1nUpGml5EoCaTCmYJmVS1uK_qyVwbsc=.9ecca7d7-d65b-41e9-9821-69b2331427e4@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
 <1dMAO2jw9Yoz1nUpGml5EoCaTCmYJmVS1uK_qyVwbsc=.9ecca7d7-d65b-41e9-9821-69b2331427e4@github.com>
Message-ID: <MKWsYQg153k59WmyIYndTz9w7pYinqXupjwy4EoRZp8=.7a518da7-f78b-49fd-b8d9-8816f6d7ab89@github.com>

On Thu, 13 Mar 2025 22:45:11 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo fix
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 198:
> 
>> 196:         this.host = hc.conContext.transport.getPeerHost();
>> 197:         this.port = hc.conContext.transport.getPeerPort();
>> 198:         this.localSupportedSignAlgs = hc.localSupportedCertSignAlgs == null ?
> 
> Can we change `this.localSupportedSignAlgs` to something that reflects that it's cert signature algorithms?  All the other uses in the PR that I've noticed have `localSupportedSignAlgs` set to handshake signature algorithms.   It's confusing to this one set to the cert list.  An alternative is to use "handshake" in the other variable names, but that is likely a bigger change.

Yes, I also thought about renaming session's `localSupportedSignAlgs` and `peerSupportedSignAlgs` variables, I'm on the fence about it. The thing is we don't really change anything about those variables: they will be used only for certificate's signature algorithm check just like before this change. And they were named this way initially although it was known they are to be used only for certificate signatures.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1995602276

From weijun at openjdk.org  Fri Mar 14 14:09:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Mar 2025 14:09:50 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v10]
In-Reply-To: <s7MGvVvEQlANKRDyM8TNvg3_9DpEdB7UtSWy-1bBBUA=.e0f46a32-7f71-43a7-ac2d-bfed4a50cbab@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <8KI25oonwxvjae5rfrDeCWFnkR_g_3UFFl6_Sb6D3T8=.1416d265-b07f-4c13-b6dc-dd6a770a139b@github.com>
 <Sf8_vZmvsUA55xKeRws8uO2sHAbHF4OdLujYJjAzeG4=.9a669ffe-49ac-4246-bf70-7ba8ee995a90@github.com>
 <s7MGvVvEQlANKRDyM8TNvg3_9DpEdB7UtSWy-1bBBUA=.e0f46a32-7f71-43a7-ac2d-bfed4a50cbab@github.com>
Message-ID: <6j3vmgexNp_UtuhgWSHe77W15D1k7pmgh6nvW_pYTVw=.254797cc-22e9-479a-bab2-b715bf22811c@github.com>

On Thu, 13 Mar 2025 20:15:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 671:
>> 
>>> 669: #   jdk.hpke.disabledAlgorithms=kem_id=0x10,kdf_id=0x01,aead_id=0xffff
>>> 670: #
>>> 671: jdk.hpke.disabledAlgorithms=
>> 
>> Do you expect that these algorithm ids would be embedded in some higher level network protocols or artifacts and thus could potentially be leveraged that way? Trying to understand the motivation/need for this property, as we have not (as of yet) disabled algorithms at the JCE layer, with the rationale that it is up to the developer to understand the security risks of directly using a weak crypto algorithm.
>> 
>> There may also be some overlap with Red Hat's proposed Security Providers Filter.
>
> You?re right. I can remove this part if there?s no requirement yet. For TLS, we already enforce constraints through the existing TLS security property. Perhaps another usage scope is enough when we start supporting Encrypted ClientHello.

Removed.

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

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

From weijun at openjdk.org  Fri Mar 14 14:09:49 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Mar 2025 14:09:49 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v13]
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: <YppedScMeQ7kkl1tDnV07UEVzW-KwjPELABpOL6RQB4=.eb8fbfea-4407-4bb8-9fd1-b426e9d0c381@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> ![HPKEParameterSpec](https://github.com/user-attachments/assets/8cc7101b-92d1-43be-b7b4-24a7ba449231)

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 24 additional commits since the last revision:

 - Merge branch 'master' into 8325448
 - remove unused imports
 - remove disabled identifiers check
 - getParameters
 - switch to Asserts.assertThrows in test; use traditional javadoc style
 - of(kdf_id, aead_id) and constants
 - add mode_auth and mode_auth_psk, tiny spec change
 - unspecified id is -1 now
 - typo, and other cleanup
 - renames, precise req, more spec, wrappings
 - ... and 14 more: https://git.openjdk.org/jdk/compare/d67e65fb...c578ef5d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/25d2fb17..c578ef5d

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

  Stats: 74664 lines in 1561 files changed: 36209 ins; 25642 del; 12813 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 kdriver at openjdk.org  Fri Mar 14 15:13:54 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 14 Mar 2025 15:13:54 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v14]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <GGgKFLE2C5YfVYFq5g4jnYwzwAfltllBGtdj4EI8DKA=.aa9566e1-b1d1-4641-a1cb-e4aa2fb00fe2@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  changed verb tense in messaging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/5bc62324..c966b78a

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

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

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

From weijun at openjdk.org  Fri Mar 14 15:49:01 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Mar 2025 15:49:01 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v14]
In-Reply-To: <GGgKFLE2C5YfVYFq5g4jnYwzwAfltllBGtdj4EI8DKA=.aa9566e1-b1d1-4641-a1cb-e4aa2fb00fe2@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <GGgKFLE2C5YfVYFq5g4jnYwzwAfltllBGtdj4EI8DKA=.aa9566e1-b1d1-4641-a1cb-e4aa2fb00fe2@github.com>
Message-ID: <jNYs9lB4_D0wE6c1liRKO6epSk2dVjijpayHo09RGD4=.9d5305ca-4f62-4e76-b604-032b542613c0@github.com>

On Fri, 14 Mar 2025 15:13:54 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed verb tense in messaging

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22222#pullrequestreview-2685977801

From kdriver at openjdk.org  Fri Mar 14 15:55:51 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 14 Mar 2025 15:55:51 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v15]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <7k3KMjo2lXIpGFE2FRox04-6waQiO01l9cldYZBvVUg=.83c2478d-b852-4b1d-bff3-b1c2e060dc77@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  make 2025 the only copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/c966b78a..6faaaba5

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

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

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

From hchao at openjdk.org  Fri Mar 14 16:03:00 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Mar 2025 16:03:00 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v15]
In-Reply-To: <7k3KMjo2lXIpGFE2FRox04-6waQiO01l9cldYZBvVUg=.83c2478d-b852-4b1d-bff3-b1c2e060dc77@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <7k3KMjo2lXIpGFE2FRox04-6waQiO01l9cldYZBvVUg=.83c2478d-b852-4b1d-bff3-b1c2e060dc77@github.com>
Message-ID: <GqlYP1ShQJCb2UYJS-q-TcqKerzVXoGhDdGf53b_MMQ=.b1ecd5d7-e3fc-47b7-a848-87ebef87002c@github.com>

On Fri, 14 Mar 2025 15:55:51 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make 2025 the only copyright year

Marked as reviewed by hchao (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22222#pullrequestreview-2686023950

From hchao at openjdk.org  Fri Mar 14 16:03:01 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Mar 2025 16:03:01 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v13]
In-Reply-To: <wCrBbdFFNDVSYEiiQoTKeeFfyXRmd9_3QJt7c_Bks4E=.d0d479b2-0c4c-4b79-b424-3ec6fd064662@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <oXJcOCGreLaTwi_VfgliPzl0eOdZ2GaMZi5vN5pNC50=.7bb96675-2bd9-4875-be90-9b2742d08da2@github.com>
 <d0ONPmsSfBWUL8pKMxwgH__ZppRE7l-IJ5wlEzEsEKY=.e24dc0a3-5eb9-484a-adbb-d560259051e2@github.com>
 <wCrBbdFFNDVSYEiiQoTKeeFfyXRmd9_3QJt7c_Bks4E=.d0d479b2-0c4c-4b79-b424-3ec6fd064662@github.com>
Message-ID: <nrmA44scwtq22DzzZIHqWUqP4pQNaqw_xzEPYc2Ws-M=.cc63f35e-18ee-44a0-8459-f2af145b510c@github.com>

On Thu, 13 Mar 2025 23:26:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 99:
>> 
>>> 97: jar.treated.unsigned.see.weak=The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled.\n\nRe-run jarsigner with the -verbose option for more details.
>>> 98: jar.treated.unsigned.see.weak.verbose=WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:
>>> 99: multiple.manifest.warning.=Duplicate manifest entries were detected in the jar file. JarSigner will operate on only one and the others will be discarded.
>> 
>> Shall we have a a past-tense phrase to make it clearer that the extra entries were actually deleted? Something like:
>> "Duplicate manifest entries were detected in the JAR file. JarSigner operated on only one, and the others have been discarded."
>
> Maybe. When this warning shows up, the extra entries have already been removed.

Thanks for the update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1995833653

From kdriver at openjdk.org  Fri Mar 14 16:13:14 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 14 Mar 2025 16:13:14 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v16]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <FE1Yo81G_0FPrd_sSANmreynTWovGKPhxGiUqKnYUpQ=.95f25dd3-e33b-4c80-b336-ec7be542e391@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:

 - update copyright for manpage markdown
 - update manpage markdown

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/6faaaba5..1ec9a991

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

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

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

From kdriver at openjdk.org  Fri Mar 14 16:19:43 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 14 Mar 2025 16:19:43 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v17]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <NJtr_wlFGt7eaa6QmDK91AGkvXmtidSJsfyMhg3HkJM=.af75337c-7b8a-4363-b266-ad22107cfef4@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  remove trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/1ec9a991..92022e0c

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

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

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

From kdriver at openjdk.org  Fri Mar 14 16:32:24 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 14 Mar 2025 16:32:24 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v18]
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <xXTlIPbJhKeNeOgCtd8mzZVUaQXRDPuuxvzqreN8IKM=.c36172db-bb2a-4ee9-a1d3-60d79a0fa431@github.com>

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  ordered new message alphabetically

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22222/files
  - new: https://git.openjdk.org/jdk/pull/22222/files/92022e0c..447e33a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22222&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22222&range=16-17

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

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

From hchao at openjdk.org  Fri Mar 14 16:32:25 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Mar 2025 16:32:25 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v17]
In-Reply-To: <NJtr_wlFGt7eaa6QmDK91AGkvXmtidSJsfyMhg3HkJM=.af75337c-7b8a-4363-b266-ad22107cfef4@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <NJtr_wlFGt7eaa6QmDK91AGkvXmtidSJsfyMhg3HkJM=.af75337c-7b8a-4363-b266-ad22107cfef4@github.com>
Message-ID: <X8YQD8VJSW9CttasQkm3Pq5KPjCt6XtK7PHBtf1bl0I=.16921c2a-0f52-45b7-ae0c-99e2298d85c0@github.com>

On Fri, 14 Mar 2025 16:19:43 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing whitespace

src/jdk.jartool/share/man/jarsigner.md line 937:

> 935:     date.
> 936: 
> 937: hasMultipleManifests

Suggest to place the new warning in alphabetical order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22222#discussion_r1995879944

From weijun at openjdk.org  Fri Mar 14 18:36:02 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Mar 2025 18:36:02 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v18]
In-Reply-To: <xXTlIPbJhKeNeOgCtd8mzZVUaQXRDPuuxvzqreN8IKM=.c36172db-bb2a-4ee9-a1d3-60d79a0fa431@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <xXTlIPbJhKeNeOgCtd8mzZVUaQXRDPuuxvzqreN8IKM=.c36172db-bb2a-4ee9-a1d3-60d79a0fa431@github.com>
Message-ID: <rfGH5M3Q_lsXIC45HF3ByweWjIP5cppyoTJOSvd0CTA=.b39b8304-8d21-4e0b-a0d0-6103e19501c5@github.com>

On Fri, 14 Mar 2025 16:32:24 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ordered new message alphabetically

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22222#pullrequestreview-2686426045

From rriggs at openjdk.org  Fri Mar 14 18:39:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Mar 2025 18:39:38 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
Message-ID: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>

Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

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

Commit messages:
 - 8351970: Retire JavaLangAccess::exit

Changes: https://git.openjdk.org/jdk/pull/24066/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351970
  Stats: 13 lines in 3 files changed: 0 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24066/head:pull/24066

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

From rgiulietti at openjdk.org  Fri Mar 14 19:03:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 14 Mar 2025 19:03:51 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
References: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
Message-ID: <4kjDoe01Av7cEkYrTuBsXVxrFScbCsyhWPkc44GpNb4=.8b0fbb2d-71ed-4533-8280-17d4b18cedf1@github.com>

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

Looks fine.

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24066#pullrequestreview-2686559418

From hchao at openjdk.org  Fri Mar 14 19:11:55 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Mar 2025 19:11:55 GMT
Subject: RFR: 8341775: Duplicate manifest files are removed by jarsigner
 after signing [v18]
In-Reply-To: <xXTlIPbJhKeNeOgCtd8mzZVUaQXRDPuuxvzqreN8IKM=.c36172db-bb2a-4ee9-a1d3-60d79a0fa431@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
 <xXTlIPbJhKeNeOgCtd8mzZVUaQXRDPuuxvzqreN8IKM=.c36172db-bb2a-4ee9-a1d3-60d79a0fa431@github.com>
Message-ID: <yvk_J6W3EGRRUlwyBcAqNau7hsdVvWLL4S7XWieSO0E=.08b196b3-c097-4c58-9d1b-99fc40168c02@github.com>

On Fri, 14 Mar 2025 16:32:24 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ordered new message alphabetically

Marked as reviewed by hchao (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22222#pullrequestreview-2686579259

From weijun at openjdk.org  Fri Mar 14 19:46:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 14 Mar 2025 19:46:57 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v4]
In-Reply-To: <gFOi2wc0zFdeRd3NEKBBvTJ64LhHm6uDFKtDrO5JXQ0=.ec6bbbe6-3767-494d-9ad1-5bb1f1930bad@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <c5KF8wFufjEbuAeFj2Mpc7M60j8jTyns-XP5iY8K194=.283efa1e-f662-4592-b1ba-0ea25a6c0bfb@github.com>
 <Z0-G2-rRsTESI2O9BOQHsAXjeVIloZ4T3--0dkm2EiU=.b5b1f7e1-6e8e-4a8b-82d1-ae6c7c09d996@github.com>
 <gFOi2wc0zFdeRd3NEKBBvTJ64LhHm6uDFKtDrO5JXQ0=.ec6bbbe6-3767-494d-9ad1-5bb1f1930bad@github.com>
Message-ID: <F2wGWIqSNQdN0JDiUsQfHzb-SbQrdZBx1f1XtL4p738=.d2363c53-e312-4401-b317-0128dc2b6575@github.com>

On Fri, 7 Mar 2025 22:03:56 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 86:
>> 
>>> 84:                 Arrays.asList(
>>> 85:                     new TestCase("EdDSA", false),
>>> 86:                     new TestCase("Ed25519", true),
>> 
>> Why should the above pass? If you disable `EdDSA` and you are still allowed `Signature.getInstance("Ed25519")`? If this is because it will reject whatever EdDSA key later? Why both check `CryptoPrimitive.SIGNATURE` at all?
>
> I'm confused by this comment.  With removing the hardcoded aliases in AbstractAlgorithmConstraints, which is what I thought you had suggested, EdDSA and Ed25519 are now separate as the check is effectively a string compare check against the disabledAlgorithm list
> 
> The second half of that case statement has a key that can check against both EdDSA and the NPS.
> 
> With respect to `CryptoPrimitive.SIGNATURE`, it just a value used in the test, it can't be null.

Yes, I remember that.

I understand there will be multiple checks in TLS and CertPath. Do we have existing tests on that level?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1996180604

From rriggs at openjdk.org  Fri Mar 14 19:47:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Mar 2025 19:47:52 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
References: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
Message-ID: <vkWmv2e4f8F2JAXi0jKEGHIo0Z8U2WG3kbNJuRcFBSw=.4a9715fc-04c1-4d2a-839f-b3c7febbf13a@github.com>

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

There are other non-recoverable errors that occur in the runtime that throw InternalError or AssertionError instead of calling System.exit. Calling System.exit seems like overkill. 
I did not find any discussion in the review of 8304265: Implementation of Foreign Function and Memory API with respect to that necessity. (https://git.openjdk.org/jdk/pull/13079)

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

PR Comment: https://git.openjdk.org/jdk/pull/24066#issuecomment-2725605716

From valeriep at openjdk.org  Fri Mar 14 22:03:28 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 14 Mar 2025 22:03:28 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings
Message-ID: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>

As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings.

Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility.

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

Commit messages:
 - 8348732: SunJCE and SunPKCS11 have different PBE key encodings

Changes: https://git.openjdk.org/jdk/pull/24068/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348732
  Stats: 356 lines in 11 files changed: 39 ins; 242 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/24068.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24068/head:pull/24068

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

From hchao at openjdk.org  Fri Mar 14 22:48:06 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 14 Mar 2025 22:48:06 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v5]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <Rj_ZDtDfaxuhZQ5XT1iyiDX4SU0LnOQeeyX_hxLmmqY=.6be4d0da-7ce4-40a8-b5f3-a03a6c4eba71@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Remove sorting for cenEntries

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/ad61b35b..867ba607

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

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

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

From liach at openjdk.org  Fri Mar 14 23:07:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Mar 2025 23:07:51 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
References: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
Message-ID: <gNzOITDP7SF1VcwTZSYcy-xKQzOxoARyOAtdW8qVpsk=.efb11cfc-9ff0-484d-998b-51582cc919dd@github.com>

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24066#pullrequestreview-2687035378

From john.r.rose at oracle.com  Sun Mar 16 01:02:06 2025
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 15 Mar 2025 18:02:06 -0700
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <wdEnV4teKEFB1neo5b2ezxAHU6EWt7HnR8VbL-MrQ4U=.177f9759-9e07-4c50-a02f-b2dec3611c0b@github.com>
 <4B5XTEOv_30znhklVd9ymC0F4bmdn1bpYR-fYwtpvtY=.f0a2f7d9-0345-4893-a3f1-8559496b3c56@github.com>
Message-ID: <48649453-7926-4353-8AD7-A62EFD5AAF84@oracle.com>

> Are deeper cycles of concern? I was thinking of this:

There are a couple of ways existing java.util code handles
self-cycles.  The deepToString method handles them at all
levels, so it is robust.  But it is tricky and expensive.
(Look at the variable named ?dejaVu?.)

If you grep for /"(this / in the java.util sources, you
will see several examples of a one-level exclusion of
self-references.  This is what the present PR emulates,
and I think it is just fine to follow those precedents.
It?s a 99% solution.  Omitting the self-check would be
a 90% solution, but the self-check is so simple that,
why not do it?  Adding a ?dejaVu? table is not simple;
don?t.

One thing I noticed, when doing that grep, is that
the type name is usually ?detuned?.  We should do that
as well in this patch.  For example, in Hashtable.java,
the string says ?(this Map)? not ?(this Hashtable)?.
The toString method tilts away from TMI. I think we
have a slight TMI problem in this patch, maybe, and
given the precedents I would expect ?(this Function)?
not ?(this StableEnumFunction)?, etc.

(TMI = Too Much Information.  See also Gafter on
the TMI temptation for language designers, which
applies to API design as well:
https://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html )

I see the PR?s unit tests look at this string.  My
humble take on it is, let?s dial back the TMI before
it?s too late.

(My sensitivity to TMI also informs other comments I
made on this PR.)

From john.r.rose at oracle.com  Sun Mar 16 03:19:38 2025
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 15 Mar 2025 20:19:38 -0700
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
In-Reply-To: <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <otK6b_uGnVsTxoLSVN45iwygrmpJ5i4mr25flsID-DM=.44c8b572-9151-4f74-a2a6-f26709bb049a@github.com>
 <RglCt7Q_3HDUJGQ9ene7hES8w37rfKd-FXlOPTEN0UQ=.be5d7b61-f2d8-4818-909f-6ff218bfcd20@github.com>
Message-ID: <93E21D00-2C99-4278-A6BB-0578F32295F8@oracle.com>

On 13 Mar 2025, at 4:20, Per Minborg wrote:

> ?
>> Reentrancy into here seems really buggy, I would endorse disallowing it >> instead. In that case, a `ReentrantLock` seems better than the native monitor as we can cheaply check `lock.isHeldByCurrentThread()`
>
> StableValueImpl was carefully designed to minimize memory footprint. Adding a lock would inflate memory usage substantially.

+1 from me

A similar level of concern with footprint was in my mind in my
earlier comment, where I claimed that capturing /this/ in a lambda
is suboptimal.  The inefficiency is in object creation and footprint,
since an extra copy of /this/ must be tracked.

>
>> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 159:
>>
>>> 157:     private boolean wrapAndCas(Object value) {
>>> 158:         // This upholds the invariant, a `@Stable` field is written to at most once
>>> 159:         return UNSAFE.compareAndSetReference(this, UNDERLYING_DATA_OFFSET, null, wrap(value));
>>
>> There is no need for a cas here as all setters have to hold the lock. We should have a dedicated private `set` that asserts `Thread.holdsLock(this)`.
>
> This is more of a belt and suspenders solution. It is true that it is redundant. A set volatile would suffice here.

There is a broad choice at the beginning of this design whether
to use a mutex (as <clinit> and ClassValue do) or use lock-free
CAS (as condy/indy do).  This API, which is more parallel to
the higher-level <clinit> and ClassValue, uses a mutex.

The choice connects to the rules about handling races.  Surely,
two threads can ask concurrently for a SV state, and both may
?suggest? a lambda to give it a value.  Now we come to a fork
in the road:  Do we select at most one lambda to run?  Or,
do we let both lambdas run and then pick a winner?  The first
requires a mutex.  The second is lock-free and uses CAS.

It?s a binary choice.  I don?t think we ever need the belt
and suspenders.  I agree that StableValue is like ClassValue
and not like condy, so it should not be playing with lock
free stuff.  (Or did I forget something??)

? John

From john.r.rose at oracle.com  Sun Mar 16 03:29:28 2025
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 15 Mar 2025 20:29:28 -0700
Subject: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
In-Reply-To: <a7bMFVUZX0bRNKG2fdBG0jE1utnwWWOt7k0ijZkMMyI=.f63c0067-7985-4a25-b3a7-7a372b1eafea@github.com>
References: <M9dcBiMNX0jKoBdEZ3qiyTeWA3kC4xOP2_V_1yDUI8E=.9e708885-86b3-41d1-8bea-943afc23705e@github.com>
 <Vv-FnSveBWnqfUAXvtH391vNKa5zh1KpfFStY4o30Qk=.756bedac-9a3b-4ae0-9b25-d8ec1ee8eb2c@github.com>
 <a7bMFVUZX0bRNKG2fdBG0jE1utnwWWOt7k0ijZkMMyI=.f63c0067-7985-4a25-b3a7-7a372b1eafea@github.com>
Message-ID: <2AEBD2FF-0816-418A-B8A9-C936D942F4D3@oracle.com>

A @Stable field does not need to be volatile.
Avoiding volatile is one of the uses for @Stable.

That said, @Stable is not as foolproof as volatile.
It?s more dangerous, and cheaper.

You have to do a release store to a stable variable.

That?s what the VM does for you automatically for
a final, and a stable is like a delayed final.
But the VM does not give you the release store
automatically; you must do it manually.

That?s why @Stable is an internal feature, and
StableValue is the ?housebroken? version of it.
StableValue has to help the VM maintain the
appearance of a ?final? variable whose initialization
got delayed.  The wrapAndSet method does this job.

This might seem to contradict my previous assertion
that StableValue, being mutex based, must not
use lock-free idioms.  That comment applies
specifically to the update operation that takes
a lambda.  Other operations, such as reading
a SV, or hopefully poking a value at a SV can be,
and should be, composed of lock-free operations.
Why take a lock when it?s just a one-word read
or write?


On 13 Mar 2025, at 9:07, Maurizio Cimadamore wrote:

> On Thu, 13 Mar 2025 15:22:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:
>
>>> Implement JEP 502.
>>>
>>> The PR passes tier1-tier3 tests.
>>
>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 246 commits:
>>
>>  - Merge branch 'master' into implement-jep502
>>  - Clean up exception messages and fix comments
>>  - Rename field
>>  - Rename method and fix comment
>>  - Rework reenterant logic
>>  - Use acquire semantics for reading rather than volatile semantics
>>  - Add missing null check
>>  - Simplify handling of sentinel, wrap, and unwrap
>>  - Fix JavaDoc issues
>>  - Fix members in StableEnumFunction
>>  - ... and 236 more: https://git.openjdk.org/jdk/compare/4e51a8c9...d6e1573f
>
> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java line 74:
>
>> 72:     @Override
>> 73:     public boolean trySet(T value) {
>> 74:         if (wrappedContentAcquire() != null) {
>
> IMHO, if our goal is to do:
>
> Object content = this.content;
> if (context != null) return content:
> synchronized (...) {
>     if (context != null) return content:
>     this.context = ...
> }
>
>
> Then we might just use a volatile field and synchronized blocks. I don't see an immediate need for using acquire/release semantics --
> especially when using a monitor. E.g. this should look more like a classic double checked locking idiom. (but with a stable field to make the first volatile read more efficient in case the field is already set)
>
> -------------
>
> PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r1993850760

From duke at openjdk.org  Sun Mar 16 23:48:52 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sun, 16 Mar 2025 23:48:52 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
References: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
Message-ID: <TK9E6Sz1_IzYAfNK2umY7aI1K-bvQEzNWfwff3NmfvU=.6b2799f5-c986-4b19-9509-8d459d1585aa@github.com>

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/24066#pullrequestreview-2688864196

From djelinski at openjdk.org  Mon Mar 17 07:27:02 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 17 Mar 2025 07:27:02 GMT
Subject: RFR: 8351970: Retire JavaLangAccess::exit
In-Reply-To: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
References: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
Message-ID: <6t_-npUpIttqDOGTqd-xrvkwQ-Miygw6MKqt-t-qAWg=.7672b684-e053-4c93-9e66-0f38be74d5de@github.com>

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24066#pullrequestreview-2689360580

From duke at openjdk.org  Mon Mar 17 11:38:04 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 17 Mar 2025 11:38:04 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v6]
In-Reply-To: <di5vo1Muk6wtMW-lE-vuZ-Ii9njvH4EYEEO5kQwaKBA=.56e974af-8b57-46fc-aecb-e27834d6bf3f@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <CY_w5CM4ZSozDcR8YQp8Bz_kCvv4g57pJlYTnuLma3w=.47f64d0e-2dd3-4785-aed0-254d93b61689@github.com>
 <di5vo1Muk6wtMW-lE-vuZ-Ii9njvH4EYEEO5kQwaKBA=.56e974af-8b57-46fc-aecb-e27834d6bf3f@github.com>
Message-ID: <soiPMM3YGMBbup5mexy2xJOF4oXRT0JCDhNUfPrWZJc=.b4d2d937-b3de-4a39-bd28-81a615730a44@github.com>

On Wed, 12 Mar 2025 15:34:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added validity test for the intrinsics.
>
> test/jdk/sun/security/provider/acvp/Launcher.java line 43:
> 
>> 41:  * @modules java.base/sun.security.provider
>> 42:  * @run main Launcher
>> 43:  * @run main/othervm -Xcomp Launcher
> 
> Thank you for adding this case. Please add it as a separate testcase:
> /*
>  * @test 
>  * @summary Test verifies intrinsic implementation. 
>  * @library /test/lib
>  * @modules java.base/sun.security.provider
>  * @run main/othervm -Xcomp Launcher
>  */

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1998545085

From mdonovan at openjdk.org  Mon Mar 17 12:01:57 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 17 Mar 2025 12:01:57 GMT
Subject: Integrated: 8350964: Add an ArtifactResolver.fetch(clazz) method
In-Reply-To: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
References: <U8IoJWXKAqq6TK7ftKwG3t41lsSdBFIHMP3KGN9otHY=.e0b9b42c-be0d-48bf-9fa3-08991a8a35aa@github.com>
Message-ID: <DFvsgEqjvAslS22s2chvU5DsrPzw5nnMhxC6xply0hU=.ffbf5c30-5770-45fc-b36e-2ed8c8d77ad1@github.com>

On Tue, 11 Mar 2025 15:21:09 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I created a new method, `ArtifactResolver.fetchOne()`, to consolidate duplicate code across tests.

This pull request has now been integrated.

Changeset: e62becc6
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e62becc6ce8e1b777c3e5b78a9d9406b6389cd25
Stats:     130 lines in 6 files changed: 44 ins; 69 del; 17 mod

8350964: Add an ArtifactResolver.fetch(clazz) method

Reviewed-by: weijun

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

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

From lmesnik at openjdk.org  Mon Mar 17 16:10:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 17 Mar 2025 16:10:25 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v7]
In-Reply-To: <xeGVcNvhb8JogSwnBjlAln9bAiZMAeiOEC5XrH0FVX0=.564addcd-ee9a-4628-8df1-b546e7de45be@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xeGVcNvhb8JogSwnBjlAln9bAiZMAeiOEC5XrH0FVX0=.564addcd-ee9a-4628-8df1-b546e7de45be@github.com>
Message-ID: <yaCzXUM8N4ScCDBFU9nmQbM4tIP4xAHwiieOq6ZqjoQ=.54da08bb-7f9a-4faa-9df5-bb66e01e4c5c@github.com>

On Wed, 12 Mar 2025 19:19:08 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made the intrinsics test separate from the pure java test.

Test changes looks good.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2691165965

From rriggs at openjdk.org  Mon Mar 17 18:58:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Mar 2025 18:58:12 GMT
Subject: Integrated: 8351970: Retire JavaLangAccess::exit
In-Reply-To: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
References: <DJHfwW7WO2rh_Vcg1QAZlWIo5TnWn2IKp9JcakryfyQ=.ed80a4d7-477a-47dc-985a-d16410db6019@github.com>
Message-ID: <UlORfKoDWTW7VtMYAdxZzaKQTYLt9ib00uge7nHOUEY=.ab7d751e-b2bd-4694-b542-db6457637779@github.com>

On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary; System.exit() can be called directly.

This pull request has now been integrated.

Changeset: 19154f7a
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19154f7af34bf6f13d61d7a9f05d6277964845d8
Stats:     13 lines in 3 files changed: 0 ins; 12 del; 1 mod

8351970: Retire JavaLangAccess::exit

Reviewed-by: rgiulietti, liach, djelinski

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

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

From duke at openjdk.org  Mon Mar 17 18:59:23 2025
From: duke at openjdk.org (Tim Jacomb)
Date: Mon, 17 Mar 2025 18:59:23 GMT
Subject: RFR: 8347067: Load certificates without explicit trust settings in
 KeyChainStore [v3]
In-Reply-To: <8SJZ0QrFr96h2O1ia4NU_P_jemAGqbItcGctoFCWdGs=.f1f50560-4f6a-4127-b0cf-ea5c743fe794@github.com>
References: <f-f5Omr-1j5X91hy0NYr9lTInI8KbY-vAhR-kF4d6VI=.aeb77e3c-0c59-4426-9166-b9c00f58d7a3@github.com>
 <LnlIpT00znaivHjJ7ay-6G6tbjy60Sf8Qf3bcFMQt_s=.69990892-8aa3-41db-b3f4-62a22cb96a1c@github.com>
 <8SJZ0QrFr96h2O1ia4NU_P_jemAGqbItcGctoFCWdGs=.f1f50560-4f6a-4127-b0cf-ea5c743fe794@github.com>
Message-ID: <FB37Gy025doS9Yf1vihRh_cEkZTI4VC9Wxs1sNELGmQ=.f3e93d05-1768-4f50-a025-c00777adf725@github.com>

On Mon, 27 Jan 2025 13:06:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Tim Jacomb has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert unneeded change
>
> This change is significant and should be reviewed by at least 2 Reviewers.

Hi @seanjmullan can you recommend anyone else for review please?

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

PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2730540517

From mdonovan at openjdk.org  Mon Mar 17 19:12:12 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 17 Mar 2025 19:12:12 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v2]
In-Reply-To: <XIEwj4lNiDE5AykPybPEl-_Mp_ZiyZzKi0qqFrFff1c=.4184f3d6-10d5-4e17-8946-880ddf0e5871@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 <XIEwj4lNiDE5AykPybPEl-_Mp_ZiyZzKi0qqFrFff1c=.4184f3d6-10d5-4e17-8946-880ddf0e5871@github.com>
Message-ID: <f3EiKmAtjwbZ-NDekBiNmKG6oYQIUhubY1F6vzs0uVA=.898c3f73-afe2-41dd-bc89-2f7d07f625f2@github.com>

On Thu, 6 Mar 2025 12:28:19 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

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

Looks good to me!

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

PR Comment: https://git.openjdk.org/jdk/pull/23898#issuecomment-2730570376

From vpaprotski at openjdk.org  Mon Mar 17 21:49:12 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Mar 2025 21:49:12 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v7]
In-Reply-To: <xeGVcNvhb8JogSwnBjlAln9bAiZMAeiOEC5XrH0FVX0=.564addcd-ee9a-4628-8df1-b546e7de45be@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xeGVcNvhb8JogSwnBjlAln9bAiZMAeiOEC5XrH0FVX0=.564addcd-ee9a-4628-8df1-b546e7de45be@github.com>
Message-ID: <kBg6GrgsVt_pKZ2MfKEHbuEb9Uk5YFWWQ7tKUOKySH4=.106187c8-0bb4-4463-afd7-a406fce15fc4@github.com>

On Wed, 12 Mar 2025 19:19:08 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made the intrinsics test separate from the pure java test.

Partial review, just didnt want to sit on comments for this long.

(Spent quite a bit of time catching up on papers and math required)

The biggest roadblock I have following the code are raw register numbers. (And more comments? perhaps I need more math knowledge, but comments would help too). 

Also, 'hidden variables' (xmm30). Can't complain, because this is exactly what Vladimir Ivanov told me to do on my first PR https://github.com/openjdk/jdk/pull/10582#discussion_r1022185591 Perhaps that discussion applies here too.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 45:

> 43: // Constants
> 44: //
> 45: ATTRIBUTE_ALIGNED(64) static const uint32_t dilithiumAvx512Consts[] = {

This is really nitpicking.. but could had loaded constants inline with `movl` without requiring an ExternalAddress()? 

Nice to have constants together, only complaint is we have 'magic offsets' in ASM to reach in for particular one..

This one isnt too bad, offset of 32bits is easy to inspect visually (`dilithiumAvx512ConstsAddr()` could take a parameter perhaps)

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 58:

> 56: 
> 57: ATTRIBUTE_ALIGNED(64) static const uint32_t dilithiumAvx512Perms[] = {
> 58:      // collect montmul results into the destination register

same as `dilithiumAvx512Consts()`, 'magic offsets'; except here they are harder to count (eg. not clear visually what is the offset of `ntt inverse`).

Could be split into three constant arrays to make the compiler count for us

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 127:

> 125:   for (int i = 0; i < parCnt; i++) {
> 126:     __ evpsubd(xmm(i + outputReg), k0, xmm(i + scratchReg1), xmm(i + scratchReg2), false, Assembler::AVX_512bit);
> 127:   }

This is such a deceptively brilliant function!!! Took me a while to understand (and map to Java `montMul` function). Perhaps needs more comments.

The comment on line 99 does provide good hints, but I still had some trouble. I ended up annotating a copy quite a bit. I do think all 'clever code' needs comments. Here is my annotated version, if you want to copy out anything:

static void montmulEven2(XMMRegister outputReg, XMMRegister inputReg1,  XMMRegister inputReg2, XMMRegister scratchReg1, 
    XMMRegister scratchReg2, XMMRegister montQInvModR, XMMRegister dilithium_q, int parCnt, MacroAssembler* _masm) {
  
  int output = outputReg->encoding();
  int input1 = inputReg1->encoding();
  int input2 = inputReg2->encoding();
  int scratch1 = scratchReg1->encoding();
  int scratch2 = scratchReg2->encoding();
  for (int i = 0; i < parCnt; i++) {
    // scratch1 = (int64)input1_even*input2_even
    //    Java: long a = (long) b * (long) c;
    __ vpmuldq(xmm(i + scratch1), xmm(i + input1), xmm((input2 == 29) ? 29 : input2 + i), Assembler::AVX_512bit);
  }
  for (int i = 0; i < parCnt; i++) {
    // scratch2 = int32(montQInvModR*(int32)scratch1)
    //    Java: int aLow = (int) a;
    //    Java: int m = MONT_Q_INV_MOD_R * aLow; // signed low product
    __ vpmulld(xmm(i + scratch2), xmm(i + scratch1), montQInvModR, Assembler::AVX_512bit);
  }
  for (int i = 0; i < parCnt; i++) {
    // scratch2 = (int64)scratch2_even*dilithium_q_even
    //    Java: ((long)m * MONT_Q)
    __ vpmuldq(xmm(i + scratch2), xmm(i + scratch2), dilithium_q, Assembler::AVX_512bit);
  }
  for (int i = 0; i < parCnt; i++) {
    // output_odd = scratch1_odd - scratch2_odd
    //    Java: (aHigh - (int) (("scratch2") >> MONT_R_BITS))
    __ evpsubd(xmm(i + output), k0, xmm(i + scratch1), xmm(i + scratch2), false, Assembler::AVX_512bit);
  }
}


- add comment that input2 can be xmm29, treated as constants, not consecutive (i.e. zetas)
- Candidate for ascii art, even/odd columns, implicit int/long casts (or more 'math' comments on what happens)
- use XMMRegisters instead of numbers (improve callsite readability)
  - can use either `inputReg1 = inputReg1->successor()` 
  - or get `encoding()` and keep current style
- could be static (local) function (hide from header), then pass _masm
- pass all registers used (helps seeing register allocation, confirm no overlaps)

False trails (i.e. nothing to do, but I thought about it already, so other reviewer doesnt have to?)
- (ignore: worse performance) squash into a single for loop, let cpu do out-of-order (and improve readability)
- xmm30/xmm31 (montQInvModR/dilithium_q) are constant. At a glance, it looks like they should be combined into one precomputed one. And paper 039.pdf suggests merging constants precompute the product; but.. different constants and looking at Java, there are several implicit casts

For reductions of products inside the NTT this is not a problem because one has to multiply by the roots of unity
which are compile-time constants. So one can just precompute them with an additional
factor of ? mod q so that the results after Montgomery reduction are in fact congruent to the desired value a

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 140:

> 138:   __ vpmuldq(xmm(scratchReg1 + 1), xmm(inputReg12), xmm(inputReg2 + 1), Assembler::AVX_512bit);
> 139:   __ vpmuldq(xmm(scratchReg1 + 2), xmm(inputReg13), xmm(inputReg2 + 2), Assembler::AVX_512bit);
> 140:   __ vpmuldq(xmm(scratchReg1 + 3), xmm(inputReg14), xmm(inputReg2 + 3), Assembler::AVX_512bit);

Another option for these four lines, to keep the style of rest of function

int inputReg1[] = {inputReg11, inputReg12, inputReg13, inputReg14};
  for (int i = 0; i < parCnt; i++) {
    __ vpmuldq(xmm(scratchReg1 + i), inputReg1[i], xmm(inputReg2 + i), Assembler::AVX_512bit);
  }

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 197:

> 195: 
> 196:   // level 0
> 197:   montmulEven(20, 8, 29, 20, 16, 4);

It would improve readability to know which parameter is a register, and which is a count.. i.e. 

`montmulEven(xmm20, xmm8, xmm29, xmm20, xmm16, 4);`

(its not _that_ bad, once I remember that its always the last parameter.. but it does add to the 'mental load' one has to carry, and this code is already interesting enough)

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 980:

> 978: // Dilithium multiply polynomials in the NTT domain.
> 979: // Implements
> 980: // static int implDilithiumNttMult(

I suppose no java changes in this PR, but I notice that the inputs are all assumed to have fixed size.

Most/all intrinsics I worked with had some sort of guard (eg `Objects.checkFromIndexSize`) right before the intrinsic java call. (It usually looks like it can be optimized away). But I notice no such guard here on the java side.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1010:

> 1008:   __ vpbroadcastd(xmm31, Address(dilithiumConsts, 4), Assembler::AVX_512bit); // q
> 1009:   __ vpbroadcastd(xmm29, Address(dilithiumConsts, 12), Assembler::AVX_512bit); // 2^64 mod q
> 1010:   __ evmovdqul(xmm28, Address(perms, 0), Assembler::AVX_512bit);

- use of `c_rarg3` is 'clever' so probably should have a comment (ie. 'no 3rd parameter, free register')
- Alternatively, load directly into the vector with `ExternalAddress()`; you need a scratch register (use r10) but address is close enough, it actually wont be used. Here is the disassembly I got:

StubRoutines::dilithiumNttMult [0x00007f414fb68280, 0x00007f414fb68548] (712 bytes)
--------------------------------------------------------------------------------
add    %al,(%rax)
  0x00007f414fb68280:   push   %rbp
  0x00007f414fb68281:   mov    %rsp,%rbp
  0x00007f414fb68284:   vpbroadcastd 0x18f9fe32(%rip),%zmm30        # 0x00007f4168b080c0
  0x00007f414fb6828e:   vpbroadcastd 0x18f9fe2c(%rip),%zmm31        # 0x00007f4168b080c4
  0x00007f414fb68298:   vpbroadcastd 0x18f9fe2a(%rip),%zmm29        # 0x00007f4168b080cc
  0x00007f414fb682a2:   vmovdqu32 0x18f9f8d4(%rip),%zmm28        # 0x00007f4168b07b80
  ```
  
The `ExternalAddress()` calls for above assembler
  ```
  const Register scratch = r10;
  const XMMRegister montRSquareModQ = xmm29;
  const XMMRegister montQInvModR = xmm30;
  const XMMRegister dilithium_q = xmm31;
  const XMMRegister perms = xmm28;

  __ vpbroadcastd(montQInvModR, ExternalAddress(dilithiumAvx512ConstsAddr()), Assembler::AVX_512bit, scratch); // q^-1 mod 2^32
  __ vpbroadcastd(dilithium_q, ExternalAddress(dilithiumAvx512ConstsAddr() + 4), Assembler::AVX_512bit, scratch); // q
  __ vpbroadcastd(montRSquareModQ, ExternalAddress(dilithiumAvx512ConstsAddr() + 12), Assembler::AVX_512bit, scratch); // 2^64 mod q
  __ evmovdqul(perms, k0, ExternalAddress(dilithiumAvx512PermsAddr()), false, Assembler::AVX_512bit, scratch);

(and `dilithiumAvx512ConstsAddr(offset)` cound take an int parameter too)

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1012:

> 1010:   __ evmovdqul(xmm28, Address(perms, 0), Assembler::AVX_512bit);
> 1011: 
> 1012:   __ movl(len, 4);

Compile-time constant, why not 'unroll at compile time'? i.e. wrap this loop with `for (int len=0; len<4; len++)` instead?

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1041:

> 1039:   for (int i = 0; i < 4; i++) {
> 1040:     __ evmovdqul(Address(result, i * 64), xmm(i), Assembler::AVX_512bit);
> 1041:   }

This is nice, compact and clean. The biggest issue I have with following this code is really with all the 'raw' registers. I would much rather prefer symbolic names, but up to you to decide style.

I ended up 'annotating' this snippet, so I could understand it and confirm everything..  as with montmulEven, hope some of it can be useful to you to copy out.


  XMMRegister POLY1[] = {xmm0, xmm1, xmm2, xmm3};
  XMMRegister POLY2[] = {xmm4, xmm5, xmm6, xmm7};
  XMMRegister SCRATCH1[] = {xmm12, xmm13, xmm14, xmm15};
  XMMRegister SCRATCH2[] = {xmm16, xmm17, xmm18, xmm19};
  XMMRegister SCRATCH3[] = {xmm8, xmm9, xmm10, xmm11};
  for (int i = 0; i < 4; i++) {
    __ evmovdqul(POLY1[i], Address(poly1, i * 64), Assembler::AVX_512bit);
    __ evmovdqul(POLY2[i], Address(poly2, i * 64), Assembler::AVX_512bit);
  }

  // montmulEven: inputs are in even columns and output is in odd columns
  // scratch3_even = poly2_even*montRSquareModQ // poly2 to montgomery domain
  montmulEven2(SCRATCH3[0], POLY2[0], montRSquareModQ, SCRATCH1[0], SCRATCH2[0], montQInvModR, dilithium_q, 4, _masm);
  for (int i = 0; i < 4; i++) {
    // swap even/odd; 0xB1 == 2-3-0-1
    __ vpshufd(SCRATCH3[i], SCRATCH3[i], 0xB1, Assembler::AVX_512bit);
  }

  // scratch3_odd = poly1_even*scratch3_even = poly1_even*poly2_even*montRSquareModQ
  montmulEven2(SCRATCH3[0], POLY1[0], SCRATCH3[0], SCRATCH1[0], SCRATCH2[0], 4, montQInvModR, dilithium_q, 4, _masm);
  for (int i = 0; i < 4; i++) {
    __ vpshufd(POLY1[i], POLY1[i], 0xB1, Assembler::AVX_512bit);
    __ vpshufd(POLY2[i], POLY2[i], 0xB1, Assembler::AVX_512bit);
  }

  // poly2_even = poly2_odd*montRSquareModQ // poly2 to montgomery domain
  montmulEven2(POLY2[0], POLY2[0], montRSquareModQ, SCRATCH1[0], SCRATCH2[0], 4, montQInvModR, dilithium_q, 4, _masm);
  for (int i = 0; i < 4; i++) {
    __ vpshufd(POLY2[i], POLY2[i], 0xB1, Assembler::AVX_512bit);
  }

  // poly1_odd = poly1_even*poly2_even
  montmulEven2(POLY1[0], POLY1[0], POLY2[0], SCRATCH1[0], SCRATCH2[0], 4, montQInvModR, dilithium_q, 4, _masm);
  for (int i = 0; i < 4; i++) {
    // result is scrambled between scratch3_odd and poly1_odd; unscramble
    __ evpermt2d(POLY1[i], perms, SCRATCH3[i], Assembler::AVX_512bit);
  }
  for (int i = 0; i < 4; i++) {
    __ evmovdqul(Address(result, i * 64), POLY1[i], Assembler::AVX_512bit);
  }


With symbolic variable names, code was much easier to follow conceptually. Also has the side benefit of making it obvious which XMM registers are used and that there is no conflicts

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1090:

> 1088:   __ evpbroadcastd(xmm29, constant, Assembler::AVX_512bit); // constant multiplier
> 1089: 
> 1090:   __ movl(len, 2);

Same comment here as the `generate_dilithiumNttMult_avx512`
- constants can be loaded directly into XMM
- len can be removed by unrolling at compile time
- symbolic names could be used for registers
- comments could be added

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

PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2665370975
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1999468929
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1999471763
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1999625933
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1992230295
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1992235625
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1999712200
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1999413007
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1999367607
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1999683384
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1999686631

From vpaprotski at openjdk.org  Mon Mar 17 21:49:14 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Mar 2025 21:49:14 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v5]
In-Reply-To: <3bphXKLpIpxAZP-FEOeob6AaHbv0BAoEceJka64vMW8=.3e4f74e0-9479-4926-b365-b08d8d702692@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <3bphXKLpIpxAZP-FEOeob6AaHbv0BAoEceJka64vMW8=.3e4f74e0-9479-4926-b365-b08d8d702692@github.com>
Message-ID: <uUNg9Inwc5sySYy-v52dgYVTSxNU0n7EQZdsjQESTsY=.b9bfb2ab-42ef-40fc-9173-6a141adfac38@github.com>

On Thu, 6 Mar 2025 17:37:33 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accepted review comments.

src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 494:

> 492:   address generate_sha3_implCompress(StubGenStubId stub_id);
> 493: 
> 494:   address generate_double_keccak();

you can hide internal helper functions (i.e. `montmulEven(*)`) if you wish. 

The trick is to add `MacroAssembler* _masm` as a parameter to the static (local) function. Its a trick I use to keep header clean, but still have plenty of helpers

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 409:

> 407:   __ evmovdquq(xmm29, Address(permsAndRots, 768), Assembler::AVX_512bit);
> 408:   __ evmovdquq(xmm30, Address(permsAndRots, 832), Assembler::AVX_512bit);
> 409:   __ evmovdquq(xmm31, Address(permsAndRots, 896), Assembler::AVX_512bit);

Matter of taste, but I liked the compactness of montmulEven; i.e. 

for (i=0; i<15; i++)
    __ evmovdquq(xmm(17+i), Address(permsAndRots, 64*i), Assembler::AVX_512bit);

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 426:

> 424:   __ subl( roundsLeft, 1);
> 425: 
> 426:   __ evmovdquw(xmm5, xmm0, Assembler::AVX_512bit);

Is there a pattern here; that can be 'compacted' into a loop?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1983903347
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1983935964
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r1983937154

From vpaprotski at openjdk.org  Mon Mar 17 22:27:08 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Mar 2025 22:27:08 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v5]
In-Reply-To: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
Message-ID: <uzF_-xRzxl5BNOncRul3GnhrhcWtF44BUexuXNEPLxA=.bb2b91e3-d1ab-4504-9406-cfa5a6dfc7db@github.com>

> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
> 
> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
> 
> Before (no AVX512)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
> 
> After (with AVX2)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
> 
> 
> Before (with AVX512):
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        102...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  improve test comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23719/files
  - new: https://git.openjdk.org/jdk/pull/23719/files/9d13cefa..72650cd3

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

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

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

From vpaprotski at openjdk.org  Mon Mar 17 22:32:01 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Mar 2025 22:32:01 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v6]
In-Reply-To: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
Message-ID: <r7WUB2uvSmQaYFwDNfQZhJGsTWPVTXJ3IBrE9JsLmys=.c6fcf4aa-2a89-47de-81e7-fdf61c263db8@github.com>

> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
> 
> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
> 
> Before (no AVX512)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
> 
> After (with AVX2)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
> 
> 
> Before (with AVX512):
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        102...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23719/files
  - new: https://git.openjdk.org/jdk/pull/23719/files/72650cd3..56fd168d

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

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

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

From vpaprotski at openjdk.org  Mon Mar 17 22:32:02 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 17 Mar 2025 22:32:02 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <W26HBW3Wj-oke-vXimRbaWxBvn0cP66GQ1PRNrtnnzI=.cb058a5d-43cb-479e-9766-0202e7f98cfb@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
 <X7zT-DxVzyhXInXudD3F5OYXMwUGQQ1mUrEPNPqZCkY=.15e0bfcd-26e6-4c0b-90ac-67f632ed81ec@github.com>
 <W26HBW3Wj-oke-vXimRbaWxBvn0cP66GQ1PRNrtnnzI=.cb058a5d-43cb-479e-9766-0202e7f98cfb@github.com>
Message-ID: <wWzeLdBojh5oUmYBgVG1ytLH1thmVBdjo6B4bL58Urg=.8ea0cb91-a278-4680-8f00-1870ad31408f@github.com>

On Mon, 10 Mar 2025 23:07:45 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> test/jdk/com/sun/security/util/math/intpoly/MontgomeryPolynomialFuzzTest.java line 30:
>> 
>>> 28: import sun.security.util.math.intpoly.*;
>>> 29: 
>>> 30: /*
>> 
>> It is strange that there are two copies of the `@test` block.  Can you please remove one of them, unless you are seeing a difference that I do not
>
> -XX:+/-UseIntPolyIntrinsics (test Java vs BigInt and intrinsic vs BigInt)
> 
> Though I think I did this before I knew much about junit.. I think I can just have two @run commands (to make it clearer)? Will give that a try

Turns out I do need both `@test`; (otherwise `make test TEST=...MontgomeryPolynomialFuzzTest.java` runs fewer tests). Seems other tests do the same.

I did add a (better?) comment to the summary tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r1999760302

From hchao at openjdk.org  Tue Mar 18 00:47:33 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 18 Mar 2025 00:47:33 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v6]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <DDSRRPF-ymb9YSUjoA3i0ST3I0kDiLutTEvRqAO3LbY=.e0587e1a-54b6-4273-8e4b-e1906872d877@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Remove only if 1st entry is MANIFEST in cenEntries

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/867ba607..31dcf68c

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

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

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

From abarashev at openjdk.org  Tue Mar 18 02:24:11 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 18 Mar 2025 02:24:11 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v2]
In-Reply-To: <XIEwj4lNiDE5AykPybPEl-_Mp_ZiyZzKi0qqFrFff1c=.4184f3d6-10d5-4e17-8946-880ddf0e5871@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 <XIEwj4lNiDE5AykPybPEl-_Mp_ZiyZzKi0qqFrFff1c=.4184f3d6-10d5-4e17-8946-880ddf0e5871@github.com>
Message-ID: <9pjV-VEL8rD_lJsPzAoLxdcdD1O8-BXhkzSIBgCjA1c=.7ac98cd1-f191-4d4d-9ca7-d220553a9f87@github.com>

On Thu, 6 Mar 2025 12:28:19 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

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

test/jdk/sun/security/ssl/SSLSocketImpl/NonAutoClose.java line 135:

> 133:          */
> 134:         System.out.println("Waiting for server ready");
> 135:         if (!SERVER_READY.await(5, TimeUnit.SECONDS)) {

Please see my other comment about `await()`.

test/jdk/sun/security/ssl/SSLSocketImpl/SetClientMode.java line 100:

> 98:                 connectedSocket.getSession();
> 99: 
> 100:                 if (!HANDSHAKE_COMPLETE.await(5, TimeUnit.SECONDS)) {

The test will be more robust if we do a simple `await()` call here. On some busy systems even 5 seconds may not be enough. JTEG tests have a default timeout of 2 minutes, so it won't wait forever in any case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r2000018849
PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r2000014224

From abarashev at openjdk.org  Tue Mar 18 02:30:14 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 18 Mar 2025 02:30:14 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v2]
In-Reply-To: <XIEwj4lNiDE5AykPybPEl-_Mp_ZiyZzKi0qqFrFff1c=.4184f3d6-10d5-4e17-8946-880ddf0e5871@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 <XIEwj4lNiDE5AykPybPEl-_Mp_ZiyZzKi0qqFrFff1c=.4184f3d6-10d5-4e17-8946-880ddf0e5871@github.com>
Message-ID: <MsI7znMIO7IJyZnTMAaPVSL2avVda-d_mZPekpO18VE=.6314c8e2-4db0-45c6-8eb5-8dbdcd189a75@github.com>

On Thu, 6 Mar 2025 12:28:19 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

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

test/jdk/sun/security/ssl/SSLSocketImpl/NonAutoClose.java line 65:

> 63:      */
> 64:     private final static boolean DEBUG = Boolean.getBoolean("test.debug");
> 65:     private final static int NUM_ITERATIONS = 10;

Why do we do 10 iterations of the same test?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r2000023465

From myankelevich at openjdk.org  Tue Mar 18 12:08:02 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 18 Mar 2025 12:08:02 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests
Message-ID: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>

8351566: Consolidate third party artifacts used in tests

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

Commit messages:
 - merge, docks and changind to use fetchOne
 - merging master
 - merge conflict fix
 - changed method flow, made unused methods private
 - JDK-8351566: Consolidate third party artifacts used in tests

Changes: https://git.openjdk.org/jdk/pull/23988/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23988&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351566
  Stats: 375 lines in 5 files changed: 230 ins; 135 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23988/head:pull/23988

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

From myankelevich at openjdk.org  Tue Mar 18 12:08:03 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 18 Mar 2025 12:08:03 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests
In-Reply-To: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
References: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
Message-ID: <DfbLymnQYKqPQTmw8DTVMGQr0EuTMI3ZY9j__7sLi4M=.331948f2-b5df-4caf-b6f7-e3f28022d352@github.com>

On Tue, 11 Mar 2025 15:15:39 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> 8351566: Consolidate third party artifacts used in tests

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh line 31:

> 29: #        jdk.test.lib.Platform
> 30: #        jdk.test.lib.Utils
> 31: #        jdk.test.lib.security.artifacts.ThirdPartyArtifacts

Please ignore this, this is temporary to prevent an error. The file itself will be removed once another pr integrated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r1989639850

From myankelevich at openjdk.org  Tue Mar 18 12:08:06 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 18 Mar 2025 12:08:06 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests
In-Reply-To: <WK5NRw-w9CnTYX4XclL9qQXwIsF5j8tmqArGQtLLY6Y=.6e0cc51f-375d-456b-aa57-ae94712c9f45@github.com>
References: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
 <WK5NRw-w9CnTYX4XclL9qQXwIsF5j8tmqArGQtLLY6Y=.6e0cc51f-375d-456b-aa57-ae94712c9f45@github.com>
Message-ID: <-rH1PqXE7GWq-PGX8yA3yEOuAxLDMTl86s8BNRz9fcg=.48bc5976-6b72-4ed1-bd80-8c21148fa8db@github.com>

On Thu, 13 Mar 2025 14:07:58 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> 8351566: Consolidate third party artifacts used in tests
>
> test/lib/jdk/test/lib/security/NSSArtifactFetcher.java line 69:
> 
>> 67:     }
>> 68: 
>> 69:     public static String getNSSLibDir(String library) throws Exception {
> 
> You have a `getNSSLibDir()` method and one called `getNSSDirectory()`.  Please add Javadocs to explain what's what.

done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2000895685

From mdonovan at openjdk.org  Tue Mar 18 12:08:05 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 18 Mar 2025 12:08:05 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests
In-Reply-To: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
References: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
Message-ID: <WK5NRw-w9CnTYX4XclL9qQXwIsF5j8tmqArGQtLLY6Y=.6e0cc51f-375d-456b-aa57-ae94712c9f45@github.com>

On Tue, 11 Mar 2025 15:15:39 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> 8351566: Consolidate third party artifacts used in tests

test/lib/jdk/test/lib/security/NSSArtifactFetcher.java line 44:

> 42:         final Class<?> nssLibClass = getNssLibClass(osId);
> 43:         if(nssLibClass == null){
> 44:             throw new RuntimeException("Platform not recognised"); // should never happen

instead of "not recognized" maybe "not supported"

test/lib/jdk/test/lib/security/NSSArtifactFetcher.java line 69:

> 67:     }
> 68: 
> 69:     public static String getNSSLibDir(String library) throws Exception {

You have a `getNSSLibDir()` method and one called `getNSSDirectory()`.  Please add Javadocs to explain what's what.

test/lib/jdk/test/lib/security/NSSArtifactFetcher.java line 99:

> 97:     }
> 98: 
> 99:     public static String getOsId() {

does this method and the one that returns the @Artifact class need to be public?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r1991282723
PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r1993610802
PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r1991298843

From rriggs at openjdk.org  Tue Mar 18 13:52:09 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 18 Mar 2025 13:52:09 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests
In-Reply-To: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
References: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
Message-ID: <KvlGPbY4D_rJ1S1C2mFtudDw5P0KhMKwcVqOdz3NbDM=.d42469b9-6d68-4917-a20f-45e45f9f43f8@github.com>

On Tue, 11 Mar 2025 15:15:39 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> 8351566: Consolidate third party artifacts used in tests

test/jdk/sun/security/pkcs11/PKCS11Test.java line 45:

> 43: import java.security.spec.ECGenParameterSpec;
> 44: import java.security.spec.ECParameterSpec;
> 45: import java.util.*;

Wildcard imports are discouraged, please correct your IDE settings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2001096047

From myankelevich at openjdk.org  Tue Mar 18 14:11:26 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 18 Mar 2025 14:11:26 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests [v2]
In-Reply-To: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
References: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
Message-ID: <mO3aM1uy62-Fql_tsQBrfhW0L3qQo17GsRWCWsCnX_g=.b3a44e18-9cee-4c36-85cc-0ff84427fe56@github.com>

> 8351566: Consolidate third party artifacts used in tests

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

  minor: imports fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23988/files
  - new: https://git.openjdk.org/jdk/pull/23988/files/6bcc7e25..46e62cb6

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

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

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

From myankelevich at openjdk.org  Tue Mar 18 14:11:26 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 18 Mar 2025 14:11:26 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests [v2]
In-Reply-To: <KvlGPbY4D_rJ1S1C2mFtudDw5P0KhMKwcVqOdz3NbDM=.d42469b9-6d68-4917-a20f-45e45f9f43f8@github.com>
References: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
 <KvlGPbY4D_rJ1S1C2mFtudDw5P0KhMKwcVqOdz3NbDM=.d42469b9-6d68-4917-a20f-45e45f9f43f8@github.com>
Message-ID: <AOtVod_DJemJQh4IjZIQPFvaOp2MfnwRI_riHfMG308=.b91ee0f3-573f-4cbb-9e58-de4b6642e439@github.com>

On Tue, 18 Mar 2025 13:49:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor: imports fix
>
> test/jdk/sun/security/pkcs11/PKCS11Test.java line 45:
> 
>> 43: import java.security.spec.ECGenParameterSpec;
>> 44: import java.security.spec.ECParameterSpec;
>> 45: import java.util.*;
> 
> Wildcard imports are discouraged, please correct your IDE settings.

fFxed in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2001139782

From mdonovan at openjdk.org  Tue Mar 18 14:58:51 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 18 Mar 2025 14:58:51 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v3]
In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
Message-ID: <NfKVswsgmqoFm08V5OCTIlVEU34w1UgP5jyzAexDekA=.54ff82f5-dd56-4f86-abf6-325fab333724@github.com>

> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
> 
> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - reversed order of DN strings when making certificates.
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - changed boolean array initialization
 - 8325766: Review seclibs tests for cert expiry

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

Changes: https://git.openjdk.org/jdk/pull/23700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=02
  Stats: 777 lines in 3 files changed: 153 ins; 598 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/23700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23700/head:pull/23700

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

From mdonovan at openjdk.org  Tue Mar 18 15:02:12 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 18 Mar 2025 15:02:12 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v2]
In-Reply-To: <s1lLXnmaouGnr4GYtyKeCGdohlv78PaE_dZdfBkET2M=.d5e0dfed-b4c3-44fe-8d74-7b17fd9aa4c6@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <NMuqjZGTGdMkShUeBjzE0iQK1XilT-KQudeup_ucr94=.1513b076-2d93-46ec-b3de-c6b2c2118a74@github.com>
 <8FUIE2gpo0-n_UiPM1qbt9CHN9l8ZkraqlwHk9EGz4U=.aaf454e8-d97c-4aa2-bc7d-70647cac6c0b@github.com>
 <s1lLXnmaouGnr4GYtyKeCGdohlv78PaE_dZdfBkET2M=.d5e0dfed-b4c3-44fe-8d74-7b17fd9aa4c6@github.com>
Message-ID: <Bo_uu6GNyMw3PsYVYqvr2pporlPZY1-NadJoNNakcbc=.d68b3b9f-9d2e-4269-92a9-e788739e8b12@github.com>

On Fri, 21 Feb 2025 13:47:59 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> The similarity between the certificate pairs is impressive! Just curious - why the change in issuer and owner names?

After looking into this some more, I found that `X500Name(String dname)` is expecting the string to be in the same order as RFC 1779, 2253, or 4514. If you give the constructor a "backwards" string, it will store and print it backwards.

OpenSSL prints them backwards and I was using OpenSSL to print the hard-coded certificates and then just copying and pasting the strings. 

I changed the hard-coded DN strings to follow the RFC order.

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

PR Comment: https://git.openjdk.org/jdk/pull/23700#issuecomment-2733572650

From jnimeh at openjdk.org  Tue Mar 18 17:07:26 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 18 Mar 2025 17:07:26 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v12]
In-Reply-To: <F50v4De5vyjBga2epwVOXSiO_fXhUbtzAkE3ZUcNe7Q=.2bee851c-12f6-4208-a2b2-59a756be9c39@github.com>
References: <pzQ-OBSQL7n5SbuQwbh6ouivfEKRbfL3pkHN6u1AGZU=.2863ee52-93dc-4530-b4dd-438a88f9699a@github.com>
 <F50v4De5vyjBga2epwVOXSiO_fXhUbtzAkE3ZUcNe7Q=.2bee851c-12f6-4208-a2b2-59a756be9c39@github.com>
Message-ID: <6rZyx-jI2LBg072eM-gPsbmDwfPzWqbQiAl8rsSAFqo=.aa125765-7cb6-484d-9222-dc3b0287e050@github.com>

On Thu, 12 Dec 2024 19:59:05 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi all,
>> 
>> I need a code review of the PEM API.  Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates.  It will be integrated into JDK24 as a Preview Feature.  Preview features does not permanently define the API and it is subject to change in future releases until it is finalized.
>> 
>> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits:
> 
>  - Merge branch 'pem-merge' into pem
>  - merge
>  - Merge in PEMRecord as part of the API.
>  - Merge branch 'pem-record' into pem-merge
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/security/PEMDecoder.java
>    #	src/java.base/share/classes/java/security/PEMRecord.java
>    #	src/java.base/share/classes/sun/security/util/Pem.java
>    #	test/jdk/java/security/PEM/PEMData.java
>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>  - Merge branch 'master' into pem-record
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - test fixes & cleanup
>  - Implement stream decoding
>    fix StringBuffer/Builder
>    X509C* changes
>  - Reorg tests data
>    minor fixes
>  - merge from pem branch
>  - Merge branch 'pem' into pem-record
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/security/PEMEncoder.java
>    #	src/java.base/share/classes/sun/security/provider/X509Factory.java
>    #	src/java.base/share/classes/sun/security/util/Pem.java
>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>  - ... and 48 more: https://git.openjdk.org/jdk/compare/22845a77...cc952c0b

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

> 56:  * </pre>
> 57:  *
> 58:  * A specified return class must extend {@link DEREncodable} and be an

nit: extend -> implement

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

> 79:  *
> 80:  * @apiNote
> 81:  * Here is an example of encoding a PrivateKey object:

Nit: encoding -> decoding

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

> 141:                 case Pem.PRIVATE_KEY -> {
> 142:                     PKCS8Key p8key = new PKCS8Key(decoder.decode(pem.pem()));
> 143:                     KeyFactory kf = getKeyFactory(p8key.getAlgorithm());

nit: I see a lot of `p8key.getAlgorithm()` calls in here.  If it's always going to be the same value, perhaps it could be assigned to a String and just reuse it throughout (though it may not be usable for the `p8.getAlgorithm()` calls further down).

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

> 292: 
> 293:         if (tClass.isAssignableFrom(PEMRecord.class)) {
> 294:         //if (PEMRecord.class.isInstance(tClass)) {

nit: dead code?

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

> 46:  * All values can never be null.
> 47:  *
> 48:  * During the instantiation of this record, there is no validation for the

These two sentences are redundant.  Either one is fine to keep though.

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

> 51:  * instantiation of this record.
> 52:  *
> 53:  * @param type The type identifier in the PEM header.  For a public key,

Since there are specific strings that will be needed in the `type` field, is there a pointer we could add so folks looking at this could see what values might be acceptable for this field.  I don't know if right here is the right place for it, but maybe a see-also or something?  Or is this left open-ended to support whatever could exist in a PEM header?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1992070595
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1992074350
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1992118727
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1992132131
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1992257185
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r1992263251

From jnimeh at openjdk.org  Tue Mar 18 17:07:29 2025
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 18 Mar 2025 17:07:29 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v13]
In-Reply-To: <08wmiSxvUmzEN6Xl0DRsYkf-AvWnCHjzcMuLaDL54ZY=.e33d468b-56a2-463f-b466-0aac792b4e92@github.com>
References: <pzQ-OBSQL7n5SbuQwbh6ouivfEKRbfL3pkHN6u1AGZU=.2863ee52-93dc-4530-b4dd-438a88f9699a@github.com>
 <08wmiSxvUmzEN6Xl0DRsYkf-AvWnCHjzcMuLaDL54ZY=.e33d468b-56a2-463f-b466-0aac792b4e92@github.com>
Message-ID: <JTvgUKRPazDXSbsRnKhvFAta4P8Hy4_dEId9U3lnM-0=.e227fbe5-570c-4024-953e-0abc97209de0@github.com>

On Thu, 13 Mar 2025 01:15:03 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi all,
>> 
>> I need a code review of the PEM API.  Privacy-Enhanced Mail (PEM) is a format for encoding and decoding cryptographic keys and certificates.  It will be integrated into JDK24 as a Preview Feature.  Preview features does not permanently define the API and it is subject to change in future releases until it is finalized.
>> 
>> Details about this change can be seen at [PEM API JEP](https://bugs.openjdk.org/browse/JDK-8300911).
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - merge with master
>  - better comment and remove commented out code
>  - Merge branch 'master' into pem
>  - Merge branch 'pem-merge' into pem
>  - merge
>  - Merge in PEMRecord as part of the API.
>  - Merge branch 'pem-record' into pem-merge
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/security/PEMDecoder.java
>    #	src/java.base/share/classes/java/security/PEMRecord.java
>    #	src/java.base/share/classes/sun/security/util/Pem.java
>    #	test/jdk/java/security/PEM/PEMData.java
>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>  - Merge branch 'master' into pem-record
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - test fixes & cleanup
>  - Implement stream decoding
>    fix StringBuffer/Builder
>    X509C* changes
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/a347ecde...106788ef

src/java.base/share/classes/sun/security/ec/ECKeyFactory.java line 232:

> 230:         } else if (keySpec instanceof PKCS8EncodedKeySpec p8) {
> 231:             PKCS8Key p8key = new ECPrivateKeyImpl(p8.getEncoded());
> 232:             if (p8key.hasPublicKey()) {

Shouldn't that be `if (!p8key.hasPublicKey()) {`, similar to XDHKeyFactory.generatePublicImpl() and others?

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

> 53:  *        ...
> 54:  *      }
> 55:  * <p>

Actually this is for the next line, and just a nit: It appears that now we are at least parsing/saving the attributes and definitely attaching the public key when decoding from DER.  Should this line be removed?

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

> 205:             byte[] internal = rawKey.generateEncoding();
> 206:             PKCS8EncodedKeySpec pkcs8KeySpec =
> 207:                 new PKCS8EncodedKeySpec(internal);

Since you don't use `internal` beyond this point AFAICT, you may not need the reference as a local variable and just inline the call to `rawKey.generateEncoding()`.  But this is more of a nit/style thing so no big deal if you want to leave it as-is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2001457211
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2001501575
PR Review Comment: https://git.openjdk.org/jdk/pull/17543#discussion_r2001518767

From abarashev at openjdk.org  Tue Mar 18 19:17:12 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 18 Mar 2025 19:17:12 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v5]
In-Reply-To: <_6CxG2DQbtkrtH7oVDI30xwt4_zsJdIMALsjdvPRBM4=.dc1fe2a4-ddba-4d83-9570-b1055e4d251c@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <_6CxG2DQbtkrtH7oVDI30xwt4_zsJdIMALsjdvPRBM4=.dc1fe2a4-ddba-4d83-9570-b1055e4d251c@github.com>
Message-ID: <9ae5-lWvHoGhiN3Z_hjsa4npeO9oBjTfUmzAQKJWhEo=.c00dbbcc-e57d-493d-aa8f-22934d98a867@github.com>

On Tue, 11 Mar 2025 16:49:49 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check for dup

src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 210:

> 208:                     new CertPathConstraintsParameters(trustedPubKey, variant,
> 209:                         anchor, date);
> 210:                 dac.permits(KeyUtil.getAlgorithm(trustedPubKey),

Do you plan to have a unit test for `AlgorithmChecker` changes? It looks like certificates using `ED25519` algorithm didn't match that check before. It would be useful to have a test where disable `ED25519` in java.security and then try to use a certificate with `ED25519` algorithm.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2001818398

From abarashev at openjdk.org  Tue Mar 18 19:29:11 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 18 Mar 2025 19:29:11 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v5]
In-Reply-To: <_6CxG2DQbtkrtH7oVDI30xwt4_zsJdIMALsjdvPRBM4=.dc1fe2a4-ddba-4d83-9570-b1055e4d251c@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <_6CxG2DQbtkrtH7oVDI30xwt4_zsJdIMALsjdvPRBM4=.dc1fe2a4-ddba-4d83-9570-b1055e4d251c@github.com>
Message-ID: <rJPmLXiD3ys6BOsFBXUb0r9UiAOYmZS1jSWfFuh2Fbc=.f18e2fcd-ea82-43f2-8c0a-2a7841dee584@github.com>

On Tue, 11 Mar 2025 16:49:49 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check for dup

test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 138:

> 136:             System.out.print("\tpermits(Set.of(CryptoPrimitive.SIGNATURE), \"" +
> 137:                 tc.testAlgo + "\", null): " +
> 138:                 (r = dac.permits(Set.of(CryptoPrimitive.SIGNATURE),

I find this construct hard to read. I suggest we do `boolean r = dac.permits(Set.of(CryptoPrimitive.SIGNATURE), tc.testAlgo, null)` above and just use `r` in the `print` statement.

test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 162:

> 160:             System.out.print("\tpermits(Set.of(CryptoPrimitive.SIGNATURE), " +
> 161:                 tc.testAlgo + " privkey): " +
> 162:                 (r = dac.permits(Set.of(CryptoPrimitive.SIGNATURE), k)) +

Same as above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2001844217
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2001844627

From fferrari at openjdk.org  Tue Mar 18 23:38:08 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 18 Mar 2025 23:38:08 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings
In-Reply-To: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
Message-ID: <fq4159DVTAlqvt68sc1oQm835p7CCXymdhSSqTfwDzQ=.38bc3de8-89f6-4adf-988c-d288ba66f6de@github.com>

On Fri, 14 Mar 2025 21:58:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings.
> 
> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility.

Hi @valeriepeng, I found code assuming `com.sun.crypto.provider.PBEKey` contains only ASCII, please find my suggestions in the review comments. I also added a suggestion for the tests, in order to increase the coverage in that regard.

All the patches are verified to cleanly apply on top of this PR branch, when copied through the GitHub's copy button and applied with `xclip -sel clip | git apply`.

src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 70:

> 68:             passwd = new char[0];
> 69:         }
> 70:         this.key = PBKDF2KeyImpl.getPasswordBytes(passwd);

This change requires a counterpart in `sun.security.util.PBEUtil`, where the encoded `byte[]` from `com.sun.crypto.provider.PBEKey` is converted back to `char[]`:


diff --git a/src/java.base/share/classes/sun/security/util/PBEUtil.java b/src/java.base/share/classes/sun/security/util/PBEUtil.java
index 12e71418bf4..996bc0059f8 100644
--- a/src/java.base/share/classes/sun/security/util/PBEUtil.java
+++ b/src/java.base/share/classes/sun/security/util/PBEUtil.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2023, Red Hat, Inc.
+ * Copyright (c) 2023, 2025, Red Hat, Inc.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,6 +25,9 @@
 
 package sun.security.util;
 
+import java.nio.ByteBuffer;
+import java.nio.CharBuffer;
+import java.nio.charset.StandardCharsets;
 import java.security.AlgorithmParameters;
 import java.security.InvalidAlgorithmParameterException;
 import java.security.InvalidKeyException;
@@ -195,10 +198,7 @@ public PBEKeySpec getPBEKeySpec(int blkSize, int keyLength, int opmode,
                 }
                 initialize(blkSize, opmode, iCountInit, saltInit, ivSpecInit,
                         random);
-                passwdChars = new char[passwdBytes.length];
-                for (int i = 0; i < passwdChars.length; i++) {
-                    passwdChars[i] = (char) (passwdBytes[i] & 0x7f);
-                }
+                passwdChars = decodePassword(passwdBytes);
                 return new PBEKeySpec(passwdChars, salt, iCount, keyLength);
             } finally {
                 // password char[] was cloned in PBEKeySpec constructor,
@@ -247,6 +247,19 @@ private static int check(int iCount)
         }
     }
 
+    /*
+     * Inverse of com.sun.crypto.provider.PBKDF2KeyImpl.getPasswordBytes
+     */
+    private static char[] decodePassword(byte[] passwdBytes) {
+        CharBuffer cb =
+                StandardCharsets.UTF_8.decode(ByteBuffer.wrap(passwdBytes));
+        int len = cb.limit();
+        char[] passwd = new char[len];
+        cb.get(passwd);
+        cb.clear().put(new char[len]);
+        return passwd;
+    }
+
     /*
      * Obtain a PBEKeySpec for Mac services, after key and parameters
      * validation. Used by HmacPKCS12PBECore (SunJCE) and P11Mac (SunPKCS11).
@@ -267,10 +280,7 @@ public static PBEKeySpec getPBAKeySpec(Key key,
                     (passwdBytes = key.getEncoded()) == null) {
                 throw new InvalidKeyException("Missing password");
             }
-            passwdChars = new char[passwdBytes.length];
-            for (int i = 0; i < passwdChars.length; i++) {
-                passwdChars[i] = (char) (passwdBytes[i] & 0x7f);
-            }
+            passwdChars = decodePassword(passwdBytes);
             Arrays.fill(passwdBytes, (byte)0x00);
         } else {
             throw new InvalidKeyException("SecretKey of PBE type required");

test/jdk/sun/security/pkcs11/Cipher/PBECipher.java line 1:

> 1: /*

I suggest changing this test's password to contain non-ASCII characters, so we have a better coverage in both _SunJCE_ (when checking the assertion data) and _SunPKCS11_ (when doing the actual test):

diff --git a/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java b/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
index b12cb5c2687..93ef097933f 100644
--- a/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
+++ b/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2023, Red Hat, Inc.
+ * Copyright (c) 2023, 2025, Red Hat, Inc.
  *
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
@@ -47,7 +47,7 @@
  */
 
 public final class PBECipher extends PKCS11Test {
-    private static final char[] password = "123456".toCharArray();
+    private static final char[] password = "123456\uA4F7".toCharArray();
     private static final byte[] salt = "abcdefgh".getBytes(
             StandardCharsets.UTF_8);
     private static final int iterations = 1000;
@@ -112,35 +112,35 @@ private static void checkAssertionValues(BigInteger expectedValue,
     // Generated with SunJCE.
     private static final AssertionData[] assertionData = new AssertionData[]{
             cipherAssertionData("PBEWithHmacSHA1AndAES_128",
-                    "AES/CBC/PKCS5Padding", "ba1c9614d550912925d99e0bc8969032" +
-                    "7ac6258b72117dcf750c19ee6ca73dd4"),
+                    "AES/CBC/PKCS5Padding", "9e097796e8d8224f2a7f5c950677d879" +
+                    "c0c578340147c7ae357550e2f4d4c6ce"),
             cipherAssertionData("PBEWithHmacSHA224AndAES_128",
-                    "AES/CBC/PKCS5Padding", "41960c43ca99cf2184511aaf2f0508a9" +
-                    "7da3762ee6c2b7e2027c8076811f2e52"),
+                    "AES/CBC/PKCS5Padding", "7b915941d8e3a87c00e2fbd8ad67a578" +
+                    "9a25648933b737706de4e4d48bdb61b6"),
             cipherAssertionData("PBEWithHmacSHA256AndAES_128",
-                    "AES/CBC/PKCS5Padding", "6bb6a3dc3834e81e5ca6b5e70073ff46" +
-                    "903b188940a269ed26db2ffe622b8e16"),
+                    "AES/CBC/PKCS5Padding", "c23912d15599908f47cc32c9da56b37f" +
+                    "e41e958e9c3a6c6e4e631a2a9e6cd20f"),
             cipherAssertionData("PBEWithHmacSHA384AndAES_128",
-                    "AES/CBC/PKCS5Padding", "22aabf7a6a059415dc4ca7d985f3de06" +
-                    "8f8300ca48d8de585d802670f4c1d9bd"),
+                    "AES/CBC/PKCS5Padding", "f05c6b2dea545d59f2a6fde845170dd6" +
+                    "7aebd6b1cc28904699d7dcff1a0a238c"),
             cipherAssertionData("PBEWithHmacSHA512AndAES_128",
-                    "AES/CBC/PKCS5Padding", "b523e7c462a0b7fd74e492b3a6550464" +
-                    "ceebe81f08649ae163673afc242ad8a2"),
+                    "AES/CBC/PKCS5Padding", "949c0c01a29375b9d421f6e2bf6ed0d7" +
+                    "15a118e0980494797d3a3b799b67daf6"),
             cipherAssertionData("PBEWithHmacSHA1AndAES_256",
-                    "AES/CBC/PKCS5Padding", "1e7c25e166afae069cec68ef9affca61" +
-                    "aea02ab1c3dc7471cb767ed7d6e37af0"),
+                    "AES/CBC/PKCS5Padding", "7bd686b15bc09e5fb5aa1f881c92aa5a" +
+                    "e72bdcd864c74e62395b9aaea7443bcd"),
             cipherAssertionData("PBEWithHmacSHA224AndAES_256",
-                    "AES/CBC/PKCS5Padding", "6701f1cc75b6494ec4bd27158aa2c15d" +
-                    "7d10bc2f1fbb7d92d8277c7edfd1dd57"),
+                    "AES/CBC/PKCS5Padding", "df58a1b26cca7e9e297da61ada03ddc4" +
+                    "39d2a5699753433f19891de33f8741a2"),
             cipherAssertionData("PBEWithHmacSHA256AndAES_256",
-                    "AES/CBC/PKCS5Padding", "f82eb2fc016505baeb23ecdf85163933" +
-                    "5e8d6d48b48631185641febb75898a1d"),
+                    "AES/CBC/PKCS5Padding", "f6ae5a15ec2c18eaa25927858f1da990" +
+                    "6df58a3b4830dbaaaa4c4317e53d717d"),
             cipherAssertionData("PBEWithHmacSHA384AndAES_256",
-                    "AES/CBC/PKCS5Padding", "ee9528022e58cdd9be80cd88443e03b3" +
-                    "de13376cf97c53d946d5c5dfc88097be"),
+                    "AES/CBC/PKCS5Padding", "5795625f51ec701594506944e5ed79f0" +
+                    "c9d8e82319762f00f8ff06a8b6195ac4"),
             cipherAssertionData("PBEWithHmacSHA512AndAES_256",
-                    "AES/CBC/PKCS5Padding", "18f472912ffaa31824e20a5486324e14" +
-                    "0225e20cb158762e8647b1216fe0ab7e"),
+                    "AES/CBC/PKCS5Padding", "ddf55933f80f42f2a8d4e8726290766e" +
+                    "024f225b76b594e8005c00227d553d05"),
     };
 
     private static final class NoRandom extends SecureRandom {
 



When we do this, it reveals that this test also needs adjusting the anonymous `PBEKey` encoding, to do UTF-8 encoding as `com.sun.crypto.provider.PBEKey`. Instead of duplicating the logic from `com.sun.crypto.provider.PBKDF2KeyImpl.getPasswordBytes()`, we can just use `com.sun.crypto.provider.PBEKey.getEncoded()`:

diff --git a/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java b/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
index 147fd9a65f5..b12cb5c2687 100644
--- a/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
+++ b/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
@@ -214,23 +214,16 @@ private static SecretKey getPasswordOnlyPBEKey()
     }
 
     private static SecretKey getAnonymousPBEKey(String algorithm,
-            boolean isPbeCipherSvc) {
+            boolean isPbeCipherSvc) throws GeneralSecurityException {
+        byte[] encodedKey =
+                isPbeCipherSvc ? getPasswordOnlyPBEKey().getEncoded() : null;
         return new PBEKey() {
             public byte[] getSalt() { return salt.clone(); }
             public int getIterationCount() { return iterations; }
             public String getAlgorithm() { return algorithm; }
             public String getFormat() { return "RAW"; }
             public char[] getPassword() { return password.clone(); }
-            public byte[] getEncoded() {
-                byte[] encodedKey = null;
-                if (isPbeCipherSvc) {
-                    encodedKey = new byte[password.length];
-                    for (int i = 0; i < password.length; i++) {
-                        encodedKey[i] = (byte) (password[i] & 0x7f);
-                    }
-                }
-                return encodedKey;
-            }
+            public byte[] getEncoded() { return encodedKey; }
         };
     }

test/jdk/sun/security/pkcs11/Mac/PBAMac.java line 1:

> 1: /*

I suggest changing this test's password to contain non-ASCII characters, so we have a better coverage in both _SunJCE_ (when checking the assertion data) and _SunPKCS11_ (when doing the actual test):

diff --git a/test/jdk/sun/security/pkcs11/Mac/PBAMac.java b/test/jdk/sun/security/pkcs11/Mac/PBAMac.java
index b70a0a6d618..0baf85bb5de 100644
--- a/test/jdk/sun/security/pkcs11/Mac/PBAMac.java
+++ b/test/jdk/sun/security/pkcs11/Mac/PBAMac.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2023, Red Hat, Inc.
+ * Copyright (c) 2023, 2025, Red Hat, Inc.
  *
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
@@ -44,7 +44,7 @@
  */
 
 public final class PBAMac extends PKCS11Test {
-    private static final char[] password = "123456".toCharArray();
+    private static final char[] password = "123456\uA4F7".toCharArray();
     private static final byte[] salt = "abcdefgh".getBytes(
             StandardCharsets.UTF_8);
     private static final int iterations = 1000;
@@ -102,19 +102,19 @@ private static void checkAssertionValues(BigInteger expectedValue,
     // Generated with SunJCE.
     private static final AssertionData[] assertionData = new AssertionData[]{
             macAssertionData("HmacPBESHA1", "HmacSHA1",
-                    "707606929395e4297adc63d520ac7d22f3f5fa66"),
+                    "8611414ddb1875d9f576282199ab492a802b7d49"),
             macAssertionData("HmacPBESHA224", "HmacSHA224",
-                    "4ffb5ad4974a7a9fca5a36ebe3e34dd443c07fb68c392f8b611657e6"),
+                    "cebb12b48eb90c07336c695f771d1d0ef4ccf5b9524fc0ab6fb9813a"),
             macAssertionData("HmacPBESHA256", "HmacSHA256",
-                    "9e8c102c212d2fd1334dc497acb4e002b04e84713b7eda5a63807af2" +
-                    "989d3e50"),
+                    "d83a6a4e8b0e1ec939d05790f385dd774bd2b7c17cfa2dd004efc894" +
+                    "e5d53f51"),
             macAssertionData("HmacPBESHA384", "HmacSHA384",
-                    "77f31a785d4f2220251143a4ba80f5610d9d0aeaebb4a278b8a7535c" +
-                    "8cea8e8211809ba450458e351c5b66d691839c23"),
+                    "ae6b69cf9edfd9cd8c3b51cdf2b0243502f35a3e6007f33b1ab73568" +
+                    "2ea81ea562f4383bb9512ff70752367b7259b16f"),
             macAssertionData("HmacPBESHA512", "HmacSHA512",
-                    "a53f942a844b234a69c1f92cba20ef272c4394a3cf4024dc16d9dbac" +
-                    "1969870b1c2b28b897149a1a3b9ad80a7ca8c547dfabf3ed5f144c6b" +
-                    "593900b62e120c45"),
+                    "46f6d09b0e7e50a66fa559ea4c4e9737a9d9e258b94f0075230d0acb" +
+                    "40f2c926f96a152c4f6b03b631efc7f99c84f052f1c78d79e07f2a9e" +
+                    "4a96164f5b46e70b"),
     };
 
     public void main(Provider sunPKCS11) throws Exception {

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

Changes requested by fferrari (Author).

PR Review: https://git.openjdk.org/jdk/pull/24068#pullrequestreview-2696475636
PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2002127839
PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2002148875
PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2002152377

From weijun at openjdk.org  Wed Mar 19 02:01:34 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 19 Mar 2025 02:01:34 GMT
Subject: RFR: 8352302: Test sun/security/tools/jarsigner/TimestampCheck.java is
 failing
Message-ID: <uTxyrTl4KGa1OyBfnxNAtBJY6uD_cinOrLMTbwAQFD8=.1309a3d3-9217-4a59-8e84-52442008cf28@github.com>

A certificate created in the test will expire on 2026-03-20. This change adds another 2000 days to it.

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

Commit messages:
 - the fix

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

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

From dholmes at openjdk.org  Wed Mar 19 02:01:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Mar 2025 02:01:34 GMT
Subject: RFR: 8352302: Test
 sun/security/tools/jarsigner/TimestampCheck.java is failing
In-Reply-To: <uTxyrTl4KGa1OyBfnxNAtBJY6uD_cinOrLMTbwAQFD8=.1309a3d3-9217-4a59-8e84-52442008cf28@github.com>
References: <uTxyrTl4KGa1OyBfnxNAtBJY6uD_cinOrLMTbwAQFD8=.1309a3d3-9217-4a59-8e84-52442008cf28@github.com>
Message-ID: <3rkfFbWgoS8mHNO_DLOz__ybBm6XeDoxmq770Db-3M0=.994bd313-e8c0-4e14-8678-3e69d3ae860d@github.com>

On Wed, 19 Mar 2025 01:54:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A certificate created in the test will expire on 2026-03-20. This change adds another 2000 days to it.

To future-proof this couldn't we set the expiration date based on the current date minus X days?

I meant the start date sorry

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

PR Comment: https://git.openjdk.org/jdk/pull/24107#issuecomment-2735128661
PR Comment: https://git.openjdk.org/jdk/pull/24107#issuecomment-2735129459

From dholmes at openjdk.org  Wed Mar 19 02:13:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Mar 2025 02:13:06 GMT
Subject: RFR: 8352302: Test
 sun/security/tools/jarsigner/TimestampCheck.java is failing
In-Reply-To: <uTxyrTl4KGa1OyBfnxNAtBJY6uD_cinOrLMTbwAQFD8=.1309a3d3-9217-4a59-8e84-52442008cf28@github.com>
References: <uTxyrTl4KGa1OyBfnxNAtBJY6uD_cinOrLMTbwAQFD8=.1309a3d3-9217-4a59-8e84-52442008cf28@github.com>
Message-ID: <_MIQP350rLyN1riB7bVMIn5leo8lRIFX5kc9wYrhWW4=.f203fdc0-a97c-4d09-9a96-d44380a483a6@github.com>

On Wed, 19 Mar 2025 01:54:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A certificate created in the test will expire on 2026-03-20. This change adds another 2000 days to it.

Okay lets fix this as-is for now. Making it future-proof would be nice as a future RFE.

Thanks for the quick fix.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24107#pullrequestreview-2696719131

From weijun at openjdk.org  Wed Mar 19 02:13:07 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 19 Mar 2025 02:13:07 GMT
Subject: RFR: 8352302: Test
 sun/security/tools/jarsigner/TimestampCheck.java is failing
In-Reply-To: <uTxyrTl4KGa1OyBfnxNAtBJY6uD_cinOrLMTbwAQFD8=.1309a3d3-9217-4a59-8e84-52442008cf28@github.com>
References: <uTxyrTl4KGa1OyBfnxNAtBJY6uD_cinOrLMTbwAQFD8=.1309a3d3-9217-4a59-8e84-52442008cf28@github.com>
Message-ID: <rGfa6FvHQRVXXUrgTtVM_k7vzb1E1xlLYV2Yjgg1-Kk=.acdd83a0-4cd7-4f5f-a1c1-eb7b5fd11054@github.com>

On Wed, 19 Mar 2025 01:54:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A certificate created in the test will expire on 2026-03-20. This change adds another 2000 days to it.

The start date probably cannot change, because we have a rule `SHA1 denyAfter 2019-01-01` in `java.security` that only denies SHA1 signatures since 2019. That said, we can calculate the days between 2018-01-01 and today next year. Is that worth doing? I just want to fix this ASAP.

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

PR Comment: https://git.openjdk.org/jdk/pull/24107#issuecomment-2735142343

From weijun at openjdk.org  Wed Mar 19 02:23:10 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 19 Mar 2025 02:23:10 GMT
Subject: Integrated: 8352302: Test
 sun/security/tools/jarsigner/TimestampCheck.java is failing
In-Reply-To: <uTxyrTl4KGa1OyBfnxNAtBJY6uD_cinOrLMTbwAQFD8=.1309a3d3-9217-4a59-8e84-52442008cf28@github.com>
References: <uTxyrTl4KGa1OyBfnxNAtBJY6uD_cinOrLMTbwAQFD8=.1309a3d3-9217-4a59-8e84-52442008cf28@github.com>
Message-ID: <b4yHVmNZYpxTT1r__JtpVaMGFfeY4ZsG_abFxOlLfdA=.db11716c-8a64-4f05-9769-806826a00200@github.com>

On Wed, 19 Mar 2025 01:54:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A certificate created in the test will expire on 2026-03-20. This change adds another 2000 days to it.

This pull request has now been integrated.

Changeset: 577ede73
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/577ede73d8e916bac9050d3bee80d2f18cc833a7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8352302: Test sun/security/tools/jarsigner/TimestampCheck.java is failing

Reviewed-by: dholmes

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

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

From hchao at openjdk.org  Wed Mar 19 03:23:17 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 19 Mar 2025 03:23:17 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v7]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <I2J7uFoTSSVFqlm5vUTcemb8VmHxi-yxDLgYRSrSKu8=.eefe8944-c193-4842-9464-5925105fa518@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Add testcase for entry name integrity check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/31dcf68c..5d93e4dc

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

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

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

From weijun at openjdk.org  Wed Mar 19 13:38:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 19 Mar 2025 13:38:09 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v7]
In-Reply-To: <I2J7uFoTSSVFqlm5vUTcemb8VmHxi-yxDLgYRSrSKu8=.eefe8944-c193-4842-9464-5925105fa518@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <I2J7uFoTSSVFqlm5vUTcemb8VmHxi-yxDLgYRSrSKu8=.eefe8944-c193-4842-9464-5925105fa518@github.com>
Message-ID: <Mx1yDSUfRcA5X0ziqlpOus8fQq-PzZDbyE3mzIkWugc=.0d1c05c8-a382-44f1-9279-0800ff38aed1@github.com>

On Wed, 19 Mar 2025 03:23:17 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add testcase for entry name integrity check

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

> 1145:             Manifest locManifest = jis.getManifest();
> 1146:             if (!compareManifest(cenManifest, locManifest)) {
> 1147:                 return;

Here and within `compareManifest`, there are multiple early returns. Have you considered avoiding early returns and accumulating more warnings instead?

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

> 1182:     }
> 1183: 
> 1184:     private void readEntry(InputStream is) throws IOException {

This can be rewritten as `is.transferTo(OutputStream.nullOutputStream())`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2003344786
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2003346301

From myankelevich at openjdk.org  Wed Mar 19 17:37:49 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 19 Mar 2025 17:37:49 GMT
Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java
 test [v5]
In-Reply-To: <xLs-5ELobHMgCFIm_lQMF_ax6c8EeyIpCS-HQPGCBVc=.47737b0f-9d47-4472-9777-7af5c6de76ff@github.com>
References: <xLs-5ELobHMgCFIm_lQMF_ax6c8EeyIpCS-HQPGCBVc=.47737b0f-9d47-4472-9777-7af5c6de76ff@github.com>
Message-ID: <5E5hBMuFtP8BdHuuO8QXemYhqAg8fuujvWvQPQH_GPs=.25daccc6-58a6-4071-8a4f-1aa9b0f7e03d@github.com>

> Moved the sh file logic to jtreg java test.

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

  added summary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23590/files
  - new: https://git.openjdk.org/jdk/pull/23590/files/3dbd4868..a8d017dd

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

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

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

From fferrari at openjdk.org  Wed Mar 19 17:42:12 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 19 Mar 2025 17:42:12 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings
In-Reply-To: <fq4159DVTAlqvt68sc1oQm835p7CCXymdhSSqTfwDzQ=.38bc3de8-89f6-4adf-988c-d288ba66f6de@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
 <fq4159DVTAlqvt68sc1oQm835p7CCXymdhSSqTfwDzQ=.38bc3de8-89f6-4adf-988c-d288ba66f6de@github.com>
Message-ID: <A8prcUa1EUnx-CaopUsPfnEhfa7u3x-WWY7h5C5UTz0=.d6f0b2d5-6d00-409b-ac7e-0dc68295af28@github.com>

On Tue, 18 Mar 2025 23:20:39 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings.
>> 
>> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility.
>
> test/jdk/sun/security/pkcs11/Mac/PBAMac.java line 1:
> 
>> 1: /*
> 
> I suggest changing this test's password to contain non-ASCII characters, so we have a better coverage in both _SunJCE_ (when checking the assertion data) and _SunPKCS11_ (when doing the actual test):
> 
> diff --git a/test/jdk/sun/security/pkcs11/Mac/PBAMac.java b/test/jdk/sun/security/pkcs11/Mac/PBAMac.java
> index b70a0a6d618..0baf85bb5de 100644
> --- a/test/jdk/sun/security/pkcs11/Mac/PBAMac.java
> +++ b/test/jdk/sun/security/pkcs11/Mac/PBAMac.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2023, Red Hat, Inc.
> + * Copyright (c) 2023, 2025, Red Hat, Inc.
>   *
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
> @@ -44,7 +44,7 @@
>   */
>  
>  public final class PBAMac extends PKCS11Test {
> -    private static final char[] password = "123456".toCharArray();
> +    private static final char[] password = "123456\uA4F7".toCharArray();
>      private static final byte[] salt = "abcdefgh".getBytes(
>              StandardCharsets.UTF_8);
>      private static final int iterations = 1000;
> @@ -102,19 +102,19 @@ private static void checkAssertionValues(BigInteger expectedValue,
>      // Generated with SunJCE.
>      private static final AssertionData[] assertionData = new AssertionData[]{
>              macAssertionData("HmacPBESHA1", "HmacSHA1",
> -                    "707606929395e4297adc63d520ac7d22f3f5fa66"),
> +                    "8611414ddb1875d9f576282199ab492a802b7d49"),
>              macAssertionData("HmacPBESHA224", "HmacSHA224",
> -                    "4ffb5ad4974a7a9fca5a36ebe3e34dd443c07fb68c392f8b611657e6"),
> +                    "cebb12b48eb90c07336c695f771d1d0ef4ccf5b9524fc0ab6fb9813a"),
>              macAssertionData("HmacPBESHA256", "HmacSHA256",
> -                    "9e8c102c212d2fd1334dc497acb4e002b04e84713b7eda5a63807af2" +
> -                    "989d3e50"),
> +                    "d83a6a4e8b0e1ec939d05790f385dd774bd2b7c17cfa2dd004efc894" +
> +                    "e5d53f51"),
>              macAssertionData("HmacPBESHA384", "HmacSHA384",
> -                    "77f31a785d4f2220251143a4ba80f5610d9d0aeaebb4a278b8a7535c" +
> -                    "8cea8e8211809ba450458e351c5b66d691839c23"),
> +                    "ae6b69cf9edfd9cd8c3b51cdf2b0243502f35a3e6007f33b1ab73568" +
> +                    "2ea81ea562f4383bb9512ff70752367b7259b16f"),
>              macAssertionData("HmacPBESHA512", "HmacSHA512",
> -                    "a53f942a844b234a69c1f92cba20ef272c4394a3cf4024dc16d9dbac" +
> -                    "1969870b1c2b28b897149a1a...

Even when the suggested `PBECipher` and `PBAMac` test changes would improve the confidence, validating _SunJCE_ against _SunPKCS11_ and viceversa is not a completely independent test, specially given both providers share some common code in `PBEUtil`. For this reason, I've just also did the following cross-check with OpenSSL:


# Non-ASCII password
password='Th1s is a Bullet: ?'

# Create a PKCS #12 keystore with a certificate and a key pair
openssl req -x509 -nodes -newkey rsa:4096 -subj /C=TT/ST=TT/L=TT/O=Test/CN=test.com/ -keyout key.pem -out cert.pem
openssl pkcs12 -export -inkey key.pem -in cert.pem -passout "pass:$password" -out ks.p12

# Read the keystore with keytool
build/*/images/jdk/bin/keytool -v -list -storetype pkcs12 -keystore ks.p12 -storepass "$password"

# Cleanup
unset password && rm -f key.pem cert.pem ks.p12


<details>
<summary><code>keytool</code> output from JDK 23:</summary>


keytool error: java.io.IOException: keystore password was incorrect
java.io.IOException: keystore password was incorrect
	at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2112)
	at java.base/sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:228)
	at java.base/java.security.KeyStore.load(KeyStore.java:1499)
	at java.base/sun.security.tools.keytool.Main.doCommands(Main.java:961)
	at java.base/sun.security.tools.keytool.Main.run(Main.java:429)
	at java.base/sun.security.tools.keytool.Main.main(Main.java:410)
Caused by: java.security.UnrecoverableKeyException: failed to decrypt safe contents entry: java.io.IOException: getSecretKey failed: Password is not ASCII
	... 6 more

</details>

<details>
<summary><code>keytool</code> output from a build of this PR's branch:</summary>


keytool error: java.io.IOException: keystore password was incorrect
java.io.IOException: keystore password was incorrect
	at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2109)
	at java.base/sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:226)
	at java.base/java.security.KeyStore.load(KeyStore.java:1502)
	at java.base/sun.security.tools.keytool.Main.doCommands(Main.java:951)
	at java.base/sun.security.tools.keytool.Main.run(Main.java:419)
	at java.base/sun.security.tools.keytool.Main.main(Main.java:400)
Caused by: java.security.UnrecoverableKeyException: failed to decrypt safe contents entry: javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
	... 6 more

</details>

<details>
<summary><code>keytool</code> output from a build of this PR's branch, including my previous <code>PBEUtil</code> suggestion:</summary>


Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: 1
Creation date: Mar 19, 2025
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=test.com, O=Test, L=TT, ST=TT, C=TT
Issuer: CN=test.com, O=Test, L=TT, ST=TT, C=TT
Serial number: 52dbdcf60a04c79cb1c2375502f0f8f026e65724
Valid from: Wed Mar 19 18:22:27 CET 2025 until: Fri Apr 18 19:22:27 CEST 2025
Certificate fingerprints:
	 SHA1: 4D:79:59:2D:92:F6:83:40:0B:29:38:B4:79:96:39:2D:43:04:8B:FB
	 SHA256: 4A:20:0E:94:D2:F0:5E:D8:A9:7F:D5:D3:C7:35:D4:DA:B0:BB:F4:14:E6:5D:E8:48:5E:87:99:A7:C5:F3:4A:FB
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions: 

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: AC E0 8F C9 E3 81 63 6B   4E F8 2B C1 35 41 AA CC  ......ckN.+.5A..
0010: 8C C8 DB 16                                        ....
]
]

#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen: no limit
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AC E0 8F C9 E3 81 63 6B   4E F8 2B C1 35 41 AA CC  ......ckN.+.5A..
0010: 8C C8 DB 16                                        ....
]
]



*******************************************
*******************************************

</details>

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2003907172

From myankelevich at openjdk.org  Wed Mar 19 18:08:40 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 19 Mar 2025 18:08:40 GMT
Subject: RFR: 8349535: Refactor ./pkcs11/Provider/MultipleLogins.sh to java
 test [v6]
In-Reply-To: <xLs-5ELobHMgCFIm_lQMF_ax6c8EeyIpCS-HQPGCBVc=.47737b0f-9d47-4472-9777-7af5c6de76ff@github.com>
References: <xLs-5ELobHMgCFIm_lQMF_ax6c8EeyIpCS-HQPGCBVc=.47737b0f-9d47-4472-9777-7af5c6de76ff@github.com>
Message-ID: <Ll3wbKj2GHtPJA49SxV2hIaIqW61wq6mNrsRNC0Z4ZY=.acadb986-0c31-413b-9d81-5505c3e11ed0@github.com>

> Moved the sh file logic to jtreg java test.

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

  minor: space at the end

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23590/files
  - new: https://git.openjdk.org/jdk/pull/23590/files/a8d017dd..88614200

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

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

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

From ascarpino at openjdk.org  Wed Mar 19 18:44:10 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 19 Mar 2025 18:44:10 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v18]
In-Reply-To: <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
Message-ID: <vt5cqMIBE3s6FKZzlSENKv4f6mjNbhA0wVjreveFmcQ=.8d1796ee-3561-4595-8aee-3f4d06298084@github.com>

On Wed, 12 Mar 2025 17:26:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix

src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 822:

> 820:                         }
> 821:                         this.scopes.add(scope);
> 822:                     }  else {

extra whitespace

test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 2:

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

Since this is a new file, it only needs 2025

test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 135:

> 133:         int type = Byte.toUnsignedInt(tlsRecord.get());
> 134:         int ver_major = Byte.toUnsignedInt(tlsRecord.get());
> 135:         int ver_minor = Byte.toUnsignedInt(tlsRecord.get());

These 3 variables appear to not be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r1999795413
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2001787345
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2002149066

From ascarpino at openjdk.org  Wed Mar 19 19:03:17 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 19 Mar 2025 19:03:17 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <wWzeLdBojh5oUmYBgVG1ytLH1thmVBdjo6B4bL58Urg=.8ea0cb91-a278-4680-8f00-1870ad31408f@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
 <X7zT-DxVzyhXInXudD3F5OYXMwUGQQ1mUrEPNPqZCkY=.15e0bfcd-26e6-4c0b-90ac-67f632ed81ec@github.com>
 <W26HBW3Wj-oke-vXimRbaWxBvn0cP66GQ1PRNrtnnzI=.cb058a5d-43cb-479e-9766-0202e7f98cfb@github.com>
 <wWzeLdBojh5oUmYBgVG1ytLH1thmVBdjo6B4bL58Urg=.8ea0cb91-a278-4680-8f00-1870ad31408f@github.com>
Message-ID: <CpTyxpgFSEDnA4HGHskFrFwR2Y-aNDVcXjHzUB8dMAQ=.dd0e40b3-b654-490d-bd3c-8785632dfb85@github.com>

On Mon, 17 Mar 2025 22:25:14 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> -XX:+/-UseIntPolyIntrinsics (test Java vs BigInt and intrinsic vs BigInt)
>> 
>> Though I think I did this before I knew much about junit.. I think I can just have two @run commands (to make it clearer)? Will give that a try
>
> Turns out I do need both `@test`; (otherwise `make test TEST=...MontgomeryPolynomialFuzzTest.java` runs fewer tests). Seems other tests do the same.
> 
> I did add a (better?) comment to the summary tag.

Oh.. I didn't notice the -/+. Thanks for adding the comment that helps explain it better

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2004049802

From ascarpino at openjdk.org  Wed Mar 19 19:03:18 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 19 Mar 2025 19:03:18 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <W26HBW3Wj-oke-vXimRbaWxBvn0cP66GQ1PRNrtnnzI=.cb058a5d-43cb-479e-9766-0202e7f98cfb@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
 <X7zT-DxVzyhXInXudD3F5OYXMwUGQQ1mUrEPNPqZCkY=.15e0bfcd-26e6-4c0b-90ac-67f632ed81ec@github.com>
 <W26HBW3Wj-oke-vXimRbaWxBvn0cP66GQ1PRNrtnnzI=.cb058a5d-43cb-479e-9766-0202e7f98cfb@github.com>
Message-ID: <PUMkpytKKZX84tzpJoB4zFLt4pZXtTI8cQoP8li_f2s=.2112b3f5-9f65-471c-a5df-cf916aab44aa@github.com>

On Mon, 10 Mar 2025 23:05:10 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> test/jdk/com/sun/security/util/math/intpoly/MontgomeryPolynomialFuzzTest.java line 123:
>> 
>>> 121:         }
>>> 122: 
>>> 123:         if (rnd.nextBoolean()) {
>> 
>> Why is this done randomly?  Wouldn't we want to check these situations every time?
>
> I was mostly attempting to test 'random paths' through the code, and this was a way to pseudo-randomly accomplish that. (i.e. a product of a difference, a product of a product.. and so on..)
> 
> Since this is looping, we got 50% chance of getting both, without me having to write/think-through all the many permutations of what input/outputs to each operations can be.
> 
> (Extend the loop count to run for several hours during development.. and it does wonders to testing corner cases. Have been following this 'template' in most my PRs)

Randomness isn't idea for reproducibility.  If a failure occurs, is it obvious what operations were done?  I don't see any stdout or stderr messages to know what operations happen to bring about a possible failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2004074368

From hchao at openjdk.org  Wed Mar 19 19:21:50 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 19 Mar 2025 19:21:50 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v8]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <yyDB3OpWZ61SW4vitIxZpEI62FfjYZqCJUKNI9iwS_c=.b5d5207c-05b1-4cf8-a724-c50d296cd548@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Update readEntry() and accumulate more warnings in compareManifest()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/5d93e4dc..ef546f4b

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

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

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

From hchao at openjdk.org  Wed Mar 19 19:25:09 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 19 Mar 2025 19:25:09 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v7]
In-Reply-To: <Mx1yDSUfRcA5X0ziqlpOus8fQq-PzZDbyE3mzIkWugc=.0d1c05c8-a382-44f1-9279-0800ff38aed1@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <I2J7uFoTSSVFqlm5vUTcemb8VmHxi-yxDLgYRSrSKu8=.eefe8944-c193-4842-9464-5925105fa518@github.com>
 <Mx1yDSUfRcA5X0ziqlpOus8fQq-PzZDbyE3mzIkWugc=.0d1c05c8-a382-44f1-9279-0800ff38aed1@github.com>
Message-ID: <k5mH67X2lXWBLzjBuHp5tnRMtjVpfAOvUMMHqaxEl_Q=.83434608-31cc-4790-9da4-6f04c08ddb2f@github.com>

On Wed, 19 Mar 2025 13:34:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add testcase for entry name integrity check
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1147:
> 
>> 1145:             Manifest locManifest = jis.getManifest();
>> 1146:             if (!compareManifest(cenManifest, locManifest)) {
>> 1147:                 return;
> 
> Here and within `compareManifest`, there are multiple early returns. Have you considered avoiding early returns and accumulating more warnings instead?

Good idea. Updated the code. Thanks.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1184:
> 
>> 1182:     }
>> 1183: 
>> 1184:     private void readEntry(InputStream is) throws IOException {
> 
> This can be rewritten as `is.transferTo(OutputStream.nullOutputStream())`.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2004125794
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2004126337

From abarashev at openjdk.org  Wed Mar 19 19:26:15 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 19 Mar 2025 19:26:15 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v18]
In-Reply-To: <vt5cqMIBE3s6FKZzlSENKv4f6mjNbhA0wVjreveFmcQ=.8d1796ee-3561-4595-8aee-3f4d06298084@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
 <vt5cqMIBE3s6FKZzlSENKv4f6mjNbhA0wVjreveFmcQ=.8d1796ee-3561-4595-8aee-3f4d06298084@github.com>
Message-ID: <wEgdv31nl551jx_ot0wFUKEyMlhCpbDg7olo2PMwQiU=.679cf5bb-1741-41b4-aa1d-f697948d6af3@github.com>

On Mon, 17 Mar 2025 22:58:20 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo fix
>
> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 822:
> 
>> 820:                         }
>> 821:                         this.scopes.add(scope);
>> 822:                     }  else {
> 
> extra whitespace

Please elaborate, I'm not quite sure what it means.

> test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Since this is a new file, it only needs 2025

Most of this file's content was copied from `SigSchemePropOrdering`, so we keep the original start year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2004125914
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2004130787

From abarashev at openjdk.org  Wed Mar 19 19:38:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 19 Mar 2025 19:38:08 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v18]
In-Reply-To: <wEgdv31nl551jx_ot0wFUKEyMlhCpbDg7olo2PMwQiU=.679cf5bb-1741-41b4-aa1d-f697948d6af3@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
 <vt5cqMIBE3s6FKZzlSENKv4f6mjNbhA0wVjreveFmcQ=.8d1796ee-3561-4595-8aee-3f4d06298084@github.com>
 <wEgdv31nl551jx_ot0wFUKEyMlhCpbDg7olo2PMwQiU=.679cf5bb-1741-41b4-aa1d-f697948d6af3@github.com>
Message-ID: <KUmI2WNGyOCgZzdokNwtUYPjW8t1JnmTWW6I9ZfIJmQ=.4f627fe2-7796-4c9e-8356-25fdc9571675@github.com>

On Wed, 19 Mar 2025 19:22:07 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 822:
>> 
>>> 820:                         }
>>> 821:                         this.scopes.add(scope);
>>> 822:                     }  else {
>> 
>> extra whitespace
>
> Please elaborate, I'm not quite sure what it means.

Nevermind, fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2004152445

From abarashev at openjdk.org  Wed Mar 19 19:38:09 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 19 Mar 2025 19:38:09 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v18]
In-Reply-To: <vt5cqMIBE3s6FKZzlSENKv4f6mjNbhA0wVjreveFmcQ=.8d1796ee-3561-4595-8aee-3f4d06298084@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
 <vt5cqMIBE3s6FKZzlSENKv4f6mjNbhA0wVjreveFmcQ=.8d1796ee-3561-4595-8aee-3f4d06298084@github.com>
Message-ID: <FXKs0T6H_OTMuDJJwtYWK7dbr-8X4k1163LbT3aQOo4=.4b93f7f5-5d0c-4792-afeb-309bcd0b0a17@github.com>

On Tue, 18 Mar 2025 23:15:29 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo fix
>
> test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 135:
> 
>> 133:         int type = Byte.toUnsignedInt(tlsRecord.get());
>> 134:         int ver_major = Byte.toUnsignedInt(tlsRecord.get());
>> 135:         int ver_minor = Byte.toUnsignedInt(tlsRecord.get());
> 
> These 3 variables appear to not be used.

Yes, that code was copied from the original `SigSchemePropOrdering` file and that's the pattern seen throughout our SSL code when reading TLS record. I think it's done for clarity. Alternatively we can remove assignments to unused variables and add a comment for every read operation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2004149338

From vpaprotski at openjdk.org  Wed Mar 19 23:03:08 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 19 Mar 2025 23:03:08 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <PUMkpytKKZX84tzpJoB4zFLt4pZXtTI8cQoP8li_f2s=.2112b3f5-9f65-471c-a5df-cf916aab44aa@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
 <X7zT-DxVzyhXInXudD3F5OYXMwUGQQ1mUrEPNPqZCkY=.15e0bfcd-26e6-4c0b-90ac-67f632ed81ec@github.com>
 <W26HBW3Wj-oke-vXimRbaWxBvn0cP66GQ1PRNrtnnzI=.cb058a5d-43cb-479e-9766-0202e7f98cfb@github.com>
 <PUMkpytKKZX84tzpJoB4zFLt4pZXtTI8cQoP8li_f2s=.2112b3f5-9f65-471c-a5df-cf916aab44aa@github.com>
Message-ID: <YIM93h8UBE4aJsRyvc_71XUD-8IrhwB1G9ELQLHr0JA=.cf7e94ec-b777-4b25-aaa6-2183ec892188@github.com>

On Wed, 19 Mar 2025 19:00:37 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I was mostly attempting to test 'random paths' through the code, and this was a way to pseudo-randomly accomplish that. (i.e. a product of a difference, a product of a product.. and so on..)
>> 
>> Since this is looping, we got 50% chance of getting both, without me having to write/think-through all the many permutations of what input/outputs to each operations can be.
>> 
>> (Extend the loop count to run for several hours during development.. and it does wonders to testing corner cases. Have been following this 'template' in most my PRs)
>
> Randomness isn't idea for reproducibility.  If a failure occurs, is it obvious what operations were done?  I don't see any stdout or stderr messages to know what operations happen to bring about a possible failure.

I used it this testcase for development (and figured I should also check it in..) so what might be 'obvious' to me, might not be for anyone else?

Typically, when a test failed, I grabbed the SEED from the test output, reran the test with that seed fixed and I went to the exception and printed the hex values of the inputs; (then debug from there. Typically, I would write another test, so I could GDB into the intrinsic, with just those input values). 

It was pretty much always the case always that once I got the inputs, I could reproduce the error i.e. not a type of bug that happens silently then discovered somewhere else. Luckily. All this crypto code is constant-time -no-branches-; so the 'test coverage' here is not 'all-branches-taken' but really 'did you remember to collect all the carries'. like 53-bit limb needs to be propagated back down to 52. Thats what the test here is 'searching' for, some input that could trip up computation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2004440368

From hchao at openjdk.org  Thu Mar 20 01:35:07 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 20 Mar 2025 01:35:07 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v9]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <0KllHcqmOGePl7ePndf9Xz7BFpUMj5C21pqDRx9GJV8=.6682eeae-f289-4e6c-966a-7b2d40c71134@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Update warnings to be more user-friendly (not with CEN/LOC)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/ef546f4b..219e91a3

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

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

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

From duke at openjdk.org  Thu Mar 20 11:29:57 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 20 Mar 2025 11:29:57 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v8]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <ArSUYG4NM91jYhSzQs1xT1nCBvffifH8BBIgGNg8Eqc=.4e96b52f-bdec-4843-9460-be386db9b025@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  responding to review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/aa2fdf2d..2438fb5c

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

  Stats: 750 lines in 3 files changed: 174 ins; 447 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/23860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860

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

From fguallini at openjdk.org  Thu Mar 20 11:59:07 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 20 Mar 2025 11:59:07 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v2]
In-Reply-To: <MsI7znMIO7IJyZnTMAaPVSL2avVda-d_mZPekpO18VE=.6314c8e2-4db0-45c6-8eb5-8dbdcd189a75@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 <XIEwj4lNiDE5AykPybPEl-_Mp_ZiyZzKi0qqFrFff1c=.4184f3d6-10d5-4e17-8946-880ddf0e5871@github.com>
 <MsI7znMIO7IJyZnTMAaPVSL2avVda-d_mZPekpO18VE=.6314c8e2-4db0-45c6-8eb5-8dbdcd189a75@github.com>
Message-ID: <HqjhO0tkmFFqm6-85gOlDXsa8WCdyAJcVVByAvt4pt8=.59d9fbfd-a399-48e6-b2cc-b62b4821cbd1@github.com>

On Tue, 18 Mar 2025 02:27:31 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   SSLContextTemplate and using asserts
>
> test/jdk/sun/security/ssl/SSLSocketImpl/NonAutoClose.java line 65:
> 
>> 63:      */
>> 64:     private final static boolean DEBUG = Boolean.getBoolean("test.debug");
>> 65:     private final static int NUM_ITERATIONS = 10;
> 
> Why do we do 10 iterations of the same test?

By looking at the original issue, I believe the multiple iterations were added to ensure that the synchronised behaviour is consistent over several cycles of socket opening and closing, to test that there is no race condition when waiting for the close_notify.

> test/jdk/sun/security/ssl/SSLSocketImpl/NonAutoClose.java line 135:
> 
>> 133:          */
>> 134:         System.out.println("Waiting for server ready");
>> 135:         if (!SERVER_READY.await(5, TimeUnit.SECONDS)) {
> 
> Please see my other comment about `await()`.

Yes, that is fine, updated

> test/jdk/sun/security/ssl/SSLSocketImpl/SetClientMode.java line 100:
> 
>> 98:                 connectedSocket.getSession();
>> 99: 
>> 100:                 if (!HANDSHAKE_COMPLETE.await(5, TimeUnit.SECONDS)) {
> 
> The test will be more robust if we do a simple `await()` call here. On some busy systems even 5 seconds may not be enough. JTEG tests have a default timeout of 2 minutes, so it won't wait forever in any case.

Yes, that is fine, updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r2005462612
PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r2005463263
PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r2005464583

From fguallini at openjdk.org  Thu Mar 20 12:07:54 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 20 Mar 2025 12:07:54 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v3]
In-Reply-To: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
Message-ID: <3HTKyOBLN6Mh_RgsCop3o-S7n7y1BktDGqliaLYiy-w=.9fa77478-7e75-4b3b-b6a3-d8ff668b35e7@github.com>

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

Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:

  latch await

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23898/files
  - new: https://git.openjdk.org/jdk/pull/23898/files/b6ac1491..0133c60f

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

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

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

From fguallini at openjdk.org  Thu Mar 20 12:23:52 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 20 Mar 2025 12:23:52 GMT
Subject: RFR: 8201778: Speed up test
 javax/net/ssl/DTLS/PacketLossRetransmission.java
In-Reply-To: <VFHSods15MJD1V7gNZ1cZb93y9xJTf9xsvRFI4EpOao=.ac9942a9-fd94-476b-86b1-6b86b69f8aef@github.com>
References: <3Tyz1fAexWwXPNzndFkG4SLcl46kKtAk4uZJymFoSz8=.0c429e07-5dfb-45d6-8a06-fdc99fad50a2@github.com>
 <VFHSods15MJD1V7gNZ1cZb93y9xJTf9xsvRFI4EpOao=.ac9942a9-fd94-476b-86b1-6b86b69f8aef@github.com>
Message-ID: <bcp4ibucUbwxu9zao6KDsW2FVYTZanP6vFMt08nN92s=.4ef7d2aa-3b0a-4a10-a8d2-ef1f2c6d07a4@github.com>

On Mon, 17 Mar 2025 18:19:46 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> The test  `javax/net/ssl/DTLS/PacketLossRetransmission` takes about ~2  to complete. The reason is that, in multiple scenarios, the server/client socket times out after 10 seconds waiting to receive a DatagramPacket that has been removed (to simulate a packet loss). 
>> After reducing the time out only for such scenarios, the total test execution is completed within ~20 seconds on average. Other scenarios do not throw SocketTimeOut, no need to update.
>
> test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java line 36:
> 
>> 34:  *
>> 35:  * @run main/othervm PacketLossRetransmission client 0 hello_request
>> 36:  * @run main/othervm PacketLossRetransmission client 1 client_hello shortTimeOut
> 
> Why are you only using a short time out for some messages?
> 
> (Also a small nit: line 109 has a typo.)

Hi Matthew, only reducing the timeout when needed (most scenarios don't throw a socketTimeOut, only some), I'll add a PR description before removing the draft status. Fixed the typo ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24079#discussion_r1999452425

From fguallini at openjdk.org  Thu Mar 20 12:23:51 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 20 Mar 2025 12:23:51 GMT
Subject: RFR: 8201778: Speed up test
 javax/net/ssl/DTLS/PacketLossRetransmission.java
Message-ID: <3Tyz1fAexWwXPNzndFkG4SLcl46kKtAk4uZJymFoSz8=.0c429e07-5dfb-45d6-8a06-fdc99fad50a2@github.com>

The test  `javax/net/ssl/DTLS/PacketLossRetransmission` takes about ~2  to complete. The reason is that, in multiple scenarios, the server/client socket times out after 10 seconds waiting to receive a DatagramPacket that has been removed (to simulate a packet loss). 
After reducing the time out only for such scenarios, the total test execution is completed within ~20 seconds on average. Other scenarios do not throw SocketTimeOut, no need to update.

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

Commit messages:
 - fixed typo
 - copyright year
 - shorter time out

Changes: https://git.openjdk.org/jdk/pull/24079/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24079&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8201778
  Stats: 26 lines in 2 files changed: 9 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24079/head:pull/24079

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

From mdonovan at openjdk.org  Thu Mar 20 12:23:52 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 20 Mar 2025 12:23:52 GMT
Subject: RFR: 8201778: Speed up test
 javax/net/ssl/DTLS/PacketLossRetransmission.java
In-Reply-To: <3Tyz1fAexWwXPNzndFkG4SLcl46kKtAk4uZJymFoSz8=.0c429e07-5dfb-45d6-8a06-fdc99fad50a2@github.com>
References: <3Tyz1fAexWwXPNzndFkG4SLcl46kKtAk4uZJymFoSz8=.0c429e07-5dfb-45d6-8a06-fdc99fad50a2@github.com>
Message-ID: <VFHSods15MJD1V7gNZ1cZb93y9xJTf9xsvRFI4EpOao=.ac9942a9-fd94-476b-86b1-6b86b69f8aef@github.com>

On Mon, 17 Mar 2025 13:19:55 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> The test  `javax/net/ssl/DTLS/PacketLossRetransmission` takes about ~2  to complete. The reason is that, in multiple scenarios, the server/client socket times out after 10 seconds waiting to receive a DatagramPacket that has been removed (to simulate a packet loss). 
> After reducing the time out only for such scenarios, the total test execution is completed within ~20 seconds on average. Other scenarios do not throw SocketTimeOut, no need to update.

test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java line 36:

> 34:  *
> 35:  * @run main/othervm PacketLossRetransmission client 0 hello_request
> 36:  * @run main/othervm PacketLossRetransmission client 1 client_hello shortTimeOut

Why are you only using a short time out for some messages?

(Also a small nit: line 109 has a typo.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24079#discussion_r1999375824

From ascarpino at openjdk.org  Thu Mar 20 16:34:12 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 20 Mar 2025 16:34:12 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v5]
In-Reply-To: <9ae5-lWvHoGhiN3Z_hjsa4npeO9oBjTfUmzAQKJWhEo=.c00dbbcc-e57d-493d-aa8f-22934d98a867@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <_6CxG2DQbtkrtH7oVDI30xwt4_zsJdIMALsjdvPRBM4=.dc1fe2a4-ddba-4d83-9570-b1055e4d251c@github.com>
 <9ae5-lWvHoGhiN3Z_hjsa4npeO9oBjTfUmzAQKJWhEo=.c00dbbcc-e57d-493d-aa8f-22934d98a867@github.com>
Message-ID: <E3izyh_JgcHtpL4ksPL02MmAp_94oVnI1AEr3aA-uQI=.e42775e8-f29a-401f-91eb-1ea946dfbca0@github.com>

On Tue, 18 Mar 2025 19:14:40 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   check for dup
>
> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java line 210:
> 
>> 208:                     new CertPathConstraintsParameters(trustedPubKey, variant,
>> 209:                         anchor, date);
>> 210:                 dac.permits(KeyUtil.getAlgorithm(trustedPubKey),
> 
> Do you plan to have a unit test for `AlgorithmChecker` changes? It looks like certificates using `ED25519` algorithm didn't match that check before. It would be useful to have a test where we disable `ED25519` in java.security and then try to use a certificate with `ED25519` algorithm.

This is checked by an existing test

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2006034135

From ascarpino at openjdk.org  Thu Mar 20 16:55:12 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 20 Mar 2025 16:55:12 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v4]
In-Reply-To: <F2wGWIqSNQdN0JDiUsQfHzb-SbQrdZBx1f1XtL4p738=.d2363c53-e312-4401-b317-0128dc2b6575@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <c5KF8wFufjEbuAeFj2Mpc7M60j8jTyns-XP5iY8K194=.283efa1e-f662-4592-b1ba-0ea25a6c0bfb@github.com>
 <Z0-G2-rRsTESI2O9BOQHsAXjeVIloZ4T3--0dkm2EiU=.b5b1f7e1-6e8e-4a8b-82d1-ae6c7c09d996@github.com>
 <gFOi2wc0zFdeRd3NEKBBvTJ64LhHm6uDFKtDrO5JXQ0=.ec6bbbe6-3767-494d-9ad1-5bb1f1930bad@github.com>
 <F2wGWIqSNQdN0JDiUsQfHzb-SbQrdZBx1f1XtL4p738=.d2363c53-e312-4401-b317-0128dc2b6575@github.com>
Message-ID: <k57wXk9UBdocErBNisEnvLMRCVGGwlh6Bzuyajz0HR8=.167465b2-3979-447d-a871-4c5d3a491008@github.com>

On Fri, 14 Mar 2025 19:44:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I'm confused by this comment.  With removing the hardcoded aliases in AbstractAlgorithmConstraints, which is what I thought you had suggested, EdDSA and Ed25519 are now separate as the check is effectively a string compare check against the disabledAlgorithm list
>> 
>> The second half of that case statement has a key that can check against both EdDSA and the NPS.
>> 
>> With respect to `CryptoPrimitive.SIGNATURE`, it just a value used in the test, it can't be null.
>
> Yes, I remember that.
> 
> I understand there will be multiple checks in TLS and CertPath. Do we have existing tests on that level?

We have other tests that check this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2006073361

From ascarpino at openjdk.org  Thu Mar 20 17:37:27 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 20 Mar 2025 17:37:27 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <YIM93h8UBE4aJsRyvc_71XUD-8IrhwB1G9ELQLHr0JA=.cf7e94ec-b777-4b25-aaa6-2183ec892188@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
 <X7zT-DxVzyhXInXudD3F5OYXMwUGQQ1mUrEPNPqZCkY=.15e0bfcd-26e6-4c0b-90ac-67f632ed81ec@github.com>
 <W26HBW3Wj-oke-vXimRbaWxBvn0cP66GQ1PRNrtnnzI=.cb058a5d-43cb-479e-9766-0202e7f98cfb@github.com>
 <PUMkpytKKZX84tzpJoB4zFLt4pZXtTI8cQoP8li_f2s=.2112b3f5-9f65-471c-a5df-cf916aab44aa@github.com>
 <YIM93h8UBE4aJsRyvc_71XUD-8IrhwB1G9ELQLHr0JA=.cf7e94ec-b777-4b25-aaa6-2183ec892188@github.com>
Message-ID: <7RbzyVMGDjIExr2AfjOVElXXrKIlddltIo6vPH0yxQs=.7296744e-29f1-4e72-a44d-ce8875be6644@github.com>

On Wed, 19 Mar 2025 23:00:55 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Randomness isn't idea for reproducibility.  If a failure occurs, is it obvious what operations were done?  I don't see any stdout or stderr messages to know what operations happen to bring about a possible failure.
>
> I used it this testcase for development (and figured I should also check it in..) so what might be 'obvious' to me, might not be for anyone else?
> 
> Typically, when a test failed, I grabbed the SEED from the test output, reran the test with that seed fixed and I went to the exception and printed the hex values of the inputs; (then debug from there. Typically, I would write another test, so I could GDB into the intrinsic, with just those input values). 
> 
> It was pretty much always the case always that once I got the inputs, I could reproduce the error i.e. not a type of bug that happens silently then discovered somewhere else. Luckily. All this crypto code is constant-time -no-branches-; so the 'test coverage' here is not 'all-branches-taken' but really 'did you remember to collect all the carries'. like 53-bit limb needs to be propagated back down to 52. Thats what the test here is 'searching' for, some input that could trip up computation.

Can you add a comment to the test code about how you use the seed to reproduce any failures?  So that in the future, someone who doesn't know will now have an idea how to start debugging this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2006142794

From abarashev at openjdk.org  Thu Mar 20 18:05:14 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 20 Mar 2025 18:05:14 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v3]
In-Reply-To: <3HTKyOBLN6Mh_RgsCop3o-S7n7y1BktDGqliaLYiy-w=.9fa77478-7e75-4b3b-b6a3-d8ff668b35e7@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 <3HTKyOBLN6Mh_RgsCop3o-S7n7y1BktDGqliaLYiy-w=.9fa77478-7e75-4b3b-b6a3-d8ff668b35e7@github.com>
Message-ID: <_xzqVzvml9hS84QUaricBT4XsNInOAzDOW9kfYFcThQ=.94cb1a17-8351-495b-9606-89754b7a0c68@github.com>

On Thu, 20 Mar 2025 12:07:54 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

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

test/jdk/sun/security/ssl/SSLSocketImpl/SetClientMode.java line 110:

> 108:                 } catch (IllegalArgumentException iae) {
> 109:                     System.out.println("succeeded, we can't set the client mode");
> 110:                 }

I suggest using `runAndCheckException` from /test/lib here instead of try/catch construct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r2006185175

From hchao at openjdk.org  Thu Mar 20 18:29:24 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 20 Mar 2025 18:29:24 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v10]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <Ahd0tqeuigogCMLBQVehnS-S0RSPyqUHOMG6subhQgQ=.cefb3207-6558-49df-b792-b54ce529a914@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Convert new test to junit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/219e91a3..0d53befd

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

  Stats: 44 lines in 1 file changed: 20 ins; 6 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

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

From xuelei at openjdk.org  Thu Mar 20 18:30:20 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 20 Mar 2025 18:30:20 GMT
Subject: RFR: 8315487: Security Providers Filter [v21]
In-Reply-To: <0-XKAp3GDqQpeD9D1XtAp31BwOvA-sZGWpKV5wTD-e8=.e73d4cf3-0970-41f8-b7e3-aa29ff6543db@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
 <0-XKAp3GDqQpeD9D1XtAp31BwOvA-sZGWpKV5wTD-e8=.e73d4cf3-0970-41f8-b7e3-aa29ff6543db@github.com>
Message-ID: <cZYLyp7aV80-45g53Wwp5l7TE9_V7R7Rf5gxFVIPW_Q=.ed2875d2-b11f-4fec-8384-2759e440b19e@github.com>

On Thu, 20 Feb 2025 20:31:40 GMT, Martin Balao <mbalao at openjdk.org> wrote:

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

The specification update and implementation details is far from I can images from last read of the pull request.  It reminds me the way security manager was used to be: permission code was inserted everywhere, and hard to configure to use it in practice.

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

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

From duke at openjdk.org  Thu Mar 20 18:42:48 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 20 Mar 2025 18:42:48 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v9]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <iLBggfqh5ULXOPU28WVp8x2ZE9WLBxduJwvnCHIaxFU=.8721af86-0cb8-492f-bc5f-00d63da14f3a@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  More beautification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/2438fb5c..1cfab778

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

  Stats: 307 lines in 1 file changed: 49 ins; 131 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/23860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860

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

From xuelei at openjdk.org  Thu Mar 20 20:08:17 2025
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 20 Mar 2025 20:08:17 GMT
Subject: RFR: 8315487: Security Providers Filter [v21]
In-Reply-To: <0-XKAp3GDqQpeD9D1XtAp31BwOvA-sZGWpKV5wTD-e8=.e73d4cf3-0970-41f8-b7e3-aa29ff6543db@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
 <0-XKAp3GDqQpeD9D1XtAp31BwOvA-sZGWpKV5wTD-e8=.e73d4cf3-0970-41f8-b7e3-aa29ff6543db@github.com>
Message-ID: <cYPe1AAMcA9NCzpYllOwB1lbqLzB0g1SDd-OM6bdfUI=.c01f1bc3-80f7-47f8-a325-08ab73f98af8@github.com>

On Thu, 20 Feb 2025 20:31:40 GMT, Martin Balao <mbalao at openjdk.org> wrote:

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

The complexity mainly comes from the legacy use of Provider.put() methods. I was just wondering if it is ok to places filter at Provider.putService() only, with specification update.  Putservice() Specification compliant provider, including all JDK built-in providers, will work with the filter.  Applications that would like to benefit from this feature could choose to use specification compliant providers.  The Provider.put() methods could be "deprecated" somehow in the future.

This is just for your reference, please just ignore it if you don't want to consider this direction.

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

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

From duke at openjdk.org  Thu Mar 20 20:37:25 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 20 Mar 2025 20:37:25 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v10]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <2N5Evij0f6qZi_pG3tqoz11aQbSnLG0YszqHR9ROfKI=.d44b16c6-d334-42c4-8de8-92eb41229248@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Fix windows build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/1cfab778..e9db09e2

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

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

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

From duke at openjdk.org  Thu Mar 20 21:09:12 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 20 Mar 2025 21:09:12 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v7]
In-Reply-To: <kBg6GrgsVt_pKZ2MfKEHbuEb9Uk5YFWWQ7tKUOKySH4=.106187c8-0bb4-4463-afd7-a406fce15fc4@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xeGVcNvhb8JogSwnBjlAln9bAiZMAeiOEC5XrH0FVX0=.564addcd-ee9a-4628-8df1-b546e7de45be@github.com>
 <kBg6GrgsVt_pKZ2MfKEHbuEb9Uk5YFWWQ7tKUOKySH4=.106187c8-0bb4-4463-afd7-a406fce15fc4@github.com>
Message-ID: <MiV8AD5mEqWLf_DDaoTF7jG06Zd7bBloGuxRZqGtN3U=.e55cfe7f-eb52-4da1-bddd-01ce74cfc633@github.com>

On Mon, 17 Mar 2025 19:24:52 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made the intrinsics test separate from the pure java test.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 58:
> 
>> 56: 
>> 57: ATTRIBUTE_ALIGNED(64) static const uint32_t dilithiumAvx512Perms[] = {
>> 58:      // collect montmul results into the destination register
> 
> same as `dilithiumAvx512Consts()`, 'magic offsets'; except here they are harder to count (eg. not clear visually what is the offset of `ntt inverse`).
> 
> Could be split into three constant arrays to make the compiler count for us

Well, it is 64 bytes per  line (16 4-byte uint32_ts), not that hard :-) ...

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 140:
> 
>> 138:   __ vpmuldq(xmm(scratchReg1 + 1), xmm(inputReg12), xmm(inputReg2 + 1), Assembler::AVX_512bit);
>> 139:   __ vpmuldq(xmm(scratchReg1 + 2), xmm(inputReg13), xmm(inputReg2 + 2), Assembler::AVX_512bit);
>> 140:   __ vpmuldq(xmm(scratchReg1 + 3), xmm(inputReg14), xmm(inputReg2 + 3), Assembler::AVX_512bit);
> 
> Another option for these four lines, to keep the style of rest of function
> 
> int inputReg1[] = {inputReg11, inputReg12, inputReg13, inputReg14};
>   for (int i = 0; i < parCnt; i++) {
>     __ vpmuldq(xmm(scratchReg1 + i), inputReg1[i], xmm(inputReg2 + i), Assembler::AVX_512bit);
>   }

I have changed the whole structure instead.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 197:
> 
>> 195: 
>> 196:   // level 0
>> 197:   montmulEven(20, 8, 29, 20, 16, 4);
> 
> It would improve readability to know which parameter is a register, and which is a count.. i.e. 
> 
> `montmulEven(xmm20, xmm8, xmm29, xmm20, xmm16, 4);`
> 
> (its not _that_ bad, once I remember that its always the last parameter.. but it does add to the 'mental load' one has to carry, and this code is already interesting enough)

I have changed the structure, now it is clear(er) which parameter is what.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 980:
> 
>> 978: // Dilithium multiply polynomials in the NTT domain.
>> 979: // Implements
>> 980: // static int implDilithiumNttMult(
> 
> I suppose no java changes in this PR, but I notice that the inputs are all assumed to have fixed size.
> 
> Most/all intrinsics I worked with had some sort of guard (eg `Objects.checkFromIndexSize`) right before the intrinsic java call. (It usually looks like it can be optimized away). But I notice no such guard here on the java side.

These functions will not be used anywhere else and in ML_DSA.java all of the arrays passed to inrinsics are of the correct size.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1010:
> 
>> 1008:   __ vpbroadcastd(xmm31, Address(dilithiumConsts, 4), Assembler::AVX_512bit); // q
>> 1009:   __ vpbroadcastd(xmm29, Address(dilithiumConsts, 12), Assembler::AVX_512bit); // 2^64 mod q
>> 1010:   __ evmovdqul(xmm28, Address(perms, 0), Assembler::AVX_512bit);
> 
> - use of `c_rarg3` is 'clever' so probably should have a comment (ie. 'no 3rd parameter, free register')
> - Alternatively, load directly into the vector with `ExternalAddress()`; you need a scratch register (use r10) but address is close enough, it actually wont be used. Here is the disassembly I got:
> 
> StubRoutines::dilithiumNttMult [0x00007f414fb68280, 0x00007f414fb68548] (712 bytes)
> --------------------------------------------------------------------------------
> add    %al,(%rax)
>   0x00007f414fb68280:   push   %rbp
>   0x00007f414fb68281:   mov    %rsp,%rbp
>   0x00007f414fb68284:   vpbroadcastd 0x18f9fe32(%rip),%zmm30        # 0x00007f4168b080c0
>   0x00007f414fb6828e:   vpbroadcastd 0x18f9fe2c(%rip),%zmm31        # 0x00007f4168b080c4
>   0x00007f414fb68298:   vpbroadcastd 0x18f9fe2a(%rip),%zmm29        # 0x00007f4168b080cc
>   0x00007f414fb682a2:   vmovdqu32 0x18f9f8d4(%rip),%zmm28        # 0x00007f4168b07b80
>   ```
>   
> The `ExternalAddress()` calls for above assembler
>   ```
>   const Register scratch = r10;
>   const XMMRegister montRSquareModQ = xmm29;
>   const XMMRegister montQInvModR = xmm30;
>   const XMMRegister dilithium_q = xmm31;
>   const XMMRegister perms = xmm28;
> 
>   __ vpbroadcastd(montQInvModR, ExternalAddress(dilithiumAvx512ConstsAddr()), Assembler::AVX_512bit, scratch); // q^-1 mod 2^32
>   __ vpbroadcastd(dilithium_q, ExternalAddress(dilithiumAvx512ConstsAddr() + 4), Assembler::AVX_512bit, scratch); // q
>   __ vpbroadcastd(montRSquareModQ, ExternalAddress(dilithiumAvx512ConstsAddr() + 12), Assembler::AVX_512bit, scratch); // 2^64 mod q
>   __ evmovdqul(perms, k0, ExternalAddress(dilithiumAvx512PermsAddr()), false, Assembler::AVX_512bit, scratch);
> 
> (and `dilithiumAvx512ConstsAddr(offset)` cound take an int parameter too)

I added comments and changed the vpbroadcast loads to load directly from memory.l

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1012:
> 
>> 1010:   __ evmovdqul(xmm28, Address(perms, 0), Assembler::AVX_512bit);
>> 1011: 
>> 1012:   __ movl(len, 4);
> 
> Compile-time constant, why not 'unroll at compile time'? i.e. wrap this loop with `for (int len=0; len<4; len++)` instead?

I have found that unrolling these loops actually hurts performance (probably an I-cache effect.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1041:
> 
>> 1039:   for (int i = 0; i < 4; i++) {
>> 1040:     __ evmovdqul(Address(result, i * 64), xmm(i), Assembler::AVX_512bit);
>> 1041:   }
> 
> This is nice, compact and clean. The biggest issue I have with following this code is really with all the 'raw' registers. I would much rather prefer symbolic names, but up to you to decide style.
> 
> I ended up 'annotating' this snippet, so I could understand it and confirm everything..  as with montmulEven, hope some of it can be useful to you to copy out.
> 
> 
>   XMMRegister POLY1[] = {xmm0, xmm1, xmm2, xmm3};
>   XMMRegister POLY2[] = {xmm4, xmm5, xmm6, xmm7};
>   XMMRegister SCRATCH1[] = {xmm12, xmm13, xmm14, xmm15};
>   XMMRegister SCRATCH2[] = {xmm16, xmm17, xmm18, xmm19};
>   XMMRegister SCRATCH3[] = {xmm8, xmm9, xmm10, xmm11};
>   for (int i = 0; i < 4; i++) {
>     __ evmovdqul(POLY1[i], Address(poly1, i * 64), Assembler::AVX_512bit);
>     __ evmovdqul(POLY2[i], Address(poly2, i * 64), Assembler::AVX_512bit);
>   }
> 
>   // montmulEven: inputs are in even columns and output is in odd columns
>   // scratch3_even = poly2_even*montRSquareModQ // poly2 to montgomery domain
>   montmulEven2(SCRATCH3[0], POLY2[0], montRSquareModQ, SCRATCH1[0], SCRATCH2[0], montQInvModR, dilithium_q, 4, _masm);
>   for (int i = 0; i < 4; i++) {
>     // swap even/odd; 0xB1 == 2-3-0-1
>     __ vpshufd(SCRATCH3[i], SCRATCH3[i], 0xB1, Assembler::AVX_512bit);
>   }
> 
>   // scratch3_odd = poly1_even*scratch3_even = poly1_even*poly2_even*montRSquareModQ
>   montmulEven2(SCRATCH3[0], POLY1[0], SCRATCH3[0], SCRATCH1[0], SCRATCH2[0], 4, montQInvModR, dilithium_q, 4, _masm);
>   for (int i = 0; i < 4; i++) {
>     __ vpshufd(POLY1[i], POLY1[i], 0xB1, Assembler::AVX_512bit);
>     __ vpshufd(POLY2[i], POLY2[i], 0xB1, Assembler::AVX_512bit);
>   }
> 
>   // poly2_even = poly2_odd*montRSquareModQ // poly2 to montgomery domain
>   montmulEven2(POLY2[0], POLY2[0], montRSquareModQ, SCRATCH1[0], SCRATCH2[0], 4, montQInvModR, dilithium_q, 4, _masm);
>   for (int i = 0; i < 4; i++) {
>     __ vpshufd(POLY2[i], POLY2[i], 0xB1, Assembler::AVX_512bit);
>   }
> 
>   // poly1_odd = poly1_even*poly2_even
>   montmulEven2(POLY1[0], POLY1[0], POLY2[0], SCRATCH1[0], SCRATCH2[0], 4, montQInvModR, dilithium_q, 4, _masm);
>   for (int i = 0; i < 4; i++) {
>     // result is scrambled between scratch3_odd and poly1_odd; unscramble
>     __ evpermt2d(POLY1[i], perms, SCRATCH3[i], Assembler::AVX_512bit);
>   }
>   for (int i = 0; i < 4; i++) {
>     __ evmovdqul(Address(result, i *...

I have rewritten it to use full montmuls (a new function) her and everywhere else. It is much easier to follow the code that way.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1090:
> 
>> 1088:   __ evpbroadcastd(xmm29, constant, Assembler::AVX_512bit); // constant multiplier
>> 1089: 
>> 1090:   __ movl(len, 2);
> 
> Same comment here as the `generate_dilithiumNttMult_avx512`
> - constants can be loaded directly into XMM
> - len can be removed by unrolling at compile time
> - symbolic names could be used for registers
> - comments could be added

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2006455445
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2006455814
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2006455732
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2006454991
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2006455529
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2006455662
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2006455178
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2006455086

From duke at openjdk.org  Thu Mar 20 21:09:14 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 20 Mar 2025 21:09:14 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v5]
In-Reply-To: <uUNg9Inwc5sySYy-v52dgYVTSxNU0n7EQZdsjQESTsY=.b9bfb2ab-42ef-40fc-9173-6a141adfac38@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <3bphXKLpIpxAZP-FEOeob6AaHbv0BAoEceJka64vMW8=.3e4f74e0-9479-4926-b365-b08d8d702692@github.com>
 <uUNg9Inwc5sySYy-v52dgYVTSxNU0n7EQZdsjQESTsY=.b9bfb2ab-42ef-40fc-9173-6a141adfac38@github.com>
Message-ID: <tUuz7mcyKkHz0RnrD6AFFd3Dq_mN3rILQQWRzRN7j80=.563937a3-2106-47ef-8d01-f75a939cd5af@github.com>

On Thu, 6 Mar 2025 19:27:12 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Accepted review comments.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 426:
> 
>> 424:   __ subl( roundsLeft, 1);
>> 425: 
>> 426:   __ evmovdquw(xmm5, xmm0, Assembler::AVX_512bit);
> 
> Is there a pattern here; that can be 'compacted' into a loop?

Unfortunately, no. This loop body is imported  from generate_sha3_implCompress() and doubled, as explained in the comment about 15 lines above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2006455877

From hchao at openjdk.org  Thu Mar 20 21:48:22 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 20 Mar 2025 21:48:22 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v11]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <crNHrhALZop4pZcc7Jr6ToFydAgquafhUU5ZTZh2dEU=.58d7a8c0-e531-46fb-aa85-c0234dd45d40@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Update test to include validating the un-modified jar

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/0d53befd..15544e22

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

  Stats: 45 lines in 1 file changed: 21 ins; 15 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

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

From fguallini at openjdk.org  Fri Mar 21 12:00:57 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Fri, 21 Mar 2025 12:00:57 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v4]
In-Reply-To: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
Message-ID: <tu2uk1Ux6SzMBZ1oo6rgEM49KqhGv0eEC2-JSVn4kHE=.4e7157fc-b871-4c7f-a785-b48be9d31503@github.com>

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

Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:

  using assertThrows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23898/files
  - new: https://git.openjdk.org/jdk/pull/23898/files/0133c60f..2741a197

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

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

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

From fguallini at openjdk.org  Fri Mar 21 12:00:57 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Fri, 21 Mar 2025 12:00:57 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v3]
In-Reply-To: <_xzqVzvml9hS84QUaricBT4XsNInOAzDOW9kfYFcThQ=.94cb1a17-8351-495b-9606-89754b7a0c68@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 <3HTKyOBLN6Mh_RgsCop3o-S7n7y1BktDGqliaLYiy-w=.9fa77478-7e75-4b3b-b6a3-d8ff668b35e7@github.com>
 <_xzqVzvml9hS84QUaricBT4XsNInOAzDOW9kfYFcThQ=.94cb1a17-8351-495b-9606-89754b7a0c68@github.com>
Message-ID: <DNJz3kzvxiRz_zWO36M2jwB0yXu4dvTolvIqBjXUmh4=.10b83cf8-b99c-4c66-9c7a-269e28a87fa5@github.com>

On Thu, 20 Mar 2025 18:02:49 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   latch await
>
> test/jdk/sun/security/ssl/SSLSocketImpl/SetClientMode.java line 110:
> 
>> 108:                 } catch (IllegalArgumentException iae) {
>> 109:                     System.out.println("succeeded, we can't set the client mode");
>> 110:                 }
> 
> I suggest using `runAndCheckException` from /test/lib here instead of try/catch construct.

Sure, but using assertThrows instead. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23898#discussion_r2007442469

From adinn at openjdk.org  Fri Mar 21 14:02:17 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Fri, 21 Mar 2025 14:02:17 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v4]
In-Reply-To: <s1i_jDlsrQSGx-cx7O4uE_qwU8L1uxhANZEqG4oXclM=.bf657af0-9c8e-4b4f-a275-43a7ce118c6a@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <s1i_jDlsrQSGx-cx7O4uE_qwU8L1uxhANZEqG4oXclM=.bf657af0-9c8e-4b4f-a275-43a7ce118c6a@github.com>
Message-ID: <SjVh7nBBIqRfsQTIgkq_KuYmu9BXjjQOOgfTk8CWPCs=.7df8664d-9152-4ee7-9967-2e80ad77aef0@github.com>

On Tue, 4 Mar 2025 22:04:26 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Fixed mismerge.
>  - Merged master.
>  - A little cleanup
>  - Merged master
>  - removing trailing spaces
>  - kyber aarch64 intrinsics

src/hotspot/share/opto/library_call.cpp line 7800:

> 7798:   const char *stubName;
> 7799:   assert(UseKyberIntrinsics, "need Kyber intrinsics support");
> 7800:   assert(callee()->signature()->size() == 3, "kyber12To16 has 3 parameters");

Just as an aside this causes testing of a debug build to fail. The intrinsic has 4 parameters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2007638886

From adinn at openjdk.org  Fri Mar 21 14:02:18 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Fri, 21 Mar 2025 14:02:18 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v4]
In-Reply-To: <SjVh7nBBIqRfsQTIgkq_KuYmu9BXjjQOOgfTk8CWPCs=.7df8664d-9152-4ee7-9967-2e80ad77aef0@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
 <s1i_jDlsrQSGx-cx7O4uE_qwU8L1uxhANZEqG4oXclM=.bf657af0-9c8e-4b4f-a275-43a7ce118c6a@github.com>
 <SjVh7nBBIqRfsQTIgkq_KuYmu9BXjjQOOgfTk8CWPCs=.7df8664d-9152-4ee7-9967-2e80ad77aef0@github.com>
Message-ID: <54ED2n9rhYXWQuwge7bPuvPXtAmL2WpfRJFfXH__r2I=.dead1c37-4283-48a6-ad01-26fc92be30fa@github.com>

On Fri, 21 Mar 2025 13:59:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Fixed mismerge.
>>  - Merged master.
>>  - A little cleanup
>>  - Merged master
>>  - removing trailing spaces
>>  - kyber aarch64 intrinsics
>
> src/hotspot/share/opto/library_call.cpp line 7800:
> 
>> 7798:   const char *stubName;
>> 7799:   assert(UseKyberIntrinsics, "need Kyber intrinsics support");
>> 7800:   assert(callee()->signature()->size() == 3, "kyber12To16 has 3 parameters");
> 
> Just as an aside this causes testing of a debug build to fail. The intrinsic has 4 parameters.

With this value reset to 4 the ML_DSA test passes for ML_KEM on a debug build.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23663#discussion_r2007642721

From abarashev at openjdk.org  Fri Mar 21 14:40:18 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 21 Mar 2025 14:40:18 GMT
Subject: RFR: 8249825: Tests
 sun/security/ssl/SSLSocketImpl/SetClientMode.java and NonAutoClose.java marked
 with @ignore [v4]
In-Reply-To: <tu2uk1Ux6SzMBZ1oo6rgEM49KqhGv0eEC2-JSVn4kHE=.4e7157fc-b871-4c7f-a785-b48be9d31503@github.com>
References: <7mLCLyAU_s7c7ArGXezoeq7wZl_dwH7TtpyrG3izjd4=.2737c7d8-aadc-4310-8dea-61e734484897@github.com>
 <tu2uk1Ux6SzMBZ1oo6rgEM49KqhGv0eEC2-JSVn4kHE=.4e7157fc-b871-4c7f-a785-b48be9d31503@github.com>
Message-ID: <QkHrnyyG5yKOQ25obPXGJOYEou0uUGmMjdcwtYkysDQ=.b57fad4a-40b9-44bc-afb2-afcd481b5134@github.com>

On Fri, 21 Mar 2025 12:00:57 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

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

LGTM

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

Marked as reviewed by abarashev (Author).

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

From mullan at openjdk.org  Fri Mar 21 16:49:14 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 21 Mar 2025 16:49:14 GMT
Subject: RFR: 8347067: Load certificates without explicit trust settings in
 KeyChainStore [v3]
In-Reply-To: <8SJZ0QrFr96h2O1ia4NU_P_jemAGqbItcGctoFCWdGs=.f1f50560-4f6a-4127-b0cf-ea5c743fe794@github.com>
References: <f-f5Omr-1j5X91hy0NYr9lTInI8KbY-vAhR-kF4d6VI=.aeb77e3c-0c59-4426-9166-b9c00f58d7a3@github.com>
 <LnlIpT00znaivHjJ7ay-6G6tbjy60Sf8Qf3bcFMQt_s=.69990892-8aa3-41db-b3f4-62a22cb96a1c@github.com>
 <8SJZ0QrFr96h2O1ia4NU_P_jemAGqbItcGctoFCWdGs=.f1f50560-4f6a-4127-b0cf-ea5c743fe794@github.com>
Message-ID: <dIGauAFyarkTrzwEoKSvJYzQAiQ9BlTTmvkCHGOkrng=.262bc90b-25e1-42f7-91ce-172093e799e7@github.com>

On Mon, 27 Jan 2025 13:06:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Tim Jacomb has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert unneeded change
>
> This change is significant and should be reviewed by at least 2 Reviewers.

> Hi @seanjmullan can you recommend anyone else for review please?

Hi, I was at the JavaOne conference this week. I'll get back to you when I get a chance to review this again.

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

PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2743916658

From hchao at openjdk.org  Fri Mar 21 17:25:40 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 21 Mar 2025 17:25:40 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v12]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <zSnAwmobvQMFlTwMjJdNpGPWxiivBkvu6lN5d1YjvmA=.4c897757-854b-4b61-a05f-a0fa7ee42558@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Update test with comment and formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/15544e22..56bd8b76

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

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

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

From hchao at openjdk.org  Fri Mar 21 19:23:59 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 21 Mar 2025 19:23:59 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v13]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

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

  Update test with more ZipEntry in the jar

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/56bd8b76..e70597d3

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

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

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

From lancea at openjdk.org  Fri Mar 21 19:28:09 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 21 Mar 2025 19:28:09 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v13]
In-Reply-To: <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
Message-ID: <wcffRW-UcXhSfom5J8l_mJINg4ms71Ii48P2S-UKYNU=.3504138b-ed22-41ac-a628-d09d727d668a@github.com>

On Fri, 21 Mar 2025 19:23:59 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test with more ZipEntry in the jar

Hi Hai-May

thank you for your work on this.

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23532#pullrequestreview-2707051183

From hchao at openjdk.org  Fri Mar 21 19:47:07 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 21 Mar 2025 19:47:07 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v13]
In-Reply-To: <wcffRW-UcXhSfom5J8l_mJINg4ms71Ii48P2S-UKYNU=.3504138b-ed22-41ac-a628-d09d727d668a@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
 <wcffRW-UcXhSfom5J8l_mJINg4ms71Ii48P2S-UKYNU=.3504138b-ed22-41ac-a628-d09d727d668a@github.com>
Message-ID: <f_cV4gKxxIPLI3zGNin7LhKMQCL7VKFy5QpTAK2r1LI=.5e29eb93-76d6-4279-b945-2fa429810957@github.com>

On Fri, 21 Mar 2025 19:25:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test with more ZipEntry in the jar
>
> Hi Hai-May
> 
> thank you for your work on this.

@LanceAndersen Thank you for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23532#issuecomment-2744295810

From ascarpino at openjdk.org  Fri Mar 21 20:36:47 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 21 Mar 2025 20:36:47 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v6]
In-Reply-To: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
Message-ID: <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>

> Hi,
> 
> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
> 
> thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  comments on test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23647/files
  - new: https://git.openjdk.org/jdk/pull/23647/files/a0fc101f..799c2acc

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

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

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

From duke at openjdk.org  Sat Mar 22 20:02:31 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Sat, 22 Mar 2025 20:02:31 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:

 - Further readability improvements.
 - Added asserts for array sizes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/e9db09e2..56656894

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

  Stats: 228 lines in 2 files changed: 72 ins; 56 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/23860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860

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

From vpaprotski at openjdk.org  Sat Mar 22 20:05:11 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Sat, 22 Mar 2025 20:05:11 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v10]
In-Reply-To: <2N5Evij0f6qZi_pG3tqoz11aQbSnLG0YszqHR9ROfKI=.d44b16c6-d334-42c4-8de8-92eb41229248@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <2N5Evij0f6qZi_pG3tqoz11aQbSnLG0YszqHR9ROfKI=.d44b16c6-d334-42c4-8de8-92eb41229248@github.com>
Message-ID: <2yP2P1VNWgQu6cWvn0_a_7LdidS71C6PWKcqGKTOHnc=.49f8ac0f-df23-4f1e-adb9-e03a3f2295b2@github.com>

On Thu, 20 Mar 2025 20:37:25 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows build

was going to finish the rest of the functions.. but I see you pushed an update so I better rebase! here are the pending comments I had that perhaps are no longer applicable..

(working through the ntt math..)

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 121:

> 119: static void montmulEven(int outputReg, int inputReg1,  int inputReg2,
> 120:                         int scratchReg1, int scratchReg2,
> 121:                         int parCnt, MacroAssembler *_masm) {

nitpick.. this could be made to look more like `montMul64()` by also taking in an array of registers.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 160:

> 158:   for (int i = 0; i < 4; i++) {
> 159:     __ vpmuldq(xmm(scratchRegs[i]), xmm(inputRegs1[i]), xmm(inputRegs2[i]),
> 160:                Assembler::AVX_512bit);

using an array of registers, instead of array of ints would read somewhat more compact and fewer 'indirections' . i.e.

static void montMul64(XMMRegister outputRegs*, XMMRegister inputRegs1*, XMMRegister inputRegs2*,
...
    __ vpmuldq(scratchRegs[i], inputRegs1[i], inputRegs2[i], Assembler::AVX_512bit);

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 216:

> 214: // Zmm8-Zmm23 used as scratch registers
> 215: // result goes to Zmm0-Zmm7
> 216: static void montMulByConst128(MacroAssembler *_masm) {

wish the inputs and output register arrays were explicit.. easier to follow that way

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 230:

> 228: }
> 229: 
> 230: static void sub_add(int subResult[], int addResult[],

Big fan of all these helper functions! Makes reading the top level functions way easier, thanks for refactoring!

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 279:

> 277: static int xmm4_20_24[] = {4, 5, 6, 7, 20, 21, 22, 23, 24, 25, 26, 27};
> 278: static int xmm16_27[] = {16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27};
> 279: static int xmm29_29[] = {29, 29, 29, 29};

I very much like the new refactor, waaaay clearer now. Some 'Could Do' comments..

- I probably would have preferred 'even more symbolic' variable names (i.e. its ideal when you can match the java variable names!). Conversely, if 'forced to defend this style', these names are MUCH much easier to debug from GDB, its clear what the matching instruction is.
- Not sure about it being global. It works currently, but less 'future proof'.

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 645:

> 643: // poly1 (int[256]) = c_rarg1
> 644: // poly2 (int[256]) = c_rarg2
> 645: static address generate_dilithiumNttMult_avx512(StubGenerator *stubgen,

This would be 'nice to have', something 'lost' with the refactor..

As I was reviewing this (original) function, I was thinking, "there is nothing here _that_ specific to AVX512, mostly columnar&independent operations... This function could be made 'vector-length-independent'..."
- double the loop length:

int iter = vector_len==Assembler::AVX_512bit?4:8;
__ movl(len, 4); -> __ movl(len, iter);

- halve the register arrays.. (or keep them the same but shuffle them to make SURE the first half are in xmm0-xmm15 range)

  XMMRegister POLY1[] = {xmm0, xmm1, xmm12, xmm13};
  XMMRegister POLY2[] = {xmm4, xmm5, xmm16, xmm17};
  XMMRegister SCRATCH1[] = {xmm2, xmm3, xmm14, xmm15}; <<< here
  XMMRegister SCRATCH2[] = {xmm6, xmm7, xmm18, xmm19}; <<< and here
  XMMRegister SCRATCH3[] = {xmm8, xmm9, xmm10, xmm11};

- couple of other int constants (like the memory 'step' and such)
- for assembler calls, like `evmovdqul` and `evpsubd`, need a few small new MacroAssembler helpers to instead generate VEX encoded versions (plenty of instructions already do that).
- I think only the perm instruction was unique to evex (didnt really think of an alternative for AVX2.. but can be abstracted away with another helper)

Anyway; not suggesting its something you do here.. but it would be convenient to leave breadcrumbs/hooks for a future update so one of us can revisit this code and add AVX2 support. e.g. `parCnt` variable was very convenient before for exactly this, now its gone... it probably could be derived in each function from vector_len but..; Its now cleaner, but also harder to 'upgrade'?

Why AVX2? many of the newer (Atom/Ecore-based/EnableX86ECoreOpts) processors do not have AVX512 support, so its something I've been prioritizing recently

The alternative would be to write a completely separate AVX2 implementation, but that would be a shame, not to 'just' reuse this code.
?
"For fun", I had even gone and parametrized the mult function with the `vector_len` to see how it would look (almost identical... to the original version):

static void montmulEven2(XMMRegister* outputReg, XMMRegister* inputReg1,  XMMRegister* inputReg2, XMMRegister* scratchReg1, 
  XMMRegister* scratchReg2, XMMRegister montQInvModR, XMMRegister dilithium_q, int parCnt, int vector_len, MacroAssembler* _masm) {

  for (int i = 0; i < parCnt; i++) {
    // scratch1 = (int64)input1_even*input2_even
    //    Java: long a = (long) b * (long) c;
    __ vpmuldq(scratchReg1[i], inputReg1[i], inputReg2[i], vector_len);
  }
  for (int i = 0; i < parCnt; i++) {
    // scratch2 = int32(montQInvModR*(int32)scratch1)
    //    Java: int aLow = (int) a;
    //    Java: int m = MONT_Q_INV_MOD_R * aLow; // signed low product
    __ vpmulld(scratchReg2[i], scratchReg1[i], montQInvModR, vector_len);
  }
  for (int i = 0; i < parCnt; i++) {
    // scratch2 = (int64)scratch2_even*dilithium_q_even
    //    Java: ((long)m * MONT_Q)
    __ vpmuldq(scratchReg2[i], scratchReg2[i], dilithium_q, vector_len);
  }
  for (int i = 0; i < parCnt; i++) {
    // output_odd = scratch1_odd - scratch2_odd
    //    Java: (aHigh - (int) (("scratch2") >> MONT_R_BITS))
    __ vpsubd(outputReg[i], scratchReg1[i], scratchReg2[i], vector_len);
  }
}

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

PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2708079853
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008809855
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008811046
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008811541
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008811704
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008808110
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008824304

From vpaprotski at openjdk.org  Sat Mar 22 20:05:12 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Sat, 22 Mar 2025 20:05:12 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v7]
In-Reply-To: <MiV8AD5mEqWLf_DDaoTF7jG06Zd7bBloGuxRZqGtN3U=.e55cfe7f-eb52-4da1-bddd-01ce74cfc633@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xeGVcNvhb8JogSwnBjlAln9bAiZMAeiOEC5XrH0FVX0=.564addcd-ee9a-4628-8df1-b546e7de45be@github.com>
 <kBg6GrgsVt_pKZ2MfKEHbuEb9Uk5YFWWQ7tKUOKySH4=.106187c8-0bb4-4463-afd7-a406fce15fc4@github.com>
 <MiV8AD5mEqWLf_DDaoTF7jG06Zd7bBloGuxRZqGtN3U=.e55cfe7f-eb52-4da1-bddd-01ce74cfc633@github.com>
Message-ID: <pqoTfEkEfzOcAOv5JLfWQa7ckVyZfmILw57FVSM7bRc=.a16fb1f6-2bf8-4503-89cc-3eab2df0f686@github.com>

On Thu, 20 Mar 2025 21:06:30 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 58:
>> 
>>> 56: 
>>> 57: ATTRIBUTE_ALIGNED(64) static const uint32_t dilithiumAvx512Perms[] = {
>>> 58:      // collect montmul results into the destination register
>> 
>> same as `dilithiumAvx512Consts()`, 'magic offsets'; except here they are harder to count (eg. not clear visually what is the offset of `ntt inverse`).
>> 
>> Could be split into three constant arrays to make the compiler count for us
>
> Well, it is 64 bytes per  line (16 4-byte uint32_ts), not that hard :-) ...

Ha! I didn't realize it was 16 per line.. ran out of fingers while counting!!! :)

'works for me, as long as its a "premeditated" decision'

>> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 980:
>> 
>>> 978: // Dilithium multiply polynomials in the NTT domain.
>>> 979: // Implements
>>> 980: // static int implDilithiumNttMult(
>> 
>> I suppose no java changes in this PR, but I notice that the inputs are all assumed to have fixed size.
>> 
>> Most/all intrinsics I worked with had some sort of guard (eg `Objects.checkFromIndexSize`) right before the intrinsic java call. (It usually looks like it can be optimized away). But I notice no such guard here on the java side.
>
> These functions will not be used anywhere else and in ML_DSA.java all of the arrays passed to inrinsics are of the correct size.

Works for me; just thought I would point it out, so its a 'premeditated' decision.

>> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 1012:
>> 
>>> 1010:   __ evmovdqul(xmm28, Address(perms, 0), Assembler::AVX_512bit);
>>> 1011: 
>>> 1012:   __ movl(len, 4);
>> 
>> Compile-time constant, why not 'unroll at compile time'? i.e. wrap this loop with `for (int len=0; len<4; len++)` instead?
>
> I have found that unrolling these loops actually hurts performance (probably an I-cache effect.

Interesting; I keep on having to re-train my intuition, thanks for the data

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008806159
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008805574
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008805113

From duke at openjdk.org  Sat Mar 22 20:23:25 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Sat, 22 Mar 2025 20:23:25 GMT
Subject: RFR: 8349721: Add aarch64 intrinsics for ML-KEM [v5]
In-Reply-To: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
References: <eUTcEbCy4gKPEfe0fS4GXXR8i49JYSKCGygRz8CsCnE=.c17a1739-85d2-4bb9-8a74-5ad1694d8d3d@github.com>
Message-ID: <Eyz7nC9xbZmhQFRfGU653-s7RDgZ7SE12mFQSoSE8U4=.3a029cf9-cc60-440a-81b5-2bacdc4a840d@github.com>

> By using the aarch64 vector registers the speed of the computation of the ML-KEM algorithms (key generation, encapsulation, decapsulation) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Fixed bad assertion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23663/files
  - new: https://git.openjdk.org/jdk/pull/23663/files/7e9b3d84..9ec9a6cd

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

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

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

From vpaprotski at openjdk.org  Sat Mar 22 20:42:09 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Sat, 22 Mar 2025 20:42:09 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
Message-ID: <Wp_7I93VCaIAwdDoDeCDPlca3JKEDK4yJeEzfQQdj5M=.118ea8cc-7a0e-4dbc-9837-53cfaccc68de@github.com>

On Sat, 22 Mar 2025 20:02:31 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Further readability improvements.
>  - Added asserts for array sizes

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 119:

> 117: static address dilithiumAvx512PermsAddr() {
> 118:   return (address) dilithiumAvx512Perms;
> 119: }

Hear me out..  ...
enums!!

enum nttPermOffset {
  montMulPermsIdx = 0,
  nttL4PermsIdx = 64,
  nttL5PermsIdx = 192,
  nttL6PermsIdx = 320,
  nttL7PermsIdx = 448,
  nttInvL0PermsIdx = 704,
  nttInvL1PermsIdx = 832,
  nttInvL2PermsIdx = 960,
  nttInvL3PermsIdx = 1088,
  nttInvL4PermsIdx = 1216,
};
static address dilithiumAvx512PermsAddr(nttPermOffset offset) {
  return (address) dilithiumAvx512Perms + offset;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008900858

From jbhateja at openjdk.org  Mon Mar 24 02:41:14 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 24 Mar 2025 02:41:14 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
Message-ID: <Kanyx8L0d27_yUHP15BCfzO8MDEE3_JfDlxaP7Ran_g=.571eca02-d927-4598-ac9e-ff19cef9f484@github.com>

On Sat, 22 Mar 2025 20:02:31 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Further readability improvements.
>  - Added asserts for array sizes

src/hotspot/cpu/x86/vm_version_x86.cpp line 1252:

> 1250:   // Currently we only have them for AVX512
> 1251: #ifdef _LP64
> 1252:   if (supports_evex() && supports_avx512bw()) {

supports_evex check looks redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009379308

From lkorinth at openjdk.org  Mon Mar 24 12:37:28 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 24 Mar 2025 12:37:28 GMT
Subject: RFR: 8352719: Add an equals sign to the modules statement
Message-ID: <zYDJXf6284TfYq62lzdb7804PbHnaH1t2il22GEJ5B0=.6082d470-a0d6-49ee-afc8-ff150d165907@github.com>

krb5/auto/TEST.properties: add an equals sign to the modules statement (this is the only `TEST.properties` file that uses this undocumented feature) .

compare:

find -name "TEST.properties" | xargs grep 'modules.*java' |
find -name "TEST.properties" | xargs grep 'modules.*java' | grep -v =

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

Commit messages:
 - 8352719: Add an equals sign to the modules statement

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

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

From djelinski at openjdk.org  Mon Mar 24 12:59:17 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Mar 2025 12:59:17 GMT
Subject: RFR: 8350705: [JMH] test security.SSLHandshake failed for 2 threads
 configuration
Message-ID: <YmF22vfQt_zYD732jZzvqafBeCAcRQT8ePY1zXjtncw=.c8d46707-4cc0-4ff0-bca5-55cc51e7352f@github.com>

Update the SSLHandshake benchmark to enable running in multiple threads.

This PR changes the scope of the state from per-benchmark to per-thread. The server SSLContext is still shared across all threads to simulate the scenario where multiple clients try to connect to the same server at the same time.

Before the change, running this benchmark with `make test TEST=micro:SSLHandshake MICRO=OPTIONS="-t 3"` failed with an exception. After this change the benchmark completes successfully.

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

Commit messages:
 - Remove outdated comments
 - Initialize server SSLContext once
 - Run benchmark in multiple threads

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

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

From weijun at openjdk.org  Mon Mar 24 13:24:07 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 24 Mar 2025 13:24:07 GMT
Subject: RFR: 8352719: Add an equals sign to the modules statement
In-Reply-To: <zYDJXf6284TfYq62lzdb7804PbHnaH1t2il22GEJ5B0=.6082d470-a0d6-49ee-afc8-ff150d165907@github.com>
References: <zYDJXf6284TfYq62lzdb7804PbHnaH1t2il22GEJ5B0=.6082d470-a0d6-49ee-afc8-ff150d165907@github.com>
Message-ID: <ovayCKefiKvhSKS0QAPuQRUJpaLjlrYQtogrW0R_xwk=.aed06b34-bd74-4b7b-982d-572393df79e5@github.com>

On Mon, 24 Mar 2025 12:30:57 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> krb5/auto/TEST.properties: add an equals sign to the modules statement (this is the only `TEST.properties` file that uses this undocumented feature) .
> 
> compare:
> 
> find -name "TEST.properties" | xargs grep 'modules.*java' 
> find -name "TEST.properties" | xargs grep 'modules.*java' | grep -v =

Thanks for catching this. LGTM.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24194#pullrequestreview-2710369903

From mullan at openjdk.org  Mon Mar 24 14:20:08 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 24 Mar 2025 14:20:08 GMT
Subject: RFR: 8352719: Add an equals sign to the modules statement
In-Reply-To: <zYDJXf6284TfYq62lzdb7804PbHnaH1t2il22GEJ5B0=.6082d470-a0d6-49ee-afc8-ff150d165907@github.com>
References: <zYDJXf6284TfYq62lzdb7804PbHnaH1t2il22GEJ5B0=.6082d470-a0d6-49ee-afc8-ff150d165907@github.com>
Message-ID: <pTjb3jJfHka0wnUf8tiWrTMTh2hgA_3ra3qXVp8s2Tc=.18bae820-399e-4d7e-ba87-3ff1bed38dab@github.com>

On Mon, 24 Mar 2025 12:30:57 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> krb5/auto/TEST.properties: add an equals sign to the modules statement (this is the only `TEST.properties` file that uses this undocumented feature) .
> 
> compare:
> 
> find -name "TEST.properties" | xargs grep 'modules.*java' 
> find -name "TEST.properties" | xargs grep 'modules.*java' | grep -v =

The bug issue needs a `noreg-self` label.

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

PR Review: https://git.openjdk.org/jdk/pull/24194#pullrequestreview-2710555545

From vpaprotski at openjdk.org  Mon Mar 24 15:19:22 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 24 Mar 2025 15:19:22 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
Message-ID: <_TOBoO4cMQpw4sgzIpNpQZ2w5wDgezKQZLe314DQ7zo=.813b81bf-ecc0-4f75-a0d6-fbb13dde594e@github.com>

On Sat, 22 Mar 2025 20:02:31 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Further readability improvements.
>  - Added asserts for array sizes

I still need to have a look at the sha3 changes, but I think I am done with the most complex part of the review. This was a really interesting bit of code to review!

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 270:

> 268: }
> 269: 
> 270: static void loadPerm(int destinationRegs[], Register perms,

`replXmm`? i.e. this function is replicating (any) Xmm register, not just perm?..

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 327:

> 325: //
> 326: //
> 327: static address generate_dilithiumAlmostNtt_avx512(StubGenerator *stubgen,

Similar comments as to `generate_dilithiumAlmostInverseNtt_avx512`

- similar comment about the 'pair-wise' operation, updating `[j]` and `[j+l]` at a time.. 
- somehow had less trouble following the flow through registers here, perhaps I am getting used to it. FYI, ended renaming some as:

// xmm16_27 = Temp1
// xmm0_3 = Coeffs1
// xmm4_7 = Coeffs2
// xmm8_11 = Coeffs3
// xmm12_15 = Coeffs4 = Temp2
// xmm16_27 = Scratch

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 421:

> 419:   for (int i = 0; i < 8; i += 2) {
> 420:     __ evpermi2d(xmm(i / 2 + 12), xmm(i), xmm(i + 1), Assembler::AVX_512bit);
> 421:   }

Wish there was a more 'abstract' way to arrange this, so its obvious from the shape of the code what registers are input/outputs (i.e. and use the register arrays). Even though its just 'elementary index operations' `i/2 + 16` is still 'clever'. Couldnt think of anything myself though (same elsewhere in this function for the table permutes).

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 509:

> 507: // coeffs (int[256]) = c_rarg0
> 508: // zetas (int[256]) = c_rarg1
> 509: static address generate_dilithiumAlmostInverseNtt_avx512(StubGenerator *stubgen,

Done with this function; Perhaps the 'permute table' is a common vector-algorithm pattern, but this is really clever!

Some general comments first, rest inline.

- The array names for registers helped a lot. And so did the new helper functions!
- The java version of this code is quite intimidating to vectorize.. 3D loop, with geometric iteration variables.. and the literature is even more intimidating (discrete convolutions which I havent touched in two decades, ffts, ntts, etc.) Here is my attempt at a comment to 'un-scare' the next reader, though feel free to reword however you like.

The core of the (Java) loop is this 'pair-wise' operation:
        int a = coeffs[j];
        int b = coeffs[j + offset];
        coeffs[j] = (a + b);
        coeffs[j + offset] = montMul(a - b, -MONT_ZETAS_FOR_NTT[m]);

There are 8 'levels' (0-7); ('levels' are equivalent to (unrolling) the outer (Java) loop)
At each level, the 'pair-wise-offset' doubles (2^l: 1, 2, 4, 8, 16, 32, 64, 128).

To vectorize this Java code, observe that at each level, REGARDLESS the offset, half the operations are the SUM, and the other half is the
montgomery MULTIPLICATION (of the pair-difference with a constant). At each level, one 'just' has to shuffle
the coefficients, so that SUMs and MULTIPLICATIONs line up accordingly.

Otherwise, this pattern is 'lightly similar' to a discrete convolution (compute integral/summation of two functions at every offset)

- I still would prefer (more) symbolic register names.. I wouldn't hold my approval over it so won't object if nobody else does, but register numbers are harder to 'see' through the flow. I ended up search/replacing/'annotating' to make it easier on myself to follow the flow of data:

// xmm8_11  = Perms1
// xmm12_15 = Perms2
// xmm16_27 = Scratch
// xmm0_3 = CoeffsPlus
// xmm4_7 = CoeffsMul
// xmm24_27 = CoeffsMinus (overlaps with Scratch)

(I made a similar comment, but I think it is now hidden after the last refactor)
- would prefer to see the helper functions to get ALL the registers passed explicitly (i.e. currently `montMulPerm`, `montQInvModR`, `dilithium_q`, `xmm29`, are implicit.). As a general rule, I've tried to set up all the registers up at the 'entry' function (`generate_dilithium*` in this case) and from there on, use symbolic names. Not always reasonable, but what I've grown used to see?
Done with this function; Perhaps the 'permute table' is a common vector-algorithm pattern, but this is really clever!

Some general comments first, rest inline.

- The array names for registers helped a lot. And so did the new helper functions!
- The java version of this code is quite intimidating to vectorize.. 3D loop, with geometric iteration variables.. and the literature is even more intimidating (discrete convolutions which I havent touched in two decades, ffts, ntts, etc.) Here is my attempt at a comment to 'un-scare' the next reader, though feel free to reword however you like.

The core of the (Java) loop is this 'pair-wise' operation:
        int a = coeffs[j];
        int b = coeffs[j + offset];
        coeffs[j] = (a + b);
        coeffs[j + offset] = montMul(a - b, -MONT_ZETAS_FOR_NTT[m]);

There are 8 'levels' (0-7); ('levels' are equivalent to (unrolling) the outer (Java) loop)
At each level, the 'pair-wise-offset' doubles (2^l: 1, 2, 4, 8, 16, 32, 64, 128).

To vectorize this Java code, observe that at each level, REGARDLESS the offset, half the operations are the SUM, and the other half is the
montgomery MULTIPLICATION (of the pair-difference with a constant). At each level, one 'just' has to shuffle
the coefficients, so that SUMs and MULTIPLICATIONs line up accordingly.

Otherwise, this pattern is 'lightly similar' to a discrete convolution (compute integral/summation of two functions at every offset)

- I still would prefer (more) symbolic register names.. I wouldn't hold my approval over it so won't object if nobody else does, but register numbers are harder to 'see' through the flow. I ended up search/replacing/'annotating' to make it easier on myself to follow the flow of data:

// xmm8_11  = Perms1
// xmm12_15 = Perms2
// xmm16_27 = Scratch
// xmm0_3 = CoeffsPlus
// xmm4_7 = CoeffsMul
// xmm24_27 = CoeffsMinus (overlaps with Scratch)

(I made a similar comment, but I think it is now hidden after the last refactor)
- would prefer to see the helper functions to get ALL the registers passed explicitly (i.e. currently `montMulPerm`, `montQInvModR`, `dilithium_q`, `xmm29`, are implicit.). As a general rule, I've tried to set up all the registers up at the 'entry' function (`generate_dilithium*` in this case) and from there on, use symbolic names. Not always reasonable, but what I've grown used to see?

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 554:

> 552:   for (int i = 0; i < 8; i += 2) {
> 553:     __ evpermi2d(xmm(i / 2 + 8), xmm(i), xmm(i + 1), Assembler::AVX_512bit);
> 554:     __ evpermi2d(xmm(i / 2 + 12), xmm(i), xmm(i + 1), Assembler::AVX_512bit);

Took a bit to unscramble the flow, so a comment needed? Purpose 'fairly obvious' once I got the general shape of the level/algorithm (as per my top-level comment) but something like "shuffle xmm0-7 into xmm8-15"?

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 572:

> 570:   load4Xmms(xmm4_7, zetas, 512, _masm);
> 571:   sub_add(xmm24_27, xmm0_3, xmm8_11, xmm12_15, _masm);
> 572:   montMul64(xmm4_7, xmm24_27, xmm4_7, xmm16_27, _masm);

>From my annotated version, levels 1-4, fairly 'straightforward':

  // level 1
  replXmm(Perms1, perms, nttInvL1PermsIdx, _masm);
  replXmm(Perms2, perms, nttInvL1PermsIdx + 64, _masm);

  for (int i = 0; i < 4; i++) {
    __ evpermi2d(xmm(Perms1[i]), xmm(CoeffsPlus[i]), xmm(CoeffsMul[i]), Assembler::AVX_512bit);
    __ evpermi2d(xmm(Perms2[i]), xmm(CoeffsPlus[i]), xmm(CoeffsMul[i]), Assembler::AVX_512bit);
  }

  load4Xmms(CoeffsMul, zetas, 512, _masm);
  sub_add(CoeffsMinus, CoeffsPlus, Perms1, Perms2, _masm);
  montMul64(CoeffsMul, CoeffsMinus, CoeffsMul, Scratch, _masm);

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 613:

> 611:   montMul64(xmm4_7, xmm24_27, xmm4_7, xmm16_27, _masm);
> 612: 
> 613:   // level 5

"// No shuffling for level 5 and 6; can just rearrange full registers"

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 656:

> 654:   for (int i = 0; i < 8; i++) {
> 655:     __ evpsubd(xmm(i), k0, xmm(i + 8), xmm(i), false, Assembler::AVX_512bit);
> 656:   }

Fairly clean as is, but could also be two sub_add calls, I think (you have to swap order of add/sub in the helper, to be able to clobber `xmm(i)`.. or swap register usage downstream, so perhaps not.. but would be cleaner) 

  sub_add(CoeffsPlus, Scratch, Perms1, CoeffsPlus, _masm);
  sub_add(CoeffsMul,  &Scratch[4], Perms2, CoeffsMul, _masm);


If nothing else, would had prefered to see the use of the register array variables

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 660:

> 658:   store4Xmms(coeffs, 0, xmm16_19, _masm);
> 659:   store4Xmms(coeffs, 4 * XMMBYTES, xmm20_23, _masm);
> 660:   montMulByConst128(_masm);

Would prefer explicit parameters here. But I think this could also be two `montMul64` calls?

  montMul64(xmm0_3, xmm0_3, xmm29_29, Scratch, _masm);
  montMul64(xmm4_7, xmm4_7, xmm29_29, Scratch, _masm);

(I think there is one other use of `montMulByConst128` where same applies; then you could delete both `montMulByConst128` and `montmulEven`

src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 871:

> 869:   __ evpaddd(xmm5, k0, xmm1, barrettAddend, false, Assembler::AVX_512bit);
> 870:   __ evpaddd(xmm6, k0, xmm2, barrettAddend, false, Assembler::AVX_512bit);
> 871:   __ evpaddd(xmm7, k0, xmm3, barrettAddend, false, Assembler::AVX_512bit);

Fairly 'straightforward' transcription of the java code.. no comments from me.

At first glance using `xmm0_3`, `xmm4_7`, etc. might had been a good idea, but you only save one line per 4x group. (Unless you have one big loop, but I suspect that give you worse performance? Is that something you tried already? Might be worth it otherwise..)

src/java.base/share/classes/sun/security/provider/ML_DSA.java line 1418:

> 1416:                                          int twoGamma2, int multiplier) {
> 1417:         assert (input.length == ML_DSA_N) && (lowPart.length == ML_DSA_N)
> 1418:                 && (highPart.length == ML_DSA_N);

I wrote this test to test java-to-intrinsic correspondence. Might be good to include it (and add the other 4 intrinsics). This is very similar to all my other *Fuzz* tests I've been adding for my own intrinsics (and you made this test FAR easier to write by breaking out the java implementation; need to 'copy' that pattern myself)

import java.util.Arrays;
import java.util.Random;

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.lang.reflect.Constructor;

public class ML_DSA_Intrinsic_Test {

    public static void main(String[] args) throws Exception {
        MethodHandles.Lookup lookup = MethodHandles.lookup();
        Class<?> kClazz = Class.forName("sun.security.provider.ML_DSA");
        Constructor<?> constructor = kClazz.getDeclaredConstructor(
                int.class);
        constructor.setAccessible(true);
        
        Method m = kClazz.getDeclaredMethod("mlDsaNttMultiply",
                int[].class, int[].class, int[].class);
        m.setAccessible(true);
        MethodHandle mult = lookup.unreflect(m);

        m = kClazz.getDeclaredMethod("implDilithiumNttMultJava",
                int[].class, int[].class, int[].class);
        m.setAccessible(true);
        MethodHandle multJava = lookup.unreflect(m);

        Random rnd = new Random();
        long seed = rnd.nextLong();
        rnd.setSeed(seed);
        //Note: it might be useful to increase this number during development of new intrinsics
        final int repeat = 1000000;
        int[] coeffs1 = new int[ML_DSA_N];
        int[] coeffs2 = new int[ML_DSA_N];
        int[] prod1 = new int[ML_DSA_N];
        int[] prod2 = new int[ML_DSA_N];
        try {
            for (int i = 0; i < repeat; i++) {
                run(prod1, prod2, coeffs1, coeffs2, mult, multJava, rnd, seed, i);
            }
            System.out.println("Fuzz Success");
        } catch (Throwable e) {
            System.out.println("Fuzz Failed: " + e);
        }
    }

    private static final int ML_DSA_N = 256;
    public static void run(int[] prod1, int[] prod2, int[] coeffs1, int[] coeffs2, 
        MethodHandle mult, MethodHandle multJava, Random rnd, 
        long seed, int i) throws Exception, Throwable {
        for (int j = 0; j<ML_DSA_N; j++) {
            coeffs1[j] = rnd.nextInt();
            coeffs2[j] = rnd.nextInt();
        }

        mult.invoke(prod1, coeffs1, coeffs2);
        multJava.invoke(prod2, coeffs1, coeffs2);

        if (!Arrays.equals(prod1, prod2)) {
                throw new RuntimeException("[Seed "+seed+"@"+i+"] Result mismatch: " + Arrays.toString(prod1) + " != " + Arrays.toString(prod2));
        }
    }
}
// java --add-opens java.base/sun.security.provider=ALL-UNNAMED  -XX:+UseDilithiumIntrinsics test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java

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

PR Review: https://git.openjdk.org/jdk/pull/23860#pullrequestreview-2708301954
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008921783
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009415317
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009477186
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009428310
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009433467
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009435329
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009435791
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009437669
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009438921
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2009486160
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2010355575

From vpaprotski at openjdk.org  Mon Mar 24 15:19:23 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 24 Mar 2025 15:19:23 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <Wp_7I93VCaIAwdDoDeCDPlca3JKEDK4yJeEzfQQdj5M=.118ea8cc-7a0e-4dbc-9837-53cfaccc68de@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
 <Wp_7I93VCaIAwdDoDeCDPlca3JKEDK4yJeEzfQQdj5M=.118ea8cc-7a0e-4dbc-9837-53cfaccc68de@github.com>
Message-ID: <PsyEjOjjVPhvslW1itlklaEZ7zraED6BQavpPxOxN8w=.0cab0c3b-837c-463c-b7f4-5a38b1ce8aeb@github.com>

On Sat, 22 Mar 2025 20:38:19 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Further readability improvements.
>>  - Added asserts for array sizes
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 119:
> 
>> 117: static address dilithiumAvx512PermsAddr() {
>> 118:   return (address) dilithiumAvx512Perms;
>> 119: }
> 
> Hear me out..  ...
> enums!!
> 
> enum nttPermOffset {
>   montMulPermsIdx = 0,
>   nttL4PermsIdx = 64,
>   nttL5PermsIdx = 192,
>   nttL6PermsIdx = 320,
>   nttL7PermsIdx = 448,
>   nttInvL0PermsIdx = 704,
>   nttInvL1PermsIdx = 832,
>   nttInvL2PermsIdx = 960,
>   nttInvL3PermsIdx = 1088,
>   nttInvL4PermsIdx = 1216,
> };
> static address dilithiumAvx512PermsAddr(nttPermOffset offset) {
>   return (address) dilithiumAvx512Perms + offset;
> }

belay that comment.. now that I looked at `generate_dilithiumAlmostInverseNtt_avx512`, I see why thats not the 'entire picture'..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008978604

From vpaprotski at openjdk.org  Mon Mar 24 15:19:25 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 24 Mar 2025 15:19:25 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v10]
In-Reply-To: <2yP2P1VNWgQu6cWvn0_a_7LdidS71C6PWKcqGKTOHnc=.49f8ac0f-df23-4f1e-adb9-e03a3f2295b2@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <2N5Evij0f6qZi_pG3tqoz11aQbSnLG0YszqHR9ROfKI=.d44b16c6-d334-42c4-8de8-92eb41229248@github.com>
 <2yP2P1VNWgQu6cWvn0_a_7LdidS71C6PWKcqGKTOHnc=.49f8ac0f-df23-4f1e-adb9-e03a3f2295b2@github.com>
Message-ID: <36fyT0z29o9GYLeQhpYkIT4d2By-8z7TEU8TGtT2uHI=.50647fa4-32ca-41ef-8287-075a70254143@github.com>

On Sat, 22 Mar 2025 16:45:31 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 216:
> 
>> 214: // Zmm8-Zmm23 used as scratch registers
>> 215: // result goes to Zmm0-Zmm7
>> 216: static void montMulByConst128(MacroAssembler *_masm) {
> 
> wish the inputs and output register arrays were explicit.. easier to follow that way

Looking at this function some more.. I think you could remove this function and replace it with two calls to `montMul64`?

  montMul64(xmm0_3, xmm0_3, xmm29_29, Scratch*, _masm);
  montMul64(xmm4_7, xmm4_7, xmm29_29, Scratch*, _masm);
  ```
Scratch would have to be defined..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2008979257

From abarashev at openjdk.org  Mon Mar 24 17:24:01 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 24 Mar 2025 17:24:01 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Fix java.security syntax. Remove whitespace.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/3f1f4016..edce779d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=17-18

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

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

From vpaprotski at openjdk.org  Mon Mar 24 17:23:51 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 24 Mar 2025 17:23:51 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v7]
In-Reply-To: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
Message-ID: <J8hfAKnOa4N_bT941kRZA4O3f43r2wFJlxe6GTKTQw0=.109cb8fd-d53c-4c52-b968-d6352e26a2a4@github.com>

> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
> 
> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
> 
> Before (no AVX512)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
> 
> After (with AVX2)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
> 
> 
> Before (with AVX512):
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        102...

Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:

 - whitespace
 - prettify test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23719/files
  - new: https://git.openjdk.org/jdk/pull/23719/files/56fd168d..a7f756af

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

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

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

From vpaprotski at openjdk.org  Mon Mar 24 17:29:08 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Mon, 24 Mar 2025 17:29:08 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v4]
In-Reply-To: <7RbzyVMGDjIExr2AfjOVElXXrKIlddltIo6vPH0yxQs=.7296744e-29f1-4e72-a44d-ce8875be6644@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <Kh8SpRwll-vnuc71PemfIOkJBWGM_wp6hkZkjr4NxDo=.837fc87d-0810-4edd-b0ab-a97376660a2e@github.com>
 <X7zT-DxVzyhXInXudD3F5OYXMwUGQQ1mUrEPNPqZCkY=.15e0bfcd-26e6-4c0b-90ac-67f632ed81ec@github.com>
 <W26HBW3Wj-oke-vXimRbaWxBvn0cP66GQ1PRNrtnnzI=.cb058a5d-43cb-479e-9766-0202e7f98cfb@github.com>
 <PUMkpytKKZX84tzpJoB4zFLt4pZXtTI8cQoP8li_f2s=.2112b3f5-9f65-471c-a5df-cf916aab44aa@github.com>
 <YIM93h8UBE4aJsRyvc_71XUD-8IrhwB1G9ELQLHr0JA=.cf7e94ec-b777-4b25-aaa6-2183ec892188@github.com>
 <7RbzyVMGDjIExr2AfjOVElXXrKIlddltIo6vPH0yxQs=.7296744e-29f1-4e72-a44d-ce8875be6644@github.com>
Message-ID: <JbTe2_AWVD4daa6xVRxQ9Lo_iZNmKaQYh4OIIc3itXw=.85769191-0071-4b71-909c-f69bc09381d6@github.com>

On Thu, 20 Mar 2025 17:34:53 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> I used it this testcase for development (and figured I should also check it in..) so what might be 'obvious' to me, might not be for anyone else?
>> 
>> Typically, when a test failed, I grabbed the SEED from the test output, reran the test with that seed fixed and I went to the exception and printed the hex values of the inputs; (then debug from there. Typically, I would write another test, so I could GDB into the intrinsic, with just those input values). 
>> 
>> It was pretty much always the case always that once I got the inputs, I could reproduce the error i.e. not a type of bug that happens silently then discovered somewhere else. Luckily. All this crypto code is constant-time -no-branches-; so the 'test coverage' here is not 'all-branches-taken' but really 'did you remember to collect all the carries'. like 53-bit limb needs to be propagated back down to 52. Thats what the test here is 'searching' for, some input that could trip up computation.
>
> Can you add a comment to the test code about how you use the seed to reproduce any failures?  So that in the future, someone who doesn't know will now have an idea how to start debugging this.

(was having fun reviewing MLDSA, getting back to this one..) just added some comments and hopefully better test error messages. Let me know if that works @ascarpino ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2010632985

From valeriep at openjdk.org  Mon Mar 24 21:02:12 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 24 Mar 2025 21:02:12 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings
In-Reply-To: <fq4159DVTAlqvt68sc1oQm835p7CCXymdhSSqTfwDzQ=.38bc3de8-89f6-4adf-988c-d288ba66f6de@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
 <fq4159DVTAlqvt68sc1oQm835p7CCXymdhSSqTfwDzQ=.38bc3de8-89f6-4adf-988c-d288ba66f6de@github.com>
Message-ID: <l7z7cSc2UTT-HLuz9n3o42fK0DGDPRmvgNh40YxMc90=.efed7e2a-8e61-46ae-82c8-b798291e908a@github.com>

On Tue, 18 Mar 2025 23:35:45 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

> Hi @valeriepeng, I found code assuming `com.sun.crypto.provider.PBEKey` contains only ASCII, please find my suggestions in the review comments. I also added a suggestion for the tests, in order to increase the coverage in that regard.
> 
> All the patches are verified to cleanly apply on top of this PR branch, when copied through the GitHub's copy button and applied with `xclip -sel clip | git apply`.

Great, thanks for catching this!

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

PR Comment: https://git.openjdk.org/jdk/pull/24068#issuecomment-2749382215

From ascarpino at openjdk.org  Mon Mar 24 21:42:21 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 24 Mar 2025 21:42:21 GMT
Subject: RFR: 8298420: PEM API: Implementation (Preview) [v12]
In-Reply-To: <6rZyx-jI2LBg072eM-gPsbmDwfPzWqbQiAl8rsSAFqo=.aa125765-7cb6-484d-9222-dc3b0287e050@github.com>
References: <pzQ-OBSQL7n5SbuQwbh6ouivfEKRbfL3pkHN6u1AGZU=.2863ee52-93dc-4530-b4dd-438a88f9699a@github.com>
 <F50v4De5vyjBga2epwVOXSiO_fXhUbtzAkE3ZUcNe7Q=.2bee851c-12f6-4208-a2b2-59a756be9c39@github.com>
 <6rZyx-jI2LBg072eM-gPsbmDwfPzWqbQiAl8rsSAFqo=.aa125765-7cb6-484d-9222-dc3b0287e050@github.com>
Message-ID: <p0ZS7ZldlJCPl36kaE2Vfm7O-4JyVnneaIa5uIcDS7Y=.db10a9e2-32a5-4edd-89d1-224a40d76e33@github.com>

On Wed, 12 Mar 2025 20:44:30 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits:
>> 
>>  - Merge branch 'pem-merge' into pem
>>  - merge
>>  - Merge in PEMRecord as part of the API.
>>  - Merge branch 'pem-record' into pem-merge
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/security/PEMDecoder.java
>>    #	src/java.base/share/classes/java/security/PEMRecord.java
>>    #	src/java.base/share/classes/sun/security/util/Pem.java
>>    #	test/jdk/java/security/PEM/PEMData.java
>>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>>  - Merge branch 'master' into pem-record
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>>  - test fixes & cleanup
>>  - Implement stream decoding
>>    fix StringBuffer/Builder
>>    X509C* changes
>>  - Reorg tests data
>>    minor fixes
>>  - merge from pem branch
>>  - Merge branch 'pem' into pem-record
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/security/PEMEncoder.java
>>    #	src/java.base/share/classes/sun/security/provider/X509Factory.java
>>    #	src/java.base/share/classes/sun/security/util/Pem.java
>>    #	test/jdk/java/security/PEM/PEMDecoderTest.java
>>    #	test/jdk/java/security/PEM/PEMEncoderTest.java
>>  - ... and 48 more: https://git.openjdk.org/jdk/compare/22845a77...cc952c0b
>
> src/java.base/share/classes/java/security/PEMRecord.java line 53:
> 
>> 51:  * instantiation of this record.
>> 52:  *
>> 53:  * @param type The type identifier in the PEM header.  For a public key,
> 
> Since there are specific strings that will be needed in the `type` field, is there a pointer we could add so folks looking at this could see what values might be acceptable for this field.  I don't know if right here is the right place for it, but maybe a see-also or something?  Or is this left open-ended to support whatever could exist in a PEM header?

As `PEMRecord` is a generic object containing PEM formatted data, the `type` field (aka header/footer) does not have any checking.   PEM data that have cryptographic objects in the Java API will by default decoded to those.  Any other header will returned as a `PEMRecord`.   A PEM header type not in the specification could be use with a `PEMRecord` for encoding or decoding, but I don't see that as a problem.  Putting in restrictions doesn't make the API any better or usable given it is a generic "catch-all" object.

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

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

From valeriep at openjdk.org  Mon Mar 24 23:32:07 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 24 Mar 2025 23:32:07 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings
In-Reply-To: <fq4159DVTAlqvt68sc1oQm835p7CCXymdhSSqTfwDzQ=.38bc3de8-89f6-4adf-988c-d288ba66f6de@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
 <fq4159DVTAlqvt68sc1oQm835p7CCXymdhSSqTfwDzQ=.38bc3de8-89f6-4adf-988c-d288ba66f6de@github.com>
Message-ID: <QjdqJikzNFMM6DM8dgGu4fz2GqHgk2z0DRr_syQAscU=.63dec169-f2e8-420f-9c6f-b8d838d7b77e@github.com>

On Tue, 18 Mar 2025 23:15:13 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings.
>> 
>> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility.
>
> test/jdk/sun/security/pkcs11/Cipher/PBECipher.java line 1:
> 
>> 1: /*
> 
> I suggest changing this test's password to contain non-ASCII characters, so we have a better coverage in both _SunJCE_ (when checking the assertion data) and _SunPKCS11_ (when doing the actual test):
> 
> diff --git a/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java b/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
> index b12cb5c2687..93ef097933f 100644
> --- a/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
> +++ b/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2023, Red Hat, Inc.
> + * Copyright (c) 2023, 2025, Red Hat, Inc.
>   *
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
> @@ -47,7 +47,7 @@
>   */
>  
>  public final class PBECipher extends PKCS11Test {
> -    private static final char[] password = "123456".toCharArray();
> +    private static final char[] password = "123456\uA4F7".toCharArray();
>      private static final byte[] salt = "abcdefgh".getBytes(
>              StandardCharsets.UTF_8);
>      private static final int iterations = 1000;
> @@ -112,35 +112,35 @@ private static void checkAssertionValues(BigInteger expectedValue,
>      // Generated with SunJCE.
>      private static final AssertionData[] assertionData = new AssertionData[]{
>              cipherAssertionData("PBEWithHmacSHA1AndAES_128",
> -                    "AES/CBC/PKCS5Padding", "ba1c9614d550912925d99e0bc8969032" +
> -                    "7ac6258b72117dcf750c19ee6ca73dd4"),
> +                    "AES/CBC/PKCS5Padding", "9e097796e8d8224f2a7f5c950677d879" +
> +                    "c0c578340147c7ae357550e2f4d4c6ce"),
>              cipherAssertionData("PBEWithHmacSHA224AndAES_128",
> -                    "AES/CBC/PKCS5Padding", "41960c43ca99cf2184511aaf2f0508a9" +
> -                    "7da3762ee6c2b7e2027c8076811f2e52"),
> +                    "AES/CBC/PKCS5Padding", "7b915941d8e3a87c00e2fbd8ad67a578" +
> +                    "9a25648933b737706de4e4d48bdb61b6"),
>              cipherAssertionData("PBEWithHmacSHA256AndAES_128",
> -                    "AES/CBC/PKCS5Padding", "6bb6a3dc3834e81e5ca6b5e70073ff46" +
> -                    "903b188940a269ed26db2ffe622b8e16"),
> +                    "AES/CBC/PKCS5Padding", "c23912d15599908f47cc32c9da56b37f" +
> +                    "e41e958e9c3a6c6e4e631a2a9e6cd20f"),
>              cipherAssertionData("PBEWithHmacSHA384AndAES_128",
> -                    "AES/CBC/PKCS5Padding", "22aabf7a6a059415dc4ca7d985f3de06" +
> -                    "8f8300ca48d8de585d8026...

Sure, I can do this. Thanks for the suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2011057913

From valeriep at openjdk.org  Tue Mar 25 00:14:08 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 25 Mar 2025 00:14:08 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings
In-Reply-To: <A8prcUa1EUnx-CaopUsPfnEhfa7u3x-WWY7h5C5UTz0=.d6f0b2d5-6d00-409b-ac7e-0dc68295af28@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
 <fq4159DVTAlqvt68sc1oQm835p7CCXymdhSSqTfwDzQ=.38bc3de8-89f6-4adf-988c-d288ba66f6de@github.com>
 <A8prcUa1EUnx-CaopUsPfnEhfa7u3x-WWY7h5C5UTz0=.d6f0b2d5-6d00-409b-ac7e-0dc68295af28@github.com>
Message-ID: <JDh8IHGdzQcUQhtvxGyiVP0xkY8h9UwAt8uy9YscRwQ=.f829104c-cfdf-4cc3-9251-e821174cedb7@github.com>

On Wed, 19 Mar 2025 17:39:39 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs11/Mac/PBAMac.java line 1:
>> 
>>> 1: /*
>> 
>> I suggest changing this test's password to contain non-ASCII characters, so we have a better coverage in both _SunJCE_ (when checking the assertion data) and _SunPKCS11_ (when doing the actual test):
>> 
>> diff --git a/test/jdk/sun/security/pkcs11/Mac/PBAMac.java b/test/jdk/sun/security/pkcs11/Mac/PBAMac.java
>> index b70a0a6d618..0baf85bb5de 100644
>> --- a/test/jdk/sun/security/pkcs11/Mac/PBAMac.java
>> +++ b/test/jdk/sun/security/pkcs11/Mac/PBAMac.java
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2023, Red Hat, Inc.
>> + * Copyright (c) 2023, 2025, Red Hat, Inc.
>>   *
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>> @@ -44,7 +44,7 @@
>>   */
>>  
>>  public final class PBAMac extends PKCS11Test {
>> -    private static final char[] password = "123456".toCharArray();
>> +    private static final char[] password = "123456\uA4F7".toCharArray();
>>      private static final byte[] salt = "abcdefgh".getBytes(
>>              StandardCharsets.UTF_8);
>>      private static final int iterations = 1000;
>> @@ -102,19 +102,19 @@ private static void checkAssertionValues(BigInteger expectedValue,
>>      // Generated with SunJCE.
>>      private static final AssertionData[] assertionData = new AssertionData[]{
>>              macAssertionData("HmacPBESHA1", "HmacSHA1",
>> -                    "707606929395e4297adc63d520ac7d22f3f5fa66"),
>> +                    "8611414ddb1875d9f576282199ab492a802b7d49"),
>>              macAssertionData("HmacPBESHA224", "HmacSHA224",
>> -                    "4ffb5ad4974a7a9fca5a36ebe3e34dd443c07fb68c392f8b611657e6"),
>> +                    "cebb12b48eb90c07336c695f771d1d0ef4ccf5b9524fc0ab6fb9813a"),
>>              macAssertionData("HmacPBESHA256", "HmacSHA256",
>> -                    "9e8c102c212d2fd1334dc497acb4e002b04e84713b7eda5a63807af2" +
>> -                    "989d3e50"),
>> +                    "d83a6a4e8b0e1ec939d05790f385dd774bd2b7c17cfa2dd004efc894" +
>> +                    "e5d53f51"),
>>              macAssertionData("HmacPBESHA384", "HmacSHA384",
>> -                    "77f31a785d4f2220251143a4ba80f5610d9d0aeaebb4a278b8a7535c" +
>> -                    "8cea8e8211809ba450458e351c5b66d691839c23"),
>> +                    "ae6b69cf9edfd9cd8c3b51cdf2b0243502f35a3e6007f33b1ab73568" +
>> +                    "2ea81ea562f4383bb9512ff70752367b7259b16f"),
>>              macAssertionData("HmacPBESHA512", "HmacSHA512",
>> -                    "a53f942a844b2...
>
> Even when the suggested `PBECipher` and `PBAMac` test changes would improve the confidence, validating _SunJCE_ against _SunPKCS11_ and viceversa is not a completely independent test, specially given both providers share some common code in `PBEUtil`. For this reason, I've just also did the following cross-check with OpenSSL:
> 
> 
> # Non-ASCII password
> password='Th1s is a Bullet: ?'
> 
> # Create a PKCS #12 keystore with a certificate and a key pair
> openssl req -x509 -nodes -newkey rsa:4096 -subj /C=TT/ST=TT/L=TT/O=Test/CN=test.com/ -keyout key.pem -out cert.pem
> openssl pkcs12 -export -inkey key.pem -in cert.pem -passout "pass:$password" -out ks.p12
> 
> # Read the keystore with keytool
> build/*/images/jdk/bin/keytool -v -list -storetype pkcs12 -keystore ks.p12 -storepass "$password"
> 
> # Cleanup
> unset password && rm -f key.pem cert.pem ks.p12
> 
> 
> <details>
> <summary><code>keytool</code> output from JDK 23:</summary>
> 
> 
> keytool error: java.io.IOException: keystore password was incorrect
> java.io.IOException: keystore password was incorrect
> 	at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2112)
> 	at java.base/sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:228)
> 	at java.base/java.security.KeyStore.load(KeyStore.java:1499)
> 	at java.base/sun.security.tools.keytool.Main.doCommands(Main.java:961)
> 	at java.base/sun.security.tools.keytool.Main.run(Main.java:429)
> 	at java.base/sun.security.tools.keytool.Main.main(Main.java:410)
> Caused by: java.security.UnrecoverableKeyException: failed to decrypt safe contents entry: java.io.IOException: getSecretKey failed: Password is not ASCII
> 	... 6 more
> 
> </details>
> 
> <details>
> <summary><code>keytool</code> output from a build of this PR's branch:</summary>
> 
> 
> keytool error: java.io.IOException: keystore password was incorrect
> java.io.IOException: keystore password was incorrect
> 	at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2109)
> 	at java.base/sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:226)
> 	at java.base/java.security.KeyStore.load(KeyStore.java:1502)
> 	at java.base/sun.security.tools.keytool.Main.doCommands(Main.java:951)
> 	at java.base/sun.security.tools.keytool.Main.run(Main.java:419)
> 	at java.base/sun.security.tools.keytool.Main.main(Main.java:400)
> Caused by: java.security.UnrecoverableKeyException: failed to decrypt safe contents entry: javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a...

Sure, thanks for crosschecking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2011087253

From valeriep at openjdk.org  Tue Mar 25 00:22:23 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 25 Mar 2025 00:22:23 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings [v2]
In-Reply-To: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
Message-ID: <UxocAgqJQGs3ZFEl1WZU2kOE9lIMfEY1_QoHPK2peVw=.916b50b6-6376-4b90-8d65-73dd6d90a35d@github.com>

> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings.
> 
> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility.

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

  apply the suggested changes and minor code refactoring.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24068/files
  - new: https://git.openjdk.org/jdk/pull/24068/files/df83f4e9..13a3f932

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

  Stats: 110 lines in 5 files changed: 30 ins; 31 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/24068.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24068/head:pull/24068

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

From myankelevich at openjdk.org  Tue Mar 25 12:02:16 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 25 Mar 2025 12:02:16 GMT
Subject: RFR: 8352509: Update jdk.test.lib.SecurityTools jar method to accept
 List<String> parameter
Message-ID: <sdQn3-o5tgpTr1bsi7C-RYxsCUpVTpsD-GNZ1jH7Bko=.0c10a7fa-1668-40ff-b03b-62c20a18cdb6@github.com>

Updating `jdk.test.lib.SecurityTools` class to have jar method accept `List<String>` parameter similar to `keytool` methods.
Currently this only accept String parameter, which is error prone with missing space

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

Commit messages:
 - Update jdk.test.lib.SecurityTools jar method to accept List<String> parameter

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

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

From lkorinth at openjdk.org  Tue Mar 25 12:07:16 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 25 Mar 2025 12:07:16 GMT
Subject: RFR: 8352719: Add an equals sign to the modules statement
In-Reply-To: <pTjb3jJfHka0wnUf8tiWrTMTh2hgA_3ra3qXVp8s2Tc=.18bae820-399e-4d7e-ba87-3ff1bed38dab@github.com>
References: <zYDJXf6284TfYq62lzdb7804PbHnaH1t2il22GEJ5B0=.6082d470-a0d6-49ee-afc8-ff150d165907@github.com>
 <pTjb3jJfHka0wnUf8tiWrTMTh2hgA_3ra3qXVp8s2Tc=.18bae820-399e-4d7e-ba87-3ff1bed38dab@github.com>
Message-ID: <fW4DrPKAbuA0OCqQY6wVHUwii9-M7ZW39drkjkEjCuo=.324e53ca-8a74-4b0e-a6e8-a1f900d11f05@github.com>

On Mon, 24 Mar 2025 14:17:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> The bug issue needs a `noreg-self` label.

Fixed

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

PR Comment: https://git.openjdk.org/jdk/pull/24194#issuecomment-2751038421

From weijun at openjdk.org  Tue Mar 25 13:04:13 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Mar 2025 13:04:13 GMT
Subject: RFR: 8352509: Update jdk.test.lib.SecurityTools jar method to
 accept List<String> parameter [v2]
In-Reply-To: <KhKa3ywt5WppXLo8kgiMGYZQ_Rk2ydXBr35Wbi90hPk=.e4b9dc73-105d-412c-bf1b-fd22e556ea13@github.com>
References: <sdQn3-o5tgpTr1bsi7C-RYxsCUpVTpsD-GNZ1jH7Bko=.0c10a7fa-1668-40ff-b03b-62c20a18cdb6@github.com>
 <KhKa3ywt5WppXLo8kgiMGYZQ_Rk2ydXBr35Wbi90hPk=.e4b9dc73-105d-412c-bf1b-fd22e556ea13@github.com>
Message-ID: <Kk31Vkop3w2-uCmpKOoxd4QXThWjsTfpNJJ8jUQPYQY=.d5cde2ea-9268-4a21-97bd-4fdafa603bc0@github.com>

On Tue, 25 Mar 2025 13:00:44 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Updating `jdk.test.lib.SecurityTools` class to have jar method accept `List<String>` parameter similar to `keytool` methods.
>> Currently this only accept String parameter, which is error prone with missing space
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cpyright year update

LGTM.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24225#pullrequestreview-2713646782

From duke at openjdk.org  Tue Mar 25 13:04:13 2025
From: duke at openjdk.org (duke)
Date: Tue, 25 Mar 2025 13:04:13 GMT
Subject: RFR: 8352509: Update jdk.test.lib.SecurityTools jar method to
 accept List<String> parameter [v2]
In-Reply-To: <KhKa3ywt5WppXLo8kgiMGYZQ_Rk2ydXBr35Wbi90hPk=.e4b9dc73-105d-412c-bf1b-fd22e556ea13@github.com>
References: <sdQn3-o5tgpTr1bsi7C-RYxsCUpVTpsD-GNZ1jH7Bko=.0c10a7fa-1668-40ff-b03b-62c20a18cdb6@github.com>
 <KhKa3ywt5WppXLo8kgiMGYZQ_Rk2ydXBr35Wbi90hPk=.e4b9dc73-105d-412c-bf1b-fd22e556ea13@github.com>
Message-ID: <rFwWoIqmsNdiDKmSC9jlou3yt7tueKDkx3vcytFhwW0=.57da51f8-b2f5-4c57-a40f-146f111a6e0d@github.com>

On Tue, 25 Mar 2025 13:00:44 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Updating `jdk.test.lib.SecurityTools` class to have jar method accept `List<String>` parameter similar to `keytool` methods.
>> Currently this only accept String parameter, which is error prone with missing space
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cpyright year update

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

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

PR Comment: https://git.openjdk.org/jdk/pull/24225#issuecomment-2751187851

From myankelevich at openjdk.org  Tue Mar 25 13:07:22 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 25 Mar 2025 13:07:22 GMT
Subject: Integrated: 8352509: Update jdk.test.lib.SecurityTools jar method to
 accept List<String> parameter
In-Reply-To: <sdQn3-o5tgpTr1bsi7C-RYxsCUpVTpsD-GNZ1jH7Bko=.0c10a7fa-1668-40ff-b03b-62c20a18cdb6@github.com>
References: <sdQn3-o5tgpTr1bsi7C-RYxsCUpVTpsD-GNZ1jH7Bko=.0c10a7fa-1668-40ff-b03b-62c20a18cdb6@github.com>
Message-ID: <Gi238B8UUCfltubgC2k-IEFoMgN6p5RTqOm-cA0G8Cc=.b931960f-8282-4264-a051-da6a0d8ffb6e@github.com>

On Tue, 25 Mar 2025 11:56:37 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Updating `jdk.test.lib.SecurityTools` class to have jar method accept `List<String>` parameter similar to `keytool` methods.
> Currently this only accept String parameter, which is error prone with missing space

This pull request has now been integrated.

Changeset: fa0b18bf
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c
Stats:     26 lines in 1 file changed: 23 ins; 0 del; 3 mod

8352509: Update jdk.test.lib.SecurityTools jar method to accept List<String> parameter

Reviewed-by: weijun

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

PR: https://git.openjdk.org/jdk/pull/24225

From weijun at openjdk.org  Tue Mar 25 14:01:24 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Mar 2025 14:01:24 GMT
Subject: RFR: 8325513: Export method for Cipher [v4]
In-Reply-To: <BwloSiI6cpATvQIc-BrAjeQ2ciooWABjZqSmhbFzpnk=.d960f6e7-6836-4a52-93a8-1905c57585a5@github.com>
References: <BwloSiI6cpATvQIc-BrAjeQ2ciooWABjZqSmhbFzpnk=.d960f6e7-6836-4a52-93a8-1905c57585a5@github.com>
Message-ID: <cxhNqdx3f5ADph8A39JmLRSX8v3B-IJMWzPYQVyg2XY=.8730e032-07e5-40da-b2c0-78c2c732836a@github.com>

> Add `Cipher::export` 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 14 additional commits since the last revision:

 - plural
 - Merge branch 'master' into 8325513
 - small update
 - Merge branch 'master' into 8325513
 - change new method to non final
 - rename
 - Merge branch 'master' into 8325513
 - make test work
 - Add test
 - Wording
 - ... and 4 more: https://git.openjdk.org/jdk/compare/aa7dccb2...11701dce

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18409/files
  - new: https://git.openjdk.org/jdk/pull/18409/files/bbd97a30..11701dce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18409&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18409&range=02-03

  Stats: 1380673 lines in 17253 files changed: 849599 ins; 410568 del; 120506 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  Tue Mar 25 14:34:28 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 25 Mar 2025 14:34:28 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint
Message-ID: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>

We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.

-------------

Commit messages:
 - 8352277: java.security documentation: incorrect regex syntax describing "usage" algorithm constraint

Changes: https://git.openjdk.org/jdk/pull/24231/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24231&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352277
  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24231/head:pull/24231

PR: https://git.openjdk.org/jdk/pull/24231

From hchao at openjdk.org  Tue Mar 25 15:41:14 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 25 Mar 2025 15:41:14 GMT
Subject: RFR: 8350705: [JMH] test security.SSLHandshake failed for 2
 threads configuration
In-Reply-To: <YmF22vfQt_zYD732jZzvqafBeCAcRQT8ePY1zXjtncw=.c8d46707-4cc0-4ff0-bca5-55cc51e7352f@github.com>
References: <YmF22vfQt_zYD732jZzvqafBeCAcRQT8ePY1zXjtncw=.c8d46707-4cc0-4ff0-bca5-55cc51e7352f@github.com>
Message-ID: <1RpDvTY_v21orweF8PU6KJ7ce9IaqQ4pr6fM2vrbsow=.ef1b7d76-5a0d-4e64-98c1-3372bd5bf275@github.com>

On Mon, 24 Mar 2025 12:54:01 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Update the SSLHandshake benchmark to enable running in multiple threads.
> 
> This PR changes the scope of the state from per-benchmark to per-thread. The server SSLContext is still shared across all threads to simulate the scenario where multiple clients try to connect to the same server at the same time.
> 
> Before the change, running this benchmark with `make test TEST=micro:SSLHandshake MICRO=OPTIONS="-t 3"` failed with an exception. After this change the benchmark completes successfully.

Changes look good.

-------------

Marked as reviewed by hchao (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24195#pullrequestreview-2714260936

From abarashev at openjdk.org  Tue Mar 25 16:32:24 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 25 Mar 2025 16:32:24 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v6]
In-Reply-To: <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>
Message-ID: <PlzMMotioxuA5fNygKbBlePoNEGfXshbypThjJKstA4=.824904c6-3884-43c2-84af-b009261b2ade@github.com>

On Fri, 21 Mar 2025 20:36:47 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments on test

test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 143:

> 141:                 throw new AssertionError("failed.  Expected " +
> 142:                     tc.expected);
> 143:             }

I suggest replacing this check with `assertEquals`.

test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 165:

> 163:                 throw new AssertionError("failed.  Expected " +
> 164:                     tc.expected);
> 165:             }

Same as above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2012489410
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2012489790

From ascarpino at openjdk.org  Tue Mar 25 16:36:30 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Mar 2025 16:36:30 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v6]
In-Reply-To: <PlzMMotioxuA5fNygKbBlePoNEGfXshbypThjJKstA4=.824904c6-3884-43c2-84af-b009261b2ade@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>
 <PlzMMotioxuA5fNygKbBlePoNEGfXshbypThjJKstA4=.824904c6-3884-43c2-84af-b009261b2ade@github.com>
Message-ID: <cJSWt2oEVAMuUcajI-EWefh0OUo_RXjOfHgnh-LZ2aM=.2bacf685-f8f8-4b08-8473-13339a79ce69@github.com>

On Tue, 25 Mar 2025 16:28:35 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments on test
>
> test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 143:
> 
>> 141:                 throw new AssertionError("failed.  Expected " +
>> 142:                     tc.expected);
>> 143:             }
> 
> I suggest replacing this check with `assertEquals`.

If I did that, then I couldn't println to stdout.  I'd rather keep it as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2012498792

From ascarpino at openjdk.org  Tue Mar 25 16:40:24 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Mar 2025 16:40:24 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v18]
In-Reply-To: <wEgdv31nl551jx_ot0wFUKEyMlhCpbDg7olo2PMwQiU=.679cf5bb-1741-41b4-aa1d-f697948d6af3@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <zUoxBXod_s3yFsu2BObVUUkjohsXfxucv59Li6BkX6M=.c041e8fc-6bcb-4a1f-9d40-a3b92a155daf@github.com>
 <vt5cqMIBE3s6FKZzlSENKv4f6mjNbhA0wVjreveFmcQ=.8d1796ee-3561-4595-8aee-3f4d06298084@github.com>
 <wEgdv31nl551jx_ot0wFUKEyMlhCpbDg7olo2PMwQiU=.679cf5bb-1741-41b4-aa1d-f697948d6af3@github.com>
Message-ID: <RFa5-SimT-ZyHtkFX6Dzx_orBIwnPfsOzzPkx0k2aAc=.8bfdcb05-b44b-426e-9ce5-e5c0875f64a4@github.com>

On Wed, 19 Mar 2025 19:23:56 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.
>> 
>> Since this is a new file, it only needs 2025
>
> Most of this file's content was copied from `SigSchemePropOrdering`, so we keep the original start year.

Copying the code from a different file doesn't matter for the copyright date. It is based on when the file was created and edited

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2012504460

From duke at openjdk.org  Tue Mar 25 17:17:42 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 25 Mar 2025 17:17:42 GMT
Subject: RFR: 8351366: Remove the java.security.debug=scl option
Message-ID: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>

This option dumped the permissions that the SecureClassLoader assigns to ProtectionDomains, but with the disabling of the Security Manager in JDK 24, these permissions are always empty and the debugging has no value. So this option should be removed.

-------------

Commit messages:
 - 8351366:Remove the java.security.debug=scl option
 - 8351366: Remove the java.security.debug=scl option

Changes: https://git.openjdk.org/jdk/pull/24208/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24208&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351366
  Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24208/head:pull/24208

PR: https://git.openjdk.org/jdk/pull/24208

From ascarpino at openjdk.org  Tue Mar 25 17:51:15 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Mar 2025 17:51:15 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
Message-ID: <L6gSbU2C3Qb3JEkDC-2n0BS6PUdcbSVd5FNYe6YEbwU=.ab10f989-598d-4b5a-aa1c-d29ee610a444@github.com>

On Mon, 24 Mar 2025 17:24:01 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix java.security syntax. Remove whitespace.

Marked as reviewed by ascarpino (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23681#pullrequestreview-2714658895

From ascarpino at openjdk.org  Tue Mar 25 17:51:27 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Mar 2025 17:51:27 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint
In-Reply-To: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
Message-ID: <wL3r-OEPQgybQG-OJDaEvK6tC7EGM4Mek7qKP7K-Qi8=.a7e4ec02-465c-48a1-b220-af040a0bd609@github.com>

On Tue, 25 Mar 2025 14:29:22 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.

looks good

-------------

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24231#pullrequestreview-2714659830

From hchao at openjdk.org  Tue Mar 25 18:54:16 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 25 Mar 2025 18:54:16 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint
In-Reply-To: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
Message-ID: <KiCW_yM5xJ-HDM6omXEudzeQAmrM-RrbwoFGkcbmPJY=.3d5adb69-9d38-4292-bafe-f520e18ab24a@github.com>

On Tue, 25 Mar 2025 14:29:22 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.

src/java.base/share/conf/security/java.security line 541:

> 539: #
> 540: #   UsageType:
> 541: #       ([TLSServer] | [TLSClient] | [SignedJAR])

It looks like we list the alternatives without brackets, for example Constraint at line #518 as:

 518 #   Constraint:
 519 #       KeySizeConstraint | CAConstraint | DenyAfterConstraint |
 520 #       UsageConstraint

 Would you consider to remove the brackets here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24231#discussion_r2012751426

From abarashev at openjdk.org  Tue Mar 25 19:25:12 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 25 Mar 2025 19:25:12 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint
In-Reply-To: <KiCW_yM5xJ-HDM6omXEudzeQAmrM-RrbwoFGkcbmPJY=.3d5adb69-9d38-4292-bafe-f520e18ab24a@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
 <KiCW_yM5xJ-HDM6omXEudzeQAmrM-RrbwoFGkcbmPJY=.3d5adb69-9d38-4292-bafe-f520e18ab24a@github.com>
Message-ID: <H_MJIloPRAr7imOqTh1cMgSFeeML2dH4fhgC36NGO_M=.fe2e9300-dfc3-4335-af41-dca90aa4addc@github.com>

On Tue, 25 Mar 2025 18:51:36 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.
>
> src/java.base/share/conf/security/java.security line 541:
> 
>> 539: #
>> 540: #   UsageType:
>> 541: #       ([TLSServer] | [TLSClient] | [SignedJAR])
> 
> It looks like we list the alternatives without brackets, for example Constraint at line #518 as:
> 
>  518 #   Constraint:
>  519 #       KeySizeConstraint | CAConstraint | DenyAfterConstraint |
>  520 #       UsageConstraint
> 
>  Would you consider to remove the brackets here?

Yes, it's inconsistent with the rest of the file actually. I'll check which version is semantically correct and make changes. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24231#discussion_r2012798596

From weijun at openjdk.org  Tue Mar 25 19:44:14 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Mar 2025 19:44:14 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v6]
In-Reply-To: <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>
Message-ID: <4EJcJL_dQX3J-utaSiDBPP749TSdp3hdGai2nKfuDnM=.44a05b73-be95-42a8-8528-b9b1d2ca692c@github.com>

On Fri, 21 Mar 2025 20:36:47 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments on test

src/java.base/share/classes/sun/security/util/KeyUtil.java line 183:

> 181:      * DisabledAlgorithmConstraints (DAC), this distinction is important.
> 182:      * "EdDSA" means all curves for DAC, but when using it with
> 183:      * KeyPairGenerator, "EdDSA" means "Ed25519".

Maybe just say this allows more precise check for DAC. For `KeyPairGenerator`, "EdDSA" by default means "Ed25519", but you can always call `init(NamedParameterSpec.ED448)` to change it.

test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 8:

> 6:  * under the terms of the GNU General Public License version 2 only, as
> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided

The copyright notice for a test does not need the "Classpath" exception.

test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 173:

> 171:     record TestCase(int testType, String testAlgo, boolean expected) {
> 172:         TestCase(String testAlgo, boolean expected) {
> 173:             this( 0, testAlgo, expected);

Remove the space before '0'.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2012820050
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2012807533
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2012810741

From hchao at openjdk.org  Tue Mar 25 19:51:06 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 25 Mar 2025 19:51:06 GMT
Subject: RFR: 8351366: Remove the java.security.debug=scl option
In-Reply-To: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
References: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
Message-ID: <1jo5w_5Nu1RNp7ttO1VVTVGYp4ld-TvzZ0q3uH3o_3A=.ccdc0a16-6765-450d-81a7-c32538eaeb64@github.com>

On Mon, 24 Mar 2025 22:02:59 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> This option dumped the permissions that the SecureClassLoader assigns to ProtectionDomains, but with the disabling of the Security Manager in JDK 24, these permissions are always empty and the debugging has no value. So this option should be removed.

nit: copyright year update in both files.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24208#pullrequestreview-2715006361

From mullan at openjdk.org  Tue Mar 25 20:09:09 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 25 Mar 2025 20:09:09 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v13]
In-Reply-To: <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
Message-ID: <Nr3Np4nomG45gRIWRoRQGsAZYOMByFO-lv05FP2UZQk=.c5807327-d768-4ddc-b7f1-abf5ce856c25@github.com>

On Fri, 21 Mar 2025 19:23:59 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test with more ZipEntry in the jar

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 214:

> 212: manifest.attribute.1.present.when.reading.jarfile.but.missing.via.jarinputstream=Manifest attribute %s is present when reading via JarFile but missing when reading via JarInputStream
> 213: manifest.attribute.1.present.when.reading.jarinputstream.but.missing.via.jarfile=Manifest attribute %s is present when reading via JarInputStream but missing when reading via JarFile
> 214: manifest.atrribute.1.differs.jarfile.value.2.jarinputstream.value.3=Manifest attribute %1$s differs: JarFile value = %2$s, JarInputStream value = %3$s

Typo: s/atrribute/attribute/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2012857942

From mullan at openjdk.org  Tue Mar 25 20:16:09 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 25 Mar 2025 20:16:09 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v13]
In-Reply-To: <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
Message-ID: <jV3A0N2451md_VgYYXp7hXUOWEYwtnwmX4K17zNGk44=.8c6f642c-79ad-4d0f-b4ce-952ffba7ab5b@github.com>

On Fri, 21 Mar 2025 19:23:59 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test with more ZipEntry in the jar

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1158:

> 1156:                 if (cenEntry == null) {
> 1157:                     crossChkWarnings.add(String.format(rb.getString(
> 1158:                             "Entry.missing.in.JarFile.1"), entryName));

Would it be more precise to change this warning to "Entry %s is present when reading via JarInputStream but missing when reading via JarFile"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2012868024

From mullan at openjdk.org  Tue Mar 25 20:25:15 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 25 Mar 2025 20:25:15 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v13]
In-Reply-To: <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
Message-ID: <05YNIfLlj4Hx-bWZP05752dR8Zv6eVy8iUEuMFQnq_Q=.43acfb6e-c9fe-4960-86ce-324818006b44@github.com>

On Fri, 21 Mar 2025 19:23:59 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test with more ZipEntry in the jar

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1163:

> 1161: 
> 1162:                 readEntry(jis);
> 1163:                 try (InputStream cenInputStream = jarFile.getInputStream(cenEntry)) {

What if this returns null? Shouldn't you also emit a warning that the entry was read by JarInputStream but not JarFile? Also, I think `readEntry()` would throw an NPE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2012879500

From mullan at openjdk.org  Tue Mar 25 20:45:10 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 25 Mar 2025 20:45:10 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v13]
In-Reply-To: <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
Message-ID: <4tDFH8ibXDPF50C0f_0_t9L0xhG8WQMYmtesytp_V20=.64d0cc59-b997-42bb-a6d7-972b14f12999@github.com>

On Fri, 21 Mar 2025 19:23:59 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test with more ZipEntry in the jar

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1241:

> 1239:         boolean locHasSigners = locSigners != null;
> 1240: 
> 1241:         if (cenHasSigners && locHasSigners) {

So, it's ok if one entry has code signers but the other doesn't?

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1245:

> 1243:             List<CodeSigner> locSignerList = Arrays.asList(locSigners);
> 1244: 
> 1245:             if (!cenSignerList.equals(locSignerList)) {

I think you can just call `Arrays.equals()` here.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1247:

> 1245:             if (!cenSignerList.equals(locSignerList)) {
> 1246:                 crossChkWarnings.add(String.format(rb.getString(
> 1247:                         "signature.mismatch.for.entry.1.when.comparing.jarfile.and.jarinputstream"),

"Signature mismatch" is not accurate in my opinion. This is really just about the code signers. Can we change this warning to "Code signers are different for entry %s when reading from JarFile and JarInputStream".

I like the words "reading from" instead of "comparing" as it seems to better describe what the JarFile and JarInputStream APIs for and how to diagnose the issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2012894677
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2012897366
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2012904886

From ascarpino at openjdk.org  Tue Mar 25 22:30:10 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 25 Mar 2025 22:30:10 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v6]
In-Reply-To: <4EJcJL_dQX3J-utaSiDBPP749TSdp3hdGai2nKfuDnM=.44a05b73-be95-42a8-8528-b9b1d2ca692c@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>
 <4EJcJL_dQX3J-utaSiDBPP749TSdp3hdGai2nKfuDnM=.44a05b73-be95-42a8-8528-b9b1d2ca692c@github.com>
Message-ID: <KCrBnuaJ4iMyC5NAwv5C-5lCjpbElp4VcMVsvy0dHwo=.c6d0d38c-5688-4108-b3b2-c8793779edde@github.com>

On Tue, 25 Mar 2025 19:40:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments on test
>
> src/java.base/share/classes/sun/security/util/KeyUtil.java line 183:
> 
>> 181:      * DisabledAlgorithmConstraints (DAC), this distinction is important.
>> 182:      * "EdDSA" means all curves for DAC, but when using it with
>> 183:      * KeyPairGenerator, "EdDSA" means "Ed25519".
> 
> Maybe just say this allows more precise check for DAC. For `KeyPairGenerator`, "EdDSA" by default means "Ed25519", but you can always call `init(NamedParameterSpec.ED448)` to change it.

I see what your saying, but I was only explaining when EdDSA & Ed25519 can mean the same with KPG.  As this is an internal method, I wasn't trying to explaining how to generate an Ed488 key.

> test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 8:
> 
>> 6:  * under the terms of the GNU General Public License version 2 only, as
>> 7:  * published by the Free Software Foundation.  Oracle designates this
>> 8:  * particular file as subject to the "Classpath" exception as provided
> 
> The copyright notice for a test does not need the "Classpath" exception.

All these years I never noticed the test and src copyrights were different.

> test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 173:
> 
>> 171:     record TestCase(int testType, String testAlgo, boolean expected) {
>> 172:         TestCase(String testAlgo, boolean expected) {
>> 173:             this( 0, testAlgo, expected);
> 
> Remove the space before '0'.

ah.. intellij hid that from me

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2013020628
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2013021710
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2013021601

From weijun at openjdk.org  Tue Mar 25 22:35:13 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Mar 2025 22:35:13 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v6]
In-Reply-To: <KCrBnuaJ4iMyC5NAwv5C-5lCjpbElp4VcMVsvy0dHwo=.c6d0d38c-5688-4108-b3b2-c8793779edde@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>
 <4EJcJL_dQX3J-utaSiDBPP749TSdp3hdGai2nKfuDnM=.44a05b73-be95-42a8-8528-b9b1d2ca692c@github.com>
 <KCrBnuaJ4iMyC5NAwv5C-5lCjpbElp4VcMVsvy0dHwo=.c6d0d38c-5688-4108-b3b2-c8793779edde@github.com>
Message-ID: <KZfZSVoV6XtpfP07Gq2GTD4r3XvVzXE9eJU6sEKB61g=.5f5ca0c7-be35-4c77-a2d2-2d9608190d96@github.com>

On Tue, 25 Mar 2025 22:26:17 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/KeyUtil.java line 183:
>> 
>>> 181:      * DisabledAlgorithmConstraints (DAC), this distinction is important.
>>> 182:      * "EdDSA" means all curves for DAC, but when using it with
>>> 183:      * KeyPairGenerator, "EdDSA" means "Ed25519".
>> 
>> Maybe just say this allows more precise check for DAC. For `KeyPairGenerator`, "EdDSA" by default means "Ed25519", but you can always call `init(NamedParameterSpec.ED448)` to change it.
>
> I see what your saying, but I was only explaining when EdDSA & Ed25519 can mean the same with KPG.  As this is an internal method, I wasn't trying to explaining how to generate an Ed488 key.

OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2013025675

From weijun at openjdk.org  Tue Mar 25 22:40:17 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Mar 2025 22:40:17 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v6]
In-Reply-To: <KCrBnuaJ4iMyC5NAwv5C-5lCjpbElp4VcMVsvy0dHwo=.c6d0d38c-5688-4108-b3b2-c8793779edde@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>
 <4EJcJL_dQX3J-utaSiDBPP749TSdp3hdGai2nKfuDnM=.44a05b73-be95-42a8-8528-b9b1d2ca692c@github.com>
 <KCrBnuaJ4iMyC5NAwv5C-5lCjpbElp4VcMVsvy0dHwo=.c6d0d38c-5688-4108-b3b2-c8793779edde@github.com>
Message-ID: <H_Do8yl3aEPEEx6sYOjUpkT37oPvjrfZ0wF-R8pPF8E=.c84457af-132f-4b79-86cc-0506537b5301@github.com>

On Tue, 25 Mar 2025 22:27:36 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 8:
>> 
>>> 6:  * under the terms of the GNU General Public License version 2 only, as
>>> 7:  * published by the Free Software Foundation.  Oracle designates this
>>> 8:  * particular file as subject to the "Classpath" exception as provided
>> 
>> The copyright notice for a test does not need the "Classpath" exception.
>
> All these years I never noticed the test and src copyrights were different.

IANAL but the "Classpath" seems to allow you to include (or reference or link or whatever) this (or its compiled form or whatever) in your own non-GPL app. This is necessary for JDK since it is the runtime for an app. On the other hand, there is no need to make this relaxation for tests. Again, IANAL.

>> test/jdk/sun/security/util/AlgorithmConstraints/DisabledAlgorithmPermits.java line 173:
>> 
>>> 171:     record TestCase(int testType, String testAlgo, boolean expected) {
>>> 172:         TestCase(String testAlgo, boolean expected) {
>>> 173:             this( 0, testAlgo, expected);
>> 
>> Remove the space before '0'.
>
> ah.. intellij hid that from me

You let it show the arg name?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2013028124
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2013029256

From hchao at openjdk.org  Wed Mar 26 02:33:02 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 26 Mar 2025 02:33:02 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v14]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <xxPP-NVMzOHqhXb5CCnZm_FJqjQirpeYBHRuoHyyQCg=.a23f77ef-da27-40b5-861c-246e270aa1cb@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Updated with Sean's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/e70597d3..2ef9e5cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=12-13

  Stats: 31 lines in 2 files changed: 21 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

PR: https://git.openjdk.org/jdk/pull/23532

From hchao at openjdk.org  Wed Mar 26 02:33:03 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 26 Mar 2025 02:33:03 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v13]
In-Reply-To: <Nr3Np4nomG45gRIWRoRQGsAZYOMByFO-lv05FP2UZQk=.c5807327-d768-4ddc-b7f1-abf5ce856c25@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
 <Nr3Np4nomG45gRIWRoRQGsAZYOMByFO-lv05FP2UZQk=.c5807327-d768-4ddc-b7f1-abf5ce856c25@github.com>
Message-ID: <Glq_PCW2cERDURdEjIEHK_EWkBYe6W6_hCK4zutAtcw=.5e969890-0506-4ed8-8042-7d1b9e610b7c@github.com>

On Tue, 25 Mar 2025 20:06:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test with more ZipEntry in the jar
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 214:
> 
>> 212: manifest.attribute.1.present.when.reading.jarfile.but.missing.via.jarinputstream=Manifest attribute %s is present when reading via JarFile but missing when reading via JarInputStream
>> 213: manifest.attribute.1.present.when.reading.jarinputstream.but.missing.via.jarfile=Manifest attribute %s is present when reading via JarInputStream but missing when reading via JarFile
>> 214: manifest.atrribute.1.differs.jarfile.value.2.jarinputstream.value.3=Manifest attribute %1$s differs: JarFile value = %2$s, JarInputStream value = %3$s
> 
> Typo: s/atrribute/attribute/

Fixed typo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2013292938

From hchao at openjdk.org  Wed Mar 26 02:38:17 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 26 Mar 2025 02:38:17 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v13]
In-Reply-To: <jV3A0N2451md_VgYYXp7hXUOWEYwtnwmX4K17zNGk44=.8c6f642c-79ad-4d0f-b4ce-952ffba7ab5b@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <HSeR2yZWDAoJrKPQ60ShaVCbDwQLJt7_bTXUS8xc09o=.58fdf618-1d39-4e22-ad8e-0fac453510fa@github.com>
 <jV3A0N2451md_VgYYXp7hXUOWEYwtnwmX4K17zNGk44=.8c6f642c-79ad-4d0f-b4ce-952ffba7ab5b@github.com>
Message-ID: <tzwwMPLuklKI8YiS28JMQKulLv3EmDwR1Y4vGrGzkik=.c1cc79c1-6bc7-403f-887e-3329ea90d956@github.com>

On Tue, 25 Mar 2025 20:13:16 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test with more ZipEntry in the jar
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1158:
> 
>> 1156:                 if (cenEntry == null) {
>> 1157:                     crossChkWarnings.add(String.format(rb.getString(
>> 1158:                             "Entry.missing.in.JarFile.1"), entryName));
> 
> Would it be more precise to change this warning to "Entry %s is present when reading via JarInputStream but missing when reading via JarFile"?

Updated this warning as suggested.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1163:
> 
>> 1161: 
>> 1162:                 readEntry(jis);
>> 1163:                 try (InputStream cenInputStream = jarFile.getInputStream(cenEntry)) {
> 
> What if this returns null? Shouldn't you also emit a warning that the entry was read by JarInputStream but not JarFile? Also, I think `readEntry()` would throw an NPE.

Yes, added checking on `cenInputStream` to emit a warning if it is null.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1241:
> 
>> 1239:         boolean locHasSigners = locSigners != null;
>> 1240: 
>> 1241:         if (cenHasSigners && locHasSigners) {
> 
> So, it's ok if one entry has code signers but the other doesn't?

Fixed. Added the checking.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1245:
> 
>> 1243:             List<CodeSigner> locSignerList = Arrays.asList(locSigners);
>> 1244: 
>> 1245:             if (!cenSignerList.equals(locSignerList)) {
> 
> I think you can just call `Arrays.equals()` here.

Done.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1247:
> 
>> 1245:             if (!cenSignerList.equals(locSignerList)) {
>> 1246:                 crossChkWarnings.add(String.format(rb.getString(
>> 1247:                         "signature.mismatch.for.entry.1.when.comparing.jarfile.and.jarinputstream"),
> 
> "Signature mismatch" is not accurate in my opinion. This is really just about the code signers. Can we change this warning to "Code signers are different for entry %s when reading from JarFile and JarInputStream".
> 
> I like the words "reading from" instead of "comparing" as it seems to better describe what the JarFile and JarInputStream APIs for and how to diagnose the issue.

Updated this warning as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2013296602
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2013296685
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2013296741
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2013296799
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2013296907

From duke at openjdk.org  Wed Mar 26 04:22:50 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 26 Mar 2025 04:22:50 GMT
Subject: RFR: 8351366: Remove the java.security.debug=scl option [v2]
In-Reply-To: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
References: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
Message-ID: <tn-aDt7kzHgVXMH37atJoRn129od7KqmYjPpfCX5j4g=.0700fc00-b6ab-465c-a413-c813e6d1d3bb@github.com>

> This option dumped the permissions that the SecureClassLoader assigns to ProtectionDomains, but with the disabling of the Security Manager in JDK 24, these permissions are always empty and the debugging has no value. So this option should be removed.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8351366:Remove the java.security.debug=scl option

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24208/files
  - new: https://git.openjdk.org/jdk/pull/24208/files/1f32d510..2416e92b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24208&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24208&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24208/head:pull/24208

PR: https://git.openjdk.org/jdk/pull/24208

From mullan at openjdk.org  Wed Mar 26 13:05:21 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Mar 2025 13:05:21 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v14]
In-Reply-To: <xxPP-NVMzOHqhXb5CCnZm_FJqjQirpeYBHRuoHyyQCg=.a23f77ef-da27-40b5-861c-246e270aa1cb@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <xxPP-NVMzOHqhXb5CCnZm_FJqjQirpeYBHRuoHyyQCg=.a23f77ef-da27-40b5-861c-246e270aa1cb@github.com>
Message-ID: <ac-xaua6obCHei0T_EXpg4n15KkUPWsK_vZaMDLpDaw=.513b5b3c-535b-4aaa-86ff-61c045eff9cf@github.com>

On Wed, 26 Mar 2025 02:33:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with Sean's comments

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1138:

> 1136:     private void crossCheckEntries(String jarName) throws Exception {
> 1137:         List<String> locEntries = new ArrayList<>();
> 1138:         List<String> cenEntries;

You can move this declaration to where you first use it (line 1177).

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1163:

> 1161:                 }
> 1162: 
> 1163:                 readEntry(jis);

I think this method is only needed in order to get the code signers, right? If so, it can be moved to just before line 1174.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1168:

> 1166:                         crossChkWarnings.add(String.format(rb.getString(
> 1167:                                 "entry.1.present.in.jarfile.but.unreadable"),
> 1168:                                 entryName));

I think we should continue after this, since the JarInputStream entry doesn't exist, so no need to compare code signers.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 215:

> 213: manifest.attribute.1.present.when.reading.jarinputstream.but.missing.via.jarfile=Manifest attribute %s is present when reading via JarInputStream but missing when reading via JarFile
> 214: manifest.attribute.1.differs.jarfile.value.2.jarinputstream.value.3=Manifest attribute %1$s differs: JarFile value = %2$s, JarInputStream value = %3$s
> 215: Entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile=Entry %s is present when reading via JarInputStream but missing when reading via JarFile

Lower case the name ("entry.1")

(to be consistent with other property names)

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 216:

> 214: manifest.attribute.1.differs.jarfile.value.2.jarinputstream.value.3=Manifest attribute %1$s differs: JarFile value = %2$s, JarInputStream value = %3$s
> 215: Entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile=Entry %s is present when reading via JarInputStream but missing when reading via JarFile
> 216: entry.1.present.in.jarfile.but.unreadable=Entry %s is present in JarFile but unreadable

Shouldn't this be the opposite of "entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile":

"Entry %s is present when reading via JarFile but missing when reading via JarInputStream"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014049119
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014064384
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014081079
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014066571
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014072968

From weijun at openjdk.org  Wed Mar 26 14:44:11 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Mar 2025 14:44:11 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v14]
In-Reply-To: <xxPP-NVMzOHqhXb5CCnZm_FJqjQirpeYBHRuoHyyQCg=.a23f77ef-da27-40b5-861c-246e270aa1cb@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <xxPP-NVMzOHqhXb5CCnZm_FJqjQirpeYBHRuoHyyQCg=.a23f77ef-da27-40b5-861c-246e270aa1cb@github.com>
Message-ID: <QooOBFQmYRXMf01Iml4fs8Fiw1YGavdwrEJZw4vB_bM=.ed29360e-64d7-44ec-aee4-64c7664b4471@github.com>

On Wed, 26 Mar 2025 02:33:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated with Sean's comments

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1170:

> 1168:                                 entryName));
> 1169:                     } else {
> 1170:                         readEntry(cenInputStream);

This could throw a `SecurityException` if the content does not match the digest. Although we have verified the JAR file with`JarFile`, things could be different when opened with a `JarInputStream`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014335558

From mullan at openjdk.org  Wed Mar 26 14:52:22 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Mar 2025 14:52:22 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v14]
In-Reply-To: <ac-xaua6obCHei0T_EXpg4n15KkUPWsK_vZaMDLpDaw=.513b5b3c-535b-4aaa-86ff-61c045eff9cf@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <xxPP-NVMzOHqhXb5CCnZm_FJqjQirpeYBHRuoHyyQCg=.a23f77ef-da27-40b5-861c-246e270aa1cb@github.com>
 <ac-xaua6obCHei0T_EXpg4n15KkUPWsK_vZaMDLpDaw=.513b5b3c-535b-4aaa-86ff-61c045eff9cf@github.com>
Message-ID: <JEdgiQ7rcCLOwORmFswjr3azPHI7CEhEDq3A3HxbvRg=.66f35d62-3217-4d5f-8d4f-e8c3cda51fcf@github.com>

On Wed, 26 Mar 2025 12:48:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated with Sean's comments
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 216:
> 
>> 214: manifest.attribute.1.differs.jarfile.value.2.jarinputstream.value.3=Manifest attribute %1$s differs: JarFile value = %2$s, JarInputStream value = %3$s
>> 215: Entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile=Entry %s is present when reading via JarInputStream but missing when reading via JarFile
>> 216: entry.1.present.in.jarfile.but.unreadable=Entry %s is present in JarFile but unreadable
> 
> Shouldn't this be the opposite of "entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile":
> 
> "Entry %s is present when reading via JarFile but missing when reading via JarInputStream"

Actually never mind, I see that this warning is if there is an entry but no input stream. So ignore my comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2014355667

From mullan at openjdk.org  Wed Mar 26 15:28:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Mar 2025 15:28:11 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint
In-Reply-To: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
Message-ID: <aNQxxyUAePTMdhTzAiAhpbXLba9peqe9tJYkIzkwysE=.6825d444-5fec-4e7f-b223-c13a753fb7bb@github.com>

On Tue, 25 Mar 2025 14:29:22 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24231#pullrequestreview-2717675307

From ascarpino at openjdk.org  Wed Mar 26 17:49:21 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 26 Mar 2025 17:49:21 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v6]
In-Reply-To: <H_Do8yl3aEPEEx6sYOjUpkT37oPvjrfZ0wF-R8pPF8E=.c84457af-132f-4b79-86cc-0506537b5301@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <AD6AzoC-Dig3k-Sv8I_v8p37bxc3ZmRQuJNWGzvSKWo=.7dda42ed-a9c4-4f12-9c14-825dd9185f96@github.com>
 <4EJcJL_dQX3J-utaSiDBPP749TSdp3hdGai2nKfuDnM=.44a05b73-be95-42a8-8528-b9b1d2ca692c@github.com>
 <KCrBnuaJ4iMyC5NAwv5C-5lCjpbElp4VcMVsvy0dHwo=.c6d0d38c-5688-4108-b3b2-c8793779edde@github.com>
 <H_Do8yl3aEPEEx6sYOjUpkT37oPvjrfZ0wF-R8pPF8E=.c84457af-132f-4b79-86cc-0506537b5301@github.com>
Message-ID: <diQ5PkNBNZ9aZ4IzBCQpet0dR5S5zNjKh1ELrkHy0UA=.ebc1998a-dc87-4826-9271-771f543a4723@github.com>

On Tue, 25 Mar 2025 22:37:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> ah.. intellij hid that from me
>
> You let it show the arg name?

intellij put the variable name popup in the method line between the whitespace and the "0", so it wasn't obvious

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r2014721257

From mullan at openjdk.org  Wed Mar 26 18:35:17 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 26 Mar 2025 18:35:17 GMT
Subject: RFR: 8351366: Remove the java.security.debug=scl option [v2]
In-Reply-To: <tn-aDt7kzHgVXMH37atJoRn129od7KqmYjPpfCX5j4g=.0700fc00-b6ab-465c-a413-c813e6d1d3bb@github.com>
References: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
 <tn-aDt7kzHgVXMH37atJoRn129od7KqmYjPpfCX5j4g=.0700fc00-b6ab-465c-a413-c813e6d1d3bb@github.com>
Message-ID: <didS8cmJ7G4nAaxGY05hq1Q5yJ17kpu5QKxAMj-vTXM=.4373c274-c824-4af6-8307-362314432e2f@github.com>

On Wed, 26 Mar 2025 04:22:50 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> This option dumped the permissions that the SecureClassLoader assigns to ProtectionDomains, but with the disabling of the Security Manager in JDK 24, these permissions are always empty and the debugging has no value. So this option should be removed.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351366:Remove the java.security.debug=scl option

src/java.base/share/classes/java/security/SecureClassLoader.java line 188:

> 186:      */
> 187:     private static class DebugHolder {
> 188:         private static final Debug debug = Debug.getInstance("scl");

You should also remove the `import sun.security.util.Debug;` line above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24208#discussion_r2014791214

From duke at openjdk.org  Wed Mar 26 21:37:42 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 26 Mar 2025 21:37:42 GMT
Subject: RFR: 8351366: Remove the java.security.debug=scl option [v3]
In-Reply-To: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
References: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
Message-ID: <e4JMomXsEqb2w5vy8UmCthnpGhhihmdjWXH6BgMCVCA=.2afb021f-ba03-4782-aa41-7e770bee8984@github.com>

> This option dumped the permissions that the SecureClassLoader assigns to ProtectionDomains, but with the disabling of the Security Manager in JDK 24, these permissions are always empty and the debugging has no value. So this option should be removed.

Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:

  8351366:Remove the java.security.debug=scl option

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24208/files
  - new: https://git.openjdk.org/jdk/pull/24208/files/2416e92b..7367139f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24208&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24208&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24208/head:pull/24208

PR: https://git.openjdk.org/jdk/pull/24208

From hchao at openjdk.org  Wed Mar 26 22:40:37 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 26 Mar 2025 22:40:37 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v15]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <jctCALbcAJKj7eDbIS_d5hTQHzmqy3b8TwDRFgh6CU4=.687a31ec-6aca-4389-ab7b-8f5a8bdb6fe5@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update with comments from Sean and Weijun

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/2ef9e5cd..a963de7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=13-14

  Stats: 70 lines in 3 files changed: 56 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

PR: https://git.openjdk.org/jdk/pull/23532

From hchao at openjdk.org  Wed Mar 26 22:49:10 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 26 Mar 2025 22:49:10 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v14]
In-Reply-To: <ac-xaua6obCHei0T_EXpg4n15KkUPWsK_vZaMDLpDaw=.513b5b3c-535b-4aaa-86ff-61c045eff9cf@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <xxPP-NVMzOHqhXb5CCnZm_FJqjQirpeYBHRuoHyyQCg=.a23f77ef-da27-40b5-861c-246e270aa1cb@github.com>
 <ac-xaua6obCHei0T_EXpg4n15KkUPWsK_vZaMDLpDaw=.513b5b3c-535b-4aaa-86ff-61c045eff9cf@github.com>
Message-ID: <_cuRUgwJ8XTRXbm_XaO4BGLXqyaOd3OoMOUnWa5EDbo=.bc7bd817-183b-4b55-be88-3abfa3680aa7@github.com>

On Wed, 26 Mar 2025 12:34:13 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated with Sean's comments
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1138:
> 
>> 1136:     private void crossCheckEntries(String jarName) throws Exception {
>> 1137:         List<String> locEntries = new ArrayList<>();
>> 1138:         List<String> cenEntries;
> 
> You can move this declaration to where you first use it (line 1177).

Moved.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1163:
> 
>> 1161:                 }
>> 1162: 
>> 1163:                 readEntry(jis);
> 
> I think this method is only needed in order to get the code signers, right? If so, it can be moved to just before line 1174.

Both `readEntry()` are needed to ensure that the entry is fully processed before calling `compareSigners()`.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1168:
> 
>> 1166:                         crossChkWarnings.add(String.format(rb.getString(
>> 1167:                                 "entry.1.present.in.jarfile.but.unreadable"),
>> 1168:                                 entryName));
> 
> I think we should continue after this, since the JarInputStream entry doesn't exist, so no need to compare code signers.

Fixed.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 215:
> 
>> 213: manifest.attribute.1.present.when.reading.jarinputstream.but.missing.via.jarfile=Manifest attribute %s is present when reading via JarInputStream but missing when reading via JarFile
>> 214: manifest.attribute.1.differs.jarfile.value.2.jarinputstream.value.3=Manifest attribute %1$s differs: JarFile value = %2$s, JarInputStream value = %3$s
>> 215: Entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile=Entry %s is present when reading via JarInputStream but missing when reading via JarFile
> 
> Lower case the name ("entry.1")
> 
> (to be consistent with other property names)

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015092387
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015092416
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015092577
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015092456

From hchao at openjdk.org  Wed Mar 26 22:49:11 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 26 Mar 2025 22:49:11 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v14]
In-Reply-To: <QooOBFQmYRXMf01Iml4fs8Fiw1YGavdwrEJZw4vB_bM=.ed29360e-64d7-44ec-aee4-64c7664b4471@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <xxPP-NVMzOHqhXb5CCnZm_FJqjQirpeYBHRuoHyyQCg=.a23f77ef-da27-40b5-861c-246e270aa1cb@github.com>
 <QooOBFQmYRXMf01Iml4fs8Fiw1YGavdwrEJZw4vB_bM=.ed29360e-64d7-44ec-aee4-64c7664b4471@github.com>
Message-ID: <t_cjJlR-6W9PfXAESplOwiTc2w5mS2cJqgpuuHH_uGI=.23760e53-c7ec-4337-928f-f2ca1747b4e5@github.com>

On Wed, 26 Mar 2025 14:41:08 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated with Sean's comments
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1170:
> 
>> 1168:                                 entryName));
>> 1169:                     } else {
>> 1170:                         readEntry(cenInputStream);
> 
> This could throw a `SecurityException` if the content does not match the digest. Although we have verified the JAR file with`JarFile`, things could be different when opened with a `JarInputStream`.

Added try-catch block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015092673

From weijun at openjdk.org  Thu Mar 27 00:02:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Mar 2025 00:02:09 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v7]
In-Reply-To: <k5mH67X2lXWBLzjBuHp5tnRMtjVpfAOvUMMHqaxEl_Q=.83434608-31cc-4790-9da4-6f04c08ddb2f@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <I2J7uFoTSSVFqlm5vUTcemb8VmHxi-yxDLgYRSrSKu8=.eefe8944-c193-4842-9464-5925105fa518@github.com>
 <Mx1yDSUfRcA5X0ziqlpOus8fQq-PzZDbyE3mzIkWugc=.0d1c05c8-a382-44f1-9279-0800ff38aed1@github.com>
 <k5mH67X2lXWBLzjBuHp5tnRMtjVpfAOvUMMHqaxEl_Q=.83434608-31cc-4790-9da4-6f04c08ddb2f@github.com>
Message-ID: <m2A2N3zUqiwN_7G_ZqxLLzWtB3kYec2Fw-ek824fR1M=.80e0966c-e874-490c-bf9e-d4b0a5f89cb6@github.com>

On Wed, 19 Mar 2025 19:22:04 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1147:
>> 
>>> 1145:             Manifest locManifest = jis.getManifest();
>>> 1146:             if (!compareManifest(cenManifest, locManifest)) {
>>> 1147:                 return;
>> 
>> Here and within `compareManifest`, there are multiple early returns. Have you considered avoiding early returns and accumulating more warnings instead?
>
> Good idea. Updated the code. Thanks.

Again, shall we return here? Do you want to skip other comparison when the manifests are not the same?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015124600

From weijun at openjdk.org  Thu Mar 27 00:02:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 27 Mar 2025 00:02:12 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v15]
In-Reply-To: <jctCALbcAJKj7eDbIS_d5hTQHzmqy3b8TwDRFgh6CU4=.687a31ec-6aca-4389-ab7b-8f5a8bdb6fe5@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <jctCALbcAJKj7eDbIS_d5hTQHzmqy3b8TwDRFgh6CU4=.687a31ec-6aca-4389-ab7b-8f5a8bdb6fe5@github.com>
Message-ID: <XPkNjU5VlEjHtJfiOTGLrgyGPBWib6YECyOg-0j9FdM=.68575ec3-37f0-430b-991a-f029374bd500@github.com>

On Wed, 26 Mar 2025 22:40:37 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with comments from Sean and Weijun

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1215:

> 1213:             if (!cenEntries2.equals(locEntries)) {
> 1214:                 crossChkWarnings.add(rb.getString(
> 1215:                         "entries.mismatch.when.comparing.jarfile.and.jarinputstream"));

Do we still need this warning? The meaning is not clear to me. Since we have already compared in both ways, does this only mean the orders are different?

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 219:

> 217: entry.1.present.in.jarfile.but.unreadable=Entry %s is present in JarFile but unreadable
> 218: codesigners.different.for.entry.1.when.reading.jarfile.and.jarinputstream=Code signers are different for entry %s when reading from JarFile and JarInputStream
> 219: entry.1.has.codesigners.in.jarfile.but.not.in.jarinputstream=Entry %s has codesigners in JarFile but not in JarInputStream

Usually we don't say "has codesigners" or "has no codesigners", we say "is signed" and "is not signed". Same for the next one.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 222:

> 220: entry.1.has.codesigners.in.jarinputstream.but.not.in.jarfile=Entry %s has codesigners in JarInputStream but not in JarFile
> 221: entries.mismatch.when.comparing.jarfile.and.jarinputstream=Entries mismatch when comparing JarFile and JarInputStream
> 222: jar.contains.internal.inconsistencies.may.result.in.different.contents.when.reading.via.jarfile.and.jarinputstream=This JAR file contains internal inconsistencies that may result in different contents when reading via JarFile and JarInputStream

Do you think it makes sense to add a ":" at the end of this header line?

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 224:

> 222: jar.contains.internal.inconsistencies.may.result.in.different.contents.when.reading.via.jarfile.and.jarinputstream=This JAR file contains internal inconsistencies that may result in different contents when reading via JarFile and JarInputStream
> 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.inputstream=Signature verification failed on entry %s when reading via JarFile InputStream

I don't think you need to mention `InputStream` for the "JarFile" case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015126222
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015128336
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015128728
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015129415

From fferrari at openjdk.org  Thu Mar 27 00:35:13 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Thu, 27 Mar 2025 00:35:13 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings [v2]
In-Reply-To: <UxocAgqJQGs3ZFEl1WZU2kOE9lIMfEY1_QoHPK2peVw=.916b50b6-6376-4b90-8d65-73dd6d90a35d@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
 <UxocAgqJQGs3ZFEl1WZU2kOE9lIMfEY1_QoHPK2peVw=.916b50b6-6376-4b90-8d65-73dd6d90a35d@github.com>
Message-ID: <l8mNdE6lNd-BucMe89HPxsCFKkK7P65LbhhUEvjc97I=.05c6288f-0090-4a94-bf51-f0e89797ae13@github.com>

On Tue, 25 Mar 2025 00:22:23 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings.
>> 
>> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility.
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply the suggested changes and minor code refactoring.

Hi @valeriepeng,

I have left a couple more comments, and taken advantage to do a more complete review.

Please note that I haven't finished reviewing `TestPBKD.java` (for example, we can still do some of the deleted checks). However I wanted to left a partial review in-advance, as I will be on PTO until next Tuesday.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 203:

> 201:                 // because this is a PBE Mac service. In addition to checking
> 202:                 // the key, check that params (if passed) are consistent.
> 203:                 PBEUtil.checkKeyAndParams(key, params, algorithm);

Both usages of `PBEUtil.checkKeyAndParams` have been removed (this is the first one), so we should now remove it from `src/java.base/share/classes/sun/security/util/PBEUtil.java`.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 135:

> 133:             // because this is a PBE Cipher service. In addition to checking the
> 134:             // key, check that params (if passed) are consistent.
> 135:             PBEUtil.checkKeyAndParams(key, params, pbeAlg);

Both usages of `PBEUtil.checkKeyAndParams` have been removed (this is the second one), so we should now remove it from `src/java.base/share/classes/sun/security/util/PBEUtil.java`.

test/jdk/sun/security/pkcs11/Mac/PBAMac.java line 114:

> 112:                     "ae6b69cf9edfd9cd8c3b51cdf2b0243502f35a3e6007f33b1ab73568" +
> 113:                     "2ea81ea562f4383bb9512ff70752367b7259b16f"),
> 114:              macAssertionData("HmacPBESHA512", "HmacSHA512",

nit: all the `macAssertionData` calls are now indented with an extra space (13 leading spaces in total).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24068#pullrequestreview-2714825938
PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2012727892
PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2012749286
PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2012738803

From hchao at openjdk.org  Thu Mar 27 01:55:20 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 01:55:20 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v7]
In-Reply-To: <m2A2N3zUqiwN_7G_ZqxLLzWtB3kYec2Fw-ek824fR1M=.80e0966c-e874-490c-bf9e-d4b0a5f89cb6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <I2J7uFoTSSVFqlm5vUTcemb8VmHxi-yxDLgYRSrSKu8=.eefe8944-c193-4842-9464-5925105fa518@github.com>
 <Mx1yDSUfRcA5X0ziqlpOus8fQq-PzZDbyE3mzIkWugc=.0d1c05c8-a382-44f1-9279-0800ff38aed1@github.com>
 <k5mH67X2lXWBLzjBuHp5tnRMtjVpfAOvUMMHqaxEl_Q=.83434608-31cc-4790-9da4-6f04c08ddb2f@github.com>
 <m2A2N3zUqiwN_7G_ZqxLLzWtB3kYec2Fw-ek824fR1M=.80e0966c-e874-490c-bf9e-d4b0a5f89cb6@github.com>
Message-ID: <RxYp_YcpEjso3KF7GKUojyp909lHGV16d9eTelmASXQ=.a56a1cea-8481-41df-8e4e-d9c1a208daf4@github.com>

On Wed, 26 Mar 2025 23:23:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Good idea. Updated the code. Thanks.
>
> Again, shall we return here? Do you want to skip other comparison when the manifests are not the same?

It was suggested that I validate the Manifest and then fast fail if there is an inconsistency. As Manifest contains metadata about the JAR, if it itself is inconsistent, it may indicate a deeper issue with the JAR. I'd think fast failing could save time by avoiding unnecessary checks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015364427

From hchao at openjdk.org  Thu Mar 27 02:21:10 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 02:21:10 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v15]
In-Reply-To: <XPkNjU5VlEjHtJfiOTGLrgyGPBWib6YECyOg-0j9FdM=.68575ec3-37f0-430b-991a-f029374bd500@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <jctCALbcAJKj7eDbIS_d5hTQHzmqy3b8TwDRFgh6CU4=.687a31ec-6aca-4389-ab7b-8f5a8bdb6fe5@github.com>
 <XPkNjU5VlEjHtJfiOTGLrgyGPBWib6YECyOg-0j9FdM=.68575ec3-37f0-430b-991a-f029374bd500@github.com>
Message-ID: <uLaib-U6EGO3iszN8uirxLcqSvBW9mcWBcIvdMX8JzI=.748f0cc2-db97-41f3-a960-21acd4f20fe2@github.com>

On Wed, 26 Mar 2025 23:26:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update with comments from Sean and Weijun
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1215:
> 
>> 1213:             if (!cenEntries2.equals(locEntries)) {
>> 1214:                 crossChkWarnings.add(rb.getString(
>> 1215:                         "entries.mismatch.when.comparing.jarfile.and.jarinputstream"));
> 
> Do we still need this warning? The meaning is not clear to me. Since we have already compared in both ways, does this only mean the orders are different?

This step checks content and order. As the order does matter, I have this step to explicitly warn about ordering issue.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 219:
> 
>> 217: entry.1.present.in.jarfile.but.unreadable=Entry %s is present in JarFile but unreadable
>> 218: codesigners.different.for.entry.1.when.reading.jarfile.and.jarinputstream=Code signers are different for entry %s when reading from JarFile and JarInputStream
>> 219: entry.1.has.codesigners.in.jarfile.but.not.in.jarinputstream=Entry %s has codesigners in JarFile but not in JarInputStream
> 
> Usually we don't say "has codesigners" or "has no codesigners", we say "is signed" and "is not signed". Same for the next one.

Change them to:
Entry %s is signed in JarFile but is not signed in JarInputStream
Entry %s is signed in JarInputStream but is not signed in JarFile

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 222:
> 
>> 220: entry.1.has.codesigners.in.jarinputstream.but.not.in.jarfile=Entry %s has codesigners in JarInputStream but not in JarFile
>> 221: entries.mismatch.when.comparing.jarfile.and.jarinputstream=Entries mismatch when comparing JarFile and JarInputStream
>> 222: jar.contains.internal.inconsistencies.may.result.in.different.contents.when.reading.via.jarfile.and.jarinputstream=This JAR file contains internal inconsistencies that may result in different contents when reading via JarFile and JarInputStream
> 
> Do you think it makes sense to add a ":" at the end of this header line?

Yes.

> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 224:
> 
>> 222: jar.contains.internal.inconsistencies.may.result.in.different.contents.when.reading.via.jarfile.and.jarinputstream=This JAR file contains internal inconsistencies that may result in different contents when reading via JarFile and JarInputStream
>> 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.inputstream=Signature verification failed on entry %s when reading via JarFile InputStream
> 
> I don't think you need to mention `InputStream` for the "JarFile" case.

The entry is read using an `InputStream` from `JarFile`, and is not directly via `JarFile`. So I added `InputStream`. Remove it to be more consistent with other warnings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015407996
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015408034
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015408114
PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2015408205

From hchao at openjdk.org  Thu Mar 27 02:50:06 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 02:50:06 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v16]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <gSjUvh3zugE8v1mT9E2qwIXVOTh9D1CcZLV3Fp_qWuE=.299a7afa-6eae-4806-a676-d15bb32b589b@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update warning messages

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/a963de7b..286f8b1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=14-15

  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

PR: https://git.openjdk.org/jdk/pull/23532

From hchao at openjdk.org  Thu Mar 27 06:40:02 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 06:40:02 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v17]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <U03qCbi_vKSBeFGnFHDEM7D-zD1nHI2ksLTnp1ROiYY=.7675385e-2427-4f2c-895f-9494d4769d9e@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Not split warning in rb.getString() accross multi-lines for Usages.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/286f8b1f..18da4b00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=15-16

  Stats: 18 lines in 2 files changed: 0 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

PR: https://git.openjdk.org/jdk/pull/23532

From mullan at openjdk.org  Thu Mar 27 13:40:29 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 13:40:29 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v17]
In-Reply-To: <U03qCbi_vKSBeFGnFHDEM7D-zD1nHI2ksLTnp1ROiYY=.7675385e-2427-4f2c-895f-9494d4769d9e@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <U03qCbi_vKSBeFGnFHDEM7D-zD1nHI2ksLTnp1ROiYY=.7675385e-2427-4f2c-895f-9494d4769d9e@github.com>
Message-ID: <3UlkYZPawFZes5PlcCRmHvzAD31NoUrM2pQ6KgzTVwI=.26513905-adfb-49ac-9c72-afbac153b0d8@github.com>

On Thu, 27 Mar 2025 06:40:02 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not split warning in rb.getString() accross multi-lines for Usages.java

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1137:

> 1135: 
> 1136:     private void crossCheckEntries(String jarName) throws Exception {
> 1137:         List<String> locEntries = new ArrayList<>();

I think this can be a `HashSet` now that you don't care about the order when checking against the `cenEntries` later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2016588287

From mullan at openjdk.org  Thu Mar 27 13:40:29 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 13:40:29 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v15]
In-Reply-To: <uLaib-U6EGO3iszN8uirxLcqSvBW9mcWBcIvdMX8JzI=.748f0cc2-db97-41f3-a960-21acd4f20fe2@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <jctCALbcAJKj7eDbIS_d5hTQHzmqy3b8TwDRFgh6CU4=.687a31ec-6aca-4389-ab7b-8f5a8bdb6fe5@github.com>
 <XPkNjU5VlEjHtJfiOTGLrgyGPBWib6YECyOg-0j9FdM=.68575ec3-37f0-430b-991a-f029374bd500@github.com>
 <uLaib-U6EGO3iszN8uirxLcqSvBW9mcWBcIvdMX8JzI=.748f0cc2-db97-41f3-a960-21acd4f20fe2@github.com>
Message-ID: <S3KolIQdKYP5veOPF5HgaKCcOBxYB-YUagJjwFFNA1Y=.a724ff9c-4d16-4fb2-a924-612e78905f8b@github.com>

On Thu, 27 Mar 2025 02:18:05 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1215:
>> 
>>> 1213:             if (!cenEntries2.equals(locEntries)) {
>>> 1214:                 crossChkWarnings.add(rb.getString(
>>> 1215:                         "entries.mismatch.when.comparing.jarfile.and.jarinputstream"));
>> 
>> Do we still need this warning? The meaning is not clear to me. Since we have already compared in both ways, does this only mean the orders are different?
>
> This step checks content and order. As the order does matter, I have this step to explicitly warn about ordering issue.

But they are Sets now, so the order could have changed simply by adding them to the Set. I think this check can be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2016594597

From fguallini at openjdk.org  Thu Mar 27 13:43:21 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 27 Mar 2025 13:43:21 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests [v2]
In-Reply-To: <mO3aM1uy62-Fql_tsQBrfhW0L3qQo17GsRWCWsCnX_g=.b3a44e18-9cee-4c36-85cc-0ff84427fe56@github.com>
References: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
 <mO3aM1uy62-Fql_tsQBrfhW0L3qQo17GsRWCWsCnX_g=.b3a44e18-9cee-4c36-85cc-0ff84427fe56@github.com>
Message-ID: <A7thnbUC1uzvY87umLURH7yxvjkHDTEVOwhwR9O-FCI=.b89df6c9-6e4e-4e2e-bbc9-83c74a2e9f92@github.com>

On Tue, 18 Mar 2025 14:11:26 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> 8351566: Consolidate third party artifacts used in tests
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor: imports fix

test/lib/jdk/test/lib/security/artifacts/ThirdPartyArtifacts.java line 30:

> 28: import jdk.test.lib.artifacts.ArtifactResolverException;
> 29: 
> 30: import java.io.IOException;

nit: unused imports can be removed

test/lib/jdk/test/lib/security/artifacts/ThirdPartyArtifacts.java line 35:

> 33: public class ThirdPartyArtifacts {
> 34: 
> 35:     public static final String ACVP_BUNDLE_LOC = "jpg.tests.jdk";

The location: "jpg.tests.jdk" may be common for all artifacts.
Suggestion:

    public static final String ARTIFACT_BASE = "jpg.tests.jdk";

test/lib/jdk/test/lib/security/artifacts/ThirdPartyArtifacts.java line 42:

> 40:     // the NSS version
> 41:     public static final String NSS_BUNDLE_VERSION = "3.107";
> 42:     public static final String NSSLIB = "jpg.tests.jdk.nsslib";

It can reuse the common location. also do the bundle vars need to be public ?

Suggestion:

    private static final String NSSLIB = ARTIFACT_BASE + ".nsslib";

test/lib/jdk/test/lib/security/artifacts/ThirdPartyArtifacts.java line 49:

> 47:             revision = NSS_BUNDLE_VERSION,
> 48:             extension = "zip")
> 49:     public static class WINDOWS_X64 {

Please rename the NSS static classes to `NSS_<platform>` as ThirdPartyArtifacts will also contain other artifacts for these platforms
Suggestion:

    public static class NSS_WINDOWS_X64 {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2016597905
PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2016590177
PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2016594920
PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2016578229

From mullan at openjdk.org  Thu Mar 27 14:17:25 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 14:17:25 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
Message-ID: <6hVzy0HMZHmVPDLLvz7bVTIVfTtYnfx2DdgMXmiVNcc=.818264da-a194-4d27-94aa-0c892c274d39@github.com>

On Mon, 24 Mar 2025 17:24:01 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix java.security syntax. Remove whitespace.

src/java.base/share/classes/sun/security/ssl/SSLScope.java line 39:

> 37:     CERTIFICATE_SIGNATURE("CertificateSignature");
> 38: 
> 39:     final String name;

Make this `private`.

src/java.base/share/conf/security/java.security line 747:

> 745: #
> 746: #     UsageType:
> 747: #         ([HandshakeSignature] | [CertificateSignature])

This needs to be updated to match CSR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2016768779
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2016770978

From abarashev at openjdk.org  Thu Mar 27 14:36:17 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 27 Mar 2025 14:36:17 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <6hVzy0HMZHmVPDLLvz7bVTIVfTtYnfx2DdgMXmiVNcc=.818264da-a194-4d27-94aa-0c892c274d39@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
 <6hVzy0HMZHmVPDLLvz7bVTIVfTtYnfx2DdgMXmiVNcc=.818264da-a194-4d27-94aa-0c892c274d39@github.com>
Message-ID: <U5eZQz0aRbJ_5q7lglUA-0MDE0y_pW7b2E6KYJUnwGQ=.daaa919e-22ce-44fe-a8ea-24ed762a2c73@github.com>

On Thu, 27 Mar 2025 14:14:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix java.security syntax. Remove whitespace.
>
> src/java.base/share/conf/security/java.security line 747:
> 
>> 745: #
>> 746: #     UsageType:
>> 747: #         ([HandshakeSignature] | [CertificateSignature])
> 
> This needs to be updated to match CSR.

Of course. The updated CSR was recently approved and I'm preparing a commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2016817290

From abarashev at openjdk.org  Thu Mar 27 14:42:36 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 27 Mar 2025 14:42:36 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint [v2]
In-Reply-To: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
Message-ID: <rg7jRRQoK7guGmJ9u6yjYnNHU_MnkETyViXmXmWXIkk=.2607a0d0-d3a5-4bec-b9d1-c889744778c1@github.com>

> We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Make syntax consistent with the rest of the file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24231/files
  - new: https://git.openjdk.org/jdk/pull/24231/files/437dbb9a..18acc237

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24231&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24231&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24231/head:pull/24231

PR: https://git.openjdk.org/jdk/pull/24231

From abarashev at openjdk.org  Thu Mar 27 14:42:36 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 27 Mar 2025 14:42:36 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint [v2]
In-Reply-To: <H_MJIloPRAr7imOqTh1cMgSFeeML2dH4fhgC36NGO_M=.fe2e9300-dfc3-4335-af41-dca90aa4addc@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
 <KiCW_yM5xJ-HDM6omXEudzeQAmrM-RrbwoFGkcbmPJY=.3d5adb69-9d38-4292-bafe-f520e18ab24a@github.com>
 <H_MJIloPRAr7imOqTh1cMgSFeeML2dH4fhgC36NGO_M=.fe2e9300-dfc3-4335-af41-dca90aa4addc@github.com>
Message-ID: <KB7ehh5KYgDdqAXDFG1ZMq7y9smEIOn37vsUZzS4PXQ=.51b9f206-6383-49ec-bda5-16861b11fbcd@github.com>

On Tue, 25 Mar 2025 19:22:52 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 541:
>> 
>>> 539: #
>>> 540: #   UsageType:
>>> 541: #       ([TLSServer] | [TLSClient] | [SignedJAR])
>> 
>> It looks like we list the alternatives without brackets, for example Constraint at line #518 as:
>> 
>>  518 #   Constraint:
>>  519 #       KeySizeConstraint | CAConstraint | DenyAfterConstraint |
>>  520 #       UsageConstraint
>> 
>>  Would you consider to remove the brackets here?
>
> Yes, it's inconsistent with the rest of the file actually. I'll check which version is semantically correct and make changes. Thanks!

All done. I had to re-open a CSR for this change, so it took some time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24231#discussion_r2016828566

From mullan at openjdk.org  Thu Mar 27 14:48:08 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 14:48:08 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint [v2]
In-Reply-To: <rg7jRRQoK7guGmJ9u6yjYnNHU_MnkETyViXmXmWXIkk=.2607a0d0-d3a5-4bec-b9d1-c889744778c1@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
 <rg7jRRQoK7guGmJ9u6yjYnNHU_MnkETyViXmXmWXIkk=.2607a0d0-d3a5-4bec-b9d1-c889744778c1@github.com>
Message-ID: <ryORnWeKUN5yAoazAzK0pptS4G3Fh1iGNEICaHvnMPs=.caa0b898-07cb-4d70-adfa-56a12035b0ae@github.com>

On Thu, 27 Mar 2025 14:42:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make syntax consistent with the rest of the file

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24231#pullrequestreview-2722018399

From myankelevich at openjdk.org  Thu Mar 27 16:55:01 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 27 Mar 2025 16:55:01 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests [v3]
In-Reply-To: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
References: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
Message-ID: <_WldHL5Zc68N5B0x4KUpoumcUV2lbgWzSdPZXRBqqYY=.07799f18-3204-4310-8712-c91bd916c165@github.com>

> 8351566: Consolidate third party artifacts used in tests

Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:

  Fernando's comments:
  
  * cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23988/files
  - new: https://git.openjdk.org/jdk/pull/23988/files/46e62cb6..05e49a55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23988&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23988&range=01-02

  Stats: 21 lines in 3 files changed: 0 ins; 8 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/23988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23988/head:pull/23988

PR: https://git.openjdk.org/jdk/pull/23988

From myankelevich at openjdk.org  Thu Mar 27 16:55:04 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 27 Mar 2025 16:55:04 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests [v2]
In-Reply-To: <A7thnbUC1uzvY87umLURH7yxvjkHDTEVOwhwR9O-FCI=.b89df6c9-6e4e-4e2e-bbc9-83c74a2e9f92@github.com>
References: <mJeUBkYdtIZNGWI82ag5z-ssphv4edDSS-X1estsnrA=.1d8fcece-1c3a-4592-b636-fc760c44917a@github.com>
 <mO3aM1uy62-Fql_tsQBrfhW0L3qQo17GsRWCWsCnX_g=.b3a44e18-9cee-4c36-85cc-0ff84427fe56@github.com>
 <A7thnbUC1uzvY87umLURH7yxvjkHDTEVOwhwR9O-FCI=.b89df6c9-6e4e-4e2e-bbc9-83c74a2e9f92@github.com>
Message-ID: <Pf97oul1k16SAJhWIPz5xMMHGwin3zvhjo3d1z-O4o0=.b56c3e86-b489-413c-8abd-4521f685e6f6@github.com>

On Thu, 27 Mar 2025 13:33:37 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor: imports fix
>
> test/lib/jdk/test/lib/security/artifacts/ThirdPartyArtifacts.java line 30:
> 
>> 28: import jdk.test.lib.artifacts.ArtifactResolverException;
>> 29: 
>> 30: import java.io.IOException;
> 
> nit: unused imports can be removed

done in the next commit

> test/lib/jdk/test/lib/security/artifacts/ThirdPartyArtifacts.java line 35:
> 
>> 33: public class ThirdPartyArtifacts {
>> 34: 
>> 35:     public static final String ACVP_BUNDLE_LOC = "jpg.tests.jdk";
> 
> The location: "jpg.tests.jdk" may be common for all artifacts.
> Suggestion:
> 
>     public static final String ARTIFACT_BASE = "jpg.tests.jdk";

done in the next commit

> test/lib/jdk/test/lib/security/artifacts/ThirdPartyArtifacts.java line 42:
> 
>> 40:     // the NSS version
>> 41:     public static final String NSS_BUNDLE_VERSION = "3.107";
>> 42:     public static final String NSSLIB = "jpg.tests.jdk.nsslib";
> 
> It can reuse the common location. also do the bundle vars need to be public ?
> 
> Suggestion:
> 
>     private static final String NSSLIB = ARTIFACT_BASE + ".nsslib";

done in the next commit

> test/lib/jdk/test/lib/security/artifacts/ThirdPartyArtifacts.java line 49:
> 
>> 47:             revision = NSS_BUNDLE_VERSION,
>> 48:             extension = "zip")
>> 49:     public static class WINDOWS_X64 {
> 
> Please rename the NSS static classes to `NSS_<platform>` as ThirdPartyArtifacts will also contain other artifacts for these platforms
> Suggestion:
> 
>     public static class NSS_WINDOWS_X64 {

done in the next commit

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2017135131
PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2017135046
PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2017135227
PR Review Comment: https://git.openjdk.org/jdk/pull/23988#discussion_r2017134859

From ascarpino at openjdk.org  Thu Mar 27 18:11:27 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Mar 2025 18:11:27 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v7]
In-Reply-To: <J8hfAKnOa4N_bT941kRZA4O3f43r2wFJlxe6GTKTQw0=.109cb8fd-d53c-4c52-b968-d6352e26a2a4@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <J8hfAKnOa4N_bT941kRZA4O3f43r2wFJlxe6GTKTQw0=.109cb8fd-d53c-4c52-b968-d6352e26a2a4@github.com>
Message-ID: <g2nUUDGCLOfdkoCQAw9ZC5GBIHk25bfSUQ-9I1CbxEg=.9d936bbb-e347-4f0b-9c53-a102c94acb12@github.com>

On Mon, 24 Mar 2025 17:23:51 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - whitespace
>  - prettify test

Java code changes look good. This has passed tier1-3 testing.

-------------

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23719#pullrequestreview-2722978322

From ascarpino at openjdk.org  Thu Mar 27 18:14:24 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Mar 2025 18:14:24 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v7]
In-Reply-To: <J8hfAKnOa4N_bT941kRZA4O3f43r2wFJlxe6GTKTQw0=.109cb8fd-d53c-4c52-b968-d6352e26a2a4@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <J8hfAKnOa4N_bT941kRZA4O3f43r2wFJlxe6GTKTQw0=.109cb8fd-d53c-4c52-b968-d6352e26a2a4@github.com>
Message-ID: <AnI5wa6uS6VX6O-SqdEwFQQ7Hgd666wt_gpnATxQ1ZM=.2de88266-5d2d-4ee1-bc66-888f707ceae1@github.com>

On Mon, 24 Mar 2025 17:23:51 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - whitespace
>  - prettify test

Wait on integration.  I need to check something

-------------

Changes requested by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23719#pullrequestreview-2722990209

From mullan at openjdk.org  Thu Mar 27 18:37:23 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 18:37:23 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
Message-ID: <ds03CayRYDY791LznOwBSTtOQZER-fwAcgtLpJDWfRs=.f7b2b513-a677-4586-8841-ca20131ea008@github.com>

On Mon, 24 Mar 2025 17:24:01 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix java.security syntax. Remove whitespace.

test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 127:

> 125:      *                      a well-formed TLS message.
> 126:      */
> 127:     protected ByteBuffer extractHandshakeMsg(ByteBuffer tlsRecord,

This seems like quite a useful method! How about adding it to the superclass `SSLEngineTemplate` so that we might use it for other tests in the future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017417135

From hchao at openjdk.org  Thu Mar 27 18:54:13 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 18:54:13 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v18]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <IDD_Wh5fvMND2qnUhMtUR2eCfSbzrZetlGRWuvG5msM=.59483654-c87b-42cd-8bf6-bc69c2c91028@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Remove fast failing upon manifest issue and entry order check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/18da4b00..9736f59d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=16-17

  Stats: 35 lines in 3 files changed: 0 ins; 22 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

PR: https://git.openjdk.org/jdk/pull/23532

From mullan at openjdk.org  Thu Mar 27 18:54:23 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 18:54:23 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
Message-ID: <MXlcHYFMydllfn0ryLs8H0IjPXstxuNvXUhy4klxUZ8=.801a8e70-7a06-4541-a821-335fa3decd96@github.com>

On Mon, 24 Mar 2025 17:24:01 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix java.security syntax. Remove whitespace.

test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 77:

> 75:     }
> 76: 
> 77:     protected String getProtocol() {

I'd be more inclined to make this abstract and force subclasses to override it.

test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS12.java line 52:

> 50:     protected static final String DISABLED_CONSTRAINTS =
> 51:             HANDSHAKE_DISABLED_SIG + " usage HandShakesignature, "
> 52:             + CERTIFICATE_DISABLED_SIG + " usage certificateSignature";

Nit: s/certificateSignature/CertificateSignature/

test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS13.java line 42:

> 40: 
> 41: public class DisableSignatureSchemePerScopeTLS13
> 42:         extends DisableSignatureSchemePerScopeTLS12 {

It's a little odd this extends *TLS12 - did you consider extending `AbstractCheckSignatureSchemes` or was that too complicated?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017434192
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017425885
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017440271

From ascarpino at openjdk.org  Thu Mar 27 18:55:43 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Mar 2025 18:55:43 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v7]
In-Reply-To: <J8hfAKnOa4N_bT941kRZA4O3f43r2wFJlxe6GTKTQw0=.109cb8fd-d53c-4c52-b968-d6352e26a2a4@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <J8hfAKnOa4N_bT941kRZA4O3f43r2wFJlxe6GTKTQw0=.109cb8fd-d53c-4c52-b968-d6352e26a2a4@github.com>
Message-ID: <th0TVPFst1gmMwVVV00YGLznU_hB07EEHoX-9gZbW44=.69d8b74d-de92-4501-9309-787e04b937b3@github.com>

On Mon, 24 Mar 2025 17:23:51 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - whitespace
>  - prettify test

src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.

You are missing a trailing comma.  I didn't pick this up originally because a test I didn't expect to see failed on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2017443311

From hchao at openjdk.org  Thu Mar 27 19:01:12 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 19:01:12 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v17]
In-Reply-To: <3UlkYZPawFZes5PlcCRmHvzAD31NoUrM2pQ6KgzTVwI=.26513905-adfb-49ac-9c72-afbac153b0d8@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <U03qCbi_vKSBeFGnFHDEM7D-zD1nHI2ksLTnp1ROiYY=.7675385e-2427-4f2c-895f-9494d4769d9e@github.com>
 <3UlkYZPawFZes5PlcCRmHvzAD31NoUrM2pQ6KgzTVwI=.26513905-adfb-49ac-9c72-afbac153b0d8@github.com>
Message-ID: <dZ-KiQSuq9M2XgJWxtPrAYdsyauO7pNuweAJUK8-Mw4=.f6bd0e7b-7cca-42c8-b210-250e1127d684@github.com>

On Thu, 27 Mar 2025 13:28:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Not split warning in rb.getString() accross multi-lines for Usages.java
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line 1137:
> 
>> 1135: 
>> 1136:     private void crossCheckEntries(String jarName) throws Exception {
>> 1137:         List<String> locEntries = new ArrayList<>();
> 
> I think this can be a `HashSet` now that you don't care about the order when checking against the `cenEntries` later.

Changed to `HashSet`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2017446934

From hchao at openjdk.org  Thu Mar 27 19:01:13 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 19:01:13 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v7]
In-Reply-To: <RxYp_YcpEjso3KF7GKUojyp909lHGV16d9eTelmASXQ=.a56a1cea-8481-41df-8e4e-d9c1a208daf4@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <I2J7uFoTSSVFqlm5vUTcemb8VmHxi-yxDLgYRSrSKu8=.eefe8944-c193-4842-9464-5925105fa518@github.com>
 <Mx1yDSUfRcA5X0ziqlpOus8fQq-PzZDbyE3mzIkWugc=.0d1c05c8-a382-44f1-9279-0800ff38aed1@github.com>
 <k5mH67X2lXWBLzjBuHp5tnRMtjVpfAOvUMMHqaxEl_Q=.83434608-31cc-4790-9da4-6f04c08ddb2f@github.com>
 <m2A2N3zUqiwN_7G_ZqxLLzWtB3kYec2Fw-ek824fR1M=.80e0966c-e874-490c-bf9e-d4b0a5f89cb6@github.com>
 <RxYp_YcpEjso3KF7GKUojyp909lHGV16d9eTelmASXQ=.a56a1cea-8481-41df-8e4e-d9c1a208daf4@github.com>
Message-ID: <v5z5gJRWZ6uV7E35QKJVijVRcNW7kTB7udVFX-sDHF0=.2265759e-8a3c-4b1c-abea-04283afe0b58@github.com>

On Thu, 27 Mar 2025 01:52:40 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Again, shall we return here? Do you want to skip other comparison when the manifests are not the same?
>
> It was suggested that I validate the Manifest and then fast fail if there is an inconsistency. As Manifest contains metadata about the JAR, if it itself is inconsistent, it may indicate a deeper issue with the JAR. I'd think fast failing could save time by avoiding unnecessary checks.

Removed `return` here, so no fast failing to continue on integrity checking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2017449428

From hchao at openjdk.org  Thu Mar 27 19:01:14 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 19:01:14 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v15]
In-Reply-To: <S3KolIQdKYP5veOPF5HgaKCcOBxYB-YUagJjwFFNA1Y=.a724ff9c-4d16-4fb2-a924-612e78905f8b@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <jctCALbcAJKj7eDbIS_d5hTQHzmqy3b8TwDRFgh6CU4=.687a31ec-6aca-4389-ab7b-8f5a8bdb6fe5@github.com>
 <XPkNjU5VlEjHtJfiOTGLrgyGPBWib6YECyOg-0j9FdM=.68575ec3-37f0-430b-991a-f029374bd500@github.com>
 <uLaib-U6EGO3iszN8uirxLcqSvBW9mcWBcIvdMX8JzI=.748f0cc2-db97-41f3-a960-21acd4f20fe2@github.com>
 <S3KolIQdKYP5veOPF5HgaKCcOBxYB-YUagJjwFFNA1Y=.a724ff9c-4d16-4fb2-a924-612e78905f8b@github.com>
Message-ID: <fvIVGVgljdcZ4BeJgP7lgIM1JY84ToN3-OkPe2mJ4JY=.a32c2c94-977b-4c3d-b891-d348c10757ed@github.com>

On Thu, 27 Mar 2025 13:32:09 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This step checks content and order. As the order does matter, I have this step to explicitly warn about ordering issue.
>
> But they are Sets now, so the order could have changed simply by adding them to the Set. I think this check can be removed.

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2017446860

From hchao at openjdk.org  Thu Mar 27 19:10:08 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 19:10:08 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v19]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <-8INCAnzcn1O-2h6yz9SeUdTNptYATbdTUdm_fBu1R0=.7a2f15c0-9bef-4f38-9ec9-a736cef8062d@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Add CEN/LOC summary warning to Informational Warnings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/9736f59d..8ec7784d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=17-18

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

PR: https://git.openjdk.org/jdk/pull/23532

From vpaprotski at openjdk.org  Thu Mar 27 19:13:59 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 27 Mar 2025 19:13:59 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v8]
In-Reply-To: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
Message-ID: <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>

> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
> 
> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
> 
> Before (no AVX512)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
> 
> After (with AVX2)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
> 
> 
> Before (with AVX512):
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        102...

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright stmt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23719/files
  - new: https://git.openjdk.org/jdk/pull/23719/files/a7f756af..0a4230aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23719&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23719&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23719/head:pull/23719

PR: https://git.openjdk.org/jdk/pull/23719

From vpaprotski at openjdk.org  Thu Mar 27 19:14:01 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 27 Mar 2025 19:14:01 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v7]
In-Reply-To: <th0TVPFst1gmMwVVV00YGLznU_hB07EEHoX-9gZbW44=.69d8b74d-de92-4501-9309-787e04b937b3@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <J8hfAKnOa4N_bT941kRZA4O3f43r2wFJlxe6GTKTQw0=.109cb8fd-d53c-4c52-b968-d6352e26a2a4@github.com>
 <th0TVPFst1gmMwVVV00YGLznU_hB07EEHoX-9gZbW44=.69d8b74d-de92-4501-9309-787e04b937b3@github.com>
Message-ID: <njhQ8HWD3G4FJmFrjOJ77ibz3yMeNZvMy0AcNAGSdA4=.50a0eba8-8a72-4d96-8a67-bc5773cac291@github.com>

On Thu, 27 Mar 2025 18:52:53 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - prettify test
>
> src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.
> 
> You are missing a trailing comma.  I didn't pick this up originally because a test I didn't expect to see failed on this.

Fixed.. guess should had looked at other files when I had to add the second year/range!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2017464572

From hchao at openjdk.org  Thu Mar 27 19:27:19 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 19:27:19 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint [v2]
In-Reply-To: <rg7jRRQoK7guGmJ9u6yjYnNHU_MnkETyViXmXmWXIkk=.2607a0d0-d3a5-4bec-b9d1-c889744778c1@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
 <rg7jRRQoK7guGmJ9u6yjYnNHU_MnkETyViXmXmWXIkk=.2607a0d0-d3a5-4bec-b9d1-c889744778c1@github.com>
Message-ID: <1tWPzGVnD4uI5eZ0hCjPREIP1z6dT_yFTy4ROiA2blY=.340d6d15-41a9-402d-b555-1f9b07e14bb3@github.com>

On Thu, 27 Mar 2025 14:42:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make syntax consistent with the rest of the file

Marked as reviewed by hchao (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24231#pullrequestreview-2723181118

From hchao at openjdk.org  Thu Mar 27 19:27:20 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 19:27:20 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint [v2]
In-Reply-To: <KB7ehh5KYgDdqAXDFG1ZMq7y9smEIOn37vsUZzS4PXQ=.51b9f206-6383-49ec-bda5-16861b11fbcd@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
 <KiCW_yM5xJ-HDM6omXEudzeQAmrM-RrbwoFGkcbmPJY=.3d5adb69-9d38-4292-bafe-f520e18ab24a@github.com>
 <H_MJIloPRAr7imOqTh1cMgSFeeML2dH4fhgC36NGO_M=.fe2e9300-dfc3-4335-af41-dca90aa4addc@github.com>
 <KB7ehh5KYgDdqAXDFG1ZMq7y9smEIOn37vsUZzS4PXQ=.51b9f206-6383-49ec-bda5-16861b11fbcd@github.com>
Message-ID: <SmxrLgpM1jumhMmRFhyHrAKlm2j8Fl_y_IjGnCHfJAw=.e92cd92c-9c3c-4408-ae4d-b5e89ca8db48@github.com>

On Thu, 27 Mar 2025 14:38:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Yes, it's inconsistent with the rest of the file actually. I'll check which version is semantically correct and make changes. Thanks!
>
> All done. I had to re-open a CSR for this change, so it took some time.

Looks good. Thanks for making the change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24231#discussion_r2017481170

From abarashev at openjdk.org  Thu Mar 27 19:41:26 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 27 Mar 2025 19:41:26 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <MXlcHYFMydllfn0ryLs8H0IjPXstxuNvXUhy4klxUZ8=.801a8e70-7a06-4541-a821-335fa3decd96@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
 <MXlcHYFMydllfn0ryLs8H0IjPXstxuNvXUhy4klxUZ8=.801a8e70-7a06-4541-a821-335fa3decd96@github.com>
Message-ID: <YzYJVx9MwEt6HIVSs6Ce1BzksvBkIp956GVnGcN5gok=.946463ae-5284-49fe-8e1d-29b89e571c97@github.com>

On Thu, 27 Mar 2025 18:46:02 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix java.security syntax. Remove whitespace.
>
> test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 77:
> 
>> 75:     }
>> 76: 
>> 77:     protected String getProtocol() {
> 
> I'd be more inclined to make this abstract and force subclasses to override it.

Will do. I also though about it but since the original `SigSchemePropOrdering` test had "TLSv1.2" I kept it as default.

> test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS12.java line 52:
> 
>> 50:     protected static final String DISABLED_CONSTRAINTS =
>> 51:             HANDSHAKE_DISABLED_SIG + " usage HandShakesignature, "
>> 52:             + CERTIFICATE_DISABLED_SIG + " usage certificateSignature";
> 
> Nit: s/certificateSignature/CertificateSignature/

Actually this is done on purpose to check case-insensitive matching, I use this approach in other tests as well.

> test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS13.java line 42:
> 
>> 40: 
>> 41: public class DisableSignatureSchemePerScopeTLS13
>> 42:         extends DisableSignatureSchemePerScopeTLS12 {
> 
> It's a little odd this extends *TLS12 - did you consider extending `AbstractCheckSignatureSchemes` or was that too complicated?

I've done it for code reusability, we'll have to copy/paste a few methods otherwise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017493320
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017495722
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017498123

From mullan at openjdk.org  Thu Mar 27 19:41:27 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 19:41:27 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <YzYJVx9MwEt6HIVSs6Ce1BzksvBkIp956GVnGcN5gok=.946463ae-5284-49fe-8e1d-29b89e571c97@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
 <MXlcHYFMydllfn0ryLs8H0IjPXstxuNvXUhy4klxUZ8=.801a8e70-7a06-4541-a821-335fa3decd96@github.com>
 <YzYJVx9MwEt6HIVSs6Ce1BzksvBkIp956GVnGcN5gok=.946463ae-5284-49fe-8e1d-29b89e571c97@github.com>
Message-ID: <J6L02_5zJjQJ71FYVymyeebnKhM1GQCxzQWXvWhsrxY=.d0011d91-3df2-41dc-88ae-ee70a23a42df@github.com>

On Thu, 27 Mar 2025 19:35:48 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS12.java line 52:
>> 
>>> 50:     protected static final String DISABLED_CONSTRAINTS =
>>> 51:             HANDSHAKE_DISABLED_SIG + " usage HandShakesignature, "
>>> 52:             + CERTIFICATE_DISABLED_SIG + " usage certificateSignature";
>> 
>> Nit: s/certificateSignature/CertificateSignature/
>
> Actually this is done on purpose to check case-insensitive matching, I use this approach in other tests as well.

Ok, please add a comment above indicating that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017498251

From mullan at openjdk.org  Thu Mar 27 19:51:27 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 19:51:27 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v14]
In-Reply-To: <JEdgiQ7rcCLOwORmFswjr3azPHI7CEhEDq3A3HxbvRg=.66f35d62-3217-4d5f-8d4f-e8c3cda51fcf@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <xxPP-NVMzOHqhXb5CCnZm_FJqjQirpeYBHRuoHyyQCg=.a23f77ef-da27-40b5-861c-246e270aa1cb@github.com>
 <ac-xaua6obCHei0T_EXpg4n15KkUPWsK_vZaMDLpDaw=.513b5b3c-535b-4aaa-86ff-61c045eff9cf@github.com>
 <JEdgiQ7rcCLOwORmFswjr3azPHI7CEhEDq3A3HxbvRg=.66f35d62-3217-4d5f-8d4f-e8c3cda51fcf@github.com>
Message-ID: <eSUHuo0QqYqhV-QUBK7YHg2YIa3y_BAdXlsGswQH2IU=.b97418e2-15ff-46b9-808e-036a5a3795b4@github.com>

On Wed, 26 Mar 2025 14:49:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner.properties line 216:
>> 
>>> 214: manifest.attribute.1.differs.jarfile.value.2.jarinputstream.value.3=Manifest attribute %1$s differs: JarFile value = %2$s, JarInputStream value = %3$s
>>> 215: Entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile=Entry %s is present when reading via JarInputStream but missing when reading via JarFile
>>> 216: entry.1.present.in.jarfile.but.unreadable=Entry %s is present in JarFile but unreadable
>> 
>> Shouldn't this be the opposite of "entry.1.present.when.reading.jarinputstream.but.missing.via.JarFile":
>> 
>> "Entry %s is present when reading via JarFile but missing when reading via JarInputStream"
>
> Actually never mind, I see that this warning is if there is an entry but no input stream. So ignore my comment.

You can resolve this comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2017502904

From mullan at openjdk.org  Thu Mar 27 19:51:27 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 19:51:27 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v19]
In-Reply-To: <-8INCAnzcn1O-2h6yz9SeUdTNptYATbdTUdm_fBu1R0=.7a2f15c0-9bef-4f38-9ec9-a736cef8062d@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <-8INCAnzcn1O-2h6yz9SeUdTNptYATbdTUdm_fBu1R0=.7a2f15c0-9bef-4f38-9ec9-a736cef8062d@github.com>
Message-ID: <RoOWo1FqXKK22AfCGHHqyNvp-ER8ksvQxVc6tPiEx8I=.6df54c11-b108-4fcd-a050-0ec2041fca36@github.com>

On Thu, 27 Mar 2025 19:10:08 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CEN/LOC summary warning to Informational Warnings

src/jdk.jartool/share/man/jarsigner.md line 929:

> 927: 
> 928: internalConsistenciesDetected
> 929: 

I don't think you need a line break here, the other warnings don't.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2017501519

From valeriep at openjdk.org  Thu Mar 27 20:57:17 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 27 Mar 2025 20:57:17 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings [v2]
In-Reply-To: <l8mNdE6lNd-BucMe89HPxsCFKkK7P65LbhhUEvjc97I=.05c6288f-0090-4a94-bf51-f0e89797ae13@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
 <UxocAgqJQGs3ZFEl1WZU2kOE9lIMfEY1_QoHPK2peVw=.916b50b6-6376-4b90-8d65-73dd6d90a35d@github.com>
 <l8mNdE6lNd-BucMe89HPxsCFKkK7P65LbhhUEvjc97I=.05c6288f-0090-4a94-bf51-f0e89797ae13@github.com>
Message-ID: <OW-kZj-x1Vs1NeHloicrZ8MvAc2IxIZqEs1UfReG0QA=.29e95089-6d2e-4fe5-9f97-20fb55f95847@github.com>

On Tue, 25 Mar 2025 18:34:00 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   apply the suggested changes and minor code refactoring.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 203:
> 
>> 201:                 // because this is a PBE Mac service. In addition to checking
>> 202:                 // the key, check that params (if passed) are consistent.
>> 203:                 PBEUtil.checkKeyAndParams(key, params, algorithm);
> 
> Both usages of `PBEUtil.checkKeyAndParams` have been removed (this is the first one), so we should now remove it from `src/java.base/share/classes/sun/security/util/PBEUtil.java`.

Sure, will remove. less code to maintain.

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 135:
> 
>> 133:             // because this is a PBE Cipher service. In addition to checking the
>> 134:             // key, check that params (if passed) are consistent.
>> 135:             PBEUtil.checkKeyAndParams(key, params, pbeAlg);
> 
> Both usages of `PBEUtil.checkKeyAndParams` have been removed (this is the second one), so we should now remove it from `src/java.base/share/classes/sun/security/util/PBEUtil.java`.

Yes.

> test/jdk/sun/security/pkcs11/Mac/PBAMac.java line 114:
> 
>> 112:                     "ae6b69cf9edfd9cd8c3b51cdf2b0243502f35a3e6007f33b1ab73568" +
>> 113:                     "2ea81ea562f4383bb9512ff70752367b7259b16f"),
>> 114:              macAssertionData("HmacPBESHA512", "HmacSHA512",
> 
> nit: all the `macAssertionData` calls are now indented with an extra space (13 leading spaces in total).

Yes, should be 12 spaces.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2017585554
PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2017588409
PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2017587244

From valeriep at openjdk.org  Thu Mar 27 21:07:08 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 27 Mar 2025 21:07:08 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings [v2]
In-Reply-To: <l7z7cSc2UTT-HLuz9n3o42fK0DGDPRmvgNh40YxMc90=.efed7e2a-8e61-46ae-82c8-b798291e908a@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
 <fq4159DVTAlqvt68sc1oQm835p7CCXymdhSSqTfwDzQ=.38bc3de8-89f6-4adf-988c-d288ba66f6de@github.com>
 <l7z7cSc2UTT-HLuz9n3o42fK0DGDPRmvgNh40YxMc90=.efed7e2a-8e61-46ae-82c8-b798291e908a@github.com>
Message-ID: <fpsHSGoD-blSk2X6nOuhTcvXmLACv7CT_cj79JVu-CE=.b38fd440-23f9-4a8e-9ce6-87509adbe105@github.com>

On Mon, 24 Mar 2025 20:59:22 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Hi @valeriepeng, I found code assuming `com.sun.crypto.provider.PBEKey` contains only ASCII, please find my suggestions in the review comments. I also added a suggestion for the tests, in order to increase the coverage in that regard.
>> 
>> All the patches are verified to cleanly apply on top of this PR branch, when copied through the GitHub's copy button and applied with `xclip -sel clip | git apply`.
>
>> Hi @valeriepeng, I found code assuming `com.sun.crypto.provider.PBEKey` contains only ASCII, please find my suggestions in the review comments. I also added a suggestion for the tests, in order to increase the coverage in that regard.
>> 
>> All the patches are verified to cleanly apply on top of this PR branch, when copied through the GitHub's copy button and applied with `xclip -sel clip | git apply`.
> 
> Great, thanks for catching this!

> Hi @valeriepeng,
> 
> I have left a couple more comments, and taken advantage to do a more complete review.
> 
> Please note that I haven't finished reviewing `TestPBKD.java` (for example, we can still do some of the deleted checks). However I wanted to left a partial review in-advance, as I will be on PTO until next Tuesday.

Sure, I will wait for you to complete the review, no hurry.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24068#issuecomment-2759473810

From hchao at openjdk.org  Thu Mar 27 21:21:04 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 21:21:04 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v20]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <ojJ3al4KiqsZd0Ga8a2r8jXaZAder07Kocn1oiW8xZw=.85ba72df-b4e8-4f76-8431-46c9f531ddfc@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra line break

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/8ec7784d..da29c5e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=18-19

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

PR: https://git.openjdk.org/jdk/pull/23532

From mullan at openjdk.org  Thu Mar 27 21:21:04 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 21:21:04 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v20]
In-Reply-To: <ojJ3al4KiqsZd0Ga8a2r8jXaZAder07Kocn1oiW8xZw=.85ba72df-b4e8-4f76-8431-46c9f531ddfc@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <ojJ3al4KiqsZd0Ga8a2r8jXaZAder07Kocn1oiW8xZw=.85ba72df-b4e8-4f76-8431-46c9f531ddfc@github.com>
Message-ID: <uvyqIU-QyrOxdSoyJaiz_3Qx2Lo8mTx2p09Qs1xNTxQ=.395cff2b-89d5-434d-8333-4fa08f2bad0f@github.com>

On Thu, 27 Mar 2025 21:17:15 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra line break

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23532#pullrequestreview-2723401945

From hchao at openjdk.org  Thu Mar 27 21:21:06 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 21:21:06 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v19]
In-Reply-To: <RoOWo1FqXKK22AfCGHHqyNvp-ER8ksvQxVc6tPiEx8I=.6df54c11-b108-4fcd-a050-0ec2041fca36@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <-8INCAnzcn1O-2h6yz9SeUdTNptYATbdTUdm_fBu1R0=.7a2f15c0-9bef-4f38-9ec9-a736cef8062d@github.com>
 <RoOWo1FqXKK22AfCGHHqyNvp-ER8ksvQxVc6tPiEx8I=.6df54c11-b108-4fcd-a050-0ec2041fca36@github.com>
Message-ID: <jF5FhdEvCkXgshyuz8kr2v9t484bYCvMnOdUXJruGTE=.5e214e0d-9836-4722-a7f7-3be244280010@github.com>

On Thu, 27 Mar 2025 19:40:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add CEN/LOC summary warning to Informational Warnings
>
> src/jdk.jartool/share/man/jarsigner.md line 929:
> 
>> 927: 
>> 928: internalConsistenciesDetected
>> 929: 
> 
> I don't think you need a line break here, the other warnings don't.

Removed line break.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23532#discussion_r2017612804

From hchao at openjdk.org  Thu Mar 27 21:29:05 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 27 Mar 2025 21:29:05 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v21]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <kTl1v-5O624vc9zvMB3ai-Dw3hNwAs2EpN79O2SviMU=.54294bed-5677-497e-bf2e-628cde3b856f@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/da29c5e9..4c801be1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=19-20

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

PR: https://git.openjdk.org/jdk/pull/23532

From mullan at openjdk.org  Thu Mar 27 21:39:43 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 27 Mar 2025 21:39:43 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v21]
In-Reply-To: <kTl1v-5O624vc9zvMB3ai-Dw3hNwAs2EpN79O2SviMU=.54294bed-5677-497e-bf2e-628cde3b856f@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <kTl1v-5O624vc9zvMB3ai-Dw3hNwAs2EpN79O2SviMU=.54294bed-5677-497e-bf2e-628cde3b856f@github.com>
Message-ID: <k60Tyfuah318_DNm2o-FuLgZaH_WN1sx5r96MyP9EC0=.d43deb22-ffa3-4aa5-b2a8-b0f1a74ec806@github.com>

On Thu, 27 Mar 2025 21:29:05 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23532#pullrequestreview-2723434058

From valeriep at openjdk.org  Thu Mar 27 21:55:25 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 27 Mar 2025 21:55:25 GMT
Subject: RFR: 8348732: SunJCE and SunPKCS11 have different PBE key
 encodings [v3]
In-Reply-To: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
References: <LP5tBs5x2ohaBW-kGPz4Sq4S2J3rxmXyhtefkj5gAb4=.c904b83a-b137-4cc7-86fb-9da40e72e0dc@github.com>
Message-ID: <J7-E3ZV9s6aqODQ0bXF5bv-1L07ZypQM_vj4rMNKWXQ=.fcbbe507-5b11-4c25-9a3d-4e91827c02ba@github.com>

> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings.
> 
> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility.

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  removed now-redundant utility method and extra leading space.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24068/files
  - new: https://git.openjdk.org/jdk/pull/24068/files/13a3f932..b7b19438

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24068&range=01-02

  Stats: 30 lines in 2 files changed: 0 ins; 25 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24068.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24068/head:pull/24068

PR: https://git.openjdk.org/jdk/pull/24068

From vpaprotski at openjdk.org  Thu Mar 27 22:40:28 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 27 Mar 2025 22:40:28 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v7]
In-Reply-To: <AnI5wa6uS6VX6O-SqdEwFQQ7Hgd666wt_gpnATxQ1ZM=.2de88266-5d2d-4ee1-bc66-888f707ceae1@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <J8hfAKnOa4N_bT941kRZA4O3f43r2wFJlxe6GTKTQw0=.109cb8fd-d53c-4c52-b968-d6352e26a2a4@github.com>
 <AnI5wa6uS6VX6O-SqdEwFQQ7Hgd666wt_gpnATxQ1ZM=.2de88266-5d2d-4ee1-bc66-888f707ceae1@github.com>
Message-ID: <xY8Woa0QRiQWAK5jJ-bGdtU93LJVGH2wUmx9EnUlhAA=.88183983-e331-4045-a23b-a5b44b1621da@github.com>

On Thu, 27 Mar 2025 18:11:32 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - prettify test
>
> Wait on integration.  I need to check something

Let me know if I can 'invoke' integrate @ascarpino ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2759693944

From ascarpino at openjdk.org  Thu Mar 27 23:08:54 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Mar 2025 23:08:54 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v7]
In-Reply-To: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
Message-ID: <wcFAfL9EVpk4YAPe48kukjOrHQxbVF6Z57B9oj7VOiI=.5cf8f6c3-3c75-4cd3-9f20-952c511545aa@github.com>

> Hi,
> 
> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
> 
> thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  code review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23647/files
  - new: https://git.openjdk.org/jdk/pull/23647/files/799c2acc..6ff9f8f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23647&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23647&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23647/head:pull/23647

PR: https://git.openjdk.org/jdk/pull/23647

From ascarpino at openjdk.org  Thu Mar 27 23:15:10 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 27 Mar 2025 23:15:10 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v8]
In-Reply-To: <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
Message-ID: <6dwvEmNBtqHw5Nn6SIRlNMkL_jgp9vKZo9H7DBxFgIQ=.62b6e849-3688-4cb2-8978-2c00327bd1a8@github.com>

On Thu, 27 Mar 2025 19:13:59 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright stmt

Thanks.  The test now passes.

-------------

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23719#pullrequestreview-2723890584

From abarashev at openjdk.org  Thu Mar 27 23:57:15 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 27 Mar 2025 23:57:15 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <ds03CayRYDY791LznOwBSTtOQZER-fwAcgtLpJDWfRs=.f7b2b513-a677-4586-8841-ca20131ea008@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
 <ds03CayRYDY791LznOwBSTtOQZER-fwAcgtLpJDWfRs=.f7b2b513-a677-4586-8841-ca20131ea008@github.com>
Message-ID: <QnN5cnKVLSKxo0S8ObVcPKML47EDgF_h5HE5UY6u-mo=.7af5c08c-a4c6-475f-8af4-c75b45e62470@github.com>

On Thu, 27 Mar 2025 18:33:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix java.security syntax. Remove whitespace.
>
> test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 127:
> 
>> 125:      *                      a well-formed TLS message.
>> 126:      */
>> 127:     protected ByteBuffer extractHandshakeMsg(ByteBuffer tlsRecord,
> 
> This seems like quite a useful method! How about adding it to the superclass `SSLEngineTemplate` so that we might use it for other tests in the future.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017733958

From abarashev at openjdk.org  Fri Mar 28 00:02:22 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 28 Mar 2025 00:02:22 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <6hVzy0HMZHmVPDLLvz7bVTIVfTtYnfx2DdgMXmiVNcc=.818264da-a194-4d27-94aa-0c892c274d39@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
 <6hVzy0HMZHmVPDLLvz7bVTIVfTtYnfx2DdgMXmiVNcc=.818264da-a194-4d27-94aa-0c892c274d39@github.com>
Message-ID: <chKSZ28Gs2WMBAN28-dH907PikvrHOqOoXQltvwU75A=.39a72c37-77db-44fd-a9ca-fa809ce5986b@github.com>

On Thu, 27 Mar 2025 14:13:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix java.security syntax. Remove whitespace.
>
> src/java.base/share/classes/sun/security/ssl/SSLScope.java line 39:
> 
>> 37:     CERTIFICATE_SIGNATURE("CertificateSignature");
>> 38: 
>> 39:     final String name;
> 
> Make this `private`.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017736674

From abarashev at openjdk.org  Fri Mar 28 00:02:22 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 28 Mar 2025 00:02:22 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <YzYJVx9MwEt6HIVSs6Ce1BzksvBkIp956GVnGcN5gok=.946463ae-5284-49fe-8e1d-29b89e571c97@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
 <MXlcHYFMydllfn0ryLs8H0IjPXstxuNvXUhy4klxUZ8=.801a8e70-7a06-4541-a821-335fa3decd96@github.com>
 <YzYJVx9MwEt6HIVSs6Ce1BzksvBkIp956GVnGcN5gok=.946463ae-5284-49fe-8e1d-29b89e571c97@github.com>
Message-ID: <itOydNNNSzAxHiWXPqqsk76S8rm2uOBcasY1bRmJ8GA=.4b2459c5-d5bd-40b5-85ad-ca302d2d7f8e@github.com>

On Thu, 27 Mar 2025 19:33:46 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SignatureScheme/AbstractCheckSignatureSchemes.java line 77:
>> 
>>> 75:     }
>>> 76: 
>>> 77:     protected String getProtocol() {
>> 
>> I'd be more inclined to make this abstract and force subclasses to override it.
>
> Will do. I also though about it but since the original `SigSchemePropOrdering` test had "TLSv1.2" I kept it as default.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017736970

From abarashev at openjdk.org  Fri Mar 28 00:02:22 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 28 Mar 2025 00:02:22 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v19]
In-Reply-To: <J6L02_5zJjQJ71FYVymyeebnKhM1GQCxzQWXvWhsrxY=.d0011d91-3df2-41dc-88ae-ee70a23a42df@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <1YfydXZsLrY1nLATCJRRXB5te0jgenmTDuaWuSY_eKY=.48204989-4ec7-46d6-a3c9-0fdb608a6134@github.com>
 <MXlcHYFMydllfn0ryLs8H0IjPXstxuNvXUhy4klxUZ8=.801a8e70-7a06-4541-a821-335fa3decd96@github.com>
 <YzYJVx9MwEt6HIVSs6Ce1BzksvBkIp956GVnGcN5gok=.946463ae-5284-49fe-8e1d-29b89e571c97@github.com>
 <J6L02_5zJjQJ71FYVymyeebnKhM1GQCxzQWXvWhsrxY=.d0011d91-3df2-41dc-88ae-ee70a23a42df@github.com>
Message-ID: <t1r53R7EjezVbbx07u-sXef6qvAJd_sZoGW5WWyC35c=.612aa55c-46f8-4e22-ace1-b4fe40f55858@github.com>

On Thu, 27 Mar 2025 19:38:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Actually this is done on purpose to check case-insensitive matching, I use this approach in other tests as well.
>
> Ok, please add a comment above indicating that.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2017736380

From abarashev at openjdk.org  Fri Mar 28 00:33:36 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 28 Mar 2025 00:33:36 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v20]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <ynYYUyHV4cweiADkgUi2BigtLTkBBV8-rmTPRkyyqeM=.64a0c5e4-ff99-4fa2-84e5-b187838b68bc@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

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/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/edce779d..1c203b49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=18-19

  Stats: 151 lines in 6 files changed: 83 ins; 61 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681

PR: https://git.openjdk.org/jdk/pull/23681

From abarashev at openjdk.org  Fri Mar 28 03:12:40 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 28 Mar 2025 03:12:40 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v21]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <EaAEFLUXNUsl7nOKzCQOVTFHkoNkwVOit1RNAHidMx8=.b944b335-dc0d-4a7b-a2c4-23fc9d734b70@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/1c203b49..9fa4f99a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=19-20

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681

PR: https://git.openjdk.org/jdk/pull/23681

From weijun at openjdk.org  Fri Mar 28 13:10:21 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Mar 2025 13:10:21 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v7]
In-Reply-To: <wcFAfL9EVpk4YAPe48kukjOrHQxbVF6Z57B9oj7VOiI=.5cf8f6c3-3c75-4cd3-9f20-952c511545aa@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <wcFAfL9EVpk4YAPe48kukjOrHQxbVF6Z57B9oj7VOiI=.5cf8f6c3-3c75-4cd3-9f20-952c511545aa@github.com>
Message-ID: <EE5EAF_EnUNCb7bdLN7byTtR91-1kSx-v5OFjpzu2tY=.4153390e-9b23-4d2e-9735-7d4d16ae2032@github.com>

On Thu, 27 Mar 2025 23:08:54 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

LGTM.

-------------

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23647#pullrequestreview-2725456861

From weijun at openjdk.org  Fri Mar 28 13:42:24 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 28 Mar 2025 13:42:24 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v21]
In-Reply-To: <kTl1v-5O624vc9zvMB3ai-Dw3hNwAs2EpN79O2SviMU=.54294bed-5677-497e-bf2e-628cde3b856f@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <kTl1v-5O624vc9zvMB3ai-Dw3hNwAs2EpN79O2SviMU=.54294bed-5677-497e-bf2e-628cde3b856f@github.com>
Message-ID: <ogwqbdbXbvr-Lyu8qjcjFnKVmJ0I90yu_rX8mmgyT4U=.23ac2bb3-db7c-4ab5-97f9-2ac2351ac2ab@github.com>

On Thu, 27 Mar 2025 21:29:05 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Final comments:
1. The warning message "Manifest attribute %s is present..." is not 100% precise, should be "Manifest main attribute %s is present...".
2. The manifest does not need to be at the first position when reading as a `JarFile` (especially we are not comparing the order now), so suggest changing the last lines in `crossCheckEntries` to

jarFile.stream()
        .map(JarEntry::getName)
        .filter(n -> !locEntries.contains(n) && !n.equals(JarFile.MANIFEST_NAME))
        .forEach(n -> crossChkWarnings.add(String.format(rb.getString(
                        "entry.1.present.when.reading.jarfile.but.missing.via.jarinputstream"), n)));

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23532#issuecomment-2761397907

From vpaprotski at openjdk.org  Fri Mar 28 14:33:30 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Fri, 28 Mar 2025 14:33:30 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v8]
In-Reply-To: <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
Message-ID: <XCvIBcA93w540ao0lkkeDwWj7u9M3ay1r-iuSPFuGtY=.f7b9f3f5-3613-4784-8fa3-5d3607e1e2a7@github.com>

On Thu, 27 Mar 2025 19:13:59 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright stmt

Thanks Tony!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2761529451

From duke at openjdk.org  Fri Mar 28 14:33:30 2025
From: duke at openjdk.org (duke)
Date: Fri, 28 Mar 2025 14:33:30 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v8]
In-Reply-To: <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
Message-ID: <RhMKL4N_KSRAn_3c4oPF7v7AytcNI3Lq6nCvcK_ZJS0=.4f14670a-802a-4dac-a416-40bf8bffe8a5@github.com>

On Thu, 27 Mar 2025 19:13:59 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright stmt

@vpaprotsk 
Your change (at version 0a4230aa41f7cb5ddf5e2978f89ad4f0ec231e88) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2761532342

From mullan at openjdk.org  Fri Mar 28 14:42:25 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 28 Mar 2025 14:42:25 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v8]
In-Reply-To: <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
Message-ID: <ao31OOBdNaYO4bNsYMfGABS7gIIohliWk7C2yLy69_Q=.8f856038-b4b9-47be-b518-e5748e88158e@github.com>

On Thu, 27 Mar 2025 19:13:59 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright stmt

I think it would also be useful to write a release note describing the approximate performance improvement gains for the crypto algorithms as displayed in your chart. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2761566550

From vpaprotski at openjdk.org  Fri Mar 28 15:23:34 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Fri, 28 Mar 2025 15:23:34 GMT
Subject: Integrated: 8350459: MontgomeryIntegerPolynomialP256 multiply
 intrinsic with AVX2 on x86_64
In-Reply-To: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
Message-ID: <JCE7nC6pmW8rBjzvGmzLhh6QMDkp0qzT6ongQ7nFgS8=.ec07602d-d31b-4e32-b9ee-ac2dff727380@github.com>

On Thu, 20 Feb 2025 21:49:42 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
> 
> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
> 
> Before (no AVX512)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
> 
> After (with AVX2)
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
> 
> 
> Before (with AVX512):
> 
> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  ops/s
> SignatureBench.ECDSA.verify  SHA256withECDSA        102...

This pull request has now been integrated.

Changeset: a269bef0
Author:    Volodymyr Paprotski <vpaprotski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a269bef04cf3c9c8b731edcbf7618624f7571a2d
Stats:     760 lines in 9 files changed: 641 ins; 16 del; 103 mod

8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64

Reviewed-by: ascarpino, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/23719

From kdriver at openjdk.org  Fri Mar 28 15:30:55 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 28 Mar 2025 15:30:55 GMT
Subject: Integrated: 8341775: Duplicate manifest files are removed by jarsigner
 after signing
In-Reply-To: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
References: <LchuZ7oG_tWj6JtW32bwpO70ekeys_FTVTvLtg2hass=.7450fa46-1764-4fc7-b967-eb126b6cfe41@github.com>
Message-ID: <vGsUjhyboOqYDT9bKYRTW3HJsECK0KtwdMfQacdMEw0=.37d12123-005c-4c43-a9a6-6df6b17283b2@github.com>

On Mon, 18 Nov 2024 22:40:40 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> JDK-8341775: In the case where there is a *single* META-INF directory but potentially *multiple* manifest files of different cases, print a warning before selecting the first one and ignoring the rest (the current behavior should be maintained).

This pull request has now been integrated.

Changeset: d8090337
Author:    Kevin Driver <kdriver at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8090337ee8ea763bca4e8e3baaf8ee4dd3d6214
Stats:     118 lines in 4 files changed: 117 ins; 0 del; 1 mod

8341775: Duplicate manifest files are removed by jarsigner after signing

Reviewed-by: weijun, hchao

-------------

PR: https://git.openjdk.org/jdk/pull/22222

From abarashev at openjdk.org  Fri Mar 28 15:47:24 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 28 Mar 2025 15:47:24 GMT
Subject: RFR: 8346129: Simplify EdDSA & XDH curve name usage [v7]
In-Reply-To: <wcFAfL9EVpk4YAPe48kukjOrHQxbVF6Z57B9oj7VOiI=.5cf8f6c3-3c75-4cd3-9f20-952c511545aa@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
 <wcFAfL9EVpk4YAPe48kukjOrHQxbVF6Z57B9oj7VOiI=.5cf8f6c3-3c75-4cd3-9f20-952c511545aa@github.com>
Message-ID: <xlX74gBXuv2brZfgNmTk5PpYR97E7xY26mYgsE9Qbk4=.024cd3bc-b1db-4792-b67f-1e64ff64d008@github.com>

On Thu, 27 Mar 2025 23:08:54 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
>> 
>> thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

LGTM

-------------

Marked as reviewed by abarashev (Author).

PR Review: https://git.openjdk.org/jdk/pull/23647#pullrequestreview-2725964720

From aturbanov at openjdk.org  Fri Mar 28 18:23:49 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 28 Mar 2025 18:23:49 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v8]
In-Reply-To: <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
Message-ID: <NZ7zKisdU7Pq1Ew6g3ZO3UcCCdO7bO-77mHI304FHTY=.20600228-7cc3-4f44-a3ed-8b16f6882be4@github.com>

On Thu, 27 Mar 2025 19:13:59 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Add AVX2 montgomery multiplication intrinsic. (About 60-80% gain)
>> 
>> Also add reduction to existing AVX512 multiplication (this was left-over from https://github.com/openjdk/jdk/pull/19893 where a quick fix was required). This is mostly for cleanup, but there is about 1-2% gain.
>> 
>> Before (no AVX512)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   3720.589 ?  17.879  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   3605.940 ?  15.807  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1076.502 ?   4.190  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1069.624 ?   2.484  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40   830.448 ? 2.285  ops/s
>> 
>> After (with AVX2)
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt      Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40   6000.496 ?  39.923  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40   5739.878 ?  34.838  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA        1024          256              thrpt   40   1942.437 ?  12.179  ops/s
>> SignatureBench.ECDSA.verify  SHA256withECDSA       16384          256              thrpt   40   1921.770 ?   8.992  ops/s
>> Benchmark                             (algorithm)  (keyLength)  (kpgAlgorithm)  (provider)   Mode  Cnt     Score   Error  Units
>> KeyAgreementBench.EC.generateSecret          ECDH          256              EC              thrpt   40  1399.761 ? 6.238  ops/s
>> 
>> 
>> Before (with AVX512):
>> 
>> Benchmark                        (algorithm)  (dataSize)  (keyLength)  (provider)   Mode  Cnt       Score     Error  Units
>> SignatureBench.ECDSA.sign    SHA256withECDSA        1024          256              thrpt   40    9621.950 ?  27.260  ops/s
>> SignatureBench.ECDSA.sign    SHA256withECDSA       16384          256              thrpt   40    8975.654 ?  26.707  o...
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright stmt

src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java line 164:

> 162:     protected void mult(long[] a, long[] b, long[] r) {
> 163:         multImpl(a, b, r);
> 164:         reducePositive(r);

`reducePositive` is now seems unused

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2019135976

From vpaprotski at openjdk.org  Fri Mar 28 20:13:24 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Fri, 28 Mar 2025 20:13:24 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v8]
In-Reply-To: <NZ7zKisdU7Pq1Ew6g3ZO3UcCCdO7bO-77mHI304FHTY=.20600228-7cc3-4f44-a3ed-8b16f6882be4@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
 <NZ7zKisdU7Pq1Ew6g3ZO3UcCCdO7bO-77mHI304FHTY=.20600228-7cc3-4f44-a3ed-8b16f6882be4@github.com>
Message-ID: <9TJyGXccPFnDI60b2Wg3ZIuQH2nd6LC-pFgEs6p8x1c=.6308a314-dd48-4cb3-9986-8e6eb754d4c2@github.com>

On Fri, 28 Mar 2025 18:20:31 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright stmt
>
> src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java line 164:
> 
>> 162:     protected void mult(long[] a, long[] b, long[] r) {
>> 163:         multImpl(a, b, r);
>> 164:         reducePositive(r);
> 
> `reducePositive` is now seems unused

oh.. hmm.. I had a second PR that I decided wasnt worth it that was going to reuse this code.. 

Will create a second JBS and remove

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23719#discussion_r2019286778

From vpaprotski at openjdk.org  Fri Mar 28 20:23:20 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Fri, 28 Mar 2025 20:23:20 GMT
Subject: RFR: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic
 with AVX2 on x86_64 [v8]
In-Reply-To: <ao31OOBdNaYO4bNsYMfGABS7gIIohliWk7C2yLy69_Q=.8f856038-b4b9-47be-b518-e5748e88158e@github.com>
References: <UBW5gkkOgWc7M7skNIHXauYZh6AGxg7BfopD7IOwhnk=.9ccc8002-b53e-4bd6-8582-370f1499310c@github.com>
 <CXQnQm1sX7QdKyLF13Y1DVu7x6zrSfRv0Oxb0c8cIo8=.2e6a8053-ee5d-4dc3-967b-fbf1e6efee97@github.com>
 <ao31OOBdNaYO4bNsYMfGABS7gIIohliWk7C2yLy69_Q=.8f856038-b4b9-47be-b518-e5748e88158e@github.com>
Message-ID: <Advmi9fZv5Rtixat1sEcFyXULEg8flisKQHO4et19Js=.8c9f1952-d267-42d6-9e8e-e1dcc27a26e8@github.com>

On Fri, 28 Mar 2025 14:39:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I think it would also be useful to write a release note describing the approximate performance improvement gains for the crypto algorithms as displayed in your chart. Thanks.

@seanjmullan I think I only done that once, cant find the 'instructions'.. I think Jamil had helped me, but.. (https://bugs.openjdk.org/browse/JDK-8297970) "Create subtask with 'release-note' label?"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23719#issuecomment-2762362675

From mullan at openjdk.org  Fri Mar 28 20:27:17 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 28 Mar 2025 20:27:17 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v21]
In-Reply-To: <EaAEFLUXNUsl7nOKzCQOVTFHkoNkwVOit1RNAHidMx8=.b944b335-dc0d-4a7b-a2c4-23fc9d734b70@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <EaAEFLUXNUsl7nOKzCQOVTFHkoNkwVOit1RNAHidMx8=.b944b335-dc0d-4a7b-a2c4-23fc9d734b70@github.com>
Message-ID: <pxSTcBQmlbBZ_bL1SI2hO2BjL4p1jsauzIiUcQX3lmo=.042464d8-6a3c-4387-82d8-1948b87f8990@github.com>

On Fri, 28 Mar 2025 03:12:40 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

A final review, just a couple of minor comments.

src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 221:

> 219: 
> 220:     // Handshake signature scope.
> 221:     public static final Set<SSLScope> HANDSHAKE_SCOPE =

I think this constant and `CERTIFICATE_SCOPE` can be package-private.

src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 554:

> 552:     // Returns true if this signature scheme is supported for the given
> 553:     // protocol version and SSL scopes.
> 554:     boolean isSupportedProtocol(ProtocolVersion version, Set<SSLScope> scopes) {

I think this method and `isAllowed` can be private.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23681#pullrequestreview-2726622461
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2019284852
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2019286085

From hchao at openjdk.org  Sat Mar 29 05:37:00 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Sat, 29 Mar 2025 05:37:00 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v22]
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <C7NcXsFINaFM6AGcC44qwzas9cSkH-CXTzvn6mE29pU=.e091d718-fb63-45e8-b2de-c58c7ffd6d52@github.com>

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:

  Update with Weijun's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23532/files
  - new: https://git.openjdk.org/jdk/pull/23532/files/4c801be1..78093d4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23532&range=20-21

  Stats: 17 lines in 2 files changed: 0 ins; 10 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23532/head:pull/23532

PR: https://git.openjdk.org/jdk/pull/23532

From weijun at openjdk.org  Sat Mar 29 12:17:10 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 29 Mar 2025 12:17:10 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v22]
In-Reply-To: <C7NcXsFINaFM6AGcC44qwzas9cSkH-CXTzvn6mE29pU=.e091d718-fb63-45e8-b2de-c58c7ffd6d52@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <C7NcXsFINaFM6AGcC44qwzas9cSkH-CXTzvn6mE29pU=.e091d718-fb63-45e8-b2de-c58c7ffd6d52@github.com>
Message-ID: <V8ygeh_5yyuT2QIM9qFsRuGFr79Xwbs6tfI9x0IOiio=.d391c960-a12b-4cc4-8306-6329ec837d40@github.com>

On Sat, 29 Mar 2025 05:37:00 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with Weijun's comments

LGTM. Thanks for the patience.

-------------

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23532#pullrequestreview-2727354857

From duke at openjdk.org  Mon Mar 31 11:14:14 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 31 Mar 2025 11:14:14 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <Kanyx8L0d27_yUHP15BCfzO8MDEE3_JfDlxaP7Ran_g=.571eca02-d927-4598-ac9e-ff19cef9f484@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
 <Kanyx8L0d27_yUHP15BCfzO8MDEE3_JfDlxaP7Ran_g=.571eca02-d927-4598-ac9e-ff19cef9f484@github.com>
Message-ID: <IrDjFB-31qorhKt_vwc2dL6LbQUq_7JMO2je_hGCa3I=.63a4319a-e334-4440-ac78-13165b4a23c3@github.com>

On Mon, 24 Mar 2025 02:38:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Further readability improvements.
>>  - Added asserts for array sizes
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1252:
> 
>> 1250:   // Currently we only have them for AVX512
>> 1251: #ifdef _LP64
>> 1252:   if (supports_evex() && supports_avx512bw()) {
> 
> supports_evex check looks redundant.

These are checks for two different feature bits: CPU_AVX512F and CPU_AVX512BW. Are you saying that the latter implies the former in every implementation of the spec?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2020853815

From abarashev at openjdk.org  Mon Mar 31 14:12:26 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 31 Mar 2025 14:12:26 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v21]
In-Reply-To: <pxSTcBQmlbBZ_bL1SI2hO2BjL4p1jsauzIiUcQX3lmo=.042464d8-6a3c-4387-82d8-1948b87f8990@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <EaAEFLUXNUsl7nOKzCQOVTFHkoNkwVOit1RNAHidMx8=.b944b335-dc0d-4a7b-a2c4-23fc9d734b70@github.com>
 <pxSTcBQmlbBZ_bL1SI2hO2BjL4p1jsauzIiUcQX3lmo=.042464d8-6a3c-4387-82d8-1948b87f8990@github.com>
Message-ID: <x-htSd_ugUoVV4lFigxE_ej3ekjlozi_Wz76EYl_6Ks=.844926e7-c34d-4ff9-a09c-98d31cac9ffc@github.com>

On Fri, 28 Mar 2025 20:08:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 221:
> 
>> 219: 
>> 220:     // Handshake signature scope.
>> 221:     public static final Set<SSLScope> HANDSHAKE_SCOPE =
> 
> I think this constant and `CERTIFICATE_SCOPE` can be package-private.

Done, thanks!

> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 554:
> 
>> 552:     // Returns true if this signature scheme is supported for the given
>> 553:     // protocol version and SSL scopes.
>> 554:     boolean isSupportedProtocol(ProtocolVersion version, Set<SSLScope> scopes) {
> 
> I think this method and `isAllowed` can be private.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2021126075
PR Review Comment: https://git.openjdk.org/jdk/pull/23681#discussion_r2021126283

From abarashev at openjdk.org  Mon Mar 31 14:17:50 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 31 Mar 2025 14:17:50 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v22]
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <4uYPOxTzWhL2Hnv6vfL4QZy4BaN7g0ei3hCuENQkBV8=.c0d62646-7a4f-4bb0-95fc-11fbfc9730c8@github.com>

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Adjust access modifiers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23681/files
  - new: https://git.openjdk.org/jdk/pull/23681/files/9fa4f99a..b6a15c57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23681&range=20-21

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23681/head:pull/23681

PR: https://git.openjdk.org/jdk/pull/23681

From duke at openjdk.org  Mon Mar 31 14:28:20 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 31 Mar 2025 14:28:20 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <_TOBoO4cMQpw4sgzIpNpQZ2w5wDgezKQZLe314DQ7zo=.813b81bf-ecc0-4f75-a0d6-fbb13dde594e@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
 <_TOBoO4cMQpw4sgzIpNpQZ2w5wDgezKQZLe314DQ7zo=.813b81bf-ecc0-4f75-a0d6-fbb13dde594e@github.com>
Message-ID: <JHUIfL3RpIiFSOyHesKuxqIfJKTzvDsQ2e3CzXvX2Gs=.3eac6881-4359-4117-a5d4-aeabc98c84d2@github.com>

On Mon, 24 Mar 2025 15:16:20 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Further readability improvements.
>>  - Added asserts for array sizes
>
> I still need to have a look at the sha3 changes, but I think I am done with the most complex part of the review. This was a really interesting bit of code to review!

@vpaprotsk , thanks a lot for the very thorough review!

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 270:
> 
>> 268: }
>> 269: 
>> 270: static void loadPerm(int destinationRegs[], Register perms,
> 
> `replXmm`? i.e. this function is replicating (any) Xmm register, not just perm?..

Since I am only using it for permutation describers, I thought this way it is easier to follow what is happening.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 327:
> 
>> 325: //
>> 326: //
>> 327: static address generate_dilithiumAlmostNtt_avx512(StubGenerator *stubgen,
> 
> Similar comments as to `generate_dilithiumAlmostInverseNtt_avx512`
> 
> - similar comment about the 'pair-wise' operation, updating `[j]` and `[j+l]` at a time.. 
> - somehow had less trouble following the flow through registers here, perhaps I am getting used to it. FYI, ended renaming some as:
> 
> // xmm16_27 = Temp1
> // xmm0_3 = Coeffs1
> // xmm4_7 = Coeffs2
> // xmm8_11 = Coeffs3
> // xmm12_15 = Coeffs4 = Temp2
> // xmm16_27 = Scratch

For me, it was easier to follow what goes where using the xmm... names (with the symbolic names you always have to remember which one overlaps with another and how much).

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 421:
> 
>> 419:   for (int i = 0; i < 8; i += 2) {
>> 420:     __ evpermi2d(xmm(i / 2 + 12), xmm(i), xmm(i + 1), Assembler::AVX_512bit);
>> 421:   }
> 
> Wish there was a more 'abstract' way to arrange this, so its obvious from the shape of the code what registers are input/outputs (i.e. and use the register arrays). Even though its just 'elementary index operations' `i/2 + 16` is still 'clever'. Couldnt think of anything myself though (same elsewhere in this function for the table permutes).

Well, this is how it is when we have three inputs, one of which also plays as output... At least the output is always the first one (so that one gets clobbered). This is why you have to replicate the permutation describer when you need both permutands later.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 509:
> 
>> 507: // coeffs (int[256]) = c_rarg0
>> 508: // zetas (int[256]) = c_rarg1
>> 509: static address generate_dilithiumAlmostInverseNtt_avx512(StubGenerator *stubgen,
> 
> Done with this function; Perhaps the 'permute table' is a common vector-algorithm pattern, but this is really clever!
> 
> Some general comments first, rest inline.
> 
> - The array names for registers helped a lot. And so did the new helper functions!
> - The java version of this code is quite intimidating to vectorize.. 3D loop, with geometric iteration variables.. and the literature is even more intimidating (discrete convolutions which I havent touched in two decades, ffts, ntts, etc.) Here is my attempt at a comment to 'un-scare' the next reader, though feel free to reword however you like.
> 
> The core of the (Java) loop is this 'pair-wise' operation:
>         int a = coeffs[j];
>         int b = coeffs[j + offset];
>         coeffs[j] = (a + b);
>         coeffs[j + offset] = montMul(a - b, -MONT_ZETAS_FOR_NTT[m]);
> 
> There are 8 'levels' (0-7); ('levels' are equivalent to (unrolling) the outer (Java) loop)
> At each level, the 'pair-wise-offset' doubles (2^l: 1, 2, 4, 8, 16, 32, 64, 128).
> 
> To vectorize this Java code, observe that at each level, REGARDLESS the offset, half the operations are the SUM, and the other half is the
> montgomery MULTIPLICATION (of the pair-difference with a constant). At each level, one 'just' has to shuffle
> the coefficients, so that SUMs and MULTIPLICATIONs line up accordingly.
> 
> Otherwise, this pattern is 'lightly similar' to a discrete convolution (compute integral/summation of two functions at every offset)
> 
> - I still would prefer (more) symbolic register names.. I wouldn't hold my approval over it so won't object if nobody else does, but register numbers are harder to 'see' through the flow. I ended up search/replacing/'annotating' to make it easier on myself to follow the flow of data:
> 
> // xmm8_11  = Perms1
> // xmm12_15 = Perms2
> // xmm16_27 = Scratch
> // xmm0_3 = CoeffsPlus
> // xmm4_7 = CoeffsMul
> // xmm24_27 = CoeffsMinus (overlaps with Scratch)
> 
> (I made a similar comment, but I think it is now hidden after the last refactor)
> - would prefer to see the helper functions to get ALL the registers passed explicitly (i.e. currently `montMulPerm`, `montQInvModR`, `dilithium_q`, `xmm29`, are implicit.). As a general rule, I've tried to set up all the registers up at the 'entry' function (`generate_dilithium*` in this case) and ...

I added some more comments, but I kept the xmm... names for the registers, just like with the ntt function.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 554:
> 
>> 552:   for (int i = 0; i < 8; i += 2) {
>> 553:     __ evpermi2d(xmm(i / 2 + 8), xmm(i), xmm(i + 1), Assembler::AVX_512bit);
>> 554:     __ evpermi2d(xmm(i / 2 + 12), xmm(i), xmm(i + 1), Assembler::AVX_512bit);
> 
> Took a bit to unscramble the flow, so a comment needed? Purpose 'fairly obvious' once I got the general shape of the level/algorithm (as per my top-level comment) but something like "shuffle xmm0-7 into xmm8-15"?

I hope the comment that I added at the beginning of the function sheds some light on the purpose of these permutations.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 656:
> 
>> 654:   for (int i = 0; i < 8; i++) {
>> 655:     __ evpsubd(xmm(i), k0, xmm(i + 8), xmm(i), false, Assembler::AVX_512bit);
>> 656:   }
> 
> Fairly clean as is, but could also be two sub_add calls, I think (you have to swap order of add/sub in the helper, to be able to clobber `xmm(i)`.. or swap register usage downstream, so perhaps not.. but would be cleaner) 
> 
>   sub_add(CoeffsPlus, Scratch, Perms1, CoeffsPlus, _masm);
>   sub_add(CoeffsMul,  &Scratch[4], Perms2, CoeffsMul, _masm);
> 
> 
> If nothing else, would had prefered to see the use of the register array variables

I would rather leave this alone, too. I was considering the same, but decided that this is fairly easy to follow, it would be more complicated to either add a new helper function or follow where there are overlaps in the symbolically named register sets.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 871:
> 
>> 869:   __ evpaddd(xmm5, k0, xmm1, barrettAddend, false, Assembler::AVX_512bit);
>> 870:   __ evpaddd(xmm6, k0, xmm2, barrettAddend, false, Assembler::AVX_512bit);
>> 871:   __ evpaddd(xmm7, k0, xmm3, barrettAddend, false, Assembler::AVX_512bit);
> 
> Fairly 'straightforward' transcription of the java code.. no comments from me.
> 
> At first glance using `xmm0_3`, `xmm4_7`, etc. might had been a good idea, but you only save one line per 4x group. (Unless you have one big loop, but I suspect that give you worse performance? Is that something you tried already? Might be worth it otherwise..)

I have considered this but decided to leave it alone (for the reason that you mentioned).

> src/java.base/share/classes/sun/security/provider/ML_DSA.java line 1418:
> 
>> 1416:                                          int twoGamma2, int multiplier) {
>> 1417:         assert (input.length == ML_DSA_N) && (lowPart.length == ML_DSA_N)
>> 1418:                 && (highPart.length == ML_DSA_N);
> 
> I wrote this test to test java-to-intrinsic correspondence. Might be good to include it (and add the other 4 intrinsics). This is very similar to all my other *Fuzz* tests I've been adding for my own intrinsics (and you made this test FAR easier to write by breaking out the java implementation; need to 'copy' that pattern myself)
> 
> import java.util.Arrays;
> import java.util.Random;
> 
> import java.lang.invoke.MethodHandle;
> import java.lang.invoke.MethodHandles;
> import java.lang.reflect.Field;
> import java.lang.reflect.Method;
> import java.lang.reflect.Constructor;
> 
> public class ML_DSA_Intrinsic_Test {
> 
>     public static void main(String[] args) throws Exception {
>         MethodHandles.Lookup lookup = MethodHandles.lookup();
>         Class<?> kClazz = Class.forName("sun.security.provider.ML_DSA");
>         Constructor<?> constructor = kClazz.getDeclaredConstructor(
>                 int.class);
>         constructor.setAccessible(true);
>         
>         Method m = kClazz.getDeclaredMethod("mlDsaNttMultiply",
>                 int[].class, int[].class, int[].class);
>         m.setAccessible(true);
>         MethodHandle mult = lookup.unreflect(m);
> 
>         m = kClazz.getDeclaredMethod("implDilithiumNttMultJava",
>                 int[].class, int[].class, int[].class);
>         m.setAccessible(true);
>         MethodHandle multJava = lookup.unreflect(m);
> 
>         Random rnd = new Random();
>         long seed = rnd.nextLong();
>         rnd.setSeed(seed);
>         //Note: it might be useful to increase this number during development of new intrinsics
>         final int repeat = 1000000;
>         int[] coeffs1 = new int[ML_DSA_N];
>         int[] coeffs2 = new int[ML_DSA_N];
>         int[] prod1 = new int[ML_DSA_N];
>         int[] prod2 = new int[ML_DSA_N];
>         try {
>             for (int i = 0; i < repeat; i++) {
>                 run(prod1, prod2, coeffs1, coeffs2, mult, multJava, rnd, seed, i);
>             }
>             System.out.println("Fuzz Success");
>         } catch (Throwable e) {
>             System.out.println("Fuzz Failed: " + e);
>         }
>     }
> 
>     private static final int ML_DSA_N = 256;
>     public static void run(int[] prod1, int[] prod2, int[] coeffs1, int[] coeffs2, 
>         MethodH...

We will consider it for a follow-up PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23860#issuecomment-2766414076
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021150966
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021151152
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021151361
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021151680
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021152095
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021152962
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021154571
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021156249

From duke at openjdk.org  Mon Mar 31 14:28:22 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 31 Mar 2025 14:28:22 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <PsyEjOjjVPhvslW1itlklaEZ7zraED6BQavpPxOxN8w=.0cab0c3b-837c-463c-b7f4-5a38b1ce8aeb@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
 <Wp_7I93VCaIAwdDoDeCDPlca3JKEDK4yJeEzfQQdj5M=.118ea8cc-7a0e-4dbc-9837-53cfaccc68de@github.com>
 <PsyEjOjjVPhvslW1itlklaEZ7zraED6BQavpPxOxN8w=.0cab0c3b-837c-463c-b7f4-5a38b1ce8aeb@github.com>
Message-ID: <F6oaqCaQHfnSVnaI6XwVwoYcyBWq9KPJ0PDRYIvdFaE=.451d4ec3-83c3-49b6-a3b1-b674bfb14b2b@github.com>

On Sun, 23 Mar 2025 00:21:18 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 119:
>> 
>>> 117: static address dilithiumAvx512PermsAddr() {
>>> 118:   return (address) dilithiumAvx512Perms;
>>> 119: }
>> 
>> Hear me out..  ...
>> enums!!
>> 
>> enum nttPermOffset {
>>   montMulPermsIdx = 0,
>>   nttL4PermsIdx = 64,
>>   nttL5PermsIdx = 192,
>>   nttL6PermsIdx = 320,
>>   nttL7PermsIdx = 448,
>>   nttInvL0PermsIdx = 704,
>>   nttInvL1PermsIdx = 832,
>>   nttInvL2PermsIdx = 960,
>>   nttInvL3PermsIdx = 1088,
>>   nttInvL4PermsIdx = 1216,
>> };
>> static address dilithiumAvx512PermsAddr(nttPermOffset offset) {
>>   return (address) dilithiumAvx512Perms + offset;
>> }
>
> belay that comment.. now that I looked at `generate_dilithiumAlmostInverseNtt_avx512`, I see why thats not the 'entire picture'..

I leave it as it is now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021149925

From duke at openjdk.org  Mon Mar 31 14:28:24 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 31 Mar 2025 14:28:24 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v10]
In-Reply-To: <2yP2P1VNWgQu6cWvn0_a_7LdidS71C6PWKcqGKTOHnc=.49f8ac0f-df23-4f1e-adb9-e03a3f2295b2@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <2N5Evij0f6qZi_pG3tqoz11aQbSnLG0YszqHR9ROfKI=.d44b16c6-d334-42c4-8de8-92eb41229248@github.com>
 <2yP2P1VNWgQu6cWvn0_a_7LdidS71C6PWKcqGKTOHnc=.49f8ac0f-df23-4f1e-adb9-e03a3f2295b2@github.com>
Message-ID: <m_ebURrfxd_YhF6rrVT3SrctPGeMy5U_5sOdVZNjP2c=.c48e1992-3be6-430c-92b6-79ec244539db@github.com>

On Sat, 22 Mar 2025 16:36:08 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 121:
> 
>> 119: static void montmulEven(int outputReg, int inputReg1,  int inputReg2,
>> 120:                         int scratchReg1, int scratchReg2,
>> 121:                         int parCnt, MacroAssembler *_masm) {
> 
> nitpick.. this could be made to look more like `montMul64()` by also taking in an array of registers.

I eliminated this function.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 160:
> 
>> 158:   for (int i = 0; i < 4; i++) {
>> 159:     __ vpmuldq(xmm(scratchRegs[i]), xmm(inputRegs1[i]), xmm(inputRegs2[i]),
>> 160:                Assembler::AVX_512bit);
> 
> using an array of registers, instead of array of ints would read somewhat more compact and fewer 'indirections' . i.e.
> 
> static void montMul64(XMMRegister outputRegs*, XMMRegister inputRegs1*, XMMRegister inputRegs2*,
> ...
>     __ vpmuldq(scratchRegs[i], inputRegs1[i], inputRegs2[i], Assembler::AVX_512bit);

I think from the names it is easy enough to see that we are really passing register names here and it is also easy to check that the indexes of the registers in the named arrays are really what the names of those arrays suggest, so I would like to leave this alone.

> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 645:
> 
>> 643: // poly1 (int[256]) = c_rarg1
>> 644: // poly2 (int[256]) = c_rarg2
>> 645: static address generate_dilithiumNttMult_avx512(StubGenerator *stubgen,
> 
> This would be 'nice to have', something 'lost' with the refactor..
> 
> As I was reviewing this (original) function, I was thinking, "there is nothing here _that_ specific to AVX512, mostly columnar&independent operations... This function could be made 'vector-length-independent'..."
> - double the loop length:
> 
> int iter = vector_len==Assembler::AVX_512bit?4:8;
> __ movl(len, 4); -> __ movl(len, iter);
> 
> - halve the register arrays.. (or keep them the same but shuffle them to make SURE the first half are in xmm0-xmm15 range)
> 
>   XMMRegister POLY1[] = {xmm0, xmm1, xmm12, xmm13};
>   XMMRegister POLY2[] = {xmm4, xmm5, xmm16, xmm17};
>   XMMRegister SCRATCH1[] = {xmm2, xmm3, xmm14, xmm15}; <<< here
>   XMMRegister SCRATCH2[] = {xmm6, xmm7, xmm18, xmm19}; <<< and here
>   XMMRegister SCRATCH3[] = {xmm8, xmm9, xmm10, xmm11};
> 
> - couple of other int constants (like the memory 'step' and such)
> - for assembler calls, like `evmovdqul` and `evpsubd`, need a few small new MacroAssembler helpers to instead generate VEX encoded versions (plenty of instructions already do that).
> - I think only the perm instruction was unique to evex (didnt really think of an alternative for AVX2.. but can be abstracted away with another helper)
> 
> Anyway; not suggesting its something you do here.. but it would be convenient to leave breadcrumbs/hooks for a future update so one of us can revisit this code and add AVX2 support. e.g. `parCnt` variable was very convenient before for exactly this, now its gone... it probably could be derived in each function from vector_len but..; Its now cleaner, but also harder to 'upgrade'?
> 
> Why AVX2? many of the newer (Atom/Ecore-based/EnableX86ECoreOpts) processors do not have AVX512 support, so its something I've been prioritizing recently
> 
> The alternative would be to write a completely separate AVX2 implementation, but that would be a shame, not to 'just' reuse this code.
> ?
> "For fun", I had even gone and parametrized the mult function with the `vector_len` to see how it would look (almost identical... to the original version):
> 
> static void montmulEven2(XMMRegister* outputReg, XMMRegister* inputReg1,  XMMRegister* inputReg2, XMMRegister* scratchReg1, 
>   XMMRegister* scratchReg2, XMMRegister montQInvModR, XMMRegister dilithium_q, int parCnt, int vector_len, ...

I'd like to leave this for another PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021150150
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021150516
PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021153931

From duke at openjdk.org  Mon Mar 31 14:28:21 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 31 Mar 2025 14:28:21 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v7]
In-Reply-To: <kBg6GrgsVt_pKZ2MfKEHbuEb9Uk5YFWWQ7tKUOKySH4=.106187c8-0bb4-4463-afd7-a406fce15fc4@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xeGVcNvhb8JogSwnBjlAln9bAiZMAeiOEC5XrH0FVX0=.564addcd-ee9a-4628-8df1-b546e7de45be@github.com>
 <kBg6GrgsVt_pKZ2MfKEHbuEb9Uk5YFWWQ7tKUOKySH4=.106187c8-0bb4-4463-afd7-a406fce15fc4@github.com>
Message-ID: <V-Um4_MZamQaQUXEwjGPIFyYG7kYWo3hS_XW0oE3j5s=.d454f8d7-789a-4009-aadc-024fe8a90971@github.com>

On Mon, 17 Mar 2025 19:22:41 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made the intrinsics test separate from the pure java test.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 45:
> 
>> 43: // Constants
>> 44: //
>> 45: ATTRIBUTE_ALIGNED(64) static const uint32_t dilithiumAvx512Consts[] = {
> 
> This is really nitpicking.. but could had loaded constants inline with `movl` without requiring an ExternalAddress()? 
> 
> Nice to have constants together, only complaint is we have 'magic offsets' in ASM to reach in for particular one..
> 
> This one isnt too bad, offset of 32bits is easy to inspect visually (`dilithiumAvx512ConstsAddr()` could take a parameter perhaps)

I added symbolic names for the indexes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021149647

From duke at openjdk.org  Mon Mar 31 14:28:25 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 31 Mar 2025 14:28:25 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v10]
In-Reply-To: <36fyT0z29o9GYLeQhpYkIT4d2By-8z7TEU8TGtT2uHI=.50647fa4-32ca-41ef-8287-075a70254143@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <2N5Evij0f6qZi_pG3tqoz11aQbSnLG0YszqHR9ROfKI=.d44b16c6-d334-42c4-8de8-92eb41229248@github.com>
 <2yP2P1VNWgQu6cWvn0_a_7LdidS71C6PWKcqGKTOHnc=.49f8ac0f-df23-4f1e-adb9-e03a3f2295b2@github.com>
 <36fyT0z29o9GYLeQhpYkIT4d2By-8z7TEU8TGtT2uHI=.50647fa4-32ca-41ef-8287-075a70254143@github.com>
Message-ID: <RlqToYqMgX0HTc-X_WNN2jlw9s0CjgrsIvxFqObeAwY=.31eb71b7-6a54-4f0c-aa88-c526b8e73402@github.com>

On Sun, 23 Mar 2025 00:26:20 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_dilithium.cpp line 216:
>> 
>>> 214: // Zmm8-Zmm23 used as scratch registers
>>> 215: // result goes to Zmm0-Zmm7
>>> 216: static void montMulByConst128(MacroAssembler *_masm) {
>> 
>> wish the inputs and output register arrays were explicit.. easier to follow that way
>
> Looking at this function some more.. I think you could remove this function and replace it with two calls to `montMul64`?
> 
>   montMul64(xmm0_3, xmm0_3, xmm29_29, Scratch*, _masm);
>   montMul64(xmm4_7, xmm4_7, xmm29_29, Scratch*, _masm);
>   ```
> Scratch would have to be defined..

I accepted this suggestion, it really saved quite a few lines of code, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021150687

From duke at openjdk.org  Mon Mar 31 14:28:26 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 31 Mar 2025 14:28:26 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v7]
In-Reply-To: <pqoTfEkEfzOcAOv5JLfWQa7ckVyZfmILw57FVSM7bRc=.a16fb1f6-2bf8-4503-89cc-3eab2df0f686@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <xeGVcNvhb8JogSwnBjlAln9bAiZMAeiOEC5XrH0FVX0=.564addcd-ee9a-4628-8df1-b546e7de45be@github.com>
 <kBg6GrgsVt_pKZ2MfKEHbuEb9Uk5YFWWQ7tKUOKySH4=.106187c8-0bb4-4463-afd7-a406fce15fc4@github.com>
 <MiV8AD5mEqWLf_DDaoTF7jG06Zd7bBloGuxRZqGtN3U=.e55cfe7f-eb52-4da1-bddd-01ce74cfc633@github.com>
 <pqoTfEkEfzOcAOv5JLfWQa7ckVyZfmILw57FVSM7bRc=.a16fb1f6-2bf8-4503-89cc-3eab2df0f686@github.com>
Message-ID: <tg8N7pyqL0slcHiljNo1zxkCLUQ76MXm_12Lc5poyII=.e0d32962-05db-43b4-a1c4-623bba718c7e@github.com>

On Sat, 22 Mar 2025 16:11:02 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> These functions will not be used anywhere else and in ML_DSA.java all of the arrays passed to inrinsics are of the correct size.
>
> Works for me; just thought I would point it out, so its a 'premeditated' decision.

Well, I ended up putting some asserts in the java code, just in case...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021153417

From duke at openjdk.org  Mon Mar 31 14:28:27 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 31 Mar 2025 14:28:27 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v5]
In-Reply-To: <uUNg9Inwc5sySYy-v52dgYVTSxNU0n7EQZdsjQESTsY=.b9bfb2ab-42ef-40fc-9173-6a141adfac38@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <3bphXKLpIpxAZP-FEOeob6AaHbv0BAoEceJka64vMW8=.3e4f74e0-9479-4926-b365-b08d8d702692@github.com>
 <uUNg9Inwc5sySYy-v52dgYVTSxNU0n7EQZdsjQESTsY=.b9bfb2ab-42ef-40fc-9173-6a141adfac38@github.com>
Message-ID: <bUWSTdt_26lSS9_P1W0PTVPvFnYGnmHcFhvWpK0-hzQ=.1a40b277-9642-45a7-a1d8-25ff039c0c0f@github.com>

On Thu, 6 Mar 2025 19:26:14 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Accepted review comments.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 409:
> 
>> 407:   __ evmovdquq(xmm29, Address(permsAndRots, 768), Assembler::AVX_512bit);
>> 408:   __ evmovdquq(xmm30, Address(permsAndRots, 832), Assembler::AVX_512bit);
>> 409:   __ evmovdquq(xmm31, Address(permsAndRots, 896), Assembler::AVX_512bit);
> 
> Matter of taste, but I liked the compactness of montmulEven; i.e. 
> 
> for (i=0; i<15; i++)
>     __ evmovdquq(xmm(17+i), Address(permsAndRots, 64*i), Assembler::AVX_512bit);

Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021155416

From duke at openjdk.org  Mon Mar 31 14:40:56 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 31 Mar 2025 14:40:56 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v12]
In-Reply-To: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
Message-ID: <jC0P2QJcg4d8sNdrxMl5u2I7wB2J3k8Kght-nyv8i_Y=.608416bb-0d15-48ec-91f9-ef2b4df8fb4b@github.com>

> By using the AVX-512 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Reacting to comments by Volodymyr.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23860/files
  - new: https://git.openjdk.org/jdk/pull/23860/files/56656894..7a9f6645

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23860&range=10-11

  Stats: 145 lines in 2 files changed: 24 ins; 91 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/23860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23860/head:pull/23860

PR: https://git.openjdk.org/jdk/pull/23860

From hchao at openjdk.org  Mon Mar 31 14:57:17 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 31 Mar 2025 14:57:17 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v21]
In-Reply-To: <k60Tyfuah318_DNm2o-FuLgZaH_WN1sx5r96MyP9EC0=.d43deb22-ffa3-4aa5-b2a8-b0f1a74ec806@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <kTl1v-5O624vc9zvMB3ai-Dw3hNwAs2EpN79O2SviMU=.54294bed-5677-497e-bf2e-628cde3b856f@github.com>
 <k60Tyfuah318_DNm2o-FuLgZaH_WN1sx5r96MyP9EC0=.d43deb22-ffa3-4aa5-b2a8-b0f1a74ec806@github.com>
Message-ID: <zlnXhftyOJgbE5SpzpKAy36GWeuOFQHtGrmGgzsbf4s=.88c5069b-4f8f-4f59-bbd1-b5125d79943c@github.com>

On Thu, 27 Mar 2025 21:37:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> Marked as reviewed by mullan (Reviewer).

@seanjmullan @wangweij Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23532#issuecomment-2766500057

From mullan at openjdk.org  Mon Mar 31 15:07:34 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Mar 2025 15:07:34 GMT
Subject: RFR: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC [v22]
In-Reply-To: <C7NcXsFINaFM6AGcC44qwzas9cSkH-CXTzvn6mE29pU=.e091d718-fb63-45e8-b2de-c58c7ffd6d52@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
 <C7NcXsFINaFM6AGcC44qwzas9cSkH-CXTzvn6mE29pU=.e091d718-fb63-45e8-b2de-c58c7ffd6d52@github.com>
Message-ID: <stz7zv_PfI8cQNNhTPCZXFZFxbAVflQRRa1NOHT1-_s=.d89d5790-d04d-40c5-97c0-7ba51b8bdf77@github.com>

On Sat, 29 Mar 2025 05:37:00 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.
>
> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with Weijun's comments

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23532#pullrequestreview-2729612134

From hchao at openjdk.org  Mon Mar 31 15:07:35 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 31 Mar 2025 15:07:35 GMT
Subject: Integrated: 8339280: jarsigner -verify performs cross-checking between
 CEN and LOC
In-Reply-To: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
References: <XU1-lMxHTctB5CRXinH8tDmX0jay43Ie1ONshV_-zLw=.35b6cea9-a104-427c-9955-a552940553a6@github.com>
Message-ID: <nogfj3pzPLoXJ4EStB7-BiheoddonehxIF16zc6JGos=.277be45c-e66c-4b5b-9ce6-b7018d022272@github.com>

On Sun, 9 Feb 2025 05:02:07 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> The jarsigner -verify command currently performs verification by reading from JarFile to navigate the central directory (CEN) headers. It is now enhanced to include cross-validation of entries between JarFile (CEN-based) and JarInputStream (stream-based) representations of the JAR. It emits earnings when detecting discrepancies between a JAR file?s central directory and its local file entries.

This pull request has now been integrated.

Changeset: bbd5b174
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bbd5b174c50346152a624317b6bd76ec48f7e551
Stats:     303 lines in 4 files changed: 303 ins; 0 del; 0 mod

8339280: jarsigner -verify performs cross-checking between CEN and LOC

Reviewed-by: mullan, weijun, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/23532

From mullan at openjdk.org  Mon Mar 31 15:33:10 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Mar 2025 15:33:10 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v22]
In-Reply-To: <4uYPOxTzWhL2Hnv6vfL4QZy4BaN7g0ei3hCuENQkBV8=.c0d62646-7a4f-4bb0-95fc-11fbfc9730c8@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <4uYPOxTzWhL2Hnv6vfL4QZy4BaN7g0ei3hCuENQkBV8=.c0d62646-7a4f-4bb0-95fc-11fbfc9730c8@github.com>
Message-ID: <84l4v1wraUToBSJca1Y8MEFXLLH2O5N_lraeq99OhBM=.4d1bd55d-e6da-42e0-9b43-05351ce694c1@github.com>

On Mon, 31 Mar 2025 14:17:50 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust access modifiers

Looks good. Please also add a release note (can be done after you integrate).

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23681#pullrequestreview-2729700320

From duke at openjdk.org  Mon Mar 31 15:38:15 2025
From: duke at openjdk.org (duke)
Date: Mon, 31 Mar 2025 15:38:15 GMT
Subject: RFR: 8352277: java.security documentation: incorrect regex syntax
 describing "usage" algorithm constraint [v2]
In-Reply-To: <rg7jRRQoK7guGmJ9u6yjYnNHU_MnkETyViXmXmWXIkk=.2607a0d0-d3a5-4bec-b9d1-c889744778c1@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
 <rg7jRRQoK7guGmJ9u6yjYnNHU_MnkETyViXmXmWXIkk=.2607a0d0-d3a5-4bec-b9d1-c889744778c1@github.com>
Message-ID: <EIGIQa0IanL0E0azeGUz2_iajkHGWSLF-oX28kZQUlM=.a56cb73a-3f4d-411d-bef9-bbc6569d44e8@github.com>

On Thu, 27 Mar 2025 14:42:36 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make syntax consistent with the rest of the file

@artur-oracle 
Your change (at version 18acc2378db77db451560371f3cc8a572ac07a88) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24231#issuecomment-2766614410

From abarashev at openjdk.org  Mon Mar 31 15:51:20 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 31 Mar 2025 15:51:20 GMT
Subject: Integrated: 8352277: java.security documentation: incorrect regex
 syntax describing "usage" algorithm constraint
In-Reply-To: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
References: <Rv2L1zGKgfCaUakt6iSrDX96pDHPt5NNoGkOVtaVHIg=.987e1590-c6b1-4c6b-a226-e2084e5eac1e@github.com>
Message-ID: <eHS55Fv0HCaIDJGjnsZXMTCIGQyeEuJTP_Wce_-_zFg=.d195e416-3a92-4839-9725-14a0139007bd@github.com>

On Tue, 25 Mar 2025 14:29:22 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> We have an incorrect regex syntax when describing a "usage" algorithm constraint. Current syntax indicates that usage types are optional while they are not: at least one usage type should be specified.

This pull request has now been integrated.

Changeset: 7a2e198e
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a2e198e9fec54158020a49165c1f4a4518e28d8
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

8352277: java.security documentation: incorrect regex syntax describing "usage" algorithm constraint

Reviewed-by: mullan, hchao, ascarpino

-------------

PR: https://git.openjdk.org/jdk/pull/24231

From ascarpino at openjdk.org  Mon Mar 31 16:02:59 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 31 Mar 2025 16:02:59 GMT
Subject: Integrated: 8346129: Simplify EdDSA & XDH curve name usage
In-Reply-To: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
References: <xqmXQ8N33wJn8JzFH6iIBgbh0kORY9PYQr1eqdYzGL4=.a458c029-4b65-499d-bc73-387c8640fedb@github.com>
Message-ID: <Sj6_kC6HaqJHrt1zoFpjyv1a8MISKXdR6uhFb7jQOVg=.34fea290-02be-4282-a88a-bfab98fa88ae@github.com>

On Fri, 14 Feb 2025 18:44:38 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a review for the following change. Naming conventions for EdDSA and XDH have inconsistencies between DisabledAlgorithms and KeyPairGenerator. These internal changes help make it more consistent when parsing the actual curve being used vs the broader algorithm name.
> 
> thanks
> 
> Tony

This pull request has now been integrated.

Changeset: e4e62789
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4e62789c7c89bd094480ca3fe19c123a34f9625
Stats:     221 lines in 4 files changed: 199 ins; 3 del; 19 mod

8346129: Simplify EdDSA & XDH curve name usage

Reviewed-by: weijun, abarashev

-------------

PR: https://git.openjdk.org/jdk/pull/23647

From mullan at openjdk.org  Mon Mar 31 16:26:15 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Mar 2025 16:26:15 GMT
Subject: RFR: 8351366: Remove the java.security.debug=scl option [v3]
In-Reply-To: <e4JMomXsEqb2w5vy8UmCthnpGhhihmdjWXH6BgMCVCA=.2afb021f-ba03-4782-aa41-7e770bee8984@github.com>
References: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
 <e4JMomXsEqb2w5vy8UmCthnpGhhihmdjWXH6BgMCVCA=.2afb021f-ba03-4782-aa41-7e770bee8984@github.com>
Message-ID: <WplKANaaTkmxVhvfv--6iBLZPbMEPzs66dShPi9WWEk=.312c69fe-a3de-449e-a644-2573e72ac00e@github.com>

On Wed, 26 Mar 2025 21:37:42 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> This option dumped the permissions that the SecureClassLoader assigns to ProtectionDomains, but with the disabling of the Security Manager in JDK 24, these permissions are always empty and the debugging has no value. So this option should be removed.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351366:Remove the java.security.debug=scl option

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24208#pullrequestreview-2729839128

From hchao at openjdk.org  Mon Mar 31 16:26:15 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 31 Mar 2025 16:26:15 GMT
Subject: RFR: 8351366: Remove the java.security.debug=scl option [v3]
In-Reply-To: <e4JMomXsEqb2w5vy8UmCthnpGhhihmdjWXH6BgMCVCA=.2afb021f-ba03-4782-aa41-7e770bee8984@github.com>
References: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
 <e4JMomXsEqb2w5vy8UmCthnpGhhihmdjWXH6BgMCVCA=.2afb021f-ba03-4782-aa41-7e770bee8984@github.com>
Message-ID: <SnkhPE1V53apYwRDxPdTc2Rtw5UbQ0S8Gbdq2IgrIdw=.df3263e0-b18a-4b06-ba2e-bdbaa7cde2cb@github.com>

On Wed, 26 Mar 2025 21:37:42 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> This option dumped the permissions that the SecureClassLoader assigns to ProtectionDomains, but with the disabling of the Security Manager in JDK 24, these permissions are always empty and the debugging has no value. So this option should be removed.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351366:Remove the java.security.debug=scl option

Marked as reviewed by hchao (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24208#pullrequestreview-2729843965

From duke at openjdk.org  Mon Mar 31 16:30:20 2025
From: duke at openjdk.org (duke)
Date: Mon, 31 Mar 2025 16:30:20 GMT
Subject: RFR: 8349583: Add mechanism to disable signature schemes based on
 their TLS scope [v22]
In-Reply-To: <4uYPOxTzWhL2Hnv6vfL4QZy4BaN7g0ei3hCuENQkBV8=.c0d62646-7a4f-4bb0-95fc-11fbfc9730c8@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
 <4uYPOxTzWhL2Hnv6vfL4QZy4BaN7g0ei3hCuENQkBV8=.c0d62646-7a4f-4bb0-95fc-11fbfc9730c8@github.com>
Message-ID: <B3R2cey7rmtE1GkHvchIwZ8t2v2UlFDV7MhTBGwCvY0=.b41cca61-1642-4c09-b142-60444fa251b7@github.com>

On Mon, 31 Mar 2025 14:17:50 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust access modifiers

@artur-oracle 
Your change (at version b6a15c57248e4a299a6aec73ea3c02a3dbf90ca6) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23681#issuecomment-2766761649

From jbhateja at openjdk.org  Mon Mar 31 16:43:39 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 31 Mar 2025 16:43:39 GMT
Subject: RFR: 8351034: Add AVX-512 intrinsics for ML-DSA [v11]
In-Reply-To: <IrDjFB-31qorhKt_vwc2dL6LbQUq_7JMO2je_hGCa3I=.63a4319a-e334-4440-ac78-13165b4a23c3@github.com>
References: <sSyNauBw37i2PTz7sjlG2MRJOeyVliI2my0I6moVVlk=.a55a94fc-adb4-4d55-99ac-f70ac456a4b9@github.com>
 <JKJusH1gWBybGf4kMN2t_B4u-8qm8BXnEdUA-6sHaQ0=.cf44a3bf-319d-4a42-b7c9-827641753062@github.com>
 <Kanyx8L0d27_yUHP15BCfzO8MDEE3_JfDlxaP7Ran_g=.571eca02-d927-4598-ac9e-ff19cef9f484@github.com>
 <IrDjFB-31qorhKt_vwc2dL6LbQUq_7JMO2je_hGCa3I=.63a4319a-e334-4440-ac78-13165b4a23c3@github.com>
Message-ID: <-sFpKarpt9CP7DYd7v9vSBAgHYthQ4OZFNGHFOgb2AI=.fc908719-8e45-43d2-97df-95ff01129275@github.com>

On Mon, 31 Mar 2025 11:11:54 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.cpp line 1252:
>> 
>>> 1250:   // Currently we only have them for AVX512
>>> 1251: #ifdef _LP64
>>> 1252:   if (supports_evex() && supports_avx512bw()) {
>> 
>> supports_evex check looks redundant.
>
> These are checks for two different feature bits: CPU_AVX512F and CPU_AVX512BW. Are you saying that the latter implies the former in every implementation of the spec?

AVX512BW is built on top of AVX512F spec. In assembler and other places we only check BW in assertions which implies EVEX.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23860#discussion_r2021381288

From abarashev at openjdk.org  Mon Mar 31 16:48:41 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 31 Mar 2025 16:48:41 GMT
Subject: Integrated: 8349583: Add mechanism to disable signature schemes based
 on their TLS scope
In-Reply-To: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
References: <eLTOB7CsiuAB24y7vBwZEG0W0vqboLtl1iTkxEF0MgU=.08b2c610-bb1d-4700-94e6-057cae29e6c6@github.com>
Message-ID: <s7M4_P4zc-o78OgdNqyh7vgBWruw6c-lDahJZ5scm4U=.3f773cda-674c-499c-97bb-75b4edee2016@github.com>

On Tue, 18 Feb 2025 21:41:58 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> Currently when a signature scheme constraint is specified with "jdk.tls.disabledAlgorithms" property we don't differentiate between signatures used to sign a TLS handshake exchange and the signatures used in TLS certificates:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

This pull request has now been integrated.

Changeset: 9c06dcb4
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c06dcb4396c3307d625663d92c0e11d794a56ea
Stats:     1271 lines in 21 files changed: 923 ins; 224 del; 124 mod

8349583: Add mechanism to disable signature schemes based on their TLS scope

Reviewed-by: mullan, ascarpino

-------------

PR: https://git.openjdk.org/jdk/pull/23681

From duke at openjdk.org  Mon Mar 31 16:53:08 2025
From: duke at openjdk.org (duke)
Date: Mon, 31 Mar 2025 16:53:08 GMT
Subject: RFR: 8351366: Remove the java.security.debug=scl option [v3]
In-Reply-To: <e4JMomXsEqb2w5vy8UmCthnpGhhihmdjWXH6BgMCVCA=.2afb021f-ba03-4782-aa41-7e770bee8984@github.com>
References: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
 <e4JMomXsEqb2w5vy8UmCthnpGhhihmdjWXH6BgMCVCA=.2afb021f-ba03-4782-aa41-7e770bee8984@github.com>
Message-ID: <xaVRBy6opa1OLyQKM2EVTPw1iBKDy9739D10ep2FhIk=.a4a1227a-1db4-40bc-9556-a2f774f34015@github.com>

On Wed, 26 Mar 2025 21:37:42 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> This option dumped the permissions that the SecureClassLoader assigns to ProtectionDomains, but with the disabling of the Security Manager in JDK 24, these permissions are always empty and the debugging has no value. So this option should be removed.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351366:Remove the java.security.debug=scl option

@koushikthirupattur 
Your change (at version 7367139f472be40cff0c9fba8fd64dfa35bc9bd7) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24208#issuecomment-2766814900

From duke at openjdk.org  Mon Mar 31 16:57:26 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Mon, 31 Mar 2025 16:57:26 GMT
Subject: Integrated: 8351366: Remove the java.security.debug=scl option
In-Reply-To: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
References: <tQhBNkJxIy_tDxD4a9HEO3mkKB1S9BQDDpVz9o1fdNI=.1980d41d-ef51-4335-b120-7a00bf4e79eb@github.com>
Message-ID: <mitHKyfRGnrnwxDINIZw80B7qCJfYIn_aGeVTcoyHJY=.1388ae41-2cfe-4ee2-9fec-4a551398a94d@github.com>

On Mon, 24 Mar 2025 22:02:59 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> This option dumped the permissions that the SecureClassLoader assigns to ProtectionDomains, but with the disabling of the Security Manager in JDK 24, these permissions are always empty and the debugging has no value. So this option should be removed.

This pull request has now been integrated.

Changeset: 3e96f5cb
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e96f5cbcad2cb61b68e2ae6440085b80b6cc287
Stats:     16 lines in 2 files changed: 0 ins; 14 del; 2 mod

8351366: Remove the java.security.debug=scl option

Reviewed-by: hchao, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/24208

From hchao at openjdk.org  Mon Mar 31 21:22:15 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 31 Mar 2025 21:22:15 GMT
Subject: RFR: 8353299: VerifyJarEntryName.java test fails
Message-ID: <02_IneDp5KX-GGN-2QaG28NXX_OeLuZU-L5D93_Z1pY=.ffeb1d43-b6e1-4ed4-a287-707c722889c9@github.com>

Please review the change for JDK-8353299.

-------------

Commit messages:
 - Remove altering signature file name test

Changes: https://git.openjdk.org/jdk/pull/24337/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24337&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353299
  Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24337/head:pull/24337

PR: https://git.openjdk.org/jdk/pull/24337

From mullan at openjdk.org  Mon Mar 31 21:33:11 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 31 Mar 2025 21:33:11 GMT
Subject: RFR: 8353299: VerifyJarEntryName.java test fails
In-Reply-To: <02_IneDp5KX-GGN-2QaG28NXX_OeLuZU-L5D93_Z1pY=.ffeb1d43-b6e1-4ed4-a287-707c722889c9@github.com>
References: <02_IneDp5KX-GGN-2QaG28NXX_OeLuZU-L5D93_Z1pY=.ffeb1d43-b6e1-4ed4-a287-707c722889c9@github.com>
Message-ID: <IwxPm0JorIMFqTmFJnTBpgbcaUOyZ8RqAHb2_HO0YQY=.b83308b9-8836-4fe4-9ef5-e75a04e86eb4@github.com>

On Mon, 31 Mar 2025 21:16:42 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the change for JDK-8353299.

Bug needs a `noreg-self` label. Otherwise fix looks fine.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24337#pullrequestreview-2730550363

From hchao at openjdk.org  Mon Mar 31 21:42:20 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 31 Mar 2025 21:42:20 GMT
Subject: RFR: 8353299: VerifyJarEntryName.java test fails
In-Reply-To: <02_IneDp5KX-GGN-2QaG28NXX_OeLuZU-L5D93_Z1pY=.ffeb1d43-b6e1-4ed4-a287-707c722889c9@github.com>
References: <02_IneDp5KX-GGN-2QaG28NXX_OeLuZU-L5D93_Z1pY=.ffeb1d43-b6e1-4ed4-a287-707c722889c9@github.com>
Message-ID: <ReJca8PQKdKSkyasbfLfz1SppeQWBvUOfueZf1MfNtU=.8c20bedd-ef10-4f49-a8a8-6cb766d04424@github.com>

On Mon, 31 Mar 2025 21:16:42 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the change for JDK-8353299.

Label `noreg-self` added. Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24337#issuecomment-2767466294

From hchao at openjdk.org  Mon Mar 31 21:42:20 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Mon, 31 Mar 2025 21:42:20 GMT
Subject: Integrated: 8353299: VerifyJarEntryName.java test fails
In-Reply-To: <02_IneDp5KX-GGN-2QaG28NXX_OeLuZU-L5D93_Z1pY=.ffeb1d43-b6e1-4ed4-a287-707c722889c9@github.com>
References: <02_IneDp5KX-GGN-2QaG28NXX_OeLuZU-L5D93_Z1pY=.ffeb1d43-b6e1-4ed4-a287-707c722889c9@github.com>
Message-ID: <C0Vp0T1AQ4j_QC5gCA4FBcV3QZUTscZt7n_P6l5e2eE=.1d8c6215-fce8-45ae-ad5c-1ac321cf4f4d@github.com>

On Mon, 31 Mar 2025 21:16:42 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Please review the change for JDK-8353299.

This pull request has now been integrated.

Changeset: acd4da49
Author:    Hai-May Chao <hchao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acd4da49a01760599ec4c325ff6c56f53ba5cc9c
Stats:     16 lines in 1 file changed: 0 ins; 16 del; 0 mod

8353299: VerifyJarEntryName.java test fails

Reviewed-by: mullan

-------------

PR: https://git.openjdk.org/jdk/pull/24337