From jpai at openjdk.org  Sun Jun  1 03:53:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 1 Jun 2025 03:53:00 GMT
Subject: RFR: 8230016: re-visit test
 sun/security/pkcs11/Serialize/SerializeProvider.java [v3]
In-Reply-To: <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com>
References: <xcBCj9Ix3GWBJva01yradKVjmlVGIIE6EDo7CaS-unI=.eb404269-4e24-4035-9d37-d733634b7bbe@github.com>
 <12bEhLew4G7bp1r4Zca91NpYd6l_Bu2Idv5rs9MYyWU=.930a3d09-aea4-4aaa-be71-55a843618e5c@github.com>
Message-ID: <NozJL5n7IS9EhpBhb__P_qDaQDJX_EOupwXjbab_ZVw=.c82a7b96-a19f-4ed5-8d51-4e9ab1726ada@github.com>

On Wed, 30 Apr 2025 14:36:02 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Provider is now added to the Security before the test
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unneeded check

I see that Rajan has approved this and tier1, tier2 testing with this change completed without issues. I checked that the test is no longer skipped in those runs. I'll go ahead and sponsor this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24750#issuecomment-2926413120

From myankelevich at openjdk.org  Sun Jun  1 03:53:00 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Sun, 1 Jun 2025 03:53:00 GMT
Subject: Integrated: 8230016: re-visit test
 sun/security/pkcs11/Serialize/SerializeProvider.java
In-Reply-To: <xcBCj9Ix3GWBJva01yradKVjmlVGIIE6EDo7CaS-unI=.eb404269-4e24-4035-9d37-d733634b7bbe@github.com>
References: <xcBCj9Ix3GWBJva01yradKVjmlVGIIE6EDo7CaS-unI=.eb404269-4e24-4035-9d37-d733634b7bbe@github.com>
Message-ID: <yIbryRqP9o7FiJcZYFVeHq4lH4LEu_-Hk8ycWoRBb0Q=.66fed424-cbc8-4373-97df-ab661b51a349@github.com>

On Fri, 18 Apr 2025 10:15:06 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Provider is now added to the Security before the test

This pull request has now been integrated.

Changeset: 470ffeed
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/470ffeedda45b6f75ce0c794a965428b7859be6f
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8230016: re-visit test sun/security/pkcs11/Serialize/SerializeProvider.java

Reviewed-by: rhalade

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

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

From shade at openjdk.org  Mon Jun  2 10:31:23 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 10:31:23 GMT
Subject: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after JDK-8298420
Message-ID: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>

Found by static analysis, see more details in the bug.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `jdk_security`

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

Commit messages:
 - Fix

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

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

From shade at openjdk.org  Mon Jun  2 11:15:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 11:15:28 GMT
Subject: RFR: 8358319: Pem.decode should cache the Pattern
Message-ID: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>

SonarCloud complains we are using the String.replaceAll() method that creates Pattern internally every time. This looks a minor inefficiency in preview feature, but we can fix it from the day 1. Also fixed the variable name style in adjacent cached Pattern.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `jdk_security`

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

Commit messages:
 - Fix

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

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

From varadam at openjdk.org  Mon Jun  2 12:11:55 2025
From: varadam at openjdk.org (Varada M)
Date: Mon, 2 Jun 2025 12:11:55 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations
In-Reply-To: <3Z3TT_VySGy5fZr2c39ljN34dvQo-9mPLnWnZB8gluY=.efae4a33-7a03-4d7c-8ccc-d3f6ab35b105@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <3Z3TT_VySGy5fZr2c39ljN34dvQo-9mPLnWnZB8gluY=.efae4a33-7a03-4d7c-8ccc-d3f6ab35b105@github.com>
Message-ID: <1V-RAIaR1Zjv0Y7JSBDjMMXIEI3T4rx6N8o_5ltx9qQ=.9bac6e6e-a0bb-437c-aeb3-d87c2909d0a9@github.com>

On Fri, 30 May 2025 12:40:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> I think this should have a regression test for this change. Also, you indicated this patch restores the behavior - do you know what release this last worked in and what issue caused it to stop working?

Hi @seanjmullan ,
This [previous commit](https://github.com/openjdk/jdk/pull/11339) in openjdk broke some cipher transformations.

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

PR Comment: https://git.openjdk.org/jdk/pull/25547#issuecomment-2930371743

From fguallini at openjdk.org  Mon Jun  2 15:17:13 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Mon, 2 Jun 2025 15:17:13 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API
Message-ID: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>

The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing

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

Commit messages:
 - lines comments
 - add final break and test comment
 - multi thread and defaut algo tests
 - more test coverage for PEM

Changes: https://git.openjdk.org/jdk/pull/25588/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25588&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358171
  Stats: 512 lines in 10 files changed: 469 ins; 2 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/25588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25588/head:pull/25588

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

From mullan at openjdk.org  Mon Jun  2 15:18:01 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 2 Jun 2025 15:18:01 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations
In-Reply-To: <3Z3TT_VySGy5fZr2c39ljN34dvQo-9mPLnWnZB8gluY=.efae4a33-7a03-4d7c-8ccc-d3f6ab35b105@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <3Z3TT_VySGy5fZr2c39ljN34dvQo-9mPLnWnZB8gluY=.efae4a33-7a03-4d7c-8ccc-d3f6ab35b105@github.com>
Message-ID: <UJH9kMf0lOthpalcgweBMldbmbJVxlMdt6fmRm3VhA4=.51a82d05-485a-4beb-b3d4-0942987480a9@github.com>

On Fri, 30 May 2025 12:40:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> I think this should have a regression test for this change. Also, you indicated this patch restores the behavior - do you know what release this last worked in and what issue caused it to stop working?

> Hi @seanjmullan , This [previous commit](https://github.com/openjdk/jdk/pull/11339) in openjdk broke some cipher transformations.

Thanks - please add that comment and add 8288050 as a related issue to https://bugs.openjdk.org/browse/JDK-8358159

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

PR Comment: https://git.openjdk.org/jdk/pull/25547#issuecomment-2931213412

From sean.mullan at oracle.com  Mon Jun  2 16:45:32 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 2 Jun 2025 12:45:32 -0400
Subject: Quantum Resistant hybrid key exchange
In-Reply-To: <0C220CEF-D3D9-DB46-80F5-E40EC5BA221F@hxcore.ol>
References: <F7730317-0408-425A-B6B7-7AF0BEBA7036@apple.com>
 <0C220CEF-D3D9-DB46-80F5-E40EC5BA221F@hxcore.ol>
Message-ID: <2c0f1769-1575-4172-ab9b-bacf47d004f4@oracle.com>

Hi Azeem,

For TLS, we are currently working on an implementation of "Hybrid Key 
Exchange for TLS 1.3" [1]. We also expect to implement one or more of 
the hybrid mechanisms that are being specified [2]. Expect to see a JEP 
with more details on this effort in the near future.

As for other hybrid key exchange mechanisms, we are tracking X-Wing and 
there was a recent message to security-dev from Sebastian Stenzel about 
potentially contributing an implementation.

As Bernd mentions, our policy is not to deliver features until the 
standard, or RFC has been published.

--Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
[2] https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
[3] https://mail.openjdk.org/pipermail/security-dev/2025-May/046224.html

On 5/31/25 3:01 AM, ecki wrote:
> You find the published plans in JEPs or Jira tickets about PQC, 
> currently however I have seen more groundwork like KEM and HKDF plus ML, 
> none hybrid (mostly due to the fact that OpenJDK waits for standards, 
> see the recent XWing discussion),
> 
> I have seen that Oracle (of course) stated, that they will work on TLS 
> and even back port it, for example here: https://blogs.oracle.com/ 
> security/post/post-quantum-cryptography <https://blogs.oracle.com/ 
> security/post/post-quantum-cryptography>
> Maybe Sean can comment on it, but I think the same caveat applies here - 
> missing completed standardization (and NIST did their fair share to 
> hinder development, glad IETF picked up, draft-ietf-tls-ecdhe-mlkem-00 
> is till pretty fresh, though).
> 
> I also know that ssh client providers (probably with the help of 
> Bouncycastle) want to catch up to OpenSSH 10. With x25519mlkem (and 
> maybe sntrupx?)
> 
> The next, much bigger step IMHO is the area of (certificate) signatures/ 
> authentication. We have a bit more time there, so the future stays 
> interesting,
> 
> Gru?,
> Bernd
> -- 
> https://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:*?security-dev <security-dev-retn at openjdk.org> im Auftrag von Azeem 
> Jiva <a_jiva at apple.com>
> *Gesendet:*?Samstag, Mai 31, 2025 3:10 AM
> *An:*?security-dev at openjdk.org <security-dev at openjdk.org>
> *Betreff:*?Quantum Resistant hybrid key exchange
> Hi,
> Is there a list of future quantum resistant hybrid key changes under 
> development for future OpenJDK releases? Thanks.


From ascarpino at openjdk.org  Mon Jun  2 16:57:56 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 2 Jun 2025 16:57:56 GMT
Subject: RFR: 8358319: Pem.decode should cache the Pattern
In-Reply-To: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
References: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
Message-ID: <IBxxQ7HXMrKIg6Vkqk9KQVUeohYb15IxkijvzuqkzQo=.2dcfdc5b-b084-491c-9037-a955a8e80b7c@github.com>

On Mon, 2 Jun 2025 11:10:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains we are using the String.replaceAll() method that creates Pattern internally every time. This looks a minor inefficiency in preview feature, but we can fix it from the day 1. Also fixed the variable name style in adjacent cached Pattern.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

looks good

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25583#pullrequestreview-2889246606

From ascarpino at openjdk.org  Mon Jun  2 16:57:58 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 2 Jun 2025 16:57:58 GMT
Subject: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after
 JDK-8298420
In-Reply-To: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
References: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
Message-ID: <YeC5MSkgMbq6M0E5QTYRbjL3NsE4i6xclLiMbcLtX7o=.cf6c8062-b6a5-4535-b7bc-3f01c31eeed7@github.com>

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found by static analysis, see more details in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

looks good

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25581#pullrequestreview-2889251717

From shade at openjdk.org  Mon Jun  2 16:57:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 16:57:56 GMT
Subject: RFR: 8358319: Pem.decode should cache the Pattern
In-Reply-To: <IBxxQ7HXMrKIg6Vkqk9KQVUeohYb15IxkijvzuqkzQo=.2dcfdc5b-b084-491c-9037-a955a8e80b7c@github.com>
References: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
 <IBxxQ7HXMrKIg6Vkqk9KQVUeohYb15IxkijvzuqkzQo=.2dcfdc5b-b084-491c-9037-a955a8e80b7c@github.com>
Message-ID: <1moGSTRm9DbpkoEAgv6x1llNleAw3ehLMMRNu761F84=.ef5721ab-2979-4e56-b76b-0d73cde57750@github.com>

On Mon, 2 Jun 2025 16:53:54 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> looks good

Thanks! A bit blurry on review rules in this area: do you want me to wait for someone else to review? More tests to run?

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

PR Comment: https://git.openjdk.org/jdk/pull/25583#issuecomment-2931591245

From ascarpino at openjdk.org  Mon Jun  2 17:02:50 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 2 Jun 2025 17:02:50 GMT
Subject: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after
 JDK-8298420
In-Reply-To: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
References: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
Message-ID: <hlJrqFWKZ-ug5MvtFeKWNKKZzIe4ym7dhPsm9G87kdk=.02b988d5-eff7-4026-ac7c-1565cb8f01a0@github.com>

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found by static analysis, see more details in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

I'm. sure this is fine, but let me run the regression tests before integration

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

PR Comment: https://git.openjdk.org/jdk/pull/25581#issuecomment-2931602749

From ascarpino at openjdk.org  Mon Jun  2 18:08:51 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 2 Jun 2025 18:08:51 GMT
Subject: RFR: 8358319: Pem.decode should cache the Pattern
In-Reply-To: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
References: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
Message-ID: <JjFk5dSEIByjAFKQYNRsSZ3TiMQ544o_DoKNe89aj_E=.055c7a3e-213a-4827-8771-6493b86d4996@github.com>

On Mon, 2 Jun 2025 11:10:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains we are using the String.replaceAll() method that creates Pattern internally every time. This looks a minor inefficiency in preview feature, but we can fix it from the day 1. Also fixed the variable name style in adjacent cached Pattern.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

Tests passed

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

PR Comment: https://git.openjdk.org/jdk/pull/25583#issuecomment-2931861062

From ascarpino at openjdk.org  Mon Jun  2 18:08:52 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 2 Jun 2025 18:08:52 GMT
Subject: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after
 JDK-8298420
In-Reply-To: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
References: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
Message-ID: <ExvNHTVltoBqsx4kXt6ga6xHKy6p7v9AmA4jN-SWcm4=.45c981ab-f230-4e28-8a04-e368eeaaf3ff@github.com>

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found by static analysis, see more details in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

Tests pass

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

PR Comment: https://git.openjdk.org/jdk/pull/25581#issuecomment-2931860336

From shade at openjdk.org  Mon Jun  2 18:18:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 18:18:52 GMT
Subject: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after
 JDK-8298420
In-Reply-To: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
References: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
Message-ID: <MlLookTVEcKyCHC4KXe8VWLUnKxCwAiP1iFo1U8UUy0=.712378b2-def4-41c4-b9e0-e70cc6d5f386@github.com>

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found by static analysis, see more details in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

Thanks! I'll integrate once my day starts tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/25581#issuecomment-2931907175

From shade at openjdk.org  Mon Jun  2 18:18:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 18:18:52 GMT
Subject: RFR: 8358319: Pem.decode should cache the Pattern
In-Reply-To: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
References: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
Message-ID: <tMTE7LX7wGwGQQcvV22syP-lfhVjIE87R6tvTz01MhQ=.77cf22d3-191d-4ae5-b1ad-a6603662b8be@github.com>

On Mon, 2 Jun 2025 11:10:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains we are using the String.replaceAll() method that creates Pattern internally every time. This looks a minor inefficiency in preview feature, but we can fix it from the day 1. Also fixed the variable name style in adjacent cached Pattern.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

Thanks! I'll integrate once my day starts tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/25583#issuecomment-2931906688

From vyazici at openjdk.org  Mon Jun  2 19:27:08 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:27:08 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v2]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Provide fallback for `stdin.encoding`
 - Revert changes to `Application` and `JavaChild`
   
   There stdin is connected to the parent process rather than the console.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/3da53cc9..ef30c050

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

  Stats: 28 lines in 8 files changed: 14 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

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

From vyazici at openjdk.org  Mon Jun  2 19:27:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:27:09 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v2]
In-Reply-To: <sa8L4ZBywxveDtzE7b5VbcdXy3cLvh3INzrIKv4ja7s=.01a87615-dc77-4022-a52a-2e6225b83f8f@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <sa8L4ZBywxveDtzE7b5VbcdXy3cLvh3INzrIKv4ja7s=.01a87615-dc77-4022-a52a-2e6225b83f8f@github.com>
Message-ID: <WSL4sRjVbOyRjK8xqSUVuclRvRXa5zwKdptdkG-BETY=.192e259a-1dec-4421-8bc4-e9bdc50493f1@github.com>

On Fri, 30 May 2025 14:23:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Provide fallback for `stdin.encoding`
>>  - Revert changes to `Application` and `JavaChild`
>>    
>>    There stdin is connected to the parent process rather than the console.
>
> test/jdk/com/sun/tools/attach/Application.java line 40:
> 
>> 38: 
>> 39:         try (BufferedReader br = new BufferedReader(new InputStreamReader(
>> 40:                 System.in, System.getProperty("stdin.encoding")))) {
> 
> This "application" is launched by the test so connected to the parent process rather than the console.

Reverted in 2d52ba408.

> test/jdk/java/lang/ProcessHandle/JavaChild.java line 315:
> 
>> 313:                         // children and wait for each to exit
>> 314:                         sendResult(action, "start");
>> 315:                         try (Reader reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 
> I didn't study the test closely but I think this is another case where a child process is launched so System.in is connected to the parent rather than the console.

Reverted in 2d52ba408..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2121978546
PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2121978885

From cjplummer at openjdk.org  Mon Jun  2 19:29:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 19:29:50 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v2]
In-Reply-To: <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>
Message-ID: <8V_c_ulLVTPp6ivKsU3vsslAV3l4b41mRhDKbWGv5Qk=.ea887db3-4975-4c23-b907-d02ba90f2b44@github.com>

On Mon, 2 Jun 2025 19:27:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Provide fallback for `stdin.encoding`
>  - Revert changes to `Application` and `JavaChild`
>    
>    There stdin is connected to the parent process rather than the console.

test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 141:

> 139:     Thread console(final int num, final int nhits) {
> 140:         final InputStreamReader isr = new InputStreamReader(
> 141:                 System.in, Charset.forName(System.getProperty("stdin.encoding")));

`isr` is not really needed. It is used to create `br`, which is never used. It is also synchronized on, but since there is a unique `isr` for each thread, the synchronization does nothing. I suggest just deleting `isr`, `br`, and the `synchronized` below.

Note there is a hint in a comment as to why it is like this:


                                // This is a tendril from the original jdb test.
                                // It could probably be deleted.


I think this test once used jdb (and had to deal with the jdb console), but no longer does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2121984300

From mullan at openjdk.org  Mon Jun  2 19:39:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 2 Jun 2025 19:39:54 GMT
Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for
 java.security.debug [v3]
In-Reply-To: <fMPriSrxGjqWaZJPRPEgKL8XWUooF3jrV61G6IyrAqc=.814c71ae-615e-42db-9315-81a10669bd6f@github.com>
References: <ICRPdwS8zU1KgGep1aOvQTR-7a9B7q6wih0dTrRl8iE=.bf7802d2-e65a-435f-b88b-0ac02c1e4e12@github.com>
 <fMPriSrxGjqWaZJPRPEgKL8XWUooF3jrV61G6IyrAqc=.814c71ae-615e-42db-9315-81a10669bd6f@github.com>
Message-ID: <YlEXlVOWTK0BQvZQxzs5amN082cITn_Avulf6hbjkvY=.afd99e90-4211-44da-8f1a-31e9eb745271@github.com>

On Fri, 30 May 2025 14:43:32 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property.
>> 
>> 
>> To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data.
>> 
>> This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data.
>> 
>> Debug output data from use of the `java.security.debug` property will now resemble something like the following:
>> 
>> 
>> 
>> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update property doc as per Sean Mullan comment

src/java.base/share/classes/java/security/doc-files/debug-system-property.html line 56:

> 54:     execution. The value of the property is one or more options separated by a
> 55:     comma. Each trace message includes the thread id, timestamp and caller
> 56:     information.

Small comment, but I would list this in the order they are printed: "thread id, caller information, and timestamp".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25528#discussion_r2121984557

From vyazici at openjdk.org  Mon Jun  2 19:50:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:50:10 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v3]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <A-d7eoGNEQ-n4RYuRRUfHuu4FT6clqA-Y_sYEScbdQs=.12fb732d-7078-43a2-855f-c8980a3f4de7@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

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

  Clean-up `MultiBreakpointsTarg`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/ef30c050..8f8a6575

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

  Stats: 65 lines in 1 file changed: 5 ins; 21 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

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

From vyazici at openjdk.org  Mon Jun  2 19:50:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:50:11 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v3]
In-Reply-To: <8V_c_ulLVTPp6ivKsU3vsslAV3l4b41mRhDKbWGv5Qk=.ea887db3-4975-4c23-b907-d02ba90f2b44@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>
 <8V_c_ulLVTPp6ivKsU3vsslAV3l4b41mRhDKbWGv5Qk=.ea887db3-4975-4c23-b907-d02ba90f2b44@github.com>
Message-ID: <oZJozOvTGdWRwxL9ISwdDP49MAHhj1-KM5CRF4w77LQ=.b13d7e0f-f02e-4b94-958b-09fc2f092eef@github.com>

On Mon, 2 Jun 2025 19:27:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean-up `MultiBreakpointsTarg`
>
> test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 141:
> 
>> 139:     Thread console(final int num, final int nhits) {
>> 140:         final InputStreamReader isr = new InputStreamReader(
>> 141:                 System.in, Charset.forName(System.getProperty("stdin.encoding")));
> 
> `isr` is not really needed. It is used to create `br`, which is never used. It is also synchronized on, but since there is a unique `isr` for each thread, the synchronization does nothing. I suggest just deleting `isr`, `br`, and the `synchronized` below.
> 
> Note there is a hint in a comment as to why it is like this:
> 
> 
>                                 // This is a tendril from the original jdb test.
>                                 // It could probably be deleted.
> 
> 
> I think this test once used jdb (and had to deal with the jdb console), but no longer does.

Implemented your suggestion in 8f8a65754 ? took the liberty to remove the unused `done` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2122019203

From cjplummer at openjdk.org  Mon Jun  2 22:03:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 22:03:51 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v3]
In-Reply-To: <A-d7eoGNEQ-n4RYuRRUfHuu4FT6clqA-Y_sYEScbdQs=.12fb732d-7078-43a2-855f-c8980a3f4de7@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <A-d7eoGNEQ-n4RYuRRUfHuu4FT6clqA-Y_sYEScbdQs=.12fb732d-7078-43a2-855f-c8980a3f4de7@github.com>
Message-ID: <ujbbla0V9GPjN2ivoOPSrIY_apfD9lXuiUCXFJkjWpc=.350f1114-42ed-4abf-85f5-7bfbf77d6655@github.com>

On Mon, 2 Jun 2025 19:50:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean-up `MultiBreakpointsTarg`

The src/jdk.jdi and test/jdk/com/sun/jdi changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25544#pullrequestreview-2890059517

From mdonovan at openjdk.org  Tue Jun  3 00:16:53 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 00:16:53 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API
In-Reply-To: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
Message-ID: <VdtvQ_qa82oJWbPnybR9L87cmBEewfO4EKT9l4vygL4=.754f8983-d8cc-4b74-96d0-dae97146584c@github.com>

On Mon, 2 Jun 2025 12:14:13 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing

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

> 47:         +OO4oO0VNduC44gUN1nrk7/wdNSpL+xXNEX52Dsff+2RD/fop224ANvB
> 48:         -----END PRIVATE KEY-----
> 49:         """, KeyPair.class, "SunEC");

When possible, we've been replacing hard-coded provider names with the system property, such as `System.getProperty("test.provider.name", "SunEC")`. 

Is that appropriate for these tests?

test/jdk/java/security/PEM/PEMDecoderTest.java line 376:

> 374: 
> 375:     // Run test with a given Entry
> 376:     static DEREncodable test(PEMData.Entry entry, boolean withFactory) {

Would it be too much output to include print statements at the beginning of the test methods?
Something like `System.out.printf("Testing %s %s%n", entry.name, entry.provider);`?

test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java line 34:

> 32:  *          java.base/sun.security.x509
> 33:  * @run main PKCS8Test
> 34:  * @run main/othervm -Dtest.provider.name=SunJCE PKCS8Test

I'm curious why you're specifying the provider name this way instead of using the `System.getProperty("test.provider.name", "SunJCE")` pattern?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2122345088
PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2122351612
PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2122357087

From vyazici at openjdk.org  Tue Jun  3 07:55:06 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 07:55:06 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

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

  Fix missing `java.io.Reader` import in `Ktab`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/8f8a6575..78e8de51

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

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

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

From michaelm at openjdk.org  Tue Jun  3 08:14:48 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 08:14:48 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v19]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@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 with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge branch 'master' into 8348986-exceptions
 - doc update to java.security
 - removed jmod/Handler change
 - doc update to java.security
 - Fixed problem with j.n.HostPortRange
 - typo in suggestions and other issues
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Additional callsites identified by Mark S.
 - Merge branch 'master' into 8348986-exceptions
 - ... and 29 more: https://git.openjdk.org/jdk/compare/dbf562c7...ab6387d8

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=18
  Stats: 984 lines in 47 files changed: 709 ins; 101 del; 174 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 shade at openjdk.org  Tue Jun  3 08:17:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 08:17:00 GMT
Subject: RFR: 8358319: Pem.decode should cache the Pattern
In-Reply-To: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
References: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
Message-ID: <oV67OanYujIA6j-kuO35vFEyBV3vZqcVF6vP9oli_Ck=.f3cacc1d-7dc1-49dc-9e93-f4bb36a1358e@github.com>

On Mon, 2 Jun 2025 11:10:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains we are using the String.replaceAll() method that creates Pattern internally every time. This looks a minor inefficiency in preview feature, but we can fix it from the day 1. Also fixed the variable name style in adjacent cached Pattern.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25583#issuecomment-2934061689

From shade at openjdk.org  Tue Jun  3 08:17:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 08:17:00 GMT
Subject: Integrated: 8358319: Pem.decode should cache the Pattern
In-Reply-To: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
References: <QnbCpJ0GOmmFakfOCZsxA6Ba4aUhZfT2VJMQK3LX11U=.c63b881b-eef1-40ee-b4af-a16e9c219b83@github.com>
Message-ID: <ZwA3JO4wjjSkmBPysgqPpnGbo5AwsbwydxubniAzIrQ=.167c36b9-a8a9-4051-a03e-383019208c1d@github.com>

On Mon, 2 Jun 2025 11:10:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains we are using the String.replaceAll() method that creates Pattern internally every time. This looks a minor inefficiency in preview feature, but we can fix it from the day 1. Also fixed the variable name style in adjacent cached Pattern.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

This pull request has now been integrated.

Changeset: 6f783e5f
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f783e5fab0e98da6c41e3c22d4523733f060d68
Stats:     9 lines in 1 file changed: 4 ins; 0 del; 5 mod

8358319: Pem.decode should cache the Pattern

Reviewed-by: ascarpino

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

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

From shade at openjdk.org  Tue Jun  3 08:17:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 08:17:03 GMT
Subject: RFR: 8358316: PKCS8Key.getEncoded() can throw NPE after
 JDK-8298420
In-Reply-To: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
References: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
Message-ID: <bBAOMw4gLrB6OTCW7IasDe9aH2nIywsnnJ4LJSNpGUk=.68a44cb0-3860-4b81-8b22-df9eef953b86@github.com>

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found by static analysis, see more details in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

Here goes!

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

PR Comment: https://git.openjdk.org/jdk/pull/25581#issuecomment-2934062135

From shade at openjdk.org  Tue Jun  3 08:17:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jun 2025 08:17:03 GMT
Subject: Integrated: 8358316: PKCS8Key.getEncoded() can throw NPE after
 JDK-8298420
In-Reply-To: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
References: <fta2P3waODtKb4shYEgiqCRNnuGjAWKWD3ZdT4wzXU0=.fcf051d7-15be-4587-a3e1-ac50557a8f99@github.com>
Message-ID: <-Rf3lcOOAQyMnFn9mxOMG04X9NmG3K7moJspODyhaEs=.c5ae827b-f63d-4048-a8b6-4c5293215e94@github.com>

On Mon, 2 Jun 2025 10:26:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found by static analysis, see more details in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_security`

This pull request has now been integrated.

Changeset: cff75eb6
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cff75eb60628827541ea6c08eb1970401f606ebc
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8358316: PKCS8Key.getEncoded() can throw NPE after JDK-8298420

Reviewed-by: ascarpino

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

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

From fguallini at openjdk.org  Tue Jun  3 09:47:09 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Tue, 3 Jun 2025 09:47:09 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API
In-Reply-To: <VdtvQ_qa82oJWbPnybR9L87cmBEewfO4EKT9l4vygL4=.754f8983-d8cc-4b74-96d0-dae97146584c@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
 <VdtvQ_qa82oJWbPnybR9L87cmBEewfO4EKT9l4vygL4=.754f8983-d8cc-4b74-96d0-dae97146584c@github.com>
Message-ID: <bklSXthds1lXaeqWHPAu2r8JBBkmqNGn0LMXh8cFwHk=.a14e5e84-4965-43d3-96a7-0b0b7b5ef88a@github.com>

On Mon, 2 Jun 2025 23:46:23 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing
>
> test/jdk/java/security/PEM/PEMData.java line 49:
> 
>> 47:         +OO4oO0VNduC44gUN1nrk7/wdNSpL+xXNEX52Dsff+2RD/fop224ANvB
>> 48:         -----END PRIVATE KEY-----
>> 49:         """, KeyPair.class, "SunEC");
> 
> When possible, we've been replacing hard-coded provider names with the system property, such as `System.getProperty("test.provider.name", "SunEC")`. 
> 
> Is that appropriate for these tests?

I think that may not applicable for these tests, as there are multiple providers in this file to support all of the PEM decodings. It would need something like:"test.provider.1.name", "test.provider.2.name" and so on, it may be too confusing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2123300286

From fguallini at openjdk.org  Tue Jun  3 09:52:52 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Tue, 3 Jun 2025 09:52:52 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API
In-Reply-To: <VdtvQ_qa82oJWbPnybR9L87cmBEewfO4EKT9l4vygL4=.754f8983-d8cc-4b74-96d0-dae97146584c@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
 <VdtvQ_qa82oJWbPnybR9L87cmBEewfO4EKT9l4vygL4=.754f8983-d8cc-4b74-96d0-dae97146584c@github.com>
Message-ID: <Z7LC9dzI5V3lUi7i6wJB5L5YtOPTfj44xuIm5IjL7Zc=.9002f97f-3ad3-445b-ac7a-dd60d1e5e5c0@github.com>

On Mon, 2 Jun 2025 23:54:30 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing
>
> test/jdk/java/security/PEM/PEMDecoderTest.java line 376:
> 
>> 374: 
>> 375:     // Run test with a given Entry
>> 376:     static DEREncodable test(PEMData.Entry entry, boolean withFactory) {
> 
> Would it be too much output to include print statements at the beginning of the test methods?
> Something like `System.out.printf("Testing %s %s%n", entry.name, entry.provider);`?

I will add that print statement ?

> test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java line 34:
> 
>> 32:  *          java.base/sun.security.x509
>> 33:  * @run main PKCS8Test
>> 34:  * @run main/othervm -Dtest.provider.name=SunJCE PKCS8Test
> 
> I'm curious why you're specifying the provider name this way instead of using the `System.getProperty("test.provider.name", "SunJCE")` pattern?

That is because this test is covering the scenarios with and without passing a provider ([line 80](https://github.com/openjdk/jdk/blob/6f18e8b29750bbb1281b35a0c0a66873ae5c61f8/test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java#L80))

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2123315338
PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2123309884

From mdonovan at openjdk.org  Tue Jun  3 11:43:52 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 11:43:52 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API
In-Reply-To: <bklSXthds1lXaeqWHPAu2r8JBBkmqNGn0LMXh8cFwHk=.a14e5e84-4965-43d3-96a7-0b0b7b5ef88a@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
 <VdtvQ_qa82oJWbPnybR9L87cmBEewfO4EKT9l4vygL4=.754f8983-d8cc-4b74-96d0-dae97146584c@github.com>
 <bklSXthds1lXaeqWHPAu2r8JBBkmqNGn0LMXh8cFwHk=.a14e5e84-4965-43d3-96a7-0b0b7b5ef88a@github.com>
Message-ID: <lAs8jdViBSdWnqcBVb8L4Y1pEdDAPIuLD7E3VAJoZF8=.f35dd1bb-c888-49c3-9d52-97fdc2c58043@github.com>

On Tue, 3 Jun 2025 09:43:38 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> test/jdk/java/security/PEM/PEMData.java line 49:
>> 
>>> 47:         +OO4oO0VNduC44gUN1nrk7/wdNSpL+xXNEX52Dsff+2RD/fop224ANvB
>>> 48:         -----END PRIVATE KEY-----
>>> 49:         """, KeyPair.class, "SunEC");
>> 
>> When possible, we've been replacing hard-coded provider names with the system property, such as `System.getProperty("test.provider.name", "SunEC")`. 
>> 
>> Is that appropriate for these tests?
>
> I think that may not applicable for these tests, as there are multiple providers in this file to support all of the PEM decodings. It would need something like:"test.provider.1.name", "test.provider.2.name" and so on, it may be too confusing.

Yeah that wouldn't be good.

>> test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java line 34:
>> 
>>> 32:  *          java.base/sun.security.x509
>>> 33:  * @run main PKCS8Test
>>> 34:  * @run main/othervm -Dtest.provider.name=SunJCE PKCS8Test
>> 
>> I'm curious why you're specifying the provider name this way instead of using the `System.getProperty("test.provider.name", "SunJCE")` pattern?
>
> That is because this test is covering the scenarios with and without passing a provider ([line 80](https://github.com/openjdk/jdk/blob/6f18e8b29750bbb1281b35a0c0a66873ae5c61f8/test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java#L80))

Ah, I see that now. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2123554558
PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2123555016

From mdonovan at openjdk.org  Tue Jun  3 13:18:01 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 13:18:01 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
Message-ID: <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>

On Fri, 30 May 2025 19:28:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - expanded wildcard imports
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - reversed order of DN strings when making certificates.
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - changed boolean array initialization
>>  - 8325766: Review seclibs tests for cert expiry
>
> test/lib/jdk/test/lib/security/CertificateBuilder.java line 109:
> 
>> 107:      */
>> 108:     public static CertificateBuilder newCertificateBuilder(String subjectName,
>> 109:                            PublicKey publicKey, PublicKey caKey, KeyUsage... keyUsages)
> 
> My suggestion is to make this a regular constructor and have an additional method that sets the certificate lifetime as a `Duration` parameter, ex:
> 
> `new CertificateBuilder(subject, pubKey, caPubKey, keyUsage).withValidity(Duration.ofHours(1));`

I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.

I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2123779281

From mdonovan at openjdk.org  Tue Jun  3 13:11:31 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 13:11:31 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v5]
In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
Message-ID: <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@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 12 commits:

 - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
 - Merge branch 'master' into certbuilder
 - expanded wildcard imports
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - reversed order of DN strings when making certificates.
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - ... and 2 more: https://git.openjdk.org/jdk/compare/e490b4f0...2b5533aa

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

Changes: https://git.openjdk.org/jdk/pull/23700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=04
  Stats: 784 lines in 3 files changed: 158 ins; 582 del; 44 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 dfuchs at openjdk.org  Tue Jun  3 13:22:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 13:22:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v19]
In-Reply-To: <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>
Message-ID: <Z9wuYyFiAHmGeI1K2E_tBDqs3kurtsXNmE327z_Io6Q=.248a8519-e3c3-436c-b597-b46195984eb2@github.com>

On Tue, 3 Jun 2025 08:14:48 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 with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - doc update to java.security
>  - removed jmod/Handler change
>  - doc update to java.security
>  - Fixed problem with j.n.HostPortRange
>  - typo in suggestions and other issues
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Additional callsites identified by Mark S.
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/dbf562c7...ab6387d8

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2892334027

From coffeys at openjdk.org  Tue Jun  3 13:38:16 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 3 Jun 2025 13:38:16 GMT
Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for
 java.security.debug [v4]
In-Reply-To: <ICRPdwS8zU1KgGep1aOvQTR-7a9B7q6wih0dTrRl8iE=.bf7802d2-e65a-435f-b88b-0ac02c1e4e12@github.com>
References: <ICRPdwS8zU1KgGep1aOvQTR-7a9B7q6wih0dTrRl8iE=.bf7802d2-e65a-435f-b88b-0ac02c1e4e12@github.com>
Message-ID: <pfqYJsiKk5wqgZ_vA-tYdx3LE94_MLtrbHg3vh0QcyU=.8a787050-277e-48d6-9370-eca2a1e860de@github.com>

> Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property.
> 
> 
> To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data.
> 
> This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data.
> 
> Debug output data from use of the `java.security.debug` property will now resemble something like the following:
> 
> 
> 
> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
> 
> 
> I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch.

Sean Coffey has updated the pull request 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:

 - tweak sentence in debug-system-property.html
 - Merge branch 'master' into 8350689-default-timestamps
 - Update property doc as per Sean Mullan comment
 - Incorporate review comments from Mark
 - Merge branch 'master' into 8350689-default-timestamps
 - update system property doc
 - 8350689

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25528/files
  - new: https://git.openjdk.org/jdk/pull/25528/files/85babe83..0e5c0da0

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

  Stats: 28437 lines in 397 files changed: 8194 ins; 12651 del; 7592 mod
  Patch: https://git.openjdk.org/jdk/pull/25528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25528/head:pull/25528

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

From michaelm at openjdk.org  Tue Jun  3 14:27:57 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 14:27:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v20]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@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:

  uodate to JNDI

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/ab6387d8..1a6f5af2

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

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

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

From dfuchs at openjdk.org  Tue Jun  3 14:27:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 14:27:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v20]
In-Reply-To: <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>
Message-ID: <ipCTRLZJFZ552tbf9IHpkAhXwOtPdgOXDPmliSJieUc=.f0ed0520-c99d-4d6f-ad46-03891f10ca76@github.com>

On Tue, 3 Jun 2025 14:23:54 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:
> 
>   uodate to JNDI

Thanks for the last updates Michael. I believe we're good now!

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2892676320

From mullan at openjdk.org  Tue Jun  3 15:14:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 3 Jun 2025 15:14:54 GMT
Subject: RFR: 8350689: Turn on timestamp and thread metadata by default for
 java.security.debug [v4]
In-Reply-To: <pfqYJsiKk5wqgZ_vA-tYdx3LE94_MLtrbHg3vh0QcyU=.8a787050-277e-48d6-9370-eca2a1e860de@github.com>
References: <ICRPdwS8zU1KgGep1aOvQTR-7a9B7q6wih0dTrRl8iE=.bf7802d2-e65a-435f-b88b-0ac02c1e4e12@github.com>
 <pfqYJsiKk5wqgZ_vA-tYdx3LE94_MLtrbHg3vh0QcyU=.8a787050-277e-48d6-9370-eca2a1e860de@github.com>
Message-ID: <TXBrwdYPsohLRnGi6qb9wDYchxQ3n5ealwvQwDJJtTQ=.ccc5f78d-c76a-4016-8b58-2e83612f4d71@github.com>

On Tue, 3 Jun 2025 13:38:16 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property.
>> 
>> 
>> To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data.
>> 
>> This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data.
>> 
>> Debug output data from use of the `java.security.debug` property will now resemble something like the following:
>> 
>> 
>> 
>> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
>> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
>> 
>> 
>> I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch.
>
> Sean Coffey has updated the pull request 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:
> 
>  - tweak sentence in debug-system-property.html
>  - Merge branch 'master' into 8350689-default-timestamps
>  - Update property doc as per Sean Mullan comment
>  - Incorporate review comments from Mark
>  - Merge branch 'master' into 8350689-default-timestamps
>  - update system property doc
>  - 8350689

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25528#pullrequestreview-2892968462

From mullan at openjdk.org  Tue Jun  3 15:33:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 3 Jun 2025 15:33:56 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
Message-ID: <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>

On Tue, 3 Jun 2025 13:15:33 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.

I'm not sure what you mean - can you give an example? I don't see any advantages of using a static method here, but I agree it works either way.

> I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.

I view this test utility class as being flexible enough for different cases. This is a useful method in that the other parameters are common fields that all certs usually have but it also means I can't use this method to to create a certificate with a longer, or shorter validity period. Alternatively, how about adding another method that hard-codes it as one hour:

`CertificateBuilder oneHourValidity()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2124254602

From michaelm at openjdk.org  Tue Jun  3 15:39:06 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 15:39:06 GMT
Subject: Integrated: 8348986: Improve coverage of enhanced exception messages
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <ANCJMV9FtfHoAU_5eMxPFITXqxhqUwFM7UMQW1kicBQ=.57bfe450-373c-45b6-94a8-4a8b33c873f4@github.com>

On Thu, 6 Mar 2025 10:24:13 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

This pull request has now been integrated.

Changeset: b6f827ef
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6f827ef054959662190e21ce63fc3d3c45b92f3
Stats:     984 lines in 47 files changed: 709 ins; 101 del; 174 mod

8348986: Improve coverage of enhanced exception messages

Reviewed-by: dfuchs

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

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

From mdonovan at openjdk.org  Tue Jun  3 16:05:55 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 16:05:55 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
 <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
Message-ID: <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>

On Tue, 3 Jun 2025 15:31:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.
>> 
>> I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.
>
>> I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.
> 
> I'm not sure what you mean - can you give an example? I don't see any advantages of using a static method here, but I agree it works either way.
> 
>> I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.
> 
> I view this test utility class as being flexible enough for different cases. This is a useful method in that the other parameters are common fields that all certs usually have but it also means I can't use this method to to create a certificate with a longer, or shorter validity period. Alternatively, how about adding another method that hard-codes it as one hour:
> 
> `CertificateBuilder oneHourValidity()`

As a constructor, the code would look like this


public CertificateBuilder(String subjectName,
                              PublicKey publicKey, PublicKey caKey, KeyUsage... keyUsages)
            throws CertificateException, IOException {
        factory = CertificateFactory.getInstance("X.509");
        SecureRandom random = new SecureRandom();

        boolean [] keyUsage = new boolean[KeyUsage.values().length];
        for (KeyUsage ku : keyUsages) {
            keyUsage[ku.ordinal()] = true;
        }

        this.subjectName = new X500Principal(subjectName);
        this.publicKey = Objects.requireNonNull(publicKey, "Caught null public key");
        notBefore = (Date)Date.from(Instant.now().minus(1, ChronoUnit.HOURS));
        notAfter = Date.from(Instant.now().plus(1, ChronoUnit.HOURS));
        serialNumber = BigInteger.valueOf(random.nextLong(1000000)+1);
        byte[] keyIdBytes = new KeyIdentifier(publicKey).getIdentifier();
        Extension e = new SubjectKeyIdentifierExtension(keyIdBytes);
        extensions.put(e.getId(), e);

        KeyIdentifier kid = new KeyIdentifier(caKey);
        e = new AuthorityKeyIdentifierExtension(kid, null, null);
        extensions.put(e.getId(), e);

        if (keyUsages.length != 0) {
            e = new KeyUsageExtension(keyUsage);
            extensions.put(e.getId(), e);
        }
    }



>   it also means I can't use this method to to create a certificate with a longer, or shorter validity period

There are methods to set the not-before and not-after fields. Any field set in this static method can be changed:

`
newCertificateBuilder(...).notAfter(Date.from(Instant.now().plus(10, TimeUnit.YEARS)));
`

I don't like using `Date` here and would be happy to overload it to take `Instant` as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2124330323

From ascarpino at openjdk.org  Tue Jun  3 16:15:31 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 3 Jun 2025 16:15:31 GMT
Subject: RFR: 8358099: PEM spec updates
Message-ID: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>

Hi, I need a review of some PEM updates.  `PEMRecord.pem` is renamed to `content` to better describe that it is the base64 content and not including the header and footer. Additionally, `PEMRecord.getEncoded()` is removed and some javadoc clarifications for PEMEncoder and PEMDecoder.  Thanks.

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

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/25620/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25620&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358099
  Stats: 67 lines in 6 files changed: 1 ins; 20 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/25620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25620/head:pull/25620

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

From mullan at openjdk.org  Tue Jun  3 16:31:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 3 Jun 2025 16:31:56 GMT
Subject: RFR: 8358099: PEM spec updates
In-Reply-To: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
References: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
Message-ID: <W8RC2c1ZNm8EToCR1GtorVNLi0C0R2CamL3bUJfEOyk=.5a28363c-3ac3-451e-b24d-b8c3d1c0da37@github.com>

On Tue, 3 Jun 2025 16:09:32 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi, I need a review of some PEM updates.  `PEMRecord.pem` is renamed to `content` to better describe that it is the base64 content and not including the header and footer. Additionally, `PEMRecord.getEncoded()` is removed and some javadoc clarifications for PEMEncoder and PEMDecoder.  Thanks.

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

> 91:  * public key will be returned in that format.  Any type of PEM data can be
> 92:  * decoded into a {@code PEMRecord} by specifying {@code PEMRecord.class}.
> 93:  * If the class parameter doesn't match the PEM content, an

s/an/a/

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

> 125:  * @implNote An implementation may support other PEM types and
> 126:  * {@code DEREncodable} objects. This implementation additionally supports
> 127:  * PEM types:  {@code X509 CERTIFICATE}, {@code X.509 CERTIFICATE}, {@code CRL},

Suggest to insert "the following" before "PEM types"

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

> 289: 
> 290:         // If `keySpec` is non-null, then `key` hasn't been established.
> 291:         // Setting a `key` prevents repeated key generations operations.

s/generations/generation/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25620#discussion_r2124365392
PR Review Comment: https://git.openjdk.org/jdk/pull/25620#discussion_r2124371518
PR Review Comment: https://git.openjdk.org/jdk/pull/25620#discussion_r2124374177

From weijun at openjdk.org  Tue Jun  3 16:37:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Jun 2025 16:37:53 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
 <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>
Message-ID: <Vl-kbwNIBs0PMNSVHDHbicUBj6_gqwSHN-8rqUI1BvA=.35f594fc-e149-4ccb-b0c5-7f02ad047b1f@github.com>

On Fri, 30 May 2025 13:59:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> > Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`.
> 
> Required changes are pretty minimal ? passing `System.getProperty("stdin.encoding")` as an argument to the ctor. I doubt adding an extra layer of indirection (plus the need for changes in `@build` and `@library` tags) will worth it.

I?m just not sure if we?ll end up changing the rule again in the future. Hardcoding the system property name makes me a bit uneasy, and the default fallback being hardcoded as well adds to that concern.

That said, the changes to the security tools look good and should work as expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2936243501

From mullan at openjdk.org  Tue Jun  3 17:37:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 3 Jun 2025 17:37:07 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
 <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
 <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>
Message-ID: <xEMRItOXiz4QiIfzOGi5uyciDwMlL_RXN-mqbMWK7D0=.22861fb0-6375-43cc-be8f-04e42d03de5c@github.com>

On Tue, 3 Jun 2025 16:03:09 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> As a constructor, the code would look like this

<snip>

Ah, I see. Well technically you could call the set methods from the ctor but you would get `this-escape` compiler warnings, which you probably want to avoid.

> > it also means I can't use this method to to create a certificate with a longer, or shorter validity period
> 
> There are methods to set the not-before and not-after fields. Any field set in this static method can be changed:
> 
> `newCertificateBuilder(...).notAfter(Date.from(Instant.now().plus(10, TimeUnit.YEARS)));`
> 
> I don't like using `Date` here and would be happy to overload it to take `Instant` as well.

Yes, but I don't think the static method which is generically named `newCertificateBuilder` should be hard-coding a one hour validity period, that detail should be either in a different method (my preference) or this method should be named more clearly like `oneHourCertificateBuilder`. I realize this is just a test method, but this is a nicely designed API that has been very useful so I would prefer if we keep the flexibility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2124489674

From ihse at openjdk.org  Tue Jun  3 17:52:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Jun 2025 17:52:55 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v3]
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

Magnus Ihse Bursie has updated the pull request 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 branch 'master' into utf8-minor-cleanup
 - Revert changes in RotFontBoundsTest.java
 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java
 - Replace uncessary unicode characters with ASCII in instructions, and fix typo
 - Seems like typos in the comments
 - Fix unicode sequences in comments (previously missed)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/7184e685..c3027c1a

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

  Stats: 125596 lines in 1865 files changed: 71361 ins; 38692 del; 15543 mod
  Patch: https://git.openjdk.org/jdk/pull/25228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228

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

From ihse at openjdk.org  Tue Jun  3 17:52:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Jun 2025 17:52:57 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <DsuF98gTV85TRV5ofvmvH_-7fKmRNk28rI3RJV4e6Gk=.bc6bd102-147c-497e-9734-1bf6863060df@github.com>

On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

@naotoj Are you happy with the other changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/25228#issuecomment-2936435086

From naoto at openjdk.org  Tue Jun  3 17:52:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 17:52:55 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v3]
In-Reply-To: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>
Message-ID: <gah_JMPE3xHcudSsDq_iqqxmTfi3edTCv8NCbKznr1M=.67bfc258-b96f-4d60-b2f7-cda514b11b68@github.com>

On Tue, 3 Jun 2025 17:42:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request 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 branch 'master' into utf8-minor-cleanup
>  - Revert changes in RotFontBoundsTest.java
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java
>  - Replace uncessary unicode characters with ASCII in instructions, and fix typo
>  - Seems like typos in the comments
>  - Fix unicode sequences in comments (previously missed)

> @naotoj Are you happy with the other changes?

Yes. Thank you for the cleanup!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2893481166

From vyazici at openjdk.org  Tue Jun  3 19:08:17 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 19:08:17 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <Vl-kbwNIBs0PMNSVHDHbicUBj6_gqwSHN-8rqUI1BvA=.35f594fc-e149-4ccb-b0c5-7f02ad047b1f@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
 <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>
 <Vl-kbwNIBs0PMNSVHDHbicUBj6_gqwSHN-8rqUI1BvA=.35f594fc-e149-4ccb-b0c5-7f02ad047b1f@github.com>
Message-ID: <wYx8GmUa9k8P3LWrlcgLIGdsNsb-iAFq68A8mCYNFi0=.0e5b689f-6d56-4278-bafa-87ea1db6ac2c@github.com>

On Tue, 3 Jun 2025 16:35:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I?m just not sure if we?ll end up changing the rule again in the future. Hardcoding the system property name makes me a bit uneasy, and the default fallback being hardcoded as well adds to that concern.

Thanks so much for the review @wangweij. What would be your preference?

1. Leave things as is
2. Add an internal method to create stdin-aware `Scanner`/`InputStreamReader` (If this is your preference, any hints on which class I shall use? Shall I create a new `src/java.base/share/classes/jdk/internal/io/StdinAware.java`? Something else?)
3. Add a test utility method to create stdin-aware `Scanner`/`InputStreamReader`
4. Something else

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2936772995

From weijun at openjdk.org  Tue Jun  3 20:02:27 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Jun 2025 20:02:27 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
Message-ID: <vHzpavpczSKL0Mt6tcnqTJ86WVo8GXMBnJRyCKbUh40=.20742ec0-3fe4-4480-86f9-32807e5128d5@github.com>

On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing `java.io.Reader` import in `Ktab`

Personally I think both 2 and 3 are good. However, I'm totally OK with keeping your current code if no one else think it's worth a rewrite.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2936969327

From naoto at openjdk.org  Tue Jun  3 20:12:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 20:12:17 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
Message-ID: <0r4lN4voPGXnF1IPlmMGgdyZd54Y4a5GdOsngNbSGlY=.03c9a53f-b044-44d3-affa-4542a7711d8c@github.com>

On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing `java.io.Reader` import in `Ktab`

I was thinking if someone made a typo for "stdin.encoding" and then it unknowingly defaults to the fallback. Turned out it immediately fails with "java.lang.IllegalArgumentException: Null charset name" so I think it should be OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2937031130

From ascarpino at openjdk.org  Tue Jun  3 21:09:32 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 3 Jun 2025 21:09:32 GMT
Subject: RFR: 8358099: PEM spec updates [v2]
In-Reply-To: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
References: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
Message-ID: <yCauR44OEzwb4XKrVgRB1j0CXogjg5f8dt7b43asplo=.0af4047e-982a-490e-b337-0d166d25e3a2@github.com>

> Hi, I need a review of some PEM updates.  `PEMRecord.pem` is renamed to `content` to better describe that it is the base64 content and not including the header and footer. Additionally, `PEMRecord.getEncoded()` is removed and some javadoc clarifications for PEMEncoder and PEMDecoder.  Thanks.

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

  comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25620/files
  - new: https://git.openjdk.org/jdk/pull/25620/files/8de4469f..cbb00924

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

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

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

From duke at openjdk.org  Wed Jun  4 04:27:11 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 4 Jun 2025 04:27:11 GMT
Subject: RFR: 8355379: Annotate lazy fields in java.security @Stable
Message-ID: <BdTzABSl5jaGkV-xByy2FlnE8-JPfLejMQBjRZNLBjY=.b6265489-d61e-4572-a523-93e77be49e0c@github.com>

Several classes in the `java.security` package lazily compute their hash value and store it in a field. These fields can typically be annotated with the `@Stable` annotation. Many of the current implementations are using -1 as a flag for not computed, this needs to be refactored away.

Here are some examples of such classes: PKCS12Attribute, Timestamp, Certificate, and URICertStoreParameters.

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

Commit messages:
 - 8355379: Annotate lazy fields in java.security @Stable
 - Merge branch 'master' into 8355379
 - 8355379: Annotate lazy fields in java.security @Stable

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

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

From ihse at openjdk.org  Wed Jun  4 08:14:23 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 4 Jun 2025 08:14:23 GMT
Subject: Integrated: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <At8VnpzuhZYQNUNMKjqDDQJWpn-95O-PP01qGcpOB20=.8371e2ec-5f36-4a13-b566-6482ac2b6667@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

This pull request has now been integrated.

Changeset: edf92721
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edf92721c2db4cfba091cf4901af603db8486951
Stats:     15 lines in 13 files changed: 0 ins; 0 del; 15 mod

8356977: UTF-8 cleanups

Reviewed-by: naoto, prr

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

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

From coffeys at openjdk.org  Wed Jun  4 09:44:23 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 4 Jun 2025 09:44:23 GMT
Subject: Integrated: 8350689: Turn on timestamp and thread metadata by default
 for java.security.debug
In-Reply-To: <ICRPdwS8zU1KgGep1aOvQTR-7a9B7q6wih0dTrRl8iE=.bf7802d2-e65a-435f-b88b-0ac02c1e4e12@github.com>
References: <ICRPdwS8zU1KgGep1aOvQTR-7a9B7q6wih0dTrRl8iE=.bf7802d2-e65a-435f-b88b-0ac02c1e4e12@github.com>
Message-ID: <2_nbj_wEqzLfEwnHHbVrGaWXKagBnDftslgd8QR9J_Y=.964828db-4889-47fc-9f3f-c1ea1bcdcabf@github.com>

On Thu, 29 May 2025 19:06:15 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Removal of the `+thread` and `+timestamp` options that were used to control the logging behavior of output from the `java.security.debug` system property.
> 
> 
> To enhance the security debug logs, the thread and timestamp data should always be present. This brings it to a par with another important security debug system property, the TLS debug property: javax.net.debug. Output from the TLS `javax.net.debug` logs always contains thread and timestamp data.
> 
> This patch remove the `+thread` and `+timestamp` support code and print thread and timestamp data by default. This enancement is only proposed for the JDK feature release. Update releases can continue to opt into such data.
> 
> Debug output data from use of the `java.security.debug` property will now resemble something like the following:
> 
> 
> 
> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: package.definition=sun.misc.,sun.reflect.
> properties[0x10|main|Security.java:122|2025-05-01 14:59:42.859 UTC]: Initial security property: krb5.kdc.bad.policy=tryLast
> 
> 
> I've also trimmed back on some of the test case coverage since use of `+thread` and `+timestamp` options is now redundant with this patch.

This pull request has now been integrated.

Changeset: 42f48a39
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42f48a39e867ae1683708dda3e158c24a6957180
Stats:     184 lines in 5 files changed: 15 ins; 130 del; 39 mod

8350689: Turn on timestamp and thread metadata by default for java.security.debug

Reviewed-by: mullan

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

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

From varadam at openjdk.org  Wed Jun  4 10:30:04 2025
From: varadam at openjdk.org (Varada M)
Date: Wed, 4 Jun 2025 10:30:04 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v2]
In-Reply-To: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
Message-ID: <dtw3lMIUGsqvVnyfHP9Cj7KPTF7EPzmQK7TpsBhz3Q0=.f6dc76bb-37a1-4c3b-9b35-4ed0b6927f9b@github.com>

> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
> 
> Testing done for : tier1 - fastdebug level (AIX)
> 
> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  jtreg test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25547/files
  - new: https://git.openjdk.org/jdk/pull/25547/files/e7a35711..ccc650bb

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

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

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

From varadam at openjdk.org  Wed Jun  4 10:37:28 2025
From: varadam at openjdk.org (Varada M)
Date: Wed, 4 Jun 2025 10:37:28 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
In-Reply-To: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
Message-ID: <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>

> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
> 
> Testing done for : tier1 - fastdebug level (AIX)
> 
> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  whitespace error fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25547/files
  - new: https://git.openjdk.org/jdk/pull/25547/files/ccc650bb..b5854da0

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

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

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

From pminborg at openjdk.org  Wed Jun  4 11:39:18 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 4 Jun 2025 11:39:18 GMT
Subject: RFR: 8355379: Annotate lazy fields in java.security @Stable
In-Reply-To: <BdTzABSl5jaGkV-xByy2FlnE8-JPfLejMQBjRZNLBjY=.b6265489-d61e-4572-a523-93e77be49e0c@github.com>
References: <BdTzABSl5jaGkV-xByy2FlnE8-JPfLejMQBjRZNLBjY=.b6265489-d61e-4572-a523-93e77be49e0c@github.com>
Message-ID: <2pAp5aEu2qlPRpjEu4Jwk3o-FtT_rvgiuXtN61iRWqk=.564fa993-af2c-4f28-ae6f-c11d97e16b9a@github.com>

On Fri, 23 May 2025 04:54:26 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> Several classes in the `java.security` package lazily compute their hash value and store it in a field. These fields can typically be annotated with the `@Stable` annotation. Many of the current implementations are using -1 as a flag for not computed, this needs to be refactored away.
> 
> Here are some examples of such classes: PKCS12Attribute, Timestamp, Certificate, and URICertStoreParameters.

I think we should add tests that seralizes/deserializes objects several times to make sure the hash code works as expected here.

src/java.base/share/classes/java/security/CodeSigner.java line 172:

> 170:             throw new InvalidObjectException("signerCertPath is null");
> 171:         }
> 172:         myhash = 0;

I do not think we can use `@Stable` for this class, as `readObject()` can be called multiple times on an object.

src/java.base/share/classes/java/security/Timestamp.java line 179:

> 177:             throw new InvalidObjectException("Invalid null field(s)");
> 178:         }
> 179:         myhash = 0;

Same here.

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

PR Comment: https://git.openjdk.org/jdk/pull/25405#issuecomment-2939685005
PR Review Comment: https://git.openjdk.org/jdk/pull/25405#discussion_r2126373067
PR Review Comment: https://git.openjdk.org/jdk/pull/25405#discussion_r2126374887

From fguallini at openjdk.org  Wed Jun  4 12:02:36 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 4 Jun 2025 12:02:36 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API [v2]
In-Reply-To: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
Message-ID: <QwNcFqx18vRFu7qCVAwxxZu2xklIjDV9vvjdoHOAOQQ=.bbf11586-9105-4b1a-9eaa-9bb8dafe6a2d@github.com>

> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing

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

 - Merge branch 'master' into 8358171
 - add logging line
 - lines comments
 - add final break and test comment
 - multi thread and defaut algo tests
 - more test coverage for PEM

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25588/files
  - new: https://git.openjdk.org/jdk/pull/25588/files/6f18e8b2..a74a76c2

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

  Stats: 8811 lines in 345 files changed: 6496 ins; 1064 del; 1251 mod
  Patch: https://git.openjdk.org/jdk/pull/25588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25588/head:pull/25588

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

From amitkumar at openjdk.org  Wed Jun  4 12:37:30 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 4 Jun 2025 12:37:30 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
In-Reply-To: <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
Message-ID: <aEHNIJhxNkx_HQP2jhRrMBQg7wS_nnGee-PLIh8A5x0=.e95394fd-7bcb-4605-bde4-52ea1be533e6@github.com>

On Wed, 4 Jun 2025 10:37:28 GMT, Varada M <varadam at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace error fix

LGTM

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

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25547#pullrequestreview-2896543679

From valeriep at openjdk.org  Wed Jun  4 13:19:19 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 4 Jun 2025 13:19:19 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw IllegalStateException
 when getEncoded() is called
Message-ID: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>

Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 

1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed
2. serialization of such destroyed `PBEKey` object will lead to exception. 
 
Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc.

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

Commit messages:
 - 8358451: SunJCE PBEKey impl should throw IllegalStateException when getEncoded() is called

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

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

From mullan at openjdk.org  Wed Jun  4 13:42:51 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 4 Jun 2025 13:42:51 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
In-Reply-To: <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
Message-ID: <De8mtWP2zRlYP7cAk5MPYPqnRX5H5a2PGrrMorTN9dE=.28101479-01c5-4e34-a4bb-ed5cc0dfce25@github.com>

On Wed, 4 Jun 2025 10:37:28 GMT, Varada M <varadam at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace error fix

@valeriepeng Can you also review this? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25547#issuecomment-2940086483

From weijun at openjdk.org  Wed Jun  4 15:06:33 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 4 Jun 2025 15:06:33 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key
Message-ID: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>

Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.

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

Commit messages:
 - the fix

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

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

From weijun at openjdk.org  Wed Jun  4 15:14:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 4 Jun 2025 15:14:51 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called
In-Reply-To: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
Message-ID: <SbxuNsmyP7PkGCMSPq6myUIIRRiv9dhsp8cULVD6dAo=.cb9967e5-047a-48a2-afc6-4e1cb4aa7e6d@github.com>

On Wed, 4 Jun 2025 03:10:29 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 
> 
> 1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed
> 2. serialization of such destroyed `PBEKey` object will lead to exception. 
>  
> Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc.

src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 1:

> 1: /*

Shall we also throw ISE when `getFormat` and `getAlgorithm` are called? Calling these methods after the key is destroyed looks suspicious and may reveal a coding error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2126853766

From weijun at openjdk.org  Wed Jun  4 15:17:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 4 Jun 2025 15:17:50 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called
In-Reply-To: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
Message-ID: <OLoWC8G0mCZjRexhtTvVulZt_UYhxrN-cwCR6C2vbyU=.1d2060cb-b539-4185-96fc-4b55c0cd0f5e@github.com>

On Wed, 4 Jun 2025 03:10:29 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 
> 
> 1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed
> 2. serialization of such destroyed `PBEKey` object will lead to exception. 
>  
> Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc.

src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 82:

> 80:     }
> 81: 
> 82:     public byte[] getEncoded() {

I understand this is not a public API class so there is no need to provide `@throws` in the spec. But, on the other hand, do we need to provide one in its super class `java.security.key`? I have no opinion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2126861948

From dfuchs at openjdk.org  Wed Jun  4 15:46:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 15:46:36 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v6]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 495 commits:

 - merge latest changes from master branch
 - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
 - http3: refactor HTTP/3 connection pool management in a separate class
 - Ignore DestroyFailedExceptions
 - Remove outdated TODO
 - Remove outdated TODO
 - Remove cryptic TODO
 - Remove outdated TODO
 - Fix race in test server's Http3StreamDispatcher
 - Test H3 server: close connection if control stream closed
 - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=05
  Stats: 103642 lines in 473 files changed: 100781 ins; 1345 del; 1516 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From dfuchs at openjdk.org  Wed Jun  4 16:08:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 16:08:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
 <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>
Message-ID: <UngOa-uQ8FF4qZk_AdQcyxqGWy_EsLCwDJDFv7MQqMQ=.a822c514-86df-452a-b63a-2716cc50b238@github.com>

On Fri, 16 May 2025 10:26:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:
>> 
>>  - merge latest changes from master branch
>>  - Undo whitespace change
>>  - Remove unnecessary import
>>  - Merge remote-tracking branch 'origin/master' into http3
>>  - Fix test license
>>  - Remove leftover file (test was moved to parent directory)
>>  - Remove unnecessary import
>>  - Update throws clauses
>>  - Merge remote-tracking branch 'origin/master' into http3
>>  - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
>>  - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 737:
> 
>> 735:         // channel, and a single selector thread, so we can do
>> 736:         // the reading directly in the selector thread and offload
>> 737:         // the parsing (the readLoop) to the executor.
> 
> This comment is outdated. We actually stop reading from the channel when the amount of data buffered exceeds a high watermark threshold.

Updated in latest commits (https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 822:
> 
>> 820:                     if (this.buffered.get() >= MAX_BUFFERED_HIGH) {
>> 821:                         pauseReading();
>> 822:                         readLoopScheduler.runOrSchedule(executor);
> 
> This line should not be needed: we should already have kicked the read loop at line 797.

Updated in latest commits (https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126958527
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126959414

From mpowers at openjdk.org  Wed Jun  4 16:10:58 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 4 Jun 2025 16:10:58 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key
In-Reply-To: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
Message-ID: <AyO0Mf947VpFTJ06IRCMOt3mPTq0QMc_0wCDpafX2QQ=.e486606b-fbae-4f78-ba70-bf9381b12462@github.com>

On Wed, 4 Jun 2025 14:59:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.

src/java.base/share/classes/sun/security/util/KeyUtil.java line 56:

> 54:      * Traditionally, the key size of an asymmetric key refers to the size of
> 55:      * its modulus. For example, a 2048-bit RSA key or a 256-bit NIST P-256 EC
> 56:      * key. However, modern post-quantum algorithms based on lattice cryptography,

I would not say "modern post-quantum".

src/java.base/share/classes/sun/security/util/KeyUtil.java line 134:

> 132: 
> 133:     /**
> 134:      * Returns the NIST security categories defined for PQC algorithms. It was

s/was/is/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2126930677
PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2126940503

From abarashev at openjdk.org  Wed Jun  4 16:10:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 4 Jun 2025 16:10:59 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key
In-Reply-To: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
Message-ID: <me8UL2NboSO-m359ZuQ1YPjoVcZaPujZZV5njVdJrXw=.d67dae0c-5a56-4de7-8d8c-b95cf943d31f@github.com>

On Wed, 4 Jun 2025 14:59:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.

src/java.base/share/classes/sun/security/util/KeyUtil.java line 62:

> 60:      * each standardized parameter set. For example, ML-KEM-768 is assigned to
> 61:      * category 3, and ML-DSA-87 to category 5.
> 62:      *

Should we consider returning whatever number is an the end of PQC algorithms as a key size? That would make things consistent and it would allow us to use existing `keySize` algorithm constraints for PQC algorithms. Key sizes for RSA and EC algorithms already differ significantly for the same security level: 3072-bit RSA corresponds to 256-bit EC. So we can return `768` for ML-KEM-768 or `87` for ML-DSA-87.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2126968358

From weijun at openjdk.org  Wed Jun  4 16:48:08 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 4 Jun 2025 16:48:08 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v2]
In-Reply-To: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
Message-ID: <2Wn63i462_Dg4xOCC_DTq7WaRat4jo2ppkIUnjG50E8=.62a78d06-aad3-4083-b608-3a0fe5ca3270@github.com>

> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.

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

  addressing Mark's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25642/files
  - new: https://git.openjdk.org/jdk/pull/25642/files/bd7abe8e..157c53b9

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

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

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

From fguallini at openjdk.org  Wed Jun  4 16:49:11 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Wed, 4 Jun 2025 16:49:11 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API [v3]
In-Reply-To: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
Message-ID: <r77ozI45qSxm3WTWI0cLHBKIr3g-NLLSojS6wCHX_oI=.b3dbfa7f-0fd5-4d60-bcad-c712f3ff179e@github.com>

> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing

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

  add invalid PEM content test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25588/files
  - new: https://git.openjdk.org/jdk/pull/25588/files/a74a76c2..c16eabe1

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

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

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

From weijun at openjdk.org  Wed Jun  4 16:52:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 4 Jun 2025 16:52:54 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v2]
In-Reply-To: <me8UL2NboSO-m359ZuQ1YPjoVcZaPujZZV5njVdJrXw=.d67dae0c-5a56-4de7-8d8c-b95cf943d31f@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
 <me8UL2NboSO-m359ZuQ1YPjoVcZaPujZZV5njVdJrXw=.d67dae0c-5a56-4de7-8d8c-b95cf943d31f@github.com>
Message-ID: <UdJF_NezfY9yJ9TVLsipSNIJAgzRacl9TXrp-CKNIpU=.0a063f4b-6708-472d-93bb-47d6a08f202d@github.com>

On Wed, 4 Jun 2025 16:08:31 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing Mark's comments
>
> src/java.base/share/classes/sun/security/util/KeyUtil.java line 62:
> 
>> 60:      * each standardized parameter set. For example, ML-KEM-768 is assigned to
>> 61:      * category 3, and ML-DSA-87 to category 5.
>> 62:      *
> 
> Should we consider returning whatever number is an the end of PQC algorithms as a key size? That would make things consistent and it would allow us to use existing `keySize` algorithm constraints for PQC algorithms. Key sizes for RSA and EC algorithms already differ significantly for the same security level: 3072-bit RSA corresponds to 256-bit EC. So we can return `768` for ML-KEM-768 or `87` for ML-DSA-87.

For ML-DSA-87, 87 isn?t a key size in any sense. Using it as a key size would be misleading. For algorithm constraints, we can use the parameter set name directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2127040718

From valeriep at openjdk.org  Wed Jun  4 17:44:53 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 4 Jun 2025 17:44:53 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
In-Reply-To: <De8mtWP2zRlYP7cAk5MPYPqnRX5H5a2PGrrMorTN9dE=.28101479-01c5-4e34-a4bb-ed5cc0dfce25@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
 <De8mtWP2zRlYP7cAk5MPYPqnRX5H5a2PGrrMorTN9dE=.28101479-01c5-4e34-a4bb-ed5cc0dfce25@github.com>
Message-ID: <Am-bb4OHIIwkdd8jpYetKW-ZCQHo9dnf1RR5AIfggoo=.9b07b6ce-fdb6-4e25-938d-a25f8218d1e6@github.com>

On Wed, 4 Jun 2025 13:39:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> @valeriepeng Can you also review this? Thanks.

Yes, I have started looking at it. Was about to ask for a regression test, and you beat me to it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25547#issuecomment-2940866076

From abarashev at openjdk.org  Wed Jun  4 17:51:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 4 Jun 2025 17:51:55 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v2]
In-Reply-To: <UdJF_NezfY9yJ9TVLsipSNIJAgzRacl9TXrp-CKNIpU=.0a063f4b-6708-472d-93bb-47d6a08f202d@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
 <me8UL2NboSO-m359ZuQ1YPjoVcZaPujZZV5njVdJrXw=.d67dae0c-5a56-4de7-8d8c-b95cf943d31f@github.com>
 <UdJF_NezfY9yJ9TVLsipSNIJAgzRacl9TXrp-CKNIpU=.0a063f4b-6708-472d-93bb-47d6a08f202d@github.com>
Message-ID: <n5R6fzivCBRaIX9r2xQUu-bJLyn4NnnEIS5b2RWLXrM=.6b09b638-df44-4412-89c9-6bfa73ecddb6@github.com>

On Wed, 4 Jun 2025 16:50:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/KeyUtil.java line 62:
>> 
>>> 60:      * each standardized parameter set. For example, ML-KEM-768 is assigned to
>>> 61:      * category 3, and ML-DSA-87 to category 5.
>>> 62:      *
>> 
>> Should we consider returning whatever number is an the end of PQC algorithms as a key size? That would make things consistent and it would allow us to use existing `keySize` algorithm constraints for PQC algorithms. Key sizes for RSA and EC algorithms already differ significantly for the same security level: 3072-bit RSA corresponds to 256-bit EC. So we can return `768` for ML-KEM-768 or `87` for ML-DSA-87.
>
> For ML-DSA-87, 87 isn?t a key size in any sense. Using it as a key size would be misleading. For algorithm constraints, we can use the parameter set name directly.

Right, we should probably consider renaming `getKeySize()` to `getKeyStrength()`, but I guess that would be outside of this PR's scope.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2127131876

From valeriep at openjdk.org  Wed Jun  4 17:54:03 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 4 Jun 2025 17:54:03 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
In-Reply-To: <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
Message-ID: <qRfxN2onv-fQYI1d4SEbawYThWVQXqvkMpV296Kcik8=.b14b46a8-13eb-45f7-bfcc-40d40446a64c@github.com>

On Wed, 4 Jun 2025 10:37:28 GMT, Varada M <varadam at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace error fix

test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 27:

> 25:  * @test
> 26:  * @bug 8358159
> 27:  * @summary test that the Cipher.getInstance() handles transformations with empty mode and/or padding

nit: In general, we try to keep the lines <= 80 chars. Could you try breaking lines longer than 80 chars into multiple lines? There are a few lines in this test are longer than 80 chars.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2127134802

From dfuchs at openjdk.org  Wed Jun  4 17:54:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 17:54:25 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v6]
In-Reply-To: <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
Message-ID: <ilp-dq4Sz3lLQs-v9R-04shh7tKsaQLPBts7z5VO0zQ=.9c6aa5c9-357f-43c2-9481-e54e01f48ce4@github.com>

On Wed, 4 Jun 2025 15:46:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 495 commits:
> 
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - Remove cryptic TODO
>  - Remove outdated TODO
>  - Fix race in test server's Http3StreamDispatcher
>  - Test H3 server: close connection if control stream closed
>  - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0

src/java.net.http/share/classes/jdk/internal/net/http/hpack/HPACK.java line 176:

> 174: 
> 175:     @FunctionalInterface
> 176:     interface BufferUpdateConsumer {

@AlekseiEfimov It looks like this change is no longer required and could be reverted

src/java.net.http/share/classes/jdk/internal/net/http/hpack/ISO_8859_1.java line 43:

> 41: // The encoding is simple and well known: 1 byte <-> 1 char
> 42: //
> 43: final class ISO_8859_1 {

OK - this class is actually used in QPack as well as HPack. Same for the `QuickHuffman` class below (notice that this is Quick - not Quic ;-) )

It might be interesting to investigate if we could pull out these classes to a common location to break the tie between QPack and HPack. Something to think about after integration maybe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126966393
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2127123043

From rhalade at openjdk.org  Wed Jun  4 18:05:52 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 4 Jun 2025 18:05:52 GMT
Subject: RFR: 8357592: Update output parsing in
 test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java
In-Reply-To: <Kb9M3dxkVVBuWoIzQQmrWT8ldujOTJRh8Y-q7hn4Nrc=.c8251ca2-536d-4ffe-80cb-22582b83844c@github.com>
References: <Kb9M3dxkVVBuWoIzQQmrWT8ldujOTJRh8Y-q7hn4Nrc=.c8251ca2-536d-4ffe-80cb-22582b83844c@github.com>
Message-ID: <s4bxGvIhyLcgDRCIc5uKTtm74QogSeeoJEkMweYGhd0=.bc2b1f3e-7f17-4c68-a93a-a8c9717afa18@github.com>

On Thu, 22 May 2025 23:03:47 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I updated the jarsigner compatibility test to handle minor differences in the output of jarsigner between versions.

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25403#pullrequestreview-2897643246

From valeriep at openjdk.org  Wed Jun  4 18:09:54 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 4 Jun 2025 18:09:54 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
In-Reply-To: <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
Message-ID: <oDlnRO5Kq7yTjeEIxX2Q_CuGAioxWQLDtStbgM4ZwVw=.28f44a18-2b86-4e6c-a8a9-843ca9623349@github.com>

On Wed, 4 Jun 2025 10:37:28 GMT, Varada M <varadam at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace error fix

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

> 391:             this.suffix = suffix.toUpperCase(Locale.ENGLISH);
> 392:             this.mode = ((mode == null) || mode.isEmpty()) ? null : mode;
> 393:             this.pad = ((pad == null) || pad.isEmpty()) ? null : pad;

Thanks for reporting and fixing this issue. 
Since this is an internal class used solely inside `Cipher` class, instead of changing the empty string to null inside the `Transform` constuctor, we can do that before calling `Transform` constructor. Also if one of `mode` or `pad` is empty, then maybe we don't need all 4 `Transform`s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2127160213

From mdonovan at openjdk.org  Wed Jun  4 18:09:56 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 4 Jun 2025 18:09:56 GMT
Subject: Integrated: 8357592: Update output parsing in
 test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java
In-Reply-To: <Kb9M3dxkVVBuWoIzQQmrWT8ldujOTJRh8Y-q7hn4Nrc=.c8251ca2-536d-4ffe-80cb-22582b83844c@github.com>
References: <Kb9M3dxkVVBuWoIzQQmrWT8ldujOTJRh8Y-q7hn4Nrc=.c8251ca2-536d-4ffe-80cb-22582b83844c@github.com>
Message-ID: <gyySthc-X2pcEPtCEZUsdzAt9woz6-3nNkY6bq38wtU=.19e2a292-3644-42a8-b9c1-b16d7e4cce74@github.com>

On Thu, 22 May 2025 23:03:47 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I updated the jarsigner compatibility test to handle minor differences in the output of jarsigner between versions.

This pull request has now been integrated.

Changeset: 5ed246d1
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ed246d17d9f40489ed715b7df104ec6a832841e
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8357592: Update output parsing in test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java

Reviewed-by: rhalade

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

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

From valeriep at openjdk.org  Wed Jun  4 18:16:51 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 4 Jun 2025 18:16:51 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
In-Reply-To: <oDlnRO5Kq7yTjeEIxX2Q_CuGAioxWQLDtStbgM4ZwVw=.28f44a18-2b86-4e6c-a8a9-843ca9623349@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
 <oDlnRO5Kq7yTjeEIxX2Q_CuGAioxWQLDtStbgM4ZwVw=.28f44a18-2b86-4e6c-a8a9-843ca9623349@github.com>
Message-ID: <ubzMGt7xgq5YwCdLgtWzcNw5il6_HjSBc8PcodfnMOk=.54d57a0a-22e6-44e9-a7c3-7d2f30eba427@github.com>

On Wed, 4 Jun 2025 18:06:33 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   whitespace error fix
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 393:
> 
>> 391:             this.suffix = suffix.toUpperCase(Locale.ENGLISH);
>> 392:             this.mode = ((mode == null) || mode.isEmpty()) ? null : mode;
>> 393:             this.pad = ((pad == null) || pad.isEmpty()) ? null : pad;
> 
> Thanks for reporting and fixing this issue. 
> Since this is an internal class used solely inside `Cipher` class, instead of changing the empty string to null inside the `Transform` constuctor, we can do that before calling `Transform` constructor. Also if one of `mode` or `pad` is empty, then maybe we don't need all 4 `Transform`s.

For exampl, line 457, 458, we can do something like:

        String mode = (parts[1].length() == 0 ? null : parts[1]);
        String pad = (parts[2].length() == 0 ? null : parts[2]);

When populating the `list `(after line 467), we can skip the Tranform if the required component is missing, e.g.

            List<Transform> list = new ArrayList<>(4);
            if ((mode != null) && (pad != null)) {
                list.add(new Transform(alg, "/" + mode + "/" + pad, null, null));
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2127172956

From mullan at openjdk.org  Wed Jun  4 18:53:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 4 Jun 2025 18:53:53 GMT
Subject: RFR: 8349550: Improve SASL random usage [v4]
In-Reply-To: <cjlnYXMiUYNMxRszbvxiGnCYYofkCqyToHQ8Io_eHKI=.1105c51f-9c10-44f3-b1af-b6646fb562d2@github.com>
References: <D8e7CNHWtQIQdHBay1Xz0iGBTiB54XF-Dbfh0egoFUc=.c65f4143-0182-4e88-a9d8-8c82a829fae7@github.com>
 <cjlnYXMiUYNMxRszbvxiGnCYYofkCqyToHQ8Io_eHKI=.1105c51f-9c10-44f3-b1af-b6646fb562d2@github.com>
Message-ID: <u0ueLyfGL6fMktaeIM3qNLYdkCCHvpXZqZNnd2xok1w=.d1339e76-a65e-4c67-8b70-00cb866f5cb3@github.com>

On Fri, 30 May 2025 18:19:13 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random
>
> Koushik Muthukrishnan Thirupattur has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - 8349550: Improve SASL random usage
>  - Merge branch 'master' into 8349550
>  - 8349550: Improve SASL random usage
>  - Merge branch 'master' into 8349550
>  - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random
>  - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random
>  - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25241#pullrequestreview-2897769890

From mullan at openjdk.org  Wed Jun  4 20:44:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 4 Jun 2025 20:44:53 GMT
Subject: RFR: 8358099: PEM spec updates [v2]
In-Reply-To: <W8RC2c1ZNm8EToCR1GtorVNLi0C0R2CamL3bUJfEOyk=.5a28363c-3ac3-451e-b24d-b8c3d1c0da37@github.com>
References: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
 <W8RC2c1ZNm8EToCR1GtorVNLi0C0R2CamL3bUJfEOyk=.5a28363c-3ac3-451e-b24d-b8c3d1c0da37@github.com>
Message-ID: <xHWLF0g4shnRsLs0rVfYavcz3jOfsEDGd8Zh6iV1ITU=.f4a8d44c-1e2f-4995-bba0-f6018a16384e@github.com>

On Tue, 3 Jun 2025 16:24:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments
>
> src/java.base/share/classes/java/security/PEMDecoder.java line 127:
> 
>> 125:  * @implNote An implementation may support other PEM types and
>> 126:  * {@code DEREncodable} objects. This implementation additionally supports
>> 127:  * PEM types:  {@code X509 CERTIFICATE}, {@code X.509 CERTIFICATE}, {@code CRL},
> 
> Suggest to insert "the following" before "PEM types"

"the following" should not be in the first sentence, only the second sentence, as:

"This implementation additionally supports the following PEM types: ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25620#discussion_r2127402367

From ascarpino at openjdk.org  Wed Jun  4 22:23:05 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 4 Jun 2025 22:23:05 GMT
Subject: RFR: 8358099: PEM spec updates [v3]
In-Reply-To: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
References: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
Message-ID: <F-XDONrXV1MX5B_HbrMzn29nm9Q1-Uk_LSyJvIPOx_8=.0a0b0104-f1d4-40b7-865e-0f1d0ac3d7f9@github.com>

> Hi, I need a review of some PEM updates.  `PEMRecord.pem` is renamed to `content` to better describe that it is the base64 content and not including the header and footer. Additionally, `PEMRecord.getEncoded()` is removed and some javadoc clarifications for PEMEncoder and PEMDecoder.  Thanks.

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

  wrong "PEM types"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25620/files
  - new: https://git.openjdk.org/jdk/pull/25620/files/cbb00924..afdc32e5

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

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

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

From weijun at openjdk.org  Thu Jun  5 01:26:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 5 Jun 2025 01:26:04 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v3]
In-Reply-To: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
Message-ID: <TnWloajWzELKJAzASpdMn4-aSHmLwFuOp3gGFRB7snE=.7705403b-145d-4aa0-bdd8-6e230b69ecb2@github.com>

> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.

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

  enhance test to be exhaustive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25642/files
  - new: https://git.openjdk.org/jdk/pull/25642/files/157c53b9..5ec95fb2

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

  Stats: 42 lines in 1 file changed: 25 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25642/head:pull/25642

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

From ascarpino at openjdk.org  Thu Jun  5 01:55:56 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 5 Jun 2025 01:55:56 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API [v3]
In-Reply-To: <r77ozI45qSxm3WTWI0cLHBKIr3g-NLLSojS6wCHX_oI=.b3dbfa7f-0fd5-4d60-bcad-c712f3ff179e@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
 <r77ozI45qSxm3WTWI0cLHBKIr3g-NLLSojS6wCHX_oI=.b3dbfa7f-0fd5-4d60-bcad-c712f3ff179e@github.com>
Message-ID: <1fRTvMmhd-hQhDHW6v6b3RG_QlufGhRECS418IvHsEI=.dd436e0d-b800-4a6c-9f3b-cab1ecc98eb3@github.com>

On Wed, 4 Jun 2025 16:49:11 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add invalid PEM content test

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

> 498:         }
> 499:         Entry(String name, String pem, Class clazz, String provider, char[] password) {
> 500:             this(name, pem, clazz,provider, password, null);

nit:  no space after comma

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2127792563

From fguallini at openjdk.org  Thu Jun  5 08:14:15 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 5 Jun 2025 08:14:15 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API [v4]
In-Reply-To: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
Message-ID: <Kpnce6a3kqGP1Vxzm7XoCbjSm2ZColtwYc7ihzOjBZs=.c2efd449-8f48-4275-b355-574b52a95148@github.com>

> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing

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

 - comment
 - Merge branch 'master' into 8358171
 - add invalid PEM content test
 - Merge branch 'master' into 8358171
 - add logging line
 - lines comments
 - add final break and test comment
 - multi thread and defaut algo tests
 - more test coverage for PEM

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25588/files
  - new: https://git.openjdk.org/jdk/pull/25588/files/c16eabe1..ea306f56

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

  Stats: 8389 lines in 62 files changed: 7876 ins; 135 del; 378 mod
  Patch: https://git.openjdk.org/jdk/pull/25588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25588/head:pull/25588

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

From fguallini at openjdk.org  Thu Jun  5 08:14:16 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 5 Jun 2025 08:14:16 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API [v3]
In-Reply-To: <1fRTvMmhd-hQhDHW6v6b3RG_QlufGhRECS418IvHsEI=.dd436e0d-b800-4a6c-9f3b-cab1ecc98eb3@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
 <r77ozI45qSxm3WTWI0cLHBKIr3g-NLLSojS6wCHX_oI=.b3dbfa7f-0fd5-4d60-bcad-c712f3ff179e@github.com>
 <1fRTvMmhd-hQhDHW6v6b3RG_QlufGhRECS418IvHsEI=.dd436e0d-b800-4a6c-9f3b-cab1ecc98eb3@github.com>
Message-ID: <beuOA1DUXGfe5SAoOWIWGCaZoLPpPJ5BoEI85GkAQZ8=.0650455d-847b-4b1e-ad1e-dbad780e67d3@github.com>

On Thu, 5 Jun 2025 01:53:40 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add invalid PEM content test
>
> test/jdk/java/security/PEM/PEMData.java line 500:
> 
>> 498:         }
>> 499:         Entry(String name, String pem, Class clazz, String provider, char[] password) {
>> 500:             this(name, pem, clazz,provider, password, null);
> 
> nit:  no space after comma

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2128226751

From aturbanov at openjdk.org  Thu Jun  5 08:59:02 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 08:59:02 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API [v4]
In-Reply-To: <Kpnce6a3kqGP1Vxzm7XoCbjSm2ZColtwYc7ihzOjBZs=.c2efd449-8f48-4275-b355-574b52a95148@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
 <Kpnce6a3kqGP1Vxzm7XoCbjSm2ZColtwYc7ihzOjBZs=.c2efd449-8f48-4275-b355-574b52a95148@github.com>
Message-ID: <fao8XuOFZheMu_pDp6tgKBVeZRkzKy-LuZ5xxIlltSE=.2f55182a-3238-4d21-a341-cd9f6a86e87c@github.com>

On Thu, 5 Jun 2025 08:14:15 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing
>
> Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - comment
>  - Merge branch 'master' into 8358171
>  - add invalid PEM content test
>  - Merge branch 'master' into 8358171
>  - add logging line
>  - lines comments
>  - add final break and test comment
>  - multi thread and defaut algo tests
>  - more test coverage for PEM

test/jdk/java/security/PEM/PEMDecoderTest.java line 536:

> 534:             case "EC" -> "SHA256withECDSA";
> 535:             case "EdDSA" -> "EdDSA";
> 536:             case "RSASSA-PSS" ->  {

Suggestion:

            case "RSASSA-PSS" -> {

test/jdk/java/security/PEM/PEMMultiThreadTest.java line 47:

> 45:     public static void main(String[] args) throws Exception {
> 46:         PEMEncoder encoder = PEMEncoder.of();
> 47:         try(ExecutorService ex = Executors.newFixedThreadPool(THREAD_COUNT)) {

Suggestion:

        try (ExecutorService ex = Executors.newFixedThreadPool(THREAD_COUNT)) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2128316054
PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2128316488

From aturbanov at openjdk.org  Thu Jun  5 09:03:53 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 09:03:53 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
Message-ID: <Dgsv_uSz55K8txQhEFMYlV1LO2pK9uce85qifdv21hA=.7a279770-1103-4140-a3b2-15503dbb80e8@github.com>

On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing `java.io.Reader` import in `Ktab`

test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 181:

> 179: 
> 180:                 }
> 181:             } catch(Exception e) {

Suggestion:

            } catch (Exception e) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2128325755

From vyazici at openjdk.org  Thu Jun  5 10:13:24 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 10:13:24 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

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

  Improve code style
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/78e8de51..92248bb3

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

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

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

From fguallini at openjdk.org  Thu Jun  5 10:20:40 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 5 Jun 2025 10:20:40 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API [v5]
In-Reply-To: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
Message-ID: <XZVmWtqGn8Tq3_wA_iDW4rIZqDPx1t1QlXj3Rkvsbz4=.4a1ff43a-2204-4dfd-a075-11dc53d7a0fb@github.com>

> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing

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

  styling fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25588/files
  - new: https://git.openjdk.org/jdk/pull/25588/files/ea306f56..ff00187a

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

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

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

From fguallini at openjdk.org  Thu Jun  5 10:20:42 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Thu, 5 Jun 2025 10:20:42 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API [v4]
In-Reply-To: <fao8XuOFZheMu_pDp6tgKBVeZRkzKy-LuZ5xxIlltSE=.2f55182a-3238-4d21-a341-cd9f6a86e87c@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
 <Kpnce6a3kqGP1Vxzm7XoCbjSm2ZColtwYc7ihzOjBZs=.c2efd449-8f48-4275-b355-574b52a95148@github.com>
 <fao8XuOFZheMu_pDp6tgKBVeZRkzKy-LuZ5xxIlltSE=.2f55182a-3238-4d21-a341-cd9f6a86e87c@github.com>
Message-ID: <7xf2JbnwvwVJaeJWSr7_KWfvAW4iC_tGeORNQgBDj0M=.ddccefce-3514-497c-9b5a-8e0a171071a2@github.com>

On Thu, 5 Jun 2025 08:56:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - comment
>>  - Merge branch 'master' into 8358171
>>  - add invalid PEM content test
>>  - Merge branch 'master' into 8358171
>>  - add logging line
>>  - lines comments
>>  - add final break and test comment
>>  - multi thread and defaut algo tests
>>  - more test coverage for PEM
>
> test/jdk/java/security/PEM/PEMMultiThreadTest.java line 47:
> 
>> 45:     public static void main(String[] args) throws Exception {
>> 46:         PEMEncoder encoder = PEMEncoder.of();
>> 47:         try(ExecutorService ex = Executors.newFixedThreadPool(THREAD_COUNT)) {
> 
> Suggestion:
> 
>         try (ExecutorService ex = Executors.newFixedThreadPool(THREAD_COUNT)) {

Updated !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25588#discussion_r2128491245

From varadam at openjdk.org  Thu Jun  5 11:30:42 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 5 Jun 2025 11:30:42 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v4]
In-Reply-To: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
Message-ID: <OHyCsw9CoSKiMJxzJFQ4-leA3b0C9D0F-pXjUJ57mI4=.943e7c01-2cd5-41e5-a410-5b4cab63fd3b@github.com>

> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
> 
> Testing done for : tier1 - fastdebug level (AIX)
> 
> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  8358159: Empty mode/padding in cipher transformations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25547/files
  - new: https://git.openjdk.org/jdk/pull/25547/files/b5854da0..4bc7e62d

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

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

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

From varadam at openjdk.org  Thu Jun  5 11:30:42 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 5 Jun 2025 11:30:42 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v3]
In-Reply-To: <ubzMGt7xgq5YwCdLgtWzcNw5il6_HjSBc8PcodfnMOk=.54d57a0a-22e6-44e9-a7c3-7d2f30eba427@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <aCyNYqSiee4Gd-X0ywBwZTk6A05rmdNlbV60UmgN5qE=.e2b9f45e-b0b0-4547-8663-e1a2a2ab9fcd@github.com>
 <oDlnRO5Kq7yTjeEIxX2Q_CuGAioxWQLDtStbgM4ZwVw=.28f44a18-2b86-4e6c-a8a9-843ca9623349@github.com>
 <ubzMGt7xgq5YwCdLgtWzcNw5il6_HjSBc8PcodfnMOk=.54d57a0a-22e6-44e9-a7c3-7d2f30eba427@github.com>
Message-ID: <DjRDLWF1Pzcm2lthj2BlB-wWc4FzMtYBNBpOZpNQuMc=.683a0c5b-ccfb-48fc-8ade-56edcf071685@github.com>

On Wed, 4 Jun 2025 18:13:59 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/Cipher.java line 393:
>> 
>>> 391:             this.suffix = suffix.toUpperCase(Locale.ENGLISH);
>>> 392:             this.mode = ((mode == null) || mode.isEmpty()) ? null : mode;
>>> 393:             this.pad = ((pad == null) || pad.isEmpty()) ? null : pad;
>> 
>> Thanks for reporting and fixing this issue. 
>> Since this is an internal class used solely inside `Cipher` class, instead of changing the empty string to null inside the `Transform` constuctor, we can do that before calling `Transform` constructor. Also if one of `mode` or `pad` is empty, then maybe we don't need all 4 `Transform`s.
>
> For example, line 457, 458, we can do something like:
> 
>         String mode = (parts[1].length() == 0 ? null : parts[1]);
>         String pad = (parts[2].length() == 0 ? null : parts[2]);
> 
> When populating the `list `(after line 467), we can skip the Tranform if the required component is missing, e.g.
> 
>             List<Transform> list = new ArrayList<>(4);
>             if ((mode != null) && (pad != null)) {
>                 list.add(new Transform(alg, "/" + mode + "/" + pad, null, null));
>             }

Thank you @valeriepeng. I have made the suggested changes. Did the jtreg testing too, it looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2128613087

From mullan at openjdk.org  Thu Jun  5 12:20:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 12:20:53 GMT
Subject: RFR: 8358099: PEM spec updates [v3]
In-Reply-To: <F-XDONrXV1MX5B_HbrMzn29nm9Q1-Uk_LSyJvIPOx_8=.0a0b0104-f1d4-40b7-865e-0f1d0ac3d7f9@github.com>
References: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
 <F-XDONrXV1MX5B_HbrMzn29nm9Q1-Uk_LSyJvIPOx_8=.0a0b0104-f1d4-40b7-865e-0f1d0ac3d7f9@github.com>
Message-ID: <G8XKuMbgLJjsxus3LyV7tmP1D9VNWtwbXPFrhS2v0BU=.222c26a2-6a69-43ec-97c3-b91ccfefc8fc@github.com>

On Wed, 4 Jun 2025 22:23:05 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi, I need a review of some PEM updates.  `PEMRecord.pem` is renamed to `content` to better describe that it is the base64 content and not including the header and footer. Additionally, `PEMRecord.getEncoded()` is removed and some javadoc clarifications for PEMEncoder and PEMDecoder.  Thanks.
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrong "PEM types"

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25620#pullrequestreview-2900090595

From mullan at openjdk.org  Thu Jun  5 13:06:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 13:06:54 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v3]
In-Reply-To: <TnWloajWzELKJAzASpdMn4-aSHmLwFuOp3gGFRB7snE=.7705403b-145d-4aa0-bdd8-6e230b69ecb2@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
 <TnWloajWzELKJAzASpdMn4-aSHmLwFuOp3gGFRB7snE=.7705403b-145d-4aa0-bdd8-6e230b69ecb2@github.com>
Message-ID: <EogNys19QLxTpiCyo8kZ9ektMdaaB9BTtTYQ8_LqMy0=.eac9e5ad-3d6f-43e9-83a6-3fac82cf1a7d@github.com>

On Thu, 5 Jun 2025 01:26:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enhance test to be exhaustive

I think that the JFR event should not print -1 for the key size for ML-KEM keys, and should be able to identity a key type that doesn't have a key size and emit something else. Otherwise I think the issue reported in this bug is still an issue because users won't understand what -1 means.

I actually think logging the ML-KEM variant (ex: ML-KEM-768) would be most useful. Nobody other than crypto experts are going to understand the NIST security levels, it's not much more user friendly than -1 in my opinion.

Perhaps the JSR code could see if the key implements `NamedX509Key` and then print out the `NamedParameterSpec` constant

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

PR Comment: https://git.openjdk.org/jdk/pull/25642#issuecomment-2944214724

From weijun at openjdk.org  Thu Jun  5 13:33:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 5 Jun 2025 13:33:50 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v3]
In-Reply-To: <EogNys19QLxTpiCyo8kZ9ektMdaaB9BTtTYQ8_LqMy0=.eac9e5ad-3d6f-43e9-83a6-3fac82cf1a7d@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
 <TnWloajWzELKJAzASpdMn4-aSHmLwFuOp3gGFRB7snE=.7705403b-145d-4aa0-bdd8-6e230b69ecb2@github.com>
 <EogNys19QLxTpiCyo8kZ9ektMdaaB9BTtTYQ8_LqMy0=.eac9e5ad-3d6f-43e9-83a6-3fac82cf1a7d@github.com>
Message-ID: <WHeiA94XvPpjt99_D5ITQ0M_44V-AJ8rBAjkTqHWxXY=.eaea5682-712c-40ee-8cab-eb8b3afb7027@github.com>

On Thu, 5 Jun 2025 13:04:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Perhaps the JFR event logging code could see if the key implements `NamedX509Key` and then print out the `NamedParameterSpec` constant.

Or, just use public APIs as

if (key instanceof AsymmetricKey ak
                    && ak.getParams() instanceof NamedParameterSpec nps) {
    print(nps.getName());
}

This will print out `Ed25519` and `X448` as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/25642#issuecomment-2944352378

From mullan at openjdk.org  Thu Jun  5 13:51:55 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 13:51:55 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v3]
In-Reply-To: <WHeiA94XvPpjt99_D5ITQ0M_44V-AJ8rBAjkTqHWxXY=.eaea5682-712c-40ee-8cab-eb8b3afb7027@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
 <TnWloajWzELKJAzASpdMn4-aSHmLwFuOp3gGFRB7snE=.7705403b-145d-4aa0-bdd8-6e230b69ecb2@github.com>
 <EogNys19QLxTpiCyo8kZ9ektMdaaB9BTtTYQ8_LqMy0=.eac9e5ad-3d6f-43e9-83a6-3fac82cf1a7d@github.com>
 <WHeiA94XvPpjt99_D5ITQ0M_44V-AJ8rBAjkTqHWxXY=.eaea5682-712c-40ee-8cab-eb8b3afb7027@github.com>
Message-ID: <hZ8VcJN59gxHCT8CY0BaCJv3t9Mf4087knRSYGlRpuA=.5721d840-ce1d-4105-a30c-82f0e36fa31a@github.com>

On Thu, 5 Jun 2025 13:31:19 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > Perhaps the JFR event logging code could see if the key implements `NamedX509Key` and then print out the `NamedParameterSpec` constant.
> 
> Or, just use public APIs as
> 
> ```
> if (key instanceof AsymmetricKey ak
>                     && ak.getParams() instanceof NamedParameterSpec nps) {
>     print(nps.getName());
> }
> ```
> 
> This will print out `Ed25519` and `X448` as well.

Need @coffeys to weigh in on this. My suggestion is to add that code above in `JCAUtil.tryCommitCertEvent()` so that the key type is set to, for example, "ML-KEM-768" instead of "ML-KEM". Then, I would probably change `EventHelper.logX509CertificateEvent` and when the keysize passed in is -1, instead log "N/A" or some suitable text instead of "-1".

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

PR Comment: https://git.openjdk.org/jdk/pull/25642#issuecomment-2944467452

From ascarpino at openjdk.org  Thu Jun  5 15:48:54 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 5 Jun 2025 15:48:54 GMT
Subject: RFR: 8358171: Additional code coverage for PEM API [v5]
In-Reply-To: <XZVmWtqGn8Tq3_wA_iDW4rIZqDPx1t1QlXj3Rkvsbz4=.4a1ff43a-2204-4dfd-a075-11dc53d7a0fb@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
 <XZVmWtqGn8Tq3_wA_iDW4rIZqDPx1t1QlXj3Rkvsbz4=.4a1ff43a-2204-4dfd-a075-11dc53d7a0fb@github.com>
Message-ID: <lDyXrwEvQtBr3by6tF4xQNiWr_PaTujwudd8xSCtHaI=.0ebec1cf-5877-4301-bbbf-6f54b008fedc@github.com>

On Thu, 5 Jun 2025 10:20:40 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   styling fixes

I'm fine with the change

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25588#pullrequestreview-2900862169

From mullan at openjdk.org  Thu Jun  5 17:47:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 17:47:54 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

Some initial comments.

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 264:

> 262:      * the peer (if any).
> 263:      *
> 264:      * @since 1.5

I would remove the `@since 1.5` from these methods. It isn't relevant anymore since this is an internal class and that version is no longer supported. That version info is in the `X509ExtendedKeyManager` API which is sufficient.

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 395:

> 393:                 if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 394:                     SSLLogger.fine("Ignore alias " + alias +
> 395:                             ": certificate list does not conform to " +

suggest saying "certificate chain" not "certificate list".

test/lib/jdk/test/lib/security/CertificateBuilder.java line 244:

> 242:      * @throws IOException if an encoding error occurs.
> 243:      */
> 244:     public CertificateBuilder addSubjectAltNameIPExt(List<String> IPAddresses)

variables usually start with lower case letter, so suggest `ipAddresses`

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

PR Review: https://git.openjdk.org/jdk/pull/25016#pullrequestreview-2900744862
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129536065
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129556680
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129090967

From mullan at openjdk.org  Thu Jun  5 19:34:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 19:34:53 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 1:

> 1: /*

Are these changes relevant to this issue? It doesn't use a SunX509 TrustManager AFAICT.

test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:

> 1: /*

I am trying to figure out when the algorithm constraints are enabled, why the key isn't being selected. I don't see anywhere that you are setting the algorithm constraints property.

Please add some more comments explaining how the exception case occurs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129881920
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2130018039

From weijun at openjdk.org  Thu Jun  5 20:31:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 5 Jun 2025 20:31:50 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v3]
In-Reply-To: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
Message-ID: <Ul4l91JmDGY5t8ABZryXhXv2Py3dGlTOK6NBG8jHe64=.2a5fed5c-1028-4253-8796-5b2cef542531@github.com>

> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
> 
> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - allow expanded to be null
 - merge
 - Merge
 - safer privKeyToPubKey; updated desciptions for the properties; adding braces to if blocks
 - the fix

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

Changes: https://git.openjdk.org/jdk/pull/24969/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=02
  Stats: 2490 lines in 23 files changed: 1785 ins; 537 del; 168 mod
  Patch: https://git.openjdk.org/jdk/pull/24969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24969/head:pull/24969

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

From valeriep at openjdk.org  Thu Jun  5 21:25:55 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 5 Jun 2025 21:25:55 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v4]
In-Reply-To: <OHyCsw9CoSKiMJxzJFQ4-leA3b0C9D0F-pXjUJ57mI4=.943e7c01-2cd5-41e5-a410-5b4cab63fd3b@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <OHyCsw9CoSKiMJxzJFQ4-leA3b0C9D0F-pXjUJ57mI4=.943e7c01-2cd5-41e5-a410-5b4cab63fd3b@github.com>
Message-ID: <BT0kkq-dxfcJ3HRGVLjAoX7wvQyL1VPhgMBIViSuC98=.473c4851-f9e3-4988-a30b-d92cb1d68724@github.com>

On Thu, 5 Jun 2025 11:30:42 GMT, Varada M <varadam at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8358159: Empty mode/padding in cipher transformations

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

> 458:         String pad = (parts[2].length() == 0 ? null : parts[2]);
> 459: 
> 460:         if ((mode == null || mode.isEmpty()) && (pad == null || pad.isEmpty())) {

The `mode.isEmpty()` and `pad.isEmpty()` should always be `false` since line 457 and 458 already converted empty String to `null`, right? Looks redundant to me and can be removed.

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

> 469:             }
> 470:             list.add(new Transform(alg, "/" + mode, null, pad));
> 471:             list.add(new Transform(alg, "//" + pad, mode, null));

For these two lines, also do similar check as line 467? E.g. check mode to be non-null for line 470 and check pad to be non-null for line 471.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2130435820
PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2130442953

From ascarpino at openjdk.org  Thu Jun  5 22:16:06 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 5 Jun 2025 22:16:06 GMT
Subject: Integrated: 8358099: PEM spec updates
In-Reply-To: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
References: <l8_M3MyJdo24vVTOt7Uz5HUiPBwVS-IkISD2DcelBzs=.c236f9c3-92aa-45a8-bbba-0b04fbfd5213@github.com>
Message-ID: <brtE8ukb_C-UV6dLLYd9IfBA5zRtdJl7_x-6yFB-pCs=.b0afcff7-2d21-4ca8-8daf-2630a5049b17@github.com>

On Tue, 3 Jun 2025 16:09:32 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi, I need a review of some PEM updates.  `PEMRecord.pem` is renamed to `content` to better describe that it is the base64 content and not including the header and footer. Additionally, `PEMRecord.getEncoded()` is removed and some javadoc clarifications for PEMEncoder and PEMDecoder.  Thanks.

This pull request has now been integrated.

Changeset: 78158f30
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78158f30aee51e14ab203b0127aeb883c010319c
Stats:     68 lines in 6 files changed: 1 ins; 20 del; 47 mod

8358099: PEM spec updates

Reviewed-by: mullan

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

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

From fguallini at openjdk.org  Fri Jun  6 09:55:57 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Fri, 6 Jun 2025 09:55:57 GMT
Subject: Integrated: 8358171: Additional code coverage for PEM API
In-Reply-To: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
References: <mMnOwFFevZ0yZ338a-kxhulARm56q80HR16Q5sifhH0=.e442f541-d989-41ce-9728-9ee473b664a3@github.com>
Message-ID: <7jplPhBtLEvV-NB5uCOTvND5rITahLSUl06WjzY0DIA=.12e89dc7-7058-419f-9504-1904801d580c@github.com>

On Mon, 2 Jun 2025 12:14:13 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> The tests included in this PR add code coverage mainly to the following classes introduced/updated by JEP 470 (PEM): PEMDecoder, PEMEncoder, Pem, EncryptedPrivateKeyInfo and the Key factories. In addition, more tests are included for RSAPSS, multithreading, _jdk.epkcs8.defaultAlgorithm_ property and some negative testing

This pull request has now been integrated.

Changeset: b2e7cda6
Author:    Fernando Guallini <fguallini at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2e7cda6a0bd21fa3c4ffe2a67da4953f1ca3f1f
Stats:     535 lines in 10 files changed: 492 ins; 2 del; 41 mod

8358171: Additional code coverage for PEM API

Reviewed-by: ascarpino

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

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

From dfuchs at openjdk.org  Fri Jun  6 12:00:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 12:00:37 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:

 - merge latest changes from master branch
 - http3: improve H3ConnectionPoolTest.java
 - Fix snippet
 - Improve key destruction
 - merge latest changes from master branch
 - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
 - http3: refactor HTTP/3 connection pool management in a separate class
 - Ignore DestroyFailedExceptions
 - Remove outdated TODO
 - Remove outdated TODO
 - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=06
  Stats: 103750 lines in 473 files changed: 100888 ins; 1345 del; 1517 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From sean.mullan at oracle.com  Fri Jun  6 12:26:01 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 6 Jun 2025 08:26:01 -0400
Subject: New Security Group Member: Martin Balao
Message-ID: <df181dc1-b8f8-47aa-bd9a-ab9b6c623b9e@oracle.com>

I hereby nominate Martin Balao to Membership in the Security Group.

Martin joined the Red Hat Java Platform team in 2017 as its security 
expert, leading all Red Hat work related to OpenJDK security. He has 
been an active contributor to OpenJDK security library development work 
and is the co-author and owner of Draft JEP 8325511 (Security Providers 
Filter) [1]. Martin has contributed many security library related 
changes to the JDK over the past 8 years.

Votes are due by 13:00 UTC Friday 20th June 2025.

Only current Members of the Security Group [2] are eligible to vote on 
this nomination.  Votes must be cast in the open by replying to this 
mailing list.

For Lazy Consensus voting instructions, see [3].

Sean Mullan

[1] https://openjdk.org/jeps/8325511
[2] https://openjdk.org/census#security
[3] https://openjdk.org/groups/#member-vote

From sean.mullan at oracle.com  Fri Jun  6 12:29:14 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 6 Jun 2025 08:29:14 -0400
Subject: CFV: New Security Group Member: Martin Balao
Message-ID: <9e63aaa0-650b-430e-939b-d400bafb6c2a@oracle.com>

(correcting subject title)

I hereby nominate Martin Balao to Membership in the Security Group.

Martin joined the Red Hat Java Platform team in 2017 as its security 
expert, leading all Red Hat work related to OpenJDK security. He has 
been an active contributor to OpenJDK security library development work 
and is the co-author and owner of Draft JEP 8325511 (Security Providers 
Filter) [1]. Martin has contributed many security library related 
changes to the JDK over the past 8 years.

Votes are due by 13:00 UTC Friday 20th June 2025.

Only current Members of the Security Group [2] are eligible to vote on 
this nomination.  Votes must be cast in the open by replying to this 
mailing list.

For Lazy Consensus voting instructions, see [3].

Sean Mullan

[1] https://openjdk.org/jeps/8325511
[2] https://openjdk.org/census#security
[3] https://openjdk.org/groups/#member-vote

From sean.mullan at oracle.com  Fri Jun  6 12:29:39 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 6 Jun 2025 08:29:39 -0400
Subject: CFV: New Security Group Member: Martin Balao
In-Reply-To: <9e63aaa0-650b-430e-939b-d400bafb6c2a@oracle.com>
References: <9e63aaa0-650b-430e-939b-d400bafb6c2a@oracle.com>
Message-ID: <00d7f75f-95ad-4cfc-a61b-f4e6026be4f4@oracle.com>

Vote: yes

--Sean

On 6/6/25 8:29 AM, Sean Mullan wrote:
> (correcting subject title)
> 
> I hereby nominate Martin Balao to Membership in the Security Group.
> 
> Martin joined the Red Hat Java Platform team in 2017 as its security 
> expert, leading all Red Hat work related to OpenJDK security. He has 
> been an active contributor to OpenJDK security library development work 
> and is the co-author and owner of Draft JEP 8325511 (Security Providers 
> Filter) [1]. Martin has contributed many security library related 
> changes to the JDK over the past 8 years.
> 
> Votes are due by 13:00 UTC Friday 20th June 2025.
> 
> Only current Members of the Security Group [2] are eligible to vote on 
> this nomination.? Votes must be cast in the open by replying to this 
> mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Sean Mullan
> 
> [1] https://openjdk.org/jeps/8325511
> [2] https://openjdk.org/census#security
> [3] https://openjdk.org/groups/#member-vote


From weijun.wang at oracle.com  Fri Jun  6 12:55:19 2025
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Fri, 6 Jun 2025 12:55:19 +0000
Subject: CFV: New Security Group Member: Martin Balao
In-Reply-To: <9e63aaa0-650b-430e-939b-d400bafb6c2a@oracle.com>
References: <9e63aaa0-650b-430e-939b-d400bafb6c2a@oracle.com>
Message-ID: <C1719951-5B52-4691-AD0C-95913CD802E3@oracle.com>

Vote: yes

--Weijun

> On Jun 6, 2025, at 08:29, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> (correcting subject title)
> 
> I hereby nominate Martin Balao to Membership in the Security Group.
> 
> Martin joined the Red Hat Java Platform team in 2017 as its security expert, leading all Red Hat work related to OpenJDK security. He has been an active contributor to OpenJDK security library development work and is the co-author and owner of Draft JEP 8325511 (Security Providers Filter) [1]. Martin has contributed many security library related changes to the JDK over the past 8 years.
> 
> Votes are due by 13:00 UTC Friday 20th June 2025.
> 
> Only current Members of the Security Group [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Sean Mullan
> 
> [1] https://openjdk.org/jeps/8325511
> [2] https://openjdk.org/census#security
> [3] https://openjdk.org/groups/#member-vote


From mullan at openjdk.org  Fri Jun  6 15:24:04 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 6 Jun 2025 15:24:04 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 401:

> 399:                 continue;
> 400:             }
> 401: 

I think we should also call `CertType.check` here, like in `X509KeyManagerImpl`. Since this change is now only selecting certificates with algorithms that are not disabled, I think it also makes sense to select certificates that have the proper extensions, etc and will not cause subsequent certificate chain validation failures.

This means we would have to change the name of the property so that it isn't only about disabling constraints checking. Perhaps: `jdk.tls.keymanager.disableCertSelectionChecking`.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerConstraints.java line 170:

> 168:     }
> 169: 
> 170:     protected boolean isConstraintsDisabled() {

Make this private? Not sure why it would need to be overridden.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132394682
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132187663

From abarashev at openjdk.org  Fri Jun  6 16:21:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 16:21:59 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
Message-ID: <r4AMd_4-pjf_PHIYI36I3WHc6FvcI2-bSGldzvhkGFg=.ed24ea21-3860-4d2d-81ea-16c00ced5959@github.com>

On Thu, 5 Jun 2025 19:31:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:
> 
>> 1: /*
> 
> I am trying to figure out when the algorithm constraints are enabled, why the key isn't being selected. I don't see anywhere that you are setting the algorithm constraints property.
> 
> Please add some more comments explaining how the exception case occurs.

Hi @seanjmullan! This PR fixes both JDK-8353113 and JDK-8170706. So we have 2 new unit tests for each:

1. `AlgorithmConstraintsCheck`: tests JDK-8170706. BTW, I'm going to update the `@bug` tag in this test to `8170706`
2. `PeerConstraintsCheck`: tests JDK-8353113. No need to set any algorithm constraints because we test against the peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions. I'll add a comment to this test with the explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132486696

From abarashev at openjdk.org  Fri Jun  6 16:53:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 16:53:51 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
Message-ID: <Dr8nXtVReKyM-yLEjr8LBerGUo-GjP_HhhmqTujd3S8=.44c27f3a-63ac-4b07-9e76-7c23b61c3d49@github.com>

On Fri, 6 Jun 2025 13:20:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerConstraints.java line 170:
> 
>> 168:     }
>> 169: 
>> 170:     protected boolean isConstraintsDisabled() {
> 
> Make this private? Not sure why it would need to be overridden.

If we have a consensus on keeping `jdk.tls.keymanager.disableConstraintsChecking` toggle as is, then I'm going to remove this method and do this check directly in the constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132534993

From anthony.scarpino at oracle.com  Fri Jun  6 18:26:05 2025
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 6 Jun 2025 11:26:05 -0700
Subject: CFV: New Security Group Member: Martin Balao
In-Reply-To: <9e63aaa0-650b-430e-939b-d400bafb6c2a@oracle.com>
References: <9e63aaa0-650b-430e-939b-d400bafb6c2a@oracle.com>
Message-ID: <e2928f65-3755-4096-a4b4-3c9633b172d9@oracle.com>

Vote: yes

Tony

On 6/6/25 5:29 AM, Sean Mullan wrote:
> (correcting subject title)
> 
> I hereby nominate Martin Balao to Membership in the Security Group.
> 
> Martin joined the Red Hat Java Platform team in 2017 as its security expert, 
> leading all Red Hat work related to OpenJDK security. He has been an active 
> contributor to OpenJDK security library development work and is the co-author 
> and owner of Draft JEP 8325511 (Security Providers Filter) [1]. Martin has 
> contributed many security library related changes to the JDK over the past 8 
> years.
> 
> Votes are due by 13:00 UTC Friday 20th June 2025.
> 
> Only current Members of the Security Group [2] are eligible to vote on this 
> nomination.? Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Sean Mullan
> 
> [1] https://openjdk.org/jeps/8325511
> [2] https://openjdk.org/census#security
> [3] https://openjdk.org/groups/#member-vote


From prr at openjdk.org  Fri Jun  6 18:41:38 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 6 Jun 2025 18:41:38 GMT
Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
Message-ID: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>

The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
removed use of AppContext from java/util/logging/LogManager.java.
That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.

There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.

Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

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

Commit messages:
 - 8358731

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

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

From prr at openjdk.org  Fri Jun  6 18:41:38 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 6 Jun 2025 18:41:38 GMT
Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
In-Reply-To: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
References: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
Message-ID: <cL7qvjaj0zGitG3Q0-HaVVz15pPzW_COHxNX1iL3JHs=.5cb2672c-b57a-45ad-848a-4a69df509995@github.com>

On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.
> 
> There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.
> 
> Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

@dfuch please review this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25677#issuecomment-2950146654

From rhalade at openjdk.org  Fri Jun  6 18:49:30 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 6 Jun 2025 18:49:30 GMT
Subject: [jdk25] RFR: 8345414: Google CAInterop test failures
Message-ID: <xZA46HakuTHn-d2c3Idgl_0dFMz_rKpIDPhy-BzgZ7Q=.765261df-4e2e-47d0-8ca2-bc7bc1a0a6c4@github.com>

This fix was missed in JDK 25 as it was integrated to JDK 24+b28.

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

Commit messages:
 - Backport 8e9ba788ae04a9a617a393709bf2c51a0c157206

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

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

From rhalade at openjdk.org  Fri Jun  6 18:53:27 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 6 Jun 2025 18:53:27 GMT
Subject: RFR: 8345414: Google CAInterop test failures
Message-ID: <gaL8RBBCd2nYnB2EmAeEnyW6txGp7lUoq3t1kCDkZ98=.ffc9bb62-df8c-4619-a6f0-671445c904f7@github.com>

This fix was missed in JDK 25 as it was integrated to JDK 24+b28. After JDK 25 fork, this fix is also needed in JDK 26.

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

Commit messages:
 - Backport 8e9ba788ae04a9a617a393709bf2c51a0c157206

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

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

From duke at openjdk.org  Fri Jun  6 19:57:11 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Fri, 6 Jun 2025 19:57:11 GMT
Subject: RFR: 8349946: Cipher javadoc could describe AEAD reuse better
Message-ID: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>

The class documentation in javax.crypto.Cipher could better describe AEAD and reuse. The current class description example is outdated as GCM encryption does not allow resets. The doc should state that reset() may not be possible with some algorithms or providers and that an InvalidAlgorithmParameterException is thrown

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

Commit messages:
 - 8349946:Cipher javadoc could describe AEAD reuse better
 - 8349946:Cipher javadoc could describe AEAD reuse better
 - 8349946:Cipher javadoc could describe AEAD reuse better
 - 8349946:Cipher javadoc could describe AEAD reuse better
 - 8349946:Cipher javadoc could describe AEAD reuse better
 - 8349946: Initial draft changes for cipher java doc updates
 - 8349946:Cipher javadoc could describe AEAD reuse better
 - 8349946:Cipher javadoc could describe AEAD reuse better

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

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

From ascarpino at openjdk.org  Fri Jun  6 19:57:12 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 6 Jun 2025 19:57:12 GMT
Subject: RFR: 8349946: Cipher javadoc could describe AEAD reuse better
In-Reply-To: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
References: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
Message-ID: <ykaO9t2NWOPufWMjvYmrmnlDrJ6MogHliwuerNCWzRs=.83bae4d5-a926-4762-ab82-6bda0a8e516b@github.com>

On Thu, 22 May 2025 19:30:44 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The class documentation in javax.crypto.Cipher could better describe AEAD and reuse. The current class description example is outdated as GCM encryption does not allow resets. The doc should state that reset() may not be possible with some algorithms or providers and that an InvalidAlgorithmParameterException is thrown

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

> 109:  * the {@code update} and {@code doFinal} methods).
> 110:  * <p>
> 111:  * When {@code doFinal} completes the operation, the {@code Cipher} object will attempt

Please change to "{@code doFinal} methods complete"

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

> 115:  * forgery attacks due to Key and IV uniqueness requirements.
> 116:  * An {@link IllegalStateException} will be thrown when calling {@code update}
> 117:  * or {@code doFinal} when a reset did not occur.

Please change to "or {@code doFinal} methods when"

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

> 117:  * or {@code doFinal} when a reset did not occur.
> 118:  *
> 119:  * <p><b>Important:</b> Reusing the same IV (nonce) with the same key in AEAD modes like GCM is a serious security risk.

I would remove this, only because it's a broad statement about algorithm security that may not be proper for the javadoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2132766944
PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2132769581
PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2132785620

From hchao at openjdk.org  Fri Jun  6 20:03:57 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 6 Jun 2025 20:03:57 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
 <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>
 <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>
Message-ID: <6zkY8S4cVr4HOiWkQlXuh3Vu0QXWzyB-buNY2_Wvpl0=.81e0a04e-a82f-4e46-82c1-88cb40d9603e@github.com>

On Thu, 15 May 2025 19:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).
> > 
> > 
> > @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it to be disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this.
> > @seanjmullan What do you think?
> 
> Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced.

I'd agree. As I mentioned in my earlier comment, if the new system property ends up toggling behavior in both `SunX509KeyManager` and `X509KeyManagerImpl`, we could run into an unintended side effect. While we're adding compliant algorithm constraints checking to `SunX509KeyManager`, turning on the property to disable it for compatibility reasons would also disable the already-existing checking in `X509KeyManagerImpl`. The applications already relying on the stricter checks in `X509KeyManagerImpl` might lose that enforcement unintentionally.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2950663297

From abarashev at openjdk.org  Fri Jun  6 21:13:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 21:13:51 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
Message-ID: <dUqp1eE1r7WCnvTsiskeeBEuRUO2MU8LgAHbZR53KQg=.779bbb42-784a-4f62-a29e-577fe40fb31b@github.com>

On Fri, 6 Jun 2025 15:20: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:
>> 
>>   Make the test run on TLSv1.3
>
> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 401:
> 
>> 399:                 continue;
>> 400:             }
>> 401: 
> 
> I think we should also call `CertType.check` here, like in `X509KeyManagerImpl`. Since this change is now only selecting certificates with algorithms that are not disabled, I think it also makes sense to select certificates that have the proper extensions, etc and will not cause subsequent certificate chain validation failures.
> 
> This means we would have to change the name of the property so that it isn't only about disabling constraints checking. Perhaps: `jdk.tls.keymanager.disableCertSelectionChecking`.

Yes, makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132913338

From abarashev at openjdk.org  Fri Jun  6 21:21:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 21:21:52 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
Message-ID: <EW0TYxe6HMEHe7iAFt3W70PGrm3ZpCy6cZhzWe1GR2Q=.00e86f02-0bd4-46dc-97b1-7f5c8b3173a9@github.com>

On Thu, 5 Jun 2025 17:40:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 264:
> 
>> 262:      * the peer (if any).
>> 263:      *
>> 264:      * @since 1.5
> 
> I would remove the `@since 1.5` from these methods. It isn't relevant anymore since this is an internal class and that version is no longer supported. That version info is in the `X509ExtendedKeyManager` API which is sufficient.

Done.

> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 395:
> 
>> 393:                 if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>> 394:                     SSLLogger.fine("Ignore alias " + alias +
>> 395:                             ": certificate list does not conform to " +
> 
> suggest saying "certificate chain" not "certificate list".

Done. Also changing the same message in `X509KeyManagerImpl`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132920769
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132919667

From weijun at openjdk.org  Fri Jun  6 21:27:50 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 6 Jun 2025 21:27:50 GMT
Subject: [jdk25] RFR: 8345414: Google CAInterop test failures
In-Reply-To: <xZA46HakuTHn-d2c3Idgl_0dFMz_rKpIDPhy-BzgZ7Q=.765261df-4e2e-47d0-8ca2-bc7bc1a0a6c4@github.com>
References: <xZA46HakuTHn-d2c3Idgl_0dFMz_rKpIDPhy-BzgZ7Q=.765261df-4e2e-47d0-8ca2-bc7bc1a0a6c4@github.com>
Message-ID: <YGL2Ki1Ieeq_aij_F62M6KB-Oa5AHkW_RPFnk7ZbkbE=.82cf7457-603e-4b1f-b8f2-f5a51767d7b4@github.com>

On Fri, 6 Jun 2025 18:43:55 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix was missed in JDK 25 as it was integrated to JDK 24+b28.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25678#pullrequestreview-2906176558

From weijun at openjdk.org  Fri Jun  6 21:27:57 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 6 Jun 2025 21:27:57 GMT
Subject: RFR: 8345414: Google CAInterop test failures
In-Reply-To: <gaL8RBBCd2nYnB2EmAeEnyW6txGp7lUoq3t1kCDkZ98=.ffc9bb62-df8c-4619-a6f0-671445c904f7@github.com>
References: <gaL8RBBCd2nYnB2EmAeEnyW6txGp7lUoq3t1kCDkZ98=.ffc9bb62-df8c-4619-a6f0-671445c904f7@github.com>
Message-ID: <mD5MWp31_4dk2CSBfiKjvzLudDAx4fptlEONyn--xDw=.265f37d6-a84b-4269-b867-c1435390a3dd@github.com>

On Fri, 6 Jun 2025 18:48:16 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix was missed in JDK 25 as it was integrated to JDK 24+b28. After JDK 25 fork, this fix is also needed in JDK 26.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25679#pullrequestreview-2906176967

From dfuchs at openjdk.org  Fri Jun  6 21:28:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 21:28:49 GMT
Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
In-Reply-To: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
References: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
Message-ID: <GmfnwkItU5m1dwNNCnnNnOhExO36SJM9QNTTpoy8-xc=.f5699710-8786-44c4-a04e-9200c79fc921@github.com>

On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.
> 
> There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.
> 
> Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25677#pullrequestreview-2906178505

From valeriep at openjdk.org  Fri Jun  6 21:28:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 6 Jun 2025 21:28:52 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called
In-Reply-To: <SbxuNsmyP7PkGCMSPq6myUIIRRiv9dhsp8cULVD6dAo=.cb9967e5-047a-48a2-afc6-4e1cb4aa7e6d@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
 <SbxuNsmyP7PkGCMSPq6myUIIRRiv9dhsp8cULVD6dAo=.cb9967e5-047a-48a2-afc6-4e1cb4aa7e6d@github.com>
Message-ID: <lbP3k3GS_BZeOZeKxFhfsGTtxUyt88R94gaWASAOLzI=.761d70c8-c3ec-413d-a098-b51655e30d4c@github.com>

On Wed, 4 Jun 2025 15:11:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 
>> 
>> 1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed
>> 2. serialization of such destroyed `PBEKey` object will lead to exception. 
>>  
>> Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc.
>
> src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 1:
> 
>> 1: /*
> 
> Shall we also throw ISE when `getFormat` and `getAlgorithm` are called? Calling these methods after the key is destroyed looks suspicious and may reveal a coding error.

Well, I see that throw `IllegalStateException` for almost all methods seems to be the style for the `Destroyable` impl classes under the `javax.security.auth.kerberos` package. But I am not sure if this would be too "noisy" for Key objects. At a minimum, we should throw `IllegalStateException` for method which trying to use the sensitive info which has been cleared out. However, if we throw `IllegalStateException` for all methods such as `getAlgorithm()`, then it may lead to even more `IllegalStateException` being thrown unexpectedly and may make troubleshooting harder.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2132926205

From rhalade at openjdk.org  Fri Jun  6 21:33:53 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 6 Jun 2025 21:33:53 GMT
Subject: [jdk25] Integrated: 8345414: Google CAInterop test failures
In-Reply-To: <xZA46HakuTHn-d2c3Idgl_0dFMz_rKpIDPhy-BzgZ7Q=.765261df-4e2e-47d0-8ca2-bc7bc1a0a6c4@github.com>
References: <xZA46HakuTHn-d2c3Idgl_0dFMz_rKpIDPhy-BzgZ7Q=.765261df-4e2e-47d0-8ca2-bc7bc1a0a6c4@github.com>
Message-ID: <HabaeFbvHJbl2cannBt_hSZTXLar9iJWjlAMXAiW60M=.3fed1ad6-a695-4347-9d09-3418fb10f4f2@github.com>

On Fri, 6 Jun 2025 18:43:55 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix was missed in JDK 25 as it was integrated to JDK 24+b28.

This pull request has now been integrated.

Changeset: 80e066e7
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80e066e733099c5eb08a0524d77aa7a692e8a93d
Stats:     10 lines in 1 file changed: 0 ins; 0 del; 10 mod

8345414: Google CAInterop test failures

Reviewed-by: weijun
Backport-of: 8e9ba788ae04a9a617a393709bf2c51a0c157206

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

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

From rhalade at openjdk.org  Fri Jun  6 21:37:58 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Fri, 6 Jun 2025 21:37:58 GMT
Subject: Integrated: 8345414: Google CAInterop test failures
In-Reply-To: <gaL8RBBCd2nYnB2EmAeEnyW6txGp7lUoq3t1kCDkZ98=.ffc9bb62-df8c-4619-a6f0-671445c904f7@github.com>
References: <gaL8RBBCd2nYnB2EmAeEnyW6txGp7lUoq3t1kCDkZ98=.ffc9bb62-df8c-4619-a6f0-671445c904f7@github.com>
Message-ID: <FJBBzzwasE2hdDVa30fNkPy_XxHxPrEOBXByWoPsNIA=.23d916ff-8e6c-4142-bad9-6ed567467a5f@github.com>

On Fri, 6 Jun 2025 18:48:16 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This fix was missed in JDK 25 as it was integrated to JDK 24+b28. After JDK 25 fork, this fix is also needed in JDK 26.

This pull request has now been integrated.

Changeset: d7352559
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7352559195b9e052c3eb24d773c0d6c10dc23ad
Stats:     10 lines in 1 file changed: 0 ins; 0 del; 10 mod

8345414: Google CAInterop test failures

Reviewed-by: weijun
Backport-of: 8e9ba788ae04a9a617a393709bf2c51a0c157206

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

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

From valeriep at openjdk.org  Fri Jun  6 21:38:49 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 6 Jun 2025 21:38:49 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called
In-Reply-To: <OLoWC8G0mCZjRexhtTvVulZt_UYhxrN-cwCR6C2vbyU=.1d2060cb-b539-4185-96fc-4b55c0cd0f5e@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
 <OLoWC8G0mCZjRexhtTvVulZt_UYhxrN-cwCR6C2vbyU=.1d2060cb-b539-4185-96fc-4b55c0cd0f5e@github.com>
Message-ID: <93z474u2QLsNV-KVBLeJIUTYpfShck67iw0wlr6RXm4=.ea5430e4-c1a5-4858-a49b-76c2911c67fc@github.com>

On Wed, 4 Jun 2025 15:15:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 
>> 
>> 1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed
>> 2. serialization of such destroyed `PBEKey` object will lead to exception. 
>>  
>> Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc.
>
> src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 82:
> 
>> 80:     }
>> 81: 
>> 82:     public byte[] getEncoded() {
> 
> I understand this is not a public API class so there is no need to provide `@throws` in the spec. But, on the other hand, do we need to provide one in its super class `java.security.key`? I have no opinion.

Well, I am not sure. `java.securityKey` is the super interface for all keys, including private, public, and secret keys. The Exception is due to implementing the `javax.security.auth.Destroyable` interface, so the `@throws` spec should goes to the class which implements both `Destroyable` and `Key` interfaces. `PBEKey` is not a public API class, so perhaps we can documenting this in the `SunJCE` provider section as this is implementation-specific?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2132935613

From abarashev at openjdk.org  Fri Jun  6 23:22:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 23:22:52 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
Message-ID: <gcFQMFOoDfItWveSNHHS_NcV5dqK4EdvUh556otCgsQ=.ab3ae941-5a95-43fb-a541-a7e280cd6346@github.com>

On Thu, 5 Jun 2025 15:10:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> test/lib/jdk/test/lib/security/CertificateBuilder.java line 244:
> 
>> 242:      * @throws IOException if an encoding error occurs.
>> 243:      */
>> 244:     public CertificateBuilder addSubjectAltNameIPExt(List<String> IPAddresses)
> 
> variables usually start with lower case letter, so suggest `ipAddresses`

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2133067693

From abarashev at openjdk.org  Fri Jun  6 23:34:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 23:34:52 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
Message-ID: <3EASChBurpIG_iq35iGkr7MYrc79c0jl_RNb7sbqYkk=.65d9df1a-9e96-4e8e-a409-c9f9d7eef597@github.com>

On Thu, 5 Jun 2025 19:00:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 1:
> 
>> 1: /*
> 
> Are these changes relevant to this issue? It doesn't use a SunX509 TrustManager AFAICT.

You mean `SunX509` KeyManager? All these existing tests I'm modifying in this PR are using it together with the certificates signed with `MD5withRSA` algorithm. That's why they fail when we add algorithm constraints to SunX509KeyManagerImpl - MD5 is not allowed in TLSv1.3.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2133073579

From duke at openjdk.org  Sat Jun  7 05:28:00 2025
From: duke at openjdk.org (Sebastian Stenzel)
Date: Sat, 7 Jun 2025 05:28:00 GMT
Subject: RFR: 8349946: Cipher javadoc could describe AEAD reuse better
In-Reply-To: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
References: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
Message-ID: <TrwHU140bc4tTBDcocdzdr7MjewYsBBSUxC0-Yw9Ykk=.aa1e59da-d232-423a-b079-489a1c4ae8c5@github.com>

On Thu, 22 May 2025 19:30:44 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The class documentation in javax.crypto.Cipher could better describe AEAD and reuse. The current class description example is outdated as GCM encryption does not allow resets. The doc should state that reset() may not be possible with some algorithms or providers and that an InvalidAlgorithmParameterException is thrown

Changes requested by overheadhunter at github.com (no known OpenJDK username).

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

> 115:  * forgery attacks due to Key and IV uniqueness requirements.
> 116:  * An {@link IllegalStateException} will be thrown when calling {@code update}
> 117:  * or {@code doFinal} methods when a reset did not occur.

It might be helpful to describe what to do instead:

When reset is not possible, you don't need to dispose the cipher object. Instead you can call init again with a different key/nonce.

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

PR Review: https://git.openjdk.org/jdk/pull/25399#pullrequestreview-2906814350
PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2133386033

From serb at openjdk.org  Sat Jun  7 12:52:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 7 Jun 2025 12:52:51 GMT
Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
In-Reply-To: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
References: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
Message-ID: <ltbzzzMlyFCZnSbqfGDL0IOGfNIfcJY3oM9OiUyiWGY=.a2140d15-07f6-415d-8a4c-49f3398c5503@github.com>

On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.
> 
> There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.
> 
> Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25677#pullrequestreview-2907352143

From varadam at openjdk.org  Sat Jun  7 20:07:45 2025
From: varadam at openjdk.org (Varada M)
Date: Sat, 7 Jun 2025 20:07:45 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v5]
In-Reply-To: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
Message-ID: <pvhSQjYfzdrNGfwj_4zOfPQIpMwmHpPmtZIFm_551Sc=.8eada92c-87b0-49e4-a011-4a42afce1fe3@github.com>

> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
> 
> Testing done for : tier1 - fastdebug level (AIX)
> 
> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  8358159: Empty mode/padding in cipher transformations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25547/files
  - new: https://git.openjdk.org/jdk/pull/25547/files/4bc7e62d..413dea01

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

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

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

From varadam at openjdk.org  Sat Jun  7 20:09:57 2025
From: varadam at openjdk.org (Varada M)
Date: Sat, 7 Jun 2025 20:09:57 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v4]
In-Reply-To: <BT0kkq-dxfcJ3HRGVLjAoX7wvQyL1VPhgMBIViSuC98=.473c4851-f9e3-4988-a30b-d92cb1d68724@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <OHyCsw9CoSKiMJxzJFQ4-leA3b0C9D0F-pXjUJ57mI4=.943e7c01-2cd5-41e5-a410-5b4cab63fd3b@github.com>
 <BT0kkq-dxfcJ3HRGVLjAoX7wvQyL1VPhgMBIViSuC98=.473c4851-f9e3-4988-a30b-d92cb1d68724@github.com>
Message-ID: <OQdR_QSdi9bmFR8XXamVbbtiCnqi3MEph-xSXozcGOQ=.03154d22-5e08-4c31-9dec-e7fea19b4699@github.com>

On Thu, 5 Jun 2025 21:20:58 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8358159: Empty mode/padding in cipher transformations
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 460:
> 
>> 458:         String pad = (parts[2].length() == 0 ? null : parts[2]);
>> 459: 
>> 460:         if ((mode == null || mode.isEmpty()) && (pad == null || pad.isEmpty())) {
> 
> The `mode.isEmpty()` and `pad.isEmpty()` should always be `false` since line 457 and 458 already converted empty String to `null`, right? Looks redundant to me and can be removed.

You are right. I have updated accordingly. Thanks for pointing it out!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25547#discussion_r2134116721

From sebastian.stenzel at gmail.com  Sat Jun  7 20:14:03 2025
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Sat, 7 Jun 2025 22:14:03 +0200
Subject: X-Wing KEM
In-Reply-To: <2B84AC72-3A5E-4E81-92DF-5BF19A1100DC@oracle.com>
References: <D4720121-83F6-483B-AD84-7A137AB65D46@gmail.com>
 <EBA594D5-865A-4348-A3C6-FD976DAF7787@oracle.com>
 <73235A95-D1EF-4BAA-8F1F-E90355DEFC37@gmail.com>
 <2B84AC72-3A5E-4E81-92DF-5BF19A1100DC@oracle.com>
Message-ID: <13D07A70-0AEE-49EC-8809-EBCE08CCE339@gmail.com>

Hi Weijun,

I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:

The (current) X-Wing spec wants this PKCS#8 encoding: [1]

However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2]

Note the difference here:
* https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f
* https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo

I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this?

Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don?t seem to be complete yet.

Best regards,
Sebastian

[0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing
[1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D
[2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81

> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> 
> 
>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>> 
>> Hi Weijun,
>> 
>> waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet?
> 
> Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK.
> 
>> 
>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
>> 
>> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.
> 
> I see.
> 
>> 
>> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]
> 
> Nice to know. Sorry I didn't noticed that earlier.
> 
> Thanks,
> Weijun
> 
>> 
>> Thank you,
>> Sebastian
>> 
>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
>> 
>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Hi Sebastian.
>>> 
>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>>> 
>>>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>>> 
>>> Thanks for your continued interest on enhancing OpenJDK.
>>> 
>>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first. 
>>> 
>>>> 
>>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>>> 
>>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>>> 
>>>> 
>>>> Alternatively, can we make the two mentioned APIs public?
>>> 
>>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>>> 
>>> [1] https://openjdk.org/guide/
>>> 
>>> Thanks,
>>> Weijun
>>> 
>>>> 
>>>> Cheers!
>>>> Sebastian
>>>> 
>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250607/9fb8acf3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4407 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250607/9fb8acf3/smime-0001.p7s>

From kevin.driver at oracle.com  Mon Jun  9 15:55:54 2025
From: kevin.driver at oracle.com (Kevin Driver)
Date: Mon, 9 Jun 2025 15:55:54 +0000
Subject: CFV: New Security Group Member: Martin Balao
In-Reply-To: <9e63aaa0-650b-430e-939b-d400bafb6c2a@oracle.com>
References: <9e63aaa0-650b-430e-939b-d400bafb6c2a@oracle.com>
Message-ID: <DEE9D9D3-72FF-4A30-B773-EE04FE69F640@oracle.com>

Vote: yes

[image001.png]
Kevin Driver
Java Security Libraries

On Jun 6, 2025, at 7:29?AM, Sean Mullan <sean.mullan at oracle.com> wrote:

(correcting subject title)

I hereby nominate Martin Balao to Membership in the Security Group.

Martin joined the Red Hat Java Platform team in 2017 as its security expert, leading all Red Hat work related to OpenJDK security. He has been an active contributor to OpenJDK security library development work and is the co-author and owner of Draft JEP 8325511 (Security Providers Filter) [1]. Martin has contributed many security library related changes to the JDK over the past 8 years.

Votes are due by 13:00 UTC Friday 20th June 2025.

Only current Members of the Security Group [2] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

Sean Mullan

[1] https://openjdk.org/jeps/8325511
[2] https://openjdk.org/census#security
[3] https://openjdk.org/groups/#member-vote

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250609/380b97ba/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6346 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250609/380b97ba/image001.png>

From prr at openjdk.org  Mon Jun  9 16:04:00 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Jun 2025 16:04:00 GMT
Subject: Integrated: 8358731: Remove jdk.internal.access.JavaAWTAccess.java
In-Reply-To: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
References: <F5ZbNK0tPZUrpDjZi3az1EpFUf4oyZ3tMxnvrkuky98=.32d02a32-49eb-47b9-b487-ffd9ac184735@github.com>
Message-ID: <MWLlvat_GaMGyCxofHjNm79qkTL08IUcVP8LCWlbIC4=.6f2ff711-2e92-4102-b229-56b9fe7b481a@github.com>

On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed.
> 
> There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted.
> 
> Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass.

This pull request has now been integrated.

Changeset: eb8ee8bd
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb8ee8bdc7c170910abc9aa18de1e22677160358
Stats:     1110 lines in 6 files changed: 0 ins; 1110 del; 0 mod

8358731: Remove jdk.internal.access.JavaAWTAccess.java

Reviewed-by: dfuchs, serb

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

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

From valeriep at openjdk.org  Mon Jun  9 18:18:53 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 9 Jun 2025 18:18:53 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v5]
In-Reply-To: <pvhSQjYfzdrNGfwj_4zOfPQIpMwmHpPmtZIFm_551Sc=.8eada92c-87b0-49e4-a011-4a42afce1fe3@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <pvhSQjYfzdrNGfwj_4zOfPQIpMwmHpPmtZIFm_551Sc=.8eada92c-87b0-49e4-a011-4a42afce1fe3@github.com>
Message-ID: <m5J1d5ZnmT6VIdm4wUKUTHNwj_Qs1_fCZzArY-l641U=.6c7d9a3d-b56e-4586-ae62-6049068e00f3@github.com>

On Sat, 7 Jun 2025 20:07:45 GMT, Varada M <varadam at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8358159: Empty mode/padding in cipher transformations

Look good, thanks!

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25547#pullrequestreview-2910914746

From abarashev at openjdk.org  Mon Jun  9 21:51:38 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 9 Jun 2025 21:51:38 GMT
Subject: RFR: 8273042: TLS Certificate Compression
In-Reply-To: <WZJV1PTvW-BUS7sqMuFhHI5P-KvOTWpqPskHNyefKRg=.63da5c42-4c76-40f5-a470-074724c124bb@github.com>
References: <WZJV1PTvW-BUS7sqMuFhHI5P-KvOTWpqPskHNyefKRg=.63da5c42-4c76-40f5-a470-074724c124bb@github.com>
Message-ID: <r5qFM-YedWRWurk1oi0ykWAfkuV-FCKO-LpEL5c3kFk=.c7af1248-767f-4fe1-861d-fcb41f144b93@github.com>

On Wed, 23 Feb 2022 20:15:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review the implementation of RFC 8879, TLS Certificate Compression, in JDK.  The TLS Certificate Compression standard is an essential part for QUIC connections and performance improvement for TLS connections.  More details, please refer to the [JEP](https://bugs.openjdk.java.net/browse/JDK-8281710) proposal.
> 
> The JEP was submitted, and it may take time for the final approval.  But let me know you ideas and concerns about the proposal and implementation.
> 
> JEP: https://bugs.openjdk.java.net/browse/JDK-8281710

test/jdk/javax/net/ssl/HttpsURLConnection/HttpsCompressedCert.java line 64:

> 62:     public static void main(String[] args) throws Exception {
> 63:         SSLParameters sslParameters = new SSLParameters();
> 64:         sslParameters.setCertificateInflaters(Map.of("brotli", certInflater));

Why `brotli` compression is being requested here when JDK doesn't support it? Looks like Google doesn't send a compressed certificate back, that's why this test works, the supplied `certInflater` function is using ZLIB.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/7599#discussion_r2136560698

From ascarpino at openjdk.org  Tue Jun 10 00:17:29 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 10 Jun 2025 00:17:29 GMT
Subject: RFR: 8349946: Cipher javadoc could describe AEAD reuse better
In-Reply-To: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
References: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
Message-ID: <L-px4PdHImmRPWkOzgPK-2RGkO9gvJyf1JPt4ZX8f3U=.4938106c-59ec-4f09-893a-53ccbfbdc194@github.com>

On Thu, 22 May 2025 19:30:44 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The class documentation in javax.crypto.Cipher could better describe AEAD and reuse. The current class description example is outdated as GCM encryption does not allow resets. The doc should state that reset() may not be possible with some algorithms or providers and that an InvalidAlgorithmParameterException is thrown

Line 170 and 171 can be removed as the CC20/Poly1305 RFC isn't referenced anymore

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

PR Review: https://git.openjdk.org/jdk/pull/25399#pullrequestreview-2911656999

From ascarpino at openjdk.org  Tue Jun 10 00:17:30 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 10 Jun 2025 00:17:30 GMT
Subject: RFR: 8349946: Cipher javadoc could describe AEAD reuse better
In-Reply-To: <TrwHU140bc4tTBDcocdzdr7MjewYsBBSUxC0-Yw9Ykk=.aa1e59da-d232-423a-b079-489a1c4ae8c5@github.com>
References: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
 <TrwHU140bc4tTBDcocdzdr7MjewYsBBSUxC0-Yw9Ykk=.aa1e59da-d232-423a-b079-489a1c4ae8c5@github.com>
Message-ID: <Zof2JwoCGBsHmtGT10TdhwZcHRkgTCaVms-VVbSUMjk=.e303dba5-02bf-46e3-8f40-6271832022bc@github.com>

On Sat, 7 Jun 2025 05:24:40 GMT, Sebastian Stenzel <duke at openjdk.org> wrote:

>> The class documentation in javax.crypto.Cipher could better describe AEAD and reuse. The current class description example is outdated as GCM encryption does not allow resets. The doc should state that reset() may not be possible with some algorithms or providers and that an InvalidAlgorithmParameterException is thrown
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 117:
> 
>> 115:  * forgery attacks due to Key and IV uniqueness requirements.
>> 116:  * An {@link IllegalStateException} will be thrown when calling {@code update}
>> 117:  * or {@code doFinal} methods when a reset did not occur.
> 
> It might be helpful to describe what to do instead:
> 
> When reset is not possible, you don't need to dispose the cipher object. Instead you can call init again with a different key/nonce.

I suggest appending the sentence:  "{@code init} may re-initialize the {@code Cipher} object with new parameters".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2136696481

From amitkumar at openjdk.org  Tue Jun 10 03:59:35 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 10 Jun 2025 03:59:35 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v5]
In-Reply-To: <pvhSQjYfzdrNGfwj_4zOfPQIpMwmHpPmtZIFm_551Sc=.8eada92c-87b0-49e4-a011-4a42afce1fe3@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <pvhSQjYfzdrNGfwj_4zOfPQIpMwmHpPmtZIFm_551Sc=.8eada92c-87b0-49e4-a011-4a42afce1fe3@github.com>
Message-ID: <RC4JyQWezWfOa_yKOC9l98piTFET6qK-7_r1dIHwq3I=.860f2fe8-11e5-4449-b0ac-98655c96b336@github.com>

On Sat, 7 Jun 2025 20:07:45 GMT, Varada M <varadam at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8358159: Empty mode/padding in cipher transformations

Marked as reviewed by amitkumar (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25547#pullrequestreview-2911889507

From varadam at openjdk.org  Tue Jun 10 08:20:52 2025
From: varadam at openjdk.org (Varada M)
Date: Tue, 10 Jun 2025 08:20:52 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v5]
In-Reply-To: <pvhSQjYfzdrNGfwj_4zOfPQIpMwmHpPmtZIFm_551Sc=.8eada92c-87b0-49e4-a011-4a42afce1fe3@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <pvhSQjYfzdrNGfwj_4zOfPQIpMwmHpPmtZIFm_551Sc=.8eada92c-87b0-49e4-a011-4a42afce1fe3@github.com>
Message-ID: <J2Bs9db133bbdfgUdb2yYBL59JRN32zqnPwGBQSOVus=.bcbfe678-9751-4317-accc-bc6b248af485@github.com>

On Sat, 7 Jun 2025 20:07:45 GMT, Varada M <varadam at openjdk.org> wrote:

>> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
>> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
>> 
>> Testing done for : tier1 - fastdebug level (AIX)
>> 
>> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8358159: Empty mode/padding in cipher transformations

Thanks all

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

PR Comment: https://git.openjdk.org/jdk/pull/25547#issuecomment-2958124525

From varadam at openjdk.org  Tue Jun 10 08:20:55 2025
From: varadam at openjdk.org (Varada M)
Date: Tue, 10 Jun 2025 08:20:55 GMT
Subject: Integrated: 8358159: Empty mode/padding in cipher transformations
In-Reply-To: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
Message-ID: <5V6b4baqEhYe26zDZA6HMr1Tb9wBAJQGluoAOAvKPmI=.3a5d716e-69b6-4bda-9470-7ae012bfb0e9@github.com>

On Fri, 30 May 2025 12:06:21 GMT, Varada M <varadam at openjdk.org> wrote:

> Omitting the mode/padding in a transformation string eg: "AES/ /NoPadding" throws NoSuchAlgorithmException.
> This patch restores the behavior by ensuring that empty mode or padding strings are interpreted as null.
> 
> Testing done for : tier1 - fastdebug level (AIX)
> 
> JBS: [JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159)

This pull request has now been integrated.

Changeset: 3ff83ec4
Author:    Varada M <varadam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ff83ec49e561c44dd99508364b8ba068274b63a
Stats:     68 lines in 2 files changed: 62 ins; 0 del; 6 mod

8358159: Empty mode/padding in cipher transformations

Reviewed-by: amitkumar, valeriep

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

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

From jpai at openjdk.org  Tue Jun 10 10:31:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jun 2025 10:31:45 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v2]
In-Reply-To: <VK3OPea665iZC9L0afD3lLokdgrTbNj_kbiYZFe2Xf8=.885395b6-9daa-421b-8c5a-09722b236052@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
 <VK3OPea665iZC9L0afD3lLokdgrTbNj_kbiYZFe2Xf8=.885395b6-9daa-421b-8c5a-09722b236052@github.com>
Message-ID: <USriuw2Xh65pMGKkP2rtqvWiOfWEs_8hj_V18XdgH9A=.f0225d4f-95e2-4a10-9514-a4c595dc6035@github.com>

On Fri, 25 Apr 2025 19:07:37 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>>  - http3: minor improvement to log message
>>  - http3: Artur's review - remove commented out code from test
>>  - http3: Artur's review - make methods package private
>>  - http3: qpack - allow 0 capacity when max capacity is 0
>>  - Remove flow control from stream limit comments
>>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 192:
> 
>> 190:      */
>> 191:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
>> 192:                                         String[] allowedAlgorithms,
> 
> This should probably be renamed to `supportedAlgorithms` for consistency, to match SSLEngine and SSLSocket methods.

Done, the PR has been updated to rename this to supportedAlgorithms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2137500358

From sean.mullan at oracle.com  Tue Jun 10 12:11:52 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 10 Jun 2025 08:11:52 -0400
Subject: CFV: New Security Group Member: Hai-May Chao
Message-ID: <be448405-48cd-45dd-be4b-1a259fce8d0e@oracle.com>

I hereby nominate Hai-May Chao to Membership in the Security Group.

Hai-May is a member of Oracle's Java Security Libraries team and has 
contributed many changes to the security components of the JDK project. 
She has significantly enhanced and improved the security of the Java 
platform, especially in the area of security tools (jarsigner and 
keytool) and signed JAR verification.

Votes are due by 13:00 UTC Tuesday 24th June 2025.

Only current Members of the Security Group [1] are eligible to vote on 
this nomination.  Votes must be cast in the open by replying to this 
mailing list.

For Lazy Consensus voting instructions, see [2].

Sean Mullan

[1] https://openjdk.org/census#security
[2] https://openjdk.org/groups/#member-vote

From sean.mullan at oracle.com  Tue Jun 10 12:13:22 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 10 Jun 2025 08:13:22 -0400
Subject: CFV: New Security Group Member: Hai-May Chao
In-Reply-To: <be448405-48cd-45dd-be4b-1a259fce8d0e@oracle.com>
References: <be448405-48cd-45dd-be4b-1a259fce8d0e@oracle.com>
Message-ID: <044bdb71-e05a-499f-885c-4f014df1340b@oracle.com>

Vote: yes

--Sean

On 6/10/25 8:11 AM, Sean Mullan wrote:
> I hereby nominate Hai-May Chao to Membership in the Security Group.
> 
> Hai-May is a member of Oracle's Java Security Libraries team and has 
> contributed many changes to the security components of the JDK project. 
> She has significantly enhanced and improved the security of the Java 
> platform, especially in the area of security tools (jarsigner and 
> keytool) and signed JAR verification.
> 
> Votes are due by 13:00 UTC Tuesday 24th June 2025.
> 
> Only current Members of the Security Group [1] are eligible to vote on 
> this nomination.? Votes must be cast in the open by replying to this 
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Sean Mullan
> 
> [1] https://openjdk.org/census#security
> [2] https://openjdk.org/groups/#member-vote


From mullan at openjdk.org  Tue Jun 10 12:34:40 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 10 Jun 2025 12:34:40 GMT
Subject: RFR: 8314180: Disable XPath in XML Signatures
Message-ID: <8_nUxGMyVGehCq8srfBgUaz5LF-DRmKkJQeendvRWLA=.d1d7a403-d94f-46d1-a763-3030debcff1d@github.com>

The XPath Transform is rarely used, introduces complexity, and is not recommended by the [XML Signature Best Practices](https://www.w3.org/TR/xmldsig-bestpractices/) document. Applications should use the XPath Transform 2.0 Filter instead, which was designed to be an alternative to the XPath Transform. This change will disable the XPath Transform by default.

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

Commit messages:
 - Initial fix.

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

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

From mullan at openjdk.org  Tue Jun 10 13:09:36 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 10 Jun 2025 13:09:36 GMT
Subject: RFR: 8315487: Security Providers Filter [v23]
In-Reply-To: <pgzoxuhBfcidmYjTbIXafrm3NA3HPefOc6xyeJ7CagA=.4f5513c3-beac-4ee3-9779-a63eb5ca478c@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
 <pgzoxuhBfcidmYjTbIXafrm3NA3HPefOc6xyeJ7CagA=.4f5513c3-beac-4ee3-9779-a63eb5ca478c@github.com>
Message-ID: <W7HG7cN_W33gisSku8n_mEecODOIipX9coNKF67_nWA=.3ca2853a-0f57-4d1a-adf0-96db2f69efb7@github.com>

On Thu, 8 May 2025 20:50:17 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 with a new target base due to a merge or a rebase. The pull request now contains 1268 commits:
> 
>  - 8315487: Security Providers Filter
>    
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8356126: Duplication handling and optimization of CaptureCallState
>    
>    Reviewed-by: jvernee
>  - 8332934: Do loop with continue with subsequent switch leads to incorrect stack maps
>    
>    Reviewed-by: vromero
>  - 8354461: Update tests to disable streaming output for attach tools
>    
>    Reviewed-by: sspitsyn, cjplummer
>  - 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty
>    
>    Reviewed-by: ccheung, shade, kvn
>  - 8356318: Unexpected VerifyError in AOT training run
>    
>    Reviewed-by: shade, kvn
>  - 8356025: Provide a PrintVMInfoAtExit diagnostic switch
>    
>    Reviewed-by: mbaesken, jsikstro
>  - 8347004: vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java fails with CDS disabled
>    
>    Reviewed-by: coleenp
>  - 8354443: [Graal] crash after deopt in TestG1BarrierGeneration.java
>    
>    Reviewed-by: dnsimon, yzheng
>  - 8355775: Improve symbolic sharing in dynamic constant pool entries
>    
>    Reviewed-by: asotona
>  - ... and 1258 more: https://git.openjdk.org/jdk/compare/8c09d40d...37d3f23a

src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java line 162:

> 160:      * {@link System#getProperty(String) System} and
> 161:      * {@link Security#getProperty(String) Security} properties determine
> 162:      * which services are enabled. A service that is not enabled by the

In these and other APIs, I think it would be useful to link to `java.security.Provider.Service` when mentioning "services" since this is the first mention of that term in this API.

src/java.base/share/classes/java/security/Security.java line 387:

> 385:      * algorithm and provider. Search is case-insensitive.
> 386:      */
> 387:     private static Provider.Service findService(String type, String algo,

You need to add a similar implementation note about the `jdk.security.providers.filter` property to the `getProviders(String)` method since it can affect what providers are returned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15539#discussion_r2132598600
PR Review Comment: https://git.openjdk.org/jdk/pull/15539#discussion_r2137858527

From weijun.wang at oracle.com  Tue Jun 10 13:29:40 2025
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Tue, 10 Jun 2025 13:29:40 +0000
Subject: CFV: New Security Group Member: Hai-May Chao
In-Reply-To: <be448405-48cd-45dd-be4b-1a259fce8d0e@oracle.com>
References: <be448405-48cd-45dd-be4b-1a259fce8d0e@oracle.com>
Message-ID: <450A4CAD-9FB4-4510-B39B-B4D75ADD2381@oracle.com>

Vote: yes

--Weijun

> On Jun 10, 2025, at 08:11, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> I hereby nominate Hai-May Chao to Membership in the Security Group.
> 
> Hai-May is a member of Oracle's Java Security Libraries team and has contributed many changes to the security components of the JDK project. She has significantly enhanced and improved the security of the Java platform, especially in the area of security tools (jarsigner and keytool) and signed JAR verification.
> 
> Votes are due by 13:00 UTC Tuesday 24th June 2025.
> 
> Only current Members of the Security Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Sean Mullan
> 
> [1] https://openjdk.org/census#security
> [2] https://openjdk.org/groups/#member-vote


From fguallini at openjdk.org  Tue Jun 10 14:02:44 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Tue, 10 Jun 2025 14:02:44 GMT
Subject: [jdk25] RFR: 8358171: Additional code coverage for PEM API
Message-ID: <zQyHxpXs8nQpAyvJD7bUsgEtrAOQsLwojM6sqVChBDY=.ed8b5255-2c08-486a-9bd3-590f00b432f1@github.com>

Hi all,

This pull request contains a backport of commit [b2e7cda6](https://github.com/openjdk/jdk/commit/b2e7cda6a0bd21fa3c4ffe2a67da4953f1ca3f1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Fernando Guallini on 6 Jun 2025 and was reviewed by Anthony Scarpino.

Thanks!

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

Commit messages:
 - Backport b2e7cda6a0bd21fa3c4ffe2a67da4953f1ca3f1f

Changes: https://git.openjdk.org/jdk/pull/25712/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25712&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358171
  Stats: 535 lines in 10 files changed: 492 ins; 2 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/25712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25712/head:pull/25712

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

From weijun at openjdk.org  Tue Jun 10 14:41:49 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 10 Jun 2025 14:41:49 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v4]
In-Reply-To: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
Message-ID: <SsqcFUEplYv6T9rqb1-9wE7K7ANRTYyJuab6lS9H5JM=.64eb3edf-3711-480b-a69f-0c1484018120@github.com>

> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-11 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded when a new key pair is generated or when `KeyFactory::translateKey` is called.
> 
> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is calculated from the input if it's seed only.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into 8347938
 - KeyChoices class
 - allow expanded to be null
 - merge
 - Merge
 - safer privKeyToPubKey; updated desciptions for the properties; adding braces to if blocks
 - the fix

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

Changes: https://git.openjdk.org/jdk/pull/24969/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24969&range=03
  Stats: 2697 lines in 23 files changed: 1939 ins; 548 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/24969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24969/head:pull/24969

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

From rhalade at openjdk.org  Tue Jun 10 18:28:30 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 10 Jun 2025 18:28:30 GMT
Subject: [jdk25] RFR: 8358171: Additional code coverage for PEM API
In-Reply-To: <zQyHxpXs8nQpAyvJD7bUsgEtrAOQsLwojM6sqVChBDY=.ed8b5255-2c08-486a-9bd3-590f00b432f1@github.com>
References: <zQyHxpXs8nQpAyvJD7bUsgEtrAOQsLwojM6sqVChBDY=.ed8b5255-2c08-486a-9bd3-590f00b432f1@github.com>
Message-ID: <kDWoXD_cyVC8o0sxEmmyC5-ba1PSZEkRv-SGTj9qrRE=.d9009d75-406e-49cb-a9d2-baf58aa29beb@github.com>

On Tue, 10 Jun 2025 07:26:54 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b2e7cda6](https://github.com/openjdk/jdk/commit/b2e7cda6a0bd21fa3c4ffe2a67da4953f1ca3f1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Fernando Guallini on 6 Jun 2025 and was reviewed by Anthony Scarpino.
> 
> Thanks!

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25712#pullrequestreview-2914668327

From ascarpino at openjdk.org  Tue Jun 10 18:50:28 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 10 Jun 2025 18:50:28 GMT
Subject: [jdk25] RFR: 8358171: Additional code coverage for PEM API
In-Reply-To: <zQyHxpXs8nQpAyvJD7bUsgEtrAOQsLwojM6sqVChBDY=.ed8b5255-2c08-486a-9bd3-590f00b432f1@github.com>
References: <zQyHxpXs8nQpAyvJD7bUsgEtrAOQsLwojM6sqVChBDY=.ed8b5255-2c08-486a-9bd3-590f00b432f1@github.com>
Message-ID: <kibu28LtxI0MbSlRiDxkF56WEc7BvhztBd4LZA-8y8E=.fb546bd9-d90c-4248-b2c9-1147d11b4751@github.com>

On Tue, 10 Jun 2025 07:26:54 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b2e7cda6](https://github.com/openjdk/jdk/commit/b2e7cda6a0bd21fa3c4ffe2a67da4953f1ca3f1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Fernando Guallini on 6 Jun 2025 and was reviewed by Anthony Scarpino.
> 
> Thanks!

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25712#pullrequestreview-2914723224

From rhalade at openjdk.org  Tue Jun 10 21:25:14 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 10 Jun 2025 21:25:14 GMT
Subject: RFR: 8359170: Add 2 TLS and 2 CS Sectigo roots
Message-ID: <HdEWjtU-1sf4U5vvsQaS4eqr8oyZ21Hjdf2dnUSkjx4=.c3c5ffc4-67ce-494c-880a-4c85a38d137b@github.com>

This PR is to add four new root certificates from Sectigo Limited. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.

The release-note is at [JDK-8359171](https://bugs.openjdk.org/browse/JDK-8359171)

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

Commit messages:
 - 8359170: Update to bug id
 - 0000000: Certify Sectigo TLS and CS CAs

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

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

From mullan at openjdk.org  Tue Jun 10 21:59:28 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 10 Jun 2025 21:59:28 GMT
Subject: RFR: 8359170: Add 2 TLS and 2 CS Sectigo roots
In-Reply-To: <HdEWjtU-1sf4U5vvsQaS4eqr8oyZ21Hjdf2dnUSkjx4=.c3c5ffc4-67ce-494c-880a-4c85a38d137b@github.com>
References: <HdEWjtU-1sf4U5vvsQaS4eqr8oyZ21Hjdf2dnUSkjx4=.c3c5ffc4-67ce-494c-880a-4c85a38d137b@github.com>
Message-ID: <X8xfvOY3QAeUsCPM_5zD5XIWJA3NvzPAlGyxG1SBMzs=.de1b8e70-b310-4514-8eff-394cd96552b8@github.com>

On Tue, 10 Jun 2025 18:36:17 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add four new root certificates from Sectigo Limited. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> The release-note is at [JDK-8359171](https://bugs.openjdk.org/browse/JDK-8359171)

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25733#pullrequestreview-2915131861

From rhalade at openjdk.org  Tue Jun 10 22:02:45 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 10 Jun 2025 22:02:45 GMT
Subject: Integrated: 8359170: Add 2 TLS and 2 CS Sectigo roots
In-Reply-To: <HdEWjtU-1sf4U5vvsQaS4eqr8oyZ21Hjdf2dnUSkjx4=.c3c5ffc4-67ce-494c-880a-4c85a38d137b@github.com>
References: <HdEWjtU-1sf4U5vvsQaS4eqr8oyZ21Hjdf2dnUSkjx4=.c3c5ffc4-67ce-494c-880a-4c85a38d137b@github.com>
Message-ID: <jCldJiKxQcNkMlIqgignMiRjBY2CWifO-3jXmnjlg28=.390fccf1-4919-4920-a41c-bade230bafeb@github.com>

On Tue, 10 Jun 2025 18:36:17 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add four new root certificates from Sectigo Limited. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> The release-note is at [JDK-8359171](https://bugs.openjdk.org/browse/JDK-8359171)

This pull request has now been integrated.

Changeset: 9586817c
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9586817cea3f1cad8a49d43e9106e25dafa04765
Stats:     479 lines in 7 files changed: 475 ins; 0 del; 4 mod

8359170: Add 2 TLS and 2 CS Sectigo roots

Reviewed-by: mullan

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

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

From abarashev at openjdk.org  Tue Jun 10 22:04:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:04:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <w_IZtUmgo7JbvZayavQbvsBLhMesF1P60iZ-tMJU5-w=.3bd35485-107b-4e10-9a65-b9acb64811f8@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

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

> 241:         }
> 242:         // QUIC TLS version is mandated to be always TLSv1.3
> 243:         if (!ProtocolVersion.useTLS12PlusSpec(session.getProtocol())) {

Should be `useTLS13PlusSpec`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138839652

From rhalade at openjdk.org  Tue Jun 10 22:09:01 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 10 Jun 2025 22:09:01 GMT
Subject: [jdk25] RFR: 8359170: Add 2 TLS and 2 CS Sectigo roots
Message-ID: <U81Rvkd3rCouvQCgHnalznWXhKvi4sAPB9rKeYlWTuE=.8892890f-ec92-4519-a763-f119ea74833b@github.com>

Hi all,

This pull request contains a backport of commit [9586817c](https://github.com/openjdk/jdk/commit/9586817cea3f1cad8a49d43e9106e25dafa04765) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Rajan Halade on 10 Jun 2025 and was reviewed by Sean Mullan.

Thanks!

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

Commit messages:
 - Backport 9586817cea3f1cad8a49d43e9106e25dafa04765

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

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

From abarashev at openjdk.org  Tue Jun 10 22:12:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:12:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <6AU7lGXUVGbSk3B65aPdjokTF3j91LjG445kzW5Hq1Y=.c1580e0d-3ebe-4b0b-8e58-b0233639b295@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 229:

> 227:             // any algorithm constraints when choosing the client alias and
> 228:             // just call the functionally limited
> 229:             // javax.net.ssl.X509KeyManager.chooseClientAlias(...)

This comment should be updated as we do take into account algorithm constraints. I would remove `TODO` word as well, maybe replace it with `NOTE`

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 328:

> 326:                 // any algorithm constraints when choosing the server alias
> 327:                 // and just call the functionally limited
> 328:                 // javax.net.ssl.X509KeyManager.chooseServerAlias(...)

Same as above, update the comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138847212
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138847768

From abarashev at openjdk.org  Tue Jun 10 22:19:41 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:19:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <vLvyqUUFPFSJUrFUl8EOEBJHGsoIxWOVGMeB0uhV6Tw=.249ece3e-3a6e-4671-ae9a-5fa23bee0b14@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 164:

> 162:      */
> 163:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
> 164:                                         boolean applyCertPathAlgConstraints) {

This parameter should be called `withDefaultCertPathConstraints` for consistency with other methods.

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 188:

> 186:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
> 187:                                         String[] supportedAlgorithms,
> 188:                                         boolean applyCertPathAlgConstraints) {

Same as above:  should be called `withDefaultCertPathConstraints`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138853006
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138853942

From abarashev at openjdk.org  Tue Jun 10 22:24:42 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:24:42 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 247:

> 245:         if (quicEngine != null) {
> 246:             if (quicEngine instanceof QuicTLSEngineImpl engineImpl) {
> 247:                 return engineImpl.getAlgorithmConstraints();

Any particular reason constraints selection code was moved to `engineImpl.getAlgorithmConstraints()` and not kept in this file for consistency with `SSLEngine` and `SSLSocket`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138858886

From abarashev at openjdk.org  Tue Jun 10 22:58:44 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:58:44 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <fopFSoDFZHwFvMU9afn5Z0GeiECsjaMNr0ng4-rtXAQ=.72243a2e-a505-4e2b-943c-9ec644d47a4b@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <fopFSoDFZHwFvMU9afn5Z0GeiECsjaMNr0ng4-rtXAQ=.72243a2e-a505-4e2b-943c-9ec644d47a4b@github.com>
Message-ID: <oGSPDZ3vfqSMEE64wxCFmFw9MSgZV0eWGKbmvFQetXM=.ce8d8479-bbf8-4af2-8ed9-f70bfad1b8f3@github.com>

On Tue, 22 Apr 2025 19:36:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - Improve key destruction
>>  - merge latest changes from master branch
>>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>>  - http3: refactor HTTP/3 connection pool management in a separate class
>>  - Ignore DestroyFailedExceptions
>>  - Remove outdated TODO
>>  - Remove outdated TODO
>>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8
>
> src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1221:
> 
>> 1219:                         tm.checkClientTrusted(
>> 1220:                                 certs.clone(),
>> 1221:                                 authType);
> 
> This call doesn't check against `SSLAlgorithmConstraints` unlike 2 calls for `SSLSocket` and `SSLEngine` above.

What would be the reason it's not addressed like in `checkServerCerts` below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138892993

From vyazici at openjdk.org  Wed Jun 11 10:32:32 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:32:32 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
Message-ID: <E2xTeHEtEObgciaqOrdjj-xGRdq1ZugtdzM7XQFvMvA=.f5defb51-2610-473d-89e7-1f6f178d7b9c@github.com>

On Thu, 5 Jun 2025 10:13:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve code style
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/javax/script/MyContext.java line 52:

> 50:         engineScope = new SimpleBindings();
> 51:         globalScope = null;
> 52:         reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));

I will revert this change, since

1. AFAICT, this file is not used anymore
2. Neither `std{out,err}.encoding` were used while creating `PrintWriter`s below

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139786341

From vyazici at openjdk.org  Wed Jun 11 10:37:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:37:30 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
Message-ID: <v97kiJfbm4kka6qtgVKr30XtA_BIPRQ26QVLuGdwzJY=.040aee98-63fc-469a-ab1b-d82daf9ecd46@github.com>

On Thu, 5 Jun 2025 10:13:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve code style
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/javax/security/auth/login/LoginContext/DefaultHandlerImpl.java line 80:

> 78:                 System.err.flush();
> 79:                 Reader stdinReader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 80:                 nc.setName(new BufferedReader(stdinReader).readLine());

Will revert this change, it is superfluous. As a matter of fact, there is a `readPassword(System.in)` down below that could have also been addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139795483

From vyazici at openjdk.org  Wed Jun 11 10:43:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:43:47 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v6]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <7XLzfBmB2raJzcZP4NtaaWxQX2gYDrdd8Z1FzhTRmTg=.cfe1fb59-e062-45c4-9410-f5164c2cf479@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

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

  Revert superfluous test changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/92248bb3..ca96e12b

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

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

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

From vyazici at openjdk.org  Wed Jun 11 10:43:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:43:48 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <E2xTeHEtEObgciaqOrdjj-xGRdq1ZugtdzM7XQFvMvA=.f5defb51-2610-473d-89e7-1f6f178d7b9c@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
 <E2xTeHEtEObgciaqOrdjj-xGRdq1ZugtdzM7XQFvMvA=.f5defb51-2610-473d-89e7-1f6f178d7b9c@github.com>
Message-ID: <jOged_3bL5xjITokxOe5yzZ-gIUw1VeLnjiyqQrgSn4=.961fb018-8482-45a7-8f67-dad86cb59b23@github.com>

On Wed, 11 Jun 2025 10:29:52 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve code style
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/javax/script/MyContext.java line 52:
> 
>> 50:         engineScope = new SimpleBindings();
>> 51:         globalScope = null;
>> 52:         reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 
> I will revert this change, since
> 
> 1. AFAICT, this file is not used anymore
> 2. Neither `std{out,err}.encoding` were used while creating `PrintWriter`s below

Reverted in ca96e12be8e.

> test/jdk/javax/security/auth/login/LoginContext/DefaultHandlerImpl.java line 80:
> 
>> 78:                 System.err.flush();
>> 79:                 Reader stdinReader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
>> 80:                 nc.setName(new BufferedReader(stdinReader).readLine());
> 
> Will revert this change, it is superfluous. As a matter of fact, there is a `readPassword(System.in)` down below that could have also been addressed.

Reverted in ca96e12be8e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139804910
PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139804751

From valerie.peng at oracle.com  Wed Jun 11 20:45:05 2025
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 11 Jun 2025 20:45:05 +0000
Subject: CFV: New Security Group Member: Hai-May Chao
In-Reply-To: <be448405-48cd-45dd-be4b-1a259fce8d0e@oracle.com>
References: <be448405-48cd-45dd-be4b-1a259fce8d0e@oracle.com>
Message-ID: <SN7PR10MB6364ADC81FD53A9B114B9105F175A@SN7PR10MB6364.namprd10.prod.outlook.com>

Vote: yes

Valerie

-----Original Message-----
From: security-dev <security-dev-retn at openjdk.org> On Behalf Of Sean Mullan
Sent: Tuesday, June 10, 2025 5:12 AM
To: security-dev at openjdk.org
Subject: CFV: New Security Group Member: Hai-May Chao

I hereby nominate Hai-May Chao to Membership in the Security Group.

Hai-May is a member of Oracle's Java Security Libraries team and has contributed many changes to the security components of the JDK project. 
She has significantly enhanced and improved the security of the Java platform, especially in the area of security tools (jarsigner and
keytool) and signed JAR verification.

Votes are due by 13:00 UTC Tuesday 24th June 2025.

Only current Members of the Security Group [1] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2].

Sean Mullan

[1] https://openjdk.org/census#security
[2] https://openjdk.org/groups/#member-vote

From jamil.j.nimeh at oracle.com  Wed Jun 11 21:14:19 2025
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 11 Jun 2025 14:14:19 -0700
Subject: CFV: New Security Group Member: Hai-May Chao
In-Reply-To: <be448405-48cd-45dd-be4b-1a259fce8d0e@oracle.com>
References: <be448405-48cd-45dd-be4b-1a259fce8d0e@oracle.com>
Message-ID: <424db07d-cbfa-4af1-a895-797d69d39435@oracle.com>

Vote: yes

--Jamil

On 6/10/2025 5:11 AM, Sean Mullan wrote:
> I hereby nominate Hai-May Chao to Membership in the Security Group.
>
> Hai-May is a member of Oracle's Java Security Libraries team and has 
> contributed many changes to the security components of the JDK 
> project. She has significantly enhanced and improved the security of 
> the Java platform, especially in the area of security tools (jarsigner 
> and keytool) and signed JAR verification.
>
> Votes are due by 13:00 UTC Tuesday 24th June 2025.
>
> Only current Members of the Security Group [1] are eligible to vote on 
> this nomination.? Votes must be cast in the open by replying to this 
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Sean Mullan
>
> [1] https://openjdk.org/census#security
> [2] https://openjdk.org/groups/#member-vote

From weijun at openjdk.org  Thu Jun 12 12:47:44 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 12 Jun 2025 12:47:44 GMT
Subject: RFR: 8314180: Disable XPath in XML Signatures
In-Reply-To: <8_nUxGMyVGehCq8srfBgUaz5LF-DRmKkJQeendvRWLA=.d1d7a403-d94f-46d1-a763-3030debcff1d@github.com>
References: <8_nUxGMyVGehCq8srfBgUaz5LF-DRmKkJQeendvRWLA=.d1d7a403-d94f-46d1-a763-3030debcff1d@github.com>
Message-ID: <yBMt9v1GNgKS5Avz51cALHfe7kyxa92HJT6eV8xIC-g=.9e95ca1d-0ebb-4e11-9188-8af51cbb5041@github.com>

On Tue, 10 Jun 2025 12:29:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> The XPath Transform is rarely used, introduces complexity, and is not recommended by the [XML Signature Best Practices](https://www.w3.org/TR/xmldsig-bestpractices/) document. Applications should use the XPath Transform 2.0 Filter instead, which was designed to be an alternative to the XPath Transform. This change will disable the XPath Transform by default.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25721#pullrequestreview-2920998704

From michael.osipov at innomotics.com  Thu Jun 12 16:42:38 2025
From: michael.osipov at innomotics.com (Osipov, Michael (IN IT IN))
Date: Thu, 12 Jun 2025 18:42:38 +0200
Subject: [Bug] NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is
 used with QOP auth-int against Active Directory
Message-ID: <4f83241c-3de7-4986-963c-60e11a5f5faf@siemens.com>

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

Hi Weibing,

apologies, it took me some time to respond. Here is the Java code in 
question: 
https://gist.github.com/michael-o/8cff749d3ce5536bf70a16a64819cf10. 
Please also find here some screenshots 
(https://people.freebsd.org/~michaelo/ad-gssapi-tls-npe/) from my 
debugger showing the cause.

There is, indeed, something you missed: The Connection object is run 
asynchronously is a separate thread. ::run() invokes the SASL input 
stream which throws an IOE because the SASL receive buffer size is too 
large. The exception is caught and swallowed. finally{} is called, it 
calls ::cleanup(). Meanwhile the LDAP client receives the connection 
closure from the server, the client tries to abandon the request and 
invokes the SASL client which is already disposed by the connection. 
Therefore you don't see the Connection::cleanup() method in the stack 
trace. If you pay a close look at the output of ldapsearch(1) you will 
see that there are two errors: (1) the buffer size mismatch and (2) the 
connection closure from the server. The first issue causes the second to 
fail in JNDI/LDAP.

Michael

From duke at openjdk.org  Thu Jun 12 17:04:22 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 12 Jun 2025 17:04:22 GMT
Subject: RFR: 8349946: Cipher javadoc could describe AEAD reuse better [v2]
In-Reply-To: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
References: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
Message-ID: <pLTFSk6xU2gd47wM95pcIvCCg32wX5OBilbrd7TcW-s=.10b0f2bc-512d-49c9-a9cf-c67e66b5368b@github.com>

> The class documentation in javax.crypto.Cipher could better describe AEAD and reuse. The current class description example is outdated as GCM encryption does not allow resets. The doc should state that reset() may not be possible with some algorithms or providers and that an InvalidAlgorithmParameterException is thrown

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

  8349946:Cipher javadoc could describe AEAD reuse better

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25399/files
  - new: https://git.openjdk.org/jdk/pull/25399/files/ea320d8a..8d8446e3

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

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

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

From dfuchs at openjdk.org  Thu Jun 12 18:53:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 18:53:18 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <bttVrklfkEVMhRXGDs3ombxBWKJXkX3PFG9dg1qJyJo=.99d3a625-d679-43d7-9f2b-25ce105f521c@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 506 commits:

 - merge latest changes from master branch
 - http3: update H3InsertionsLimitTest to start after receival of client settings
 - merge latest changes from master branch
 - quic: separate out the idle termination timer and the STREAM_DATA_BLOCKED timer
 - quic: simplify idle timeout management
 - http3: rely on the sole isOpen() method instead of isOpen() and isClosed()
 - quic: do not let h3 idle (in pool) timeout to influence the quic transport idle timeout
 - merge latest changes from master branch
 - http3: improve H3ConnectionPoolTest.java
 - Fix snippet
 - ... and 496 more: https://git.openjdk.org/jdk/compare/8d33ea73...d4984d5e

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=07
  Stats: 103752 lines in 472 files changed: 100891 ins; 1345 del; 1516 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From duke at openjdk.org  Thu Jun 12 19:15:31 2025
From: duke at openjdk.org (duke)
Date: Thu, 12 Jun 2025 19:15:31 GMT
Subject: RFR: 8349550: Improve SASL random usage [v4]
In-Reply-To: <cjlnYXMiUYNMxRszbvxiGnCYYofkCqyToHQ8Io_eHKI=.1105c51f-9c10-44f3-b1af-b6646fb562d2@github.com>
References: <D8e7CNHWtQIQdHBay1Xz0iGBTiB54XF-Dbfh0egoFUc=.c65f4143-0182-4e88-a9d8-8c82a829fae7@github.com>
 <cjlnYXMiUYNMxRszbvxiGnCYYofkCqyToHQ8Io_eHKI=.1105c51f-9c10-44f3-b1af-b6646fb562d2@github.com>
Message-ID: <GjPdG5SS-VC2DYquZiqhqgbpYYpzcF2-Temmm5Pmpas=.0ee02353-c485-4fe0-93b3-85caef76c585@github.com>

On Fri, 30 May 2025 18:19:13 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random
>
> Koushik Muthukrishnan Thirupattur has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - 8349550: Improve SASL random usage
>  - Merge branch 'master' into 8349550
>  - 8349550: Improve SASL random usage
>  - Merge branch 'master' into 8349550
>  - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random
>  - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random
>  - 8349550: Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random

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

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

PR Comment: https://git.openjdk.org/jdk/pull/25241#issuecomment-2967888600

From duke at openjdk.org  Thu Jun 12 19:34:33 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 12 Jun 2025 19:34:33 GMT
Subject: Integrated: 8349550: Improve SASL random usage
In-Reply-To: <D8e7CNHWtQIQdHBay1Xz0iGBTiB54XF-Dbfh0egoFUc=.c65f4143-0182-4e88-a9d8-8c82a829fae7@github.com>
References: <D8e7CNHWtQIQdHBay1Xz0iGBTiB54XF-Dbfh0egoFUc=.c65f4143-0182-4e88-a9d8-8c82a829fae7@github.com>
Message-ID: <caqgWsxdbTwevKbnpz8FiwTQ3OImxa2fVJeEHw2TBg8=.d5834cdd-02f2-44ae-b27f-bf5de010cd83@github.com>

On Wed, 14 May 2025 23:37:09 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> Check Digest-MD5 utilities SecureRandom Usage and update random usage with secure random

This pull request has now been integrated.

Changeset: db7af2b3
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db7af2b3c3bd63f17f7952e815ebafb5dd8486ab
Stats:     23 lines in 3 files changed: 13 ins; 6 del; 4 mod

8349550: Improve SASL random usage

Reviewed-by: mullan

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

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

From naoto at openjdk.org  Thu Jun 12 20:08:31 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 20:08:31 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v6]
In-Reply-To: <7XLzfBmB2raJzcZP4NtaaWxQX2gYDrdd8Z1FzhTRmTg=.cfe1fb59-e062-45c4-9410-f5164c2cf479@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <7XLzfBmB2raJzcZP4NtaaWxQX2gYDrdd8Z1FzhTRmTg=.cfe1fb59-e062-45c4-9410-f5164c2cf479@github.com>
Message-ID: <Z13w_jQPyUsasMyTRcXDJDwdlCNZImVLdJz9xUjY_rg=.5b78eb62-0344-4ebf-9c34-98e4b471dea7@github.com>

On Wed, 11 Jun 2025 10:43:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert superfluous test changes

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25544#pullrequestreview-2922513387

From valeriep at openjdk.org  Thu Jun 12 20:51:38 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 12 Jun 2025 20:51:38 GMT
Subject: RFR: 8358159: Empty mode/padding in cipher transformations [v5]
In-Reply-To: <J2Bs9db133bbdfgUdb2yYBL59JRN32zqnPwGBQSOVus=.bcbfe678-9751-4317-accc-bc6b248af485@github.com>
References: <Vy5mVbH5cnX7CTB74laN9_Ok-m87MWIkh3kAyzzvqPk=.aa2d884f-514e-459a-927f-c100d5296162@github.com>
 <pvhSQjYfzdrNGfwj_4zOfPQIpMwmHpPmtZIFm_551Sc=.8eada92c-87b0-49e4-a011-4a42afce1fe3@github.com>
 <J2Bs9db133bbdfgUdb2yYBL59JRN32zqnPwGBQSOVus=.bcbfe678-9751-4317-accc-bc6b248af485@github.com>
Message-ID: <blKbAU7CCW89lL8QjIQr1ReRa1P31DvhEj24EtTap14=.8350d55b-a4e2-49dd-9253-a7de7b2e16aa@github.com>

On Tue, 10 Jun 2025 08:17:29 GMT, Varada M <varadam at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8358159: Empty mode/padding in cipher transformations
>
> Thanks all

@varada1110 After checking various javadoc, security documentation, and the comments in earlier JDK releases, I have second thought on allowing empty mode and/or padding. Even though not strictly enforced to be rejected, I think the intention is to specify cipher transformations ("algorithm" or "algorithm/mode/padding") which all present components are non-empty. I filed a separate issue https://bugs.openjdk.org/browse/JDK-8359388 to address this. Please do let me know if tightening this up would break how you use it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25547#issuecomment-2968117537

From vyazici at openjdk.org  Fri Jun 13 08:15:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 08:15:44 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v7]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <8Cr08eX4jZi0YBrIUAWJqV8q3xZxdSCvm7t6_4ch-Jw=.299b1af4-e363-4669-9f3c-8f37d27bc068@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge remote-tracking branch 'upstream/master' into stdinEnc-core
 - Revert superfluous test changes
 - Improve code style
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Fix missing `java.io.Reader` import in `Ktab`
 - Clean-up `MultiBreakpointsTarg`
 - Provide fallback for `stdin.encoding`
 - Revert changes to `Application` and `JavaChild`
   
   There stdin is connected to the parent process rather than the console.
 - Revert more superfluous changes
 - Fix code typo
 - Discard changes unrelated with core libraries
 - ... and 4 more: https://git.openjdk.org/jdk/compare/9aeacf2d...d36e0bd5

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

Changes: https://git.openjdk.org/jdk/pull/25544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25544&range=06
  Stats: 130 lines in 11 files changed: 33 ins; 28 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

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

From mullan at openjdk.org  Fri Jun 13 12:18:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 13 Jun 2025 12:18:00 GMT
Subject: Integrated: 8314180: Disable XPath in XML Signatures
In-Reply-To: <8_nUxGMyVGehCq8srfBgUaz5LF-DRmKkJQeendvRWLA=.d1d7a403-d94f-46d1-a763-3030debcff1d@github.com>
References: <8_nUxGMyVGehCq8srfBgUaz5LF-DRmKkJQeendvRWLA=.d1d7a403-d94f-46d1-a763-3030debcff1d@github.com>
Message-ID: <UqNzKeAElqVMOecCn3scTYOwKvep8-MNnpLH_QFH0N4=.08f07583-747f-4346-a751-f2aa10137158@github.com>

On Tue, 10 Jun 2025 12:29:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> The XPath Transform is rarely used, introduces complexity, and is not recommended by the [XML Signature Best Practices](https://www.w3.org/TR/xmldsig-bestpractices/) document. Applications should use the XPath Transform 2.0 Filter instead, which was designed to be an alternative to the XPath Transform. This change will disable the XPath Transform by default.

This pull request has now been integrated.

Changeset: b5334fe2
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5334fe23797a81b91a558f9e55cdcaaee61d37b
Stats:     14 lines in 5 files changed: 2 ins; 0 del; 12 mod

8314180: Disable XPath in XML Signatures

Reviewed-by: weijun

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

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

From weijun at openjdk.org  Fri Jun 13 14:20:40 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 13 Jun 2025 14:20:40 GMT
Subject: RFR: 8359395: XML signature generation does not support user provided
 SecureRandom
Message-ID: <PmnDYLcH8BUUeAWsEGj14s7nMQ57Nv23Cu7O_fEK3eQ=.4d7ee88f-7ea7-4ddc-a384-97d669c52991@github.com>

New `XMLSignContext` property to allow user-specific `SecureRandom` for XML signature generation.

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

Commit messages:
 - the change

Changes: https://git.openjdk.org/jdk/pull/25802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359395
  Stats: 117 lines in 3 files changed: 115 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25802/head:pull/25802

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

From weijun at openjdk.org  Fri Jun 13 14:37:51 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 13 Jun 2025 14:37:51 GMT
Subject: RFR: 8359395: XML signature generation does not support user
 provided SecureRandom [v2]
In-Reply-To: <PmnDYLcH8BUUeAWsEGj14s7nMQ57Nv23Cu7O_fEK3eQ=.4d7ee88f-7ea7-4ddc-a384-97d669c52991@github.com>
References: <PmnDYLcH8BUUeAWsEGj14s7nMQ57Nv23Cu7O_fEK3eQ=.4d7ee88f-7ea7-4ddc-a384-97d669c52991@github.com>
Message-ID: <8Eyn71amqqwK75WsELmuwOAvbescRrDFcYfYLfBILVQ=.74b95830-6e4b-431b-a850-6dd86a7b54e4@github.com>

> New `XMLSignContext` property to allow user-specific `SecureRandom` for XML signature generation.

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

  rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25802/files
  - new: https://git.openjdk.org/jdk/pull/25802/files/b8d3431b..fcd50edd

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

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

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

From abarashev at openjdk.org  Fri Jun 13 14:45:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 13 Jun 2025 14:45:00 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v5]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <esnUNkBj9LPwYc4Y0oMz--CYw-oLMC4UimL2aKGr50Y=.a99616de-a1a1-4e74-8a2a-bee24e231bb0@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
> 
> **SUNX509 KeyManager performance before change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

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 19 additional commits since the last revision:

 - Support certificate checks in SunX509 key manager
 - Address some review comments
 - Merge branch 'master' into JDK-8353113
 - Make the test run on TLSv1.3
 - Make sure the exception happens during KeyManager's algorithm check
 - Add PeerConstraintsCheck unit test
 - Add unit test
 - Code refactoring
 - Fix open unit tests
 - Adding a system property to skip the constraints checking. Remove SunX509c.
 - ... and 9 more: https://git.openjdk.org/jdk/compare/5479addb...448442e9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/451e1efd..448442e9

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

  Stats: 228571 lines in 4300 files changed: 142799 ins; 58830 del; 26942 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From abarashev at openjdk.org  Fri Jun 13 14:48:31 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 13 Jun 2025 14:48:31 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <dUqp1eE1r7WCnvTsiskeeBEuRUO2MU8LgAHbZR53KQg=.779bbb42-784a-4f62-a29e-577fe40fb31b@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
 <dUqp1eE1r7WCnvTsiskeeBEuRUO2MU8LgAHbZR53KQg=.779bbb42-784a-4f62-a29e-577fe40fb31b@github.com>
Message-ID: <HiCi28cajcDKD8Ru8gjke2Q3-4rfc6hCNQ2EPlP52gQ=.3e188934-30df-4cea-90d0-32f62ba55696@github.com>

On Fri, 6 Jun 2025 21:11:16 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 401:
>> 
>>> 399:                 continue;
>>> 400:             }
>>> 401: 
>> 
>> I think we should also call `CertType.check` here, like in `X509KeyManagerImpl`. Since this change is now only selecting certificates with algorithms that are not disabled, I think it also makes sense to select certificates that have the proper extensions, etc and will not cause subsequent certificate chain validation failures.
>> 
>> This means we would have to change the name of the property so that it isn't only about disabling constraints checking. Perhaps: `jdk.tls.keymanager.disableCertSelectionChecking`.
>
> Yes, makes sense.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2145256449

From coffeys at openjdk.org  Fri Jun 13 14:58:40 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 13 Jun 2025 14:58:40 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v3]
In-Reply-To: <hZ8VcJN59gxHCT8CY0BaCJv3t9Mf4087knRSYGlRpuA=.5721d840-ce1d-4105-a30c-82f0e36fa31a@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
 <TnWloajWzELKJAzASpdMn4-aSHmLwFuOp3gGFRB7snE=.7705403b-145d-4aa0-bdd8-6e230b69ecb2@github.com>
 <EogNys19QLxTpiCyo8kZ9ektMdaaB9BTtTYQ8_LqMy0=.eac9e5ad-3d6f-43e9-83a6-3fac82cf1a7d@github.com>
 <WHeiA94XvPpjt99_D5ITQ0M_44V-AJ8rBAjkTqHWxXY=.eaea5682-712c-40ee-8cab-eb8b3afb7027@github.com>
 <hZ8VcJN59gxHCT8CY0BaCJv3t9Mf4087knRSYGlRpuA=.5721d840-ce1d-4105-a30c-82f0e36fa31a@github.com>
Message-ID: <OjjQvuXJOnSub0qsi-cJNNcfBcgxAu5-h__RYuIVJ78=.f30e13b7-7534-4acd-9329-3cc6819e974d@github.com>

On Thu, 5 Jun 2025 13:49:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > Perhaps the JFR event logging code could see if the key implements `NamedX509Key` and then print out the `NamedParameterSpec` constant.
> > 
> > 
> > Or, just use public APIs as
> > ```
> > if (key instanceof AsymmetricKey ak
> >                     && ak.getParams() instanceof NamedParameterSpec nps) {
> >     print(nps.getName());
> > }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > This will print out `Ed25519` and `X448` as well.
> 
> Need @coffeys to weigh in on this. My suggestion is to add that code above in `JCAUtil.tryCommitCertEvent()` so that the key type is set to, for example, "ML-KEM-768" instead of "ML-KEM". Then, I would probably change `EventHelper.logX509CertificateEvent` and when the keysize passed in is -1, instead log "N/A" or some suitable text instead of "-1".

The suggested changes to the Logger part look fine to me. For JFR event itself, `keyLength` is of type int. We'd have to think through the implications of changing this. Perhaps we can have follow on sub-tasks or bugs for the logger and JFR changes. 

The current patch looks good for enabling change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25642#issuecomment-2970662187

From valeriep at openjdk.org  Fri Jun 13 17:36:51 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 13 Jun 2025 17:36:51 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations
Message-ID: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>

Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
"algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.

Tier1 - 3 Mach5 job: https://mach5.us.oracle.com/mdash/jobs/vpeng-jdkOh3-20250613-0441-29515109
JCK javax_crypto and java_security Mach5 job: https://mach5.us.oracle.com/mdash/jobs/vpeng-jdkOh3-20250613-0624-29519811 

Thanks in advance for the review~

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

Commit messages:
 - 8359388: Stricter checking for cipher transformations

Changes: https://git.openjdk.org/jdk/pull/25808/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25808&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359388
  Stats: 87 lines in 2 files changed: 39 ins; 13 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/25808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25808/head:pull/25808

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

From vyazici at openjdk.org  Mon Jun 16 07:29:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 07:29:43 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <0r4lN4voPGXnF1IPlmMGgdyZd54Y4a5GdOsngNbSGlY=.03c9a53f-b044-44d3-affa-4542a7711d8c@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
 <0r4lN4voPGXnF1IPlmMGgdyZd54Y4a5GdOsngNbSGlY=.03c9a53f-b044-44d3-affa-4542a7711d8c@github.com>
Message-ID: <hZ604vk0v1SI0nglx9lAGDH4A0ljfgAZBBxD0fVFfPE=.fd2e67cc-8454-4b00-86ed-7dbc2c18851c@github.com>

On Tue, 3 Jun 2025 20:09:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing `java.io.Reader` import in `Ktab`
>
> I was thinking if someone made a typo for "stdin.encoding" and then it unknowingly defaults to the fallback. Turned out it immediately fails with "java.lang.IllegalArgumentException: Null charset name" so I think it should be OK.

@naotoj, @turbanoff, @wangweij, @plummercj, @AlanBateman, thanks so much for the reviews.

`tier1,2,3` pass ? results are attached to the ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2969879685

From vyazici at openjdk.org  Mon Jun 16 07:29:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 07:29:44 GMT
Subject: Integrated: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <2bZxFXAIgff0dW80SQs1nnYNEarkBmhThnJ4pkmHre4=.de088625-d9ef-442d-9be5-70725a6000f6@github.com>

On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

This pull request has now been integrated.

Changeset: eacfcd86
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eacfcd86d38f4acf0165275a42d246ba6c5fae56
Stats:     130 lines in 11 files changed: 33 ins; 28 del; 69 mod

8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core]

Reviewed-by: naoto, cjplummer

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

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

From fguallini at openjdk.org  Mon Jun 16 09:57:37 2025
From: fguallini at openjdk.org (Fernando Guallini)
Date: Mon, 16 Jun 2025 09:57:37 GMT
Subject: [jdk25] Integrated: 8358171: Additional code coverage for PEM API
In-Reply-To: <zQyHxpXs8nQpAyvJD7bUsgEtrAOQsLwojM6sqVChBDY=.ed8b5255-2c08-486a-9bd3-590f00b432f1@github.com>
References: <zQyHxpXs8nQpAyvJD7bUsgEtrAOQsLwojM6sqVChBDY=.ed8b5255-2c08-486a-9bd3-590f00b432f1@github.com>
Message-ID: <7A_Li-kSEk9P0ZDmYpmdMfkoi8giTJKA6V6YgW7FXXs=.1eb189d7-455a-43ee-b2f7-c2ec994c65a3@github.com>

On Tue, 10 Jun 2025 07:26:54 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b2e7cda6](https://github.com/openjdk/jdk/commit/b2e7cda6a0bd21fa3c4ffe2a67da4953f1ca3f1f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Fernando Guallini on 6 Jun 2025 and was reviewed by Anthony Scarpino.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 2ea2f74f
Author:    Fernando Guallini <fguallini at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ea2f74f9238edd2492c4a9a050d14192f1ed42a
Stats:     535 lines in 10 files changed: 492 ins; 2 del; 41 mod

8358171: Additional code coverage for PEM API

Reviewed-by: rhalade, ascarpino
Backport-of: b2e7cda6a0bd21fa3c4ffe2a67da4953f1ca3f1f

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

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

From myankelevich at openjdk.org  Mon Jun 16 10:38:08 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 16 Jun 2025 10:38:08 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
Message-ID: <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>

> * added an automated mixed case option
> * using multithreading now
> * added logs for simpler debug
> * added missing -Djava.security.auth.debug coverage

Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8357470
 - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
   
   * added an automated mixed case option
   * using multithreading now
   * added logs for simpler debug
   * added missing -Djava.security.auth.debug coverage

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

Changes: https://git.openjdk.org/jdk/pull/25391/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25391&range=01
  Stats: 156 lines in 1 file changed: 131 ins; 5 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25391.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25391/head:pull/25391

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

From myankelevich at openjdk.org  Mon Jun 16 13:52:28 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 16 Jun 2025 13:52:28 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations
In-Reply-To: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
Message-ID: <2OdabS5ivp7ZuM-1BWZBxGgAgqKJStHw19Jq4LPmosk=.f49ccd2d-ba98-427c-b612-ace4077b80dc@github.com>

On Fri, 13 Jun 2025 17:32:12 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
> 
> Tier1 - 3 Mach5 job: https://mach5.us.oracle.com/mdash/jobs/vpeng-jdkOh3-20250613-0441-29515109
> JCK javax_crypto and java_security Mach5 job: https://mach5.us.oracle.com/mdash/jobs/vpeng-jdkOh3-20250613-0624-29519811 
> 
> Thanks in advance for the review~

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

> 346:                 transformation.substring(0, endIdx).trim());
> 347:         if (algo.isEmpty()) {
> 348:             throw new NoSuchAlgorithmException("Invalid transformation: " +

I don't think this exception is tested. It could be by adding `test(" ", provider);` in [test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java](https://github.com/openjdk/jdk/pull/25808/files#diff-5442ba4fbe85af64a99ca3c2d2b5795026be4c40e23af8337d52a64cefd6af35) on line 68

test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 75:

> 73:         try {
> 74:             Cipher c = Cipher.getInstance(transformation, provider);
> 75:             throw new RuntimeException("Expected NSAE not thrown");

Minor: Do you think it would be a good idea to print out `transformation` and `provider` data for debug? In `System.err` that is. Otherwise afaik the exception is thrown and no trace in system error, just in `System.out.println`, making debugging quite challenging 

Just something like this 
```suggestion 
            System.err.println("Error while testing " + transformation);
            throw new RuntimeException("Expected NSAE not thrown");

or just add it to the `RuntimeException` message

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2150062308
PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2149939460

From kdriver at openjdk.org  Mon Jun 16 14:44:31 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 16 Jun 2025 14:44:31 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called
In-Reply-To: <93z474u2QLsNV-KVBLeJIUTYpfShck67iw0wlr6RXm4=.ea5430e4-c1a5-4858-a49b-76c2911c67fc@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
 <OLoWC8G0mCZjRexhtTvVulZt_UYhxrN-cwCR6C2vbyU=.1d2060cb-b539-4185-96fc-4b55c0cd0f5e@github.com>
 <93z474u2QLsNV-KVBLeJIUTYpfShck67iw0wlr6RXm4=.ea5430e4-c1a5-4858-a49b-76c2911c67fc@github.com>
Message-ID: <PVGD3-UGEEmJykdwXWT3vAhPe30L_Kcpgunui4NpglQ=.69e9064d-c9a5-4c47-a736-38e65600eba0@github.com>

On Fri, 6 Jun 2025 21:36:06 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 82:
>> 
>>> 80:     }
>>> 81: 
>>> 82:     public byte[] getEncoded() {
>> 
>> I understand this is not a public API class so there is no need to provide `@throws` in the spec. But, on the other hand, do we need to provide one in its super class `java.security.key`? I have no opinion.
>
> Well, I am not sure. `java.securityKey` is the super interface for all keys, including private, public, and secret keys. The Exception is due to implementing the `javax.security.auth.Destroyable` interface, so the `@throws` spec should goes to the class which implements both `Destroyable` and `Key` interfaces. `PBEKey` is not a public API class, so perhaps we can documenting this in the `SunJCE` provider section as this is implementation-specific?

Also, `PublicKey` does not implement (or implement by inheritance) `Destroyable`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2150187408

From myankelevich at openjdk.org  Mon Jun 16 16:31:31 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 16 Jun 2025 16:31:31 GMT
Subject: RFR: 8359395: XML signature generation does not support user
 provided SecureRandom [v2]
In-Reply-To: <8Eyn71amqqwK75WsELmuwOAvbescRrDFcYfYLfBILVQ=.74b95830-6e4b-431b-a850-6dd86a7b54e4@github.com>
References: <PmnDYLcH8BUUeAWsEGj14s7nMQ57Nv23Cu7O_fEK3eQ=.4d7ee88f-7ea7-4ddc-a384-97d669c52991@github.com>
 <8Eyn71amqqwK75WsELmuwOAvbescRrDFcYfYLfBILVQ=.74b95830-6e4b-431b-a850-6dd86a7b54e4@github.com>
Message-ID: <18Q2KViEgwUIwUI5sgv_8Q2U-3jvjIJ3BAYp5V5fswk=.282c5ade-7f97-4908-8057-62b896e1b342@github.com>

On Fri, 13 Jun 2025 14:37:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> New `XMLSignContext` property to allow user-specific `SecureRandom` for XML signature generation.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

Also copyright

src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMRSAPSSSignatureMethod.java line 33:

> 31: import java.security.Key;
> 32: import java.security.NoSuchAlgorithmException;
> 33: import java.security.PrivateKey;

Do we need a copyright update here and in `DOMSignatureMethod.java`?

test/jdk/javax/xml/crypto/dsig/Properties.java line 34:

> 32: import java.security.Security;
> 33: import java.util.Base64;
> 34: import java.util.logging.*;

Nitpick: this is not needed

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

PR Review: https://git.openjdk.org/jdk/pull/25802#pullrequestreview-2932584212
PR Review Comment: https://git.openjdk.org/jdk/pull/25802#discussion_r2150411773
PR Review Comment: https://git.openjdk.org/jdk/pull/25802#discussion_r2150284518

From weijun at openjdk.org  Mon Jun 16 17:32:12 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 16 Jun 2025 17:32:12 GMT
Subject: RFR: 8359395: XML signature generation does not support user
 provided SecureRandom [v3]
In-Reply-To: <PmnDYLcH8BUUeAWsEGj14s7nMQ57Nv23Cu7O_fEK3eQ=.4d7ee88f-7ea7-4ddc-a384-97d669c52991@github.com>
References: <PmnDYLcH8BUUeAWsEGj14s7nMQ57Nv23Cu7O_fEK3eQ=.4d7ee88f-7ea7-4ddc-a384-97d669c52991@github.com>
Message-ID: <AY0BlRwbiz9ghqLAmSOzcgxHGV5y9TsTUBcgIqeUaSA=.579f22d2-2c5a-477e-9a47-102c261a7438@github.com>

> New `XMLSignContext` property to allow user-specific `SecureRandom` for XML signature generation.

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

  update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25802/files
  - new: https://git.openjdk.org/jdk/pull/25802/files/fcd50edd..56620819

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

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

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

From duke at openjdk.org  Mon Jun 16 17:48:48 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Mon, 16 Jun 2025 17:48:48 GMT
Subject: RFR: 8355379: Annotate lazy fields in java.security @Stable [v2]
In-Reply-To: <BdTzABSl5jaGkV-xByy2FlnE8-JPfLejMQBjRZNLBjY=.b6265489-d61e-4572-a523-93e77be49e0c@github.com>
References: <BdTzABSl5jaGkV-xByy2FlnE8-JPfLejMQBjRZNLBjY=.b6265489-d61e-4572-a523-93e77be49e0c@github.com>
Message-ID: <T6yeTXpf5h9bjVISO2HroBAwaDdBZBKluwM5rRyWYsI=.ab730149-af82-4c46-9b7e-3eafe928921f@github.com>

> Several classes in the `java.security` package lazily compute their hash value and store it in a field. These fields can typically be annotated with the `@Stable` annotation. Many of the current implementations are using -1 as a flag for not computed, this needs to be refactored away.
> 
> Here are some examples of such classes: PKCS12Attribute, Timestamp, Certificate, and URICertStoreParameters.

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

  8355379: Annotate lazy fields in java.security @Stable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25405/files
  - new: https://git.openjdk.org/jdk/pull/25405/files/17778c5f..c2304982

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

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

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

From mullan at openjdk.org  Mon Jun 16 20:15:27 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 16 Jun 2025 20:15:27 GMT
Subject: [jdk25] RFR: 8359170: Add 2 TLS and 2 CS Sectigo roots
In-Reply-To: <U81Rvkd3rCouvQCgHnalznWXhKvi4sAPB9rKeYlWTuE=.8892890f-ec92-4519-a763-f119ea74833b@github.com>
References: <U81Rvkd3rCouvQCgHnalznWXhKvi4sAPB9rKeYlWTuE=.8892890f-ec92-4519-a763-f119ea74833b@github.com>
Message-ID: <AS-JLgLJKpU_rIXRHr-IuzwREqDU99U2OkREYmH8t2Q=.1bf948d8-45e5-4956-9b6c-7735270f0169@github.com>

On Tue, 10 Jun 2025 22:01:44 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [9586817c](https://github.com/openjdk/jdk/commit/9586817cea3f1cad8a49d43e9106e25dafa04765) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 10 Jun 2025 and was reviewed by Sean Mullan.
> 
> Thanks!

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25736#pullrequestreview-2933379644

From mdonovan at openjdk.org  Mon Jun 16 21:10:02 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 16 Jun 2025 21:10:02 GMT
Subject: RFR: 8356897: Update NSS library to 3.111
Message-ID: <AxVjE1tEos6vAhIf8C8zQ6PWh12yCSajWsi6RUvdZFU=.8a08ce9d-d5a2-459b-a9a3-d7d71b38cf5a@github.com>

This PR simply bumps the NSS version to 3.111

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

Commit messages:
 - 8356897: Update NSS library to 3.111

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

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

From valeriep at openjdk.org  Mon Jun 16 21:34:29 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 16 Jun 2025 21:34:29 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations
In-Reply-To: <2OdabS5ivp7ZuM-1BWZBxGgAgqKJStHw19Jq4LPmosk=.f49ccd2d-ba98-427c-b612-ace4077b80dc@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <2OdabS5ivp7ZuM-1BWZBxGgAgqKJStHw19Jq4LPmosk=.f49ccd2d-ba98-427c-b612-ace4077b80dc@github.com>
Message-ID: <G-ol2jjhtzldLHK6BroQ1d83KdJ_nirG-BGDFvJoWro=.626009af-303a-429c-a6cb-a321256aa793@github.com>

On Mon, 16 Jun 2025 13:49:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
>> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
>> 
>> 
>> Thanks in advance for the review~
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 348:
> 
>> 346:                 transformation.substring(0, endIdx).trim());
>> 347:         if (algo.isEmpty()) {
>> 348:             throw new NoSuchAlgorithmException("Invalid transformation: " +
> 
> I don't think this exception is tested. It could be by adding `test(" ", provider);` in [test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java](https://github.com/openjdk/jdk/pull/25808/files#diff-5442ba4fbe85af64a99ca3c2d2b5795026be4c40e23af8337d52a64cefd6af35) on line 68

Sure, I can add it.

> test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 75:
> 
>> 73:         try {
>> 74:             Cipher c = Cipher.getInstance(transformation, provider);
>> 75:             throw new RuntimeException("Expected NSAE not thrown");
> 
> Minor: Do you think it would be a good idea to print out `transformation` and `provider` data for debug? In `System.err` that is. Otherwise afaik the exception is thrown and no trace in system error, just in `System.out.println`, making debugging quite challenging 
> 
> Just something like this 
> ```suggestion 
>             System.err.println("Error while testing " + transformation);
>             throw new RuntimeException("Expected NSAE not thrown");
> 
> or just add it to the `RuntimeException` message

Ok, I will update the test to include the `transformation` info in the exception message. As for `provider`, it's somewhat related, but given that it stays the same for the test, I printed it out just once in the beginning of the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2150929140
PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2150927529

From valeriep at openjdk.org  Mon Jun 16 22:20:10 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 16 Jun 2025 22:20:10 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v2]
In-Reply-To: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
Message-ID: <CRApdkjoWuf6SvjFbISbouVbusI56r1yvnVR9S-wOv0=.04197c49-5a57-4390-b570-f4148110754d@github.com>

> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
> 
> 
> Thanks in advance for the review~

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

  Updated test per Mikhail's review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25808/files
  - new: https://git.openjdk.org/jdk/pull/25808/files/245bf361..8d8640c6

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

  Stats: 39 lines in 1 file changed: 9 ins; 8 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25808/head:pull/25808

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

From rhalade at openjdk.org  Tue Jun 17 06:13:37 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 17 Jun 2025 06:13:37 GMT
Subject: [jdk25] Integrated: 8359170: Add 2 TLS and 2 CS Sectigo roots
In-Reply-To: <U81Rvkd3rCouvQCgHnalznWXhKvi4sAPB9rKeYlWTuE=.8892890f-ec92-4519-a763-f119ea74833b@github.com>
References: <U81Rvkd3rCouvQCgHnalznWXhKvi4sAPB9rKeYlWTuE=.8892890f-ec92-4519-a763-f119ea74833b@github.com>
Message-ID: <nRBJII7y5xFiZZDYHHuwrykXRpm_5ZLPw6SeeKnSM0w=.69fdb64f-35f2-49dc-8f9c-cbe0f82accf8@github.com>

On Tue, 10 Jun 2025 22:01:44 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [9586817c](https://github.com/openjdk/jdk/commit/9586817cea3f1cad8a49d43e9106e25dafa04765) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Rajan Halade on 10 Jun 2025 and was reviewed by Sean Mullan.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ae71782e
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae71782e77113797f9d0a2244757c47896d2a213
Stats:     479 lines in 7 files changed: 475 ins; 0 del; 4 mod

8359170: Add 2 TLS and 2 CS Sectigo roots

Reviewed-by: mullan
Backport-of: 9586817cea3f1cad8a49d43e9106e25dafa04765

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

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

From myankelevich at openjdk.org  Tue Jun 17 10:34:29 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 17 Jun 2025 10:34:29 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v2]
In-Reply-To: <CRApdkjoWuf6SvjFbISbouVbusI56r1yvnVR9S-wOv0=.04197c49-5a57-4390-b570-f4148110754d@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <CRApdkjoWuf6SvjFbISbouVbusI56r1yvnVR9S-wOv0=.04197c49-5a57-4390-b570-f4148110754d@github.com>
Message-ID: <DTr1YUtBNpiTwRPWPM-SIfKnSRmbAsKiyWcjRbjaUFM=.575ef157-e959-4fa8-b684-4d6fa76f797a@github.com>

On Mon, 16 Jun 2025 22:20:10 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
>> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
>> 
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test per Mikhail's review comments.

Thank you for your changes!

Just a few super minor questions

test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 30:

> 28:  * @summary test that the Cipher.getInstance() would reject improper
> 29:  *     transformations with empty mode and/or padding.
> 30:  * @run main TestEmptyModePadding

minor: Is `@run` needed here? It's fine to leave it here, if you prefer it this way though.

test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 37:

> 35: import javax.crypto.*;
> 36: 
> 37: public class TestEmptyModePadding {

Could you please change the imports to not use wildcard imports



import java.security.NoSuchAlgorithmException;
import java.security.Provider;
import java.security.Security;
import javax.crypto.Cipher;

test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 45:

> 43:         System.out.println("Testing against " + provider.getName());
> 44: 
> 45:         String[] testTransformations = {

minor: Do you think it would be easier to read if each entry was a separate line?

test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 69:

> 67:         for (String t : testTransformations) {
> 68:             test(t, provider);
> 69:         };

nit, `;` after for loop

Suggestion:

        }

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

PR Review: https://git.openjdk.org/jdk/pull/25808#pullrequestreview-2935056506
PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2151902251
PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2151902337
PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2151906412
PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2151894079

From myankelevich at openjdk.org  Tue Jun 17 10:34:30 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 17 Jun 2025 10:34:30 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v2]
In-Reply-To: <G-ol2jjhtzldLHK6BroQ1d83KdJ_nirG-BGDFvJoWro=.626009af-303a-429c-a6cb-a321256aa793@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <2OdabS5ivp7ZuM-1BWZBxGgAgqKJStHw19Jq4LPmosk=.f49ccd2d-ba98-427c-b612-ace4077b80dc@github.com>
 <G-ol2jjhtzldLHK6BroQ1d83KdJ_nirG-BGDFvJoWro=.626009af-303a-429c-a6cb-a321256aa793@github.com>
Message-ID: <I6xG5WzV_ifeFqtItXQWwvUgK3J9op5p735IXJ3_lc4=.b2540c7b-6d12-44c9-8643-bafb3ca68479@github.com>

On Mon, 16 Jun 2025 21:32:16 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/Cipher.java line 348:
>> 
>>> 346:                 transformation.substring(0, endIdx).trim());
>>> 347:         if (algo.isEmpty()) {
>>> 348:             throw new NoSuchAlgorithmException("Invalid transformation: " +
>> 
>> I don't think this exception is tested. It could be by adding `test(" ", provider);` in [test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java](https://github.com/openjdk/jdk/pull/25808/files#diff-5442ba4fbe85af64a99ca3c2d2b5795026be4c40e23af8337d52a64cefd6af35) on line 68
>
> Sure, I can add it.

Thank you! This is covered now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2151921175

From myankelevich at openjdk.org  Tue Jun 17 13:11:29 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 17 Jun 2025 13:11:29 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v3]
In-Reply-To: <TnWloajWzELKJAzASpdMn4-aSHmLwFuOp3gGFRB7snE=.7705403b-145d-4aa0-bdd8-6e230b69ecb2@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
 <TnWloajWzELKJAzASpdMn4-aSHmLwFuOp3gGFRB7snE=.7705403b-145d-4aa0-bdd8-6e230b69ecb2@github.com>
Message-ID: <VzXhaI5J3oG1N8Ji2k4OrfZAFGVYU9zHH9gs13o16ig=.6b9369d9-8e71-45a7-a951-ebf85f831e29@github.com>

On Thu, 5 Jun 2025 01:26:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enhance test to be exhaustive

src/java.base/share/classes/sun/security/util/KeyUtil.java line 150:

> 148:                     && ak.getParams() instanceof NamedParameterSpec nps)
> 149:                 ? nps.getName()
> 150:                 : k.getAlgorithm();

This case is not covered. Could you please add something like this test? it should cover the case when this is false `k instanceof AsymmetricKey ak && ak.getParams() instanceof NamedParameterSpec nps`


    static void testDummyKey() throws Exception {

        Key key = new Key() {
            @Override
            public String getAlgorithm() {
                return "";
            }

            @Override
            public String getFormat() {
                return "";
            }

            @Override
            public byte[] getEncoded() {
                return new byte[0];
            }
        };

        Asserts.assertEQ(-1, KeyUtil.getNistCategory(key));
    }
``` 
and `testDummyKey();` on line 52 of course.

test/jdk/sun/security/provider/all/NistCategories.java line 46:

> 44:         for (var p : Security.getProviders()) {
> 45:             for (var s : p.getServices()) {
> 46:                 switch (s.getType()) {

Minor: why not just this? I don't mind, just asking


 for (var p : Security.getProviders()) {
            for (var s : p.getServices()) {
                if ("KeyPairGenerator".equals(s.getType())) {
                    test(s);
                }
            }
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2152233592
PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2152056476

From weijun at openjdk.org  Tue Jun 17 13:51:18 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Jun 2025 13:51:18 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v4]
In-Reply-To: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
Message-ID: <fj2GIFDOYcyApnvNIO3PBjjBl-cFqqvxe6zQajm53QA=.719f5eb2-8ac4-4eae-9a8a-ea63bed8b8f3@github.com>

> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.

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

 - enhance test
 - a doc fix elsewhere

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25642/files
  - new: https://git.openjdk.org/jdk/pull/25642/files/5ec95fb2..9e1a257c

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

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

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

From weijun at openjdk.org  Tue Jun 17 13:56:16 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Jun 2025 13:56:16 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v5]
In-Reply-To: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
Message-ID: <D7QJxWfcbUtaejqDNBn3chJAOXlJFpwVXtO0vdTYu2s=.81fbc86b-5236-4714-9b6c-e1a2b5917069@github.com>

> Add more comment on why `KeyUtil::getKeySize` could return -1. Add a new method `getNistCategory` to get the NIST security category.

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

  switch to if

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25642/files
  - new: https://git.openjdk.org/jdk/pull/25642/files/9e1a257c..8ec639e7

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

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

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

From weijun at openjdk.org  Tue Jun 17 13:56:17 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 17 Jun 2025 13:56:17 GMT
Subject: RFR: 8358594: Misleading keyLength value captured in JFR event for
 ML-KEM key [v3]
In-Reply-To: <VzXhaI5J3oG1N8Ji2k4OrfZAFGVYU9zHH9gs13o16ig=.6b9369d9-8e71-45a7-a951-ebf85f831e29@github.com>
References: <_0c4B3uJE9t3J6chBeUg8yDhX4tlJyhhqR_KhFnYglA=.792f129a-59e2-4620-afe1-0103b677f653@github.com>
 <TnWloajWzELKJAzASpdMn4-aSHmLwFuOp3gGFRB7snE=.7705403b-145d-4aa0-bdd8-6e230b69ecb2@github.com>
 <VzXhaI5J3oG1N8Ji2k4OrfZAFGVYU9zHH9gs13o16ig=.6b9369d9-8e71-45a7-a951-ebf85f831e29@github.com>
Message-ID: <WNpnHn21yFPYA0_xZ0FFADkIyHpJZKQpMEic0RqQI_E=.a2491c0f-be2b-4d3f-95fe-e7a5d5e4604a@github.com>

On Tue, 17 Jun 2025 13:08:24 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   enhance test to be exhaustive
>
> src/java.base/share/classes/sun/security/util/KeyUtil.java line 150:
> 
>> 148:                     && ak.getParams() instanceof NamedParameterSpec nps)
>> 149:                 ? nps.getName()
>> 150:                 : k.getAlgorithm();
> 
> This case is not covered. Could you please add something like this test? it should cover the case when this is false `k instanceof AsymmetricKey ak && ak.getParams() instanceof NamedParameterSpec nps`
> 
> 
>     static void testDummyKey() throws Exception {
> 
>         Key key = new Key() {
>             @Override
>             public String getAlgorithm() {
>                 return "";
>             }
> 
>             @Override
>             public String getFormat() {
>                 return "";
>             }
> 
>             @Override
>             public byte[] getEncoded() {
>                 return new byte[0];
>             }
>         };
> 
>         Asserts.assertEQ(-1, KeyUtil.getNistCategory(key));
>     }
> ``` 
> and `testDummyKey();` on line 52 of course.

Added a test case on `SecretKey`, which is not an `AsymmetricKey`.

> test/jdk/sun/security/provider/all/NistCategories.java line 46:
> 
>> 44:         for (var p : Security.getProviders()) {
>> 45:             for (var s : p.getServices()) {
>> 46:                 switch (s.getType()) {
> 
> Minor: why not just this? I don't mind, just asking
> 
> 
>  for (var p : Security.getProviders()) {
>             for (var s : p.getServices()) {
>                 if ("KeyPairGenerator".equals(s.getType())) {
>                     test(s);
>                 }
>             }
>         }

Oh, you're right it's not worth a switch. I might have just copied the same structure from another test where there can be different actions on more than 1 type. I'll change it. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2152342047
PR Review Comment: https://git.openjdk.org/jdk/pull/25642#discussion_r2152335707

From rhalade at openjdk.org  Tue Jun 17 16:38:29 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 17 Jun 2025 16:38:29 GMT
Subject: RFR: 8356897: Update NSS library to 3.111
In-Reply-To: <AxVjE1tEos6vAhIf8C8zQ6PWh12yCSajWsi6RUvdZFU=.8a08ce9d-d5a2-459b-a9a3-d7d71b38cf5a@github.com>
References: <AxVjE1tEos6vAhIf8C8zQ6PWh12yCSajWsi6RUvdZFU=.8a08ce9d-d5a2-459b-a9a3-d7d71b38cf5a@github.com>
Message-ID: <YzkuDmueh4IRqBZnlDr7jhIyZy5NuhjCU1ewsTREdqA=.209f3eaa-180a-4f22-bfe7-5cd0093cd268@github.com>

On Fri, 13 Jun 2025 17:14:46 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR simply bumps the NSS version to 3.111

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25807#pullrequestreview-2936367529

From naoto at openjdk.org  Tue Jun 17 20:37:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jun 2025 20:37:04 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
Message-ID: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>

Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

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

Commit messages:
 - Several more locations
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25860/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25860&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359732
  Stats: 69 lines in 13 files changed: 50 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25860/head:pull/25860

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

From achung at openjdk.org  Tue Jun 17 23:11:15 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:11:15 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
Message-ID: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>

This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

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

Commit messages:
 - empty commit
 - redo ws fixes, add manual changes

Changes: https://git.openjdk.org/jdk/pull/25839/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359761
  Stats: 1574 lines in 76 files changed: 810 ins; 93 del; 671 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

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

From achung at openjdk.org  Tue Jun 17 23:18:27 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:18:27 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <-07gTVUiE_k1Kfc5m2OgDlX6fj1hUMYWZqsSK2YFlYc=.0fc07185-3be2-4f7c-b24f-fca061924170@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

whitespace changes are fixed, PR is ready for review

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2982077742

From jlu at openjdk.org  Tue Jun 17 23:18:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:18:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 2:

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

Same as my comment in `src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java`

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26:

> 24: #
> 25: 
> 26: main.usage=Verwendung: jdeprscan [Optionen] ''{dir|jar|class}'' ...\n\nOptionen:\n        --class-path PATH\n        --for-removal\n        --full-version\n  -? -h --help\n  -l    --list\n        --release {0}\n  -v    --verbose\n        --version

Extra quotes, applies to other localized versions as well. (Usual change we revert)

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:

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

Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314389
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153313105
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314152

From jlu at openjdk.org  Tue Jun 17 23:24:28 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:24:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <41BnI9ePFiQiYk_COU-Rrpz0qzr33GN0p9AfF38Fkmk=.0d9c1020-d538-41b2-a939-f7e296029ae0@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 30:

> 28: STARNN=*******************************************\n\n
> 29: # keytool: Help part
> 30: .OPTION.=\ [OPTION]...

We spoke about this offline. This is fine, property file values need to either start with a `\ `or `\u0020` to denote intentional leading white space. In this case, since we convert to UTF-8 native characters from escape sequences this gets included as well. Functionally, they are equivalent and the new form works well with the translation process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153321343

From achung at openjdk.org  Tue Jun 17 23:34:52 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:34:52 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  fix unicode escapes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/2dfac379..d8027691

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

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

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

From almatvee at openjdk.org  Tue Jun 17 23:43:28 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 17 Jun 2025 23:43:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <uLYnpuvdWyGcO615myaP0lHZ9HMiX9Ag27OnViwh5Ik=.cb34bbec-542b-40a6-98ab-270e2b63bcae@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

jdk.jpackage changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2937331933

From naoto at openjdk.org  Wed Jun 18 01:56:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 01:56:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:

> 1: #

Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153463170

From valeriep at openjdk.org  Wed Jun 18 03:38:31 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 18 Jun 2025 03:38:31 GMT
Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid
 include/includedir directives after sections [v2]
In-Reply-To: <O3w8ZcaxDdfeCLE-OufVFFGKdGEZ4VD43cV1xtvSflA=.d7ae7a03-5540-4319-a689-3dd848c487d0@github.com>
References: <J7Mfx9UGyrmn54abJmZEZO32FwbJIKhMAiU4UxTo6ek=.b495100e-79a6-469d-8128-11c86a9e6829@github.com>
 <O3w8ZcaxDdfeCLE-OufVFFGKdGEZ4VD43cV1xtvSflA=.d7ae7a03-5540-4319-a689-3dd848c487d0@github.com>
Message-ID: <ml-FbedqmGOTlXl9rfp3VXrHRO-QlYQUQGBppRrFmzg=.d6b883dc-d178-4acf-91a2-037113f193cb@github.com>

On Wed, 28 May 2025 15:25:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Several changes are made:
>> 
>> 1. The "include" and "includedir" directives can appear everywhere, even inside a section or a sub-section. However, it only means the content is inserted here but the included file still need its own full structure -- from section to subsections.
>> 2. The same file can be included multiple times as long as not recursively.
>> 3. Everything is merged. For duplicated values, `get` returns the first one and `getAll` returns all joining by spaces.
>> 
>> Two new tests added. I also separately confirmed that they are parsed in the same way as [MIT krb5](https://github.com/krb5/krb5/blob/master/src/util/profile/test_parse.c). MIT krb5 ignores directory name after "include" but here it's an error.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more random testing

src/java.security.jgss/share/classes/sun/security/krb5/Config.java line 608:

> 606:             // Already parsed. This is allowed.
> 607:             return;
> 608:         }

Should this block of code be moved up before the line of `dups = new HashSet<>(dups);`?

src/java.security.jgss/share/classes/sun/security/krb5/Config.java line 678:

> 676:         Path fullp = Paths.get(fileName).toAbsolutePath();
> 677:         Path path = Paths.get(fileName);
> 678:         if (!Files.exists(path)) {

Is `path` needed? Can't you just use `fullp` for the `!Files.exists()` check?

src/java.security.jgss/share/classes/sun/security/krb5/Config.java line 818:

> 816:      *
> 817:      * @param entry path to config file, could be an included one
> 818:      * @returns the parsed configuration

This method is changed to return void, why add this `@returns` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25421#discussion_r2153443893
PR Review Comment: https://git.openjdk.org/jdk/pull/25421#discussion_r2153220437
PR Review Comment: https://git.openjdk.org/jdk/pull/25421#discussion_r2153115117

From valeriep at openjdk.org  Wed Jun 18 06:17:50 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 18 Jun 2025 06:17:50 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v3]
In-Reply-To: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
Message-ID: <W6ddER9qDncudD68Dz6hdxQUAUod4qsUL0uoSanvl00=.6265917e-5491-432b-9242-caf91a8d3a97@github.com>

> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
> 
> 
> Thanks in advance for the review~

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

  remove the extra ";" as suggested
  
  Co-authored-by: Mikhail Yankelevich <mikhailyankelevich at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25808/files
  - new: https://git.openjdk.org/jdk/pull/25808/files/8d8640c6..0cb41982

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

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

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

From valeriep at openjdk.org  Wed Jun 18 06:17:51 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 18 Jun 2025 06:17:51 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v2]
In-Reply-To: <DTr1YUtBNpiTwRPWPM-SIfKnSRmbAsKiyWcjRbjaUFM=.575ef157-e959-4fa8-b684-4d6fa76f797a@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <CRApdkjoWuf6SvjFbISbouVbusI56r1yvnVR9S-wOv0=.04197c49-5a57-4390-b570-f4148110754d@github.com>
 <DTr1YUtBNpiTwRPWPM-SIfKnSRmbAsKiyWcjRbjaUFM=.575ef157-e959-4fa8-b684-4d6fa76f797a@github.com>
Message-ID: <ijacjsoEMtTjURX2ATheEDIp5URz03IiybTYtX2n1Dk=.b2f645ec-db9b-4cb8-92c7-337e78fde1bf@github.com>

On Tue, 17 Jun 2025 10:21:42 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test per Mikhail's review comments.
>
> test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 37:
> 
>> 35: import javax.crypto.*;
>> 36: 
>> 37: public class TestEmptyModePadding {
> 
> Could you please change the imports to not use wildcard imports
> 
> 
> 
> import java.security.NoSuchAlgorithmException;
> import java.security.Provider;
> import java.security.Security;
> import javax.crypto.Cipher;

Sure, I can do this.

> test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 45:
> 
>> 43:         System.out.println("Testing against " + provider.getName());
>> 44: 
>> 45:         String[] testTransformations = {
> 
> minor: Do you think it would be easier to read if each entry was a separate line?

I am ok either way, sounds like you prefer one line per entry. I can change them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2153729356
PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2153731933

From valeriep at openjdk.org  Wed Jun 18 06:22:30 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 18 Jun 2025 06:22:30 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v2]
In-Reply-To: <DTr1YUtBNpiTwRPWPM-SIfKnSRmbAsKiyWcjRbjaUFM=.575ef157-e959-4fa8-b684-4d6fa76f797a@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
 <CRApdkjoWuf6SvjFbISbouVbusI56r1yvnVR9S-wOv0=.04197c49-5a57-4390-b570-f4148110754d@github.com>
 <DTr1YUtBNpiTwRPWPM-SIfKnSRmbAsKiyWcjRbjaUFM=.575ef157-e959-4fa8-b684-4d6fa76f797a@github.com>
Message-ID: <IiaXOGcuXS5t5SFGKmlFxYGCTuI7rFmCd_2S5jiXgbI=.18178d07-571e-44c2-ae7b-ca4931eb02ed@github.com>

On Tue, 17 Jun 2025 10:21:40 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test per Mikhail's review comments.
>
> test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java line 30:
> 
>> 28:  * @summary test that the Cipher.getInstance() would reject improper
>> 29:  *     transformations with empty mode and/or padding.
>> 30:  * @run main TestEmptyModePadding
> 
> minor: Is `@run` needed here? It's fine to leave it here, if you prefer it this way though.

I am ok either way, just didn't bother to remove it from the original test. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25808#discussion_r2153738427

From valeriep at openjdk.org  Wed Jun 18 06:27:13 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 18 Jun 2025 06:27:13 GMT
Subject: RFR: 8359388: Stricter checking for cipher transformations [v4]
In-Reply-To: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
References: <WEyL3mnDoAtdFEC07ujbXWxGPENgQy3H2QiSwgwFCtI=.c300a128-24f0-4a57-95fa-cc1aa0e573a1@github.com>
Message-ID: <csaGYiAvuo8piw9ApqbvyR0evzMIVDrwvyjXndwW8IE=.1fee2f3c-00f0-439b-aa80-6b68bf7cd16a@github.com>

> Based on the javadoc of `javax.crypto.Cipher` class, the cipher transformation should be either "algorithm/mode/padding" or
> "algorithm". When parsing the transformation, space(s) is trimmed off and empty strings are considered as "unspecified". This PR adds checks to ensure that transformations with empty "mode" and/or "padding" value in the "algorithm/mode/padding" form leads to `NoSuchAlgorithmException`. This reverts some changes made in [https://bugs.openjdk.org/browse/JDK-8358159](https://bugs.openjdk.org/browse/JDK-8358159) which allows empty mode and/or padding in the transformations.
> 
> 
> Thanks in advance for the review~

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

  Updated test per 2nd round of Mikhail's review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25808/files
  - new: https://git.openjdk.org/jdk/pull/25808/files/0cb41982..7d9e36b8

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

  Stats: 12 lines in 1 file changed: 6 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25808/head:pull/25808

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

From vyazici at openjdk.org  Wed Jun 18 07:10:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 18 Jun 2025 07:10:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <cyKIsynr19VsmvHUmvEFP9RP56GFxojjJVQezBM41lg=.1aea0985-9284-43b7-8537-6a46149de0fd@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

I've verified that all relevant occurrences of `std{in,err,out}.encoding` are covered, except the ones `src/java.base/share/classes/java/lang/System.java`, which, I presume, is left out intentionally.

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2937989243

From alanb at openjdk.org  Wed Jun 18 07:55:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:55:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

src/java.base/share/classes/module-info.java line 287:

> 285:         jdk.jpackage,
> 286:         jdk.jshell,
> 287:         jdk.net;

At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 111:

> 109: 
> 110: 
> 111:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jhsdb tool, just wondering why it needs to be changed.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 802:

> 800:         }
> 801:         try {
> 802:             Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the example jdb debugger, I assume okay to let it read the stdin.encoding property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153907749
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153910478
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153913162

From alanb at openjdk.org  Wed Jun 18 07:59:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:59:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <HS_moiW1ZXnwCePhJrtlJTtiwO37FEHMKxldVBPgDcw=.d649f3bf-3ce2-44d9-bc5c-9ed5f74b333d@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

src/java.scripting/share/classes/javax/script/SimpleScriptContext.java line 100:

> 98: 
> 99:     private static InputStreamReader stdinReader() {
> 100:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jrunscript command line tool. I suppose it's possible it could run a script that changes stdin.encoding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153921907

From nbenalla at openjdk.org  Wed Jun 18 09:08:29 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Jun 2025 09:08:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <xcSAVqLxI2phW8UCEHcDpUMeFySiy0zigXx-MPkt5aU=.0c203d6f-60e1-41d1-82d5-a93bba898f5f@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

I'm unable to confirm the accuracy of the translations, since I don't speak the target languages. I've only reviewed the `jdk.javadoc` sources.

All keys in the English property files match one-to-one with those in the non-English files: there are no missing or extra entries. The only changes are to the `.properties` files, exactly as the PR title suggests.

>From the `jdk.javadoc` perspective, this looks good, so I'm happy to approve this PR.

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

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2938377311

From jsikstro at openjdk.org  Wed Jun 18 09:50:30 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 18 Jun 2025 09:50:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2983504760

From mdonovan at openjdk.org  Wed Jun 18 11:27:31 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 18 Jun 2025 11:27:31 GMT
Subject: Integrated: 8356897: Update NSS library to 3.111
In-Reply-To: <AxVjE1tEos6vAhIf8C8zQ6PWh12yCSajWsi6RUvdZFU=.8a08ce9d-d5a2-459b-a9a3-d7d71b38cf5a@github.com>
References: <AxVjE1tEos6vAhIf8C8zQ6PWh12yCSajWsi6RUvdZFU=.8a08ce9d-d5a2-459b-a9a3-d7d71b38cf5a@github.com>
Message-ID: <I64af6W4dE0vqyNQ-TaU-yuPt77_dKrHWyMMhe2gmz4=.8cc70248-fa04-492d-b506-b4f5fdf0eae0@github.com>

On Fri, 13 Jun 2025 17:14:46 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR simply bumps the NSS version to 3.111

This pull request has now been integrated.

Changeset: cabd7c1f
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cabd7c1f7a8c471d5461e3557fb589fdfe4d88be
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8356897: Update NSS library to 3.111

Reviewed-by: rhalade

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

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

From rriggs at openjdk.org  Wed Jun 18 15:08:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <LbRBF6gknL_SsjFh_wALuLuFGTOFzDNYTUikL7MbvA8=.f0b9e433-da69-4280-9a3d-9150dfaa1b80@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Static properties should not be used outside of java.base.
The "for internal use only" should have said "java.base internal use only"
Adding a comment to that effect would be a good idea.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2939624079

From rriggs at openjdk.org  Wed Jun 18 15:08:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:30 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
Message-ID: <0gpDp3XapnEa-4BfqTDt7AAHV7_qDLoKHy3-2xzJ7ro=.faa1279d-82a8-4a68-a026-94f325f904e7@github.com>

On Wed, 18 Jun 2025 07:50:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> src/java.base/share/classes/module-info.java line 287:
> 
>> 285:         jdk.jpackage,
>> 286:         jdk.jshell,
>> 287:         jdk.net;
> 
> At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

The original intent of StaticProperties was to limit it to the base module.
Other modules are free to read the property themselves.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2154852609

From abarashev at openjdk.org  Wed Jun 18 15:54:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 15:54:48 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v6]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <dorxSmvEaQ5Fq0qWV_hC5VLd5UCLO7UvcL2IGGiyA_s=.cefc093a-035c-462c-84a3-f6511b221cd1@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

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

  Add more unit tests. Some code refactoring and adjustments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/448442e9..eaf343ad

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

  Stats: 171 lines in 5 files changed: 106 ins; 36 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From aivanov at openjdk.org  Wed Jun 18 16:15:35 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:15:35 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:

> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.

Shall the copyright year be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:

> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
> 459: SliderDemo.majorticks=Grobteilungen
> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen

Should the translation of `SliderDemo.majorticks` also be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:

> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
> 462: SliderDemo.minorticks=Feinteilungen

The following description uses different words now:

Feinteilungen -> Teilstrichen
Teilungen -> Teilstrichen

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:

> 181: size.bit.alg=%1$d-Bit-%2$s
> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}

It feels as if there's something missing after _?einem?_.

src/java.base/share/classes/sun/security/util/resources/security_de.properties line 46:

> 44: invalid.null.action.provided=Ung?ltige Nullaktion angegeben
> 45: invalid.null.Class.provided=Ung?ltige Nullklasse angegeben
> 46: Subject.=Subject:\n

Is it correct? German usually uses `k`.

src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:

> 54: 
> 55: # javax.security.auth.login.AppConfigurationEntry
> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020

Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

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

> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:

Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229:

> 227: doclet.search_in_documentation=In Dokumentation suchen
> 228: doclet.search_reset=Zur?cksetzen
> 229: doclet.Member=Member

Is `Member` translated? Should it be _?Mitglied?_?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154931256
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154807291
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154813672
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154907979
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154905960
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154915395
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154968902
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154985100

From jlu at openjdk.org  Wed Jun 18 16:24:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:24:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <epU16E3XQ7BNcECTdZbJJpdFw05jYxEZ8Kt1yRx34nY=.a5624636-51ea-4466-83c2-6e0f7aa6aca1@github.com>

On Wed, 18 Jun 2025 15:28:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
> 
>> 54: 
>> 55: # javax.security.auth.login.AppConfigurationEntry
>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
> 
> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155032074

From jlu at openjdk.org  Wed Jun 18 16:28:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:28:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>

On Wed, 18 Jun 2025 15:34:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
> 
>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Shall the copyright year be updated?

In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155038247

From aivanov at openjdk.org  Wed Jun 18 16:45:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:45:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
Message-ID: <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>

On Wed, 18 Jun 2025 16:25:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
>> 
>>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> Shall the copyright year be updated?
>
> In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

This is weird? Usually, the copyright year is bumped up whenever the file is edited.

>> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
>> 
>>> 54: 
>>> 55: # javax.security.auth.login.AppConfigurationEntry
>>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
>> 
>> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.
>
> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

Thank you for clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071387
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071915

From naoto at openjdk.org  Wed Jun 18 16:58:34 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 16:58:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
Message-ID: <GMreFXOIVIHSDY6c8Vcze6uvKnnsOAaNIH6G5rBfkQA=.507f3521-b8a6-4024-a1ed-d41f71a9c1e1@github.com>

On Wed, 18 Jun 2025 09:47:57 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

Those languages (de/ja/zh-CN) are the ones we (Oracle) support. Other entities would be welcome to provide l10n for other languages (not a sporadic l10n, but commit to update/maintain).

> 
> Edit: I see that the other localizations haven't been updated for the last few releases, so maybe this is intentional. Still interested to know why we have the other localizations if they aren't updated.

Usuallly l10n resource updates are additions, so those old l10ns still have values for those languages. New additions will simply fall back to English.

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2985038815

From naoto at openjdk.org  Wed Jun 18 18:01:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 18:01:24 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v2]
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <agXiLTe_M1yttluXMMT9poQdr_hJmr-nghlR5bccgMI=.badaf025-60d0-474f-8ddb-b8d18e2af33b@github.com>

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25860/files
  - new: https://git.openjdk.org/jdk/pull/25860/files/9d1dbf3a..c5c93387

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

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

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

From naoto at openjdk.org  Wed Jun 18 18:01:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 18:01:25 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v2]
In-Reply-To: <0gpDp3XapnEa-4BfqTDt7AAHV7_qDLoKHy3-2xzJ7ro=.faa1279d-82a8-4a68-a026-94f325f904e7@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
 <0gpDp3XapnEa-4BfqTDt7AAHV7_qDLoKHy3-2xzJ7ro=.faa1279d-82a8-4a68-a026-94f325f904e7@github.com>
Message-ID: <0wpPbk27NF8jkG1A3Za6Txg7WYCbCZwMS8WlyWIx4ZM=.f58e6a1a-70ab-4513-89ea-6e02ba69fac9@github.com>

On Wed, 18 Jun 2025 15:03:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/module-info.java line 287:
>> 
>>> 285:         jdk.jpackage,
>>> 286:         jdk.jshell,
>>> 287:         jdk.net;
>> 
>> At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.
>
> The original intent of StaticProperties was to limit it to the base module.
> Other modules are free to read the property themselves.

Thanks, Alan and Roger. Limited the modification within the `java.base` module.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2155190046

From naoto at openjdk.org  Wed Jun 18 18:24:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 18:24:43 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v3]
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <gTvwrNT5Dldji_dh947tl1S8TM3YRAyAqNfAShdA0_c=.1854389c-926d-4d8a-83da-0a73dc11853f@github.com>

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Replaces a couple more

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25860/files
  - new: https://git.openjdk.org/jdk/pull/25860/files/c5c93387..278628b0

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

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

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

From naoto at openjdk.org  Wed Jun 18 18:24:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 18:24:43 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v3]
In-Reply-To: <cyKIsynr19VsmvHUmvEFP9RP56GFxojjJVQezBM41lg=.1aea0985-9284-43b7-8537-6a46149de0fd@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <cyKIsynr19VsmvHUmvEFP9RP56GFxojjJVQezBM41lg=.1aea0985-9284-43b7-8537-6a46149de0fd@github.com>
Message-ID: <VBgmWliUGCLfIt2pyF9Nka7AWZsoLjigjAk7JGRgmDM=.c009cd74-61f6-4e79-84a3-8dd5103476c5@github.com>

On Wed, 18 Jun 2025 07:08:21 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> I've verified that all relevant occurrences of `std{in,err,out}.encoding` are covered, except the ones `src/java.base/share/classes/java/lang/System.java`, which, I presume, is left out intentionally.

Initially I left them as it is too early to call, but just noticed StaticProperty class was initialized a few lines above, so it is safe to call them. Replaced.

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

PR Comment: https://git.openjdk.org/jdk/pull/25860#issuecomment-2985288682

From achung at openjdk.org  Wed Jun 18 18:42:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 18 Jun 2025 18:42:54 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <3Sb_Nj53MtMZRoKypbBFn0yumsFtiGJzY5fv60CilwA=.4ee9201b-0657-484b-8e69-01306c131b39@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  remove double quotes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/d8027691..66c34e7d

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

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

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

From mullan at openjdk.org  Wed Jun 18 18:46:37 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 18 Jun 2025 18:46:37 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <r4AMd_4-pjf_PHIYI36I3WHc6FvcI2-bSGldzvhkGFg=.ed24ea21-3860-4d2d-81ea-16c00ced5959@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
 <r4AMd_4-pjf_PHIYI36I3WHc6FvcI2-bSGldzvhkGFg=.ed24ea21-3860-4d2d-81ea-16c00ced5959@github.com>
Message-ID: <TGSM3KuPzvC_wVIKIfXMO8MeOfUZUhMCLF6Y5U3tyOQ=.5f8ffa6d-c3ce-49f8-bea0-89e457bd3e21@github.com>

On Fri, 6 Jun 2025 16:19:07 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:
>> 
>>> 1: /*
>> 
>> I am trying to figure out when the algorithm constraints are enabled, why the key isn't being selected. I don't see anywhere that you are setting the algorithm constraints property.
>> 
>> Please add some more comments explaining how the exception case occurs.
>
> Hi @seanjmullan! This PR fixes both JDK-8353113 and JDK-8170706. So we have 2 new unit tests, one for each issue:
> 
> 1. `AlgorithmConstraintsCheck`: tests JDK-8170706. BTW, I'm going to update the `@bug` tag in this test to `8170706`
> 2. `PeerConstraintsCheck`: tests JDK-8353113. No need to set any algorithm constraints because we test against the peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions. I'll add a comment to this test with the explanation.

I see. You also have a 3rd: JDK-8359069. It's rare to see one PR fix multiple issues, even though skara supports it. I'm not sure I see specific advantages of having three separate issues instead of just one. Is it primarily because you see these as separate issues? In that case, does it make sense to fix this as 3 different issues in case one or more them needs to be selectively backported?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2155264743

From dnguyen at openjdk.org  Wed Jun 18 18:50:29 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 18 Jun 2025 18:50:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
Message-ID: <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>

On Tue, 17 Jun 2025 23:15:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove double quotes
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

Is there any way to prevent this or do we just change it back when we do a drop and explain why each time?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155272483

From prr at openjdk.org  Wed Jun 18 20:40:29 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Jun 2025 20:40:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>

On Wed, 18 Jun 2025 14:45:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:
> 
>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
>> 459: SliderDemo.majorticks=Grobteilungen
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 
> Should the translation of `SliderDemo.majorticks` also be updated?

I agree. I'd expect consistency here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155451453

From abarashev at openjdk.org  Wed Jun 18 20:46:28 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 20:46:28 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v4]
In-Reply-To: <TGSM3KuPzvC_wVIKIfXMO8MeOfUZUhMCLF6Y5U3tyOQ=.5f8ffa6d-c3ce-49f8-bea0-89e457bd3e21@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
 <r4AMd_4-pjf_PHIYI36I3WHc6FvcI2-bSGldzvhkGFg=.ed24ea21-3860-4d2d-81ea-16c00ced5959@github.com>
 <TGSM3KuPzvC_wVIKIfXMO8MeOfUZUhMCLF6Y5U3tyOQ=.5f8ffa6d-c3ce-49f8-bea0-89e457bd3e21@github.com>
Message-ID: <0VHE4ir0u_0NE9nLwjsxU8l77tbCpMagmlVA5iSa8Gw=.62daacaf-52dc-4a01-b8f1-e33e52f4fa4b@github.com>

On Wed, 18 Jun 2025 18:43:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hi @seanjmullan! This PR fixes both JDK-8353113 and JDK-8170706. So we have 2 new unit tests, one for each issue:
>> 
>> 1. `AlgorithmConstraintsCheck`: tests JDK-8170706. BTW, I'm going to update the `@bug` tag in this test to `8170706`
>> 2. `PeerConstraintsCheck`: tests JDK-8353113. No need to set any algorithm constraints because we test against the peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions. I'll add a comment to this test with the explanation.
>
> I see. You also have a 3rd: JDK-8359069. It's rare to see one PR fix multiple issues, even though skara supports it. I'm not sure I see specific advantages of having three separate issues instead of just one. Is it primarily because you see these as separate issues? In that case, does it make sense to fix this as 3 different issues in case one or more them needs to be selectively backported?

Done: all 3 issues have been combined into one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2155459746

From abarashev at openjdk.org  Wed Jun 18 20:55:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 20:55:13 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v7]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <CItvJMHc5QSFnWkhWptSLmaOycUv-ygTvq-HGQC9WoM=.81959bcc-efe8-4c74-a3a1-80f2e7172002@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

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

  Make certificate checking toggle specific to SunX509. Update issue number.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/eaf343ad..45a4a48e

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

  Stats: 65 lines in 9 files changed: 18 ins; 6 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From abarashev at openjdk.org  Wed Jun 18 20:55:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 20:55:13 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v3]
In-Reply-To: <6zkY8S4cVr4HOiWkQlXuh3Vu0QXWzyB-buNY2_Wvpl0=.81e0a04e-a82f-4e46-82c1-88cb40d9603e@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
 <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>
 <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>
 <6zkY8S4cVr4HOiWkQlXuh3Vu0QXWzyB-buNY2_Wvpl0=.81e0a04e-a82f-4e46-82c1-88cb40d9603e@github.com>
Message-ID: <17Zm2X-YP4mMtlLIz4htH2qSpaUwEeqJpnS4yRq0UAI=.6af8d9ba-f831-4011-8677-ef9c00391a17@github.com>

On Fri, 6 Jun 2025 20:01:17 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> > > > It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).
> > > 
> > > 
> > > @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it to be disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this.
> > > @seanjmullan What do you think?
> > 
> > 
> > Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced.
> 
> I'd agree. As I mentioned in my earlier comment, if the new system property ends up toggling behavior in both `SunX509KeyManager` and `X509KeyManagerImpl`, we could run into an unintended side effect. While we're adding compliant algorithm constraints checking to `SunX509KeyManager`, turning on the property to disable it for compatibility reasons would also disable the already-existing checking in `X509KeyManagerImpl`. The applications already relying on the stricter checks in `X509KeyManagerImpl` might lose that enforcement unintentionally.

I made the toggle specific to SunX509 Key Manager as suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2985653083

From abarashev at openjdk.org  Wed Jun 18 21:12:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 21:12:51 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v8]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <xmD6zFsXfHAK3xD8Jkl2uuaJPCredOd91ZdzfiKiHek=.6c0fef48-48a7-4f86-822b-15d8a423b695@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

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

  Remove a couple of empty lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/45a4a48e..bcef7346

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

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

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

From abarashev at openjdk.org  Wed Jun 18 21:35:47 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 21:35:47 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v9]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

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

  Update system property name in one more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/bcef7346..a83ea8bd

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

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

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

From weijun at openjdk.org  Wed Jun 18 22:19:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 18 Jun 2025 22:19:30 GMT
Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid
 include/includedir directives after sections [v2]
In-Reply-To: <ml-FbedqmGOTlXl9rfp3VXrHRO-QlYQUQGBppRrFmzg=.d6b883dc-d178-4acf-91a2-037113f193cb@github.com>
References: <J7Mfx9UGyrmn54abJmZEZO32FwbJIKhMAiU4UxTo6ek=.b495100e-79a6-469d-8128-11c86a9e6829@github.com>
 <O3w8ZcaxDdfeCLE-OufVFFGKdGEZ4VD43cV1xtvSflA=.d7ae7a03-5540-4319-a689-3dd848c487d0@github.com>
 <ml-FbedqmGOTlXl9rfp3VXrHRO-QlYQUQGBppRrFmzg=.d6b883dc-d178-4acf-91a2-037113f193cb@github.com>
Message-ID: <AYBEGexk-_zZx6Wpu6i71NSQ5NqC1D5x8ELx9_D-CUw=.a7b39cad-0b67-4f91-9942-4bbdd10d0e85@github.com>

On Tue, 17 Jun 2025 21:43:06 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more random testing
>
> src/java.security.jgss/share/classes/sun/security/krb5/Config.java line 678:
> 
>> 676:         Path fullp = Paths.get(fileName).toAbsolutePath();
>> 677:         Path path = Paths.get(fileName);
>> 678:         if (!Files.exists(path)) {
> 
> Is `path` needed? Can't you just use `fullp` for the `!Files.exists()` check?

You're right. I'll remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25421#discussion_r2155596225

From weijun at openjdk.org  Wed Jun 18 23:56:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 18 Jun 2025 23:56:30 GMT
Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid
 include/includedir directives after sections [v2]
In-Reply-To: <ml-FbedqmGOTlXl9rfp3VXrHRO-QlYQUQGBppRrFmzg=.d6b883dc-d178-4acf-91a2-037113f193cb@github.com>
References: <J7Mfx9UGyrmn54abJmZEZO32FwbJIKhMAiU4UxTo6ek=.b495100e-79a6-469d-8128-11c86a9e6829@github.com>
 <O3w8ZcaxDdfeCLE-OufVFFGKdGEZ4VD43cV1xtvSflA=.d7ae7a03-5540-4319-a689-3dd848c487d0@github.com>
 <ml-FbedqmGOTlXl9rfp3VXrHRO-QlYQUQGBppRrFmzg=.d6b883dc-d178-4acf-91a2-037113f193cb@github.com>
Message-ID: <b2b1vA51Ado8c38DvFydmU9f3J9Yml8ENTPnkbJLIgM=.78ee3022-0fd3-408f-b04a-591fcfb1b5a8@github.com>

On Wed, 18 Jun 2025 01:28:52 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more random testing
>
> src/java.security.jgss/share/classes/sun/security/krb5/Config.java line 608:
> 
>> 606:             // Already parsed. This is allowed.
>> 607:             return;
>> 608:         }
> 
> Should this block of code be moved up before the line of `dups = new HashSet<>(dups);`?

That would allow a file to recursively include itself.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25421#discussion_r2155733258

From duke at openjdk.org  Wed Jun 18 23:58:33 2025
From: duke at openjdk.org (duke)
Date: Wed, 18 Jun 2025 23:58:33 GMT
Subject: Withdrawn: 8350710: Add GlobalSign Code Signing Root R45
In-Reply-To: <GnlmaD4FWNKxJT2Yw6UIlaANgevKbb6QjUYJi3cT4YQ=.b6148633-3a39-4de0-ae10-68956cdb04cf@github.com>
References: <GnlmaD4FWNKxJT2Yw6UIlaANgevKbb6QjUYJi3cT4YQ=.b6148633-3a39-4de0-ae10-68956cdb04cf@github.com>
Message-ID: <Oqf9fNZgt0UBx2sIGCioQFc1XW25aNMXTkvs7l7auS0=.757eec27-601f-4fd1-bacb-61c38b03f86c@github.com>

On Wed, 26 Feb 2025 18:02:38 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add new GlobalSign Code Signing Root R45. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> 
> The release-note is at [JDK-8350805](https://bugs.openjdk.org/browse/JDK-8350805)

This pull request has been closed without being integrated.

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

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

From weijun at openjdk.org  Thu Jun 19 00:03:05 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 19 Jun 2025 00:03:05 GMT
Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid
 include/includedir directives after sections [v3]
In-Reply-To: <J7Mfx9UGyrmn54abJmZEZO32FwbJIKhMAiU4UxTo6ek=.b495100e-79a6-469d-8128-11c86a9e6829@github.com>
References: <J7Mfx9UGyrmn54abJmZEZO32FwbJIKhMAiU4UxTo6ek=.b495100e-79a6-469d-8128-11c86a9e6829@github.com>
Message-ID: <WDY9FXEaGvt3grkX74dAn_8nWg78wRl2v3wQ_AHSFbM=.68625fab-e903-45e6-b9d9-a86b1c110d9b@github.com>

> Several changes are made:
> 
> 1. The "include" and "includedir" directives can appear everywhere, even inside a section or a sub-section. However, it only means the content is inserted here but the included file still need its own full structure -- from section to subsections.
> 2. The same file can be included multiple times as long as not recursively.
> 3. Everything is merged. For duplicated values, `get` returns the first one and `getAll` returns all joining by spaces.
> 
> Two new tests added. I also separately confirmed that they are parsed in the same way as [MIT krb5](https://github.com/krb5/krb5/blob/master/src/util/profile/test_parse.c). MIT krb5 ignores directory name after "include" but here it's an error.

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

  valerie comments; one more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25421/files
  - new: https://git.openjdk.org/jdk/pull/25421/files/dfabb82a..6964c158

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

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

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

From valeriep at openjdk.org  Thu Jun 19 01:48:37 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 19 Jun 2025 01:48:37 GMT
Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid
 include/includedir directives after sections [v2]
In-Reply-To: <b2b1vA51Ado8c38DvFydmU9f3J9Yml8ENTPnkbJLIgM=.78ee3022-0fd3-408f-b04a-591fcfb1b5a8@github.com>
References: <J7Mfx9UGyrmn54abJmZEZO32FwbJIKhMAiU4UxTo6ek=.b495100e-79a6-469d-8128-11c86a9e6829@github.com>
 <O3w8ZcaxDdfeCLE-OufVFFGKdGEZ4VD43cV1xtvSflA=.d7ae7a03-5540-4319-a689-3dd848c487d0@github.com>
 <ml-FbedqmGOTlXl9rfp3VXrHRO-QlYQUQGBppRrFmzg=.d6b883dc-d178-4acf-91a2-037113f193cb@github.com>
 <b2b1vA51Ado8c38DvFydmU9f3J9Yml8ENTPnkbJLIgM=.78ee3022-0fd3-408f-b04a-591fcfb1b5a8@github.com>
Message-ID: <Cy95mnnlOLgAda5qX3TViEr_FhH0vwiKZoZHtOwCV-A=.5abba802-9750-4ef1-8d81-29c052234e4b@github.com>

On Wed, 18 Jun 2025 23:53:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/sun/security/krb5/Config.java line 608:
>> 
>>> 606:             // Already parsed. This is allowed.
>>> 607:             return;
>>> 608:         }
>> 
>> Should this block of code be moved up before the line of `dups = new HashSet<>(dups);`?
>
> That would allow a file to recursively include itself.

I see. Would be nice to add a comment about this, so others are aware of this also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25421#discussion_r2155848853

From alanb at openjdk.org  Thu Jun 19 11:08:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Jun 2025 11:08:04 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v3]
In-Reply-To: <gTvwrNT5Dldji_dh947tl1S8TM3YRAyAqNfAShdA0_c=.1854389c-926d-4d8a-83da-0a73dc11853f@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <gTvwrNT5Dldji_dh947tl1S8TM3YRAyAqNfAShdA0_c=.1854389c-926d-4d8a-83da-0a73dc11853f@github.com>
Message-ID: <eGqGLsVpzdsqe5Vx1Umti4nNEerLW0SyF_xURDpAUy4=.734106e3-4862-43c5-8eaa-e6d5d93b98d4@github.com>

On Wed, 18 Jun 2025 18:24:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaces a couple more

Latest version looks okay but I think better to drop the change to System.initPhase1.

src/java.base/share/classes/java/lang/System.java line 1820:

> 1818:         // of those properties default to native.encoding
> 1819:         setOut0(newPrintStream(fdOut, StaticProperty.stdoutEncoding()));
> 1820:         initialErr = newPrintStream(fdErr, StaticProperty.stderrEncoding());

This is initPhase1 where we've just saved the initial properties. I think it would be better to not change this. It would be okay to use tempProps here too, but I think clearer as is.

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

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2942535422
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2156732745

From duke at openjdk.org  Thu Jun 19 17:42:30 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 19 Jun 2025 17:42:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>

On Wed, 18 Jun 2025 15:25:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:
> 
>> 181: size.bit.alg=%1$d-Bit-%2$s
>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}
> 
> It feels as if there's something missing after _?einem?_.

seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2157444024

From abarashev at openjdk.org  Fri Jun 20 13:42:36 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 20 Jun 2025 13:42:36 GMT
Subject: Withdrawn: 8272875: Change the default key manager to PKIX
In-Reply-To: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
Message-ID: <mrHG6zoCSxEes_4_GRKlqRujjCNJ0J0afs1A_92m_V8=.995e657a-70ff-4b79-bbee-ee77ed2d3c6f@github.com>

On Fri, 18 Apr 2025 17:04:56 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
> 
> Compatibility considerations:
> 
> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
> 
> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
> 
> **SUNX509**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> Finished running test 'micro:java.security.SSLHandshake'
> 
> **PKIX**
> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
> Finished running test 'micro:java.security.SSLHandshake'

This pull request has been closed without being integrated.

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

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

From mullan at openjdk.org  Fri Jun 20 14:06:30 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 20 Jun 2025 14:06:30 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v9]
In-Reply-To: <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
Message-ID: <Nj_wsnpaRUsX_01s9rQzjBx-uFjRjMX5Q8VRQ6gW4Wg=.0a058d5a-698a-4d5b-ad53-ff9e2a56fa9f@github.com>

On Wed, 18 Jun 2025 21:35:47 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update system property name in one more test

test/jdk/sun/security/mscapi/ShortRSAKeyWithinTLS.java line 238:

> 236:         // Disable KeyManager's algorithm constraints checking.
> 237:         System.setProperty(
> 238:                 "jdk.tls.SunX509keymanager.certSelectionChecking", "false");

What if you instead just removed "RSA keySize < 1024" from the `jdk.certpath.disabledAlgorithms` security property - would this test still pass? This way you could still test the other parts of the cert selection code.

This same comment applies to other tests where you have set the `jdk.tls.SunX509keymanager.certSelectionChecking` property to false.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2159064375

From rriggs at openjdk.org  Fri Jun 20 14:24:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Jun 2025 14:24:29 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v3]
In-Reply-To: <gTvwrNT5Dldji_dh947tl1S8TM3YRAyAqNfAShdA0_c=.1854389c-926d-4d8a-83da-0a73dc11853f@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <gTvwrNT5Dldji_dh947tl1S8TM3YRAyAqNfAShdA0_c=.1854389c-926d-4d8a-83da-0a73dc11853f@github.com>
Message-ID: <hg7KPKDUY_ko2jBEUqA_qPiPezi8tpwsa68I8hKInpw=.d23a69e9-548d-41b7-8e33-f5ca17c4f64d@github.com>

On Wed, 18 Jun 2025 18:24:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaces a couple more

lgtm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2946358383

From myankelevich at openjdk.org  Fri Jun 20 15:35:20 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 20 Jun 2025 15:35:20 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests [v4]
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: <_xRmVX0XkV14HVGo6QMGHO_-St6OBAmdW0C6TqemeRs=.eab623c6-27bd-4c01-9f90-f817d6a184b7@github.com>

> 8351566: Consolidate third party artifacts used in tests

Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into JDK-8351566
 - Fernando's comments:
   
   * cleanup
 - minor: imports fix
 - 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=03
  Stats: 363 lines in 5 files changed: 225 ins; 129 del; 9 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  Fri Jun 20 15:38:42 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 20 Jun 2025 15:38:42 GMT
Subject: RFR: 8351566: Consolidate third party artifacts used in tests [v5]
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: <X5pr0BiMXP7DGtoNm28YKmgiq4yFGLr07QL4_L86qQI=.2f7cc75e-80e7-4fd5-b9dd-9d55b58a9382@github.com>

> 8351566: Consolidate third party artifacts used in tests

Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into JDK-8351566
 - updated nss version
 - Merge branch 'master' into JDK-8351566
 - Fernando's comments:
   
   * cleanup
 - minor: imports fix
 - 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=04
  Stats: 363 lines in 5 files changed: 225 ins; 129 del; 9 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 mullan at openjdk.org  Fri Jun 20 17:46:29 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 20 Jun 2025 17:46:29 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v9]
In-Reply-To: <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
Message-ID: <yn66u1uUdFex4WBoWkdsYDgCKEn_daa5tWyyo0a5AXc=.0301c6ca-e2bc-4520-bd26-8373e6b059d7@github.com>

On Wed, 18 Jun 2025 21:35:47 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update system property name in one more test

Please create a CSR for the new system property.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2992372380

From abarashev at openjdk.org  Fri Jun 20 18:01:35 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 20 Jun 2025 18:01:35 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v9]
In-Reply-To: <Nj_wsnpaRUsX_01s9rQzjBx-uFjRjMX5Q8VRQ6gW4Wg=.0a058d5a-698a-4d5b-ad53-ff9e2a56fa9f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
 <Nj_wsnpaRUsX_01s9rQzjBx-uFjRjMX5Q8VRQ6gW4Wg=.0a058d5a-698a-4d5b-ad53-ff9e2a56fa9f@github.com>
Message-ID: <WEq9BBuYe8Xwfw8JWjKYT8UXtQMl4bIlWuN79RDFSVQ=.bb8c35f6-3cf9-4f62-89ab-6aeb4b02c92f@github.com>

On Fri, 20 Jun 2025 13:58:24 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 system property name in one more test
>
> test/jdk/sun/security/mscapi/ShortRSAKeyWithinTLS.java line 238:
> 
>> 236:         // Disable KeyManager's algorithm constraints checking.
>> 237:         System.setProperty(
>> 238:                 "jdk.tls.SunX509keymanager.certSelectionChecking", "false");
> 
> What if you instead just removed "RSA keySize < 1024" from the `jdk.certpath.disabledAlgorithms` security property - would this test still pass? This way you could still test the other parts of the cert selection code.
> 
> This same comment applies to other tests where you have set the `jdk.tls.SunX509keymanager.certSelectionChecking` property to false.

Done, good point! It works for this particular test but the same approach doesn't work for other tests because they either rely on TrustManager do the constraints checks or MD5 algorithm being blocks by TLSv1.3 spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2159457776

From abarashev at openjdk.org  Fri Jun 20 18:07:12 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 20 Jun 2025 18:07:12 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v10]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <ycKcCQF-z6xYt06nl3sc1RPlZdzUGDsVf8_E09nEd80=.821aa0e5-00c8-41c2-8579-e9b8d214628d@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

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

  Update unit tests. Some code refactoring.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/a83ea8bd..c5e381ec

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

  Stats: 184 lines in 5 files changed: 90 ins; 87 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From naoto at openjdk.org  Fri Jun 20 18:44:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 20 Jun 2025 18:44:47 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v4]
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <gSUOCunP7JQS2mZyGTGtcdO1ZID0r5rcw6drRxOzuOg=.6f94780c-e47f-4f2a-8cb8-29c1184ac4f4@github.com>

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments. Limits the usage of StaticProperty within java.base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25860/files
  - new: https://git.openjdk.org/jdk/pull/25860/files/278628b0..0a3684b7

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

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

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

From naoto at openjdk.org  Fri Jun 20 18:48:28 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 20 Jun 2025 18:48:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v3]
In-Reply-To: <eGqGLsVpzdsqe5Vx1Umti4nNEerLW0SyF_xURDpAUy4=.734106e3-4862-43c5-8eaa-e6d5d93b98d4@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <gTvwrNT5Dldji_dh947tl1S8TM3YRAyAqNfAShdA0_c=.1854389c-926d-4d8a-83da-0a73dc11853f@github.com>
 <eGqGLsVpzdsqe5Vx1Umti4nNEerLW0SyF_xURDpAUy4=.734106e3-4862-43c5-8eaa-e6d5d93b98d4@github.com>
Message-ID: <RbQ-npSAV56SMdEWzFzHbQdgVC2zDpdWW9BC0OFUDrw=.fa3ab1bf-cc0b-402d-b2ef-365b940c8ed6@github.com>

On Thu, 19 Jun 2025 11:03:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Latest version looks okay but I think better to drop the change to System.initPhase1.

Reverted the changes in the `System` class. Also, there were two sites that used `StaticProperty` class outside the `java.base` module. I replaced them with the equivalent `System.getProperty()` calls.

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

PR Comment: https://git.openjdk.org/jdk/pull/25860#issuecomment-2992523310

From rriggs at openjdk.org  Fri Jun 20 20:09:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Jun 2025 20:09:29 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v4]
In-Reply-To: <gSUOCunP7JQS2mZyGTGtcdO1ZID0r5rcw6drRxOzuOg=.6f94780c-e47f-4f2a-8cb8-29c1184ac4f4@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <gSUOCunP7JQS2mZyGTGtcdO1ZID0r5rcw6drRxOzuOg=.6f94780c-e47f-4f2a-8cb8-29c1184ac4f4@github.com>
Message-ID: <8L4kz0Wd4CvQVfWlyI1lImzWg_XVsbFRZdk7D0fj0gM=.083fbfc1-3d88-4e00-92c1-3dbdb10971cb@github.com>

On Fri, 20 Jun 2025 18:44:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments. Limits the usage of StaticProperty within java.base

The updates look fine.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2947181128

From alanb at openjdk.org  Sat Jun 21 06:13:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Jun 2025 06:13:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v4]
In-Reply-To: <gSUOCunP7JQS2mZyGTGtcdO1ZID0r5rcw6drRxOzuOg=.6f94780c-e47f-4f2a-8cb8-29c1184ac4f4@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <gSUOCunP7JQS2mZyGTGtcdO1ZID0r5rcw6drRxOzuOg=.6f94780c-e47f-4f2a-8cb8-29c1184ac4f4@github.com>
Message-ID: <M-_Q-oD5cab3XatLm4SWTSsfhnmLYp-KIlgf9vP_IqA=.336c2e6d-a4e1-4d7e-9149-2ab796daaac2@github.com>

On Fri, 20 Jun 2025 18:44:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments. Limits the usage of StaticProperty within java.base

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2947592845

From duke at openjdk.org  Sat Jun 21 23:10:32 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 21 Jun 2025 23:10:32 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
Message-ID: <Tt7SHMyu0C1IodP0H--t1D724UkMCL06c0tCbMX42UE=.18600e64-bc3f-48fd-8b43-b2c9337de9b9@github.com>

On Mon, 16 Jun 2025 10:38:08 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8357470
>  - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
>    
>    * added an automated mixed case option
>    * using multithreading now
>    * added logs for simpler debug
>    * added missing -Djava.security.auth.debug coverage

test/jdk/sun/security/util/Debug/DebugOptions.java line 214:

> 212:             final List<Future<Void>> res = executorService.invokeAll(testsCallables);
> 213:             for (final Future<Void> future : res) {
> 214:                 future.get();

future.get() could throw an unchecked exception. Can we consider logging which test failed and why?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2160175672

From duke at openjdk.org  Sat Jun 21 23:18:30 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 21 Jun 2025 23:18:30 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
Message-ID: <q98KAuB9EgliS3qCOlqXmTklVvkolQNC-JUGaNL26L4=.9ab8eb04-5fde-4538-b710-fcceb694ba48@github.com>

On Mon, 16 Jun 2025 10:38:08 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8357470
>  - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
>    
>    * added an automated mixed case option
>    * using multithreading now
>    * added logs for simpler debug
>    * added missing -Djava.security.auth.debug coverage

test/jdk/sun/security/util/Debug/DebugOptions.java line 207:

> 205:                     return null;
> 206:                 });
> 207: 

Can we add a test to explicitly test something like this for testParameter("-Djava.security.debug=", "all", EXPECTED_ALL_REGEX, "not expected") and testMixedCaseParameter("-Djava.security.debug=", "AlL", EXPECTED_ALL_REGEX, "not expected") ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2160176695

From duke at openjdk.org  Sat Jun 21 23:21:30 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 21 Jun 2025 23:21:30 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
Message-ID: <HSqAgKiWy4P7zPjzuyAEHXIVWmAQvwJ-bLgicUDXP6Y=.05b04773-878b-44a3-9124-fded3a7ad6da@github.com>

On Mon, 16 Jun 2025 10:38:08 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8357470
>  - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
>    
>    * added an automated mixed case option
>    * using multithreading now
>    * added logs for simpler debug
>    * added missing -Djava.security.auth.debug coverage

test/jdk/sun/security/util/Debug/DebugOptions.java line 208:

> 206:                 });
> 207: 
> 208:                 System.out.println("option added to all tests " + Arrays.toString(params));

Optional: consider labeling the log output to make test parameters easier to read when scanning test output

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2160176975

From duke at openjdk.org  Sat Jun 21 23:34:29 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 21 Jun 2025 23:34:29 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
Message-ID: <tnBymC4th2L_yEdpH0RKKNZ-5XUN4kim8n0A5DaxxwU=.894f3164-061e-4028-892e-1bfa31b7511d@github.com>

On Mon, 16 Jun 2025 10:38:08 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8357470
>  - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
>    
>    * added an automated mixed case option
>    * using multithreading now
>    * added logs for simpler debug
>    * added missing -Djava.security.auth.debug coverage

test/jdk/sun/security/util/Debug/DebugOptions.java line 174:

> 172: 
> 173:             patternMatches.forEach(params -> {
> 174:                 testsCallables.add(() -> {

Can we consider adding negative tests with invalid/malformed parameters like null, empty strings, unknown keywords, etc?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2160178940

From duke at openjdk.org  Sat Jun 21 23:43:30 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sat, 21 Jun 2025 23:43:30 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
Message-ID: <DPval-gpok-C1_CFSge8MvWSvAVrmUz2j7azed3Qo54=.fecb3ce0-4581-412c-8820-ef4c0818e0e3@github.com>

On Mon, 16 Jun 2025 10:38:08 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8357470
>  - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
>    
>    * added an automated mixed case option
>    * using multithreading now
>    * added logs for simpler debug
>    * added missing -Djava.security.auth.debug coverage

test/jdk/sun/security/util/Debug/DebugOptions.java line 153:

> 151:      */
> 152:     private String makeFirstAndLastLetterUppercase(final String paramString) {
> 153:         final int length = paramString.length();

Edge Case : Can we check for null or empty before this ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2160180124

From weijun at openjdk.org  Sun Jun 22 02:30:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 22 Jun 2025 02:30:53 GMT
Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid
 include/includedir directives after sections [v4]
In-Reply-To: <J7Mfx9UGyrmn54abJmZEZO32FwbJIKhMAiU4UxTo6ek=.b495100e-79a6-469d-8128-11c86a9e6829@github.com>
References: <J7Mfx9UGyrmn54abJmZEZO32FwbJIKhMAiU4UxTo6ek=.b495100e-79a6-469d-8128-11c86a9e6829@github.com>
Message-ID: <f8-Xdfm8TUPcMVGOIwPg5e5xiWqBZt_w01WQev27j-Q=.825211cb-1d1c-46f6-b9b3-577e9fe1ce32@github.com>

> Several changes are made:
> 
> 1. The "include" and "includedir" directives can appear everywhere, even inside a section or a sub-section. However, it only means the content is inserted here but the included file still need its own full structure -- from section to subsections.
> 2. The same file can be included multiple times as long as not recursively.
> 3. Everything is merged. For duplicated values, `get` returns the first one and `getAll` returns all joining by spaces.
> 
> Two new tests added. I also separately confirmed that they are parsed in the same way as [MIT krb5](https://github.com/krb5/krb5/blob/master/src/util/profile/test_parse.c). MIT krb5 ignores directory name after "include" but here it's an error.

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

  another test; no dups clone
  
  interdiff impossible; taking evasive action
  reverted:

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25421/files
  - new: https://git.openjdk.org/jdk/pull/25421/files/6964c158..d40a221e

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

  Stats: 90 lines in 2 files changed: 40 ins; 19 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/25421.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25421/head:pull/25421

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

From duke at openjdk.org  Sun Jun 22 17:23:32 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Sun, 22 Jun 2025 17:23:32 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
Message-ID: <AEOtlOrH3Ei8WoYJdhHcv2eoKNobNYGF2wgrGKhYrPs=.80e98f42-c948-446a-9d18-0b00549426bb@github.com>

On Mon, 16 Jun 2025 10:38:08 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8357470
>  - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
>    
>    * added an automated mixed case option
>    * using multithreading now
>    * added logs for simpler debug
>    * added missing -Djava.security.auth.debug coverage

test/jdk/sun/security/util/Debug/DebugOptions.java line 152:

> 150:      * @return resulting string
> 151:      */
> 152:     private String makeFirstAndLastLetterUppercase(final String paramString) {

If the goal is to test case-insensitive parsing comprehensively, this method should be expanded to test various case combinations (e.g., all-uppercase, alternating case, etc). Otherwise, document this limitation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2160410307

From henryjen at openjdk.org  Mon Jun 23 07:34:32 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 23 Jun 2025 07:34:32 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
Message-ID: <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>

On Wed, 18 Jun 2025 01:51:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:
> 
>> 1: #
> 
> Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.

I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
If that was intentionally left out, I don't see new reason to add them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2160914804

From coffeys at openjdk.org  Mon Jun 23 12:39:12 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 23 Jun 2025 12:39:12 GMT
Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages
Message-ID: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com>

SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode)

SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode.

Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()`

DebugPropertyValuesTest also updated to test new logic.

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

Commit messages:
 - 8343395

Changes: https://git.openjdk.org/jdk/pull/25934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25934&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343395
  Stats: 28 lines in 2 files changed: 7 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25934/head:pull/25934

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

From sean.mullan at oracle.com  Mon Jun 23 13:29:09 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 23 Jun 2025 09:29:09 -0400
Subject: Result: New Security Group Member: Martin Balao
Message-ID: <4983e8f5-c34d-4c48-83b1-aa59295cbdbd@oracle.com>

The vote for Martin Balao [1] is now closed.

Yes: 3
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
  to approve the nomination.

Sean Mullan

[1] https://mail.openjdk.org/pipermail/security-dev/2025-June/046521.html

From abarashev at openjdk.org  Mon Jun 23 14:08:05 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 23 Jun 2025 14:08:05 GMT
Subject: RFR: 8156715: TrustStoreManager does not buffer keystore input stream
Message-ID: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>

Wrap the FileInputStream into a BufferedInputStream which reduces the number of actual file reads when loading a key store.

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

Commit messages:
 - 8156715: TrustStoreManager does not buffer keystore input stream

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

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

From jlu at openjdk.org  Mon Jun 23 14:45:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 14:45:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
 <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>
Message-ID: <BVN8gdSxc54F_PWYYXyMoHt4FDCeFNtN_vMeMSxIGoI=.beedc45e-7447-4e77-9553-ad1420bc512e@github.com>

On Wed, 18 Jun 2025 18:48:04 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.
>> 
>> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.
>
> Is there any way to prevent this or do we just change it back when we do a drop and explain why each time?

If this is committed, then the years will be synced and we won't have to change it back. This would be consistent with the way we receive l10n translations which sync the copyright years of localized files to the original. 

If we want to deviate from this then we could file a request asking them to not update copyright years and we could update them ourselves.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161805058

From jlu at openjdk.org  Mon Jun 23 14:57:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 14:57:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>

On Wed, 18 Jun 2025 15:52:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:
> 
>> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
>> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
>> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:
> 
> Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.

I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161832785

From jlu at openjdk.org  Mon Jun 23 15:00:37 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 15:00:37 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <M5xHiXsy_RXNKRklp3u-Rc0JJiVmUyKDAdZgTmURWbo=.3c8874b7-ffda-4ffe-910f-381607b78e29@github.com>

On Wed, 18 Jun 2025 15:59:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229:
> 
>> 227: doclet.search_in_documentation=In Dokumentation suchen
>> 228: doclet.search_reset=Zur?cksetzen
>> 229: doclet.Member=Member
> 
> Is `Member` translated? Should it be _?Mitglied?_?

Good catch. Usually, we file these issues with the translation team and make the appropriate updates in the second L10n drop. I think this one is fine to be updated now as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161839290

From naoto at openjdk.org  Mon Jun 23 16:19:36 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Jun 2025 16:19:36 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty` [v4]
In-Reply-To: <gSUOCunP7JQS2mZyGTGtcdO1ZID0r5rcw6drRxOzuOg=.6f94780c-e47f-4f2a-8cb8-29c1184ac4f4@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <gSUOCunP7JQS2mZyGTGtcdO1ZID0r5rcw6drRxOzuOg=.6f94780c-e47f-4f2a-8cb8-29c1184ac4f4@github.com>
Message-ID: <jPzu5EZIaai3cfzMfqkd3x_ESpQWMGZh9QKh5GdKzzM=.4e9f3dc7-f405-4cce-8078-8691b491b058@github.com>

On Fri, 20 Jun 2025 18:44:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments. Limits the usage of StaticProperty within java.base

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25860#issuecomment-2997091425

From naoto at openjdk.org  Mon Jun 23 16:19:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Jun 2025 16:19:37 GMT
Subject: Integrated: 8359732: Make standard i/o encoding related system
 properties `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <1vaVoItIvoC18IPMZDQxkEnaCy8HtlHzDXZtkp8k52s=.afd842c0-9520-4ad6-acd9-e45a271cc89a@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

This pull request has now been integrated.

Changeset: 9c3eaa49
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c3eaa49f7f8c6ade7319064566c0370e955f631
Stats:     51 lines in 7 files changed: 34 ins; 2 del; 15 mod

8359732: Make standard i/o encoding related system properties `StaticProperty`

Reviewed-by: rriggs, alanb, vyazici

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

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

From achung at openjdk.org  Mon Jun 23 16:38:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>

On Wed, 18 Jun 2025 14:48:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:
> 
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
>> 462: SliderDemo.minorticks=Feinteilungen
> 
> The following description uses different words now:
> 
> Feinteilungen -> Teilstrichen
> Teilungen -> Teilstrichen

Just to clarify, does this mean

SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels
SliderDemo.minorticks=Teilstrichen

is correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162030543

From achung at openjdk.org  Mon Jun 23 16:38:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
 <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
Message-ID: <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>

On Mon, 23 Jun 2025 07:31:34 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:
>> 
>>> 1: #
>> 
>> Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.
>
> I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
> If that was intentionally left out, I don't see new reason to add them.

This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162024606

From achung at openjdk.org  Mon Jun 23 16:38:29 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
Message-ID: <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>

On Wed, 18 Jun 2025 20:37:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:
>> 
>>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
>>> 459: SliderDemo.majorticks=Grobteilungen
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 
>> Should the translation of `SliderDemo.majorticks` also be updated?
>
> I agree. I'd expect consistency here.

What would be the correct translation of majorticks here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162027420

From achung at openjdk.org  Mon Jun 23 16:44:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:44:23 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  update to german translations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/66c34e7d..90bfd7bd

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

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

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

From naoto at openjdk.org  Mon Jun 23 16:44:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Jun 2025 16:44:24 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
 <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
 <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>
Message-ID: <i1GseMJyfCL5uo-smr3SLsDUVkvWzdQheIzvVr5PpKY=.1281d6d5-c07e-47cc-bacc-8ea1161a3df9@github.com>

On Mon, 23 Jun 2025 16:32:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
>> If that was intentionally left out, I don't see new reason to add them.
>
> This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file?

Thanks. I guess this was simply an overlook in the first place, as the process was manual back then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162038459

From duke at openjdk.org  Mon Jun 23 17:41:29 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Mon, 23 Jun 2025 17:41:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
Message-ID: <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>

On Mon, 23 Jun 2025 16:34:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> I agree. I'd expect consistency here.
>
> What would be the correct translation of majorticks here?

If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162131034

From ascarpino at openjdk.org  Mon Jun 23 17:48:46 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 23 Jun 2025 17:48:46 GMT
Subject: [jdk25] RFR: 8358099: PEM spec updates
Message-ID: <LZxMh8i3OOry68DDu1ESdkHjwZW1X_2Siy_cVVTbPrw=.b71a832d-b878-4564-8e34-8d52240ab1a7@github.com>

Hi

This is a clean backport to jdk25 for updates to the PEM spec.

 PEMRecord.pem is renamed to content to better describe that it is the base64 content and not including the header and footer. Additionally, PEMRecord.getEncoded() is removed and some javadoc clarifications for PEMEncoder and PEMDecoder. 
Thanks.

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

Commit messages:
 - Backport 78158f30aee51e14ab203b0127aeb883c010319c

Changes: https://git.openjdk.org/jdk/pull/25940/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25940&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358099
  Stats: 68 lines in 6 files changed: 1 ins; 20 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/25940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25940/head:pull/25940

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

From mpowers at openjdk.org  Mon Jun 23 18:37:28 2025
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 23 Jun 2025 18:37:28 GMT
Subject: RFR: 8156715: TrustStoreManager does not buffer keystore input
 stream
In-Reply-To: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
References: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
Message-ID: <EB57GnzxQ1fNud-RC1L4iN7KqT8wXQ5y3qnW87iA40Q=.da72e61b-8b86-462f-8ed2-f9b7a093e824@github.com>

On Fri, 20 Jun 2025 20:21:19 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> Wrap the FileInputStream into a BufferedInputStream which reduces the number of actual file reads when loading a key store.

Update copyright date.

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

> 377: 
> 378:             if (!"NONE".equals(descriptor.storeName)) {
> 379:                 try (BufferedInputStream fis =

Nit:
`ks` is for KeyStore
`fis` is for FileInputStream
so should `bis` be used for BufferedInputStream?

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

PR Review: https://git.openjdk.org/jdk/pull/25920#pullrequestreview-2951160452
PR Review Comment: https://git.openjdk.org/jdk/pull/25920#discussion_r2162294841

From abarashev at openjdk.org  Mon Jun 23 18:45:30 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 23 Jun 2025 18:45:30 GMT
Subject: RFR: 8156715: TrustStoreManager does not buffer keystore input
 stream
In-Reply-To: <EB57GnzxQ1fNud-RC1L4iN7KqT8wXQ5y3qnW87iA40Q=.da72e61b-8b86-462f-8ed2-f9b7a093e824@github.com>
References: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
 <EB57GnzxQ1fNud-RC1L4iN7KqT8wXQ5y3qnW87iA40Q=.da72e61b-8b86-462f-8ed2-f9b7a093e824@github.com>
Message-ID: <vdNc-McQXKqcncm5DTvj4ympX6uS1DLMGj0e13vqEWQ=.380f31bb-cad2-4f29-b875-6fa3a458a726@github.com>

On Mon, 23 Jun 2025 18:34:22 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Wrap the FileInputStream into a BufferedInputStream which reduces the number of actual file reads when loading a key store.
>
> src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java line 379:
> 
>> 377: 
>> 378:             if (!"NONE".equals(descriptor.storeName)) {
>> 379:                 try (BufferedInputStream fis =
> 
> Nit:
> `ks` is for KeyStore
> `fis` is for FileInputStream
> so should `bis` be used for BufferedInputStream?

Yes, I also noticed that, will update it together with a copyright, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25920#discussion_r2162318466

From aivanov at openjdk.org  Mon Jun 23 18:45:30 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 18:45:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>
Message-ID: <9FQIYMoH-HEi7ktEzRGxRsoWXGPsDyWPWk3Ds0Edjy0=.5dcab616-2713-441b-b363-350ea62505e3@github.com>

On Mon, 23 Jun 2025 14:55:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:
>> 
>>> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
>>> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
>>> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:
>> 
>> Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.
>
> I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR".

I see the entries for


jar.signed.=jar signed.
jar.verified.=jar verified.

don't have the word *?file?*, whereas `?via.jarfile.and.jarinputstream` has it: ?This JAR *file*??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162318454

From raveenakushwah83 at gmail.com  Mon Jun 23 17:35:40 2025
From: raveenakushwah83 at gmail.com (Raveena Kushwah)
Date: Mon, 23 Jun 2025 23:05:40 +0530
Subject: Disable session tickets sent during successful session resumption?
Message-ID: <CAG6QaQ_Tj-7BUhinKpAHbrF==5xfn_sAzKVw9P0YChT1qkhV9w@mail.gmail.com>

Hi All

          This is first time that I'm asking a question here, please let me
know if any other details required.

We are having an application which sents a request to tomcat server using
https. With tls1. 2 protocol being used, session tickets are supported at
client end, server is tomcat which internally uses JSSE and we are using
jdk 17.

During first handshake, it's observed that handshake is successful with new
session ticket being sent by server at end of handshake.

The client stores the session ticket and sends it back to the server in the
client Hello which is accepted by server and with debugging it's confirmed
that the session is valid and moving ahead for resumption.

This is further confirmed with server replying back with same session id in
serverHello message which client has sended in clientHello message.

but observed that new session ticket is sent back to client in next step.

Post referring to RFC 5077, it was cleared that post successful session
resumption, server may send new session ticket for more security (sent with
tomcat server using JSSE everytime during session resumption) .

I would like to ask if there is a way to disable this and only get session
ticket once with first handshake (or if session expired, invalid..) and not
when session validation is successful but still session ticket is being
sent during session resumption?

Would be great if this question could be answered as this would help us a
lot with fixing our application issue ?

Regards
Raveena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250623/264f4027/attachment.htm>

From abarashev at openjdk.org  Mon Jun 23 19:00:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 23 Jun 2025 19:00:51 GMT
Subject: RFR: 8156715: TrustStoreManager does not buffer keystore input
 stream [v2]
In-Reply-To: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
References: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
Message-ID: <LMZrzYmTNsm2A2N5hs9Ewu2h0ixU-XCjvKF3ilGEnuM=.b438014a-e9cc-4300-887c-11b21de8cfad@github.com>

> Wrap the FileInputStream into a BufferedInputStream which reduces the number of actual file reads when loading a key store.

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

  Update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25920/files
  - new: https://git.openjdk.org/jdk/pull/25920/files/06da40b2..3a93d3df

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

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

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

From abarashev at openjdk.org  Mon Jun 23 19:00:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 23 Jun 2025 19:00:51 GMT
Subject: RFR: 8156715: TrustStoreManager does not buffer keystore input
 stream [v2]
In-Reply-To: <vdNc-McQXKqcncm5DTvj4ympX6uS1DLMGj0e13vqEWQ=.380f31bb-cad2-4f29-b875-6fa3a458a726@github.com>
References: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
 <EB57GnzxQ1fNud-RC1L4iN7KqT8wXQ5y3qnW87iA40Q=.da72e61b-8b86-462f-8ed2-f9b7a093e824@github.com>
 <vdNc-McQXKqcncm5DTvj4ympX6uS1DLMGj0e13vqEWQ=.380f31bb-cad2-4f29-b875-6fa3a458a726@github.com>
Message-ID: <XiQFi5nDqBlzQDCb1qDtLaglMTSIuKWRGcXyFbrj_FM=.7c5cc1e4-9fd5-4f15-ba12-1f0aaf4d65a3@github.com>

On Mon, 23 Jun 2025 18:43:12 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java line 379:
>> 
>>> 377: 
>>> 378:             if (!"NONE".equals(descriptor.storeName)) {
>>> 379:                 try (BufferedInputStream fis =
>> 
>> Nit:
>> `ks` is for KeyStore
>> `fis` is for FileInputStream
>> so should `bis` be used for BufferedInputStream?
>
> Yes, I also noticed that, will update it together with a copyright, thanks!

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25920#discussion_r2162341419

From aivanov at openjdk.org  Mon Jun 23 19:07:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:07:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
 <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
Message-ID: <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>

On Mon, 23 Jun 2025 17:38:58 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> What would be the correct translation of majorticks here?
>
> If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").

Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162350461

From aivanov at openjdk.org  Mon Jun 23 19:36:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:36:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>
Message-ID: <O9Co_nchUBZcx7IsEWV3BulBeBx49f1DCSSfMncRP9Y=.01ec06db-951c-4466-b07e-4f49e34c41ad@github.com>

On Mon, 23 Jun 2025 16:36:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:
>> 
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>>> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
>>> 462: SliderDemo.minorticks=Feinteilungen
>> 
>> The following description uses different words now:
>> 
>> Feinteilungen -> Teilstrichen
>> Teilungen -> Teilstrichen
>
> Just to clarify, does this mean
> 
> SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels
> SliderDemo.minorticks=Teilstrichen
> 
> is correct?

Hm? I don't know. You should clarify with the translation team. They've changed the translation for the major ticks from *Grobteilungen* to *Hauptteilstriche*. Yet minor ticks remain *Feinteilungen*, which doesn't look right because the main word is different. (*Teilung* doesn't seem to be the right word, at least dictionaries translate it as ?division?.)

*Teilstrich* means *scale line*, the marks on a ruler, so it fits.

Microsoft documentation for [MinorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.minortickmark?view=openxml-3.0.1) uses *Kleinere Teilstriche*, yet I don't understand why there's ?-e? ending (plural?).


SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels

This one looks particularly incorrect; ?einrasten? is a verb with a separable prefix that means ?to lock?, and I can't find a usage as if it's a noun.

The English phrase is ?Minor Ticks, Snap-to-ticks and Labels?, and I don't know how to correctly translate it to German.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162394521

From aivanov at openjdk.org  Mon Jun 23 19:36:32 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:36:32 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>
Message-ID: <Cnn1pTxh334i_8vCnBa3c3FWvblGyzCjASOEGJQTsw8=.eb5e76f7-e83b-416c-9fe6-361d772780af@github.com>

On Thu, 19 Jun 2025 17:39:38 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:
>> 
>>> 181: size.bit.alg=%1$d-Bit-%2$s
>>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
>>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}
>> 
>> It feels as if there's something missing after _?einem?_.
>
> seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162395125

From abarashev at openjdk.org  Mon Jun 23 19:49:50 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 23 Jun 2025 19:49:50 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v11]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <nh1-oP9GggslbWmvrN6ENCkMYVn5SAJKm2KAZmZGKIw=.58f3f881-375f-4edc-b7b3-41f3ae72e0e2@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

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

  Add more unit test cases. Some code tweaks.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/c5e381ec..3edca307

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

  Stats: 72 lines in 2 files changed: 25 ins; 15 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

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

From ascarpino at openjdk.org  Mon Jun 23 23:13:38 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 23 Jun 2025 23:13:38 GMT
Subject: RFR: 8156715: TrustStoreManager does not buffer keystore input
 stream [v2]
In-Reply-To: <LMZrzYmTNsm2A2N5hs9Ewu2h0ixU-XCjvKF3ilGEnuM=.b438014a-e9cc-4300-887c-11b21de8cfad@github.com>
References: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
 <LMZrzYmTNsm2A2N5hs9Ewu2h0ixU-XCjvKF3ilGEnuM=.b438014a-e9cc-4300-887c-11b21de8cfad@github.com>
Message-ID: <6MjxCI5n5GyWoUxH8uK8r6PBDholLHb8_U6fqD5jlXA=.e7e56817-bf1b-48e3-afcc-4d2feef4ad83@github.com>

On Mon, 23 Jun 2025 19:00:51 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Wrap the FileInputStream into a BufferedInputStream which reduces the number of actual file reads when loading a key store.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Add a no regression test label on the bug.   Probably `noreg-hard` as it's difficult to test.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25920#pullrequestreview-2951746020

From raveenakushwah83 at gmail.com  Tue Jun 24 04:12:24 2025
From: raveenakushwah83 at gmail.com (Raveena Kushwah)
Date: Tue, 24 Jun 2025 09:42:24 +0530
Subject: Disable new session tickets sent during successful session resumption?
Message-ID: <CAG6QaQ_vh-5a8_kvnNDT6+wan4uNwq8Unguu_zbvjOO54LcyWA@mail.gmail.com>

Hi All

          This is first time that I'm asking a question here, please let me
know if any other details required.

We are having an application which sents a request to tomcat server using
https. With tls1. 2 protocol being used, session tickets are supported at
client end, server is tomcat which internally uses JSSE and we are using
jdk 17.

During first handshake, it's observed that handshake is successful with new
session ticket being sent by server at end of handshake.

The client stores the session ticket and sends it back to the server in the
client Hello which is accepted by server and with debugging it's confirmed
that the session is valid and moving ahead for resumption.

This is further confirmed with server replying back with same session id in
serverHello message which client has sended in clientHello message.

but observed that new session ticket is sent back to client in next step.

Post referring to RFC 5077, it was cleared that post successful session
resumption, server may send new session ticket for more security (sent with
tomcat server using JSSE everytime during session resumption) .

I would like to ask if there is a way to disable this and only get session
ticket once with first handshake (or if session expired, invalid..) and not
when session validation is successful but still session ticket is being
sent during session resumption?

Would be great if this question could be answered as this would help us a
lot with fixing our application issue ?

Regards
Raveena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250624/367a295d/attachment-0001.htm>

From cstein at openjdk.org  Tue Jun 24 05:15:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:15:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
 <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
 <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>
Message-ID: <bNn_SZAJQvbgRD39f2sJDCLItuz4Q-fJOjCQzc0URAo=.825ec4ad-31a1-4882-93ee-97f0eff02597@github.com>

On Mon, 23 Jun 2025 19:04:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").
>
> Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct.

Ja, "Hauptteilstrich" and "Hauptteilstriche" (pl) are correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162975420

From cstein at openjdk.org  Tue Jun 24 05:22:33 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:22:33 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <ws3HlD1kGmF5lUjtCE7SxWmnc4GEkdFi6FWo_Hnm7Tc=.c3dc65c9-7681-4145-afc2-a3af84857e78@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:

> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
> 462: SliderDemo.minorticks=Feinteilungen

For consistency with the "Hilfsteilstrich" (singular) and "Hilfsteilstriche" (plural) used below in `SliderDemo.minorticksdescription` and `SliderDemo.disableddescription`, I'd suggest to use:
Suggestion:

SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
SliderDemo.minorticks=Hilfsteilstriche


As "Labels" is not a German word.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162982972

From cstein at openjdk.org  Tue Jun 24 05:34:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:34:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <8Orj0J7-iUsSjTQEc7t-pSShM2wHGmfReMStzGByHGY=.41967017-0e70-4e2a-9133-f84fd263ff51@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 178:

> 176: javac.opt.Xlint.desc.restricted=Warnt vor der Verwendung eingeschr?nkter Methoden.
> 177: 
> 178: javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n                         Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "Identit?t", die dieselben Verwendungen und\n                         Effekte hat. Benutzern wird empfohlen, die Kategorie "Identit?t" f?r alle zuk?nftigen\n                         und vorhandenen Verwendungen von "Synchronisierung" zu verwenden.

"Identit?t" and "Synchronisierung" are literals that must not be translated.

The English base entry reads:


javac.opt.Xlint.desc.synchronization=\
    Warn about synchronization attempts on instances of value-based classes.\n\
\                         This key is a deprecated alias for ''identity'', which has the same uses and\n\
\                         effects. Users are encouraged to use the ''identity'' category for all future\n\
\                         and existing uses of ''synchronization''.


And `javac --help-lint` contains:


    strictfp             Warn about unnecessary use of the strictfp modifier.
    synchronization      Warn about synchronization attempts on instances of value-based classes.
    text-blocks          Warn about inconsistent white space characters in text block indentation.
    
    
    
Suggestion:

javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n                         Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "identity", die dieselben Verwendungen und\n                         Effekte hat. Benutzern wird empfohlen, die Kategorie "identity" f?r alle zuk?nftigen\n                         und vorhandenen Verwendungen von "synchronization" zu verwenden.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162995954

From cstein at openjdk.org  Tue Jun 24 05:44:30 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:44:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <AQix03HSJOPQl9dpzNexQJ-oAj3KLVWEt4zDGOxjmZM=.1efb1178-489f-478e-9534-f9b32e5b92de@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties line 103:

> 101: 
> 102: # 0: string
> 103: launcher.err.cant.find.main.method=main(String[])- oder main()-Methode nicht gefunden in Klasse: {0}

Suggestion:

launcher.err.cant.find.main.method=Konnte keine main(String[])- oder main()-Methode in der Klasse: {0} finden.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2163006433

From myankelevich at openjdk.org  Tue Jun 24 10:20:32 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 24 Jun 2025 10:20:32 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <AEOtlOrH3Ei8WoYJdhHcv2eoKNobNYGF2wgrGKhYrPs=.80e98f42-c948-446a-9d18-0b00549426bb@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
 <AEOtlOrH3Ei8WoYJdhHcv2eoKNobNYGF2wgrGKhYrPs=.80e98f42-c948-446a-9d18-0b00549426bb@github.com>
Message-ID: <aTHgAP-DyI1jO8gu_7z_KzT8tQM7oAp4ZedJ35rfB8Y=.ddd2b066-bba0-41a6-b51a-9627535dabea@github.com>

On Sun, 22 Jun 2025 17:21:17 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8357470
>>  - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
>>    
>>    * added an automated mixed case option
>>    * using multithreading now
>>    * added logs for simpler debug
>>    * added missing -Djava.security.auth.debug coverage
>
> test/jdk/sun/security/util/Debug/DebugOptions.java line 152:
> 
>> 150:      * @return resulting string
>> 151:      */
>> 152:     private String makeFirstAndLastLetterUppercase(final String paramString) {
> 
> If the goal is to test case-insensitive parsing comprehensively, this method should be expanded to test various case combinations (e.g., all-uppercase, alternating case, etc). Otherwise, document this limitation.

As per our discussion, split this test into 3. upper case, mixed case and lowercase. Done in the next commit

> test/jdk/sun/security/util/Debug/DebugOptions.java line 153:
> 
>> 151:      */
>> 152:     private String makeFirstAndLastLetterUppercase(final String paramString) {
>> 153:         final int length = paramString.length();
> 
> Edge Case : Can we check for null or empty before this ?

Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2163549646
PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2163549856

From myankelevich at openjdk.org  Tue Jun 24 10:28:31 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 24 Jun 2025 10:28:31 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <tnBymC4th2L_yEdpH0RKKNZ-5XUN4kim8n0A5DaxxwU=.894f3164-061e-4028-892e-1bfa31b7511d@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
 <tnBymC4th2L_yEdpH0RKKNZ-5XUN4kim8n0A5DaxxwU=.894f3164-061e-4028-892e-1bfa31b7511d@github.com>
Message-ID: <rZhS3xi3J8iCf2nqTpZ6SWhIcWq0c4xbX6-K7NYZHNU=.8bf097b4-86ed-4d8d-8166-a5ef10100d93@github.com>

On Sat, 21 Jun 2025 23:32:04 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8357470
>>  - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
>>    
>>    * added an automated mixed case option
>>    * using multithreading now
>>    * added logs for simpler debug
>>    * added missing -Djava.security.auth.debug coverage
>
> test/jdk/sun/security/util/Debug/DebugOptions.java line 174:
> 
>> 172: 
>> 173:             patternMatches.forEach(params -> {
>> 174:                 testsCallables.add(() -> {
> 
> Can we consider adding negative tests with invalid/malformed parameters like null, empty strings, unknown keywords, etc?

This is not in the scope of this change, however this will be addressed in [JDK-8360373](https://bugs.openjdk.org/browse/JDK-8360373)

> test/jdk/sun/security/util/Debug/DebugOptions.java line 207:
> 
>> 205:                     return null;
>> 206:                 });
>> 207: 
> 
> Can we add a test to explicitly test something like this for `testParameter("-Djava.security.debug=", "all", EXPECTED_ALL_REGEX, "not expected")` and `testMixedCaseParameter("-Djava.security.debug=", "AlL", EXPECTED_ALL_REGEX, "not expected")` ?

As we discussed offline, if we only test a few options hardcoded like this we risk missing a potential bug where one option may not support mixed and upper case

> test/jdk/sun/security/util/Debug/DebugOptions.java line 214:
> 
>> 212:             final List<Future<Void>> res = executorService.invokeAll(testsCallables);
>> 213:             for (final Future<Void> future : res) {
>> 214:                 future.get();
> 
> future.get() could throw an unchecked exception. Can we consider logging which test failed and why?

It is logged in the `test*Parameter` methods when the action is executed. It would be saved to a separate log file by jtreg, one per thread

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2163565812
PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2163566241
PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2163566431

From myankelevich at openjdk.org  Tue Jun 24 10:41:29 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 24 Jun 2025 10:41:29 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v3]
In-Reply-To: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
Message-ID: <53tFQIIUgJaJFDLzEpcEYOjsMzz4JXhQupjzZDQ3iUQ=.417b5005-5d14-4dfb-8ae0-44b6bdc79a8a@github.com>

> * added an automated mixed case option
> * using multithreading now
> * added logs for simpler debug
> * added missing -Djava.security.auth.debug coverage

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

  comments & split test to 3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25391/files
  - new: https://git.openjdk.org/jdk/pull/25391/files/4f36b0f6..f23f2545

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

  Stats: 136 lines in 1 file changed: 91 ins; 5 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/25391.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25391/head:pull/25391

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

From myankelevich at openjdk.org  Tue Jun 24 10:41:34 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 24 Jun 2025 10:41:34 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v2]
In-Reply-To: <HSqAgKiWy4P7zPjzuyAEHXIVWmAQvwJ-bLgicUDXP6Y=.05b04773-878b-44a3-9124-fded3a7ad6da@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <lDgeHNFtYIXNlMO1WOmgNwvGGNmvKD_vCi72dR33ICo=.3a8a3c06-7d05-4196-a82a-efa04e00d121@github.com>
 <HSqAgKiWy4P7zPjzuyAEHXIVWmAQvwJ-bLgicUDXP6Y=.05b04773-878b-44a3-9124-fded3a7ad6da@github.com>
Message-ID: <vG2StS9jwphCz8IwIWj92eSMzmsUpLTUfplaNhfxmls=.c334fd56-3e6e-48d8-99f1-8c367366745d@github.com>

On Sat, 21 Jun 2025 23:18:39 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8357470
>>  - JDK-8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase
>>    
>>    * added an automated mixed case option
>>    * using multithreading now
>>    * added logs for simpler debug
>>    * added missing -Djava.security.auth.debug coverage
>
> test/jdk/sun/security/util/Debug/DebugOptions.java line 208:
> 
>> 206:                 });
>> 207: 
>> 208:                 System.out.println("option added to all tests " + Arrays.toString(params));
> 
> Optional: consider labeling the log output to make test parameters easier to read when scanning test output

I'd prefer keeping this as is, as the parameters are also logged in the `test*Parameter` when the thread is actually executed. This is just to make sure that the parameters are added to the list of threads, which would be easier in this format, as they are set in this format in the list above. 

log: 

Option added to all lowercase tests [properties, properties\[.*\|main|\\d{4}-\\d{2}-\\d{2}.*\]:, properties:]

code: 
```java 
new String[]{"properties",
             EXPECTED_PROP_REGEX,
             "properties:"},

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2163585279

From coffeys at openjdk.org  Tue Jun 24 11:44:44 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 24 Jun 2025 11:44:44 GMT
Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v2]
In-Reply-To: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com>
References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com>
Message-ID: <PBaQHCrnQEHmaKOn_nnOk6Nw_ccC0g0-P-hdhWVD_os=.139016b5-40ed-4065-a7f7-a50f0390fbfc@github.com>

> SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode)
> 
> SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode.
> 
> Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()`
> 
> DebugPropertyValuesTest also updated to test new logic.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Text Blocks use \n by default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25934/files
  - new: https://git.openjdk.org/jdk/pull/25934/files/9e589a63..51eb0f1b

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

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

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

From coffeys at openjdk.org  Tue Jun 24 13:05:43 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 24 Jun 2025 13:05:43 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v3]
In-Reply-To: <53tFQIIUgJaJFDLzEpcEYOjsMzz4JXhQupjzZDQ3iUQ=.417b5005-5d14-4dfb-8ae0-44b6bdc79a8a@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <53tFQIIUgJaJFDLzEpcEYOjsMzz4JXhQupjzZDQ3iUQ=.417b5005-5d14-4dfb-8ae0-44b6bdc79a8a@github.com>
Message-ID: <EJE2KhobR20X3d4xp3EACs8FKuwAIa7ThOtXab2-3l8=.fc89e026-f548-493c-ae32-a276cde3394e@github.com>

On Tue, 24 Jun 2025 10:41:29 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments & split test to 3

As the original contributor of this test case, it's nice to see the speed up via use of ExecutorService.

The upper case and lower case property tests are somewhat questionable IMO. One or two lines of test code would suffice but now we have a lot of noise distracting from the original intent of the test code. One could argue that every system property in the JDK could be subject to the same uppercase/lower case testing but such tests don't exist. A few lines of test code can easily verify behavior. Anything else enters the fuzzy logic testing approach. Hope it's not a pattern that new tests have to adopt.

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

PR Review: https://git.openjdk.org/jdk/pull/25391#pullrequestreview-2953749743

From myankelevich at openjdk.org  Tue Jun 24 13:44:28 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 24 Jun 2025 13:44:28 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v3]
In-Reply-To: <EJE2KhobR20X3d4xp3EACs8FKuwAIa7ThOtXab2-3l8=.fc89e026-f548-493c-ae32-a276cde3394e@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <53tFQIIUgJaJFDLzEpcEYOjsMzz4JXhQupjzZDQ3iUQ=.417b5005-5d14-4dfb-8ae0-44b6bdc79a8a@github.com>
 <EJE2KhobR20X3d4xp3EACs8FKuwAIa7ThOtXab2-3l8=.fc89e026-f548-493c-ae32-a276cde3394e@github.com>
Message-ID: <hClRjfEX7KtU-otzqugWEzYy7QoT3UTD0vT1vyNROs4=.5c15007c-432f-4c9b-a53d-fb5dfcfabef6@github.com>

On Tue, 24 Jun 2025 13:02:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> As the original contributor of this test case, it's nice to see the speed up via use of ExecutorService.
> 
> The upper case and lower case property tests are somewhat questionable IMO. One or two lines of test code would suffice but now we have a lot of noise distracting from the original intent of the test code. One could argue that every system property in the JDK could be subject to the same uppercase/lower case testing but such tests don't exist. A few lines of test code can easily verify behavior. Anything else enters the fuzzy logic testing approach. Hope it's not a pattern that new tests have to adopt.

Do you think that keeping it just mixed case would be sufficient? I believe this approach might be too much for other tests, it seems to me like a lot for this one as well

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

PR Comment: https://git.openjdk.org/jdk/pull/25391#issuecomment-3000549169

From coffeys at openjdk.org  Tue Jun 24 14:18:34 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 24 Jun 2025 14:18:34 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v3]
In-Reply-To: <hClRjfEX7KtU-otzqugWEzYy7QoT3UTD0vT1vyNROs4=.5c15007c-432f-4c9b-a53d-fb5dfcfabef6@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <53tFQIIUgJaJFDLzEpcEYOjsMzz4JXhQupjzZDQ3iUQ=.417b5005-5d14-4dfb-8ae0-44b6bdc79a8a@github.com>
 <EJE2KhobR20X3d4xp3EACs8FKuwAIa7ThOtXab2-3l8=.fc89e026-f548-493c-ae32-a276cde3394e@github.com>
 <hClRjfEX7KtU-otzqugWEzYy7QoT3UTD0vT1vyNROs4=.5c15007c-432f-4c9b-a53d-fb5dfcfabef6@github.com>
Message-ID: <Gd0E_I5LXo_4ITkGYU9TXLWOhbYBzjfpBCu-DnqRKWA=.15bcfa8a-53a7-423a-9b43-1ff4ae1eff7f@github.com>

On Tue, 24 Jun 2025 13:41:42 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> > As the original contributor of this test case, it's nice to see the speed up via use of ExecutorService.
> > The upper case and lower case property tests are somewhat questionable IMO. One or two lines of test code would suffice but now we have a lot of noise distracting from the original intent of the test code. One could argue that every system property in the JDK could be subject to the same uppercase/lower case testing but such tests don't exist. A few lines of test code can easily verify behavior. Anything else enters the fuzzy logic testing approach. Hope it's not a pattern that new tests have to adopt.
> 
> Do you think that keeping it just mixed case would be sufficient? I believe this approach might be too much for other tests, it seems to me like a lot for this one as well

I'd welcome anything that helps reduce the extra code that's being added to test multiple case combinations for a system property. It strikes me as overkill.

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

PR Comment: https://git.openjdk.org/jdk/pull/25391#issuecomment-3000692391

From weijun at openjdk.org  Tue Jun 24 14:56:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 14:56:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
Message-ID: <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>

On Wed, 18 Jun 2025 16:43:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.
>
> Thank you for the clarification.

However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164251035

From weijun at openjdk.org  Tue Jun 24 15:01:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 15:01:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:

> 47: .Principal.=\t????\u0020
> 48: .Public.Credential.=\t??????:\u0020
> 49: .Private.Credential.=\t??????:\u0020

Why aren't the 2 lines above updated like in lines 46 and 47?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164262664

From weijun at openjdk.org  Tue Jun 24 15:01:31 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 15:01:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
 <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
Message-ID: <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>

On Tue, 24 Jun 2025 14:54:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Thank you for the clarification.
>
> However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".

Some people like to insert a space between a Chinese character and a Latin letter. I?m not a fan of this style, but I don?t feel strongly about it. However, adding a space between two Chinese characters or between a Chinese character and a full-width punctuation mark is unusual.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164261187

From abarashev at openjdk.org  Tue Jun 24 15:31:29 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 24 Jun 2025 15:31:29 GMT
Subject: RFR: 8156715: TrustStoreManager does not buffer keystore input
 stream [v2]
In-Reply-To: <6MjxCI5n5GyWoUxH8uK8r6PBDholLHb8_U6fqD5jlXA=.e7e56817-bf1b-48e3-afcc-4d2feef4ad83@github.com>
References: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
 <LMZrzYmTNsm2A2N5hs9Ewu2h0ixU-XCjvKF3ilGEnuM=.b438014a-e9cc-4300-887c-11b21de8cfad@github.com>
 <6MjxCI5n5GyWoUxH8uK8r6PBDholLHb8_U6fqD5jlXA=.e7e56817-bf1b-48e3-afcc-4d2feef4ad83@github.com>
Message-ID: <e5Sj-R6Yp53OwsdFmrPXlndvz5_cgCr3wqBmi4mHHeI=.ef2a6289-6ef3-4db7-b1fb-4f6aeb8ddac5@github.com>

On Mon, 23 Jun 2025 23:11:16 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Add a no regression test label on the bug. Probably `noreg-hard` as it's difficult to test.

Done, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25920#issuecomment-3000536214

From abarashev at openjdk.org  Tue Jun 24 15:34:36 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 24 Jun 2025 15:34:36 GMT
Subject: Integrated: 8156715: TrustStoreManager does not buffer keystore input
 stream
In-Reply-To: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
References: <H8j7rQiom6jkCI3Ip9xon_oQEj8EQ5FSj9_hHTzDZ1o=.dbac4207-2c66-4fd0-b9fa-2968c1b7d9ee@github.com>
Message-ID: <2P3DOzhUxPAkHUvV_cm8T6DC54eq9BGIva51mgJiYkU=.ca7ef127-0491-41e4-83d4-6682e98f8d4f@github.com>

On Fri, 20 Jun 2025 20:21:19 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> Wrap the FileInputStream into a BufferedInputStream which reduces the number of actual file reads when loading a key store.

This pull request has now been integrated.

Changeset: 2af869b1
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2af869b193017bbd8bec4cfef9f0870de6ec1285
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8156715: TrustStoreManager does not buffer keystore input stream

Reviewed-by: ascarpino

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

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

From abarashev at openjdk.org  Tue Jun 24 16:44:36 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 24 Jun 2025 16:44:36 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v5]
In-Reply-To: <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>
Message-ID: <UTDakdKiHIzeZqtMO49ZMLGhgXEJZ1CEVFAWoOLl1k0=.a3f3886c-21be-4979-b632-4a4b9a14c7f4@github.com>

On Tue, 3 Jun 2025 13:11:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
>> 
>> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
>> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
>> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
>  - Merge branch 'master' into certbuilder
>  - expanded wildcard imports
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - reversed order of DN strings when making certificates.
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e490b4f0...2b5533aa

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 247:

> 245:     private static void setupCertificates() throws Exception {
> 246:         KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> 247:         kpg.initialize(1024);

This line can be removed so implementation uses a default value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2164469651

From abarashev at openjdk.org  Tue Jun 24 16:48:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 24 Jun 2025 16:48:34 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v5]
In-Reply-To: <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>
Message-ID: <0htGbIzjg033KwgKDz6hjpQ8ItfZI0O6fHId-nplqVI=.c713ce44-b75d-4040-b851-881163c2ed29@github.com>

On Tue, 3 Jun 2025 13:11:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
>> 
>> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
>> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
>> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
>  - Merge branch 'master' into certbuilder
>  - expanded wildcard imports
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - reversed order of DN strings when making certificates.
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e490b4f0...2b5533aa

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 390:

> 388: 
> 389:         // create a key store
> 390:         KeyStore ks = KeyStore.getInstance("JKS");

I suggest changing a key store type to `PKCS12`, should be a better choice in the long run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2164477518

From weijun at openjdk.org  Tue Jun 24 18:06:27 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 18:06:27 GMT
Subject: [jdk25] RFR: 8358099: PEM spec updates
In-Reply-To: <LZxMh8i3OOry68DDu1ESdkHjwZW1X_2Siy_cVVTbPrw=.b71a832d-b878-4564-8e34-8d52240ab1a7@github.com>
References: <LZxMh8i3OOry68DDu1ESdkHjwZW1X_2Siy_cVVTbPrw=.b71a832d-b878-4564-8e34-8d52240ab1a7@github.com>
Message-ID: <MrX2uhaSI10XIWiDMFYj7BudtKakI8NziX8uWLaR6d4=.16e396ca-6810-4bb6-a6df-cfecfdda35a8@github.com>

On Mon, 23 Jun 2025 16:55:22 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This is a clean backport to jdk25 for updates to the PEM spec.
> 
>  PEMRecord.pem is renamed to content to better describe that it is the base64 content and not including the header and footer. Additionally, PEMRecord.getEncoded() is removed and some javadoc clarifications for PEMEncoder and PEMDecoder. 
> Thanks.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25940#pullrequestreview-2954826190

From hai-may.chao at oracle.com  Tue Jun 24 19:25:15 2025
From: hai-may.chao at oracle.com (Hai-May Chao)
Date: Tue, 24 Jun 2025 19:25:15 +0000
Subject: Disable session tickets sent during successful session resumption?
In-Reply-To: <CAG6QaQ_Tj-7BUhinKpAHbrF==5xfn_sAzKVw9P0YChT1qkhV9w@mail.gmail.com>
References: <CAG6QaQ_Tj-7BUhinKpAHbrF==5xfn_sAzKVw9P0YChT1qkhV9w@mail.gmail.com>
Message-ID: <7BCDDCA0-486E-4E23-A5AE-D8D308BE469C@oracle.com>

Hi Raveena,


> On Jun 23, 2025, at 10:35?AM, Raveena Kushwah <raveenakushwah83 at gmail.com> wrote:
> 
> Hi All
> 
>           This is first time that I'm asking a question here, please let me know if any other details required. 
> 
> We are having an application which sents a request to tomcat server using https. With tls1. 2 protocol being used, session tickets are supported at client end, server is tomcat which internally uses JSSE and we are using jdk 17.
> 
> During first handshake, it's observed that handshake is successful with new session ticket being sent by server at end of handshake. 
> 
> The client stores the session ticket and sends it back to the server in the client Hello which is accepted by server and with debugging it's confirmed that the session is valid and moving ahead for resumption. 
> 
> This is further confirmed with server replying back with same session id in serverHello message which client has sended in clientHello message. 
> 
> but observed that new session ticket is sent back to client in next step. 
> 
> Post referring to RFC 5077, it was cleared that post successful session resumption, server may send new session ticket for more security (sent with tomcat server using JSSE everytime during session resumption) . 
> 
> I would like to ask if there is a way to disable this and only get session ticket once with first handshake (or if session expired, invalid..) and not when session validation is successful but still session ticket is being sent during session resumption? 


The behavior you were seeing is expected and compliant according to RFC 5077.

Session tickets are either ON or OFF globally and configured by the system property ?jdk.tls.server.enableSessionTicketExtension? . Once it is enabled, there isn?t a way to prevent NewSessionTicket from being sent after successful session resumption.

> 
> Would be great if this question could be answered as this would help us a lot with fixing our application issue ?
> 
> Regards
> Raveena


Regards,
Hai-May


From ascarpino at openjdk.org  Tue Jun 24 19:34:33 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 24 Jun 2025 19:34:33 GMT
Subject: [jdk25] Integrated: 8358099: PEM spec updates
In-Reply-To: <LZxMh8i3OOry68DDu1ESdkHjwZW1X_2Siy_cVVTbPrw=.b71a832d-b878-4564-8e34-8d52240ab1a7@github.com>
References: <LZxMh8i3OOry68DDu1ESdkHjwZW1X_2Siy_cVVTbPrw=.b71a832d-b878-4564-8e34-8d52240ab1a7@github.com>
Message-ID: <aUqQM0NbqFeNQwGiQssMFQyESN-04HF297ZV0thaICc=.5e5498ad-1217-4865-be70-a629851f2fb0@github.com>

On Mon, 23 Jun 2025 16:55:22 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This is a clean backport to jdk25 for updates to the PEM spec.
> 
>  PEMRecord.pem is renamed to content to better describe that it is the base64 content and not including the header and footer. Additionally, PEMRecord.getEncoded() is removed and some javadoc clarifications for PEMEncoder and PEMDecoder. 
> Thanks.

This pull request has now been integrated.

Changeset: b89f3648
Author:    Anthony Scarpino <ascarpino at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b89f3648421601bc7520895afb4f9d5ff87030d8
Stats:     68 lines in 6 files changed: 1 ins; 20 del; 47 mod

8358099: PEM spec updates

Reviewed-by: weijun
Backport-of: 78158f30aee51e14ab203b0127aeb883c010319c

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

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

From achung at openjdk.org  Tue Jun 24 21:47:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 24 Jun 2025 21:47:23 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v5]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <D5DGFra1xHGKB6ITrD1TV1PQcZNS_7nlA8GfD8cwQ6w=.c87859b8-fb89-4d2e-93a4-d9c0e3e44f21@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/90bfd7bd..97f3fe37

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

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

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

From dnguyen at openjdk.org  Wed Jun 25 00:30:31 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jun 2025 00:30:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
Message-ID: <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>

On Tue, 24 Jun 2025 14:59:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to german translations
>
> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:
> 
>> 47: .Principal.=\t????\u0020
>> 48: .Public.Credential.=\t??????:\u0020
>> 49: .Private.Credential.=\t??????:\u0020
> 
> Why aren't the 2 lines above updated like in lines 46 and 47?

I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.

I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2165200706

From ascarpino at openjdk.org  Wed Jun 25 01:18:39 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 25 Jun 2025 01:18:39 GMT
Subject: RFR: 8349946: Cipher javadoc could describe AEAD reuse better [v2]
In-Reply-To: <pLTFSk6xU2gd47wM95pcIvCCg32wX5OBilbrd7TcW-s=.10b0f2bc-512d-49c9-a9cf-c67e66b5368b@github.com>
References: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
 <pLTFSk6xU2gd47wM95pcIvCCg32wX5OBilbrd7TcW-s=.10b0f2bc-512d-49c9-a9cf-c67e66b5368b@github.com>
Message-ID: <TXvoVsfyFOw3MUpTwUNGMSOAc8FHpV1ulAIYYL9eD9U=.99934afd-a7bf-4eac-b2f9-ff3491a144a3@github.com>

On Thu, 12 Jun 2025 17:04:22 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The class documentation in javax.crypto.Cipher could better describe AEAD and reuse. The current class description example is outdated as GCM encryption does not allow resets. The doc should state that reset() may not be possible with some algorithms or providers and that an InvalidAlgorithmParameterException is thrown
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349946:Cipher javadoc could describe AEAD reuse better

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

> 109:  * the {@code update} and {@code doFinal} methods).
> 110:  * <p>
> 111:  * When {@code doFinal} methods completes the operation, the {@code Cipher} object will attempt

Rephrasing:  "When a {@code doFinal} method completes ..."

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

> 112:  * to reset the state to the most recent call to {@code init}, allowing for additional
> 113:  * operations. A successful reset depends on the mode ({@code ENCRYPT_MODE} or
> 114:  * {@code DECRYPT_MODE}) and the algorithm. AEAD algorithms may not reset to prevent

rephrase:  replace "to prevent" with ", in order to prevent"

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

> 114:  * {@code DECRYPT_MODE}) and the algorithm. AEAD algorithms may not reset to prevent
> 115:  * forgery attacks due to Key and IV uniqueness requirements.
> 116:  * An {@link IllegalStateException} will be thrown when calling {@code update}

insert a `<p>` at the start of this line to separate the exception explanation.

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

> 115:  * forgery attacks due to Key and IV uniqueness requirements.
> 116:  * An {@link IllegalStateException} will be thrown when calling {@code update}
> 117:  * or {@code doFinal} methods when a reset did not occur. {@code init} may

"methods when a" -> "methods if a"
Also  change the next sentence to:  "A call to {@code init} will reinitialize"

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

> 2087:      *
> 2088:      * @throws IllegalStateException if this {@code Cipher} object
> 2089:      * is in a wrong state or cannot be reset.

We should probably have said "mode", not "state"  .  How about "a wrong state" -> "an incorrect mode".
The others below should be changed as well

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2165205525
PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2165207935
PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2165205941
PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2165215568
PR Review Comment: https://git.openjdk.org/jdk/pull/25399#discussion_r2165219599

From jpai at openjdk.org  Wed Jun 25 07:38:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jun 2025 07:38:42 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <ooatWh5P-uq9NOvehhwv-TT_GF3wF9awAZYmzuIXwCc=.4d62ff7e-ad19-44cf-a7e7-92e081fda2c4@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <ooatWh5P-uq9NOvehhwv-TT_GF3wF9awAZYmzuIXwCc=.4d62ff7e-ad19-44cf-a7e7-92e081fda2c4@github.com>
Message-ID: <Ml3RL_0YjwZCf9TJ7k9gpTrZnS68yHDWiuN8v2qGR8c=.4ff1e212-745c-426b-ab44-4fbcee765903@github.com>

On Tue, 22 Apr 2025 16:39:21 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 506 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: update H3InsertionsLimitTest to start after receival of client settings
>>  - merge latest changes from master branch
>>  - quic: separate out the idle termination timer and the STREAM_DATA_BLOCKED timer
>>  - quic: simplify idle timeout management
>>  - http3: rely on the sole isOpen() method instead of isOpen() and isClosed()
>>  - quic: do not let h3 idle (in pool) timeout to influence the quic transport idle timeout
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - ... and 496 more: https://git.openjdk.org/jdk/compare/8d33ea73...d4984d5e
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 265:
> 
>> 263: //                    engine, localSupportedSignAlgs, false);
>> 264: //        } else {
>> 265: //            constraints = SSLAlgorithmConstraints.forEngine(engine, false);
> 
> We need these to check peer's certificate against constraints specified in `java.security` config file. It looks like `SSLAlgorithmConstraints` class would need a new `forQuicTLSEngine` method.

Hello Daniel @dfuchs, this can be marked as resolved since the changes proposed by Artur have been implemented in this PR. There's now a `SSLAlgorithmConstraints.forQUIC()` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166016865

From jpai at openjdk.org  Wed Jun 25 07:41:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jun 2025 07:41:43 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <vLvyqUUFPFSJUrFUl8EOEBJHGsoIxWOVGMeB0uhV6Tw=.249ece3e-3a6e-4671-ae9a-5fa23bee0b14@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <vLvyqUUFPFSJUrFUl8EOEBJHGsoIxWOVGMeB0uhV6Tw=.249ece3e-3a6e-4671-ae9a-5fa23bee0b14@github.com>
Message-ID: <HKN_NQPI7MKzBFtFIwyjpihj4glBEiJf_huvhWoD5TQ=.3fd7c853-93ad-49a2-b58e-a61c8366c275@github.com>

On Tue, 10 Jun 2025 22:16:18 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - Improve key destruction
>>  - merge latest changes from master branch
>>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>>  - http3: refactor HTTP/3 connection pool management in a separate class
>>  - Ignore DestroyFailedExceptions
>>  - Remove outdated TODO
>>  - Remove outdated TODO
>>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 164:
> 
>> 162:      */
>> 163:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
>> 164:                                         boolean applyCertPathAlgConstraints) {
> 
> This parameter should be called `withDefaultCertPathConstraints` for consistency with other methods.

Done. The change will be available in the next refresh of this PR.

> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 188:
> 
>> 186:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
>> 187:                                         String[] supportedAlgorithms,
>> 188:                                         boolean applyCertPathAlgConstraints) {
> 
> Same as above:  should be called `withDefaultCertPathConstraints`

Done. The change will be available in the next refresh of this PR.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 243:
> 
>> 241:         }
>> 242:         // QUIC TLS version is mandated to be always TLSv1.3
>> 243:         if (!ProtocolVersion.useTLS12PlusSpec(session.getProtocol())) {
> 
> Should be `useTLS13PlusSpec`

Done. The change will be available in the next refresh of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166022943
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166022795
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166023188

From jpai at openjdk.org  Wed Jun 25 07:45:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jun 2025 07:45:48 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
Message-ID: <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>

On Tue, 10 Jun 2025 22:21:31 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - Improve key destruction
>>  - merge latest changes from master branch
>>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>>  - http3: refactor HTTP/3 connection pool management in a separate class
>>  - Ignore DestroyFailedExceptions
>>  - Remove outdated TODO
>>  - Remove outdated TODO
>>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 247:
> 
>> 245:         if (quicEngine != null) {
>> 246:             if (quicEngine instanceof QuicTLSEngineImpl engineImpl) {
>> 247:                 return engineImpl.getAlgorithmConstraints();
> 
> Any particular reason constraints selection code was moved to `engineImpl.getAlgorithmConstraints()` and not kept in this file for consistency with `SSLEngine` and `SSLSocket`?

Hello Artur, we currently don't expose the `HandshakeContext` outside of the `QuicTLSEngineImpl`. The `HandshakeContext` is what is needed to get the relevant user specified algorithm constraints. So I decided to let the `HandshakeContext` be an internal detail in `QuicTLSEngineImpl` and introduce the `getAlgorithmConstraints()` method on it. Do you think we should hand out the `HandshakeContext` outside of `QuicTLSEngineImpl`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166029169

From djelinski at openjdk.org  Wed Jun 25 08:23:40 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Jun 2025 08:23:40 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <M2N2txL2370OJ-NMxgkQ_qC15SC8cUbhTcFKo--AiP4=.45b41468-c1d9-4378-ac74-48a467113baf@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
 <rVqCd_DVMFQ-IvM8H3_h26LN-rcuKon-Zv8ZA-g2t3I=.a55a3fcf-f219-4127-b3df-278534230389@github.com>
 <HICWfI_yKD64mMPhIsGHFT5cPIw4Az-RociRzPvJUXQ=.d3150052-6cb2-486a-b149-5b5617c183d3@github.com>
 <xNTKNw56qEiRc6oU_NMnWtbD1V4FRpC63waNCUm9jdQ=.8b434d7c-8c96-42f9-8e37-4d06651da4a4@github.com>
 <M2N2txL2370OJ-NMxgkQ_qC15SC8cUbhTcFKo--AiP4=.45b41468-c1d9-4378-ac74-48a467113baf@github.com>
Message-ID: <MqJOxFQxAN-Fp0b4fo5rCiBSvaZCIuxghdqn9AhmzNA=.a892b057-9743-40bf-8032-e5ba3cb6345e@github.com>

On Mon, 28 Apr 2025 18:56:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sounds good, this was just FYI.
>
> I may be wrong, but it seems you only re-enable 3DES to test a non-TLS 1.3 cipher suite. But you don't have to use a 3DES suite to do that, you could use one of the suites that are already enabled (and are still considered strong), like "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256".
> 
> As a general comment, I would avoid re-enabling broken or disabled algorithms unless you specifically have to test that algorithm for some reason.

Thanks for pointing it out. Re-enabling was removed in 368f9b58736e4eb4f37d043ecd4df28d316fec49, and we will replace the cipher suite in the next refresh of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166103818

From jpai at openjdk.org  Wed Jun 25 08:54:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jun 2025 08:54:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v2]
In-Reply-To: <d-C3dWGfCTMMvUNSJEasqpki3hPXsceVRq1Zcvk1ELs=.786376c8-68d2-48f7-8d8c-3a960d44d610@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
 <d-C3dWGfCTMMvUNSJEasqpki3hPXsceVRq1Zcvk1ELs=.786376c8-68d2-48f7-8d8c-3a960d44d610@github.com>
Message-ID: <utwMIK25ZL47maOh0egih5osEbJeJIFJuALQBXI0QVI=.6510d13b-68e5-4d0e-bf5f-ec08cef38b55@github.com>

On Fri, 25 Apr 2025 19:13:14 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>>  - http3: minor improvement to log message
>>  - http3: Artur's review - remove commented out code from test
>>  - http3: Artur's review - make methods package private
>>  - http3: qpack - allow 0 capacity when max capacity is 0
>>  - Remove flow control from stream limit comments
>>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 172:
> 
>> 170:             userSpecifiedConstraints = engine.getSSLParameters()
>> 171:                     .getAlgorithmConstraints();
>> 172:         }
> 
> Duplicate code block here and in the 2nd `forQUIC` method. We should move it to a private `getUserSpecifiedConstraints` method, like in SSLEngine and SSLSocket cases.

@dfuch this can be resolved. We followed Artur's suggestion and used a private method for this common code. It's done in commit e11998ddce124044d08c95f2c1d03f61dc20f3ed of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166182635

From dfuchs at openjdk.org  Wed Jun 25 09:02:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 25 Jun 2025 09:02:54 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <ilp-dq4Sz3lLQs-v9R-04shh7tKsaQLPBts7z5VO0zQ=.9c6aa5c9-357f-43c2-9481-e54e01f48ce4@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
 <ilp-dq4Sz3lLQs-v9R-04shh7tKsaQLPBts7z5VO0zQ=.9c6aa5c9-357f-43c2-9481-e54e01f48ce4@github.com>
Message-ID: <uDucsuhHMw9_IVrR2uo1xNxAonbsGxMQYAkKZsKuiAI=.b0dded6a-34a0-4dab-9667-024ff6ede6fd@github.com>

On Wed, 4 Jun 2025 17:43:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 506 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: update H3InsertionsLimitTest to start after receival of client settings
>>  - merge latest changes from master branch
>>  - quic: separate out the idle termination timer and the STREAM_DATA_BLOCKED timer
>>  - quic: simplify idle timeout management
>>  - http3: rely on the sole isOpen() method instead of isOpen() and isClosed()
>>  - quic: do not let h3 idle (in pool) timeout to influence the quic transport idle timeout
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - ... and 496 more: https://git.openjdk.org/jdk/compare/8d33ea73...d4984d5e
>
> src/java.net.http/share/classes/jdk/internal/net/http/hpack/ISO_8859_1.java line 43:
> 
>> 41: // The encoding is simple and well known: 1 byte <-> 1 char
>> 42: //
>> 43: final class ISO_8859_1 {
> 
> OK - this class is actually used in QPack as well as HPack. Same for the `QuickHuffman` class below (notice that this is Quick - not Quic ;-) )
> 
> It might be interesting to investigate if we could pull out these classes to a common location to break the tie between QPack and HPack. Something to think about after integration maybe.

@AlekseiEfimov I am resolving this conversation now. Something we could think about later!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166201911

From djelinski at openjdk.org  Wed Jun 25 11:04:41 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Jun 2025 11:04:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <oGSPDZ3vfqSMEE64wxCFmFw9MSgZV0eWGKbmvFQetXM=.ce8d8479-bbf8-4af2-8ed9-f70bfad1b8f3@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <fopFSoDFZHwFvMU9afn5Z0GeiECsjaMNr0ng4-rtXAQ=.72243a2e-a505-4e2b-943c-9ec644d47a4b@github.com>
 <oGSPDZ3vfqSMEE64wxCFmFw9MSgZV0eWGKbmvFQetXM=.ce8d8479-bbf8-4af2-8ed9-f70bfad1b8f3@github.com>
Message-ID: <kukozivajzBYdadZ_CUaHlIktZAcrymye1v_duXMZ44=.3e3cabab-1ce5-46e5-9e2f-a7f52c39dc49@github.com>

On Tue, 10 Jun 2025 22:55:31 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1221:
>> 
>>> 1219:                         tm.checkClientTrusted(
>>> 1220:                                 certs.clone(),
>>> 1221:                                 authType);
>> 
>> This call doesn't check against `SSLAlgorithmConstraints` unlike 2 calls for `SSLSocket` and `SSLEngine` above.
>
> What would be the reason it's not addressed like in `checkServerCerts` below?

That will be addressed in the next update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166438709

From myankelevich at openjdk.org  Wed Jun 25 14:01:15 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 25 Jun 2025 14:01:15 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v4]
In-Reply-To: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
Message-ID: <PCI99TNLb1gLTIZZscnrJCs7YE6yGgiHLqGTfyBi828=.06968641-8ab0-4548-b4b6-a5e7b3a77557@github.com>

> * added an automated mixed case option
> * using multithreading now
> * added logs for simpler debug
> * added missing -Djava.security.auth.debug coverage

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

  reverting to have only the mixed case to keep the test more consise and still cover toLowerCase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25391/files
  - new: https://git.openjdk.org/jdk/pull/25391/files/f23f2545..df17d7de

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

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

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

From myankelevich at openjdk.org  Wed Jun 25 14:01:15 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 25 Jun 2025 14:01:15 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v3]
In-Reply-To: <53tFQIIUgJaJFDLzEpcEYOjsMzz4JXhQupjzZDQ3iUQ=.417b5005-5d14-4dfb-8ae0-44b6bdc79a8a@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <53tFQIIUgJaJFDLzEpcEYOjsMzz4JXhQupjzZDQ3iUQ=.417b5005-5d14-4dfb-8ae0-44b6bdc79a8a@github.com>
Message-ID: <eWHPDNc65o5f7QkZiGO93OGTLcsbrV3E71WqhCtz1VU=.d5a20393-c3b3-48b0-8e64-3c47182617fe@github.com>

On Tue, 24 Jun 2025 10:41:29 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments & split test to 3

@koushikthirupattur @coffeys brought the cases to mixed case only in order to still test everything, but no going into the testing of the implementation of the `toLowerCase()`

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

PR Comment: https://git.openjdk.org/jdk/pull/25391#issuecomment-3004884445

From jlu at openjdk.org  Wed Jun 25 17:01:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 17:01:42 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
 <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>
Message-ID: <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com>

On Wed, 25 Jun 2025 00:27:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:
>> 
>>> 47: .Principal.=\t????\u0020
>>> 48: .Public.Credential.=\t??????:\u0020
>>> 49: .Private.Credential.=\t??????:\u0020
>> 
>> Why aren't the 2 lines above updated like in lines 46 and 47?
>
> I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.
> 
> I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.

If the context for these 2 values makes sense to use the full-width colon then let's update them here and we can file an issue with the translation team to get them synced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167196792

From achung at openjdk.org  Wed Jun 25 17:08:20 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 17:08:20 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:

 - update majorticks translation
 - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761
 - fix colon in chinese security.properties file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/97f3fe37..67990651

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

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

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

From achung at openjdk.org  Wed Jun 25 17:14:30 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 17:14:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
 <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>
 <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com>
Message-ID: <CMnvjWZDePPSAZ69wSOKZLnscDx2R5vNhJAw1OkZTi8=.c81ae441-6667-41df-8e84-2eeec2fb3d15@github.com>

On Wed, 25 Jun 2025 16:59:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.
>> 
>> I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.
>
> If the context for these 2 values makes sense to use the full-width colon then let's update them here and we can file an issue with the translation team to get them synced.

There's more full width colons spread around in different properties files and I think the translation team just revisits lines and decides to change the colon, so these changes look a bit random to us. I've updated these specific colons to full width for now but I think it might be better to just let the translation team update them for each drop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167222866

From sean.mullan at oracle.com  Wed Jun 25 17:28:06 2025
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 25 Jun 2025 13:28:06 -0400
Subject: Result: New Security Group Member: Hai-May Chao
Message-ID: <8170ab85-7703-4ce1-aef6-a14558a22978@oracle.com>

The vote for Hai-May Chao [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Sean Mullan

[1] https://mail.openjdk.org/pipermail/security-dev/2025-June/046561.html

From abarashev at openjdk.org  Wed Jun 25 19:51:41 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 25 Jun 2025 19:51:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
 <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
Message-ID: <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>

On Wed, 25 Jun 2025 07:42:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 247:
>> 
>>> 245:         if (quicEngine != null) {
>>> 246:             if (quicEngine instanceof QuicTLSEngineImpl engineImpl) {
>>> 247:                 return engineImpl.getAlgorithmConstraints();
>> 
>> Any particular reason constraints selection code was moved to `engineImpl.getAlgorithmConstraints()` and not kept in this file for consistency with `SSLEngine` and `SSLSocket`?
>
> Hello Artur, we currently don't expose the `HandshakeContext` outside of the `QuicTLSEngineImpl`. The `HandshakeContext` is what is needed to get the relevant user specified algorithm constraints. So I decided to let the `HandshakeContext` be an internal detail in `QuicTLSEngineImpl` and introduce the `getAlgorithmConstraints()` method on it. Do you think we should hand out the `HandshakeContext` outside of `QuicTLSEngineImpl`?

Hi Jaikiran! Sounds good. It's likely we are going to re-work this code anyhow when we make QUIC engine public in the next iteration. We had a discussion with Daniel about it today.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2167491992

From achung at openjdk.org  Wed Jun 25 20:22:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 20:22:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6]
In-Reply-To: <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
Message-ID: <Bot3EolwZjhUb3m62TbiB2D7LtowSu6VLXRIBmM2XfI=.92f0274b-629b-4b02-b25e-ecb71ff7f3c8@github.com>

On Wed, 25 Jun 2025 17:08:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update majorticks translation
>  - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761
>  - fix colon in chinese security.properties file

Currently running tests and everything looks green so far, @aivanov-jdk @sormuras do the German localizations look fine?

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-3006029100

From jlu at openjdk.org  Wed Jun 25 20:56:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 20:56:07 GMT
Subject: RFR: 8360416: Incorrect l10n test case in
 sun/security/tools/keytool/i18n.java
Message-ID: <hD3hQLALgIpr8CivQ9svfCBiNIH7BlNeUfjoCBTIq_k=.f3a1a25a-2b4a-404f-8181-a955244cd7ab@github.com>

Please review this PR which removes an incorrect localization test case in _sun/security/tools/keytool/i18n.java_. The manual test was identified to not emit any localized output for an incorrect `keystore` password via "-storepass". However, this message is not localized and there are no plans to localize it.

The test should be updated to remove this test case.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Wed Jun 25 21:19:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 21:19:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6]
In-Reply-To: <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
Message-ID: <7w3okXKFhjzXb1zG6J-pfS1skbQqOsmKnt9Wpxap83o=.1fb9f308-b219-4acb-9b75-8de05c43055d@github.com>

On Wed, 25 Jun 2025 17:08:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update majorticks translation
>  - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761
>  - fix colon in chinese security.properties file

Overall looks correct to me, and it seems you addressed all of the suggestions left by other reviewers. I skimmed most of the files for any glaring issues and also spot checked a few to make sure their associated English file had the correct corresponding change.

Left some small comments which should be addressed.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties line 36:

> 34: MSG_Help_mac_install=\  --mac-dmg-content <Pfad zu zus?tzlichem Inhalt>[,<Pfad zu zus?tzlichem Inhalt>...]\n          Nimmt den gesamten referenzierten Inhalt in die DMG-Datei auf.\n          Diese Option kann mehrmals verwendet werden. \n
> 35: MSG_Help_mac_launcher=\  --mac-package-identifier <ID-Zeichenfolge>\n          Eine ID, die die Anwendung f?r macOS eindeutig identifiziert\n          Standardwert ist der Hauptklassenname.\n          Es d?rfen nur alphanumerische Zeichen (A-Z, a-z, 0-9), Bindestriche (-)\n          und Punkte (.) verwendet werden.\n  --mac-package-name <Namenszeichenfolge>\n          Name der Anwendung, wie in der Men?leiste angezeigt\n          Dieser kann vom Anwendungsnamen abweichen.\n          Er darf maximal 15 Zeichen enthalten und muss f?r die Anzeige\n          in der Men?leiste und im Infofenster der Anwendung geeignet sein.\n          Standardwert: Anwendungsname.\n  --mac-package-signing-prefix <Pr?fixzeichenfolge>\n          Beim Signieren des Anwendungspackages wird dieser Wert\n          allen zu signierenden Komponenten ohne vorhandene\n          Package-ID als Pr?fix vorangestellt.\n  --mac-sign\n          Anforderung zum Signieren des Packages oder des vordefinierten\n
 Anwendungsimages\n  --mac-signing-keychain <Schl?sselbundname>\n          Name des Schl?sselbundes f?r die Suche nach der Signaturidentit?t\n          Bei fehlender Angabe werden die Standardschl?sselbunde verwendet.\n  --mac-signing-key-user-name <Teamname>\n          Team- oder Benutzernamensteil der Apple-Signaturidentit?ten. Um direkt zu steuern,\n          welche Signaturidentit?t zum Signieren eines Anwendungsimages oder\n          Installationsprogramms verwendet wird, verwenden Sie --mac-app-image-sign-identity und/oder\n          --mac-installer-sign-identity. Diese Option kann nicht mit\n          --mac-app-image-sign-identity oder --mac-installer-sign-identity kombiniert werden.\n  --mac-app-image-sign-identity <identity>\n          Zum Signieren des Anwendungsimages verwendete Identit?t. Dieser Wert wird\n          direkt an die Option --sign des Tools "codesign" ?bergeben. Diese Option kann nicht\n          mit --mac-signing-key-user-name kombiniert werden.\n  
 --mac-installer-sign-identity <identity>\n          Zum Signieren des Installationsprogramms "pkg" verwendete Identit?t. Dieser Wert wird\n          direkt an die Option --sign des Tools "productbuild" ?bergeben. Diese Option\n          kann nicht mit --mac-signing-key-user-name kombiniert werden.\n  --mac-app-store\n          Gibt an, dass die jpackage-Ausgabe f?r den\n          Mac App Store bestimmt ist.\n  --mac-entitlements <Dateipfad>\n          Pfad zu einer Datei mit Berechtigungen, die beim Signieren\n          von ausf?hrbaren Dateien und Librarys im Bundle verwendet werden sollen.\n  --mac-app-category <Kategoriezeichenfolge>\n          Zeichenfolge f?r das Erstellen von LSApplicationCategoryType in\n          Anwendungs-plist. Standardwert: "utilities".\n
> 36: MSG_Help_linux_install=\  --linux-package-name <Packagename>\n          Name f?r das Linux-Package, Standardwert: Anwendungsname\n  --linux-deb-maintainer <E-Mail-Adresse>\n          Maintainer f?r .deb-Package\n  --linux-menu-group <Men?gruppenname>\n          Men?gruppe, in der diese Anwendung abgelegt wird\n  --linux-package-deps <package-dep-string>\n          Erforderliche Packages oder Funktionen f?r die Anwendung\n  --linux-rpm-license-type <Typzeichenfolge>\n          Typ der Lizenz ("License: <Wert>" der RPM-SPEC-Datei)\n  --linux-app-release <Releasewert>\n          Releasewert der RPM-SPEC-Datei <Name> oder \n          Debian-Revisionswert der DEB-Kontrolldatei\n  --linux-app-category <Kategoriewert>\n          Gruppenwert der RPM-SPEC-Datei <Name> oder \n          Abschnittswert der DEB-Kontrolldatei\n  --linux-shortcut\n          Erstellt eine Verkn?pfung f?r die Anwendung.\n

"package-dep-string" is within "<>" and should not be translated. ja and zh_CN locales remain un-translated as well. I'd like this particular one to be reverted back and we can file an issue with the translation team.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_en.wxl line 1:

> 1: <?xml version="1.0" encoding="utf-8"?>

This change can be reverted, the English file should not be touched anyways during l10n.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959683606
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167643767
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167645253

From achung at openjdk.org  Wed Jun 25 21:28:16 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 21:28:16 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  revert german translation, revert english wxl format change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/67990651..d54f457d

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

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

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

From rhalade at openjdk.org  Wed Jun 25 21:35:28 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 25 Jun 2025 21:35:28 GMT
Subject: RFR: 8360416: Incorrect l10n test case in
 sun/security/tools/keytool/i18n.java
In-Reply-To: <hD3hQLALgIpr8CivQ9svfCBiNIH7BlNeUfjoCBTIq_k=.f3a1a25a-2b4a-404f-8181-a955244cd7ab@github.com>
References: <hD3hQLALgIpr8CivQ9svfCBiNIH7BlNeUfjoCBTIq_k=.f3a1a25a-2b4a-404f-8181-a955244cd7ab@github.com>
Message-ID: <OYBECtMkC1fJgbg-UpLs4mc3xc7Xv11DFWhaCbeNzgU=.c73831d3-344e-49f1-85a6-7f7b400aa789@github.com>

On Wed, 25 Jun 2025 20:50:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes an incorrect localization test case in _sun/security/tools/keytool/i18n.java_. The manual test was identified to not emit any localized output for an incorrect `keystore` password via "-storepass". However, this message is not localized and there are no plans to localize it.
> 
> The test should be updated to remove this test case.

test/jdk/sun/security/tools/keytool/i18n.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 4348369 8076069 8294994 8360416

instead, please use [8360400](https://bugs.openjdk.org/browse/JDK-8360400) bug id in bug list. It is closed as won't fix for which test is being updated. We prefer not to use test bugs in this list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25989#discussion_r2167673211

From jlu at openjdk.org  Wed Jun 25 21:43:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 21:43:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <L30V0OupKPnDuj1v0M_paL96VPnJ4FBQpxbR-csL9qw=.c5a4c608-2a73-4002-95ad-7af701fad29e@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959749881

From jlu at openjdk.org  Wed Jun 25 21:56:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 21:56:10 GMT
Subject: RFR: 8360416: Incorrect l10n test case in
 sun/security/tools/keytool/i18n.java [v2]
In-Reply-To: <hD3hQLALgIpr8CivQ9svfCBiNIH7BlNeUfjoCBTIq_k=.f3a1a25a-2b4a-404f-8181-a955244cd7ab@github.com>
References: <hD3hQLALgIpr8CivQ9svfCBiNIH7BlNeUfjoCBTIq_k=.f3a1a25a-2b4a-404f-8181-a955244cd7ab@github.com>
Message-ID: <UqdZBuP6sMvHt4d_5vHsnDR4KwYjly-ZlC9-42429Ms=.b3e1c697-805a-4a6c-9960-1f52a7670415@github.com>

> Please review this PR which removes an incorrect localization test case in _sun/security/tools/keytool/i18n.java_. The manual test was identified to not emit any localized output for an incorrect `keystore` password via "-storepass". However, this message is not localized and there are no plans to localize it.
> 
> The test should be updated to remove this test case.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Rajan review - swap Jtreg header bug ID

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25989/files
  - new: https://git.openjdk.org/jdk/pull/25989/files/48ab4255..c47a428e

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

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

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

From myankelevich at openjdk.org  Wed Jun 25 22:11:31 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 25 Jun 2025 22:11:31 GMT
Subject: RFR: 8343395: SSLLogger doesn't work for formatted messages [v2]
In-Reply-To: <PBaQHCrnQEHmaKOn_nnOk6Nw_ccC0g0-P-hdhWVD_os=.139016b5-40ed-4065-a7f7-a50f0390fbfc@github.com>
References: <8LMrAnXCSETOu-fbdRWdR9SOQ817uAh_IGuWs5D4ZvU=.99876215-1c2d-4c60-82cc-efbeb72cc33a@github.com>
 <PBaQHCrnQEHmaKOn_nnOk6Nw_ccC0g0-P-hdhWVD_os=.139016b5-40ed-4065-a7f7-a50f0390fbfc@github.com>
Message-ID: <fNQW8b67kAzmQqBpvrFQES6MLTpU0MOx0lJLRGQ3bOc=.49c358ee-30fa-42cc-b93c-89fc0c4440cb@github.com>

On Tue, 24 Jun 2025 11:44:44 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> SLSLogger is broken when used with with `System.Logger` (-Djavax.net.debug mode)
>> 
>> SSL Debug messages don't use format specifiers. As a result, any custom format data isn't printed. Proposed solution is to append the SSL custom format output to the original debug message. Similar approach used for `SSLConsoleLogger ` mode.
>> 
>> Used this opportunity to delete some old commented code and to replace use of `"\n"` with `System.lineSeparator()`
>> 
>> DebugPropertyValuesTest also updated to test new logic.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Text Blocks use \n by default

src/java.base/share/classes/sun/security/ssl/Utilities.java line 154:

> 152:         StringBuilder builder = new StringBuilder();
> 153:         if (source == null) {
> 154:              builder.append(LINE_SEP).append(prefix).append("<blank message>");

I don't think this ls covered by the test. Could you please add an empty case to cover this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25934#discussion_r2167723782

From jlu at openjdk.org  Wed Jun 25 22:55:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 22:55:33 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
 <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
 <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>
Message-ID: <9xiUCl6NKMT520fpbnfGriItpYYHh93M9Gn2T5nfEIE=.3e8ab340-855f-47cb-87ba-1d3275a37598@github.com>

On Tue, 24 Jun 2025 14:58:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".
>
> Some people like to insert a space between a Chinese character and a Latin letter. I?m not a fan of this style, but I don?t feel strongly about it. However, adding a space between two Chinese characters or between a Chinese character and a full-width punctuation mark is unusual.

As discussed offline, since there are many instances of this, we will file an issue with the translation team and see if they will agree to the suggested changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167774594

From dnguyen at openjdk.org  Thu Jun 26 00:18:39 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 26 Jun 2025 00:18:39 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <Qjn1b786Q_fqBZXGYAGl3IMk-YzmCrxtqRKk89XCng4=.e49c60eb-2751-41b4-ab25-283c00b3bb4d@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959999177

From jpai at openjdk.org  Thu Jun 26 01:07:44 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Jun 2025 01:07:44 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
 <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
 <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>
Message-ID: <pdvp8wxixS97HINttsn0fe2GujbNR_izHQMG_ONNFR8=.6e2e2b37-c841-4f84-bc5f-c44197f9baea@github.com>

On Wed, 25 Jun 2025 19:48:47 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hello Artur, we currently don't expose the `HandshakeContext` outside of the `QuicTLSEngineImpl`. The `HandshakeContext` is what is needed to get the relevant user specified algorithm constraints. So I decided to let the `HandshakeContext` be an internal detail in `QuicTLSEngineImpl` and introduce the `getAlgorithmConstraints()` method on it. Do you think we should hand out the `HandshakeContext` outside of `QuicTLSEngineImpl`?
>
> Hi Jaikiran! Sounds good. It's likely we are going to re-work this code anyhow when we make QUIC engine public in the next iteration. We had a discussion with Daniel about it today.

Thank you Artur.

@dfuch this conversation can be resolved too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2167888998

From duke at openjdk.org  Thu Jun 26 02:12:20 2025
From: duke at openjdk.org (Lei Zhu)
Date: Thu, 26 Jun 2025 02:12:20 GMT
Subject: RFR: 8360166: CodeSource.implies(): Wildcard host fails to imply
 specific host
Message-ID: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>

Please review this PR which use hostname not cname to check imply. And alse add test case.

If there are any problems please let me know and I will correct them promptly.

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

Commit messages:
 - 8360166: CodeSource.implies(): Wildcard host fails to imply specific host

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

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

From duke at openjdk.org  Thu Jun 26 03:42:14 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Thu, 26 Jun 2025 03:42:14 GMT
Subject: RFR: 8349946: Cipher javadoc could describe AEAD reuse better [v3]
In-Reply-To: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
References: <uwH_uk151cw78xCvd_gCY43WjbV6fiEtQOHuVeXG15E=.648e5d34-9ede-4abd-9ba8-a5918fbf4f7f@github.com>
Message-ID: <NJgp_BMZx6fURFQObCQ9glRDoDXvvvNvhCtBHNgtpCs=.2d65495b-68e8-44d5-8e70-e4d92cce0942@github.com>

> The class documentation in javax.crypto.Cipher could better describe AEAD and reuse. The current class description example is outdated as GCM encryption does not allow resets. The doc should state that reset() may not be possible with some algorithms or providers and that an InvalidAlgorithmParameterException is thrown

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

  8349946: Cipher javadoc could describe AEAD reuse better

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25399/files
  - new: https://git.openjdk.org/jdk/pull/25399/files/8d8446e3..fcc5baba

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

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

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

From cstein at openjdk.org  Thu Jun 26 05:23:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 26 Jun 2025 05:23:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <4Yu9Xo_LEoSLn6WwWbZB5GoLk0YroJfIT8B2izB5Y2k=.372e1dfb-bf3f-4ca7-be8c-edf13e87533c@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

German `_de` translations look good to me.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2960590912

From alanb at openjdk.org  Thu Jun 26 06:26:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jun 2025 06:26:27 GMT
Subject: RFR: 8360166: CodeSource.implies(): Wildcard host fails to imply
 specific host
In-Reply-To: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
References: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
Message-ID: <wELEjWaYJps-GT7gnvVqWalPLKOB_90XbxtHFSJT8UI=.accdc86c-fb69-4e2f-89b5-8445ce0b7c5f@github.com>

On Thu, 26 Jun 2025 01:43:51 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Please review this PR which use hostname not cname to check imply. And alse add test case.
> 
> If there are any problems please let me know and I will correct them promptly.

JDK-8356557 tracks updating CodeSource.imples so that it is not dependent on SocketPermission. This would move things on so that SocketPermission can be deprecated for removal (several permission classes have been deprecated for removal in JDK 25, but SocketPermission couldn't be done at the same time).

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

PR Comment: https://git.openjdk.org/jdk/pull/25991#issuecomment-3007269516

From duke at openjdk.org  Thu Jun 26 06:33:28 2025
From: duke at openjdk.org (Lei Zhu)
Date: Thu, 26 Jun 2025 06:33:28 GMT
Subject: RFR: 8360166: CodeSource.implies(): Wildcard host fails to imply
 specific host
In-Reply-To: <wELEjWaYJps-GT7gnvVqWalPLKOB_90XbxtHFSJT8UI=.accdc86c-fb69-4e2f-89b5-8445ce0b7c5f@github.com>
References: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
 <wELEjWaYJps-GT7gnvVqWalPLKOB_90XbxtHFSJT8UI=.accdc86c-fb69-4e2f-89b5-8445ce0b7c5f@github.com>
Message-ID: <5EU5mNIFWIGLqbStWtPSg-82RmxNH0cgCk_pKag1Z-g=.2cc22def-be09-4d4b-b062-e8f4c9c213d1@github.com>

On Thu, 26 Jun 2025 06:24:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JDK-8356557 tracks updating CodeSource.imples so that it is not dependent on SocketPermission. This would move things on so that SocketPermission can be deprecated for removal (several permission classes have been deprecated for removal in JDK 25, but SocketPermission couldn't be done at the same time).

Thanks for replying, I will close this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25991#issuecomment-3007295972

From coffeys at openjdk.org  Thu Jun 26 11:05:58 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 26 Jun 2025 11:05:58 GMT
Subject: RFR: 8044609: javax.net.debug options not working and documented
 as expected [v14]
In-Reply-To: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
References: <Tth06aWpRD2Tu_Oe0dJ4Nl7FvTMtHPBc4smmOAR4I2E=.2b515cad-3e7c-4839-8dc5-fc93680b90a1@github.com>
Message-ID: <zwEmQfvo_vS_Ix7vRJIZcxwj3uz-m9Px0UpprKedhaY=.992f7780-942e-4567-9f30-addd33617122@github.com>

> The `javax.net.debug` TLS debug option is buggy since TLSv1.3 implementation was introduced many years ago.
> 
> Where "ssl" was previously a value to obtain all TLS debug traces (except network type dumps, verbose data), it now prints only a few lines for a standard client TLS connection. 
> 
> The property parsing was also lax and allowed users to declare verbose logging options by themselves where the documentation stated that such verbose options were only meant to be used in conjunction with other TLS options :
> 
> 
>         System.err.println("help           print the help messages");
>         System.err.println("expand         expand debugging information");
>         System.err.println();
>         System.err.println("all            turn on all debugging");
>         System.err.println("ssl            turn on ssl debugging");
>         System.err.println();
>         System.err.println("The following can be used with ssl:");
>         System.err.println("\trecord       enable per-record tracing");
>         System.err.println("\thandshake    print each handshake message");
>         System.err.println("\tkeygen       print key generation data");
>         System.err.println("\tsession      print session activity");
>         System.err.println("\tdefaultctx   print default SSL initialization");
>         System.err.println("\tsslctx       print SSLContext tracing");
>         System.err.println("\tsessioncache print session cache tracing");
>         System.err.println("\tkeymanager   print key manager tracing");
>         System.err.println("\ttrustmanager print trust manager tracing");
>         System.err.println("\tpluggability print pluggability tracing");
>         System.err.println();
>         System.err.println("\thandshake debugging can be widened with:");
>         System.err.println("\tdata         hex dump of each handshake message");
>         System.err.println("\tverbose      verbose handshake message printing");
>         System.err.println();
>         System.err.println("\trecord debugging can be widened with:");
>         System.err.println("\tplaintext    hex dump of record plaintext");
>         System.err.println("\tpacket       print raw SSL/TLS packets");
> 
> 
> as part of this patch, I've also moved the log call to the more performant friendly `System.Logger#log(java.lang.System.Logger.Level,java.util.function.Supplier)` method. 
> 
> the output has changed slightly with respect to that  - less verbose
> 
> e.g. old style:
> 
> 
> javax.net.ssl|DEBUG|10|main|2024-04-12 15:47:24.302 GMT|SSLSocketOut...

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

 - Merge branch 'master' into 8044609-ssl
 - remove whitespace
 - erroneous edit to test file
 - remove legacy test and minor fix ups
 - Merge branch 'master' into 8044609-ssl
 - enums refactoring and line width correction
 - convert to enum options and refactor
 - minor refactor and clean up
 - Merge branch 'master' into 8044609-ssl
 - Merge branch 'master' into 8044609-ssl
 - ... and 21 more: https://git.openjdk.org/jdk/compare/5039b42d...9d6bbfd4

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

Changes: https://git.openjdk.org/jdk/pull/18764/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18764&range=13
  Stats: 1249 lines in 79 files changed: 458 ins; 99 del; 692 mod
  Patch: https://git.openjdk.org/jdk/pull/18764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18764/head:pull/18764

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

From dfuchs at openjdk.org  Thu Jun 26 11:07:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 11:07:45 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <pdvp8wxixS97HINttsn0fe2GujbNR_izHQMG_ONNFR8=.6e2e2b37-c841-4f84-bc5f-c44197f9baea@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
 <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
 <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>
 <pdvp8wxixS97HINttsn0fe2GujbNR_izHQMG_ONNFR8=.6e2e2b37-c841-4f84-bc5f-c44197f9baea@github.com>
Message-ID: <HbAo_8dRZqucHKQBzukLcdNAGNyoF9r4rDB9jBhWAeI=.39bedbfb-bf00-4f94-ae19-bb2ab4086a51@github.com>

On Thu, 26 Jun 2025 01:04:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi Jaikiran! Sounds good. It's likely we are going to re-work this code anyhow when we make QUIC engine public in the next iteration. We had a discussion with Daniel about it today.
>
> Thank you Artur.
> 
> @dfuch this conversation can be resolved too.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2168804498

From tigran.mkrtchyan at desy.de  Thu Jun 26 12:25:57 2025
From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran)
Date: Thu, 26 Jun 2025 14:25:57 +0200 (CEST)
Subject: Subject class creation performance optimization oportunity
Message-ID: <2066712341.480847.1750940757778.JavaMail.zimbra@desy.de>

Dear security-devs,

While benchmarking various parts of our code, I noticed unexpected (but fully explainable) behavior of how an instance of the Subject class can be created.

The intuitive one is to create a set of Principals and then pass it to the constructor. However, it turned out that creating an empty subject and populating it with desire principles is much faster:


    Benchmark                               Mode  Cnt        Score       Error  Units
    SubjectBenchmark.subjectByAddingToSet  thrpt    9  2061025.436 ? 24807.881  ops/s
    SubjectBenchmark.subjectByPassingSet   thrpt    9  1341492.178 ? 34701.882  ops/s


The reason is that the Subject class performs extra checks on the provided set, which first creates a null-clean LinkedList copy of the collection. Makes sense.
However, `Set#of` returns immutable, null clean sets, so there is no reason for an extra copy.


Best regards,
   Tigran.


The benchmark code:

```
@BenchmarkMode(Mode.Throughput)
@State(Scope.Benchmark)
public class SubjectBenchmark {


    @Benchmark
    public Subject subjectByAddingToSet() {
        Subject subject = new Subject();
        subject.getPrincipals().add(new UnixNumericUserPrincipal(0));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(0, true));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(1, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(2, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(3, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(4, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(5, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(6, false));
        subject.setReadOnly();
        return subject;
    }


    @Benchmark
    public Subject subjectByPassingSet() {

        Principal[] principals = new Principal[]{
              new UnixNumericUserPrincipal(0),
              new UnixNumericGroupPrincipal(0, true),
              new UnixNumericGroupPrincipal(1, false),
              new UnixNumericGroupPrincipal(2, false),
              new UnixNumericGroupPrincipal(3, false),
              new UnixNumericGroupPrincipal(4, false),
              new UnixNumericGroupPrincipal(5, false),
              new UnixNumericGroupPrincipal(6, false)
        };

        return new Subject(true, Set.of(principals), Set.of(), Set.of());
    }
}
```
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2826 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250626/e199e797/smime-0001.p7s>

From jpai at openjdk.org  Thu Jun 26 13:25:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Jun 2025 13:25:50 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <jvZfcaNkmERbDbJ7mXSp3TxkEPv7AjSm2AJIgAhZahw=.b0567300-9711-41e2-a079-854cd47dfbc6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <jvZfcaNkmERbDbJ7mXSp3TxkEPv7AjSm2AJIgAhZahw=.b0567300-9711-41e2-a079-854cd47dfbc6@github.com>
Message-ID: <afmL2M4nq0XFNAahf4ScMmsrMGx5GAE2esNJULn45ls=.e543668e-8ec7-4721-a389-8cb4df77a297@github.com>

On Tue, 22 Apr 2025 16:15:29 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 506 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: update H3InsertionsLimitTest to start after receival of client settings
>>  - merge latest changes from master branch
>>  - quic: separate out the idle termination timer and the STREAM_DATA_BLOCKED timer
>>  - quic: simplify idle timeout management
>>  - http3: rely on the sole isOpen() method instead of isOpen() and isClosed()
>>  - quic: do not let h3 idle (in pool) timeout to influence the quic transport idle timeout
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - ... and 496 more: https://git.openjdk.org/jdk/compare/8d33ea73...d4984d5e
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 226:
> 
>> 224:                     chc.peerSupportedAuthorities == null ? null :
>> 225:                             chc.peerSupportedAuthorities.clone(),
>> 226:                     chc.algorithmConstraints);
> 
> These `algorithmConstraints` won't include `peerSupportedSignAlgs`.

@dfuch this too can be marked as resolved. The updated code in this PR now calls `X509KeyManagerImpl.chooseClientAlias(String[] keyTypes, Principal[] issuers, QuicTLSEngineImpl quicTLSEngine)` which internally picks up the `peerSupportedSignAlgs` from the handshake session.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169064530

From dfuchs at openjdk.org  Thu Jun 26 14:17:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 14:17:45 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <afmL2M4nq0XFNAahf4ScMmsrMGx5GAE2esNJULn45ls=.e543668e-8ec7-4721-a389-8cb4df77a297@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <jvZfcaNkmERbDbJ7mXSp3TxkEPv7AjSm2AJIgAhZahw=.b0567300-9711-41e2-a079-854cd47dfbc6@github.com>
 <afmL2M4nq0XFNAahf4ScMmsrMGx5GAE2esNJULn45ls=.e543668e-8ec7-4721-a389-8cb4df77a297@github.com>
Message-ID: <jB-0b1xVLntHpirb5us68Lep8jcCKDgFLqQBbdhNLcc=.e813f3e7-2562-4014-9d60-6d0afa1b49ac@github.com>

On Thu, 26 Jun 2025 13:22:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 226:
>> 
>>> 224:                     chc.peerSupportedAuthorities == null ? null :
>>> 225:                             chc.peerSupportedAuthorities.clone(),
>>> 226:                     chc.algorithmConstraints);
>> 
>> These `algorithmConstraints` won't include `peerSupportedSignAlgs`.
>
> @dfuch this too can be marked as resolved. The updated code in this PR now calls `X509KeyManagerImpl.chooseClientAlias(String[] keyTypes, Principal[] issuers, QuicTLSEngineImpl quicTLSEngine)` which internally picks up the `peerSupportedSignAlgs` from the handshake session.

Thanks. done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169182330

From naoto at openjdk.org  Thu Jun 26 16:11:35 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jun 2025 16:11:35 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <yCfy1s78TO0A4KkM8-Dsfwel3MyFrljHZZfcOY31X6o=.9826e189-d4d2-4166-9634-e35bd79cf55d@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

Looks fine to me. Thanks, Alisen!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2962676541

From dfuchs at openjdk.org  Thu Jun 26 16:14:41 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 16:14:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <HbAo_8dRZqucHKQBzukLcdNAGNyoF9r4rDB9jBhWAeI=.39bedbfb-bf00-4f94-ae19-bb2ab4086a51@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
 <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
 <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>
 <pdvp8wxixS97HINttsn0fe2GujbNR_izHQMG_ONNFR8=.6e2e2b37-c841-4f84-bc5f-c44197f9baea@github.com>
 <HbAo_8dRZqucHKQBzukLcdNAGNyoF9r4rDB9jBhWAeI=.39bedbfb-bf00-4f94-ae19-bb2ab4086a51@github.com>
Message-ID: <DK8078guiUeaohxiP9d16rdJY4rX9HlqxsWyuBowY6E=.5aeb666f-c640-473a-ba3e-edaad0705fc1@github.com>

On Thu, 26 Jun 2025 11:04:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Thank you Artur.
>> 
>> @dfuch this conversation can be resolved too.
>
> Done

> Hi Jaikiran! Sounds good. It's likely we are going to re-work this code anyhow when we make QUIC engine public in the next iteration. We had a discussion with Daniel about it today.

Note that there's no definite plan to provide a public API for that yet. This is something that we will need to evaluate once the current iteration is integrated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169422961

From dfuchs at openjdk.org  Thu Jun 26 16:36:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 16:36:40 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:

 - merge latest changes from master branch
 - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
 - retry the ResetControlStream test as needed
 - http3: fix pending connection and reconnection on stream limit reached logic
 - http3: pending acknowledgement should be registered before actually sending the packet
 - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
 - http3: improve exceptions in Http3ServerExchange.java
 - http3: fix exception handling in CancelRequestTest.java
 - http3: review feedback - revert HPACK.java
 - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
 - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=08
  Stats: 105143 lines in 471 files changed: 102311 ins; 1336 del; 1496 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From dfuchs at openjdk.org  Thu Jun 26 17:04:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 17:04:47 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <bRfgBwVg54V3xLBoM7pkcN0f62GCRbMl0f1M0ibT3RQ=.e0d21848-79d2-458b-9310-a293f02bbf49@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 70:

> 68:         if (!(underlyingImpl instanceof SSLContextImpl ssci)) {
> 69:             return false;
> 70:         }

Would there be a way to check the implementation of the X509TrustManager here too? Or can we only do that later on during the handshake?

src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 126:

> 124:      *
> 125:      * @param peerHost The peer hostname or IP address. Can be null.
> 126:      * @param peerPort The peer port, can be -1 if the port is unknown

Would that be the hostname in the URI, or in the AltService?
Maybe we could add an `@apiNote` here to clarify it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169497642
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169502934

From aivanov at openjdk.org  Thu Jun 26 17:32:34 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 26 Jun 2025 17:32:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461:

> 459: SliderDemo.majorticks=Hauptteilstriche
> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften

@sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972).

Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised?

Should *Beschriften* rather be *Beschriftung*?

Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 463:

> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
> 462: SliderDemo.minorticks=Hilfsteilstriche
> 463: SliderDemo.minorticksdescription=Ein Schieberegler mit Haupt- und Hilfsteilstrichen, mit Teilstrichen, in die der Schieberegler einrastet, wobei einige Teilstriche mit einem sichtbaren Label versehen sind

This one is repetitive:
Suggestion:

SliderDemo.minorticksdescription=Ein Schieberegler mit Haupt- und Hilfsteilstrichen, in die der Schieberegler einrastet, wobei einige Teilstriche mit einer sichtbaren Beschriftung versehen sind

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169540017
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169535281

From dfuchs at openjdk.org  Thu Jun 26 17:32:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 17:32:50 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <PZ-Qh13ciNdoU-HCI-8y7p6kxzdz5diMz8fhqmLeMcQ=.13aa42e5-34d7-4412-b22b-13dbc299d914@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/jdk/internal/net/quic/QuicVersion.java line 33:

> 31: 
> 32: /**
> 33:  * Represents the Quic versions defined in their corresponding RFCs

Maybe add a note here to warn that new enum constants may be added to this enum in the future.

src/java.base/share/classes/jdk/internal/net/quic/QuicVersion.java line 40:

> 38:     QUIC_V2(0x6b3343cf); // RFC 9369
> 39: 
> 40:     private final int versionNumber;

Could add a comment here to say that the version is defined as a 32bits unsigned number, and we chose a simple int to represent it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169538372
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169549829

From djelinski at openjdk.org  Thu Jun 26 17:38:44 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 17:38:44 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <bRfgBwVg54V3xLBoM7pkcN0f62GCRbMl0f1M0ibT3RQ=.e0d21848-79d2-458b-9310-a293f02bbf49@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <bRfgBwVg54V3xLBoM7pkcN0f62GCRbMl0f1M0ibT3RQ=.e0d21848-79d2-458b-9310-a293f02bbf49@github.com>
Message-ID: <GPG7cbPxZnW8iIIBCLJZU84WTjiPuVHCDYEuvc6GdvQ=.1070c0c7-3006-46b0-9cd1-f72a8e2bd5b6@github.com>

On Thu, 26 Jun 2025 16:57:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 70:
> 
>> 68:         if (!(underlyingImpl instanceof SSLContextImpl ssci)) {
>> 69:             return false;
>> 70:         }
> 
> Would there be a way to check the implementation of the X509TrustManager here too? Or can we only do that later on during the handshake?

that's what the `isUsableWithQuic` method below does.

> src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 126:
> 
>> 124:      *
>> 125:      * @param peerHost The peer hostname or IP address. Can be null.
>> 126:      * @param peerPort The peer port, can be -1 if the port is unknown
> 
> Would that be the hostname in the URI, or in the AltService?
> Maybe we could add an `@apiNote` here to clarify it.

Well the javadoc here was written to match the one on SSLContext#createSSLEngine. The peer information is used for caching, but it's also used in the SNI extension, so ideally users should use the URI address, not the alt service one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169562950
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169561558

From cstein at openjdk.org  Thu Jun 26 17:44:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 26 Jun 2025 17:44:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
 <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>
Message-ID: <hFn5wmgbm5zMsnPdoOpOohNFpP1Rt1LK5xzezGmNW-g=.22beef9d-e3be-4862-819f-69da291a0c63@github.com>

On Thu, 26 Jun 2025 17:22:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert german translation, revert english wxl format change
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461:
> 
>> 459: SliderDemo.majorticks=Hauptteilstriche
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
> 
> @sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972).
> 
> Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised?
> 
> Should *Beschriften* rather be *Beschriftung*?
> 
> Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation?

You may (re-)use every German verb as a noun: [Substantivierung](https://de.wikipedia.org/wiki/Substantivierung)

> Would Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen be a better translation?

Nein. Sounds too disrupted/distorted in my ears. If you really want to make it longer, it could read like:

_Hilfsteilstriche, an denen der Schieberegler einrastet und denen Beschriftungen angebracht werden k?nnen_

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169576244

From djelinski at openjdk.org  Thu Jun 26 17:44:48 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 17:44:48 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <I8PsbJp206UJRkv1vA-GuQVq8rimRLZr1eeSZr6JDqE=.2165bb62-ae07-4f1f-8fbf-748e54450765@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <I8PsbJp206UJRkv1vA-GuQVq8rimRLZr1eeSZr6JDqE=.2165bb62-ae07-4f1f-8fbf-748e54450765@github.com>
Message-ID: <7Im8fuoKvFsClr07Sq8cJ1LhU6LuNK6U44j7_12P-P0=.ca3982f1-b4ce-4375-a1f6-595732c4e104@github.com>

On Tue, 22 Apr 2025 16:21:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 221:
> 
>> 219:                             chc.peerSupportedAuthorities.clone(),
>> 220:                     engine);
>> 221:             // TODO should we have a method that can take QuicTLSEngine?
> 
> Yes, I think we should have a method for `QuicTLSEngine` in `X509KeyManagerImpl`. In that new method we should use session's `peerSupportedSignAlgs` to construct algorithm constraints the same way we do it for `SSLSocketImpl` and for `SSLEngineImpl`. This is per TLSv1.3 RFC:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

Done in 1b75ef8b8579f4f8682bff28f40ed394401e8805

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169578294

From djelinski at openjdk.org  Thu Jun 26 18:02:47 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 18:02:47 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v2]
In-Reply-To: <sWlJhX9smaVlYnJXwnhev6rXJBTEgIackPrRITGTs9g=.efaa1edf-d0fe-4c6b-8205-a20ae68adcc0@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
 <sWlJhX9smaVlYnJXwnhev6rXJBTEgIackPrRITGTs9g=.efaa1edf-d0fe-4c6b-8205-a20ae68adcc0@github.com>
Message-ID: <xQA5Rtc-9ei4bQFRIlU-CneJjxE-NDWeiN-_PjdUXoA=.dd732c03-840f-412d-a8c6-a5f3a270f32e@github.com>

On Fri, 25 Apr 2025 19:42:34 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>>  - http3: minor improvement to log message
>>  - http3: Artur's review - remove commented out code from test
>>  - http3: Artur's review - make methods package private
>>  - http3: qpack - allow 0 capacity when max capacity is 0
>>  - Remove flow control from stream limit comments
>>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 532:
> 
>> 530:     }
>> 531: 
>> 532:     public boolean isQuic() {
> 
> This method never called.

Removed in 9f7f9e190b124d569eae8bf1df5e6c076ad00a06

> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 275:
> 
>> 273:         final X509Certificate[] trustedChain = v.validate(chain, null,
>> 274:                 responseList, constraints, authType);
>> 275:         if (sslParameters != null && handshakeSession != null) {
> 
> Looks like this `if` block is not needed: `sslParameters != null` condition is always `true`, and we should throw an exception in the beginning of the method if session is null.

Moved earlier in 10e3e3508415b901fe0008da4edb5c4f1e8eb85d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169589570
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169588546

From djelinski at openjdk.org  Thu Jun 26 18:02:49 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 18:02:49 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <BIio-Z0QtUmG0jk3kL8gxJjsOIxydScAlPb5DYbLUtQ=.4b83e750-328e-46c9-8434-aca1ea98a646@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <BIio-Z0QtUmG0jk3kL8gxJjsOIxydScAlPb5DYbLUtQ=.4b83e750-328e-46c9-8434-aca1ea98a646@github.com>
Message-ID: <hob__05VFHcenn0aV8VV6oSmD0oJ_JRqboqnTqEEDN8=.66784a2c-8d15-43a0-b959-e8057a4620a1@github.com>

On Tue, 22 Apr 2025 16:49:10 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 286:
> 
>> 284:         X509Certificate[] trustedChain = v.validate(chain, null,
>> 285:                 Collections.emptyList(),
>> 286:                 sslParameters.getAlgorithmConstraints(), authType);
> 
> SSLParameter's algorithm constraints don't include constraints specified in `java.security` config file.

Addressed in 633375f342b6dbf1fc608f9b9abc9bf15c15ada4

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169586259

From djelinski at openjdk.org  Thu Jun 26 18:02:50 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 18:02:50 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v2]
In-Reply-To: <MQP9ydYlNHaWHQMfVjWUnVXaB8To0aV9rSXgT1Pad_M=.84b03782-6aa0-4a21-85e1-3c59d7e9c7bc@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
 <MQP9ydYlNHaWHQMfVjWUnVXaB8To0aV9rSXgT1Pad_M=.84b03782-6aa0-4a21-85e1-3c59d7e9c7bc@github.com>
Message-ID: <Nx1-gHh-L6XEGFXgtEHv-cpuVh9ckOwJ1qDQLHRNhiI=.ef26aa39-16a3-4df6-8f12-b43676c50069@github.com>

On Mon, 28 Apr 2025 18:52:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>>  - http3: minor improvement to log message
>>  - http3: Artur's review - remove commented out code from test
>>  - http3: Artur's review - make methods package private
>>  - http3: qpack - allow 0 capacity when max capacity is 0
>>  - Remove flow control from stream limit comments
>>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe
>
> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 130:
> 
>> 128:                             + "expect UnsupportedProtocolVersionException",
>> 129:                     () -> connect(uriString, new SSLParameters(
>> 130:                             new String[] { "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA" },
> 
> Shouldn't this be "TLS_AES_128_GCM_SHA256" (per the test comment above)?

Corrected in 368f9b58736e4eb4f37d043ecd4df28d316fec49

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169591633

From dfuchs at openjdk.org  Thu Jun 26 18:13:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 18:13:40 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <GPG7cbPxZnW8iIIBCLJZU84WTjiPuVHCDYEuvc6GdvQ=.1070c0c7-3006-46b0-9cd1-f72a8e2bd5b6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <bRfgBwVg54V3xLBoM7pkcN0f62GCRbMl0f1M0ibT3RQ=.e0d21848-79d2-458b-9310-a293f02bbf49@github.com>
 <GPG7cbPxZnW8iIIBCLJZU84WTjiPuVHCDYEuvc6GdvQ=.1070c0c7-3006-46b0-9cd1-f72a8e2bd5b6@github.com>
Message-ID: <lHsCVZKhak3qpFTyHhcICl0hBmTgGAo082NpDWZtSD8=.629d1aa9-52cc-4337-96a6-11709b4ee40c@github.com>

On Thu, 26 Jun 2025 17:36:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 70:
>> 
>>> 68:         if (!(underlyingImpl instanceof SSLContextImpl ssci)) {
>>> 69:             return false;
>>> 70:         }
>> 
>> Would there be a way to check the implementation of the X509TrustManager here too? Or can we only do that later on during the handshake?
>
> that's what the `isUsableWithQuic` method below does.

Oh! I had missed that. Very good then!

>> src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 126:
>> 
>>> 124:      *
>>> 125:      * @param peerHost The peer hostname or IP address. Can be null.
>>> 126:      * @param peerPort The peer port, can be -1 if the port is unknown
>> 
>> Would that be the hostname in the URI, or in the AltService?
>> Maybe we could add an `@apiNote` here to clarify it.
>
> Well the javadoc here was written to match the one on SSLContext#createSSLEngine. The peer information is used for caching, but it's also used in the SNI extension, so ideally users should use the URI address, not the alt service one.

OK. Maybe that would deserve a note - since with HTTP/3 we have potentially two addresses and two ports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169650283
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169653256

From djelinski at openjdk.org  Thu Jun 26 18:13:45 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 18:13:45 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <JeKINmYcmLWz8AVolTvNOTzymhXNuV6w2mguL6VAJYg=.7f38e31b-5a56-48bf-b72e-63f829175234@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/Finished.java line 852:

> 850:                     QuicTLSEngineImpl engine =
> 851:                             (QuicTLSEngineImpl) shc.conContext.transport;
> 852:                     engine.deriveOneRTTKeys();

We should not derive the server's 1RTT read keys before processing the client's Finished message.

Also, we could skip calculating the SSL WriteCipher when QUIC is in use. Also, we're calculating the baseWriteSecret twice (deriveOneRTTKeys calculates the same secret)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169636620

From dfuchs at openjdk.org  Thu Jun 26 18:13:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 18:13:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 49:

> 47:     static final ExtensionConsumer chOnLoadConsumer =
> 48:             new CHKeyShareConsumer();
> 49:     static final HandshakeAbsence chOnTradeAbsence =

Could we fix that one in mainline to remove this file from the PR?

src/java.base/share/classes/sun/security/ssl/OutputRecord.java line 168:

> 166:         throw new UnsupportedOperationException();
> 167:     }
> 168: 

Do we need those two methods here? Or could we just have them on `QuicEngineOutputRecord` and do the appropriate cast at the point they are called?
Or do we have that at this level for performance reasons?

src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 61:

> 59:     static final HandshakeConsumer chOnTradeConsumer =
> 60:             new CHPreSharedKeyUpdate();
> 61:     static final HandshakeAbsence chOnTradeAbsence =

Could we bring this change to mainline to remove this file from this PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169560172
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169583454
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169585913

From tigran.mkrtchyan at desy.de  Wed Jun 25 07:59:55 2025
From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran)
Date: Wed, 25 Jun 2025 09:59:55 +0200 (CEST)
Subject: Subject class creation performance optimization oportunity
Message-ID: <1931152617.14103513.1750838395856.JavaMail.zimbra@desy.de>


Dear security-devs,

While benchmarking various parts of our code, I noticed unexpected (but fully explainable) behavior of how an instance of the Subject class can be created.

The intuitive one is to create a set of Principals and then pass it to the constructor. However, it turned out that creating an empty subject and populating it with desire principles is much faster:


    Benchmark                               Mode  Cnt        Score       Error  Units
    SubjectBenchmark.subjectByAddingToSet  thrpt    9  2061025.436 ? 24807.881  ops/s
    SubjectBenchmark.subjectByPassingSet   thrpt    9  1341492.178 ? 34701.882  ops/s


The reason is that the Subject class performs extra checks on the provided set, which first creates a null-clean LinkedList copy of the collection. Makes sense.
However, `Set#of` returns immutable, null clean sets, so there is no reason for an extra copy.


Best regards,
   Tigran.


The benchmark code:

```
@BenchmarkMode(Mode.Throughput)
@State(Scope.Benchmark)
public class SubjectBenchmark {


    @Benchmark
    public Subject subjectByAddingToSet() {
        Subject subject = new Subject();
        subject.getPrincipals().add(new UnixNumericUserPrincipal(0));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(0, true));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(1, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(2, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(3, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(4, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(5, false));
        subject.getPrincipals().add(new UnixNumericGroupPrincipal(6, false));
        subject.setReadOnly();
        return subject;
    }


    @Benchmark
    public Subject subjectByPassingSet() {

        Principal[] principals = new Principal[]{
              new UnixNumericUserPrincipal(0),
              new UnixNumericGroupPrincipal(0, true),
              new UnixNumericGroupPrincipal(1, false),
              new UnixNumericGroupPrincipal(2, false),
              new UnixNumericGroupPrincipal(3, false),
              new UnixNumericGroupPrincipal(4, false),
              new UnixNumericGroupPrincipal(5, false),
              new UnixNumericGroupPrincipal(6, false)
        };

        return new Subject(true, Set.of(principals), Set.of(), Set.of());
    }
}
```
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2826 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250625/5f9f8256/smime.p7s>

From aleonard at openjdk.org  Thu Jun 26 20:40:47 2025
From: aleonard at openjdk.org (Andrew Leonard)
Date: Thu, 26 Jun 2025 20:40:47 GMT
Subject: RFR: 8352728: InternalError loading java.security due to Windows
 parent folder permissions
In-Reply-To: <LnFuoP37qAyiajKGjdk1rRQHDtFZpN6TiUBDjBxHygs=.cc96ef7c-fd3a-4e6e-8893-d5eed8080fd1@github.com>
References: <0I5M5wETz0F1QEcqYFoBC0SEv_rgrJc1kPSWFtKrhL0=.114cf249-4f78-4d03-90c2-2925ad4cd155@github.com>
 <VOpnIb1YIv419CudMEK6ftGQ0a6OSolUquaAO63BKtI=.7a414618-6d5a-4b8f-9a9c-3c35e7655960@github.com>
 <LnFuoP37qAyiajKGjdk1rRQHDtFZpN6TiUBDjBxHygs=.cc96ef7c-fd3a-4e6e-8893-d5eed8080fd1@github.com>
Message-ID: <Q9wtXhUV_b6qKASJKKNoXWT-5g_yOqmBxkSFJ5YgSyo=.e415bbb2-1297-45aa-a6ef-5209f9598512@github.com>

On Wed, 30 Apr 2025 17:36:52 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>>> File::getCanonicalPath seems to take the best-effort approach (both in Linux and Windows), whereas Path::toRealPath is stricter.
>> 
>> Path::toRealPath is doing the right thing, and consistent with realpath(2). The issue with File::getCanonicalXXX is that it is specified to return a canonical file even if it doesn't exist, so this is why you see a lot more code to compute a result.
>> 
>> Maybe the recursive include check them maybe it should use the file key instead.
>
> @AlanBateman are you ok with letting the original c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab reviewers know of this fix and take a look? Or do you think further discussion is needed somewhere else?

@franferrax Is there any progress on this fix please?

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

PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-2969670841

From achung at openjdk.org  Thu Jun 26 20:56:39 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 26 Jun 2025 20:56:39 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v8]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <wde0M3LUuqMdILh7rklStZmGCU3jZKf0ruVujEePt0c=.3601d7c3-7e4c-494c-9599-be3adb908f4e@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/d54f457d..dcce2a39

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

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

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

From achung at openjdk.org  Thu Jun 26 20:56:40 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 26 Jun 2025 20:56:40 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <hFn5wmgbm5zMsnPdoOpOohNFpP1Rt1LK5xzezGmNW-g=.22beef9d-e3be-4862-819f-69da291a0c63@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
 <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>
 <hFn5wmgbm5zMsnPdoOpOohNFpP1Rt1LK5xzezGmNW-g=.22beef9d-e3be-4862-819f-69da291a0c63@github.com>
Message-ID: <SglYkl97hMPTI35H7e9VncJTC3GWAW2mRgU72vGs3eI=.d8f3e462-116e-4530-bc97-bb4cab345fb7@github.com>

On Thu, 26 Jun 2025 17:41:13 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461:
>> 
>>> 459: SliderDemo.majorticks=Hauptteilstriche
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>>> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
>> 
>> @sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972).
>> 
>> Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised?
>> 
>> Should *Beschriften* rather be *Beschriftung*?
>> 
>> Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation?
>
> You may (re-)use every German verb as a noun: [Substantivierung](https://de.wikipedia.org/wiki/Substantivierung)
> 
>> Would Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen be a better translation?
> 
> Nein. Sounds too disrupted/distorted in my ears. If you really want to make it longer, it could read like:
> 
> _Hilfsteilstriche, an denen der Schieberegler einrastet und denen Beschriftungen angebracht werden k?nnen_

Maybe better to leave this one as is and next drop the translation team can take another look

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169956970

From abarashev at openjdk.org  Thu Jun 26 21:43:54 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 26 Jun 2025 21:43:54 GMT
Subject: RFR: 8360539: DTLS handshakes fails due to improper cookie validation
 logic
Message-ID: <P3zzaM5pCrrIFBkJzbQJrrwVIsRHn-8xiXdz27eWx6A=.a58f780c-5b0b-47da-aa04-b2e6bf33f9d6@github.com>

DESCRIPTION OF THE PROBLEM:
There appears to be a bug in the isCookieValid method of HelloCookieManager that can lead to improper cookie validation results after a new cookieSecret is generated. The cookie version (cookieVersion) is initialized with a random number and increments with each cookie, regenerating the secret every 0xFFFFFF cookies.

When cookieVersion is negative, the expression ((cookieVersion >> 24) & 0xFF) results in an integer that does not match the signed byte value in cookie[0], causing the else clause to be executed incorrectly. This leads to the use of legacySecret even for valid cookies.

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

Commit messages:
 - 8360539: DTLS handshakes fails due to improper cookie validation logic

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

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

From weijun at openjdk.org  Thu Jun 26 22:40:04 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 26 Jun 2025 22:40:04 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v20]
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: <cP0ZZ_CZkAJ5TsH8KOo190O_jDiGLH4ljuF2nRg2r3g=.ba2415e8-7155-4199-beaf-1fedb912f598@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> ![HPKEParameterSpec ? 11 54 ? 04-21](https://github.com/user-attachments/assets/da309585-db51-40d6-b291-3d38040d6292)

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

 - no more of()
 - extract and expand

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/f819de2e..30c79948

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

  Stats: 246 lines in 5 files changed: 23 ins; 178 del; 45 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 ascarpino at openjdk.org  Thu Jun 26 22:53:43 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 26 Jun 2025 22:53:43 GMT
Subject: RFR: 8360539: DTLS handshakes fails due to improper cookie
 validation logic
In-Reply-To: <P3zzaM5pCrrIFBkJzbQJrrwVIsRHn-8xiXdz27eWx6A=.a58f780c-5b0b-47da-aa04-b2e6bf33f9d6@github.com>
References: <P3zzaM5pCrrIFBkJzbQJrrwVIsRHn-8xiXdz27eWx6A=.a58f780c-5b0b-47da-aa04-b2e6bf33f9d6@github.com>
Message-ID: <yWtvIjPTkqEY-8ocKC7mLr7jFI9YoJjXPjtj7Cr7F4Q=.7ca42055-c0dc-42c9-a32e-e79af9aaa780@github.com>

On Thu, 26 Jun 2025 21:36:34 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> DESCRIPTION OF THE PROBLEM:
> There appears to be a bug in the isCookieValid method of HelloCookieManager that can lead to improper cookie validation results after a new cookieSecret is generated. The cookie version (cookieVersion) is initialized with a random number and increments with each cookie, regenerating the secret every 0xFFFFFF cookies.
> 
> When cookieVersion is negative, the expression ((cookieVersion >> 24) & 0xFF) results in an integer that does not match the signed byte value in cookie[0], causing the else clause to be executed incorrectly. This leads to the use of legacySecret even for valid cookies.

The change looks good.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26006#pullrequestreview-2963938328

From duke at openjdk.org  Fri Jun 27 01:51:46 2025
From: duke at openjdk.org (Lei Zhu)
Date: Fri, 27 Jun 2025 01:51:46 GMT
Subject: Withdrawn: 8360166: CodeSource.implies(): Wildcard host fails to imply
 specific host
In-Reply-To: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
References: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
Message-ID: <9p92Lkx7ZcKmG54yTC4izWDWqpA3F2vNRiy9fIS0PdY=.744b636a-8123-47bd-bb42-86a0a9f8f609@github.com>

On Thu, 26 Jun 2025 01:43:51 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Please review this PR which use hostname not cname to check imply. And alse add test case.
> 
> If there are any problems please let me know and I will correct them promptly.

This pull request has been closed without being integrated.

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

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

From hchao at openjdk.org  Fri Jun 27 05:38:38 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 27 Jun 2025 05:38:38 GMT
Subject: RFR: 8360539: DTLS handshakes fails due to improper cookie
 validation logic
In-Reply-To: <P3zzaM5pCrrIFBkJzbQJrrwVIsRHn-8xiXdz27eWx6A=.a58f780c-5b0b-47da-aa04-b2e6bf33f9d6@github.com>
References: <P3zzaM5pCrrIFBkJzbQJrrwVIsRHn-8xiXdz27eWx6A=.a58f780c-5b0b-47da-aa04-b2e6bf33f9d6@github.com>
Message-ID: <VDwKpo9Fgdgf5LsH9SB-nkJwzUJRN1Sr_hGVNw2NFRU=.3497e726-5e7a-4895-9278-cf0834125e8e@github.com>

On Thu, 26 Jun 2025 21:36:34 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> DESCRIPTION OF THE PROBLEM:
> There appears to be a bug in the isCookieValid method of HelloCookieManager that can lead to improper cookie validation results after a new cookieSecret is generated. The cookie version (cookieVersion) is initialized with a random number and increments with each cookie, regenerating the secret every 0xFFFFFF cookies.
> 
> When cookieVersion is negative, the expression ((cookieVersion >> 24) & 0xFF) results in an integer that does not match the signed byte value in cookie[0], causing the else clause to be executed incorrectly. This leads to the use of legacySecret even for valid cookies.

Marked as reviewed by hchao (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26006#pullrequestreview-2964816343

From sebastian.stenzel at gmail.com  Fri Jun 27 07:44:35 2025
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Fri, 27 Jun 2025 09:44:35 +0200
Subject: RFR: 8325448: Hybrid Public Key Encryption [v20]
In-Reply-To: <cP0ZZ_CZkAJ5TsH8KOo190O_jDiGLH4ljuF2nRg2r3g=.ba2415e8-7155-4199-beaf-1fedb912f598@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <cP0ZZ_CZkAJ5TsH8KOo190O_jDiGLH4ljuF2nRg2r3g=.ba2415e8-7155-4199-beaf-1fedb912f598@github.com>
Message-ID: <82D6BCA8-09AE-4C11-A5DB-962C328FEECA@gmail.com>

Hi Weijun,

I?m probably a bit late to the party but nevertheless I hope this finds attention:

To anyone in this mailing list unfamiliar with HPKE: The encapsulation process yields a tuple: A shared secret (the key agreement result, if you will) as well as an encapsulation of said key, that is being sent to the receiver.

Therefore, I don?t think `Cipher` is an appropriate public API for HPKE. The current attempt to make it fit the Cipher API (which can?t return tuples), the encapsulation is received via `cipher.getIV()`. Which is, in my opinion, a misusage and a very confusing one: First of all, `getIV()` returns the ciphertext, usually the result of `doFinal()`. And secondly, as the latter is already used for the shared secret, `getIV()`?s behaviour depends on the state of the Cipher.

Given that HPKE will probably rise in relevance quickly, I strongly advise giving it its own public API that aligns with the spec. Something like this:

```
record Encapsulated(SecretKey sharedSecret, byte[] enc) {}

Encapsulated encap(PublicKey recipientKey);

SecretKey decap(byte[] enc, PrivateKey recipientKey);
```

Best regards,
Sebastian

> On 27. Jun 2025, at 00:40, Weijun Wang <weijun at openjdk.org> wrote:
> 
>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> ![HPKEParameterSpec ? 11 54 ? 04-21](https://github.com/user-attachments/assets/da309585-db51-40d6-b291-3d38040d6292)
> 
> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
> - no more of()
> - extract and expand
> 
> -------------
> 
> Changes:
>  - all: https://git.openjdk.org/jdk/pull/18411/files
>  - new: https://git.openjdk.org/jdk/pull/18411/files/f819de2e..30c79948
> 
> Webrevs:
> - full: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=19
> - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18411&range=18-19
> 
>  Stats: 246 lines in 5 files changed: 23 ins; 178 del; 45 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4407 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250627/003299ed/smime-0001.p7s>

From dfuchs at openjdk.org  Fri Jun 27 08:19:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 08:19:06 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <qqRnOdt43mTxoxspZcXBrov-Ic0EQfzxxVIrLM_z7Ro=.9ae22464-e982-481b-9482-7bd2db47f7c7@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/QuicCipher.java line 375:

> 373:             super(cipherSuite, secret, new T13AESHPCipher(hp), keyPhase);
> 374:             this.key = key;
> 375:             this.iv = iv;

Suggestion:

            this.iv = iv.clone();

src/java.base/share/classes/sun/security/ssl/QuicCipher.java line 451:

> 449:             super(cipherSuite, secret, new T13AESHPCipher(hp), keyPhase);
> 450:             this.key = key;
> 451:             this.iv = iv;

Suggestion:

            this.iv = iv.clone();

src/java.base/share/classes/sun/security/ssl/QuicCipher.java line 619:

> 617:             super(cipherSuite, secret, new T13CC20HPCipher(hp), keyPhase);
> 618:             this.key = key;
> 619:             this.iv = iv;

Suggestion:

            this.iv = iv.clone();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171138262
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171167148
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171168244

From dfuchs at openjdk.org  Fri Jun 27 09:54:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 09:54:53 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <sRrFfMwi7-AB95otK9r0yVDjwkkAOzol6qh0J_00r6M=.6068f49c-0d79-4030-952b-6b4924e87d41@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/QuicTransportParametersExtension.java line 37:

> 35: /**
> 36:  * QuicTransportParametersExtension is an implementation of RFC 9000.
> 37:  * It is only used by QUIC connections.

I believe referencing RFC 9001 Section 8.2 would be more appropriate here. 
The QUIC transport parameters themselves are defined in RFC 9000, but the use of the quic_transport_parameters extension in the ClientHello and the EncryptedExtensions messages is described in RFC 9001.
Or else the purpose and description of this class could be clarified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171444954

From dfuchs at openjdk.org  Fri Jun 27 10:00:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 10:00:57 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <sfwzdQ0sp1xjfYi6rP-PX9FDUyrSIRH96W4tU1ilvxo=.56a5f3b2-661f-486f-8c8a-82f00c03ab15@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/SSLExtension.java line 461:

> 459:                                 KeyShareExtension.hrrStringizer),
> 460: 
> 461:     // Extension defined in RFC 9000

Shouldn't this be RFC 9001 here too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171464016

From djelinski at openjdk.org  Fri Jun 27 10:27:53 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Jun 2025 10:27:53 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>
Message-ID: <Sio-byu14_9C3KXO2V6faMHvvKR9eVzdgl4Uc5ruMlQ=.8ef12c8f-af20-4858-9bf2-ebee075f0202@github.com>

On Thu, 26 Jun 2025 17:43:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/OutputRecord.java line 168:
> 
>> 166:         throw new UnsupportedOperationException();
>> 167:     }
>> 168: 
> 
> Do we need those two methods here? Or could we just have them on `QuicEngineOutputRecord` and do the appropriate cast at the point they are called?
> Or do we have that at this level for performance reasons?

This was done to match the surrounding code. There's a bunch of methods in OutputRecord that throw UOE and are overridden by one class only. I suppose it would be cleaner to just do the cast, but "when in Rome, do as the Romans do"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171543796

From djelinski at openjdk.org  Fri Jun 27 11:25:54 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Jun 2025 11:25:54 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <wg6q7AM-mNmEpoWP-0eNamXxRfCOc_eNwYJoLXWHGPI=.e203a18c-4ad0-4305-a09e-ce129f47e024@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 216:

> 214: 
> 215:     // true if previous attempt resulted in streamLimitReached
> 216:     public boolean hasReachedStreamLimit(Version version) { return streamLimitReached == version; }

it seems that `streamLimitReached` will either be equal to `version` or `null`. If that's the case, let's use a boolean instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171687180

From djelinski at openjdk.org  Fri Jun 27 11:39:55 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Jun 2025 11:39:55 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <sZqtNoTLqHcpgpaIQ3htp1aSzrAgGkUyLx7mxR9P8jg=.5bf2e89f-2776-4a82-8eff-83ac07995836@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 121:

> 119:     }
> 120: 
> 121:     // Keeps track of the underlying connection when establishing an HTTP/2

since this is now used with HTTP/3, should we update this comment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171720043

From dfuchs at openjdk.org  Fri Jun 27 11:39:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 11:39:55 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <wg6q7AM-mNmEpoWP-0eNamXxRfCOc_eNwYJoLXWHGPI=.e203a18c-4ad0-4305-a09e-ce129f47e024@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <wg6q7AM-mNmEpoWP-0eNamXxRfCOc_eNwYJoLXWHGPI=.e203a18c-4ad0-4305-a09e-ce129f47e024@github.com>
Message-ID: <WtVK68Cxlrn-AGssHcRhjZzKNG5CHGzfxZph2sG_T04=.3da5dfaf-f470-40dd-839d-32234ce5c2a3@github.com>

On Fri, 27 Jun 2025 11:22:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 216:
> 
>> 214: 
>> 215:     // true if previous attempt resulted in streamLimitReached
>> 216:     public boolean hasReachedStreamLimit(Version version) { return streamLimitReached == version; }
> 
> it seems that `streamLimitReached` will either be equal to `version` or `null`. If that's the case, let's use a boolean instead.

That's a good point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171718034

From aivanov at openjdk.org  Fri Jun 27 11:57:44 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Jun 2025 11:57:44 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v8]
In-Reply-To: <wde0M3LUuqMdILh7rklStZmGCU3jZKf0ruVujEePt0c=.3601d7c3-7e4c-494c-9599-be3adb908f4e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <wde0M3LUuqMdILh7rklStZmGCU3jZKf0ruVujEePt0c=.3601d7c3-7e4c-494c-9599-be3adb908f4e@github.com>
Message-ID: <vWI5H8ceYQIjIidhY4mIYGYza-hAcdeWODbUDEsvWCM=.281ca419-7152-43a9-b2be-8fd5f2e163c8@github.com>

On Thu, 26 Jun 2025 20:56:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2966237280

From dfuchs at openjdk.org  Fri Jun 27 12:49:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 12:49:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <sZqtNoTLqHcpgpaIQ3htp1aSzrAgGkUyLx7mxR9P8jg=.5bf2e89f-2776-4a82-8eff-83ac07995836@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <sZqtNoTLqHcpgpaIQ3htp1aSzrAgGkUyLx7mxR9P8jg=.5bf2e89f-2776-4a82-8eff-83ac07995836@github.com>
Message-ID: <0uFs6gr4vZ3wgNvAsWhQfjl1_Wq9njUMcHHO-atXhJ0=.60d8e149-5ca9-4b8f-8268-76ca4b03e31a@github.com>

On Fri, 27 Jun 2025 11:37:00 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 121:
> 
>> 119:     }
>> 120: 
>> 121:     // Keeps track of the underlying connection when establishing an HTTP/2
> 
> since this is now used with HTTP/3, should we update this comment?

I have verified the other comments in this class and updated to mention or HTTP/3 in a few places in this class, in my local repo. Will appear the next time I sync this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171978343

From dfuchs at openjdk.org  Fri Jun 27 13:21:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 13:21:57 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <ZUOzzdiol4GwFgYqiR8l23DWvdHvBXfdVn4DUmDIa14=.b0fbc9df-0013-4c23-8d17-58d82f556420@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java line 50:

> 48:     static final ExtensionConsumer chOnLoadConsumer =
> 49:             new CHSupportedGroupsConsumer();
> 50:     static final HandshakeAbsence chOnTradeAbsence =

Another one that could disappear if we fixed that typo in mainline first.
@djelinski would you be willing to do that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172033315

From dfuchs at openjdk.org  Fri Jun 27 13:24:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 13:24:57 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <FmP9p94joz0UZx-X4ijp-ssEuOP5866kdRKiu1scKH8=.994d9c2d-781f-481f-930b-18c4a5cc1621@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 224:

> 222:             // TODO in future, when QuicTLSEngine might become a public exported interface
> 223:             // we should have a method on javax.net.ssl.X509ExtendedKeyManager that
> 224:             // takes QuicTLSEngine.

Suggestion:

            // TODO in future, if QuicTLSEngine ever becomes a public exported interface
            // we might have a method on javax.net.ssl.X509ExtendedKeyManager that
            // takes QuicTLSEngine.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 318:

> 316:                 // TODO in future, when QuicTLSEngine might become a public exported interface
> 317:                 // we should have a method on javax.net.ssl.X509ExtendedKeyManager that
> 318:                 // takes QuicTLSEngine.

Suggestion:

                // TODO in future, if QuicTLSEngine ever becomes a public exported interface
                // we might have a method on javax.net.ssl.X509ExtendedKeyManager that
                // takes QuicTLSEngine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172037488
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172039159

From dfuchs at openjdk.org  Fri Jun 27 14:04:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 14:04:54 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <Ti2XlE8-hiDRBn_bXh-fgFvE9jNNH68iIHF57tmBKP0=.b709481d-8405-4886-8465-808b14dd000d@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/java/net/http/package-info.java line 43:

> 41:  * Version 3 (HTTP/3)</a>, the <a href="https://tools.ietf.org/html/rfc7540">
> 42:  * Hypertext Transfer Protocol Version 2 (HTTP/2)</a>, the
> 43:  * <a href="https://tools.ietf.org/html/rfc2616">

It is strange to link to a different place here than in the `@spec` tags below. I will fix that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172115870

From abarashev at openjdk.org  Fri Jun 27 14:18:44 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 27 Jun 2025 14:18:44 GMT
Subject: Integrated: 8360539: DTLS handshakes fails due to improper cookie
 validation logic
In-Reply-To: <P3zzaM5pCrrIFBkJzbQJrrwVIsRHn-8xiXdz27eWx6A=.a58f780c-5b0b-47da-aa04-b2e6bf33f9d6@github.com>
References: <P3zzaM5pCrrIFBkJzbQJrrwVIsRHn-8xiXdz27eWx6A=.a58f780c-5b0b-47da-aa04-b2e6bf33f9d6@github.com>
Message-ID: <TwSkVBAzADWctX_ZRJjayq15Y3jaIahm9ado_wzswa8=.06904b58-4328-452a-a1be-6a40367ed53e@github.com>

On Thu, 26 Jun 2025 21:36:34 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> DESCRIPTION OF THE PROBLEM:
> There appears to be a bug in the isCookieValid method of HelloCookieManager that can lead to improper cookie validation results after a new cookieSecret is generated. The cookie version (cookieVersion) is initialized with a random number and increments with each cookie, regenerating the secret every 0xFFFFFF cookies.
> 
> When cookieVersion is negative, the expression ((cookieVersion >> 24) & 0xFF) results in an integer that does not match the signed byte value in cookie[0], causing the else clause to be executed incorrectly. This leads to the use of legacySecret even for valid cookies.

This pull request has now been integrated.

Changeset: a471fe99
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a471fe992fc0d71ba65b5fdbcc44b97a2783b90a
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8360539: DTLS handshakes fails due to improper cookie validation logic

Reviewed-by: ascarpino, hchao

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

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

From dfuchs at openjdk.org  Fri Jun 27 15:02:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 15:02:37 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <4t44zDtXWaOP26sXJUh2TDXhARbG57u_l2oU9CSZRdA=.0731d03f-b9ae-4160-9a23-7e809db2d28a@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/AltServicesRegistry.java line 186:

> 184:             return new Origin(scheme, originHost, addr.getPort());
> 185:         }
> 186:     }

I don't think it's a good idea to rely on `InetSocketAddress::getHostString()` as this can change depending on how the `InetSocketAddress` was constructed and whether `getHost()` has been called. 
I believe it would be more reliable to add a new `URI origin` parameter to the `HttpConnection` constructor. We could build that origin from the request URI for which the connection was created. Probably `origin` should be `null` for `PlainProxyConnection`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172224088

From achung at openjdk.org  Fri Jun 27 16:15:51 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jun 2025 16:15:51 GMT
Subject: Integrated: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <GF5IDxTAhXqzc73VVys13RSJKUc87JeYqSfSPXZjZWM=.997990aa-1178-4323-83b0-de46c0f2b455@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

This pull request has now been integrated.

Changeset: da7080ff
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da7080fffb2389465dc9afca6d02e9085fe15302
Stats:     1196 lines in 71 files changed: 814 ins; 93 del; 289 mod

8359761: JDK 25 RDP1 L10n resource files update

Reviewed-by: aivanov, almatvee, nbenalla, jlu, dnguyen, cstein, naoto

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

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

From weijun at openjdk.org  Fri Jun 27 16:55:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Jun 2025 16:55:59 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v21]
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: <-Kztx6glkbfjkQpQpGDVMPwtYMKNaUTHk8-XPtJ9P9Y=.2da1a916-0ca8-4633-855c-9392297e3521@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> 
> ![HPKEParameterSpec06-27](https://github.com/user-attachments/assets/d0425a10-a312-4a95-8cee-2fbec5d83ddd)

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

  some spec change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/30c79948..787702da

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

  Stats: 32 lines in 2 files changed: 13 ins; 10 del; 9 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  Fri Jun 27 16:56:00 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Jun 2025 16:56:00 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v20]
In-Reply-To: <cP0ZZ_CZkAJ5TsH8KOo190O_jDiGLH4ljuF2nRg2r3g=.ba2415e8-7155-4199-beaf-1fedb912f598@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <cP0ZZ_CZkAJ5TsH8KOo190O_jDiGLH4ljuF2nRg2r3g=.ba2415e8-7155-4199-beaf-1fedb912f598@github.com>
Message-ID: <0YXmJuauIob47mTQ_NEaWIIQq2geyvLw_AbvmP6rD6k=.1cb882e8-6105-4786-a3f1-3892d1b9bec5@github.com>

On Thu, 26 Jun 2025 22:40:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> 
>> ![HPKEParameterSpec06-27](https://github.com/user-attachments/assets/d0425a10-a312-4a95-8cee-2fbec5d83ddd)
>
> Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - no more of()
>  - extract and expand

Hi Sebastian, the API you suggested is only the KEM step, and it should be made internal inside HPKE.

At the end of the day, HPKE is still a cipher. I understand the key encapsulation message (aka, KEM ciphertext) is different from a traditional IV, but they share some key characteristics:  1) generated by the sender after initialization, 2) cryptographically random, 3) then made public, 4) has critical impact on encryption result.

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

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

From kdriver at openjdk.org  Fri Jun 27 17:56:43 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 27 Jun 2025 17:56:43 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called
In-Reply-To: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
Message-ID: <SAtTdgKuRZGsIFD0PiD-cOX-Hi6xdsFfmTCtA6DFIfE=.794a6e22-c650-4614-8d25-2b8e770df180@github.com>

On Wed, 4 Jun 2025 03:10:29 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 
> 
> 1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed
> 2. serialization of such destroyed `PBEKey` object will lead to exception. 
>  
> Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc.

src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 85:

> 83:         try {
> 84:             if (isDestroyed()) {
> 85:                 throw new IllegalStateException("key is destroyed");

nit: for uniformity, you may want to capitalize key since it is capitalized elsewhere

src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 209:

> 207:         try {
> 208:             if (isDestroyed()) {
> 209:                 throw new NotSerializableException("key is destroyed");

nit: for uniformity, you may want to capitalize `key` since it is capitalized elsewhere

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2172563144
PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2172562131

From achung at openjdk.org  Fri Jun 27 18:31:40 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jun 2025 18:31:40 GMT
Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update
Message-ID: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>

8359761: JDK 25 RDP1 L10n resource files update

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

Commit messages:
 - Backport da7080fffb2389465dc9afca6d02e9085fe15302

Changes: https://git.openjdk.org/jdk/pull/26026/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26026&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359761
  Stats: 1196 lines in 71 files changed: 814 ins; 93 del; 289 mod
  Patch: https://git.openjdk.org/jdk/pull/26026.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26026/head:pull/26026

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

From jlu at openjdk.org  Fri Jun 27 18:48:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Jun 2025 18:48:40 GMT
Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
References: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
Message-ID: <K1-1d3pNRFgWpkSWz0z37g8bv6FZDptY3FqWn6mA1YM=.b1642fa3-3131-475d-be48-e46ae826b1ca@github.com>

On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8359761: JDK 25 RDP1 L10n resource files update

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967612181

From aivanov at openjdk.org  Fri Jun 27 18:58:42 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Jun 2025 18:58:42 GMT
Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
References: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
Message-ID: <kg51-qmlCGiGQD2uT5jUV-tXzjg56nUx10DltgKO0xY=.eec85c62-ad07-4181-bfcb-37b946b625b3@github.com>

On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8359761: JDK 25 RDP1 L10n resource files update

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967634176

From achung at openjdk.org  Fri Jun 27 19:31:01 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jun 2025 19:31:01 GMT
Subject: [jdk25] Integrated: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
References: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
Message-ID: <Lvees89-ahp6rs1DC7OJnMRzhPaBlrM8HoOj1YDdGq4=.d69d8c1f-63dc-43e3-a8d4-bd98d3bb8670@github.com>

On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8359761: JDK 25 RDP1 L10n resource files update

This pull request has now been integrated.

Changeset: 12ffb0c1
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12ffb0c131c5100dc23549b9b7216625bc0dab9e
Stats:     1196 lines in 71 files changed: 814 ins; 93 del; 289 mod

8359761: JDK 25 RDP1 L10n resource files update

Reviewed-by: jlu, aivanov
Backport-of: da7080fffb2389465dc9afca6d02e9085fe15302

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

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

From duke at openjdk.org  Fri Jun 27 19:41:46 2025
From: duke at openjdk.org (Sebastian Stenzel)
Date: Fri, 27 Jun 2025 19:41:46 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v20]
In-Reply-To: <0YXmJuauIob47mTQ_NEaWIIQq2geyvLw_AbvmP6rD6k=.1cb882e8-6105-4786-a3f1-3892d1b9bec5@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <cP0ZZ_CZkAJ5TsH8KOo190O_jDiGLH4ljuF2nRg2r3g=.ba2415e8-7155-4199-beaf-1fedb912f598@github.com>
 <0YXmJuauIob47mTQ_NEaWIIQq2geyvLw_AbvmP6rD6k=.1cb882e8-6105-4786-a3f1-3892d1b9bec5@github.com>
Message-ID: <M5-dkFRrzua7JTHo3FkC4w-s4QZGqmYHNEeyxXOnPC8=.1e7e3cfd-c091-44a9-ae16-a1d9ea348860@github.com>

On Fri, 27 Jun 2025 15:46:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Hi Sebastian, the API you suggested is only the KEM step, and it should be made internal inside HPKE.
> 
> At the end of the day, HPKE is still a cipher. I understand the key encapsulation message (aka, KEM ciphertext) is different from a traditional IV, but they share some key characteristics: 1) generated by the sender after initialization, 2) cryptographically random, 3) then made public, 4) has critical impact on encryption result.

I am sorry, I got the names mixed up - too many different standards I was recently reviewing ?. Nevertheless, the final result of HPKE is still a tuple, with the encapsulation from the KEM step being required for the receiver to decrypt the message (or "decapsulate" and then "open?, to use the KEM and AEAD wording ?).

All your points make sense, though. The main difference is, that (so far) all IVs or nonces have to be generated beforehand in order to feed them into the cipher. As opposed to now being a byproduct of the cipher. Maybe I just have to get used to the fact that this doesn?t strictly need to be this way.

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

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

From sebastian.stenzel at gmail.com  Fri Jun 27 19:51:28 2025
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Fri, 27 Jun 2025 21:51:28 +0200
Subject: X-Wing KEM
In-Reply-To: <7047DE78-6DB2-4267-A783-C432F68F27DC@oracle.com>
References: <D4720121-83F6-483B-AD84-7A137AB65D46@gmail.com>
 <EBA594D5-865A-4348-A3C6-FD976DAF7787@oracle.com>
 <73235A95-D1EF-4BAA-8F1F-E90355DEFC37@gmail.com>
 <2B84AC72-3A5E-4E81-92DF-5BF19A1100DC@oracle.com>
 <13D07A70-0AEE-49EC-8809-EBCE08CCE339@gmail.com>
 <7047DE78-6DB2-4267-A783-C432F68F27DC@oracle.com>
Message-ID: <2CD1794D-4539-4DF4-B5BD-A6A182A20393@gmail.com>

Short update on the state of the X-Wing RFC:

Two weeks ago I contacted the authors, asking if they expect further changes. Which they don?t:

> "X-Wing is final and being shipped by Google and Apple presumably in hardware."
> - Bas Westerbaan

and

> "No significant changes, no changes planned or expected at all"
> - Deirdre Connolly


So while test vectors may still update (this is a TODO in the current draft), the risk of a last-minute change seems to be marginal.

That said, I would love to get a first review of the overall implementation. Would you mind if I draft a PR? Shall I also create a corresponding issue in the bug tracker?


> On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> Cool.
> 
> The current NamedPKCS8Key was designed based on an older approach where modern asymmetric keys store private key data in a nested OCTET STRING format. This pattern was introduced with EdDSA and XDH, and at the time of JDK 24, we anticipated it would become the norm.
> 
> However, things have changed significantly, as seen in the evolution of draft-ietf-lamps-dilithium-certificates and draft-ietf-lamps-kyber-certificates. The original design now needs to be revised. While we?re still waiting for the IETF drafts to be finalized, we?re already experimenting with changes in https://github.com/openjdk/jdk/pull/24969.
> 
> Hopefully, by the time X-Wing is finalized, we?ll already have a solution in place.
> 
> Thanks,
> Weijun
> 
>> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>> 
>> Hi Weijun,
>> 
>> I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:
>> 
>> The (current) X-Wing spec wants this PKCS#8 encoding: [1]
>> 
>> However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2]
>> 
>> Note the difference here:
>> * https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f
>> * https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo
>> 
>> I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this?
>> 
>> Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don?t seem to be complete yet.
>> 
>> Best regards,
>> Sebastian
>> 
>> [0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing
>> [1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D
>> [2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81
>> 
>>> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> 
>>> 
>>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>> 
>>>> Hi Weijun,
>>>> 
>>>> waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet?
>>> 
>>> Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK.
>>> 
>>>> 
>>>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
>>>> 
>>>> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.
>>> 
>>> I see.
>>> 
>>>> 
>>>> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]
>>> 
>>> Nice to know. Sorry I didn't noticed that earlier.
>>> 
>>> Thanks,
>>> Weijun
>>> 
>>>> 
>>>> Thank you,
>>>> Sebastian
>>>> 
>>>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
>>>> 
>>>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>> 
>>>>> Hi Sebastian.
>>>>> 
>>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>>>>> 
>>>>>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>>>>> 
>>>>> Thanks for your continued interest on enhancing OpenJDK.
>>>>> 
>>>>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first. 
>>>>> 
>>>>>> 
>>>>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>>>>> 
>>>>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>>>>> 
>>>>>> 
>>>>>> Alternatively, can we make the two mentioned APIs public?
>>>>> 
>>>>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>>>>> 
>>>>> [1] https://openjdk.org/guide/
>>>>> 
>>>>> Thanks,
>>>>> Weijun
>>>>> 
>>>>>> 
>>>>>> Cheers!
>>>>>> Sebastian
>>>>>> 
>>>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>>>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>>>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4407 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250627/1401f355/smime-0001.p7s>

From valeriep at openjdk.org  Fri Jun 27 20:51:56 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 27 Jun 2025 20:51:56 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called [v2]
In-Reply-To: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
Message-ID: <ZfPRWt98oVuVjYFHt7KzS5rUoBhqBk2xGwyeyjW6pz8=.ef2e9132-9c54-41d4-b54c-7f9a8f7b9d08@github.com>

> Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 
> 
> 1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed
> 2. serialization of such destroyed `PBEKey` object will lead to exception. 
>  
> Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc.

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

  Moved the Key.isDestroyed() check from individual provider SKF impl to
  JCA SecretKeyFactory class.
  Changed to throw ISE whenever destroyed key is encountered.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25632/files
  - new: https://git.openjdk.org/jdk/pull/25632/files/5d222430..beb840be

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

  Stats: 61 lines in 5 files changed: 18 ins; 33 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25632/head:pull/25632

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

From weijun at openjdk.org  Fri Jun 27 21:22:27 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Jun 2025 21:22:27 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v21]
In-Reply-To: <-Kztx6glkbfjkQpQpGDVMPwtYMKNaUTHk8-XPtJ9P9Y=.2da1a916-0ca8-4633-855c-9392297e3521@github.com>
References: <K_h8pp8FwV2vReRw_HuEDKUp3cLeK9vYQqItCHt_MuU=.2fdd39e8-a0fc-4dea-b93b-ded7156264da@github.com>
 <-Kztx6glkbfjkQpQpGDVMPwtYMKNaUTHk8-XPtJ9P9Y=.2da1a916-0ca8-4633-855c-9392297e3521@github.com>
Message-ID: <kbl8SnwMNO7-PDWtIqPy1yf3OLFRu770PzGGWyNOAkA=.5cd66882-538d-4ef7-9562-6e17b9da7384@github.com>

On Fri, 27 Jun 2025 16:55:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
>> 
>> ![HPKEParameterSpec06-27](https://github.com/user-attachments/assets/d0425a10-a312-4a95-8cee-2fbec5d83ddd)
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some spec change

It's only a tuple for a single-shot encryption. The general operation is still one encapsulation followed by multiple "seal" outputs. As for the IV, I think it's not uncommon that the cipher generates a random one.

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

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

From weijun at openjdk.org  Fri Jun 27 21:53:25 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Jun 2025 21:53:25 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v22]
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: <6lCHapypL5y2BYyGiO4Y5WQFFQ6JgFKe9m7zWid9HPU=.3599a2b3-0024-4563-b8ee-3437c89a3fd9@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> 
> ![HPKEParameterSpec06-27-2](https://github.com/user-attachments/assets/50667170-8adb-45b4-97bf-ecb92175716e)

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

  after initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/787702da..653b56c5

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

  Stats: 14 lines in 1 file changed: 14 ins; 0 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 weijun at openjdk.org  Fri Jun 27 22:04:25 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Jun 2025 22:04:25 GMT
Subject: RFR: 8325448: Hybrid Public Key Encryption [v23]
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: <TzSqeEAQrCcWmkSHYBbNdv_edaM3qdWfh1IAupLsqVg=.2ec3f7e2-46e1-42ee-b35c-ad35a9718522@github.com>

> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/.
> 
> ![HPKEParameterSpec06-27-3](https://github.com/user-attachments/assets/a17e7ea2-86dd-4e2d-9506-210e97ff8ae8)

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

  finetune the spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18411/files
  - new: https://git.openjdk.org/jdk/pull/18411/files/653b56c5..e83a4a1b

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

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 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.wang at oracle.com  Fri Jun 27 22:12:19 2025
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Fri, 27 Jun 2025 22:12:19 +0000
Subject: X-Wing KEM
In-Reply-To: <2CD1794D-4539-4DF4-B5BD-A6A182A20393@gmail.com>
References: <D4720121-83F6-483B-AD84-7A137AB65D46@gmail.com>
 <EBA594D5-865A-4348-A3C6-FD976DAF7787@oracle.com>
 <73235A95-D1EF-4BAA-8F1F-E90355DEFC37@gmail.com>
 <2B84AC72-3A5E-4E81-92DF-5BF19A1100DC@oracle.com>
 <13D07A70-0AEE-49EC-8809-EBCE08CCE339@gmail.com>
 <7047DE78-6DB2-4267-A783-C432F68F27DC@oracle.com>
 <2CD1794D-4539-4DF4-B5BD-A6A182A20393@gmail.com>
Message-ID: <CE4599C1-D058-4553-9475-04143C8E865C@oracle.com>



> On Jun 27, 2025, at 15:51, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
> 
> Short update on the state of the X-Wing RFC:
> 
> Two weeks ago I contacted the authors, asking if they expect further changes. Which they don?t:
> 
>> "X-Wing is final and being shipped by Google and Apple presumably in hardware."
>> - Bas Westerbaan
> 
> and
> 
>> "No significant changes, no changes planned or expected at all"
>> - Deirdre Connolly

Good to know.

> 
> 
> So while test vectors may still update (this is a TODO in the current draft), the risk of a last-minute change seems to be marginal.
> 
> That said, I would love to get a first review of the overall implementation. Would you mind if I draft a PR? Shall I also create a corresponding issue in the bug tracker?

No problem. Thanks for taking the initiative.

For the NamedPKCS8Key issue, you can either do some change on your side first, or simply skip it and directly inherit from PKCS8Key. After all, there is no parameter for X-Wing. Did you hear the authors they want to introduce other algorithms like ed448 and ML-KEM-1024 into it?

Best regards,
Weijun

> 
>> On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>> 
>> Cool.
>> 
>> The current NamedPKCS8Key was designed based on an older approach where modern asymmetric keys store private key data in a nested OCTET STRING format. This pattern was introduced with EdDSA and XDH, and at the time of JDK 24, we anticipated it would become the norm.
>> 
>> However, things have changed significantly, as seen in the evolution of draft-ietf-lamps-dilithium-certificates and draft-ietf-lamps-kyber-certificates. The original design now needs to be revised. While we?re still waiting for the IETF drafts to be finalized, we?re already experimenting with changes in https://github.com/openjdk/jdk/pull/24969.
>> 
>> Hopefully, by the time X-Wing is finalized, we?ll already have a solution in place.
>> 
>> Thanks,
>> Weijun
>> 
>>> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>> 
>>> Hi Weijun,
>>> 
>>> I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:
>>> 
>>> The (current) X-Wing spec wants this PKCS#8 encoding: [1]
>>> 
>>> However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2]
>>> 
>>> Note the difference here:
>>> * https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f
>>> * https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo
>>> 
>>> I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this?
>>> 
>>> Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don?t seem to be complete yet.
>>> 
>>> Best regards,
>>> Sebastian
>>> 
>>> [0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing
>>> [1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D
>>> [2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81
>>> 
>>>> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>> 
>>>>> Hi Weijun,
>>>>> 
>>>>> waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet?
>>>> 
>>>> Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK.
>>>> 
>>>>> 
>>>>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
>>>>> 
>>>>> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.
>>>> 
>>>> I see.
>>>> 
>>>>> 
>>>>> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]
>>>> 
>>>> Nice to know. Sorry I didn't noticed that earlier.
>>>> 
>>>> Thanks,
>>>> Weijun
>>>> 
>>>>> 
>>>>> Thank you,
>>>>> Sebastian
>>>>> 
>>>>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
>>>>> 
>>>>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>> 
>>>>>> Hi Sebastian.
>>>>>> 
>>>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>>>>>> 
>>>>>>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>>>>>> 
>>>>>> Thanks for your continued interest on enhancing OpenJDK.
>>>>>> 
>>>>>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first. 
>>>>>> 
>>>>>>> 
>>>>>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>>>>>> 
>>>>>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>>>>>> 
>>>>>>> 
>>>>>>> Alternatively, can we make the two mentioned APIs public?
>>>>>> 
>>>>>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>>>>>> 
>>>>>> [1] https://openjdk.org/guide/
>>>>>> 
>>>>>> Thanks,
>>>>>> Weijun
>>>>>> 
>>>>>>> 
>>>>>>> Cheers!
>>>>>>> Sebastian
>>>>>>> 
>>>>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>>>>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>>>>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From weijun.wang at oracle.com  Fri Jun 27 22:15:47 2025
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Fri, 27 Jun 2025 22:15:47 +0000
Subject: Subject class creation performance optimization oportunity
In-Reply-To: <1931152617.14103513.1750838395856.JavaMail.zimbra@desy.de>
References: <1931152617.14103513.1750838395856.JavaMail.zimbra@desy.de>
Message-ID: <32044951-3085-4868-A614-65A9A51A5C19@oracle.com>

Hi Tigran,

Thanks for your interest on OpenJDK.

I think the timing difference makes sense as the principals are stored in a special set inside the subject so subjectByPassingSet adds each twice and the subjectByAddingToSet only once. As for why we don't just use the pre-populated set as-is since it's already immutable, I think the major reason that we do the wrapping here is to make sure the read-only flag is correctly honored and the correct type of exception is thrown. I admit there is room for optimization when the input is already immutable and the read-only flag is also set, but it?s unclear whether the benefit is worth the complexity.

Best regards,
Weijun

> On Jun 25, 2025, at 03:59, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
> 
> 
> Dear security-devs,
> 
> While benchmarking various parts of our code, I noticed unexpected (but fully explainable) behavior of how an instance of the Subject class can be created.
> 
> The intuitive one is to create a set of Principals and then pass it to the constructor. However, it turned out that creating an empty subject and populating it with desire principles is much faster:
> 
> 
>    Benchmark                               Mode  Cnt        Score       Error  Units
>    SubjectBenchmark.subjectByAddingToSet  thrpt    9  2061025.436 ? 24807.881  ops/s
>    SubjectBenchmark.subjectByPassingSet   thrpt    9  1341492.178 ? 34701.882  ops/s
> 
> 
> The reason is that the Subject class performs extra checks on the provided set, which first creates a null-clean LinkedList copy of the collection. Makes sense.
> However, `Set#of` returns immutable, null clean sets, so there is no reason for an extra copy.
> 
> 
> Best regards,
>   Tigran.
> 
> 
> The benchmark code:
> 
> ```
> @BenchmarkMode(Mode.Throughput)
> @State(Scope.Benchmark)
> public class SubjectBenchmark {
> 
> 
>    @Benchmark
>    public Subject subjectByAddingToSet() {
>        Subject subject = new Subject();
>        subject.getPrincipals().add(new UnixNumericUserPrincipal(0));
>        subject.getPrincipals().add(new UnixNumericGroupPrincipal(0, true));
>        subject.getPrincipals().add(new UnixNumericGroupPrincipal(1, false));
>        subject.getPrincipals().add(new UnixNumericGroupPrincipal(2, false));
>        subject.getPrincipals().add(new UnixNumericGroupPrincipal(3, false));
>        subject.getPrincipals().add(new UnixNumericGroupPrincipal(4, false));
>        subject.getPrincipals().add(new UnixNumericGroupPrincipal(5, false));
>        subject.getPrincipals().add(new UnixNumericGroupPrincipal(6, false));
>        subject.setReadOnly();
>        return subject;
>    }
> 
> 
>    @Benchmark
>    public Subject subjectByPassingSet() {
> 
>        Principal[] principals = new Principal[]{
>              new UnixNumericUserPrincipal(0),
>              new UnixNumericGroupPrincipal(0, true),
>              new UnixNumericGroupPrincipal(1, false),
>              new UnixNumericGroupPrincipal(2, false),
>              new UnixNumericGroupPrincipal(3, false),
>              new UnixNumericGroupPrincipal(4, false),
>              new UnixNumericGroupPrincipal(5, false),
>              new UnixNumericGroupPrincipal(6, false)
>        };
> 
>        return new Subject(true, Set.of(principals), Set.of(), Set.of());
>    }
> }
> ```



From valeriep at openjdk.org  Fri Jun 27 23:04:40 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 27 Jun 2025 23:04:40 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called [v2]
In-Reply-To: <SAtTdgKuRZGsIFD0PiD-cOX-Hi6xdsFfmTCtA6DFIfE=.794a6e22-c650-4614-8d25-2b8e770df180@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
 <SAtTdgKuRZGsIFD0PiD-cOX-Hi6xdsFfmTCtA6DFIfE=.794a6e22-c650-4614-8d25-2b8e770df180@github.com>
Message-ID: <gZ95xeIORwi-vnkYQe93vxtsXQhh0FoD3PeSm8PDZVM=.c25b442e-9c57-4259-8006-bd49ec13015a@github.com>

On Fri, 27 Jun 2025 17:53:46 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Moved the Key.isDestroyed() check from individual provider SKF impl to
>>   JCA SecretKeyFactory class.
>>   Changed to throw ISE whenever destroyed key is encountered.
>
> src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 85:
> 
>> 83:         try {
>> 84:             if (isDestroyed()) {
>> 85:                 throw new IllegalStateException("key is destroyed");
> 
> nit: for uniformity, you may want to capitalize key since it is capitalized elsewhere

Yes, will fix.

> src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java line 209:
> 
>> 207:         try {
>> 208:             if (isDestroyed()) {
>> 209:                 throw new NotSerializableException("key is destroyed");
> 
> nit: for uniformity, you may want to capitalize `key` since it is capitalized elsewhere

Yes, will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2172962035
PR Review Comment: https://git.openjdk.org/jdk/pull/25632#discussion_r2172961977

From valeriep at openjdk.org  Fri Jun 27 23:11:53 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 27 Jun 2025 23:11:53 GMT
Subject: RFR: 8358451: SunJCE PBEKey impl should throw
 IllegalStateException when getEncoded() is called [v3]
In-Reply-To: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
References: <axP0eOut38UrB5G41Fdw9aOsiu_LcBBI5T93EBIM0ec=.3f353663-988d-432b-90da-030382cbd21a@github.com>
Message-ID: <T04UTKAFdqTYdlcfuZlFsBsOma4EATnPl7xTseW9aFk=.0f876a4c-d890-40a6-a564-263e1c966ed6@github.com>

> Update the `PBEKey` class of the SunJCE provider which override the `javax.security.auth.Destroyable` interface to 
> 
> 1. throw `IllegalStateException` if `getEncoded()` is called after key is destroyed
> 2. serialization of such destroyed `PBEKey` object will lead to exception. 
>  
> Also update the `PBEKeyFactory` class of the SunJCE provider to check for destroyed keys and throw exceptions per the method javadoc.

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

  Change "key" to "Key" in exception messages.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25632/files
  - new: https://git.openjdk.org/jdk/pull/25632/files/beb840be..d7335e3d

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

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

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

From sebastian.stenzel at gmail.com  Sun Jun 29 10:02:34 2025
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Sun, 29 Jun 2025 12:02:34 +0200
Subject: X-Wing KEM
In-Reply-To: <CE4599C1-D058-4553-9475-04143C8E865C@oracle.com>
References: <D4720121-83F6-483B-AD84-7A137AB65D46@gmail.com>
 <EBA594D5-865A-4348-A3C6-FD976DAF7787@oracle.com>
 <73235A95-D1EF-4BAA-8F1F-E90355DEFC37@gmail.com>
 <2B84AC72-3A5E-4E81-92DF-5BF19A1100DC@oracle.com>
 <13D07A70-0AEE-49EC-8809-EBCE08CCE339@gmail.com>
 <7047DE78-6DB2-4267-A783-C432F68F27DC@oracle.com>
 <2CD1794D-4539-4DF4-B5BD-A6A182A20393@gmail.com>
 <CE4599C1-D058-4553-9475-04143C8E865C@oracle.com>
Message-ID: <6AFA19E1-2CCC-41AA-8996-6844FFE28204@gmail.com>


> On 28. Jun 2025, at 00:12, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> [...] After all, there is no parameter for X-Wing. Did you hear the authors they want to introduce other algorithms like ed448 and ML-KEM-1024 into it?

I forwarded this question and let you know the answer!


>> 
>>> On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Cool.
>>> 
>>> The current NamedPKCS8Key was designed based on an older approach where modern asymmetric keys store private key data in a nested OCTET STRING format. This pattern was introduced with EdDSA and XDH, and at the time of JDK 24, we anticipated it would become the norm.
>>> 
>>> However, things have changed significantly, as seen in the evolution of draft-ietf-lamps-dilithium-certificates and draft-ietf-lamps-kyber-certificates. The original design now needs to be revised. While we?re still waiting for the IETF drafts to be finalized, we?re already experimenting with changes in https://github.com/openjdk/jdk/pull/24969.
>>> 
>>> Hopefully, by the time X-Wing is finalized, we?ll already have a solution in place.
>>> 
>>> Thanks,
>>> Weijun
>>> 
>>>> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>> 
>>>> Hi Weijun,
>>>> 
>>>> I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:
>>>> 
>>>> The (current) X-Wing spec wants this PKCS#8 encoding: [1]
>>>> 
>>>> However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2]
>>>> 
>>>> Note the difference here:
>>>> * https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f
>>>> * https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo
>>>> 
>>>> I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this?
>>>> 
>>>> Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don?t seem to be complete yet.
>>>> 
>>>> Best regards,
>>>> Sebastian
>>>> 
>>>> [0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing
>>>> [1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D
>>>> [2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81
>>>> 
>>>>> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>> 
>>>>>> Hi Weijun,
>>>>>> 
>>>>>> waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet?
>>>>> 
>>>>> Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK.
>>>>> 
>>>>>> 
>>>>>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
>>>>>> 
>>>>>> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.
>>>>> 
>>>>> I see.
>>>>> 
>>>>>> 
>>>>>> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]
>>>>> 
>>>>> Nice to know. Sorry I didn't noticed that earlier.
>>>>> 
>>>>> Thanks,
>>>>> Weijun
>>>>> 
>>>>>> 
>>>>>> Thank you,
>>>>>> Sebastian
>>>>>> 
>>>>>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
>>>>>> 
>>>>>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Sebastian.
>>>>>>> 
>>>>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>>>>>>> 
>>>>>>>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>>>>>>> 
>>>>>>> Thanks for your continued interest on enhancing OpenJDK.
>>>>>>> 
>>>>>>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first. 
>>>>>>> 
>>>>>>>> 
>>>>>>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>>>>>>> 
>>>>>>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Alternatively, can we make the two mentioned APIs public?
>>>>>>> 
>>>>>>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>>>>>>> 
>>>>>>> [1] https://openjdk.org/guide/
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Weijun
>>>>>>> 
>>>>>>>> 
>>>>>>>> Cheers!
>>>>>>>> Sebastian
>>>>>>>> 
>>>>>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>>>>>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>>>>>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4407 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250629/a6132afb/smime-0001.p7s>

From ecki at zusammenkunft.net  Sun Jun 29 13:27:05 2025
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sun, 29 Jun 2025 15:27:05 +0200 (CEST)
Subject: Discard or clamp ticket lifetime?
In-Reply-To: <20250629083148.1000F6610CA@dd33810.kasserver.com>
References: <20250629083148.1000F6610CA@dd33810.kasserver.com>
Message-ID: <20250629132705.9340D66142E@dd33810.kasserver.com>

Hello,

We deal with a regression in JSSE regarding resumption tickets with high lifetime.
In older versions with Java 11 the customer claimed a FTP Server was reachable, with Java 21 the connections are rejected.
Looking at the debug log of the new version, we can see a session resumption ticket was discarded, and in the followup the ftp#s data connection had a new belonged to a fresh session - and some FTP Servers dont like this.

So while looking into the source, I had a few questions:

a) why do we discard those tickets at all, instead of just clamping their age to the 7d. Max ticket lifetime.
According to the RFC the lifetime field is only a hint and both side are free to not use them after some time.
In fact the Field was even named a ?hint? (in TLS 1.2)

https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java#L654


b) I am not sure why there is a second Test for the lifetime of the Cache Ticket, I mean if it Never accepts those longlived Tickets, why does it need to remove them. Is that second Test maybe supposed to be an expire test, instead?

https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java#L666

https://www.rfc-editor.org/rfc/rfc5077#section-5.6


C) the traced ticket had a lifetime hint of MAX_INT:

NewSessionTicket": {
  "ticket_lifetime"      : "2,147,483,647",
? 

This sounds to me like a deliberate choice of the server implementation,  if it wants to signal ?lets see how Long I am valid, try it anyway?. 
Clamping only in this case would help Interop already (but I dont see a reason to limit it to this value.)

Since we could not yet get our hands on a working trace, we are not sure where the regression is (that MAX_TICKET_LIFETIME seems to be introduced before the 11 Version and therefore is not the direct reason), has someone  an idea, or observed this as well?

Gru?
Bernd
? 
https://bernd.eckenfels.net

From swen at openjdk.org  Mon Jun 30 04:54:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Jun 2025 04:54:50 GMT
Subject: RFR: 8361018: Eliminate unnecessary buffering and encoding conversion
 in BufferedWriter
Message-ID: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>

BufferedWriter -> OutputStreamWriter -> StreamEncoder

In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.

LATIN1 -> UTF16 -> UTF8

We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.

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

Commit messages:
 - @Override & non-public
 - Update src/java.base/share/classes/java/io/BufferedWriter.java
 - final & private inner class
 - benchmark parameter charset
 - inner class
 - only UTF8
 - revert PrintStream
 - inner class
 - inner class
 - add benchmark
 - ... and 4 more: https://git.openjdk.org/jdk/compare/da7080ff...d40e3d65

Changes: https://git.openjdk.org/jdk/pull/26022/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26022&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361018
  Stats: 598 lines in 7 files changed: 474 ins; 83 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/26022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26022/head:pull/26022

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

From swen at openjdk.org  Mon Jun 30 04:54:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 30 Jun 2025 04:54:50 GMT
Subject: RFR: 8361018: Eliminate unnecessary buffering and encoding
 conversion in BufferedWriter
In-Reply-To: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
Message-ID: <gKgQ5NeoEP0QxMUmkgQHEhQ3Ezlcr7MJ9A69TO2EF2E=.d315f2d7-39d7-4d49-9294-40b0bbe73c5a@github.com>

On Fri, 27 Jun 2025 16:48:40 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> BufferedWriter -> OutputStreamWriter -> StreamEncoder
> 
> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
> 
> LATIN1 -> UTF16 -> UTF8
> 
> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.

Performance test data shows that this PR can significantly improve the performance of BufferedWriter, and can improve the performance by 30%~50% in the write(String) scenario.

## Benchmark Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

#baseline
git checkout 2758d6ad7767832db004d28f10cc764f33fa438e
make make test TEST="micro:java.io.BufferedWriterBench"

# current
git checkout 13fd490e75ed3ec4be1957e183ab1631c2029c05
make make test TEST="micro:java.io.BufferedWriterBench"


## Benchmark Numbers on MacBook M1 Pro (aarch64)

# baseline
-Benchmark                             (charType)  (charset)  Mode  Cnt   Score   Error  Units
-BufferedWriterBench.writeCharArray         ascii       UTF8  avgt   12   2.672 ? 0.097  us/op
-BufferedWriterBench.writeCharArray  utf8_2_bytes       UTF8  avgt   12  22.310 ? 0.150  us/op
-BufferedWriterBench.writeCharArray  utf8_3_bytes       UTF8  avgt   12  21.442 ? 0.097  us/op
-BufferedWriterBench.writeCharArray         emoji       UTF8  avgt   12  34.750 ? 0.245  us/op
-BufferedWriterBench.writeString            ascii       UTF8  avgt   12   2.831 ? 0.078  us/op
-BufferedWriterBench.writeString     utf8_2_bytes       UTF8  avgt   12  22.200 ? 0.102  us/op
-BufferedWriterBench.writeString     utf8_3_bytes       UTF8  avgt   12  21.522 ? 0.132  us/op
-BufferedWriterBench.writeString            emoji       UTF8  avgt   12  34.973 ? 0.331  us/op

# current
+Benchmark                             (charType)  (charset)  Mode  Cnt   Score   Error  Units
+BufferedWriterBench.writeCharArray         ascii       UTF8  avgt   12   2.663 ? 0.077  us/op +0.33%
+BufferedWriterBench.writeCharArray  utf8_2_bytes       UTF8  avgt   12  13.807 ? 0.080  us/op +61.58%
+BufferedWriterBench.writeCharArray  utf8_3_bytes       UTF8  avgt   12  16.157 ? 0.230  us/op +32.71%
+BufferedWriterBench.writeCharArray         emoji       UTF8  avgt   12  21.891 ? 0.158  us/op +58.74%
+BufferedWriterBench.writeString            ascii       UTF8  avgt   12   2.125 ? 0.190  us/op +33.22%
+BufferedWriterBench.writeString     utf8_2_bytes       UTF8  avgt   12  14.260 ? 0.716  us/op +55.68%
+BufferedWriterBench.writeString     utf8_3_bytes       UTF8  avgt   12  12.587 ? 0.099  us/op +70.98%
+BufferedWriterBench.writeString            emoji       UTF8  avgt   12  22.810 ? 0.168  us/op +53.32%

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3015795787

From duke at openjdk.org  Mon Jun 30 04:54:50 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 30 Jun 2025 04:54:50 GMT
Subject: RFR: 8361018: Eliminate unnecessary buffering and encoding
 conversion in BufferedWriter
In-Reply-To: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
Message-ID: <MBkoAq9OLfLWpifozU5f-aYFVS9m-rw6Aq2LKgcqz-0=.e879ccc6-6643-43c7-aeb1-a20a7ab2540e@github.com>

On Fri, 27 Jun 2025 16:48:40 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> BufferedWriter -> OutputStreamWriter -> StreamEncoder
> 
> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
> 
> LATIN1 -> UTF16 -> UTF8
> 
> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.

src/java.base/share/classes/java/io/BufferedWriter.java line 244:

> 242:     }
> 243: 
> 244:     private static abstract sealed class BufferedImpl permits WriterImpl, OutputStreamWriterImpl {

No?need to?explicitly list the?permitted subclasses when?in?the?same compilation?unit:
Suggestion:

    private static abstract sealed class BufferedImpl {

src/java.base/share/classes/java/io/BufferedWriter.java line 468:

> 466:         }
> 467: 
> 468:         public void close() throws IOException {

These?implement the?package?private methods from?`BufferedImpl`, so?they probably?should have?`@Override` and?don?t?need to?be?`public`:
Suggestion:

        @Override
        void flushBuffer() throws IOException {
            os.flushBuffer();
        }

        @Override
        void write(int c) throws IOException {
            os.write(new char[] {(char) c});
        }

        @Override
        void write(char[] cbuf, int off, int len) throws IOException {
            os.write(cbuf, off, len);
        }

        @Override
        void write(String s, int off, int len) throws IOException {
            os.write(s, off, len);
        }

        @Override
        void flush() throws IOException {
            os.flush();
        }

        @Override
        void close() throws IOException {


Same?applies to?the?regular `WriterImpl`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26022#discussion_r2173989119
PR Review Comment: https://git.openjdk.org/jdk/pull/26022#discussion_r2173990102

From duke at openjdk.org  Mon Jun 30 05:32:26 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Mon, 30 Jun 2025 05:32:26 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage
Message-ID: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>

SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.

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

Commit messages:
 - 8357915: SecureRandom nextLong memory usage
 - Merge branch 'master' into 8357915
 - 8357915: SecureRandom nextLong memory usage
 - 8357915: SecureRandom nextLong memory usage

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

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

From duke at openjdk.org  Mon Jun 30 05:32:26 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 30 Jun 2025 05:32:26 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage
In-Reply-To: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
Message-ID: <It84I_vN_ObevOLAxF6s4G5YyjV-NW3ho2sMKGiZEGs=.69e56c8d-5232-4a99-88ac-7ff266f8d1d9@github.com>

On Thu, 26 Jun 2025 18:00:21 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.

src/java.base/share/classes/java/security/SecureRandom.java line 842:

> 840: 
> 841:     @Override
> 842:     public synchronized long nextLong() {

Does?not?need to?be?`synchronized`, as?that?s?handled by?the?`synchronized`?block in?`nextBytes(?)`:
Suggestion:

    public long nextLong() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26005#discussion_r2173519227

From liach at openjdk.org  Mon Jun 30 05:32:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 30 Jun 2025 05:32:27 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage
In-Reply-To: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
Message-ID: <_qlNCuZgyYBwASaidkcdeI2Ok1MJRwToqU_-DrfJc5Q=.68076690-e8d0-47dc-8ebd-eb41846cdf2e@github.com>

On Thu, 26 Jun 2025 18:00:21 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.

src/java.base/share/classes/java/security/SecureRandom.java line 859:

> 857:         byte[] b = new byte[8];
> 858:         nextBytes(b); // Calls engineNextBytes internally
> 859:         return ((long)(b[0] & 0xff) << 56) |

You can use `ByteArray.getLong(b, 0)` instead. And I don't think we need to rewrite the API specification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26005#discussion_r2169666613

From duke at openjdk.org  Mon Jun 30 05:32:27 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Mon, 30 Jun 2025 05:32:27 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage
In-Reply-To: <_qlNCuZgyYBwASaidkcdeI2Ok1MJRwToqU_-DrfJc5Q=.68076690-e8d0-47dc-8ebd-eb41846cdf2e@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <_qlNCuZgyYBwASaidkcdeI2Ok1MJRwToqU_-DrfJc5Q=.68076690-e8d0-47dc-8ebd-eb41846cdf2e@github.com>
Message-ID: <w-jQoNisvQOLk8uOjXoD5MEnDVG5A8MnlcspABy2OE4=.d33d8cdd-f712-4c24-9ee6-d732badfaed5@github.com>

On Thu, 26 Jun 2025 18:16:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
>> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
>> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.
>
> src/java.base/share/classes/java/security/SecureRandom.java line 859:
> 
>> 857:         byte[] b = new byte[8];
>> 858:         nextBytes(b); // Calls engineNextBytes internally
>> 859:         return ((long)(b[0] & 0xff) << 56) |
> 
> You can use `ByteArray.getLong(b, 0)` instead. And I don't think we need to rewrite the API specification.

As per our discussion, I have made the changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26005#discussion_r2170263918

From djelinski at openjdk.org  Mon Jun 30 08:10:57 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 30 Jun 2025 08:10:57 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <sRrFfMwi7-AB95otK9r0yVDjwkkAOzol6qh0J_00r6M=.6068f49c-0d79-4030-952b-6b4924e87d41@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <sRrFfMwi7-AB95otK9r0yVDjwkkAOzol6qh0J_00r6M=.6068f49c-0d79-4030-952b-6b4924e87d41@github.com>
Message-ID: <YDH5OpjsRwpC3fX3dNWSxsAGtCcUMa1eIe3d_danADw=.4abfcee6-7fdc-4e3c-9736-44be7f686b86@github.com>

On Fri, 27 Jun 2025 09:49:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/QuicTransportParametersExtension.java line 37:
> 
>> 35: /**
>> 36:  * QuicTransportParametersExtension is an implementation of RFC 9000.
>> 37:  * It is only used by QUIC connections.
> 
> I believe referencing RFC 9001 Section 8.2 would be more appropriate here. 
> The QUIC transport parameters themselves are defined in RFC 9000, but the use of the quic_transport_parameters extension in the ClientHello and the EncryptedExtensions messages is described in RFC 9001.
> Or else the purpose and description of this class could be clarified.

Most of the extensions have a generic JavaDoc, I will update this one to match the others.

> src/java.base/share/classes/sun/security/ssl/SSLExtension.java line 461:
> 
>> 459:                                 KeyShareExtension.hrrStringizer),
>> 460: 
>> 461:     // Extension defined in RFC 9000
> 
> Shouldn't this be RFC 9001 here too?

Will be updated in the next refresh.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174477328
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174479150

From jpai at openjdk.org  Mon Jun 30 09:14:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jun 2025 09:14:56 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <4t44zDtXWaOP26sXJUh2TDXhARbG57u_l2oU9CSZRdA=.0731d03f-b9ae-4160-9a23-7e809db2d28a@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <4t44zDtXWaOP26sXJUh2TDXhARbG57u_l2oU9CSZRdA=.0731d03f-b9ae-4160-9a23-7e809db2d28a@github.com>
Message-ID: <iIzts4EuH4WNoOfQ9tYHbfqM4GWYCp9CdY95up8L32k=.907c963d-d92b-4aad-8a05-c78e9574659e@github.com>

On Fri, 27 Jun 2025 14:55:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/AltServicesRegistry.java line 186:
> 
>> 184:             return new Origin(scheme, originHost, addr.getPort());
>> 185:         }
>> 186:     }
> 
> I don't think it's a good idea to rely on `InetSocketAddress::getHostString()` as this can change depending on how the `InetSocketAddress` was constructed and whether `getHost()` has been called. 
> I believe it would be more reliable to add a new `URI origin` parameter to the `HttpConnection` constructor. We could build that origin from the request URI for which the connection was created. Probably `origin` should be `null` for `PlainProxyConnection`.

I've created https://bugs.openjdk.org/browse/JDK-8361060 to track this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174603879

From djelinski at openjdk.org  Mon Jun 30 09:37:58 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 30 Jun 2025 09:37:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <gJjX2SWnVaY5_Iu8xzVmwlIdgYS8PgPYVHEvOaz00KY=.53ed95dc-6560-48da-8db2-49823788a63c@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 124:

> 122:     // exchange so that it can be aborted/timed out mid setup.
> 123:     final class ConnectionAborter {
> 124:         // In case of HTTP/3 direct connection we may have

"direct" is usually used to refer to connections that don't use a proxy; since H3 connections never use a proxy, can we drop the "direct" here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174648431

From dfuchs at openjdk.org  Mon Jun 30 09:48:59 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Jun 2025 09:48:59 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <gJjX2SWnVaY5_Iu8xzVmwlIdgYS8PgPYVHEvOaz00KY=.53ed95dc-6560-48da-8db2-49823788a63c@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <gJjX2SWnVaY5_Iu8xzVmwlIdgYS8PgPYVHEvOaz00KY=.53ed95dc-6560-48da-8db2-49823788a63c@github.com>
Message-ID: <_KViTKZGBXQP1jf-JCdme4Wwzhc1VxUbIgeIaqCuA3E=.b36c2681-216d-4377-9492-9164eef40b51@github.com>

On Mon, 30 Jun 2025 09:34:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 124:
> 
>> 122:     // exchange so that it can be aborted/timed out mid setup.
>> 123:     final class ConnectionAborter {
>> 124:         // In case of HTTP/3 direct connection we may have
> 
> "direct" is usually used to refer to connections that don't use a proxy; since H3 connections never use a proxy, can we drop the "direct" here?

Good point. I will rephrase. We should be speaking of HTTP/3 requests (and not connection) here anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174668926

From dfuchs at openjdk.org  Mon Jun 30 09:48:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Jun 2025 09:48:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <kTIIcfqilyJuMUP65znNS6M7QoUQGpws8bXRmcbC0hQ=.a7fa725f-be22-41c1-b2b3-378ad0695ea9@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/AltSvcProcessor.java line 360:

> 358:             return new ParsedHeaderValue(altValue, alpnName, hostPort.host(), hostPort.port(), Map.of());
> 359:         }
> 360:         // parse the semi-colon delimited parameters out of the rest of the remaining string

Suggestion:

        // parse the semicolon delimited parameters out of the rest of the remaining string

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 85:

> 83: 
> 84:     // This will be set to true only when it is guaranteed that the server hasn't processed
> 85:     // the request. Typically this happens when the server explicitly states (through a GOAWAY frame

Suggestion:

    // the request. Typically, this happens when the server explicitly states (through a GOAWAY frame

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172279904
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172285806

From sebastian.stenzel at gmail.com  Mon Jun 30 10:06:40 2025
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Mon, 30 Jun 2025 12:06:40 +0200
Subject: X-Wing KEM
In-Reply-To: <6AFA19E1-2CCC-41AA-8996-6844FFE28204@gmail.com>
References: <D4720121-83F6-483B-AD84-7A137AB65D46@gmail.com>
 <EBA594D5-865A-4348-A3C6-FD976DAF7787@oracle.com>
 <73235A95-D1EF-4BAA-8F1F-E90355DEFC37@gmail.com>
 <2B84AC72-3A5E-4E81-92DF-5BF19A1100DC@oracle.com>
 <13D07A70-0AEE-49EC-8809-EBCE08CCE339@gmail.com>
 <7047DE78-6DB2-4267-A783-C432F68F27DC@oracle.com>
 <2CD1794D-4539-4DF4-B5BD-A6A182A20393@gmail.com>
 <CE4599C1-D058-4553-9475-04143C8E865C@oracle.com>
 <6AFA19E1-2CCC-41AA-8996-6844FFE28204@gmail.com>
Message-ID: <99A6CAB5-DD35-41A2-AD4F-A30F7B3EA74E@gmail.com>

Quoting Bas Westerbaan (in CC) again, we will most likely see further PQ/T hybrids from the IETF crypto forum research group (CFRG for short):

> It seems likely that the CFRG will at some point produce a P-384+ML-KEM-1024 hybrid. See https://mailarchive.ietf.org/arch/msg/cfrg/CwrVvm-J7o85TEWkG9RJxZwfXDY/ . That might take some time.
> 
> Very few (but notably Ericsson) have asked for X448 hybrids, so I don't expect them soon.

That said, the construction does not necessarily be compatible to X-Wing. Just to be sure, I asked whether they see any value in parameterizing X-Wing to swap out algorithms. This is what Bas replied:

> Even if the other hybrids will also use an X-Wing style combiner, it doesn't hurt not to parametrize initially. :)

So I would suggest to follow this advice for now and only refactor the implementation eventually, when further pairs of algorithms are combined in the same way.

Best,
Sebastian


> On 29. Jun 2025, at 12:02, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
> 
> 
>> On 28. Jun 2025, at 00:12, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>> 
>> [...] After all, there is no parameter for X-Wing. Did you hear the authors they want to introduce other algorithms like ed448 and ML-KEM-1024 into it?
> 
> I forwarded this question and let you know the answer!
> 
> 
>>> 
>>>> On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>> 
>>>> Cool.
>>>> 
>>>> The current NamedPKCS8Key was designed based on an older approach where modern asymmetric keys store private key data in a nested OCTET STRING format. This pattern was introduced with EdDSA and XDH, and at the time of JDK 24, we anticipated it would become the norm.
>>>> 
>>>> However, things have changed significantly, as seen in the evolution of draft-ietf-lamps-dilithium-certificates and draft-ietf-lamps-kyber-certificates. The original design now needs to be revised. While we?re still waiting for the IETF drafts to be finalized, we?re already experimenting with changes in https://github.com/openjdk/jdk/pull/24969.
>>>> 
>>>> Hopefully, by the time X-Wing is finalized, we?ll already have a solution in place.
>>>> 
>>>> Thanks,
>>>> Weijun
>>>> 
>>>>> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>> 
>>>>> Hi Weijun,
>>>>> 
>>>>> I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:
>>>>> 
>>>>> The (current) X-Wing spec wants this PKCS#8 encoding: [1]
>>>>> 
>>>>> However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2]
>>>>> 
>>>>> Note the difference here:
>>>>> * https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f
>>>>> * https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo
>>>>> 
>>>>> I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this?
>>>>> 
>>>>> Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don?t seem to be complete yet.
>>>>> 
>>>>> Best regards,
>>>>> Sebastian
>>>>> 
>>>>> [0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing
>>>>> [1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D
>>>>> [2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81
>>>>> 
>>>>>> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>> 
>>>>>>> Hi Weijun,
>>>>>>> 
>>>>>>> waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet?
>>>>>> 
>>>>>> Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK.
>>>>>> 
>>>>>>> 
>>>>>>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
>>>>>>> 
>>>>>>> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.
>>>>>> 
>>>>>> I see.
>>>>>> 
>>>>>>> 
>>>>>>> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]
>>>>>> 
>>>>>> Nice to know. Sorry I didn't noticed that earlier.
>>>>>> 
>>>>>> Thanks,
>>>>>> Weijun
>>>>>> 
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> Sebastian
>>>>>>> 
>>>>>>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
>>>>>>> 
>>>>>>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> Hi Sebastian.
>>>>>>>> 
>>>>>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> Hi all,
>>>>>>>>> 
>>>>>>>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>>>>>>>> 
>>>>>>>>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>>>>>>>> 
>>>>>>>> Thanks for your continued interest on enhancing OpenJDK.
>>>>>>>> 
>>>>>>>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first. 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>>>>>>>> 
>>>>>>>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Alternatively, can we make the two mentioned APIs public?
>>>>>>>> 
>>>>>>>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>>>>>>>> 
>>>>>>>> [1] https://openjdk.org/guide/
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Weijun
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Cheers!
>>>>>>>>> Sebastian
>>>>>>>>> 
>>>>>>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>>>>>>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>>>>>>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4407 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250630/3f347367/smime-0001.p7s>

From mullan at openjdk.org  Mon Jun 30 12:57:39 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 30 Jun 2025 12:57:39 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage
In-Reply-To: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
Message-ID: <6hmP23ebk4T-lXhmU0sRGf0CSxHGRi3L5zO7K5Jv0o4=.50743810-cc87-470a-8675-c5c6d093c226@github.com>

On Thu, 26 Jun 2025 18:00:21 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.

A CSR should be filed, since you are overriding a public method.

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

PR Comment: https://git.openjdk.org/jdk/pull/26005#issuecomment-3019048117

From mullan at openjdk.org  Mon Jun 30 13:21:44 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 30 Jun 2025 13:21:44 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage
In-Reply-To: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
Message-ID: <kpTRhT_FL1iU7hyev_smBN_LOhFt6SbaWEjCg9D2PvU=.a1987172-af6b-4a62-900a-f5233ae73477@github.com>

On Thu, 26 Jun 2025 18:00:21 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.

src/java.base/share/classes/java/security/SecureRandom.java line 841:

> 839:     }
> 840: 
> 841:     @Override

This method will appear in the javadoc for `SecureRandom` now, so I think you need to add the `inheritDoc` tag to incorporate the superclass` javadoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26005#discussion_r2175058965

From ecki at zusammenkunft.net  Mon Jun 30 14:45:39 2025
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 30 Jun 2025 16:45:39 +0200 (CEST)
Subject: Discard or clamp ticket lifetime?
In-Reply-To: <20250629152705.9340D66142E@dd33810.kasserver.com>
References: <20250629083148.1000F6610CA@dd33810.kasserver.com>
 <20250629152705.9340D66142E@dd33810.kasserver.com>
Message-ID: <20250630144539.5502766361A@dd33810.kasserver.com>

This OpenSSL Ticket describes the same MAX_INT liferime problem, and they Seen to use clamping as well.
I think the change and the exakt condition is different (since it is a TLS1.3 issue for them), but the Observation that vsftpd is causing this, will allow us to reproduce it. (I may report it to vsftpd as well).

https://github.com/openssl/openssl/issues/17948

Gru?
Bernd

Bernd Eckenfels wrote on 29. June 2025 15:27 (GMT +02:00):
> We deal with a regression in JSSE regarding resumption tickets with high
> lifetime.
> In older versions with Java 11 the customer claimed a FTP Server was
> reachable, with Java 21 the connections are rejected.
?

From liach at openjdk.org  Mon Jun 30 15:14:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 30 Jun 2025 15:14:39 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage
In-Reply-To: <kpTRhT_FL1iU7hyev_smBN_LOhFt6SbaWEjCg9D2PvU=.a1987172-af6b-4a62-900a-f5233ae73477@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <kpTRhT_FL1iU7hyev_smBN_LOhFt6SbaWEjCg9D2PvU=.a1987172-af6b-4a62-900a-f5233ae73477@github.com>
Message-ID: <j4ks7N1RH212yItVdCB-k_jrU-Knp-4XMj2SgPSDP94=.db0a67cc-8979-4d3f-9c7a-cd014014424f@github.com>

On Mon, 30 Jun 2025 13:18:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
>> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
>> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.
>
> src/java.base/share/classes/java/security/SecureRandom.java line 841:
> 
>> 839:     }
>> 840: 
>> 841:     @Override
> 
> This method will appear in the javadoc for `SecureRandom` now, so I think you need to add the `inheritDoc` tag to incorporate the superclass` javadoc.

This won't appear in the list of methods declared by `SecureRandom`. An analogy is [`ConcurrentHashMap::forEach(BiConsumer)`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#methods-inherited-from-class-java.util.concurrent.ConcurrentMap): this method is [overridden in `ConcurrentHashMap`](https://github.com/openjdk/jdk/blob/jdk24/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L1613) but is described by Javadoc as "Methods declared in interface java.util.concurrent.ConcurrentMap".

Since this method won't appear, we don't need an `@inheritDoc` tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26005#discussion_r2175319564

From mullan at openjdk.org  Mon Jun 30 15:23:43 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 30 Jun 2025 15:23:43 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage
In-Reply-To: <j4ks7N1RH212yItVdCB-k_jrU-Knp-4XMj2SgPSDP94=.db0a67cc-8979-4d3f-9c7a-cd014014424f@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
 <kpTRhT_FL1iU7hyev_smBN_LOhFt6SbaWEjCg9D2PvU=.a1987172-af6b-4a62-900a-f5233ae73477@github.com>
 <j4ks7N1RH212yItVdCB-k_jrU-Knp-4XMj2SgPSDP94=.db0a67cc-8979-4d3f-9c7a-cd014014424f@github.com>
Message-ID: <QFzldRJRMuylnXQZRJeHSE-r41yOJh4_KsU8Glfhfmo=.0a535a6f-b5d1-4e51-a61e-e734cf319b26@github.com>

On Mon, 30 Jun 2025 15:12:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/SecureRandom.java line 841:
>> 
>>> 839:     }
>>> 840: 
>>> 841:     @Override
>> 
>> This method will appear in the javadoc for `SecureRandom` now, so I think you need to add the `inheritDoc` tag to incorporate the superclass` javadoc.
>
> This won't appear in the list of methods declared by `SecureRandom`. An analogy is [`ConcurrentHashMap::forEach(BiConsumer)`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/concurrent/ConcurrentHashMap.html#methods-inherited-from-class-java.util.concurrent.ConcurrentMap): this method is [overridden in `ConcurrentHashMap`](https://github.com/openjdk/jdk/blob/jdk24/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L1613) but is described by Javadoc as "Methods declared in interface java.util.concurrent.ConcurrentMap".
> 
> Since this method won't appear, we don't need an `@inheritDoc` tag.

I don't know, that seems less obvious to me, as I can't tell if the class is overriding the method or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26005#discussion_r2175339692

From valeriep at openjdk.org  Mon Jun 30 16:56:40 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 30 Jun 2025 16:56:40 GMT
Subject: RFR: 8356997: /etc/krb5.conf parser should not forbid
 include/includedir directives after sections [v4]
In-Reply-To: <f8-Xdfm8TUPcMVGOIwPg5e5xiWqBZt_w01WQev27j-Q=.825211cb-1d1c-46f6-b9b3-577e9fe1ce32@github.com>
References: <J7Mfx9UGyrmn54abJmZEZO32FwbJIKhMAiU4UxTo6ek=.b495100e-79a6-469d-8128-11c86a9e6829@github.com>
 <f8-Xdfm8TUPcMVGOIwPg5e5xiWqBZt_w01WQev27j-Q=.825211cb-1d1c-46f6-b9b3-577e9fe1ce32@github.com>
Message-ID: <dtzVl_zf0uY7l3cRf2LWWqFpbt7O3L1mVWWESXch3RA=.371ae42a-d4cb-4fe0-9fa8-1311ddc00598@github.com>

On Sun, 22 Jun 2025 02:30:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Several changes are made:
>> 
>> 1. The "include" and "includedir" directives can appear everywhere, even inside a section or a sub-section. However, it only means the content is inserted here but the included file still need its own full structure -- from section to subsections.
>> 2. The same file can be included multiple times as long as not recursively.
>> 3. Everything is merged. For duplicated values, `get` returns the first one and `getAll` returns all joining by spaces.
>> 
>> Two new tests added. I also separately confirmed that they are parsed in the same way as [MIT krb5](https://github.com/krb5/krb5/blob/master/src/util/profile/test_parse.c). MIT krb5 ignores directory name after "include" but here it's an error.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another test; no dups clone
>   
>   interdiff impossible; taking evasive action
>   reverted:

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25421#pullrequestreview-2971995565

From duke at openjdk.org  Mon Jun 30 17:45:23 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Mon, 30 Jun 2025 17:45:23 GMT
Subject: RFR: 8357915: SecureRandom nextLong memory usage [v2]
In-Reply-To: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
References: <yGCkD2IEWZYPJ5Mcc-HvGbwzcWZS-QF_o-4UolVU5Zs=.f5efda26-ea6f-4dc7-b60e-f3c9b8f2d8d2@github.com>
Message-ID: <XTYzDh-pUL6Sm7YMGHUHhe3FnsmbGcCn3Nx1bbLgw_Y=.62028d71-2795-4048-a81d-5e989226e71f@github.com>

> SecureRandom uses straightforward implementations inherited from Random but in the process does double the memory allocations necessary.
> The delegation to SecureRandom.engineNextBytes does not provide `int` or `long` values, the caller must allocate a byte array and assemble the value itself.
> So added an implementation in SecureRandom that call nextBytes(8 bytes) and then convert that to a long.

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

  8357915: SecureRandom nextLong memory usage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26005/files
  - new: https://git.openjdk.org/jdk/pull/26005/files/23228fd8..04f859bd

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

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

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

From anthony.scarpino at oracle.com  Mon Jun 30 21:51:53 2025
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 30 Jun 2025 14:51:53 -0700
Subject: Discard or clamp ticket lifetime?
In-Reply-To: <20250630144539.5502766361A@dd33810.kasserver.com>
References: <20250629083148.1000F6610CA@dd33810.kasserver.com>
 <20250629152705.9340D66142E@dd33810.kasserver.com>
 <20250630144539.5502766361A@dd33810.kasserver.com>
Message-ID: <b606a554-f16f-4c7c-af28-2101af6f9f2f@oracle.com>

Hi Bernd,

This likely occurred when stateless ticket handling was introduced in jdk 13. 
For your customer situation, disabling stateless ticket by setting the system 
property "jdk.tls.client.enableSessionTicketExtension" to false may cause the 
server to store the session and allow resumption to operate like jdk 11.

The TLS 1.2 ticket handling should be better about receiving a hint greater 
than the max, instead of just rejecting it.  I don't think the client should 
be storing the ticket for MAX_INT, but storing it for the max of 7 days would 
be fine with me.  JDK-8361108.

Thanks,

Tony


On 6/30/25 7:45 AM, Bernd Eckenfels wrote:
> This OpenSSL Ticket describes the same MAX_INT liferime problem, and they Seen to use clamping as well.
> I think the change and the exakt condition is different (since it is a TLS1.3 issue for them), but the Observation that vsftpd is causing this, will allow us to reproduce it. (I may report it to vsftpd as well).
> 
> https://github.com/openssl/openssl/issues/17948
> 
> Gru?
> Bernd
> 
> Bernd Eckenfels wrote on 29. June 2025 15:27 (GMT +02:00):
>> We deal with a regression in JSSE regarding resumption tickets with high
>> lifetime.
>> In older versions with Java 11 the customer claimed a FTP Server was
>> reachable, with Java 21 the connections are rejected.
> ?


From ecki at zusammenkunft.net  Mon Jun 30 22:07:52 2025
From: ecki at zusammenkunft.net (ecki)
Date: Tue, 1 Jul 2025 00:07:52 +0200
Subject: Discard or clamp ticket lifetime?
In-Reply-To: <b606a554-f16f-4c7c-af28-2101af6f9f2f@oracle.com>
References: <20250629083148.1000F6610CA@dd33810.kasserver.com>
 <20250629152705.9340D66142E@dd33810.kasserver.com>
 <20250630144539.5502766361A@dd33810.kasserver.com>,
 <b606a554-f16f-4c7c-af28-2101af6f9f2f@oracle.com>
Message-ID: <9EA080B3-576D-0044-8D98-8233B9FA0E07@hxcore.ol>

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