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