From wetmore at openjdk.org  Fri Aug  1 00:43:59 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 1 Aug 2025 00:43:59 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v3]
In-Reply-To: <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>
Message-ID: <EaQd4t6jdEt07jF2o51WeTOwtAtkABvmINUE-alL-Cg=.f0a6b2cf-3e22-4fed-b033-65e38a8e5177@github.com>

On Thu, 31 Jul 2025 18:53:20 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Brad's code review

A couple minor fixes.

I'll approve next round.

src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 1101:

> 1099:      * dependent. For example, in TLSv1.3 calling this method after the
> 1100:      * connection has been established will force a key update. For prior TLS
> 1101:      * versions it will force a renegotiation (re-handshake).

You should delete 1115-1116, as it's duplicating what you have here.

src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 520:

> 518:      * to flow during this handshake.  When the handshake completes, this
> 519:      * will be signaled with an event.
> 520:      * <P>

On line 524, put inside a {@code IOException}

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

PR Review: https://git.openjdk.org/jdk/pull/26484#pullrequestreview-3077251110
PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2246633075
PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2246634901

From haosun at openjdk.org  Fri Aug  1 01:07:19 2025
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 1 Aug 2025 01:07:19 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v15]
In-Reply-To: <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
Message-ID: <pYr9JQYqPMwyzKQsUwMen4VUeRivQneH95nccE5T7_g=.aaf8cf9f-b327-4908-a004-6c04e259fc78@github.com>

On Tue, 29 Jul 2025 21:00:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

Hi I found that `test/jdk/javax/management/security/SecurityTest.java` failed after this patch on both AArch64 and x86_64. Filed in https://bugs.openjdk.org/browse/JDK-8364495. I was wondering if you could help take a look at this issue? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-3141799952

From valeriep at openjdk.org  Fri Aug  1 01:43:41 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 1 Aug 2025 01:43:41 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
Message-ID: <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>

> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
> 
> A few implementation notes:
> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
> 
> CSR will be filed once the review is wrapping up.
> 
> Thanks~
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Added support for overriding the security property with a system
  property using the same property name.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26377/files
  - new: https://git.openjdk.org/jdk/pull/26377/files/81c231c6..d4f892fc

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

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

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

From abarashev at openjdk.org  Fri Aug  1 10:15:20 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 10:15:20 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v15]
In-Reply-To: <pYr9JQYqPMwyzKQsUwMen4VUeRivQneH95nccE5T7_g=.aaf8cf9f-b327-4908-a004-6c04e259fc78@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
 <pYr9JQYqPMwyzKQsUwMen4VUeRivQneH95nccE5T7_g=.aaf8cf9f-b327-4908-a004-6c04e259fc78@github.com>
Message-ID: <botxlK5QKf6vhN6fT0_40WWIfSN-8JD3WbHEDhPF_yg=.659ddced-659e-4138-b746-00148eda377d@github.com>

On Fri, 1 Aug 2025 01:04:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

> Hi I found that `test/jdk/javax/management/security/SecurityTest.java` failed after this patch on both AArch64 and x86_64. Filed in https://bugs.openjdk.org/browse/JDK-8364495. I was wondering if you could help take a look at this issue? Thanks.

Hi! It's already fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-3144021668

From kcr at openjdk.org  Fri Aug  1 11:45:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 11:45:56 GMT
Subject: [jdk25] RFR: 8360416: Incorrect l10n test case in
 sun/security/tools/keytool/i18n.java
In-Reply-To: <sfx00ZU9JIRoq4IhtVJM6gmgIrb6cKWaSjeS3vJKnuc=.c8e1be65-36dc-4a7f-8614-a8e89a834d8f@github.com>
References: <-XhmZ0pWwW8rQH9cpS1O73JwpdntJroQyteJ7Z4yO54=.fcbc8a1a-8309-4cae-a60f-60d34d3fb282@github.com>
 <sfx00ZU9JIRoq4IhtVJM6gmgIrb6cKWaSjeS3vJKnuc=.c8e1be65-36dc-4a7f-8614-a8e89a834d8f@github.com>
Message-ID: <0KErfkZjXzDAfLearCGELF0pnDUeKgtYAs_REimC2BI=.cbb7ffb3-199f-44ca-a6d5-b66d14204fa7@github.com>

On Fri, 25 Jul 2025 16:40:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which is a backport of commit [5540a785](https://github.com/openjdk/jdk/commit/5540a7859b3ae0faf6b6c7f50e53ff611b253a9f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> This is a test-only issue which removes an incorrect l10n test case.
>
> @wangweij When you have the chance, are you able to review this issue you already reviewed in mainline. It is a test-only issue and eligible for backport to JDK25. TIA!

@justin-curtis-lu If you plan to integrate this, please do so before the RC build, which is on Aug 7.

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

PR Comment: https://git.openjdk.org/jdk/pull/26431#issuecomment-3144288942

From mullan at openjdk.org  Fri Aug  1 13:07:02 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 1 Aug 2025 13:07:02 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
Message-ID: <_93nDrWDtJXk8v15hGJ0F6EcF6oSKoJyWbunHE8meyM=.cb9276ed-78a5-4c1b-b796-9b747c2e8cac@github.com>

On Fri, 1 Aug 2025 01:43:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
>> 
>> A few implementation notes:
>> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
>> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
>> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
>> 
>> CSR will be filed once the review is wrapping up.
>> 
>> Thanks~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added support for overriding the security property with a system
>   property using the same property name.

src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 80:

> 78:         if (val != null) {
> 79:             Security.setProperty(propertyName, val);
> 80:         }

I don't think you should set the security property with the value of the system property. This should be:


if (val == null) {
    val = Security.getProperty(propertyName);
}


Or you can just call `sun.security.util.SecurityProperties.getOverridableProperty()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2247939762

From mullan at openjdk.org  Fri Aug  1 13:40:06 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 1 Aug 2025 13:40:06 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
Message-ID: <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>

On Thu, 31 Jul 2025 12:58:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

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

Can you attach a snapshot of the output with these new settings?

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

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

From mdonovan at openjdk.org  Fri Aug  1 14:10:54 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 1 Aug 2025 14:10:54 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>
Message-ID: <P4OFtEPX7OPcZFERND0ToyPzWVzz4jZUIL46qhtAMHQ=.c5cc4e86-d7ab-4826-ba07-85f5cdc88231@github.com>

On Fri, 1 Aug 2025 13:36:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Can you attach a snapshot of the output with these new settings?

<img width="1037" height="997" alt="Screenshot 2025-08-01 at 10 07 32?AM" src="https://github.com/user-attachments/assets/0d2efc34-629e-4510-8de9-3acc068a6446" />

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

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

From coffeys at openjdk.org  Fri Aug  1 14:22:59 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 1 Aug 2025 14:22:59 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v4]
In-Reply-To: <PCI99TNLb1gLTIZZscnrJCs7YE6yGgiHLqGTfyBi828=.06968641-8ab0-4548-b4b6-a5e7b3a77557@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <PCI99TNLb1gLTIZZscnrJCs7YE6yGgiHLqGTfyBi828=.06968641-8ab0-4548-b4b6-a5e7b3a77557@github.com>
Message-ID: <eroaTN71sjCsLHuhsB3SWAnbVbCNKUkhsi0dFQ0xbLk=.9d2081bb-0f41-4287-aa0a-5ca175326d06@github.com>

On Wed, 25 Jun 2025 14:01:15 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverting to have only the mixed case to keep the test more consise and still cover toLowerCase

test/jdk/sun/security/util/Debug/DebugOptions.java line 114:

> 112:     }
> 113: 
> 114:     /**

approach looks fine - this comment could be removed or corrected

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2248114669

From coffeys at openjdk.org  Fri Aug  1 14:24:11 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 1 Aug 2025 14:24:11 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
Message-ID: <7pqiE7w7YX6ojyK5Kw7T7LdcwJRqrt-g7EfyCLEzs_Q=.bd4d6ea1-dd60-461c-b40d-e5a6db03f2ad@github.com>

On Thu, 31 Jul 2025 12:58:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

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

LGTM

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24424#pullrequestreview-3079441371

From mullan at openjdk.org  Fri Aug  1 14:30:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 1 Aug 2025 14:30:56 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <P4OFtEPX7OPcZFERND0ToyPzWVzz4jZUIL46qhtAMHQ=.c5cc4e86-d7ab-4826-ba07-85f5cdc88231@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>
 <P4OFtEPX7OPcZFERND0ToyPzWVzz4jZUIL46qhtAMHQ=.c5cc4e86-d7ab-4826-ba07-85f5cdc88231@github.com>
Message-ID: <nG5OTE_uS_t-jXoIJzhDrKi0g9dhP1I1gDGoDY7vbYI=.b414aa67-e0fa-48cf-b49d-a10ed77b5ff6@github.com>

On Fri, 1 Aug 2025 14:08:18 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> > Can you attach a snapshot of the output with these new settings?
> 

I can't see all of the groups or the signature algorithms. Is it truncated?

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

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

From duke at openjdk.org  Fri Aug  1 15:00:03 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 1 Aug 2025 15:00:03 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
 <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
 <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>
Message-ID: <zOTX9iQJ7lBJQBJqbjsLxpnZDGIcT7J2F2anwqQgK7k=.a3ec5a23-d70b-4345-804d-3a4e3472280c@github.com>

On Wed, 30 Jul 2025 10:57:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I?mean the?existing private?fields of?`SharedSecrets`[^1] so?that the?JIT is?able to?constant?fold calls?to?`SharedSecrets?::getJava*Access()` so?that it?becomes equally?as?performant as?using a?`Holder`?class.
>> 
>> Modifiers are?transient, as?those are?sourced?from the?`InnerClasses`?attribute, which?can?be?changed when?classes are?redefined by?a?**JVMTI**?agent, but?access?flags can?t?be?changed through?redefinition.
>> 
>> [^1]: https://github.com/openjdk/jdk/blob/330ee871315348594171c43aa75b58f6027001af/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java#L62-L92
>
> I don't think inner class attributes can be changed via JVMTI RedefineClasses either.  I'm pretty sure we check and that's considered a change of schema.  File an RFE to make SharedSecrets fields @Stable though for a different change.

I?don?t?have a?**JBS**?account, and?I?don?t?like going?through <https://bugreport.java.com>, so?could someone?else file?said?**RFE**?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248196045

From rriggs at openjdk.org  Fri Aug  1 15:12:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Aug 2025 15:12:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <zOTX9iQJ7lBJQBJqbjsLxpnZDGIcT7J2F2anwqQgK7k=.a3ec5a23-d70b-4345-804d-3a4e3472280c@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
 <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
 <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>
 <zOTX9iQJ7lBJQBJqbjsLxpnZDGIcT7J2F2anwqQgK7k=.a3ec5a23-d70b-4345-804d-3a4e3472280c@github.com>
Message-ID: <_0yq0VEEVe1apROVSN5nckimKR_PQOurkq3Rc_qxCwo=.6e7f9c28-6ab6-4561-8336-8133d14badf5@github.com>

On Fri, 1 Aug 2025 14:57:03 GMT, ExE Boss <duke at openjdk.org> wrote:

>> I don't think inner class attributes can be changed via JVMTI RedefineClasses either.  I'm pretty sure we check and that's considered a change of schema.  File an RFE to make SharedSecrets fields @Stable though for a different change.
>
> I?don?t?have a?**JBS**?account, and?I?don?t?like going?through <https://bugreport.java.com>, so?could someone?else file?said?**RFE**?

Created https://bugs.openjdk.org/browse/JDK-8364540

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248224660

From mdonovan at openjdk.org  Fri Aug  1 15:15:01 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 1 Aug 2025 15:15:01 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <nG5OTE_uS_t-jXoIJzhDrKi0g9dhP1I1gDGoDY7vbYI=.b414aa67-e0fa-48cf-b49d-a10ed77b5ff6@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <1FtZN6oSbFuKJJkOy6URLoqnRmPzky00Kyr7_2rnvE4=.92a399b1-6c39-498c-a3e7-438730ea3d0d@github.com>
 <P4OFtEPX7OPcZFERND0ToyPzWVzz4jZUIL46qhtAMHQ=.c5cc4e86-d7ab-4826-ba07-85f5cdc88231@github.com>
 <nG5OTE_uS_t-jXoIJzhDrKi0g9dhP1I1gDGoDY7vbYI=.b414aa67-e0fa-48cf-b49d-a10ed77b5ff6@github.com>
Message-ID: <ev0QpCdSdHP94MUhWURRRszmhIpg8G5BhKvWcJ2cB1M=.5d2aa605-97fd-4a49-b97e-622164019407@github.com>

On Fri, 1 Aug 2025 14:28:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > Can you attach a snapshot of the output with these new settings?
> 
> I can't see all of the groups or the signature algorithms. Is it truncated?

It's not truncated, I just needed to resize the terminal window for a screenshot.
<img width="463" height="909" alt="Screenshot 2025-08-01 at 11 11 11?AM" src="https://github.com/user-attachments/assets/a39b6cd2-2e94-4ba4-a872-75e2cf01b0cc" />

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

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

From abarashev at openjdk.org  Fri Aug  1 15:18:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 15:18:10 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v4]
In-Reply-To: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
Message-ID: <hCWwXOG2sFI3tJy8LpXttN51dQZ4j6wbknWX2sYnAis=.8b064316-85ab-42fa-9b0e-b8b3e3c53e25@github.com>

> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

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

  Address latest review commants

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26484/files
  - new: https://git.openjdk.org/jdk/pull/26484/files/8cf4e12f..5779ff34

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

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

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

From abarashev at openjdk.org  Fri Aug  1 15:18:11 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 15:18:11 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v3]
In-Reply-To: <EaQd4t6jdEt07jF2o51WeTOwtAtkABvmINUE-alL-Cg=.f0a6b2cf-3e22-4fed-b033-65e38a8e5177@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>
 <EaQd4t6jdEt07jF2o51WeTOwtAtkABvmINUE-alL-Cg=.f0a6b2cf-3e22-4fed-b033-65e38a8e5177@github.com>
Message-ID: <LptKwtgCONpcAkrkVNYkF82fGNmhn9TL54xqwpqHTZ4=.a7b519b5-856c-4fa3-85e3-0c2731cbe118@github.com>

On Fri, 1 Aug 2025 00:39:32 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Brad's code review
>
> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 1101:
> 
>> 1099:      * dependent. For example, in TLSv1.3 calling this method after the
>> 1100:      * connection has been established will force a key update. For prior TLS
>> 1101:      * versions it will force a renegotiation (re-handshake).
> 
> You should delete 1115-1116, as it's duplicating what you have here.

Good catch, done!

> src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 520:
> 
>> 518:      * to flow during this handshake.  When the handshake completes, this
>> 519:      * will be signaled with an event.
>> 520:      * <P>
> 
> On line 524, put inside a {@code IOException}

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2248230395
PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2248233328

From coleenp at openjdk.org  Fri Aug  1 15:25:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 1 Aug 2025 15:25:02 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <Nr-UUunnDCGoWJoIBr77q58_1ThDFEX-6vnWFTo01yE=.8ae9dbcb-ddcc-4f84-9816-5de395e839da@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

Thank you for reviewing Tobias, Roger and Chen.

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

PR Comment: https://git.openjdk.org/jdk/pull/26517#issuecomment-3144938447

From coleenp at openjdk.org  Fri Aug  1 15:25:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 1 Aug 2025 15:25:03 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <_0yq0VEEVe1apROVSN5nckimKR_PQOurkq3Rc_qxCwo=.6e7f9c28-6ab6-4561-8336-8133d14badf5@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
 <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
 <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>
 <zOTX9iQJ7lBJQBJqbjsLxpnZDGIcT7J2F2anwqQgK7k=.a3ec5a23-d70b-4345-804d-3a4e3472280c@github.com>
 <_0yq0VEEVe1apROVSN5nckimKR_PQOurkq3Rc_qxCwo=.6e7f9c28-6ab6-4561-8336-8133d14badf5@github.com>
Message-ID: <qtwv2gD8ZM7JHaR64AvAi16QItv4CZOrT3Bc1-29A-U=.d3420e33-b31b-4b18-b9e9-d36cab0e0096@github.com>

On Fri, 1 Aug 2025 15:10:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I?don?t?have a?**JBS**?account, and?I?don?t?like going?through <https://bugreport.java.com>, so?could someone?else file?said?**RFE**?
>
> Created https://bugs.openjdk.org/browse/JDK-8364540

Thanks Roger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248246788

From coleenp at openjdk.org  Fri Aug  1 15:25:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 1 Aug 2025 15:25:04 GMT
Subject: Integrated: 8364187: Make getClassAccessFlagsRaw non-native
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <2HVJZKZ8FwStZduaGH4jA-zQsd8VDH4VF_1lnO1lDlY=.790ad8b0-d8da-43c5-81d5-97387b6ddcad@github.com>

On Mon, 28 Jul 2025 20:14:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: ee3665bc
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee3665bca026fe53409df8391d49477c64ae23a2
Stats:     128 lines in 16 files changed: 61 ins; 36 del; 31 mod

8364187: Make getClassAccessFlagsRaw non-native

Reviewed-by: thartmann, rriggs, liach

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

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

From coleenp at openjdk.org  Fri Aug  1 15:25:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 1 Aug 2025 15:25:03 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <h0k-2CPFK6Zh2eVLqfuvVDUmxXo5Drkgo-0XVM85A3s=.9b435eba-01c4-4dd3-933b-ed0cdb89187a@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>
 <WaSIOivDQRRQnonz9wGKjhjtHhtDduz6boD7uMyM86Y=.e62e0a8c-0f0c-4e23-846f-3744707527fa@github.com>
 <h0k-2CPFK6Zh2eVLqfuvVDUmxXo5Drkgo-0XVM85A3s=.9b435eba-01c4-4dd3-933b-ed0cdb89187a@github.com>
Message-ID: <jIpeMc9SvMoKF4H612gN8vP-VpMJb81CxP9gwG-W2Eg=.95089384-3d63-4e78-980f-9c84262953bd@github.com>

On Tue, 29 Jul 2025 14:35:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is a good suggestion but I made it Raw to match getRawClassAnnotations this name.
>
> Thanks for the rename. I think `raw annotations` means the uninterpreted byte data in the attribute is carried over raw; this concept is less applicable to the access_flags u2 value.

Thank you for the suggested name change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2248245044

From mullan at openjdk.org  Fri Aug  1 15:31:00 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 1 Aug 2025 15:31:00 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
Message-ID: <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>

On Thu, 31 Jul 2025 12:58:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

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

Thanks for the latest screenshot. I don't think the signature algorithms should be "none". If we can't access the provider-specific defaults, then I think we should omit this information for now. @artur-oracle or @haimaychao can you check this out and see if there is a way to get those defaults? Thanks.

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

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

From jlu at openjdk.org  Fri Aug  1 16:13:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 16:13:07 GMT
Subject: [jdk25] RFR: 8360416: Incorrect l10n test case in
 sun/security/tools/keytool/i18n.java
In-Reply-To: <-XhmZ0pWwW8rQH9cpS1O73JwpdntJroQyteJ7Z4yO54=.fcbc8a1a-8309-4cae-a60f-60d34d3fb282@github.com>
References: <-XhmZ0pWwW8rQH9cpS1O73JwpdntJroQyteJ7Z4yO54=.fcbc8a1a-8309-4cae-a60f-60d34d3fb282@github.com>
Message-ID: <cMwQ8LWgnjAfXyn2mHKPmDdTEXrFiuoyjcjQ3K4Br4w=.3f0087b6-5bf5-4dc2-a787-32992806a8a5@github.com>

On Tue, 22 Jul 2025 20:44:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [5540a785](https://github.com/openjdk/jdk/commit/5540a7859b3ae0faf6b6c7f50e53ff611b253a9f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only issue which removes an incorrect l10n test case.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26431#issuecomment-3145078161

From jlu at openjdk.org  Fri Aug  1 16:13:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 16:13:08 GMT
Subject: [jdk25] Integrated: 8360416: Incorrect l10n test case in
 sun/security/tools/keytool/i18n.java
In-Reply-To: <-XhmZ0pWwW8rQH9cpS1O73JwpdntJroQyteJ7Z4yO54=.fcbc8a1a-8309-4cae-a60f-60d34d3fb282@github.com>
References: <-XhmZ0pWwW8rQH9cpS1O73JwpdntJroQyteJ7Z4yO54=.fcbc8a1a-8309-4cae-a60f-60d34d3fb282@github.com>
Message-ID: <pJxmrD0Ndt_n1kr-8ynKhZB8c7U6tK0WTMU-qe1kHJM=.3c9df8a5-36de-4e20-ad9b-2a7015c3f5ca@github.com>

On Tue, 22 Jul 2025 20:44:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [5540a785](https://github.com/openjdk/jdk/commit/5540a7859b3ae0faf6b6c7f50e53ff611b253a9f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only issue which removes an incorrect l10n test case.

This pull request has now been integrated.

Changeset: 9bdf9eba
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9bdf9ebadd148efad49e8b232c2f530eba217c45
Stats:     9 lines in 1 file changed: 0 ins; 4 del; 5 mod

8360416: Incorrect l10n test case in sun/security/tools/keytool/i18n.java

Reviewed-by: hchao
Backport-of: 5540a7859b3ae0faf6b6c7f50e53ff611b253a9f

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

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

From kdriver at openjdk.org  Fri Aug  1 16:17:36 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 1 Aug 2025 16:17:36 GMT
Subject: RFR: 8364226: Better ECDSASignature Memory Management [v2]
In-Reply-To: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
References: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
Message-ID: <y6T6Lo4n63y-hqOiroyxLg-oDFBg82nSo9ES_6RtXuI=.53d2c6e4-868b-4e61-a222-708d0e7f0121@github.com>

> Enhance the memory management/cleanup for `ECDSASignature`.

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  simplify detection of when to zero

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26516/files
  - new: https://git.openjdk.org/jdk/pull/26516/files/7909b0e4..2cfaefcd

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

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

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

From myankelevich at openjdk.org  Fri Aug  1 16:20:14 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 1 Aug 2025 16:20:14 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v5]
In-Reply-To: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
Message-ID: <0wPeEiZeon8Jhb9idfYUiiv0o4pcWbNNZECNKdBP3TM=.b052cf98-fbdc-49f5-aeae-72426066794a@github.com>

> * added an automated mixed case option
> * using multithreading now
> * added logs for simpler debug
> * added missing -Djava.security.auth.debug coverage

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

  comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25391/files
  - new: https://git.openjdk.org/jdk/pull/25391/files/df17d7de..9666cda9

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

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

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

From myankelevich at openjdk.org  Fri Aug  1 16:20:15 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 1 Aug 2025 16:20:15 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v4]
In-Reply-To: <eroaTN71sjCsLHuhsB3SWAnbVbCNKUkhsi0dFQ0xbLk=.9d2081bb-0f41-4287-aa0a-5ca175326d06@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <PCI99TNLb1gLTIZZscnrJCs7YE6yGgiHLqGTfyBi828=.06968641-8ab0-4548-b4b6-a5e7b3a77557@github.com>
 <eroaTN71sjCsLHuhsB3SWAnbVbCNKUkhsi0dFQ0xbLk=.9d2081bb-0f41-4287-aa0a-5ca175326d06@github.com>
Message-ID: <oVdRYv-yyZrqjNj158-0dzYA3I3Je55Im8S5lnBKC7E=.1e125527-7f55-4ed2-8aea-2385805e266f@github.com>

On Fri, 1 Aug 2025 14:20:15 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reverting to have only the mixed case to keep the test more consise and still cover toLowerCase
>
> test/jdk/sun/security/util/Debug/DebugOptions.java line 114:
> 
>> 112:     }
>> 113: 
>> 114:     /**
> 
> approach looks fine - this comment could be removed or corrected

Thanks! Done in the next commit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25391#discussion_r2248368885

From kdriver at openjdk.org  Fri Aug  1 16:20:32 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 1 Aug 2025 16:20:32 GMT
Subject: RFR: 8364226: Better ECDSASignature Memory Management [v3]
In-Reply-To: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
References: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
Message-ID: <nHsoy5CqyU8iy5xV2riGqx9ewUUnQ-ywMJS4EDEhy_Q=.c8517b4a-9d6c-4c82-85b7-5862698edaeb@github.com>

> Enhance the memory management/cleanup for `ECDSASignature`.

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  remove whitespace differences

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26516/files
  - new: https://git.openjdk.org/jdk/pull/26516/files/2cfaefcd..76ed979e

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

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

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

From kdriver at openjdk.org  Fri Aug  1 16:25:37 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 1 Aug 2025 16:25:37 GMT
Subject: RFR: 8364226: Better ECDSASignature Memory Management [v4]
In-Reply-To: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
References: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
Message-ID: <be8clfPn07zGVuUs4H9iXTzBiMeaENLqGHRm8uiij1g=.a622ff0b-41b7-44fc-9ed9-cdb1950acf3b@github.com>

> Enhance the memory management/cleanup for `ECDSASignature`.

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  remove whitespace differences

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26516/files
  - new: https://git.openjdk.org/jdk/pull/26516/files/76ed979e..fa468221

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

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

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

From coffeys at openjdk.org  Fri Aug  1 16:25:59 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 1 Aug 2025 16:25:59 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v5]
In-Reply-To: <0wPeEiZeon8Jhb9idfYUiiv0o4pcWbNNZECNKdBP3TM=.b052cf98-fbdc-49f5-aeae-72426066794a@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <0wPeEiZeon8Jhb9idfYUiiv0o4pcWbNNZECNKdBP3TM=.b052cf98-fbdc-49f5-aeae-72426066794a@github.com>
Message-ID: <PHCjrWxuCIoymoWJW52WDh5d98XHNkDAhYWCqzSCL4g=.779eea11-02f6-467a-8496-e202f21911fa@github.com>

On Fri, 1 Aug 2025 16:20:14 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment fix

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25391#pullrequestreview-3079847026

From duke at openjdk.org  Fri Aug  1 16:28:58 2025
From: duke at openjdk.org (duke)
Date: Fri, 1 Aug 2025 16:28:58 GMT
Subject: RFR: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase [v5]
In-Reply-To: <0wPeEiZeon8Jhb9idfYUiiv0o4pcWbNNZECNKdBP3TM=.b052cf98-fbdc-49f5-aeae-72426066794a@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
 <0wPeEiZeon8Jhb9idfYUiiv0o4pcWbNNZECNKdBP3TM=.b052cf98-fbdc-49f5-aeae-72426066794a@github.com>
Message-ID: <VOm87lyImYPixmONDh4DGwp19iJSUuWJX0231KxFeJA=.414e2707-eac9-4d8c-8a71-1342b019c87b@github.com>

On Fri, 1 Aug 2025 16:20:14 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * added an automated mixed case option
>> * using multithreading now
>> * added logs for simpler debug
>> * added missing -Djava.security.auth.debug coverage
>
> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment fix

@myankelev 
Your change (at version 9666cda9121776e188a5d32eaead3c8268cb3c83) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25391#issuecomment-3145121988

From myankelevich at openjdk.org  Fri Aug  1 18:46:02 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 1 Aug 2025 18:46:02 GMT
Subject: Integrated: 8357470:
 src/java.base/share/classes/sun/security/util/Debug.java implement the test
 for args.toLowerCase
In-Reply-To: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
References: <MDPRxMxkgFeoqM-o1gwneXi5fMlYl-bzQopeJG-AJU8=.193dc426-c384-4afe-81d0-1205cb0a5985@github.com>
Message-ID: <t43xKuKr4neCKwBQ83eVMhq_mn3UTRuEYep2-CdAu_Q=.5e587332-48b4-42b2-8089-638077af8735@github.com>

On Thu, 22 May 2025 12:22:26 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> * added an automated mixed case option
> * using multithreading now
> * added logs for simpler debug
> * added missing -Djava.security.auth.debug coverage

This pull request has now been integrated.

Changeset: 6d0bbc8a
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6d0bbc8a18fa555b5e8d132bef400097ef6ee5cb
Stats:     131 lines in 1 file changed: 87 ins; 4 del; 40 mod

8357470: src/java.base/share/classes/sun/security/util/Debug.java implement the test for args.toLowerCase

Reviewed-by: coffeys

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

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

From hchao at openjdk.org  Fri Aug  1 19:11:01 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 1 Aug 2025 19:11:01 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
Message-ID: <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>

On Fri, 1 Aug 2025 15:28:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Thanks for the latest screenshot. I don't think the signature algorithms should be "none". If we can't access the provider-specific defaults, then I think we should omit this information for now. @artur-oracle or @haimaychao can you check this out and see if there is a way to get those defaults? Thanks.

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/net/ssl/SSLParameters.java#L852
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/net/ssl/SSLParameters.java#L868

So if we never call `setSignatureSchemes()` on the `SSLParameters`, then `getSignatureSchemes()` will return null. But it doesn't mean no signature schemes are used, and it means underlying provider-specific default signature schemes will be used over the TLS connections. We may use `System.getProperty("jdk.tls.client.SignatureSchemes")`, but it works if the property has been set. It seems no public API we can use to query it directly.

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

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

From ascarpino at openjdk.org  Fri Aug  1 19:17:53 2025
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 1 Aug 2025 19:17:53 GMT
Subject: RFR: 8364226: Better ECDSASignature Memory Management [v4]
In-Reply-To: <be8clfPn07zGVuUs4H9iXTzBiMeaENLqGHRm8uiij1g=.a622ff0b-41b7-44fc-9ed9-cdb1950acf3b@github.com>
References: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
 <be8clfPn07zGVuUs4H9iXTzBiMeaENLqGHRm8uiij1g=.a622ff0b-41b7-44fc-9ed9-cdb1950acf3b@github.com>
Message-ID: <0oCCMXPpvtXkMYmS4s20SclxDRuWA1ao-qXSCUrUPGE=.beb665b3-b25f-4c63-bcd9-a4ba20dcb51b@github.com>

On Fri, 1 Aug 2025 16:25:37 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Enhance the memory management/cleanup for `ECDSASignature`.
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove whitespace differences

Change looks good. Thanks.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26516#pullrequestreview-3080321194

From hchao at openjdk.org  Fri Aug  1 19:24:04 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 1 Aug 2025 19:24:04 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
Message-ID: <qgN4wPVujSOrsGzxtvzywgmy9HRBcyBjmR07O29YoOo=.658f7cca-8d8d-48b2-9bff-fa8599775772@github.com>

On Thu, 31 Jul 2025 12:58:21 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

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

Links to API doc should be:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/net/ssl/SSLParameters.java#L729
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/net/ssl/SSLParameters.java#L745

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

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

From abarashev at openjdk.org  Fri Aug  1 19:27:55 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 19:27:55 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
 <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
Message-ID: <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>

On Fri, 1 Aug 2025 19:08:22 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Thanks for the latest screenshot. I don't think the signature algorithms should be "none". If we can't access the provider-specific defaults, then I think we should omit this information for now. @artur-oracle or @haimaychao can you check this out and see if there is a way to get those defaults? Thanks.

We actually have 2 lists of signature algorithms: one for the handshake and another for certificates. Both lists are being constructed only during the TLS handshake (see `SignatureScheme.updateHandshakeLocalSupportedAlgs` method).  There is no public API currently to get those lists, although it shouldn't be hard to add such API call.
The code currently being reviewed should only display signature schemes set with `jdk.tls.client.SignatureSchemes` system property.

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

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

From hchao at openjdk.org  Fri Aug  1 20:13:58 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 1 Aug 2025 20:13:58 GMT
Subject: RFR: 8364226: Better ECDSASignature Memory Management [v4]
In-Reply-To: <be8clfPn07zGVuUs4H9iXTzBiMeaENLqGHRm8uiij1g=.a622ff0b-41b7-44fc-9ed9-cdb1950acf3b@github.com>
References: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
 <be8clfPn07zGVuUs4H9iXTzBiMeaENLqGHRm8uiij1g=.a622ff0b-41b7-44fc-9ed9-cdb1950acf3b@github.com>
Message-ID: <eroMKgYSRfIGIGoKQ--5L6OUhrQfCUrP0fSiJXPXA_Y=.86aa4138-9139-487f-bfcc-b09039c34f7b@github.com>

On Fri, 1 Aug 2025 16:25:37 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Enhance the memory management/cleanup for `ECDSASignature`.
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove whitespace differences

Marked as reviewed by hchao (Reviewer).

Looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/26516#pullrequestreview-3080449601
PR Comment: https://git.openjdk.org/jdk/pull/26516#issuecomment-3145659233

From wetmore at openjdk.org  Fri Aug  1 20:13:58 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 1 Aug 2025 20:13:58 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v4]
In-Reply-To: <hCWwXOG2sFI3tJy8LpXttN51dQZ4j6wbknWX2sYnAis=.8b064316-85ab-42fa-9b0e-b8b3e3c53e25@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <hCWwXOG2sFI3tJy8LpXttN51dQZ4j6wbknWX2sYnAis=.8b064316-85ab-42fa-9b0e-b8b3e3c53e25@github.com>
Message-ID: <K7wQuY_8jTVtDX2QMeB_gAqcfg26Y43EBkYszmCGUjU=.bc021f52-137c-4757-b913-bf968db3cb55@github.com>

On Fri, 1 Aug 2025 15:18:10 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address latest review commants

LGTM.  Thanks for the updates.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26484#pullrequestreview-3080451570

From sebastian.stenzel at gmail.com  Sat Aug  2 17:42:53 2025
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Sat, 2 Aug 2025 19:42:53 +0200
Subject: X-Wing KEM
In-Reply-To: <12EDA0E7-4E62-45FA-ACDB-F64024940720@oracle.com>
References: <749F5007-1175-441D-AC4A-6BD493C309AB@oracle.com>
 <FA1B3534-E9B2-43E6-82DC-B32B9D045295@gmail.com>
 <12EDA0E7-4E62-45FA-ACDB-F64024940720@oracle.com>
Message-ID: <6D611C3E-04D4-48D1-803E-819AAF88A7FA@gmail.com>

Hi,

I merged your NamedPKCS8Key branch into the X-Wing branch and tried to adjust to the new API. I encountered one problem:

With your changes, `NamedKEM#implDecapsulate` will now receive the expanded key (no longer the raw seed). So far, so good. However, in X-Wing I need to split this into an ML-KEM key and the X25519 key. Now here is the problem: If I only have expanded bytes, how can I construct an ML-KEM key? NamedPKCS8Key requires ?raw key bytes, not null? (i.e. the seed) and only optionally the expanded bytes.

Is there any internal API I can use to run ML-KEM?s decapsulate with a byte[] key?

Otherwise, I would suggest that you widen the signature of `NamedKEM#implDecapsulate` to receive both parameters, the seed and the expanded key.

Cheers,
Sebastian

> On 23. Jul 2025, at 17:52, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> 
> 
>> On Jul 23, 2025, at 11:41, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>> 
>> Welcome back, I hope you enjoyed the time! :-)
>> 
>> If you find time, can you give me an update on the ASN.1 key encoding topic? This is the only remaining issue to fulfill the spec. Afterwards we simply need to wait for the final test vectors and publication of the RFC.
> 
> https://github.com/openjdk/jdk/pull/24969 updated NamedPKCS8Key which contains both the encoding format (as in PKCS #8) and the expanded format (used in calculation). For X-Wing, I think the encoding will be the seed, but you are free to choose the expanded format, or, you can "expand" it to an arbitrary object at NamdKEM::implCheckPrivateKey. The KeyPairGenerator interface does not have a deterministic generateKey method so you will have to call internal methods for both ML-KEM and x25519.
> 
> Thanks,
> Weijun
> 
>> 
>> Thank you!
>> Sebastian
>> 
>>> Am 23.07.2025 um 14:33 schrieb Wei-Jun Wang <weijun.wang at oracle.com>:
>>> 
>>> ?Hi Sebastian,
>>> 
>>> I'm back from my vacation. Thanks for the update.
>>> 
>>> I agree, using NamedKey is probably a better choice anyway. It's nice that getParams() always return a name and we don't need to call getAlgorithm() as a fallback.
>>> 
>>> Thanks,
>>> Weijun
>>> 
>>>> On Jun 30, 2025, at 06:06, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>> 
>>>> Quoting Bas Westerbaan (in CC) again, we will most likely see further PQ/T hybrids from the IETF crypto forum research group (CFRG for short):
>>>> 
>>>>> It seems likely that the CFRG will at some point produce a P-384+ML-KEM-1024 hybrid. See https://mailarchive.ietf.org/arch/msg/cfrg/CwrVvm-J7o85TEWkG9RJxZwfXDY/ . That might take some time.
>>>>> 
>>>>> Very few (but notably Ericsson) have asked for X448 hybrids, so I don't expect them soon.
>>>> 
>>>> That said, the construction does not necessarily be compatible to X-Wing. Just to be sure, I asked whether they see any value in parameterizing X-Wing to swap out algorithms. This is what Bas replied:
>>>> 
>>>>> Even if the other hybrids will also use an X-Wing style combiner, it doesn't hurt not to parametrize initially. :)
>>>> 
>>>> So I would suggest to follow this advice for now and only refactor the implementation eventually, when further pairs of algorithms are combined in the same way.
>>>> 
>>>> Best,
>>>> Sebastian
>>>> 
>>>> 
>>>>>> On 29. Jun 2025, at 12:02, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>> 
>>>>> 
>>>>>> On 28. Jun 2025, at 00:12, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>> 
>>>>>> [...] After all, there is no parameter for X-Wing. Did you hear the authors they want to introduce other algorithms like ed448 and ML-KEM-1024 into it?
>>>>> 
>>>>> I forwarded this question and let you know the answer!
>>>>> 
>>>>> 
>>>>>>> 
>>>>>>>> On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> Cool.
>>>>>>>> 
>>>>>>>> The current NamedPKCS8Key was designed based on an older approach where modern asymmetric keys store private key data in a nested OCTET STRING format. This pattern was introduced with EdDSA and XDH, and at the time of JDK 24, we anticipated it would become the norm.
>>>>>>>> 
>>>>>>>> However, things have changed significantly, as seen in the evolution of draft-ietf-lamps-dilithium-certificates and draft-ietf-lamps-kyber-certificates. The original design now needs to be revised. While we?re still waiting for the IETF drafts to be finalized, we?re already experimenting with changes in https://github.com/openjdk/jdk/pull/24969.
>>>>>>>> 
>>>>>>>> Hopefully, by the time X-Wing is finalized, we?ll already have a solution in place.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Weijun
>>>>>>>> 
>>>>>>>>> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Weijun,
>>>>>>>>> 
>>>>>>>>> I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:
>>>>>>>>> 
>>>>>>>>> The (current) X-Wing spec wants this PKCS#8 encoding: [1]
>>>>>>>>> 
>>>>>>>>> However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2]
>>>>>>>>> 
>>>>>>>>> Note the difference here:
>>>>>>>>> * https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f
>>>>>>>>> * https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo
>>>>>>>>> 
>>>>>>>>> I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this?
>>>>>>>>> 
>>>>>>>>> Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don?t seem to be complete yet.
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> Sebastian
>>>>>>>>> 
>>>>>>>>> [0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing
>>>>>>>>> [1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D
>>>>>>>>> [2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81
>>>>>>>>> 
>>>>>>>>>> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Weijun,
>>>>>>>>>>> 
>>>>>>>>>>> waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet?
>>>>>>>>>> 
>>>>>>>>>> Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
>>>>>>>>>>> 
>>>>>>>>>>> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.
>>>>>>>>>> 
>>>>>>>>>> I see.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]
>>>>>>>>>> 
>>>>>>>>>> Nice to know. Sorry I didn't noticed that earlier.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Weijun
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Sebastian
>>>>>>>>>>> 
>>>>>>>>>>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
>>>>>>>>>>> 
>>>>>>>>>>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Sebastian.
>>>>>>>>>>>> 
>>>>>>>>>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks for your continued interest on enhancing OpenJDK.
>>>>>>>>>>>> 
>>>>>>>>>>>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>>>>>>>>>>>> 
>>>>>>>>>>>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Alternatively, can we make the two mentioned APIs public?
>>>>>>>>>>>> 
>>>>>>>>>>>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>>>>>>>>>>>> 
>>>>>>>>>>>> [1] https://openjdk.org/guide/
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Weijun
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>>>>>>>>>>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>>>>>>>>>>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4407 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250802/03eab836/smime-0001.p7s>

From weijun.wang at oracle.com  Sun Aug  3 19:56:23 2025
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Sun, 3 Aug 2025 19:56:23 +0000
Subject: X-Wing KEM
In-Reply-To: <6D611C3E-04D4-48D1-803E-819AAF88A7FA@gmail.com>
References: <749F5007-1175-441D-AC4A-6BD493C309AB@oracle.com>
 <FA1B3534-E9B2-43E6-82DC-B32B9D045295@gmail.com>
 <12EDA0E7-4E62-45FA-ACDB-F64024940720@oracle.com>
 <6D611C3E-04D4-48D1-803E-819AAF88A7FA@gmail.com>
Message-ID: <EB97C67F-0F40-4968-965F-4E301228E9A9@oracle.com>

The ML-KEM key does not need to be serialized anywhere so I think its encoding does not matter. If you already have the expanded key you can directly create a NamedPKCS8Key whose expander is an identity function, i.e. both its encoding and expanded key are the expanded key itself. The encoding does not necessarily be the seed.

Thanks,
Weijun

> On Aug 2, 2025, at 13:42, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
> 
> Hi,
> 
> I merged your NamedPKCS8Key branch into the X-Wing branch and tried to adjust to the new API. I encountered one problem:
> 
> With your changes, `NamedKEM#implDecapsulate` will now receive the expanded key (no longer the raw seed). So far, so good. However, in X-Wing I need to split this into an ML-KEM key and the X25519 key. Now here is the problem: If I only have expanded bytes, how can I construct an ML-KEM key? NamedPKCS8Key requires ?raw key bytes, not null? (i.e. the seed) and only optionally the expanded bytes.
> 
> Is there any internal API I can use to run ML-KEM?s decapsulate with a byte[] key?
> 
> Otherwise, I would suggest that you widen the signature of `NamedKEM#implDecapsulate` to receive both parameters, the seed and the expanded key.
> 
> Cheers,
> Sebastian
> 
>> On 23. Jul 2025, at 17:52, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>> 
>> 
>> 
>>> On Jul 23, 2025, at 11:41, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>> 
>>> Welcome back, I hope you enjoyed the time! :-)
>>> 
>>> If you find time, can you give me an update on the ASN.1 key encoding topic? This is the only remaining issue to fulfill the spec. Afterwards we simply need to wait for the final test vectors and publication of the RFC.
>> 
>> https://github.com/openjdk/jdk/pull/24969 updated NamedPKCS8Key which contains both the encoding format (as in PKCS #8) and the expanded format (used in calculation). For X-Wing, I think the encoding will be the seed, but you are free to choose the expanded format, or, you can "expand" it to an arbitrary object at NamdKEM::implCheckPrivateKey. The KeyPairGenerator interface does not have a deterministic generateKey method so you will have to call internal methods for both ML-KEM and x25519.
>> 
>> Thanks,
>> Weijun
>> 
>>> 
>>> Thank you!
>>> Sebastian
>>> 
>>>> Am 23.07.2025 um 14:33 schrieb Wei-Jun Wang <weijun.wang at oracle.com>:
>>>> 
>>>> ?Hi Sebastian,
>>>> 
>>>> I'm back from my vacation. Thanks for the update.
>>>> 
>>>> I agree, using NamedKey is probably a better choice anyway. It's nice that getParams() always return a name and we don't need to call getAlgorithm() as a fallback.
>>>> 
>>>> Thanks,
>>>> Weijun
>>>> 
>>>>> On Jun 30, 2025, at 06:06, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>> 
>>>>> Quoting Bas Westerbaan (in CC) again, we will most likely see further PQ/T hybrids from the IETF crypto forum research group (CFRG for short):
>>>>> 
>>>>>> It seems likely that the CFRG will at some point produce a P-384+ML-KEM-1024 hybrid. See https://mailarchive.ietf.org/arch/msg/cfrg/CwrVvm-J7o85TEWkG9RJxZwfXDY/ . That might take some time.
>>>>>> 
>>>>>> Very few (but notably Ericsson) have asked for X448 hybrids, so I don't expect them soon.
>>>>> 
>>>>> That said, the construction does not necessarily be compatible to X-Wing. Just to be sure, I asked whether they see any value in parameterizing X-Wing to swap out algorithms. This is what Bas replied:
>>>>> 
>>>>>> Even if the other hybrids will also use an X-Wing style combiner, it doesn't hurt not to parametrize initially. :)
>>>>> 
>>>>> So I would suggest to follow this advice for now and only refactor the implementation eventually, when further pairs of algorithms are combined in the same way.
>>>>> 
>>>>> Best,
>>>>> Sebastian
>>>>> 
>>>>> 
>>>>>>> On 29. Jun 2025, at 12:02, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 28. Jun 2025, at 00:12, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>> 
>>>>>>> [...] After all, there is no parameter for X-Wing. Did you hear the authors they want to introduce other algorithms like ed448 and ML-KEM-1024 into it?
>>>>>> 
>>>>>> I forwarded this question and let you know the answer!
>>>>>> 
>>>>>> 
>>>>>>>> 
>>>>>>>>> On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> Cool.
>>>>>>>>> 
>>>>>>>>> The current NamedPKCS8Key was designed based on an older approach where modern asymmetric keys store private key data in a nested OCTET STRING format. This pattern was introduced with EdDSA and XDH, and at the time of JDK 24, we anticipated it would become the norm.
>>>>>>>>> 
>>>>>>>>> However, things have changed significantly, as seen in the evolution of draft-ietf-lamps-dilithium-certificates and draft-ietf-lamps-kyber-certificates. The original design now needs to be revised. While we?re still waiting for the IETF drafts to be finalized, we?re already experimenting with changes in https://github.com/openjdk/jdk/pull/24969.
>>>>>>>>> 
>>>>>>>>> Hopefully, by the time X-Wing is finalized, we?ll already have a solution in place.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Weijun
>>>>>>>>> 
>>>>>>>>>> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Weijun,
>>>>>>>>>> 
>>>>>>>>>> I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:
>>>>>>>>>> 
>>>>>>>>>> The (current) X-Wing spec wants this PKCS#8 encoding: [1]
>>>>>>>>>> 
>>>>>>>>>> However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2]
>>>>>>>>>> 
>>>>>>>>>> Note the difference here:
>>>>>>>>>> * https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f
>>>>>>>>>> * https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo
>>>>>>>>>> 
>>>>>>>>>> I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this?
>>>>>>>>>> 
>>>>>>>>>> Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don?t seem to be complete yet.
>>>>>>>>>> 
>>>>>>>>>> Best regards,
>>>>>>>>>> Sebastian
>>>>>>>>>> 
>>>>>>>>>> [0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing
>>>>>>>>>> [1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D
>>>>>>>>>> [2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81
>>>>>>>>>> 
>>>>>>>>>>> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Weijun,
>>>>>>>>>>>> 
>>>>>>>>>>>> waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet?
>>>>>>>>>>> 
>>>>>>>>>>> Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK.
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
>>>>>>>>>>>> 
>>>>>>>>>>>> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.
>>>>>>>>>>> 
>>>>>>>>>>> I see.
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]
>>>>>>>>>>> 
>>>>>>>>>>> Nice to know. Sorry I didn't noticed that earlier.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Weijun
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> Sebastian
>>>>>>>>>>>> 
>>>>>>>>>>>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Sebastian.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks for your continued interest on enhancing OpenJDK.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Alternatively, can we make the two mentioned APIs public?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1] https://openjdk.org/guide/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Weijun
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>>>>>>>>>>>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>>>>>>>>>>>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
> 


From sebastian.stenzel at gmail.com  Sun Aug  3 20:14:33 2025
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Sun, 3 Aug 2025 22:14:33 +0200
Subject: X-Wing KEM
In-Reply-To: <EB97C67F-0F40-4968-965F-4E301228E9A9@oracle.com>
References: <EB97C67F-0F40-4968-965F-4E301228E9A9@oracle.com>
Message-ID: <F0BBA8A9-B0C2-4218-BA9B-995B1572C1AF@gmail.com>


> Am 03.08.2025 um 21:56 schrieb Wei-Jun Wang <weijun.wang at oracle.com>:
> 
> The encoding does not necessarily be the seed.

I see, thanks for the clarification. In this case consider this a request to improve the docs ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2502 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250803/2cd9abff/smime-0001.p7s>

From liach at openjdk.org  Mon Aug  4 00:24:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Aug 2025 00:24:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
Message-ID: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>

Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

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

Commit messages:
 - Years
 - Roll back Objects.rNN for now
 - Review remarks
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Bork
 - Try generify the NPE tracing API
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Perf concerns
 - Tests, MPs based prints
 - Objects rNN better message

Changes: https://git.openjdk.org/jdk/pull/26600/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364588
  Stats: 390 lines in 12 files changed: 335 ins; 13 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/26600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600

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

From liach at openjdk.org  Mon Aug  4 00:24:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Aug 2025 00:24:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <ksPqCsaVSiWksRW5oIZmkZ0TimHDV030yw31f42Vmzs=.9365ce10-9ba7-4da5-b577-e1bb4368886b@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

Thanks for the preliminary review. After some thinking, to avoid wasting review cycles, I am pulling the common infrastructure for requireNonNull and Checks::nullCheck into a JDK-internal API, and the changes here are mostly confined to runtime.

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

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

From dholmes at openjdk.org  Mon Aug  4 00:24:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Aug 2025 00:24:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <FgcCs3wtRwUawkd0mM0h9E9I03F9BAB_8OhTPIEMH4U=.0516eeff-61d5-45c5-a884-312ce07bca5b@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

src/hotspot/share/classfile/javaClasses.cpp line 3060:

> 3058: }
> 3059: 
> 3060: bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool hidden_ok) {

Suggestion:

bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool allow_hidden) {

src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:

> 38:   static bool get_NPE_message_at(outputStream* ss, Method* method, int bci);
> 39:   // NPE extended message. Return true if string is printed.
> 40:   static bool get_NPE_message_at(outputStream* ss, Method* method, int bci, int slot);

Can you combine these with a default slot parameter (-1?) ? I'm suspecting not even though it might appear that once you have the slot you could call the new method, but the new method seems to expect only particular "kinds" of slot i.e. non-bytecode. But this is not documented at all. Please add comments to make it clear what the `slot` parameter is expected to be and how these two methods differ.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2248868942
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2248881502

From liach at openjdk.org  Mon Aug  4 00:24:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Aug 2025 00:24:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <FgcCs3wtRwUawkd0mM0h9E9I03F9BAB_8OhTPIEMH4U=.0516eeff-61d5-45c5-a884-312ce07bca5b@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <FgcCs3wtRwUawkd0mM0h9E9I03F9BAB_8OhTPIEMH4U=.0516eeff-61d5-45c5-a884-312ce07bca5b@github.com>
Message-ID: <sGKHMLSCvSm9UYsRFcahJf7vyYyT1Z0yfAPM4D9nKdo=.de4402e8-ce6f-4e38-94b3-6911cd5d92e0@github.com>

On Fri, 1 Aug 2025 21:05:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>
> src/hotspot/share/classfile/javaClasses.cpp line 3060:
> 
>> 3058: }
>> 3059: 
>> 3060: bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool hidden_ok) {
> 
> Suggestion:
> 
> bool java_lang_Throwable::get_method_and_bci(oop throwable, Method** method, int* bci, int depth, bool allow_hidden) {

Done.

> src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:
> 
>> 38:   static bool get_NPE_message_at(outputStream* ss, Method* method, int bci);
>> 39:   // NPE extended message. Return true if string is printed.
>> 40:   static bool get_NPE_message_at(outputStream* ss, Method* method, int bci, int slot);
> 
> Can you combine these with a default slot parameter (-1?) ? I'm suspecting not even though it might appear that once you have the slot you could call the new method, but the new method seems to expect only particular "kinds" of slot i.e. non-bytecode. But this is not documented at all. Please add comments to make it clear what the `slot` parameter is expected to be and how these two methods differ.

Done, and documented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2250200947
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2250201005

From jjiang at openjdk.org  Mon Aug  4 07:43:35 2025
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 4 Aug 2025 07:43:35 GMT
Subject: RFR: 8364597: Replace THL A29 Limited with Tencent
Message-ID: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>

`THL A29 Limited` was a `Tencent` company but was dissolved.
So, the copyright notes just use `Tencent` directly.

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

Commit messages:
 - 8364597: Replace THL A29 Limited with Tencent

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

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

From duke at openjdk.org  Mon Aug  4 12:53:58 2025
From: duke at openjdk.org (Sebastian Stenzel)
Date: Mon, 4 Aug 2025 12:53:58 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v5]
In-Reply-To: <ZJ_dhGAnbwkBndQhKCXGgj0kRet3emnjRiaC1W-hmrM=.9efe4a90-07d6-4990-8489-a1e5f6e318a5@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <ZJ_dhGAnbwkBndQhKCXGgj0kRet3emnjRiaC1W-hmrM=.9efe4a90-07d6-4990-8489-a1e5f6e318a5@github.com>
Message-ID: <KGc-zsTg-LH46D-1NdEEMTMNTp6yi8MOU5Ev_d4inBM=.a6907280-18b2-4607-94e2-9c46b808878e@github.com>

On Wed, 30 Jul 2025 15:45:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> 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.
>> 
>> By default, the choice is "seed".
>> 
>> 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 incrementally with one additional commit since the last revision:
> 
>   combine security properties description; remove one test

If my understanding is correct, we have now up to three byte[] in the NamedPKCS8Key class:
* the encoded format
* the raw expanded format
* the raw seed

With `getRawBytes()` either returning the encoded or the expanded format, depending on whether the encoded format and the expanded key are the same.

`getEncoded()` on the other hand always wraps the raw key in its ASN.1 structure.

Shouldn't `engineTranslateKey()` rely on the latter, then?

src/java.base/share/classes/com/sun/crypto/provider/ML_KEM_Impls.java line 132:

> 130:             if (nk instanceof NamedPKCS8Key npk) {
> 131:                 var type = KeyChoices.getPreferred("mlkem");
> 132:                 if (KeyChoices.typeOfChoice(npk.getRawBytes()) != type) {

> ```
> /// 1. If only `privKeyMaterial` is present, it's also the expanded format.
> /// 2. If both `privKeyMaterial` and `expanded` are available, `privKeyMaterial`
> ///    is the encoding format, and `expanded` is the expanded format.
> ```

This in mind, the result of `getRawBytes()` differs. In the first case, it is in fact raw bytes, as the method name suggests. (See also usage of `privKeyMaterial` in `PKCS8Key.generateEncoding()`).

Therefore, the ASN.1 envelope may be missing, causing 


java.security.InvalidKeyException: Wrong tag: -39
	at java.base/sun.security.util.KeyChoices.typeOfChoice(KeyChoices.java:144)
	at java.base/com.sun.crypto.provider.ML_KEM_Impls$KF.engineTranslateKey(ML_KEM_Impls.java:132)
	at java.base/java.security.KeyFactory.translateKey(KeyFactory.java:475)


Isn't `getEncoded()` the safer bet?

Suggestion:

                if (KeyChoices.typeOfChoice(npk.getEncoded()) != type) {

src/java.base/share/classes/sun/security/provider/ML_DSA_Impls.java line 157:

> 155:             if (nk instanceof NamedPKCS8Key npk) {
> 156:                 var type = KeyChoices.getPreferred("mldsa");
> 157:                 if (KeyChoices.typeOfChoice(npk.getRawBytes()) != type) {

See corresponding comment above for ML-KEM

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

Changes requested by overheadhunter at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/24969#pullrequestreview-3083718545
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2251165104
PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2251166383

From sebastian.stenzel at gmail.com  Mon Aug  4 12:55:45 2025
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Mon, 4 Aug 2025 14:55:45 +0200
Subject: X-Wing KEM
In-Reply-To: <EB97C67F-0F40-4968-965F-4E301228E9A9@oracle.com>
References: <749F5007-1175-441D-AC4A-6BD493C309AB@oracle.com>
 <FA1B3534-E9B2-43E6-82DC-B32B9D045295@gmail.com>
 <12EDA0E7-4E62-45FA-ACDB-F64024940720@oracle.com>
 <6D611C3E-04D4-48D1-803E-819AAF88A7FA@gmail.com>
 <EB97C67F-0F40-4968-965F-4E301228E9A9@oracle.com>
Message-ID: <A6B06F1D-701B-4E3C-87C0-BC0AA39175C5@gmail.com>

I believe I got it working. Since my PR now relies on [1] your key encoding changes, shall I push the changes or rather wait until your?s is merged into master?

[1]: https://github.com/openjdk/jdk/pull/24969

> On 3. Aug 2025, at 21:56, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> The ML-KEM key does not need to be serialized anywhere so I think its encoding does not matter. If you already have the expanded key you can directly create a NamedPKCS8Key whose expander is an identity function, i.e. both its encoding and expanded key are the expanded key itself. The encoding does not necessarily be the seed.
> 
> Thanks,
> Weijun
> 
>> On Aug 2, 2025, at 13:42, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>> 
>> Hi,
>> 
>> I merged your NamedPKCS8Key branch into the X-Wing branch and tried to adjust to the new API. I encountered one problem:
>> 
>> With your changes, `NamedKEM#implDecapsulate` will now receive the expanded key (no longer the raw seed). So far, so good. However, in X-Wing I need to split this into an ML-KEM key and the X25519 key. Now here is the problem: If I only have expanded bytes, how can I construct an ML-KEM key? NamedPKCS8Key requires ?raw key bytes, not null? (i.e. the seed) and only optionally the expanded bytes.
>> 
>> Is there any internal API I can use to run ML-KEM?s decapsulate with a byte[] key?
>> 
>> Otherwise, I would suggest that you widen the signature of `NamedKEM#implDecapsulate` to receive both parameters, the seed and the expanded key.
>> 
>> Cheers,
>> Sebastian
>> 
>>> On 23. Jul 2025, at 17:52, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> 
>>> 
>>>> On Jul 23, 2025, at 11:41, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>> 
>>>> Welcome back, I hope you enjoyed the time! :-)
>>>> 
>>>> If you find time, can you give me an update on the ASN.1 key encoding topic? This is the only remaining issue to fulfill the spec. Afterwards we simply need to wait for the final test vectors and publication of the RFC.
>>> 
>>> https://github.com/openjdk/jdk/pull/24969 updated NamedPKCS8Key which contains both the encoding format (as in PKCS #8) and the expanded format (used in calculation). For X-Wing, I think the encoding will be the seed, but you are free to choose the expanded format, or, you can "expand" it to an arbitrary object at NamdKEM::implCheckPrivateKey. The KeyPairGenerator interface does not have a deterministic generateKey method so you will have to call internal methods for both ML-KEM and x25519.
>>> 
>>> Thanks,
>>> Weijun
>>> 
>>>> 
>>>> Thank you!
>>>> Sebastian
>>>> 
>>>>> Am 23.07.2025 um 14:33 schrieb Wei-Jun Wang <weijun.wang at oracle.com>:
>>>>> 
>>>>> ?Hi Sebastian,
>>>>> 
>>>>> I'm back from my vacation. Thanks for the update.
>>>>> 
>>>>> I agree, using NamedKey is probably a better choice anyway. It's nice that getParams() always return a name and we don't need to call getAlgorithm() as a fallback.
>>>>> 
>>>>> Thanks,
>>>>> Weijun
>>>>> 
>>>>>> On Jun 30, 2025, at 06:06, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>> 
>>>>>> Quoting Bas Westerbaan (in CC) again, we will most likely see further PQ/T hybrids from the IETF crypto forum research group (CFRG for short):
>>>>>> 
>>>>>>> It seems likely that the CFRG will at some point produce a P-384+ML-KEM-1024 hybrid. See https://mailarchive.ietf.org/arch/msg/cfrg/CwrVvm-J7o85TEWkG9RJxZwfXDY/ . That might take some time.
>>>>>>> 
>>>>>>> Very few (but notably Ericsson) have asked for X448 hybrids, so I don't expect them soon.
>>>>>> 
>>>>>> That said, the construction does not necessarily be compatible to X-Wing. Just to be sure, I asked whether they see any value in parameterizing X-Wing to swap out algorithms. This is what Bas replied:
>>>>>> 
>>>>>>> Even if the other hybrids will also use an X-Wing style combiner, it doesn't hurt not to parametrize initially. :)
>>>>>> 
>>>>>> So I would suggest to follow this advice for now and only refactor the implementation eventually, when further pairs of algorithms are combined in the same way.
>>>>>> 
>>>>>> Best,
>>>>>> Sebastian
>>>>>> 
>>>>>> 
>>>>>>>> On 29. Jun 2025, at 12:02, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On 28. Jun 2025, at 00:12, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> [...] After all, there is no parameter for X-Wing. Did you hear the authors they want to introduce other algorithms like ed448 and ML-KEM-1024 into it?
>>>>>>> 
>>>>>>> I forwarded this question and let you know the answer!
>>>>>>> 
>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> Cool.
>>>>>>>>>> 
>>>>>>>>>> The current NamedPKCS8Key was designed based on an older approach where modern asymmetric keys store private key data in a nested OCTET STRING format. This pattern was introduced with EdDSA and XDH, and at the time of JDK 24, we anticipated it would become the norm.
>>>>>>>>>> 
>>>>>>>>>> However, things have changed significantly, as seen in the evolution of draft-ietf-lamps-dilithium-certificates and draft-ietf-lamps-kyber-certificates. The original design now needs to be revised. While we?re still waiting for the IETF drafts to be finalized, we?re already experimenting with changes in https://github.com/openjdk/jdk/pull/24969.
>>>>>>>>>> 
>>>>>>>>>> Hopefully, by the time X-Wing is finalized, we?ll already have a solution in place.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Weijun
>>>>>>>>>> 
>>>>>>>>>>> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Weijun,
>>>>>>>>>>> 
>>>>>>>>>>> I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:
>>>>>>>>>>> 
>>>>>>>>>>> The (current) X-Wing spec wants this PKCS#8 encoding: [1]
>>>>>>>>>>> 
>>>>>>>>>>> However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2]
>>>>>>>>>>> 
>>>>>>>>>>> Note the difference here:
>>>>>>>>>>> * https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f
>>>>>>>>>>> * https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo
>>>>>>>>>>> 
>>>>>>>>>>> I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this?
>>>>>>>>>>> 
>>>>>>>>>>> Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don?t seem to be complete yet.
>>>>>>>>>>> 
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Sebastian
>>>>>>>>>>> 
>>>>>>>>>>> [0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing
>>>>>>>>>>> [1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D
>>>>>>>>>>> [2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81
>>>>>>>>>>> 
>>>>>>>>>>>> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Weijun,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet?
>>>>>>>>>>>> 
>>>>>>>>>>>> Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.
>>>>>>>>>>>> 
>>>>>>>>>>>> I see.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]
>>>>>>>>>>>> 
>>>>>>>>>>>> Nice to know. Sorry I didn't noticed that earlier.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Weijun
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi Sebastian.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks for your continued interest on enhancing OpenJDK.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Alternatively, can we make the two mentioned APIs public?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> [1] https://openjdk.org/guide/
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Weijun
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>>>>>>>>>>>>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>>>>>>>>>>>>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4407 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250804/b547669b/smime-0001.p7s>

From mdonovan at openjdk.org  Mon Aug  4 12:59:55 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 4 Aug 2025 12:59:55 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>
 <mKq07UbUqBaAMCgpiDS-oW_VRVkC0KDM8RIpdZPeos8=.ed75404f-e76a-4188-954d-1044b1a7745f@github.com>
 <ojHP_Q-dB5apZOkG13ngaPm83E_wpxUdbjcf9i9bRpY=.038009fa-cd2e-4f6d-8fa5-40a1a24794a1@github.com>
 <Te4rI_U8oqzoaZjU2qMlboFjiXhTIX6v7uzGitVMpew=.befd073a-561c-46f6-8d4c-6cc5a64872b0@github.com>
Message-ID: <cnqT7g1JdcDC0IjD8h386mUWQPL9AgcQOW_Djrjz4l4=.06a5f9be-ad54-4466-936d-7a443560cd2b@github.com>

On Fri, 1 Aug 2025 19:25:43 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> The code currently being reviewed should only display signature schemes set with `jdk.tls.client.SignatureSchemes` system property.

Should that be displayed with `-XshowSettings:security:tls` or `-XshowSettings:security:properties`? On the surface, the latter makes more sense to me.

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

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

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

On Mon, 4 Aug 2025 12:57:20 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> > The code currently being reviewed should only display signature schemes set with `jdk.tls.client.SignatureSchemes` system property.
> 
> Should that be displayed with `-XshowSettings:security:tls` or `-XshowSettings:security:properties`? On the surface, the latter makes more sense to me.

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

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

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

From abarashev at openjdk.org  Mon Aug  4 13:59:03 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 4 Aug 2025 13:59:03 GMT
Subject: Integrated: 8209992: Align SSLSocket and SSLEngine Javadocs
In-Reply-To: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
Message-ID: <gxfNgJoKQIV5OanUNCP_fvHt_Zrc-xty888gAzN1knc=.46821ecf-24cb-4952-bd51-e3f267a27d88@github.com>

On Fri, 25 Jul 2025 16:27:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

This pull request has now been integrated.

Changeset: 6c52b734
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c52b73465b0d0daeafc54c3c6cec3062bf490c5
Stats:     29 lines in 2 files changed: 17 ins; 3 del; 9 mod

8209992: Align SSLSocket and SSLEngine Javadocs

Reviewed-by: wetmore

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

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

From dnsimon at openjdk.org  Mon Aug  4 15:04:04 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 4 Aug 2025 15:04:04 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <bsYDcgavbXfmf2WP_iXtlEJGKPZppbq1yBGektW4cI0=.4e19234e-cd9a-40d7-add6-e6cbcf8ea01c@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

src/hotspot/share/prims/jvm.cpp line 1744:

> 1742: JVM_END
> 1743: 
> 1744: JVM_ENTRY(jint, JVM_GetClassAccessFlags(JNIEnv *env, jclass cls))

What about the declaration in `jvm.h`? https://github.com/openjdk/jdk/blob/6c52b73465b0d0daeafc54c3c6cec3062bf490c5/src/hotspot/share/include/jvm.h#L610

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2251770425

From weijun.wang at oracle.com  Mon Aug  4 15:07:22 2025
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Mon, 4 Aug 2025 15:07:22 +0000
Subject: X-Wing KEM
In-Reply-To: <A6B06F1D-701B-4E3C-87C0-BC0AA39175C5@gmail.com>
References: <749F5007-1175-441D-AC4A-6BD493C309AB@oracle.com>
 <FA1B3534-E9B2-43E6-82DC-B32B9D045295@gmail.com>
 <12EDA0E7-4E62-45FA-ACDB-F64024940720@oracle.com>
 <6D611C3E-04D4-48D1-803E-819AAF88A7FA@gmail.com>
 <EB97C67F-0F40-4968-965F-4E301228E9A9@oracle.com>
 <A6B06F1D-701B-4E3C-87C0-BC0AA39175C5@gmail.com>
Message-ID: <742B0173-2811-4B3A-A791-1C5CB582BDD5@oracle.com>

Just push all changes to the PR and you can remove mine later. I cannot guarantee when my PR can be integrated. Those I-Ds are still in Ed Queue.

--Weijun

> On Aug 4, 2025, at 08:55, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
> 
> I believe I got it working. Since my PR now relies on [1] your key encoding changes, shall I push the changes or rather wait until your?s is merged into master?
> 
> [1]: https://github.com/openjdk/jdk/pull/24969
> 
>> On 3. Aug 2025, at 21:56, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>> 
>> The ML-KEM key does not need to be serialized anywhere so I think its encoding does not matter. If you already have the expanded key you can directly create a NamedPKCS8Key whose expander is an identity function, i.e. both its encoding and expanded key are the expanded key itself. The encoding does not necessarily be the seed.
>> 
>> Thanks,
>> Weijun
>> 
>>> On Aug 2, 2025, at 13:42, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I merged your NamedPKCS8Key branch into the X-Wing branch and tried to adjust to the new API. I encountered one problem:
>>> 
>>> With your changes, `NamedKEM#implDecapsulate` will now receive the expanded key (no longer the raw seed). So far, so good. However, in X-Wing I need to split this into an ML-KEM key and the X25519 key. Now here is the problem: If I only have expanded bytes, how can I construct an ML-KEM key? NamedPKCS8Key requires ?raw key bytes, not null? (i.e. the seed) and only optionally the expanded bytes.
>>> 
>>> Is there any internal API I can use to run ML-KEM?s decapsulate with a byte[] key?
>>> 
>>> Otherwise, I would suggest that you widen the signature of `NamedKEM#implDecapsulate` to receive both parameters, the seed and the expanded key.
>>> 
>>> Cheers,
>>> Sebastian
>>> 
>>>> On 23. Jul 2025, at 17:52, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Jul 23, 2025, at 11:41, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>> 
>>>>> Welcome back, I hope you enjoyed the time! :-)
>>>>> 
>>>>> If you find time, can you give me an update on the ASN.1 key encoding topic? This is the only remaining issue to fulfill the spec. Afterwards we simply need to wait for the final test vectors and publication of the RFC.
>>>> 
>>>> https://github.com/openjdk/jdk/pull/24969 updated NamedPKCS8Key which contains both the encoding format (as in PKCS #8) and the expanded format (used in calculation). For X-Wing, I think the encoding will be the seed, but you are free to choose the expanded format, or, you can "expand" it to an arbitrary object at NamdKEM::implCheckPrivateKey. The KeyPairGenerator interface does not have a deterministic generateKey method so you will have to call internal methods for both ML-KEM and x25519.
>>>> 
>>>> Thanks,
>>>> Weijun
>>>> 
>>>>> 
>>>>> Thank you!
>>>>> Sebastian
>>>>> 
>>>>>> Am 23.07.2025 um 14:33 schrieb Wei-Jun Wang <weijun.wang at oracle.com>:
>>>>>> 
>>>>>> ?Hi Sebastian,
>>>>>> 
>>>>>> I'm back from my vacation. Thanks for the update.
>>>>>> 
>>>>>> I agree, using NamedKey is probably a better choice anyway. It's nice that getParams() always return a name and we don't need to call getAlgorithm() as a fallback.
>>>>>> 
>>>>>> Thanks,
>>>>>> Weijun
>>>>>> 
>>>>>>> On Jun 30, 2025, at 06:06, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>> 
>>>>>>> Quoting Bas Westerbaan (in CC) again, we will most likely see further PQ/T hybrids from the IETF crypto forum research group (CFRG for short):
>>>>>>> 
>>>>>>>> It seems likely that the CFRG will at some point produce a P-384+ML-KEM-1024 hybrid. See https://mailarchive.ietf.org/arch/msg/cfrg/CwrVvm-J7o85TEWkG9RJxZwfXDY/ . That might take some time.
>>>>>>>> 
>>>>>>>> Very few (but notably Ericsson) have asked for X448 hybrids, so I don't expect them soon.
>>>>>>> 
>>>>>>> That said, the construction does not necessarily be compatible to X-Wing. Just to be sure, I asked whether they see any value in parameterizing X-Wing to swap out algorithms. This is what Bas replied:
>>>>>>> 
>>>>>>>> Even if the other hybrids will also use an X-Wing style combiner, it doesn't hurt not to parametrize initially. :)
>>>>>>> 
>>>>>>> So I would suggest to follow this advice for now and only refactor the implementation eventually, when further pairs of algorithms are combined in the same way.
>>>>>>> 
>>>>>>> Best,
>>>>>>> Sebastian
>>>>>>> 
>>>>>>> 
>>>>>>>>> On 29. Jun 2025, at 12:02, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 28. Jun 2025, at 00:12, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> [...] After all, there is no parameter for X-Wing. Did you hear the authors they want to introduce other algorithms like ed448 and ML-KEM-1024 into it?
>>>>>>>> 
>>>>>>>> I forwarded this question and let you know the answer!
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Cool.
>>>>>>>>>>> 
>>>>>>>>>>> The current NamedPKCS8Key was designed based on an older approach where modern asymmetric keys store private key data in a nested OCTET STRING format. This pattern was introduced with EdDSA and XDH, and at the time of JDK 24, we anticipated it would become the norm.
>>>>>>>>>>> 
>>>>>>>>>>> However, things have changed significantly, as seen in the evolution of draft-ietf-lamps-dilithium-certificates and draft-ietf-lamps-kyber-certificates. The original design now needs to be revised. While we?re still waiting for the IETF drafts to be finalized, we?re already experimenting with changes in https://github.com/openjdk/jdk/pull/24969.
>>>>>>>>>>> 
>>>>>>>>>>> Hopefully, by the time X-Wing is finalized, we?ll already have a solution in place.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Weijun
>>>>>>>>>>> 
>>>>>>>>>>>> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Weijun,
>>>>>>>>>>>> 
>>>>>>>>>>>> I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:
>>>>>>>>>>>> 
>>>>>>>>>>>> The (current) X-Wing spec wants this PKCS#8 encoding: [1]
>>>>>>>>>>>> 
>>>>>>>>>>>> However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2]
>>>>>>>>>>>> 
>>>>>>>>>>>> Note the difference here:
>>>>>>>>>>>> * https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f
>>>>>>>>>>>> * https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo
>>>>>>>>>>>> 
>>>>>>>>>>>> I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this?
>>>>>>>>>>>> 
>>>>>>>>>>>> Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don?t seem to be complete yet.
>>>>>>>>>>>> 
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Sebastian
>>>>>>>>>>>> 
>>>>>>>>>>>> [0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing
>>>>>>>>>>>> [1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D
>>>>>>>>>>>> [2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi Weijun,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> waiting for the final standard is understandable. The internals may still change, but the ?outer hull? of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won?t be merged yet?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Feel free to start a draft if you?d like. I'll create a JBS issue once we decide we want to include it in the JDK.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I see.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Nice to know. Sorry I didn't noticed that earlier.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Weijun
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi Sebastian.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> As the X-Wing spec doesn?t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks for your continued interest on enhancing OpenJDK.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers? Guide [1] and try working on something smaller first.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM?s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Alternatively, can we make the two mentioned APIs public?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [1] https://openjdk.org/guide/
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Weijun
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>>>>>>>>>>>>>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>>>>>>>>>>>>>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 
> 


From kdriver at openjdk.org  Mon Aug  4 16:03:02 2025
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 4 Aug 2025 16:03:02 GMT
Subject: Integrated: 8364226: Better ECDSASignature Memory Management
In-Reply-To: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
References: <2_WiZ0b2p82VnRhqrjHSSUxRPAaNqZNLKQIl9GDpeqE=.ff58b71f-2404-4ef5-84e5-ad83eb16c4cf@github.com>
Message-ID: <JiHzmClJcFbtAbMNAL24rFwVjIvAVDl8axX835iSfk4=.95fe3094-a385-44c6-8690-33f7f21f6f65@github.com>

On Mon, 28 Jul 2025 19:59:49 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Enhance the memory management/cleanup for `ECDSASignature`.

This pull request has now been integrated.

Changeset: b5f450a5
Author:    Kevin Driver <kdriver at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5f450a599a0f63df0307cced09295fe1309bf6f
Stats:     10 lines in 1 file changed: 8 ins; 0 del; 2 mod

8364226: Better ECDSASignature Memory Management

Reviewed-by: ascarpino, hchao

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

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

From weijun at openjdk.org  Mon Aug  4 16:51:58 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Aug 2025 16:51:58 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v5]
In-Reply-To: <KGc-zsTg-LH46D-1NdEEMTMNTp6yi8MOU5Ev_d4inBM=.a6907280-18b2-4607-94e2-9c46b808878e@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <ZJ_dhGAnbwkBndQhKCXGgj0kRet3emnjRiaC1W-hmrM=.9efe4a90-07d6-4990-8489-a1e5f6e318a5@github.com>
 <KGc-zsTg-LH46D-1NdEEMTMNTp6yi8MOU5Ev_d4inBM=.a6907280-18b2-4607-94e2-9c46b808878e@github.com>
Message-ID: <CmZ6hoYeHbKiYm93nxvkYHB_rz8Q6zOoapz0xR3xnFs=.c6f4dd02-4ac2-41d3-823d-d6cce04e5c48@github.com>

On Mon, 4 Aug 2025 11:12:11 GMT, Sebastian Stenzel <duke at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   combine security properties description; remove one test
>
> src/java.base/share/classes/com/sun/crypto/provider/ML_KEM_Impls.java line 132:
> 
>> 130:             if (nk instanceof NamedPKCS8Key npk) {
>> 131:                 var type = KeyChoices.getPreferred("mlkem");
>> 132:                 if (KeyChoices.typeOfChoice(npk.getRawBytes()) != type) {
> 
>> ```
>> /// 1. If only `privKeyMaterial` is present, it's also the expanded format.
>> /// 2. If both `privKeyMaterial` and `expanded` are available, `privKeyMaterial`
>> ///    is the encoding format, and `expanded` is the expanded format.
>> ```
> 
> This in mind, the result of `getRawBytes()` differs. In the first case, it is in fact raw bytes, as the method name suggests. (See also usage of `privKeyMaterial` in `PKCS8Key.generateEncoding()`).
> 
> Therefore, the ASN.1 envelope may be missing, causing 
> 
> 
> java.security.InvalidKeyException: Wrong tag: -39
> 	at java.base/sun.security.util.KeyChoices.typeOfChoice(KeyChoices.java:144)
> 	at java.base/com.sun.crypto.provider.ML_KEM_Impls$KF.engineTranslateKey(ML_KEM_Impls.java:132)
> 	at java.base/java.security.KeyFactory.translateKey(KeyFactory.java:475)
> 
> 
> Isn't `getEncoded()` the safer bet?
> 
> Suggestion:
> 
>                 if (KeyChoices.typeOfChoice(npk.getEncoded()) != type) {

`getEncoded` is the whole PKCS #8 encoding.
`getRawBytes` returns the content of the `privateKey` field inside the PKCS #8 encoding.
`getExpanded` is not related to encoding. It's what the underlying `NamedKEM` or `NamedSignature` will use.

For ML-KEM, `getRawBytes` might be any of the 3 CHOICEs: seed, expandedKey, or both. `getExpanded` is always the expanded format (defined in FIPS 203). There is a slight difference even if `getRawBytes` is using the expandedKey choice: it has the OCTET STRING header but `getExpanded` does not.

`engineTranslateKey` can re-encode the key depending on the "jdk.mlkem.pkcs8.encoding" security property. Therefore it works on the `getRawBytes` level.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2252029114

From pminborg at openjdk.org  Mon Aug  4 17:27:05 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 4 Aug 2025 17:27:05 GMT
Subject: RFR: 8364540: Apply @Stable to Shared Secrets
Message-ID: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>

This PR proposes to update the `SharedSecrets` class in `jdk.internal.access` to annotate all but one static field with the `@Stable` annotation.

The `@Stable` annotation was added to all static fields except for `javaAWTFontAccess`, which remains unannotated. This is because it can be set using several code paths.

No tests were changed or added, as this is an internal annotation adjustment with no expected behavioral impact.

This PR passes `tier1`, `tier2`, and `tier3` testing on multiple platforms.

In a future follow-up issue, we could identify fields in the implementations of the access classes that, in turn, are stable themselves. When this PR is integrated, it might be possible to remove local copies of access in classes to reduce bytecode size with little or no performance impact. Currently, we do not check the invariant, a field is set only once. This is yet another improvement proposal we could do -- maybe using Stable Values.

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

Commit messages:
 - Make all fields except one @Stable in SharedSecrets

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

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

From rhalade at openjdk.org  Mon Aug  4 17:35:02 2025
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 4 Aug 2025 17:35:02 GMT
Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java
In-Reply-To: <QNJ0JfM5Ofh-3HQve5AWl3euzPKNyqgH8xYXjDKwL_k=.f7a88184-a7e7-47e8-b5d7-0967ec5f6ca7@github.com>
References: <QNJ0JfM5Ofh-3HQve5AWl3euzPKNyqgH8xYXjDKwL_k=.f7a88184-a7e7-47e8-b5d7-0967ec5f6ca7@github.com>
Message-ID: <xWXZrQ7yFfdaPuGwSoUROy7kFerRUVcDoD5Zt_jDYBA=.c7c01f30-8424-4b4b-88ba-2a8b456fab8d@github.com>

On Tue, 15 Jul 2025 16:43:16 GMT, Thomas Fitzsimmons <duke at openjdk.org> wrote:

> This patch adds configurability to `PKCS11Test.java`.
> 
> Specifically, it adds two new system properties:
> 
> - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the `nss_library` field.  Prior to this patch, `nss_library` was set to either `"softokn3"` or `"nss3"`.
> 
> - `CUSTOM_P11_CONFIG_VARIANT`: Abstract the configuration file type to load.  Prior to this patch, test cases that wanted to run `NSS` in sensitive mode would hard-code `p11-nss-sensitive.txt` on their command lines.
> 
> The patch updates the three `p11-nss-sensitive.txt`-using test cases to use the new `CUSTOM_P11_CONFIG_VARIANT` property:
> 
> 
> test/jdk/java/security/KeyAgreement/Generic.java
> test/jdk/sun/security/pkcs11/Mac/TestLargeSecretKeys.java
> test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java
> 
> 
> I have been using this change to run `PKCS11Test.java` against the [Kryoptic](https://github.com/latchset/kryoptic) PKCS11 soft token, using this invocation:
> 
> 
> make test \
>     JTREG="JAVA_OPTIONS=-DCUSTOM_P11_CONFIG=/tmp/kryoptic-configuration/p11-kryoptic.txt \
>                         -DCUSTOM_P11_LIBRARY_NAME=kryoptic_pkcs11 \
>                         -Djdk.test.lib.artifacts.nsslib-linux_x64=/tmp/kryoptic-configuration \
>                         -DCUSTOM_DB_DIR=/tmp/kryoptic-configuration"
> 
> 
> `/tmp/kryoptic-configuration` contains (among other files):
> 
> 
> libkryoptic_pkcs11.so
> p11-kryoptic.txt
> p11-kryoptic-sensitive.txt
> 
> 
> With `CUSTOM_P11_LIBRARY_NAME` set, `PKCS11Test.java` can find `libkryoptic_pkcs11.so`.
> 
> And setting `CUSTOM_P11_CONFIG` causes the sensitive tests to use `p11-kryoptic-sensitive.txt` via the new `CUSTOM_P11_CONFIG_VARIANT` property.
> 
> On my `Fedora 42` `x86-64` machine, I tested for regressions with:
> 
> $ time make test JOBS=4 JTREG="JAVA_OPTIONS=-Djdk.test.lib.artifacts.nsslib-linux_x64=/usr/lib64" TEST="test/jdk/sun/security/pkcs11"
> 
> and:
> 
> $ time make test JOBS=4 TEST="test/jdk/sun/security/pkcs11"

Will you also include p11-kryoptic.txt and p11-kryoptic-sensitive.txt configuration files for Kryoptic library so others can also run this interoperability? And do the current P11-NSS tests continue to work as expected?

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

PR Comment: https://git.openjdk.org/jdk/pull/26325#issuecomment-3151764343

From duke at openjdk.org  Mon Aug  4 20:02:05 2025
From: duke at openjdk.org (Sebastian Stenzel)
Date: Mon, 4 Aug 2025 20:02:05 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v5]
In-Reply-To: <CmZ6hoYeHbKiYm93nxvkYHB_rz8Q6zOoapz0xR3xnFs=.c6f4dd02-4ac2-41d3-823d-d6cce04e5c48@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <ZJ_dhGAnbwkBndQhKCXGgj0kRet3emnjRiaC1W-hmrM=.9efe4a90-07d6-4990-8489-a1e5f6e318a5@github.com>
 <KGc-zsTg-LH46D-1NdEEMTMNTp6yi8MOU5Ev_d4inBM=.a6907280-18b2-4607-94e2-9c46b808878e@github.com>
 <CmZ6hoYeHbKiYm93nxvkYHB_rz8Q6zOoapz0xR3xnFs=.c6f4dd02-4ac2-41d3-823d-d6cce04e5c48@github.com>
Message-ID: <b0ZbIwaRrL9LQ89ijeIA6ZOqLazH42_KG1LQ8jZmEIU=.cdce65ed-c561-4354-91e0-5a3a029d2b6e@github.com>

On Mon, 4 Aug 2025 16:46:51 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/ML_KEM_Impls.java line 132:
>> 
>>> 130:             if (nk instanceof NamedPKCS8Key npk) {
>>> 131:                 var type = KeyChoices.getPreferred("mlkem");
>>> 132:                 if (KeyChoices.typeOfChoice(npk.getRawBytes()) != type) {
>> 
>>> ```
>>> /// 1. If only `privKeyMaterial` is present, it's also the expanded format.
>>> /// 2. If both `privKeyMaterial` and `expanded` are available, `privKeyMaterial`
>>> ///    is the encoding format, and `expanded` is the expanded format.
>>> ```
>> 
>> This in mind, the result of `getRawBytes()` differs. In the first case, it is in fact raw bytes, as the method name suggests. (See also usage of `privKeyMaterial` in `PKCS8Key.generateEncoding()`).
>> 
>> Therefore, the ASN.1 envelope may be missing, causing 
>> 
>> 
>> java.security.InvalidKeyException: Wrong tag: -39
>> 	at java.base/sun.security.util.KeyChoices.typeOfChoice(KeyChoices.java:144)
>> 	at java.base/com.sun.crypto.provider.ML_KEM_Impls$KF.engineTranslateKey(ML_KEM_Impls.java:132)
>> 	at java.base/java.security.KeyFactory.translateKey(KeyFactory.java:475)
>> 
>> 
>> Isn't `getEncoded()` the safer bet?
>> 
>> Suggestion:
>> 
>>                 if (KeyChoices.typeOfChoice(npk.getEncoded()) != type) {
>
> `getEncoded` is the whole PKCS #8 encoding.
> `getRawBytes` returns the content of the `privateKey` field inside the PKCS #8 encoding.
> `getExpanded` is not related to encoding. It's what the underlying `NamedKEM` or `NamedSignature` will use.
> 
> For ML-KEM, `getRawBytes` might be any of the 3 CHOICEs: seed, expandedKey, or both. `getExpanded` is always the expanded format (defined in FIPS 203). There is a slight difference even if `getRawBytes` is using the expandedKey choice: it has the OCTET STRING header but `getExpanded` does not.
> 
> `engineTranslateKey` can re-encode the key depending on the "jdk.mlkem.pkcs8.encoding" security property. Therefore it works on the `getRawBytes` level.

In X-Wing, the expanded decapsulation key is referred to as `sk_m`. I.e. *without* the CHOICE structure. So in order to have `NamedPKCS8Key.privKeyMaterial` contain the choice, I would have to do this:


byte[] keyBytesWrappedInChoice = KeyChoices.writeToChoice(KeyChoices.Type.EXPANDED_KEY, null, sk_m);
PrivateKey key = NamedPKCS8Key.internalCreate("ML-KEM", "ML-KEM-768", keyBytesWrappedInChoice, null);


However, if I now call `keyFactory.translateKey(key)`, it'll throw:


java.security.InvalidKeyException: key contains not enough info to translate
	at java.base/sun.security.util.KeyChoices.choiceToChoice(KeyChoices.java:220)
	at java.base/com.sun.crypto.provider.ML_KEM_Impls$KF.engineTranslateKey(ML_KEM_Impls.java:133)
	at java.base/java.security.KeyFactory.translateKey(KeyFactory.java:475)


in base64 `sk_m` has this value (test case 1 from [X-Wing test vectors](https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-08#appendix-C)):


IDjHPToyMBF3joBR7joyxgHNZdrAqPmpQIEj8GRIi+thihFD1Fqc+BbMlZuDnLsPH5y7DJWqXHsqhQNeiMRkT1VZjVF7psO12woyNCIYSHFQe8O/BspLfeOW/MFH4tONheMqoIKMUHvC28nEk4Q57YciB7y//iNoevxrdhG4/XrCetNairsm2RB0AQtsc1WhUUyluoExawtc3bmm2BmiGocA2PmbB4hBPVw8fXyhm4ACCJqKjKJ7BZBelLxh49fPLbaXxZYrC0s5O7Cbv/oujGxuk8K8NOpIFxZVSdota6ikQDe4ELd8Dhk0ppU3FjE0JhsjQshoNGtB2AkDgcDADDMb44giv+KWv8o1khgg52Q76KgrzlnMZdUn+ujHA1lK2FcYT+R52uyrJJec8WKCVtSPJdp+ajBrOaCoUlQMrRgMUMC0xnegLoubeWQBxdwUpSgloIjDG0RxVQRPCwgYczWfClLEaOaK/TlOiUisecKTeECk38gfr1IUvdocAtTO62klYLa4Z9fKO/uvXxwzHjap6uaWsJJeZ/GUMrCX+Helmdiu3DArkTgQl9kNIYgkapcOw1gKqxVDCtdHcntCp/fDy3sSDKaM1mZHdtmdZfMIbKW8sZiPHbyZqsJtZwEL0wjAzpeVnouGSCEvPSYuTfW3ThDLsKs+oFxI32S4EvgQNUd2vFd2kuUhmct6YDTLA9hh+Vs7jlEUYjtx1fAUIiO6F9tR1KWRskqkY8qWrWpJYBg61ySdKUq/kHEvhcieVqMGcId8DFpIUDhsCoIjmAQrabZyvTWb9ndKaboaa5kOFNGrEoA1iHovnOZgxhSQf/IXWncIZOJ0B+MSIYJ/OBgU2OrGvmq/28pxtHK1iSnBN5c2JXK/qhZdhkqdzHFhDbOyM7QOOyVnJuMXO3x+fXXPlCgrpVYivOZ5lhfJEuUQMPgm0abCeHScyGRSw2KXkXpg7icb/gWsTSedtEpGcTMie4BqeZaUZRYlxQ
 oGeRCeQPZvXIS7ajlPmBxge1S5DDCCw4Q9gUgCAXo6DNQ10ABGXTmba6kkUwFz+xREY1sapcykudONJ7eo8NUkerE0I/pGUErLZrBulhERusBpPuB9FIKXNdY6hEei9OxgfwKWfGMeUrtoUDOrv9hvViBycHXNP0UroNeTU2au3ycSwtkquVNHYtG94DOi8/Bu59ueXwEx4TZNrXNyW9NwknYF7TgZQBm55PVHurYtq1Cy4Wq2r5TLbFUe5DearAdyKZy746WLCOm29wyp7HRvIsSpTqlyYAla5PymyQov0lqbJexd9bAnXUhOByJqHXM0oou+JIpcVrJSQMuE39soR6iFHhB9icVUxjOKjlWr1zeu30EEzAhVD3JKk9gNrImWY+UJkXuWvfFcowE/EmIDDckeqHqrx8iVDsF0g0pLNYgTI6okoHMLccBHolui9abEBPcswpSRDuDOkDUbuESkSAqiXGRS9NClUTkKLToMyByJshhOHEhONaNrxlAxd4psk+aNscF84sAfABBjd/R84gUj4iNrNajCSzmxCqEyOpapGaLO2IQAYzp7BxMXE/wUsrWxnPw9pfoaksSfJVE+D9MNaxYRyauWNdcIZyekt9IdNCROZpac8Vs7KnhTKfYbCWsnfqA3ODR5prVW3nIx/kt/qcmsJMBpmgAYpSU0AbrPqQXKgWVz5WotLgZ+m3KHUzuhOpN97bMfpEus7UB2mSNhADSuMeYZoXAkUZmzxcOYZIWf4bTJcXoHwwSVvfuYoKACzPVsEobO9QQd7ePETPFr9WLHRIUYAms9i5lAaAq9OKFXX9J7WNoGO/rDLDnDCGk3TAXBrrGJi2swPMaL5FU0buCvaZY2IkoUjKKuoQRjERxwn2m2nHDOhTh0ZpjExgqa7wAwx5JM7sQqXTaBb1RerhMpNGCzrLN+oOE9cOSqeGhto5ioOXwI6vloghE/5Pe61NpAsFAeHHU+/nMFPIcBToZhwzCZr+i
 +3kFKWxqifYOSs+Ex6acMEFWHgkDK0PQNX+PN+FI26tl+KpdEg2OygIyq/VFs0lBSxcNiVDwlF+Ss0OYOwHFjAJtkJfwyJ3rO5xwkurU+2fKedMZqCjVklVmY12uWqai1DRY1pNemfrQt9WRNMwRXKTqAQvU8x6aSiPF+1Vgn6Cso6CZlqGoU+9lmReyoFywET4O8DYwLTIYmmFYxyoevgpBo8TWJY8szNmTKSCdjujs7sghXf5umrGLCX3ZZJ0O2S+UZMXcUy0ECy3svmiWytPBhXeMd7NnKVQJtbaC2URGxb+Uv7tikh+FERiptupNyj1ALb/xJ5RVWnvJf7Rev9SBQc2glNSWGD1i+O+YclkYEpqyBTmk1WWQCpSCkZws9KEMYhmWT0VpLsBw14+WH7gxn0ogNbyQH+3pwcSuDjeuWxde/K0S89gOMy+M/vPUaVKWE/pAIPJHHptQ9T7FfSMYML9ZuCoqtStZOXEK7iHfA6+wrXjh8ipiP3CO+ueFsh1d4HgoUmcYeE4wh8hbCnQdpeYccqmlCuvwJBUS+6ZtUsWy5qaNk1iRtn0LM5TxmtZxFyPmukpmnXRUYDDyVIVGpG3oQdyQp3Ey65vzGIvqAGMY0OfiQYwuZKNtrt/lDiuQGXtNNc9SG8/UvkPCAfciN/djHKOlU8aw1wGwADOQaBYJYDju1e2cpcokKxeeYjnhQZXEW8bV9CAmq7ewL7eGuFIFIMRxvfjFzRuUYn7jNY1uYb4wL3SdkHFhLd4s6kRqAvhyWkquOG7sSg5VzzOGd8YO0WDW7tVBS+fxmoWeO8qNt6nhBHmyNYFAbTmBZLRNpipQ7UJGF25EuLqEL4GFxI2syfHFxYJTJZKaLAzd/UToFvNmcHzRlg7sFKXehChKt/HWANOVhfaTBJ2WF5XdOHzuZeLCdDpxE07yGFRxDqtGFcScXNAIjrDgdIRUKBClOl7sTu9ohtaGCttqWnhmn/QcnN/qOiApT
 wkKOPQSbfSGXQFKW3bNhkSp7z0gnztYR0Men2hBN3kMiCVM59kph1bsQj/C/TXgMrlCfsiwlaRQZP/c0kEJYEjfVIoKIJO4739B/sD8flC0uoXn+ci8GzAPeW2nL1+07ipDytAYD2J8QzfWFiXGJ+R/FH7jN0lxsff7gw/D8b6TkgnUxFoCH7yI+mwcMWninif1G1MYE1psROdTa

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2252458776

From weijun at openjdk.org  Mon Aug  4 21:07:09 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Aug 2025 21:07:09 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v5]
In-Reply-To: <b0ZbIwaRrL9LQ89ijeIA6ZOqLazH42_KG1LQ8jZmEIU=.cdce65ed-c561-4354-91e0-5a3a029d2b6e@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <ZJ_dhGAnbwkBndQhKCXGgj0kRet3emnjRiaC1W-hmrM=.9efe4a90-07d6-4990-8489-a1e5f6e318a5@github.com>
 <KGc-zsTg-LH46D-1NdEEMTMNTp6yi8MOU5Ev_d4inBM=.a6907280-18b2-4607-94e2-9c46b808878e@github.com>
 <CmZ6hoYeHbKiYm93nxvkYHB_rz8Q6zOoapz0xR3xnFs=.c6f4dd02-4ac2-41d3-823d-d6cce04e5c48@github.com>
 <b0ZbIwaRrL9LQ89ijeIA6ZOqLazH42_KG1LQ8jZmEIU=.cdce65ed-c561-4354-91e0-5a3a029d2b6e@github.com>
Message-ID: <5tL2oa7PIuuivR3_CVX_c8Zg168Pqqr29lfLpNBkFgQ=.9788c1c1-987a-4557-9b32-38e0b16c45b1@github.com>

On Mon, 4 Aug 2025 19:59:50 GMT, Sebastian Stenzel <duke at openjdk.org> wrote:

>> `getEncoded` is the whole PKCS #8 encoding.
>> `getRawBytes` returns the content of the `privateKey` field inside the PKCS #8 encoding.
>> `getExpanded` is not related to encoding. It's what the underlying `NamedKEM` or `NamedSignature` will use.
>> 
>> For ML-KEM, `getRawBytes` might be any of the 3 CHOICEs: seed, expandedKey, or both. `getExpanded` is always the expanded format (defined in FIPS 203). There is a slight difference even if `getRawBytes` is using the expandedKey choice: it has the OCTET STRING header but `getExpanded` does not.
>> 
>> `engineTranslateKey` can re-encode the key depending on the "jdk.mlkem.pkcs8.encoding" security property. Therefore it works on the `getRawBytes` level.
>
> In X-Wing, the expanded decapsulation key is referred to as `sk_m`. I.e. *without* the CHOICE structure. So in order to have `NamedPKCS8Key.privKeyMaterial` contain the choice, I would have to do this:
> 
> 
> byte[] keyBytesWrappedInChoice = KeyChoices.writeToChoice(KeyChoices.Type.EXPANDED_KEY, null, sk_m);
> PrivateKey key = NamedPKCS8Key.internalCreate("ML-KEM", "ML-KEM-768", keyBytesWrappedInChoice, null);
> 
> 
> However, if I now call `keyFactory.translateKey(key)`, it'll throw:
> 
> 
> java.security.InvalidKeyException: key contains not enough info to translate
> 	at java.base/sun.security.util.KeyChoices.choiceToChoice(KeyChoices.java:220)
> 	at java.base/com.sun.crypto.provider.ML_KEM_Impls$KF.engineTranslateKey(ML_KEM_Impls.java:133)
> 	at java.base/java.security.KeyFactory.translateKey(KeyFactory.java:475)
> 
> 
> in base64 `sk_m` has this value (test case 1 from [X-Wing test vectors](https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-08#appendix-C)):
> 
> 
> IDjHPToyMBF3joBR7joyxgHNZdrAqPmpQIEj8GRIi+thihFD1Fqc+BbMlZuDnLsPH5y7DJWqXHsqhQNeiMRkT1VZjVF7psO12woyNCIYSHFQe8O/BspLfeOW/MFH4tONheMqoIKMUHvC28nEk4Q57YciB7y//iNoevxrdhG4/XrCetNairsm2RB0AQtsc1WhUUyluoExawtc3bmm2BmiGocA2PmbB4hBPVw8fXyhm4ACCJqKjKJ7BZBelLxh49fPLbaXxZYrC0s5O7Cbv/oujGxuk8K8NOpIFxZVSdota6ikQDe4ELd8Dhk0ppU3FjE0JhsjQshoNGtB2AkDgcDADDMb44giv+KWv8o1khgg52Q76KgrzlnMZdUn+ujHA1lK2FcYT+R52uyrJJec8WKCVtSPJdp+ajBrOaCoUlQMrRgMUMC0xnegLoubeWQBxdwUpSgloIjDG0RxVQRPCwgYczWfClLEaOaK/TlOiUisecKTeECk38gfr1IUvdocAtTO62klYLa4Z9fKO/uvXxwzHjap6uaWsJJeZ/GUMrCX+Helmdiu3DArkTgQl9kNIYgkapcOw1gKqxVDCtdHcntCp/fDy3sSDKaM1mZHdtmdZfMIbKW8sZiPHbyZqsJtZwEL0wjAzpeVnouGSCEvPSYuTfW3ThDLsKs+oFxI32S4EvgQNUd2vFd2kuUhmct6YDTLA9hh+Vs7jlEUYjtx1fAUIiO6F9tR1KWRskqkY8qWrWpJYBg61ySdKUq/kHEvhcieVqMGcId8DFpIUDhsCoIjmAQrabZyvTWb9ndKaboaa5kOFNGrEoA1iHovnOZgxhSQf/IXWncIZOJ0B+MSIYJ/OBgU2OrGvmq/28pxtHK1iSnBN5c2JXK/qhZdhkqdzHFhDbOyM7QOOyVnJuMXO3x+fXXPlCgrpVYivOZ5lhfJEuUQMPgm0abCeHScyGRSw2KXkXpg7icb/gWsTSedtEpGcTMie4BqeZaUZRYl
 xQoGeRCeQPZvXIS7ajlPmBxge1S5DDCCw4Q9gUgCAXo6DNQ10ABGXTmba6kkUwFz+xREY1sapcykudONJ7eo8NUkerE0I/pGUErLZrBulhERusBpPuB9FIKXNdY6hEei9OxgfwKWfGMeUrtoUDOrv9hvViBycHXNP0UroNeTU2au3ycSwtkquVNHYtG94DOi8/Bu59ueXwEx4TZNrXNyW9NwknYF7TgZQBm55PVHurYtq1Cy4Wq2r5TLbFUe5DearAdyKZy746WLCOm29wyp7HRvIsSpTqlyYAla5PymyQov0lqbJexd9bAnXUhOByJqHXM0oou+JIpcVrJSQMuE39soR6iFHhB9icVUxjOKjlWr1zeu30EEzAhVD3JKk9gNrImWY+UJkXuWvfFcowE/EmIDDckeqHqrx8iVDsF0g0pLNYgTI6okoHMLccBHolui9abEBPcswpSRDuDOkDUbuESkSAqiXGRS9NClUTkKLToMyByJshhOHEhONaNrxlAxd4psk+aNscF84sAfABBjd/R84gU...

If you manually create an expanded-only key and then try to call`translateKey` on it but the security property is using the default value "seed", then of course the translation will not work.

Anyway, I don't think X-Wing implementation needs to touch that property. The X-Wing private key is always the 32-byte seed, and its "expanded" form can include the whole `expandDecapsulationKey` output, and then you can simply call internal `ML-KEM` methods on it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2252579592

From bperez at openjdk.org  Mon Aug  4 21:50:09 2025
From: bperez at openjdk.org (Ben Perez)
Date: Mon, 4 Aug 2025 21:50:09 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v5]
In-Reply-To: <ZJ_dhGAnbwkBndQhKCXGgj0kRet3emnjRiaC1W-hmrM=.9efe4a90-07d6-4990-8489-a1e5f6e318a5@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <ZJ_dhGAnbwkBndQhKCXGgj0kRet3emnjRiaC1W-hmrM=.9efe4a90-07d6-4990-8489-a1e5f6e318a5@github.com>
Message-ID: <nyciV-BAM8UDyljf-bCyItufy6z2mO-G2mX8W9GWTqk=.3b3c7fc7-32f2-4816-8434-25a07fa73252@github.com>

On Wed, 30 Jul 2025 15:45:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> 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.
>> 
>> By default, the choice is "seed".
>> 
>> 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 incrementally with one additional commit since the last revision:
> 
>   combine security properties description; remove one test

src/java.base/share/classes/sun/security/provider/ML_DSA.java line 593:

> 591:         var s1 = deepClone(sk.s1);
> 592:         mlDsaVectorNtt(s1); //s1 now in NTT domain
> 593:         int[][] As1 = new int[mlDsa_k][ML_DSA_N];

Multiarray allocations like this are quite slow - for better performance consider using the `integerMatrixAlloc` method. This also applies to the allocations on L598 and L599

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2252637672

From weijun at openjdk.org  Mon Aug  4 22:38:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Aug 2025 22:38:06 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v5]
In-Reply-To: <nyciV-BAM8UDyljf-bCyItufy6z2mO-G2mX8W9GWTqk=.3b3c7fc7-32f2-4816-8434-25a07fa73252@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
 <ZJ_dhGAnbwkBndQhKCXGgj0kRet3emnjRiaC1W-hmrM=.9efe4a90-07d6-4990-8489-a1e5f6e318a5@github.com>
 <nyciV-BAM8UDyljf-bCyItufy6z2mO-G2mX8W9GWTqk=.3b3c7fc7-32f2-4816-8434-25a07fa73252@github.com>
Message-ID: <Z1qMhiF78yT-uLy6Z56iMoi8D97pc1n4gl69mxsyuKo=.d4dac6ff-496f-4911-8532-5c343170b356@github.com>

On Mon, 4 Aug 2025 21:44:30 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   combine security properties description; remove one test
>
> src/java.base/share/classes/sun/security/provider/ML_DSA.java line 593:
> 
>> 591:         var s1 = deepClone(sk.s1);
>> 592:         mlDsaVectorNtt(s1); //s1 now in NTT domain
>> 593:         int[][] As1 = new int[mlDsa_k][ML_DSA_N];
> 
> Multiarray allocations like this are quite slow - for better performance consider using the `integerMatrixAlloc` method. This also applies to the allocations on L598 and L599

Ah yes, I remember this. Will fix it. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2252709647

From pminborg at openjdk.org  Tue Aug  5 08:03:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Aug 2025 08:03:12 GMT
Subject: RFR: 8355379: Annotate lazy fields in java.security @Stable [v4]
In-Reply-To: <e4e1FN_Bt_l8dWiudCe37G0hPgmpD08vm1T6wfSsyb4=.1ddd55d9-8506-45d6-9570-7fc55c4fdd4d@github.com>
References: <BdTzABSl5jaGkV-xByy2FlnE8-JPfLejMQBjRZNLBjY=.b6265489-d61e-4572-a523-93e77be49e0c@github.com>
 <e4e1FN_Bt_l8dWiudCe37G0hPgmpD08vm1T6wfSsyb4=.1ddd55d9-8506-45d6-9570-7fc55c4fdd4d@github.com>
Message-ID: <Q6YqQw8V6nx-ukVBvGm_Qfn9-3HWo6cku0mL6gMCNCQ=.d1953f35-90d7-4006-a44c-9b956b926281@github.com>

On Tue, 29 Jul 2025 23:07:45 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 and URICertStoreParameters.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8355379: Annotate lazy fields in java.security @Stable
>  - 8355379: Annotate lazy fields in java.security @Stable
>  - 8355379: Annotate lazy fields in java.security @Stable

src/java.base/share/classes/java/security/PKCS12Attribute.java line 50:

> 48:     private String value;
> 49:     private final byte[] encoded;
> 50: 

The fields `name`, `value`, and `encoded` can also be marked `@Stable` with appropriate changes (e.g., making the fields `final` and setting them to `null` in the constructor that only takes an array). I think we should do this under a separate issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25405#discussion_r2253482575

From pminborg at openjdk.org  Tue Aug  5 08:10:04 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Aug 2025 08:10:04 GMT
Subject: RFR: 8355379: Annotate lazy fields in java.security @Stable [v4]
In-Reply-To: <e4e1FN_Bt_l8dWiudCe37G0hPgmpD08vm1T6wfSsyb4=.1ddd55d9-8506-45d6-9570-7fc55c4fdd4d@github.com>
References: <BdTzABSl5jaGkV-xByy2FlnE8-JPfLejMQBjRZNLBjY=.b6265489-d61e-4572-a523-93e77be49e0c@github.com>
 <e4e1FN_Bt_l8dWiudCe37G0hPgmpD08vm1T6wfSsyb4=.1ddd55d9-8506-45d6-9570-7fc55c4fdd4d@github.com>
Message-ID: <e9ZKvG1RSxeWf89SwmKhW0zK8_oEy0x1beP4sLkrGGk=.f73fd4cb-18c0-4cd3-a453-7c42240fea94@github.com>

On Tue, 29 Jul 2025 23:07:45 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 and URICertStoreParameters.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8355379: Annotate lazy fields in java.security @Stable
>  - 8355379: Annotate lazy fields in java.security @Stable
>  - 8355379: Annotate lazy fields in java.security @Stable

The latest changes look good to me.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25405#pullrequestreview-3087082930

From dholmes at openjdk.org  Tue Aug  5 08:35:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 5 Aug 2025 08:35:11 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

VM side seems reasonable. Java side looks a bit clunky but that is up to core-libs folk to evaluate.

General note: if comments start with a capital they should end with a period, and vice-versa. Extended comments should consist of full sentences. 

Thanks.

src/hotspot/share/classfile/javaClasses.cpp line 3078:

> 3076:   do {
> 3077:     // No backtrace available.
> 3078:     if (!iter.repeat()) return false;

Suggestion:

    if (!iter.repeat()) { 
       return false;
    }

src/hotspot/share/interpreter/bytecodeUtils.cpp line 346:

> 344: 
> 345:     if (found && is_parameter) {
> 346:       // Check MethodParameters for a name, if it carries a name

Suggestion:

      // check MethodParameters for a name, if it carries a name

src/hotspot/share/interpreter/bytecodeUtils.cpp line 354:

> 352:           char *var = cp->symbol_at(elem.name_cp_index)->as_C_string();
> 353:           os->print("%s", var);
> 354: 

No need for blank line

src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483:

> 1481:   // Is an explicit slot given?
> 1482:   bool explicit_search = slot >= 0;
> 1483:   if (explicit_search) {

Suggestion:

  if (slot >= 0) {

No need for the temporary local.

src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:

> 38:   // Slot can be nonnegative to indicate an explicit search for the source of null
> 39:   // If slot is negative (default), also search for the action that caused the NPE before
> 40:   // deriving the actual slot and source of null by code parsing

Suggestion:

  // Slot can be nonnegative to indicate an explicit search for the source of null.
  // If slot is negative (default), also search for the action that caused the NPE before
  // deriving the actual slot and source of null by code parsing.

Periods at the end of sentences in comments.

src/java.base/share/classes/java/lang/NullPointerException.java line 78:

> 76:     NullPointerException(int stackOffset, int searchSlot) {
> 77:         extendedMessageState = setupCustomBackTrace(stackOffset, searchSlot);
> 78:         this();

I thought `this()` had to come first in a constructor? Is this new in 25 or 26?

src/java.base/share/classes/java/lang/NullPointerException.java line 101:

> 99:             SEARCH_SLOT_MASK = SEARCH_SLOT_MAX << SEARCH_SLOT_SHIFT;
> 100: 
> 101:     // Access these fields in object monitor only

Suggestion:

    // Access these fields only while holding this object's monitor lock.

src/java.base/share/classes/java/lang/NullPointerException.java line 162:

> 160:     ///    and the search slot will be derived by bytecode tracing.  The message
> 161:     ///    will also include the action that caused the NPE besides the source of
> 162:     ///    the `null`.

Suggestion:

    ///    will also include the action that caused the NPE along with the source
    ///    of the `null`.

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

PR Review: https://git.openjdk.org/jdk/pull/26600#pullrequestreview-3087045581
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253509165
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253517408
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253519550
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253472224
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253481631
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253558481
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253541806
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253487877

From jsjolen at openjdk.org  Tue Aug  5 09:59:03 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 5 Aug 2025 09:59:03 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
Message-ID: <O1JJQxRIOgu1ja8EluwT-8ug6y-fP0kxUkRosHIycuw=.ac5d6ae7-3ca9-44fa-abf6-6b27f88699e5@github.com>

On Tue, 5 Aug 2025 08:32:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>
> src/java.base/share/classes/java/lang/NullPointerException.java line 78:
> 
>> 76:     NullPointerException(int stackOffset, int searchSlot) {
>> 77:         extendedMessageState = setupCustomBackTrace(stackOffset, searchSlot);
>> 78:         this();
> 
> I thought `this()` had to come first in a constructor? Is this new in 25 or 26?

https://openjdk.org/jeps/492

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253816429

From jsjolen at openjdk.org  Tue Aug  5 10:23:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 5 Aug 2025 10:23:07 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <DpevExdDMh5yWZXGeYw_IHBv9l0sxT-x3tn0DeAvh7M=.e41619ed-238a-4559-ad10-ae248b4e9ba9@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

Still reading this. A few comments, mostly intended to make this easier to grok for future readers. The actual logic seems fine from a first read.

src/java.base/share/classes/java/lang/NullPointerException.java line 159:

> 157:     ///    configurations to trace how a particular argument, which turns out to
> 158:     ///    be `null`, was evaluated.
> 159:     /// 2. `searchSlot < 0`, stack offset is 0 (a call to the nullary constructor)

Can `searchSlot == -1` here?

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

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

From jsjolen at openjdk.org  Tue Aug  5 10:23:08 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 5 Aug 2025 10:23:08 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
Message-ID: <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>

On Tue, 5 Aug 2025 07:55:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>
> src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483:
> 
>> 1481:   // Is an explicit slot given?
>> 1482:   bool explicit_search = slot >= 0;
>> 1483:   if (explicit_search) {
> 
> Suggestion:
> 
>   if (slot >= 0) {
> 
> No need for the temporary local.

If we don't adopt the enum I suggested, then I do prefer the naming of the condition through a variable. It gives you a hint of what the check is looking for, and not only what the check does.

> src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:
> 
>> 38:   // Slot can be nonnegative to indicate an explicit search for the source of null
>> 39:   // If slot is negative (default), also search for the action that caused the NPE before
>> 40:   // deriving the actual slot and source of null by code parsing
> 
> Suggestion:
> 
>   // Slot can be nonnegative to indicate an explicit search for the source of null.
>   // If slot is negative (default), also search for the action that caused the NPE before
>   // deriving the actual slot and source of null by code parsing.
> 
> Periods at the end of sentences in comments.

I'd like to see the description for `slot` pushed into an enum, and make any negative number except `-1` explicitly forbidden.

```c++
enum class NPESlot : int {
  // docs here
  None = -1,
  // docs here
  Explicit // Anything >= 0
};
bool get_NPE_message_at(outputStream* ss, Method* method, int bci, NPESlot slot) {
  if (slot != NPESlot::None) {
    // Explicit search
  }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253888922
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2253865251

From rriggs at openjdk.org  Tue Aug  5 13:52:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 13:52:03 GMT
Subject: RFR: 8364540: Apply @Stable to Shared Secrets
In-Reply-To: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>
References: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>
Message-ID: <CXthYaM9OZBPjO7U_eRZbCw46Dihg8H7EBq9b-QhVYk=.c38e3747-5f01-4cc4-b936-dfd250b4a546@github.com>

On Mon, 4 Aug 2025 17:21:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to update the `SharedSecrets` class in `jdk.internal.access` to annotate all but one static field with the `@Stable` annotation.
> 
> The `@Stable` annotation was added to all static fields except for `javaAWTFontAccess`, which remains unannotated. This is because it can be set using several code paths.
> 
> No tests were changed or added, as this is an internal annotation adjustment with no expected behavioral impact.
> 
> This PR passes `tier1`, `tier2`, and `tier3` testing on multiple platforms.
> 
> In a future follow-up issue, we could identify fields in the implementations of the access classes that, in turn, are stable themselves. When this PR is integrated, it might be possible to remove local copies of access in classes to reduce bytecode size with little or no performance impact. Currently, we do not check the invariant, a field is set only once. This is yet another improvement proposal we could do -- maybe using Stable Values.

Looks good, thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26627#pullrequestreview-3088393663

From rriggs at openjdk.org  Tue Aug  5 14:22:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 14:22:05 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>

On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

src/hotspot/share/interpreter/bytecodeUtils.cpp line 1514:

> 1512:   return true;
> 1513: }
> 1514: 

Extra new line

src/java.base/share/classes/java/lang/NullPointerException.java line 75:

> 73: 
> 74:     /// Creates an NPE with a custom backtrace configuration.
> 75:     /// The exception has no message if detailed NPE is not enabled.

Don't mix markdown comments with regular javadoc comments, it just looks inconsistent without adding value.
Use regular // comments.

src/java.base/share/classes/java/lang/NullPointerException.java line 142:

> 140:     }
> 141: 
> 142:     // Methods below must be called in object monitor

This kind of warning should be on every method declaration, if separated from the method doc, it can be overlooked by future maintainers.

src/java.base/share/classes/java/lang/NullPointerException.java line 146:

> 144:     private void ensureMessageComputed() {
> 145:         if ((extendedMessageState & (MESSAGE_COMPUTED | CONSTRUCTOR_FINISHED)) == CONSTRUCTOR_FINISHED) {
> 146:             int stackOffset = (extendedMessageState & STACK_OFFSET_MASK) >> STACK_OFFSET_SHIFT;

This would be more readable if private utility methods were added that encapsulated the shift and masking, both for extraction and construction.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 637:

> 635:     /// Stack offset is the number of non-hidden frames to skip, pointing to the null-checking API.
> 636:     /// Search slot is the slot where the null-checked value is passed in.
> 637:     NullPointerException extendedNullPointerException(int stackOffset, int searchSlot);

Method should **not** be added to SharedSecrets solely for access by tests.
Tests can use @modules to gain access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2251763870
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254483182
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254486286
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254494309
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254508852

From weijun at openjdk.org  Tue Aug  5 14:31:24 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Aug 2025 14:31:24 GMT
Subject: RFR: 8347938: Switch to latest ML-KEM private key encoding [v6]
In-Reply-To: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
References: <A6ozfQOWRAJoz59gnQZCNaisAoxY8AT4dYaBVo2J5E8=.4fff3bdb-19d1-478a-b2a8-330734ecaf2c@github.com>
Message-ID: <CD4bmGAgzjpO8QXsnn0kQPyoJuw3Y1RShUtCbxLEsCY=.b9b0814e-e377-4a80-bad1-e6a33cfc3f72@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.
> 
> By default, the choice is "seed".
> 
> 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 incrementally with one additional commit since the last revision:

  Ben comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24969/files
  - new: https://git.openjdk.org/jdk/pull/24969/files/94a7a437..281af2c0

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

  Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 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 liach at openjdk.org  Tue Aug  5 14:34:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:34:50 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <qFbIrj_vDeAq8NRzQsM2Z1emOVVveaLY9-irBY6AhTc=.842fd351-aba9-4ad8-a34f-65a622199d70@github.com>

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Web review
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26600/files
  - new: https://git.openjdk.org/jdk/pull/26600/files/5735b802..09233e9a

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

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

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

From liach at openjdk.org  Tue Aug  5 14:34:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:34:50 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
Message-ID: <Y80VX-2tPoUBRa-WvIwxrVoHo5nbC5FEgS430uF8fuk=.fefc80d4-9c95-4cc4-bd7f-4065317424a9@github.com>

On Tue, 5 Aug 2025 08:16:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Web review
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/interpreter/bytecodeUtils.cpp line 354:
> 
>> 352:           char *var = cp->symbol_at(elem.name_cp_index)->as_C_string();
>> 353:           os->print("%s", var);
>> 354: 
> 
> No need for blank line

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254528382

From liach at openjdk.org  Tue Aug  5 14:34:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:34:51 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
Message-ID: <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>

On Mon, 4 Aug 2025 14:58:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Web review
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/interpreter/bytecodeUtils.cpp line 1514:
> 
>> 1512:   return true;
>> 1513: }
>> 1514: 
> 
> Extra new line

Suggestion:

> src/java.base/share/classes/java/lang/NullPointerException.java line 75:
> 
>> 73: 
>> 74:     /// Creates an NPE with a custom backtrace configuration.
>> 75:     /// The exception has no message if detailed NPE is not enabled.
> 
> Don't mix markdown comments with regular javadoc comments, it just looks inconsistent without adding value.
> Use regular // comments.

Suggestion:

    // Creates an NPE with a custom backtrace configuration.
    // The exception has no message if detailed NPE is not enabled.

> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 637:
> 
>> 635:     /// Stack offset is the number of non-hidden frames to skip, pointing to the null-checking API.
>> 636:     /// Search slot is the slot where the null-checked value is passed in.
>> 637:     NullPointerException extendedNullPointerException(int stackOffset, int searchSlot);
> 
> Method should **not** be added to SharedSecrets solely for access by tests.
> Tests can use @modules to gain access.

This is intended to be an API directly called by future null-check APIs, like `Objects.requireNonNull` or `Checks.nullCheck`. I initially had code for rNN but decided to withhold that for a future patch since it involves CSR and other evaluations not related to this patch's efforts.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254529734
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254532646
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254537044

From liach at openjdk.org  Tue Aug  5 14:34:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:34:51 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
Message-ID: <tkRkYwC8-2p6lYMpypceROvLtksWkX_DeKUQmtXszcA=.c90ff7e1-9003-4938-9a47-0871d98b34f6@github.com>

On Tue, 5 Aug 2025 10:07:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/interpreter/bytecodeUtils.hpp line 40:
>> 
>>> 38:   // Slot can be nonnegative to indicate an explicit search for the source of null
>>> 39:   // If slot is negative (default), also search for the action that caused the NPE before
>>> 40:   // deriving the actual slot and source of null by code parsing
>> 
>> Suggestion:
>> 
>>   // Slot can be nonnegative to indicate an explicit search for the source of null.
>>   // If slot is negative (default), also search for the action that caused the NPE before
>>   // deriving the actual slot and source of null by code parsing.
>> 
>> Periods at the end of sentences in comments.
>
> I'd like to see the description for `slot` pushed into an enum, and make any negative number except `-1` explicitly forbidden.
> 
> ```c++
> enum class NPESlot : int {
>   // docs here
>   None = -1,
>   // docs here
>   Explicit // Anything >= 0
> };
> bool get_NPE_message_at(outputStream* ss, Method* method, int bci, NPESlot slot) {
>   if (slot != NPESlot::None) {
>     // Explicit search
>   }
> }

I don't think I know how to use C++ enums. I tried to define this enum in bytecodeUtils.hpp and use it from jvm.cpp, and don't know how in any way I can ever express `BytecodeUtils::NullSlot slot = search_slot >= 0 ? search_slot : ???;` because `NullSlot::Search` or `BytecodeUtils::NullSlot::Search` or `BytecodeUtils::NullSlot.Search` are all erroneous. I don't think this may worth the hassle since the attempt to use C++ enum only creates more pain, unless you tell me how to use it properly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254525459

From rriggs at openjdk.org  Tue Aug  5 14:56:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 14:56:03 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v2]
In-Reply-To: <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
 <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>
Message-ID: <pEd2HoPSaXF2YFTsfN9OdGy5AbFo2pVPblVzqDCDeL0=.df678328-6541-4ffc-b1f2-becedb965351@github.com>

On Tue, 5 Aug 2025 14:28:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 637:
>> 
>>> 635:     /// Stack offset is the number of non-hidden frames to skip, pointing to the null-checking API.
>>> 636:     /// Search slot is the slot where the null-checked value is passed in.
>>> 637:     NullPointerException extendedNullPointerException(int stackOffset, int searchSlot);
>> 
>> Method should **not** be added to SharedSecrets solely for access by tests.
>> Tests can use @modules to gain access.
>
> This is intended to be an API directly called by future null-check APIs, like `Objects.requireNonNull` or `Checks.nullCheck`. I initially had code for rNN but decided to withhold that for a future patch since it involves CSR and other evaluations not related to this patch's efforts.

Don't add APIs without uses; it speculative and the API may not be what is really needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254604180

From liach at openjdk.org  Tue Aug  5 15:07:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 15:07:13 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v3]
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <e-H-6DU67U-jnIXODbrZFIwc1lhfBWKnGMMDQZp3icg=.7a952975-977c-4e5c-8dbe-cf5426733f23@github.com>

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

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

 - Use c++ enum classes per jdksjolen
 - Merge branch 'exp/requireNonNull-message-hacks' of github.com:liachmodded/jdk into exp/requireNonNull-message-hacks
 - Web review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Years
 - Roll back Objects.rNN for now
 - Review remarks
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks
 - Bork
 - Try generify the NPE tracing API
 - ... and 4 more: https://git.openjdk.org/jdk/compare/dc4f5978...9af7ee85

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26600/files
  - new: https://git.openjdk.org/jdk/pull/26600/files/09233e9a..9af7ee85

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

  Stats: 5643 lines in 151 files changed: 3341 ins; 1944 del; 358 mod
  Patch: https://git.openjdk.org/jdk/pull/26600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600

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

From liach at openjdk.org  Tue Aug  5 15:07:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 15:07:14 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v3]
In-Reply-To: <tkRkYwC8-2p6lYMpypceROvLtksWkX_DeKUQmtXszcA=.c90ff7e1-9003-4938-9a47-0871d98b34f6@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
 <tkRkYwC8-2p6lYMpypceROvLtksWkX_DeKUQmtXszcA=.c90ff7e1-9003-4938-9a47-0871d98b34f6@github.com>
Message-ID: <PNvKV4rwpdi4t9ia_UuybItWpKIO45Z6ZqGIMj9CKus=.0923e38f-929b-420d-8a6c-828094bac39b@github.com>

On Tue, 5 Aug 2025 14:24:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I'd like to see the description for `slot` pushed into an enum, and make any negative number except `-1` explicitly forbidden.
>> 
>> ```c++
>> enum class NPESlot : int {
>>   // docs here
>>   None = -1,
>>   // docs here
>>   Explicit // Anything >= 0
>> };
>> bool get_NPE_message_at(outputStream* ss, Method* method, int bci, NPESlot slot) {
>>   if (slot != NPESlot::None) {
>>     // Explicit search
>>   }
>> }
>
> I don't think I know how to use C++ enums. I tried to define this enum in bytecodeUtils.hpp and use it from jvm.cpp, and don't know how in any way I can ever express `BytecodeUtils::NullSlot slot = search_slot >= 0 ? search_slot : ???;` because `NullSlot::Search` or `BytecodeUtils::NullSlot::Search` or `BytecodeUtils::NullSlot.Search` are all erroneous. I don't think this may worth the hassle since the attempt to use C++ enum only creates more pain, unless you tell me how to use it properly.

I think I figured out how to use static_cast with C++ enum classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254630773

From liach at openjdk.org  Tue Aug  5 15:07:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 15:07:15 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v3]
In-Reply-To: <pEd2HoPSaXF2YFTsfN9OdGy5AbFo2pVPblVzqDCDeL0=.df678328-6541-4ffc-b1f2-becedb965351@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
 <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>
 <pEd2HoPSaXF2YFTsfN9OdGy5AbFo2pVPblVzqDCDeL0=.df678328-6541-4ffc-b1f2-becedb965351@github.com>
Message-ID: <pOYre3BM8bk2MGRLph2dEW0u8XSC1BVM3_PaMBywEZY=.d893ba55-1f8c-4f50-9123-96200cb33367@github.com>

On Tue, 5 Aug 2025 14:53:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This is intended to be an API directly called by future null-check APIs, like `Objects.requireNonNull` or `Checks.nullCheck`. I initially had code for rNN but decided to withhold that for a future patch since it involves CSR and other evaluations not related to this patch's efforts.
>
> Don't add APIs without uses; it speculative and the API may not be what is really needed.

Should I open a dependent PR to prove that this is exactly what we need to unblock [Objects::requireNonNull message enhancements](https://bugs.openjdk.org/browse/JDK-8233268)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2254627867

From rriggs at openjdk.org  Tue Aug  5 15:17:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 15:17:12 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <bsYDcgavbXfmf2WP_iXtlEJGKPZppbq1yBGektW4cI0=.4e19234e-cd9a-40d7-add6-e6cbcf8ea01c@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
 <bsYDcgavbXfmf2WP_iXtlEJGKPZppbq1yBGektW4cI0=.4e19234e-cd9a-40d7-add6-e6cbcf8ea01c@github.com>
Message-ID: <XxpmQudu9kApTVI9haudSB_WKmuAnZiyad5EMZqYjJ8=.af2ddc70-c0f2-461e-8064-bf0f29574bcb@github.com>

On Mon, 4 Aug 2025 15:00:52 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore c2 optimization.
>
> src/hotspot/share/prims/jvm.cpp line 1744:
> 
>> 1742: JVM_END
>> 1743: 
>> 1744: JVM_ENTRY(jint, JVM_GetClassAccessFlags(JNIEnv *env, jclass cls))
> 
> What about the declaration in `jvm.h`? https://github.com/openjdk/jdk/blob/6c52b73465b0d0daeafc54c3c6cec3062bf490c5/src/hotspot/share/include/jvm.h#L610

Created issue https://bugs.openjdk.org/browse/JDK-8364750

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2254660805

From liach at openjdk.org  Tue Aug  5 16:04:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 16:04:08 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
Message-ID: <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>

> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update NPE per roger review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26600/files
  - new: https://git.openjdk.org/jdk/pull/26600/files/9af7ee85..4ba1f17c

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

  Stats: 33 lines in 1 file changed: 12 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/26600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600

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

From duke at openjdk.org  Tue Aug  5 16:29:03 2025
From: duke at openjdk.org (duke)
Date: Tue, 5 Aug 2025 16:29:03 GMT
Subject: RFR: 8355379: Annotate lazy fields in java.security @Stable [v4]
In-Reply-To: <e4e1FN_Bt_l8dWiudCe37G0hPgmpD08vm1T6wfSsyb4=.1ddd55d9-8506-45d6-9570-7fc55c4fdd4d@github.com>
References: <BdTzABSl5jaGkV-xByy2FlnE8-JPfLejMQBjRZNLBjY=.b6265489-d61e-4572-a523-93e77be49e0c@github.com>
 <e4e1FN_Bt_l8dWiudCe37G0hPgmpD08vm1T6wfSsyb4=.1ddd55d9-8506-45d6-9570-7fc55c4fdd4d@github.com>
Message-ID: <gP9EbMYoGI2G7xGCmIvkgohA597ZjuTubWi5RRAxrEg=.ed599ef6-8613-41fb-8918-7046256e5dcf@github.com>

On Tue, 29 Jul 2025 23:07:45 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 and URICertStoreParameters.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8355379: Annotate lazy fields in java.security @Stable
>  - 8355379: Annotate lazy fields in java.security @Stable
>  - 8355379: Annotate lazy fields in java.security @Stable

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

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

PR Comment: https://git.openjdk.org/jdk/pull/25405#issuecomment-3155817089

From dfuchs at openjdk.org  Tue Aug  5 19:17:35 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 5 Aug 2025 19:17:35 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v12]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <SCsRMYq_YcUXak0vqS9nds-o8JCzef-RS8XmXCWqxkk=.422e19d8-d034-4bd4-a925-63f242f7734c@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 588 commits:

 - merge latest changes from master branch
 - qpack: modify Encoder.header to use DT lock, test headers cleanup.
 - merge latest from master branch
 - merge latest from master branch
 - Include peer's error information in exceptions thrown on connection close
 - Fix error IDs
 - Remove assertion error
 - Remove assertion errors from packet encryption
 - Remove assertion errors from retry packet handling
 - Remove assertion errors from initial key derivation
 - ... and 578 more: https://git.openjdk.org/jdk/compare/d906e450...83f8dad1

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=11
  Stats: 105164 lines in 470 files changed: 102303 ins; 1335 del; 1526 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 coleenp at openjdk.org  Tue Aug  5 19:30:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 5 Aug 2025 19:30:12 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <XxpmQudu9kApTVI9haudSB_WKmuAnZiyad5EMZqYjJ8=.af2ddc70-c0f2-461e-8064-bf0f29574bcb@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
 <bsYDcgavbXfmf2WP_iXtlEJGKPZppbq1yBGektW4cI0=.4e19234e-cd9a-40d7-add6-e6cbcf8ea01c@github.com>
 <XxpmQudu9kApTVI9haudSB_WKmuAnZiyad5EMZqYjJ8=.af2ddc70-c0f2-461e-8064-bf0f29574bcb@github.com>
Message-ID: <w6q2m3_BNHYfKHF63DJNf_A2TiizbTQDGCbdN_JX8k4=.c0ce5dc8-b4ae-4c76-a390-4d2f6f72b906@github.com>

On Tue, 5 Aug 2025 15:14:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1744:
>> 
>>> 1742: JVM_END
>>> 1743: 
>>> 1744: JVM_ENTRY(jint, JVM_GetClassAccessFlags(JNIEnv *env, jclass cls))
>> 
>> What about the declaration in `jvm.h`? https://github.com/openjdk/jdk/blob/6c52b73465b0d0daeafc54c3c6cec3062bf490c5/src/hotspot/share/include/jvm.h#L610
>
> Created issue https://bugs.openjdk.org/browse/JDK-8364750

Sorry I missed the declaration. Will fix it. Thanks for filing the bug Roger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2255153426

From abarashev at openjdk.org  Tue Aug  5 19:46:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 5 Aug 2025 19:46:08 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
Message-ID: <SPj7_bBKhsw_eyQRM_xasJMbMg5I9Y9Q_fc18Ogv0nE=.d69b7a4f-70d6-45b1-b386-12e6d59e945d@github.com>

On Fri, 1 Aug 2025 01:43:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
>> 
>> A few implementation notes:
>> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
>> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
>> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
>> 
>> CSR will be filed once the review is wrapping up.
>> 
>> Thanks~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added support for overriding the security property with a system
>   property using the same property name.

src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 40:

> 38: /**
> 39:  * Algorithm constraints for disabled crypto algorithms property
> 40:  *

Blank line will be ignored, `<P>` should be used

src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 49:

> 47:     private static class CryptoHolder {
> 48:         static final CryptoAlgorithmConstraints CONSTRAINTS =
> 49:                 new CryptoAlgorithmConstraints("jdk.crypto.disabledAlgorithms");

Current convention is to declare security property as `public static final String` at the top of the class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255182293
PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255186585

From abarashev at openjdk.org  Tue Aug  5 20:02:07 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 5 Aug 2025 20:02:07 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
Message-ID: <KjPlEQ9zwpupdHu7iucmfe1BJ3ji4oru5gv0BEbYHX4=.9a7fb045-751b-462f-a15c-a45938e7a6d8@github.com>

On Fri, 1 Aug 2025 01:43:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
>> 
>> A few implementation notes:
>> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
>> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
>> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
>> 
>> CSR will be filed once the review is wrapping up.
>> 
>> Thanks~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added support for overriding the security property with a system
>   property using the same property name.

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

> 791: #
> 792: # Service:  (one of the following, more service may be added later)
> 793: #     Cipher | KeyStore | MessageDigest | Signature

Should we consider matching all services if service name is missing (make service name optional)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255219755

From duke at openjdk.org  Tue Aug  5 22:43:04 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 5 Aug 2025 22:43:04 GMT
Subject: RFR: 8355379: Annotate lazy fields in java.security @Stable [v4]
In-Reply-To: <Q6YqQw8V6nx-ukVBvGm_Qfn9-3HWo6cku0mL6gMCNCQ=.d1953f35-90d7-4006-a44c-9b956b926281@github.com>
References: <BdTzABSl5jaGkV-xByy2FlnE8-JPfLejMQBjRZNLBjY=.b6265489-d61e-4572-a523-93e77be49e0c@github.com>
 <e4e1FN_Bt_l8dWiudCe37G0hPgmpD08vm1T6wfSsyb4=.1ddd55d9-8506-45d6-9570-7fc55c4fdd4d@github.com>
 <Q6YqQw8V6nx-ukVBvGm_Qfn9-3HWo6cku0mL6gMCNCQ=.d1953f35-90d7-4006-a44c-9b956b926281@github.com>
Message-ID: <mgLd_7SfCbVy6c-TtkFuH7FEkftw7YKhe-NbUnC_MZ8=.495ec507-139d-4555-b5bb-6b8314922b21@github.com>

On Tue, 5 Aug 2025 08:00:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 8355379: Annotate lazy fields in java.security @Stable
>>  - 8355379: Annotate lazy fields in java.security @Stable
>>  - 8355379: Annotate lazy fields in java.security @Stable
>
> src/java.base/share/classes/java/security/PKCS12Attribute.java line 50:
> 
>> 48:     private String value;
>> 49:     private final byte[] encoded;
>> 50: 
> 
> The fields `name`, `value`, and `encoded` can also be marked `@Stable` with appropriate changes (e.g., making the fields `final` and setting them to `null` in the constructor that only takes an array). I think we should do this under a separate issue.
> 
> Similar for the other class in this PR.

https://bugs.openjdk.org/browse/JDK-8364779

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25405#discussion_r2255479469

From duke at openjdk.org  Tue Aug  5 23:09:02 2025
From: duke at openjdk.org (Thomas Fitzsimmons)
Date: Tue, 5 Aug 2025 23:09:02 GMT
Subject: RFR: 8361711: Add library name configurability to PKCS11Test.java
In-Reply-To: <xWXZrQ7yFfdaPuGwSoUROy7kFerRUVcDoD5Zt_jDYBA=.c7c01f30-8424-4b4b-88ba-2a8b456fab8d@github.com>
References: <QNJ0JfM5Ofh-3HQve5AWl3euzPKNyqgH8xYXjDKwL_k=.f7a88184-a7e7-47e8-b5d7-0967ec5f6ca7@github.com>
 <xWXZrQ7yFfdaPuGwSoUROy7kFerRUVcDoD5Zt_jDYBA=.c7c01f30-8424-4b4b-88ba-2a8b456fab8d@github.com>
Message-ID: <OtrwHQeh7sPOfc-d-YYUhzRgQHbxX9DQorcA5u6Df1w=.6628b101-3ad7-4e6e-9c0c-b74fe742afef@github.com>

On Mon, 4 Aug 2025 17:32:38 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> This patch adds configurability to `PKCS11Test.java`.
>> 
>> Specifically, it adds two new system properties:
>> 
>> - `CUSTOM_P11_LIBRARY_NAME`: Allow overriding the value assigned to the `nss_library` field.  Prior to this patch, `nss_library` was set to either `"softokn3"` or `"nss3"`.
>> 
>> - `CUSTOM_P11_CONFIG_VARIANT`: Abstract the configuration file type to load.  Prior to this patch, test cases that wanted to run `NSS` in sensitive mode would hard-code `p11-nss-sensitive.txt` on their command lines.
>> 
>> The patch updates the three `p11-nss-sensitive.txt`-using test cases to use the new `CUSTOM_P11_CONFIG_VARIANT` property:
>> 
>> 
>> test/jdk/java/security/KeyAgreement/Generic.java
>> test/jdk/sun/security/pkcs11/Mac/TestLargeSecretKeys.java
>> test/jdk/sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec.java
>> 
>> 
>> I have been using this change to run `PKCS11Test.java` against the [Kryoptic](https://github.com/latchset/kryoptic) PKCS11 soft token, using this invocation:
>> 
>> 
>> make test \
>>     JTREG="JAVA_OPTIONS=-DCUSTOM_P11_CONFIG=/tmp/kryoptic-configuration/p11-kryoptic.txt \
>>                         -DCUSTOM_P11_LIBRARY_NAME=kryoptic_pkcs11 \
>>                         -Djdk.test.lib.artifacts.nsslib-linux_x64=/tmp/kryoptic-configuration \
>>                         -DCUSTOM_DB_DIR=/tmp/kryoptic-configuration"
>> 
>> 
>> `/tmp/kryoptic-configuration` contains (among other files):
>> 
>> 
>> libkryoptic_pkcs11.so
>> p11-kryoptic.txt
>> p11-kryoptic-sensitive.txt
>> 
>> 
>> With `CUSTOM_P11_LIBRARY_NAME` set, `PKCS11Test.java` can find `libkryoptic_pkcs11.so`.
>> 
>> And setting `CUSTOM_P11_CONFIG` causes the sensitive tests to use `p11-kryoptic-sensitive.txt` via the new `CUSTOM_P11_CONFIG_VARIANT` property.
>> 
>> On my `Fedora 42` `x86-64` machine, I tested for regressions with:
>> 
>> $ time make test JOBS=4 JTREG="JAVA_OPTIONS=-Djdk.test.lib.artifacts.nsslib-linux_x64=/usr/lib64" TEST="test/jdk/sun/security/pkcs11"
>> 
>> and:
>> 
>> $ time make test JOBS=4 TEST="test/jdk/sun/security/pkcs11"
>
> Will you also include p11-kryoptic.txt and p11-kryoptic-sensitive.txt configuration files for Kryoptic library so others can also run this interoperability? And do the current P11-NSS tests continue to work as expected?

Thank you for taking a look, @rhalade.

> Will you also include p11-kryoptic.txt and p11-kryoptic-sensitive.txt configuration files for Kryoptic library so others can also run this interoperability?

I had not planned to yet (i.e., not with this patch).  Eventually I think doing so will make sense, once we settle on the Kryoptic configuration that best suits `OpenJDK`.

For reference in the meantime, the `Kryoptic` project is running their continuous integration with the following configuration files:

https://github.com/latchset/kryoptic/blob/main/testdata/openjdk/p11-kryoptic.txt
https://github.com/latchset/kryoptic/blob/main/testdata/openjdk/p11-kryoptic-sensitive.txt

> And do the current P11-NSS tests continue to work as expected?

Yes, I checked for differences in `.jtr` files produced by the following invocation:


time make test JOBS=4 JTREG="JAVA_OPTIONS=-Djdk.test.lib.artifacts.nsslib-linux_x64=/usr/lib64 --enable-native-access=ALL-UNNAMED" TEST="test/jdk/sun/security/pkcs11 test/jdk/java/security/KeyAgreement/Generic.java"


on commit b65fdf5af0a5e1cf0d66d7551c6df63e8d07c5fa (i.e., without my patch) and on commit 780a630af938edeab3d8c5c895c92f2243814ede (i.e., with my patch).

(The `--enable-native-access=ALL-UNNAMED` argument is not strictly required, but reduces noise in the diffs; without it, both with and without my patch, tests mostly print the following warning, but sometimes do not; which tests do and do not changes from run to run:


WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by PKCS11Test in an unnamed module (file:/[...])
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled


I am not sure what's going on there.)

The only differences are the configuration file lines printed in the `.jtr` files, for example, `TestRSAKeyLength.jtr` has a new line:


Configuration file: ./nss/p11-nss.txt

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

PR Comment: https://git.openjdk.org/jdk/pull/26325#issuecomment-3156881829

From valeriep at openjdk.org  Wed Aug  6 03:03:08 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 03:03:08 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v2]
In-Reply-To: <3RkK1-IRWRHq9o9wV1-RZtu7IBBvX54pH-5VZTh3c70=.033fe294-e6ec-4cf3-b1a7-8b70a3108db1@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <n3rThis-Gh-OViJsqanyON9fkg2flZzy_pSLozIqnBU=.49d548ec-8073-421f-854b-9e302fd707b7@github.com>
 <3RkK1-IRWRHq9o9wV1-RZtu7IBBvX54pH-5VZTh3c70=.033fe294-e6ec-4cf3-b1a7-8b70a3108db1@github.com>
Message-ID: <uXLr4vC2fHf7gDUHKmz89ahekHnQnTEfEDWAL16JHkM=.685d0865-53b7-4d0c-9bc6-87f5b6fbb14f@github.com>

On Thu, 31 Jul 2025 18:20:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments from Sean and Tony.
>
> src/java.base/share/conf/security/java.security line 775:
> 
>> 773: 
>> 774: #
>> 775: # Algorithm restrictions for Java Crypto API services
> 
> Nit: missing period.

Given this is a title, we don't need a period? This is same as other titles in the `java.security` file.

> src/java.base/share/conf/security/java.security line 789:
> 
>> 787: #       Service.AlgorithmName
>> 788: #
>> 789: # Service:  (one of the following, more service may be added later)
> 
> s/service/services/

Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255747128
PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255747624

From valeriep at openjdk.org  Wed Aug  6 03:03:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 03:03:06 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v2]
In-Reply-To: <HMrlte1MePLdhlW0C3nkgJ5Zwl-uU6XuiBDUJCBjcis=.8c947025-29a7-4e78-9b82-dcadaad20b35@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <n3rThis-Gh-OViJsqanyON9fkg2flZzy_pSLozIqnBU=.49d548ec-8073-421f-854b-9e302fd707b7@github.com>
 <EyFPcJyRuneG4kAezbZAQSgPu2bBOdA7d5Edf934o3U=.2f0d7dc3-5aa2-4359-a583-9e3648e5e057@github.com>
 <oeNnaWSGuZKgLpbPBKF_b3SuJjZLy3f-nJreuxtXrf8=.05589182-29e9-40c3-9224-ce2d13d14f23@github.com>
 <HMrlte1MePLdhlW0C3nkgJ5Zwl-uU6XuiBDUJCBjcis=.8c947025-29a7-4e78-9b82-dcadaad20b35@github.com>
Message-ID: <0YFUM_bFR4q87cNux6QgGMmRNIxABS3L4hg08WvqKe4=.15c6c8f0-9856-4e16-8d33-9bdcf2b49cba@github.com>

On Thu, 31 Jul 2025 14:33:03 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Well, I see your concern and it's valid. However, quite a few algorithms do not have OIDs as the java security standard names may not have an 1-to-1 mapping to OID, or no OID defined at all. For example, none of `Keystore` type has a corresponding OID. Also, in the case of `Cipher`, this is even more complicated, e.g. `AES` OIDs are keysize-specific and `PBES2` cipher has one OID but there are multiple algorithm names which includes additional components/algorithms info (`PBEWithHmacSHA1AndAES_128`, `PBEWithHmacSHA512/256AndAES_256`. Thus, we can't use whether there is an OID to check for user typos. In addition, there could be algorithms which JDK does not have an OID mapping as `KnownOIDs` usually doesn't cover algorithms that we don't support. If we want to be stricter, I can change to error out if invalid entry is detected instead of ignored. However, we can only validate against syntax and perhaps reject unsupported services if desired. But the algorithm part is really diffic
 ult to validate.
>
> Ok, these are good points. So suggest we throw an IAE if the syntax is invalid (missing ".", etc) or the service name is not one of the supported ones.

Ok. will change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255744826

From valeriep at openjdk.org  Wed Aug  6 03:07:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 03:07:06 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v2]
In-Reply-To: <3RkK1-IRWRHq9o9wV1-RZtu7IBBvX54pH-5VZTh3c70=.033fe294-e6ec-4cf3-b1a7-8b70a3108db1@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <n3rThis-Gh-OViJsqanyON9fkg2flZzy_pSLozIqnBU=.49d548ec-8073-421f-854b-9e302fd707b7@github.com>
 <3RkK1-IRWRHq9o9wV1-RZtu7IBBvX54pH-5VZTh3c70=.033fe294-e6ec-4cf3-b1a7-8b70a3108db1@github.com>
Message-ID: <OBvLdBn3anv32cArBP_13O3opbint_Adk4-IkkmD6lk=.819c1dd6-1356-4282-86ae-e2b905a50a71@github.com>

On Thu, 31 Jul 2025 18:23:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments from Sean and Tony.
>
> src/java.base/share/conf/security/java.security line 801:
> 
>> 799: # its algorithm is the transformation string.
>> 800: #
>> 801: # Note: Entries with unsupported services will be ignored
> 
> Suggest: Services with unrecognized or unsupported algorithms will be ignored.

Per the discussion regarding the throwing `IllegalArgumentException` for invalid entries, I will change this to 

# Note: IllegalArgumentException will be thrown if the property value contains
# entries with invalid syntax or unsupported services.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255751466

From valeriep at openjdk.org  Wed Aug  6 03:12:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 03:12:06 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <_93nDrWDtJXk8v15hGJ0F6EcF6oSKoJyWbunHE8meyM=.cb9276ed-78a5-4c1b-b796-9b747c2e8cac@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
 <_93nDrWDtJXk8v15hGJ0F6EcF6oSKoJyWbunHE8meyM=.cb9276ed-78a5-4c1b-b796-9b747c2e8cac@github.com>
Message-ID: <BXjWSmn_qSY9BMTVoVPudmIBmCcBukOn99BlOmM94po=.678cb03d-b524-481e-94ef-d06fcf5b9394@github.com>

On Fri, 1 Aug 2025 13:04:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added support for overriding the security property with a system
>>   property using the same property name.
>
> src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 80:
> 
>> 78:         if (val != null) {
>> 79:             Security.setProperty(propertyName, val);
>> 80:         }
> 
> I don't think you should set the security property with the value of the system property. This should be:
> 
> 
> if (val == null) {
>     val = Security.getProperty(propertyName);
> }
> 
> 
> Or you can just call `sun.security.util.SecurityProperties.getOverridableProperty()`.

The property value retrieval is inside the parent class. Yes, it's a little like a hack. Let me modify the parent class to achieve this more gracefully then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255755998

From valeriep at openjdk.org  Wed Aug  6 04:40:06 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 04:40:06 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <SPj7_bBKhsw_eyQRM_xasJMbMg5I9Y9Q_fc18Ogv0nE=.d69b7a4f-70d6-45b1-b386-12e6d59e945d@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
 <SPj7_bBKhsw_eyQRM_xasJMbMg5I9Y9Q_fc18Ogv0nE=.d69b7a4f-70d6-45b1-b386-12e6d59e945d@github.com>
Message-ID: <ieaHhISJQQoHGjIxRM3_X4ortIqurVUgWr8NUtrjxu0=.9b161318-9ebf-4c08-90ea-3aa7a41a2d90@github.com>

On Tue, 5 Aug 2025 19:41:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added support for overriding the security property with a system
>>   property using the same property name.
>
> src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 40:
> 
>> 38: /**
>> 39:  * Algorithm constraints for disabled crypto algorithms property
>> 40:  *
> 
> Blank line will be ignored, `<P>` should be used

I re-wrote to put everything in one paragraph.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255841539

From valeriep at openjdk.org  Wed Aug  6 04:50:07 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 04:50:07 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <SPj7_bBKhsw_eyQRM_xasJMbMg5I9Y9Q_fc18Ogv0nE=.d69b7a4f-70d6-45b1-b386-12e6d59e945d@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
 <SPj7_bBKhsw_eyQRM_xasJMbMg5I9Y9Q_fc18Ogv0nE=.d69b7a4f-70d6-45b1-b386-12e6d59e945d@github.com>
Message-ID: <Nkp-IQV-tsEp1X2MFZhBj5CFGph6-9qYMmLk_hL0SJY=.35aa78bb-2e4e-41c0-8c8c-773718ca3bdc@github.com>

On Tue, 5 Aug 2025 19:43:19 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added support for overriding the security property with a system
>>   property using the same property name.
>
> src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 49:
> 
>> 47:     private static class CryptoHolder {
>> 48:         static final CryptoAlgorithmConstraints CONSTRAINTS =
>> 49:                 new CryptoAlgorithmConstraints("jdk.crypto.disabledAlgorithms");
> 
> Current convention is to declare security property as `public static final String` at the top of the class.

Ok, I can do that as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255852462

From valeriep at openjdk.org  Wed Aug  6 04:53:05 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 04:53:05 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <KjPlEQ9zwpupdHu7iucmfe1BJ3ji4oru5gv0BEbYHX4=.9a7fb045-751b-462f-a15c-a45938e7a6d8@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
 <KjPlEQ9zwpupdHu7iucmfe1BJ3ji4oru5gv0BEbYHX4=.9a7fb045-751b-462f-a15c-a45938e7a6d8@github.com>
Message-ID: <Afs0oTEy81pox7-XQEFJK7MpDw0txr2mn49NnCPBYkY=.a477cd49-9182-48c3-b010-e806ead984bf@github.com>

On Tue, 5 Aug 2025 19:59:35 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added support for overriding the security property with a system
>>   property using the same property name.
>
> src/java.base/share/conf/security/java.security line 793:
> 
>> 791: #
>> 792: # Service:  (one of the following, more service may be added later)
>> 793: #     Cipher | KeyStore | MessageDigest | Signature
> 
> Should we consider matching all services if service name is missing (make service name optional)?

Missing service should be treated as error. If we want to match all services, it is better represented as "*". This may be considered for future enhancement if there is a demand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2255856087

From valeriep at openjdk.org  Wed Aug  6 05:39:56 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 05:39:56 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v5]
In-Reply-To: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
Message-ID: <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>

> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
> 
> A few implementation notes:
> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
> 
> CSR will be filed once the review is wrapping up.
> 
> Thanks~
> Valerie

Valerie Peng has updated the pull request incrementally with two additional commits since the last revision:

 - Add a public static final constant for the property name.
 - Address more review comments from Sean and Artur.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26377/files
  - new: https://git.openjdk.org/jdk/pull/26377/files/d4f892fc..c9bf72f4

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

  Stats: 60 lines in 8 files changed: 23 ins; 7 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/26377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26377/head:pull/26377

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

From duke at openjdk.org  Wed Aug  6 06:43:07 2025
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Wed, 6 Aug 2025 06:43:07 GMT
Subject: Integrated: 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: <nElM32K6YPCg6mnV94k5eRJPlvEchYBxgJR_JxVpYO8=.c808d0a5-2273-49ae-85db-a91774126220@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 and URICertStoreParameters.

This pull request has now been integrated.

Changeset: ca416445
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca41644538c7cba3e2f50b11c5045cf2aa595f7f
Stats:     118 lines in 4 files changed: 103 ins; 1 del; 14 mod

8355379: Annotate lazy fields in java.security @Stable

Reviewed-by: pminborg

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

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

From jiefu at openjdk.org  Wed Aug  6 06:59:02 2025
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 6 Aug 2025 06:59:02 GMT
Subject: RFR: 8364597: Replace THL A29 Limited with Tencent
In-Reply-To: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
References: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
Message-ID: <08Gigv9qz5H5c80w-WLegQ_8KVI4xoY-kZ374S8t5ls=.35ded307-c917-4c1b-9ab0-032499140a67@github.com>

On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `THL A29 Limited` was a `Tencent` company but was dissolved.
> So, the copyright notes just use `Tencent` directly.

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26614#pullrequestreview-3090664823

From dholmes at openjdk.org  Wed Aug  6 07:01:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Aug 2025 07:01:06 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
Message-ID: <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>

On Tue, 5 Aug 2025 10:16:32 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483:
>> 
>>> 1481:   // Is an explicit slot given?
>>> 1482:   bool explicit_search = slot >= 0;
>>> 1483:   if (explicit_search) {
>> 
>> Suggestion:
>> 
>>   if (slot >= 0) {
>> 
>> No need for the temporary local.
>
> If we don't adopt the enum I suggested, then I do prefer the naming of the condition through a variable. It gives you a hint of what the check is looking for, and not only what the check does.

That is what comments are for.

>> src/java.base/share/classes/java/lang/NullPointerException.java line 78:
>> 
>>> 76:     NullPointerException(int stackOffset, int searchSlot) {
>>> 77:         extendedMessageState = setupCustomBackTrace(stackOffset, searchSlot);
>>> 78:         this();
>> 
>> I thought `this()` had to come first in a constructor? Is this new in 25 or 26?
>
> https://openjdk.org/jeps/492

And now final - https://openjdk.org/jeps/513

Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256053422
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256047794

From jsjolen at openjdk.org  Wed Aug  6 07:48:23 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 6 Aug 2025 07:48:23 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
 <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>
Message-ID: <7IGhtSwHIBGIY1j6nJCm3Sjv6l28aHypbC98PwPL_Ak=.5d270255-7419-4754-9775-9fc546dae1e2@github.com>

On Wed, 6 Aug 2025 06:57:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If we don't adopt the enum I suggested, then I do prefer the naming of the condition through a variable. It gives you a hint of what the check is looking for, and not only what the check does.
>
> That is what comments are for.

I'd rather explain things with code than with comments when possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256207131

From pminborg at openjdk.org  Wed Aug  6 08:55:08 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Aug 2025 08:55:08 GMT
Subject: Integrated: 8364540: Apply @Stable to Shared Secrets
In-Reply-To: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>
References: <oet4RE1Ap73F4P8za6ZbmVrhYXI91u9G53inaNJfBi0=.ac1ac577-2ead-4329-87c7-5b9b74c892bf@github.com>
Message-ID: <n64JGYjGqgIktGoqBdsIgZ5UmMq-SWziI6OJdeyVo_E=.70addb5e-8010-44c9-b700-7f450e3ec8ec@github.com>

On Mon, 4 Aug 2025 17:21:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to update the `SharedSecrets` class in `jdk.internal.access` to annotate all but one static field with the `@Stable` annotation.
> 
> The `@Stable` annotation was added to all static fields except for `javaAWTFontAccess`, which remains unannotated. This is because it can be set using several code paths.
> 
> No tests were changed or added, as this is an internal annotation adjustment with no expected behavioral impact.
> 
> This PR passes `tier1`, `tier2`, and `tier3` testing on multiple platforms.
> 
> In a future follow-up issue, we could identify fields in the implementations of the access classes that, in turn, are stable themselves. When this PR is integrated, it might be possible to remove local copies of access in classes to reduce bytecode size with little or no performance impact. Currently, we do not check the invariant, a field is set only once. This is yet another improvement proposal we could do -- maybe using Stable Values.

This pull request has now been integrated.

Changeset: 9dffbc9c
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9dffbc9c4cfee7a1f023d548c12194bcf60e4ffd
Stats:     33 lines in 1 file changed: 3 ins; 0 del; 30 mod

8364540: Apply @Stable to Shared Secrets

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Wed Aug  6 08:56:10 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 6 Aug 2025 08:56:10 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <ehWwgSeNEyK5dAKPGqj3s4dqJcqVSlt1yqhWMLR1ZFU=.8e462f15-3c5c-4811-a3e7-c18f78753c70@github.com>
 <qFTX2WInEVE4dJVJmbHOkRE7uNaQ5_GW4IHQsJjJp80=.ed30b7ad-083b-4940-8241-6024987d5477@github.com>
 <MwGV2mrN6hE-PlMvHDTbIVOUCOudNEzLy1F7P8sgpRY=.cb5d53d0-de9d-4ed8-a6a1-8860b4d12a97@github.com>
Message-ID: <HrW_NNP6Azyhislt7LUrESvN985o0vS9ro5OxlIxTvo=.cbefb39d-456b-4c5f-9442-ed824608ecb4@github.com>

On Wed, 6 Aug 2025 06:55:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> https://openjdk.org/jeps/492
>
> And now final - https://openjdk.org/jeps/513
> 
> Thanks

It?s?necessary to?do?this?before the?`this()`/`super()`?call, as?the?`Throwable(?)` constructors?call `this.fillInStackTrace()`:
https://github.com/openjdk/jdk/blob/e304d37996b075b8b2b44b5762d7d242169add49/src/java.base/share/classes/java/lang/Throwable.java#L263-L264

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2256443245

From abarashev at openjdk.org  Wed Aug  6 15:13:07 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 6 Aug 2025 15:13:07 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <Afs0oTEy81pox7-XQEFJK7MpDw0txr2mn49NnCPBYkY=.a477cd49-9182-48c3-b010-e806ead984bf@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
 <KjPlEQ9zwpupdHu7iucmfe1BJ3ji4oru5gv0BEbYHX4=.9a7fb045-751b-462f-a15c-a45938e7a6d8@github.com>
 <Afs0oTEy81pox7-XQEFJK7MpDw0txr2mn49NnCPBYkY=.a477cd49-9182-48c3-b010-e806ead984bf@github.com>
Message-ID: <JwlyaSyHPSPel2niq664pBXjwVz1kTBRqSywfRIAyeg=.c4ae6b66-a080-4444-860d-f5dd42d478c0@github.com>

On Wed, 6 Aug 2025 04:50:50 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 793:
>> 
>>> 791: #
>>> 792: # Service:  (one of the following, more service may be added later)
>>> 793: #     Cipher | KeyStore | MessageDigest | Signature
>> 
>> Should we consider matching all services if service name is missing (make service name optional)?
>
> Missing service should be treated as error. If we want to match all services, it is better represented as "*". This may be considered for future enhancement if there is a demand.

I thought about an option of using `*` wildcard too. We can do it in this iteration simply by replacing `*.algorithm` with `Cipher.algorithm`,  `KeyStore.algorithm`, `MessageDiges.algorithmt`,  `Signature.algorithm`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2257516193

From abarashev at openjdk.org  Wed Aug  6 15:21:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 6 Aug 2025 15:21:08 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v5]
In-Reply-To: <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>
Message-ID: <3HKw-unUnyxY2qwjzygjTHTBu3ykHMBdbtK34Jkgl9w=.bcb4cc08-dbcb-41ed-93ff-5120e46af248@github.com>

On Wed, 6 Aug 2025 05:39:56 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
>> 
>> A few implementation notes:
>> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
>> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
>> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
>> 
>> CSR will be filed once the review is wrapping up.
>> 
>> Thanks~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add a public static final constant for the property name.
>  - Address more review comments from Sean and Artur.

src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 98:

> 96:                     service.equalsIgnoreCase("KeyStore") ||
> 97:                     service.equalsIgnoreCase("MessageDigest") ||
> 98:                     service.equalsIgnoreCase("Signature")) {

It will be a cleaner solution if we define a set of allowed services as a static class variable (all in upper/lower case) and then do `SET.contains(service.toUpper/toLower)`. We may also need such set of allowed services for other operations (like `*` wildcard substitution).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2257535714

From abarashev at openjdk.org  Wed Aug  6 15:37:05 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 6 Aug 2025 15:37:05 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <JwlyaSyHPSPel2niq664pBXjwVz1kTBRqSywfRIAyeg=.c4ae6b66-a080-4444-860d-f5dd42d478c0@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
 <KjPlEQ9zwpupdHu7iucmfe1BJ3ji4oru5gv0BEbYHX4=.9a7fb045-751b-462f-a15c-a45938e7a6d8@github.com>
 <Afs0oTEy81pox7-XQEFJK7MpDw0txr2mn49NnCPBYkY=.a477cd49-9182-48c3-b010-e806ead984bf@github.com>
 <JwlyaSyHPSPel2niq664pBXjwVz1kTBRqSywfRIAyeg=.c4ae6b66-a080-4444-860d-f5dd42d478c0@github.com>
Message-ID: <ioiYkMsEevC3kE1ie2V5rORoGtLaTL6gf2H1Ivhe8LU=.0261ea2e-2908-4353-b139-e5b130ec485b@github.com>

On Wed, 6 Aug 2025 15:10:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Missing service should be treated as error. If we want to match all services, it is better represented as "*". This may be considered for future enhancement if there is a demand.
>
> I thought about an option of using `*` wildcard too. We can do it in this iteration simply by replacing `*.algorithm` with `Cipher.algorithm`,  `KeyStore.algorithm`, `MessageDiges.algorithmt`,  `Signature.algorithm`.

But I think simply omitting a service name is a better solution because in such case we can check the algorithm against the whole `jdk.crypto.disabledAlgorithms` property in one call without specifying the service name:
`CryptoAlgorithmConstraints.permits(algo)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2257577015

From abarashev at openjdk.org  Wed Aug  6 15:40:09 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 6 Aug 2025 15:40:09 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v5]
In-Reply-To: <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>
Message-ID: <P0o-aPY360yS3Fh_BSTACZ22ilfiSEvMzp4mWEudUN8=.919818c0-ca61-451a-85ee-fc09d17a2c2b@github.com>

On Wed, 6 Aug 2025 05:39:56 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
>> 
>> A few implementation notes:
>> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
>> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
>> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
>> 
>> CSR will be filed once the review is wrapping up.
>> 
>> Thanks~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add a public static final constant for the property name.
>  - Address more review comments from Sean and Artur.

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

> 60:     }
> 61: 
> 62:     public static boolean permits(String service, String algo) {

I think in other places of our code we don't separate the service and the algo in 2 strings, those are being used as a single string. So this method's signature should be `public static boolean permits(String algo)` for consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2257585332

From abarashev at openjdk.org  Wed Aug  6 15:43:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 6 Aug 2025 15:43:08 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v5]
In-Reply-To: <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>
Message-ID: <RPz8c2lR7HoT8LTXLLydn2swiOtYL629n6wcRdyVdyM=.f0f1caa9-8709-4979-a552-8fc1e15d9448@github.com>

On Wed, 6 Aug 2025 05:39:56 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
>> 
>> A few implementation notes:
>> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
>> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
>> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
>> 
>> CSR will be filed once the review is wrapping up.
>> 
>> Thanks~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add a public static final constant for the property name.
>  - Address more review comments from Sean and Artur.

I don't see any unit test cases testing invalid service names, we should add those.

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

PR Comment: https://git.openjdk.org/jdk/pull/26377#issuecomment-3160674516

From valeriep at openjdk.org  Wed Aug  6 17:52:16 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 17:52:16 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v5]
In-Reply-To: <RPz8c2lR7HoT8LTXLLydn2swiOtYL629n6wcRdyVdyM=.f0f1caa9-8709-4979-a552-8fc1e15d9448@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>
 <RPz8c2lR7HoT8LTXLLydn2swiOtYL629n6wcRdyVdyM=.f0f1caa9-8709-4979-a552-8fc1e15d9448@github.com>
Message-ID: <6Yic_bNPXSoDyy3JeQUoucl_r4Vb9JXZMtcA9V7N93Q=.0ccbccee-cdf7-4cb3-844f-684dc70d28f2@github.com>

On Wed, 6 Aug 2025 15:40:40 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> I don't see any unit test cases testing invalid service names, we should add those.

Yes, I am working on one. Just want to get the source changes out first, so they get reviewed earlier.

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

PR Comment: https://git.openjdk.org/jdk/pull/26377#issuecomment-3161048075

From valeriep at openjdk.org  Wed Aug  6 18:12:21 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Aug 2025 18:12:21 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v5]
In-Reply-To: <P0o-aPY360yS3Fh_BSTACZ22ilfiSEvMzp4mWEudUN8=.919818c0-ca61-451a-85ee-fc09d17a2c2b@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>
 <P0o-aPY360yS3Fh_BSTACZ22ilfiSEvMzp4mWEudUN8=.919818c0-ca61-451a-85ee-fc09d17a2c2b@github.com>
Message-ID: <RuE3vuSjFhgMEQpAFCPljfe9drGCdZjYvOYvDLa3gEo=.75febd02-2ef3-410b-9f16-fa7286ab56a7@github.com>

On Wed, 6 Aug 2025 15:37:41 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add a public static final constant for the property name.
>>  - Address more review comments from Sean and Artur.
>
> src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 62:
> 
>> 60:     }
>> 61: 
>> 62:     public static boolean permits(String service, String algo) {
> 
> I think in other places of our code we don't separate the service and the algo in 2 strings, those are being used as a single string. So this method's signature should be `public static boolean permits(String algo)` for consistency.

I don't want the caller classes to have to do the `service` +"." + `algo` String concatenation. It's cleaner to provide 2 arguments. Given this `permits(...)` method is already very different from the other `permits(...)` methods in the super interface, I don't think it really matters. Or, I can rename the method to something like `isAllowed` if you prefer a different method name.

> src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 98:
> 
>> 96:                     service.equalsIgnoreCase("KeyStore") ||
>> 97:                     service.equalsIgnoreCase("MessageDigest") ||
>> 98:                     service.equalsIgnoreCase("Signature")) {
> 
> It will be a cleaner solution if we define a set of allowed services as a static class variable (all in upper/lower case) and then do `SET.contains(service.toUpper/toLower)`. We may also need such set of allowed services for other operations (like `*` wildcard substitution).

Sure, I didn't bother since there are only 4 services. But I can do that now also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2257916632
PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2257921194

From rriggs at openjdk.org  Wed Aug  6 18:52:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Aug 2025 18:52:16 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <baO09QrTXRZJB-pGp959QaSwgZcjzaFhA0g1idWFxsg=.7f016537-430c-41ff-bda7-3dd560ae458f@github.com>
Message-ID: <0_Cs4qRmBwmfZE8qrUNZaRCtUfWqarRBdrzZjGEZvLM=.9a0b66f9-9a12-4296-9c90-304080e72886@github.com>

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

>> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value).
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update NPE per roger review

A hotspot and 2 core-libs reviewers should have a chance to comment.

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

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

From rriggs at openjdk.org  Wed Aug  6 18:52:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Aug 2025 18:52:17 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <pOYre3BM8bk2MGRLph2dEW0u8XSC1BVM3_PaMBywEZY=.d893ba55-1f8c-4f50-9123-96200cb33367@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
 <canen3_Yq6vspRsDO_OBvX7bLmW3vL1v4cFb3tiI2g4=.54dd9223-9d28-44a1-9226-f096bc5443ee@github.com>
 <pEd2HoPSaXF2YFTsfN9OdGy5AbFo2pVPblVzqDCDeL0=.df678328-6541-4ffc-b1f2-becedb965351@github.com>
 <pOYre3BM8bk2MGRLph2dEW0u8XSC1BVM3_PaMBywEZY=.d893ba55-1f8c-4f50-9123-96200cb33367@github.com>
Message-ID: <QoxZIbp0af4jJQThb2DXF42UnDjGi8raPFnr4jcCZjw=.d9184e90-4c44-4dc0-9307-12e3cec7220a@github.com>

On Tue, 5 Aug 2025 15:01:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Don't add APIs without uses; it speculative and the API may not be what is really needed.
>
> Should I open a dependent PR to prove that this is exactly what we need to unblock [Objects::requireNonNull message enhancements](https://bugs.openjdk.org/browse/JDK-8233268)?

Please update the description to note this is a pre-requsite for:
[JDK-8233268](https://bugs.openjdk.org/browse/JDK-8233268) Improve integration of Objects.requireNonNull and JEP 358 Helpful NPE

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2257996201

From abarashev at openjdk.org  Wed Aug  6 19:25:19 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 6 Aug 2025 19:25:19 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v5]
In-Reply-To: <RuE3vuSjFhgMEQpAFCPljfe9drGCdZjYvOYvDLa3gEo=.75febd02-2ef3-410b-9f16-fa7286ab56a7@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <L38CT5RqyU8SErE7WF9IMyPlCs8U2npQcwWhepCqVZg=.0181f331-eca0-462d-963a-f78b23590842@github.com>
 <P0o-aPY360yS3Fh_BSTACZ22ilfiSEvMzp4mWEudUN8=.919818c0-ca61-451a-85ee-fc09d17a2c2b@github.com>
 <RuE3vuSjFhgMEQpAFCPljfe9drGCdZjYvOYvDLa3gEo=.75febd02-2ef3-410b-9f16-fa7286ab56a7@github.com>
Message-ID: <fdrJDhZK-ysTr8OKBQSnyY9Pt1jrsnmCqrULwmSO7TQ=.a5735d76-42d5-4035-8c48-6e543d356d80@github.com>

On Wed, 6 Aug 2025 18:07:13 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 62:
>> 
>>> 60:     }
>>> 61: 
>>> 62:     public static boolean permits(String service, String algo) {
>> 
>> I think in other places of our code we don't separate the service and the algo in 2 strings, those are being used as a single string. So this method's signature should be `public static boolean permits(String algo)` for consistency.
>
> I don't want the caller classes to have to do the `service` +"." + `algo` String concatenation. It's cleaner to provide 2 arguments. Given this `permits(...)` method is already very different from the other `permits(...)` methods in the super interface, I don't think it really matters. Or, I can rename the method to something like `isAllowed` if you prefer a different method name.

I see. It's not about method's name though, just a consistency and supporting `anyService` check. Alternatively we can accept null or `*` for a service name to check for all services.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2258068646

From valeriep at openjdk.org  Thu Aug  7 04:43:25 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Aug 2025 04:43:25 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v6]
In-Reply-To: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
Message-ID: <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>

> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
> 
> A few implementation notes:
> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
> 
> CSR will be filed once the review is wrapping up.
> 
> Thanks~
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments from Artur and added a regression test for
  invalid property values.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26377/files
  - new: https://git.openjdk.org/jdk/pull/26377/files/c9bf72f4..23b5464f

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

  Stats: 81 lines in 2 files changed: 66 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26377/head:pull/26377

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

From wxiao at openjdk.org  Thu Aug  7 15:38:37 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Thu, 7 Aug 2025 15:38:37 GMT
Subject: RFR: 8362268 : NPE thrown from SASL GSSAPI impl on Java 11+ when TLS
 is used with QOP auth-int against Active Directory
Message-ID: <G2uhTiWrGNg8zO_2QN3dD0pSFVJ7tPg-D34hQYijvIc=.bf1f03fa-9332-4079-a203-31ff4d07e780@github.com>

[webrev.zip](https://github.com/user-attachments/files/21517501/webrev.zip)
NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory.

When the exception is triggered, LDAP Connection will do "clean-up" operation and output stream get flushed and closed the context while GssKrb5Client is still wrapping the message and SaslOuput Stream is writing the content of the buffer; and at the time GSSContext is disposed and it is null. That's the reason to throw NPE.

1) Check if the context is null or not; then wrap the NPE. The change is done in GssKrb5Base.java

No test file is attached for this MR since it needs Sasl LDAP server with security setup. Attached webrev for the reference.

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

Commit messages:
 - revert the code
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8362268
 - revert javax.security.sasl.maxbuffer
 - Merge branch 'JDK-8362268' of https://github.com/weibxiao/jdk into JDK-8362268
 - added missing file
 - added missing file
 - 8362268 : NPE thrown from SASL GSSAPI impl on Java 11+ when TLS is used with QOP auth-int against Active Directory

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

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

From abarashev at openjdk.org  Thu Aug  7 17:46:23 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 7 Aug 2025 17:46:23 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v6]
In-Reply-To: <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>
Message-ID: <5nJQCgnkBJrah_RrM9hyM0WbwDja4HAz2c9886kSprI=.cd45b0d0-be37-4742-bdc7-de4777a6b8f6@github.com>

On Thu, 7 Aug 2025 04:43:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
>> 
>> A few implementation notes:
>> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
>> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
>> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
>> 
>> CSR will be filed once the review is wrapping up.
>> 
>> Thanks~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments from Artur and added a regression test for
>   invalid property values.

test/jdk/java/security/Security/SecurityPropFile/InvalidCryptoDisabledAlgos.java line 52:

> 50:             MessageDigest md = MessageDigest.getInstance("SHA-512");
> 51:             throw new RuntimeException("Should Fail!");
> 52:         } catch (ExceptionInInitializerError e) {

Nit: Consider using `runAndCheckException` from `/test/lib`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2261037530

From abarashev at openjdk.org  Thu Aug  7 17:56:20 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 7 Aug 2025 17:56:20 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v6]
In-Reply-To: <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>
Message-ID: <eSWTR5qyh__334_eeOGUYuB-2g_bLVFSAHnb__QbPIA=.6a5887a1-6e97-4416-86c6-a8f90d6cb111@github.com>

On Thu, 7 Aug 2025 04:43:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
>> 
>> A few implementation notes:
>> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
>> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
>> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
>> 
>> CSR will be filed once the review is wrapping up.
>> 
>> Thanks~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments from Artur and added a regression test for
>   invalid property values.

src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 99:

> 97:                 throw new IllegalArgumentException("Invalid entry: " + dk);
> 98:             }
> 99:             if (SUPPORTED_SERVICES.stream().anyMatch(e->e.equalsIgnoreCase

Nit: 
- Spaces around `->`
- Look up will be faster if we do `Set.contains` on upper-cased strings instead of iteration with `equalsIgnoreCase`. Although probably not noticeable with just 4 services we currently have.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2261054733

From abarashev at openjdk.org  Thu Aug  7 18:05:17 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 7 Aug 2025 18:05:17 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v6]
In-Reply-To: <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>
Message-ID: <hDppyVU9sBwf6vDl2WPdICLDI7yVlYEN0shhKQUCxg4=.7fe6ffef-adb6-4cc7-9105-9bff76f1d5aa@github.com>

On Thu, 7 Aug 2025 04:43:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
>> 
>> A few implementation notes:
>> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
>> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
>> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
>> 
>> CSR will be filed once the review is wrapping up.
>> 
>> Thanks~
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments from Artur and added a regression test for
>   invalid property values.

test/jdk/java/security/MessageDigest/TestDisabledAlgorithms.java line 29:

> 27:  * @summary Test JCE layer algorithm restriction
> 28:  * @run main/othervm TestDisabledAlgorithms MessageDigest.Sha-512 true
> 29:  * @run main/othervm TestDisabledAlgorithms MessageDigest.what false

Let's use differently mixed upper/lower cased versions of  `MessageDigest` word to test proper case-insensitive match. In current versions of the tests all service names match exactly the names defines in `CryptoAlgorithmConstraints`. For example:

- MessageDigest
- messaGedigesT
- MESSAGEdigest

Same for other services' tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2261071041

From valeriep at openjdk.org  Thu Aug  7 19:55:14 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Aug 2025 19:55:14 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v7]
In-Reply-To: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
Message-ID: <u5UXFmCiITLnFS46nlVA9hUH7kheGKeN9xtQ23w8EII=.54e3fe02-daf4-471e-8895-c62a0daad190@github.com>

> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
> 
> A few implementation notes:
> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
> 
> CSR will be filed once the review is wrapping up.
> 
> Thanks~
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Update the comment in java.security

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26377/files
  - new: https://git.openjdk.org/jdk/pull/26377/files/23b5464f..8df5f993

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

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

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

From valeriep at openjdk.org  Thu Aug  7 19:56:19 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Aug 2025 19:56:19 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v2]
In-Reply-To: <OBvLdBn3anv32cArBP_13O3opbint_Adk4-IkkmD6lk=.819c1dd6-1356-4282-86ae-e2b905a50a71@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <n3rThis-Gh-OViJsqanyON9fkg2flZzy_pSLozIqnBU=.49d548ec-8073-421f-854b-9e302fd707b7@github.com>
 <3RkK1-IRWRHq9o9wV1-RZtu7IBBvX54pH-5VZTh3c70=.033fe294-e6ec-4cf3-b1a7-8b70a3108db1@github.com>
 <OBvLdBn3anv32cArBP_13O3opbint_Adk4-IkkmD6lk=.819c1dd6-1356-4282-86ae-e2b905a50a71@github.com>
Message-ID: <i6RQxnTa22kcgCeZqdCw3M7xMa7RlLEOm6RVlKaZm_k=.0358d9d8-97b6-4c94-b217-8399b41dd5ad@github.com>

On Wed, 6 Aug 2025 03:04:27 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/conf/security/java.security line 801:
>> 
>>> 799: # its algorithm is the transformation string.
>>> 800: #
>>> 801: # Note: Entries with unsupported services will be ignored
>> 
>> Suggest: Services with unrecognized or unsupported algorithms will be ignored.
>
> Per the discussion regarding the throwing `IllegalArgumentException` for invalid entries, I will change this to 
> 
> # Note: IllegalArgumentException will be thrown if the property value contains
> # entries with invalid syntax or unsupported services.

Hmm, after adding the regression test, I updated the wording further to:

# Note: If the property value contains entries with invalid syntax or
# unsupported services at the time of checking, an ExceptionInInitializerError
# with a cause of IllegalArgumentException will be thrown.

as this matches better with what the caller observes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2261276455

From valeriep at openjdk.org  Thu Aug  7 20:18:14 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Aug 2025 20:18:14 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v6]
In-Reply-To: <5nJQCgnkBJrah_RrM9hyM0WbwDja4HAz2c9886kSprI=.cd45b0d0-be37-4742-bdc7-de4777a6b8f6@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>
 <5nJQCgnkBJrah_RrM9hyM0WbwDja4HAz2c9886kSprI=.cd45b0d0-be37-4742-bdc7-de4777a6b8f6@github.com>
Message-ID: <qs7sVdMYYRws04DjQvorhzTYpo0O1TFNJDCUONh53qs=.4daab6e6-92ec-435d-bbaf-2a3516cc71d2@github.com>

On Thu, 7 Aug 2025 17:43:53 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments from Artur and added a regression test for
>>   invalid property values.
>
> test/jdk/java/security/Security/SecurityPropFile/InvalidCryptoDisabledAlgos.java line 52:
> 
>> 50:             MessageDigest md = MessageDigest.getInstance("SHA-512");
>> 51:             throw new RuntimeException("Should Fail!");
>> 52:         } catch (ExceptionInInitializerError e) {
> 
> Nit: Consider using `runAndCheckException` from `/test/lib`

Yes, good suggestion, thanks~

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2261311950

From valeriep at openjdk.org  Thu Aug  7 20:30:15 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Aug 2025 20:30:15 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v6]
In-Reply-To: <eSWTR5qyh__334_eeOGUYuB-2g_bLVFSAHnb__QbPIA=.6a5887a1-6e97-4416-86c6-a8f90d6cb111@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>
 <eSWTR5qyh__334_eeOGUYuB-2g_bLVFSAHnb__QbPIA=.6a5887a1-6e97-4416-86c6-a8f90d6cb111@github.com>
Message-ID: <DV0XvVLuDf2OHT-eA94imislgIvY9a-q1buYEvKBZD4=.194912ca-5985-4fda-aae6-03b9b97efb38@github.com>

On Thu, 7 Aug 2025 17:53:21 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments from Artur and added a regression test for
>>   invalid property values.
>
> src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 99:
> 
>> 97:                 throw new IllegalArgumentException("Invalid entry: " + dk);
>> 98:             }
>> 99:             if (SUPPORTED_SERVICES.stream().anyMatch(e->e.equalsIgnoreCase
> 
> Nit: 
> - Spaces around `->`
> - Look up will be faster if we do `Set.contains` on upper-cased strings instead of iteration with `equalsIgnoreCase`. Although probably not noticeable with just 4 services we currently have.

Yes, I will add space around "->".
As for performance differences, the `Set,.contains`, approach will require an additional `toUpperCase()` call for every lookup. Or we can also use a `TreeSet` w/ case-insensitive ordering. Anyway, probably not difference when there are just 4 services?

> test/jdk/java/security/MessageDigest/TestDisabledAlgorithms.java line 29:
> 
>> 27:  * @summary Test JCE layer algorithm restriction
>> 28:  * @run main/othervm TestDisabledAlgorithms MessageDigest.Sha-512 true
>> 29:  * @run main/othervm TestDisabledAlgorithms MessageDigest.what false
> 
> Let's use differently mixed upper/lower cased versions of  `MessageDigest` word to test proper case-insensitive match. In current versions of the tests all service names match exactly the names defines in `CryptoAlgorithmConstraints`. For example:
> 
> - MessageDigest
> - messaGedigesT
> - MESSAGEdigest
> 
> Same for other services' tests.

Good suggestion, will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2261329773
PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2261331035

From abarashev at openjdk.org  Thu Aug  7 20:50:14 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 7 Aug 2025 20:50:14 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v6]
In-Reply-To: <DV0XvVLuDf2OHT-eA94imislgIvY9a-q1buYEvKBZD4=.194912ca-5985-4fda-aae6-03b9b97efb38@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <lkw5XNDAzm-RGe0nnvO_vi6j2S6kDI49C58s1OLRc0k=.fed4dd52-2def-442a-a6c2-f0e34982b4b1@github.com>
 <eSWTR5qyh__334_eeOGUYuB-2g_bLVFSAHnb__QbPIA=.6a5887a1-6e97-4416-86c6-a8f90d6cb111@github.com>
 <DV0XvVLuDf2OHT-eA94imislgIvY9a-q1buYEvKBZD4=.194912ca-5985-4fda-aae6-03b9b97efb38@github.com>
Message-ID: <zu71IbeWcrZg3ePvMUilFbULmsnW0yIKJI8ubjAnotU=.47bc68d7-7f24-4db1-ad32-3b437a9fc1fe@github.com>

On Thu, 7 Aug 2025 20:26:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java line 99:
>> 
>>> 97:                 throw new IllegalArgumentException("Invalid entry: " + dk);
>>> 98:             }
>>> 99:             if (SUPPORTED_SERVICES.stream().anyMatch(e->e.equalsIgnoreCase
>> 
>> Nit: 
>> - Spaces around `->`
>> - Look up will be faster if we do `Set.contains` on upper-cased strings instead of iteration with `equalsIgnoreCase`. Although probably not noticeable with just 4 services we currently have.
>
> Yes, I will add space around "->".
> As for performance differences, the `Set,.contains`, approach will require an additional `toUpperCase()` call for every lookup. Or we can also use a `TreeSet` w/ case-insensitive ordering. Anyway, probably not difference when there are just 4 services?

Yes, if we don't expect a large number of services it's a moot point, especially since current 4 services all start with different letters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2261366192

From valeriep at openjdk.org  Fri Aug  8 01:37:14 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 8 Aug 2025 01:37:14 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <ioiYkMsEevC3kE1ie2V5rORoGtLaTL6gf2H1Ivhe8LU=.0261ea2e-2908-4353-b139-e5b130ec485b@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
 <KjPlEQ9zwpupdHu7iucmfe1BJ3ji4oru5gv0BEbYHX4=.9a7fb045-751b-462f-a15c-a45938e7a6d8@github.com>
 <Afs0oTEy81pox7-XQEFJK7MpDw0txr2mn49NnCPBYkY=.a477cd49-9182-48c3-b010-e806ead984bf@github.com>
 <JwlyaSyHPSPel2niq664pBXjwVz1kTBRqSywfRIAyeg=.c4ae6b66-a080-4444-860d-f5dd42d478c0@github.com>
 <ioiYkMsEevC3kE1ie2V5rORoGtLaTL6gf2H1Ivhe8LU=.0261ea2e-2908-4353-b139-e5b130ec485b@github.com>
Message-ID: <Oxm1N90hF5C-yyb6q3arB3nb59TTQ9xaVRFIaLmJ-Yw=.9994a758-6617-491c-ada5-42eddd8d99cb@github.com>

On Wed, 6 Aug 2025 15:34:11 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> I thought about an option of using `*` wildcard too. We can do it in this iteration simply by replacing `*.algorithm` with `Cipher.algorithm`,  `KeyStore.algorithm`, `MessageDiges.algorithmt`,  `Signature.algorithm`.
>
> But I think simply omitting a service name is a better solution because in such case we can check the algorithm against the whole `jdk.crypto.disabledAlgorithms` property in one call without specifying the service name:
> `CryptoAlgorithmConstraints.permits(algo)`

Well, with the current list of 4 supported services, they don't generally share the algorithm names. Thus, I don't see a lot of sense of doing this. Personally, I'd view omitting of service as an oversight. Not sure how commonly used it is. If there is no strong need for supporting wildcard, then I'd not do it at least for this iteration. This is my personal preference. If there are strong reasons and usage scenarios driving wildcard support, then I am open for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2261752951

From jjiang at openjdk.org  Fri Aug  8 02:31:15 2025
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 8 Aug 2025 02:31:15 GMT
Subject: Integrated: 8364597: Replace THL A29 Limited with Tencent
In-Reply-To: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
References: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
Message-ID: <lUxnGf2cVXWfHR38WmZQVPwfzfBnjtOcc2Re_omkeGw=.c64c63b7-e7dd-48e1-b6f7-f0a1ebefaf56@github.com>

On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `THL A29 Limited` was a `Tencent` company but was dissolved.
> So, the copyright notes just use `Tencent` directly.

This pull request has now been integrated.

Changeset: 4c9eadda
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c9eaddaef83c6ba30e27ae3e0d16caeeec206cb
Stats:     67 lines in 58 files changed: 0 ins; 9 del; 58 mod

8364597: Replace THL A29 Limited with Tencent

Reviewed-by: jiefu

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

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

From abarashev at openjdk.org  Fri Aug  8 12:13:22 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 8 Aug 2025 12:13:22 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v4]
In-Reply-To: <Oxm1N90hF5C-yyb6q3arB3nb59TTQ9xaVRFIaLmJ-Yw=.9994a758-6617-491c-ada5-42eddd8d99cb@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
 <RvXHZ3hDwdDt079QZGfQi_ognVG69no4DH09YKaW_cQ=.4fab3d91-3502-48b2-9b04-640068dbe7e1@github.com>
 <KjPlEQ9zwpupdHu7iucmfe1BJ3ji4oru5gv0BEbYHX4=.9a7fb045-751b-462f-a15c-a45938e7a6d8@github.com>
 <Afs0oTEy81pox7-XQEFJK7MpDw0txr2mn49NnCPBYkY=.a477cd49-9182-48c3-b010-e806ead984bf@github.com>
 <JwlyaSyHPSPel2niq664pBXjwVz1kTBRqSywfRIAyeg=.c4ae6b66-a080-4444-860d-f5dd42d478c0@github.com>
 <ioiYkMsEevC3kE1ie2V5rORoGtLaTL6gf2H1Ivhe8LU=.0261ea2e-2908-4353-b139-e5b130ec485b@github.com>
 <Oxm1N90hF5C-yyb6q3arB3nb59TTQ9xaVRFIaLmJ-Yw=.9994a758-6617-491c-ada5-42eddd8d99cb@github.com>
Message-ID: <4lWuqDVDQxSFD8VUIEc5Vrls7wAV1lbXak1ghctGfjA=.6ab556b1-9fa8-48b6-aedb-06b4b383c898@github.com>

On Fri, 8 Aug 2025 01:34:52 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> But I think simply omitting a service name is a better solution because in such case we can check the algorithm against the whole `jdk.crypto.disabledAlgorithms` property in one call without specifying the service name:
>> `CryptoAlgorithmConstraints.permits(algo)`
>
> Well, with the current list of 4 supported services, they don't generally share the algorithm names. Thus, I don't see a lot of sense of doing this. Personally, I'd view omitting of service as an oversight. Not sure how commonly used it is. If there is no strong need for supporting wildcard, then I'd not do it at least for this iteration. This is my personal preference. If there are strong reasons and usage scenarios driving wildcard support, then I am open for it.

I see, makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26377#discussion_r2262799299

From vyazici at openjdk.org  Fri Aug  8 13:38:31 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 13:38:31 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v2]
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <6LY-pGXEYGVLE2sAYTG8175PvnICXFoHw4velrtLk8E=.dc8a5a32-5c4f-44fa-a281-c5516a22b4bb@github.com>

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

Volkan Yazici 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:

 - Group `String` methods by `doReplace` argument
 - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
 - Replace `requireNonNull` with implicit null checks
 - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
 - Improve docs of touched methods and add NPE checks
 - Convert IAE-throwing methods into CCE-throwing ones
 - Rename `JavaLangAccess::*NoRepl` methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26413/files
  - new: https://git.openjdk.org/jdk/pull/26413/files/5f555a68..1fb8582e

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

  Stats: 18798 lines in 552 files changed: 11544 ins; 5896 del; 1358 mod
  Patch: https://git.openjdk.org/jdk/pull/26413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26413/head:pull/26413

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

From vyazici at openjdk.org  Fri Aug  8 13:51:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 13:51:10 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <WObG1v-uiiW5td-qzSA06iRjh3U8fzfnKqX4DZf3gLE=.f63ef6b7-0e32-4345-8bec-24e7925b2b20@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <WObG1v-uiiW5td-qzSA06iRjh3U8fzfnKqX4DZf3gLE=.f63ef6b7-0e32-4345-8bec-24e7925b2b20@github.com>
Message-ID: <4vNV2kY5DmMEoWtuq40MzP2BnudJysIwgcjxJpldxBY=.735cf122-f7bb-4d4c-a2ff-7d49cf86d0bf@github.com>

On Tue, 29 Jul 2025 13:25:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> If CCE should have a constructor with a message, it can be added if you have a clear idea how it would be used.

Motivated by @RogerRiggs inquiries, and @AlanBateman's below remark,

> Another high level comment from a first read is that it feels like there are two forms needed. One form is REPLACE action and doesn't throw. The other is REPORT action and throws CharacterCodingException.

grouped `String` methods by `doReplace` argument in 1fb8582e3f9. There are several `String` methods of the following form:

    private static byte[] encode8859_1(..., boolean doReplace) {
        // ...
        if (!doReplace) {
            throwUnmappable(sp);
        }
        // ...
     }

We want to make `doReplace = false` case visible in the function footprint, and this resulted in:

    private static byte[] encode8859_1(..., boolean doReplace) throws CCE { ... }

Though this propagates the checked `CCE` even for `doReplace = true`. To avoid this, I've grouped methods by `doReplace` argument into two:

    private static byte[] encode8859_1(...) { ... }
    private static byte[] encode8859_1NoReplacement(...) throws CCE { ... }

As a result,

1. `doReplace = true` call-sites invoke `encode8859_1()`, replacement *will* occur, and there is no checked `CCE` thrown
2. `doReplace = false` call-sites invoke `encode8859_1NoReplacement()`, replacement will *not* occur, and `CCE` needs to be handled

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

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3167985180

From liach at openjdk.org  Fri Aug  8 17:32:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:32:17 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v2]
In-Reply-To: <6LY-pGXEYGVLE2sAYTG8175PvnICXFoHw4velrtLk8E=.dc8a5a32-5c4f-44fa-a281-c5516a22b4bb@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <6LY-pGXEYGVLE2sAYTG8175PvnICXFoHw4velrtLk8E=.dc8a5a32-5c4f-44fa-a281-c5516a22b4bb@github.com>
Message-ID: <GYMlMXwoAVU4hBdebtau5SDWtPDT5MLeQ92r_2Qio8k=.e439853e-faa8-470a-afdc-0c8c5644d083@github.com>

On Fri, 8 Aug 2025 13:38:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> Volkan Yazici 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:
> 
>  - Group `String` methods by `doReplace` argument
>  - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
>  - Replace `requireNonNull` with implicit null checks
>  - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
>  - Improve docs of touched methods and add NPE checks
>  - Convert IAE-throwing methods into CCE-throwing ones
>  - Rename `JavaLangAccess::*NoRepl` methods

src/java.base/share/classes/java/lang/String.java line 855:

> 853:         int len = val.length >> coder;  // assume LATIN1=0/UTF16=1;
> 854:         int en = scale(len, ce.maxBytesPerChar());
> 855:         // Fast-path with `ArrayEncoder` implies replacement.

I recommend documenting this on ArrayEncoder instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2263641162

From valeriep at openjdk.org  Fri Aug  8 18:42:08 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 8 Aug 2025 18:42:08 GMT
Subject: RFR: 8244336: Restrict algorithms at JCE layer [v8]
In-Reply-To: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
References: <9C0ZA3Rj427GMHFsTHsVNxahdWfdKL_tTXFuGvLeEjU=.e3f18f54-7f28-4c7e-8e01-bb807f99e8e2@github.com>
Message-ID: <S51DMTzcXCBSleQoe_lVUXL0CJEXzAPrwdAyF6iPtKA=.e99ade49-c76a-42ec-9420-042ecb07cb14@github.com>

> This enhancement introduces a new security property "jdk.crypto.disabledAlgorithms" which can be leveraged to disable algorithms for JCE/JCA crypto services. For now, only Cipher, KeyStore, MessageDigest, and Signature services support this new security property. The support can be expanded later to cover more services if needed. Note that this security property is meant to disable algorithms irrespective of providers. If the algorithm is found to be disabled, it will be rejected before reaching out to provider(s) for the corresponding implementation(s).
> 
> A few implementation notes:
> 1) The specified security property value is lazily loaded and all changes after it's been loaded are ignored. Invalid entries, e.g. wrong syntax, are ignored and removed. The algorithm name check is case-insensitive. If a disabled algorithm is known to has an object identifier (oid) by JDK, this oid and its aliases is also added to the disabled services.
> 2) The algorithm name checking impl is based on the sun.security.util.AlgorithmConstraints class, but without the decomposing and different constraints.
> 3) The hardwiring of NONEwithRSA signature to RSA/ECB/PKCS1Padding cipher in java.security.Signature class is removed. Instead, this is moved to the provider level, i.e. SunJCE and SunPKCS11 provider are changed to claim the NONEwithRSA signature support. Disabling one will not affect the other. 
> 
> CSR will be filed once the review is wrapping up.
> 
> Thanks~
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments from Artur and updated tests to leverage Utils.runAndCheckException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26377/files
  - new: https://git.openjdk.org/jdk/pull/26377/files/8df5f993..77c98b6c

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

  Stats: 174 lines in 7 files changed: 50 ins; 57 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/26377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26377/head:pull/26377

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

From liach at openjdk.org  Fri Aug  8 18:54:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 18:54:13 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <7f8HeMWpFC1Y1JWDmdi5lMU0kgT9z-yQFLDOXuSUucU=.40edcd18-9311-41a1-b007-81bf4a11bd7d@github.com>
Message-ID: <TKZUMJoAPB3DQvLV_lw9olioidoxBtQA4sNDC6DKZgA=.65005d16-127a-4d42-b154-648004f0833b@github.com>

On Tue, 5 Aug 2025 14:11:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update NPE per roger review
>
> src/java.base/share/classes/java/lang/NullPointerException.java line 142:
> 
>> 140:     }
>> 141: 
>> 142:     // Methods below must be called in object monitor
> 
> This kind of warning should be on every method declaration, if separated from the method doc, it can be overlooked by future maintainers.

Done.

> src/java.base/share/classes/java/lang/NullPointerException.java line 146:
> 
>> 144:     private void ensureMessageComputed() {
>> 145:         if ((extendedMessageState & (MESSAGE_COMPUTED | CONSTRUCTOR_FINISHED)) == CONSTRUCTOR_FINISHED) {
>> 146:             int stackOffset = (extendedMessageState & STACK_OFFSET_MASK) >> STACK_OFFSET_SHIFT;
> 
> This would be more readable if private utility methods were added that encapsulated the shift and masking, both for extraction and construction.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2263783470
PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2263782482

From liach at openjdk.org  Fri Aug  8 18:54:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 18:54:14 GMT
Subject: RFR: 8364588: Export the NPE backtracking functionality to general
 null-checking APIs [v4]
In-Reply-To: <DpevExdDMh5yWZXGeYw_IHBv9l0sxT-x3tn0DeAvh7M=.e41619ed-238a-4559-ad10-ae248b4e9ba9@github.com>
References: <qR0DC0gLxv9GwgyKNXq3Rz-ER-DpLq3_4k6EfOWNfSc=.df319ee0-cf45-47a5-8154-1dc41885b1c9@github.com>
 <DpevExdDMh5yWZXGeYw_IHBv9l0sxT-x3tn0DeAvh7M=.e41619ed-238a-4559-ad10-ae248b4e9ba9@github.com>
Message-ID: <pKJv-ubY7vjR26WI2q9WrYYKfVtAjEanq_nuBRh_Vcw=.2cdd722d-45da-42e1-b1a0-dc3208dd7e4a@github.com>

On Tue, 5 Aug 2025 10:14:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update NPE per roger review
>
> src/java.base/share/classes/java/lang/NullPointerException.java line 159:
> 
>> 157:     ///    configurations to trace how a particular argument, which turns out to
>> 158:     ///    be `null`, was evaluated.
>> 159:     /// 2. `searchSlot < 0`, stack offset is 0 (a call to the nullary constructor)
> 
> Can `searchSlot == -1` here?

I think the code handles all < 0 cases so using that is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2263781125