From xuelei at openjdk.org  Mon May  1 07:41:23 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 1 May 2023 07:41:23 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v3]
In-Reply-To: <BLTahgtHIDyiZd-M7SBz_jdBC6xByNj5boeO_QRB6T8=.617c647f-97ee-4690-b7a3-aee5c96c2835@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <BLTahgtHIDyiZd-M7SBz_jdBC6xByNj5boeO_QRB6T8=.617c647f-97ee-4690-b7a3-aee5c96c2835@github.com>
Message-ID: <Z6WIpNXlgJSQ7_-Bue1XRjpsrpPeSWnNN0xNRKaRRlo=.ed213aff-e920-4d55-a612-f6012f8fc399@github.com>

On Fri, 28 Apr 2023 19:15:59 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
>   
>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

There are two blocks called CertificateAuthoritiesSpec.getAuthorities(). Another call is in the CRCertificateAuthoritiesConsumer inner class. Did you check if both should be updated?  Or Is  it possible to update the getAuthorities() implementation directly?

There are similar code in CertificateRequest.  Did you have a chance to look at if it is impacted as well?

Basically, the issue is caused by the X500Principal constructor with DER bytes.  It may be good to check the call to the constructor and handle the IAE accordingly as well, for example in the CertificateAuthoritiesSpec.toString() method.

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

Changes requested by xuelei (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1407415460

From mullan at openjdk.org  Mon May  1 15:37:54 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 May 2023 15:37:54 GMT
Subject: RFR: 8305963: Typo in java.security.Security.getProperty
In-Reply-To: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
References: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
Message-ID: <vJJgtLX6hZmBDgYzkRlPv4P9TPSKCVKCeoTaHDTvC7A=.4fa86620-4109-4efc-919d-97793c29ac68@github.com>

On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Fix type-o and update returns message.

src/java.base/share/classes/java/security/Security.java line 705:

> 703:      * @param key the key of the property being retrieved.
> 704:      *
> 705:      * @return the string value of the security property, or null if there

I don't think saying "string" is necessary - since this method can only return a String.
Put "null" in code syntax: {@code null}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13729#discussion_r1181655614

From mullan at openjdk.org  Mon May  1 17:54:52 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 May 2023 17:54:52 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v3]
In-Reply-To: <BLTahgtHIDyiZd-M7SBz_jdBC6xByNj5boeO_QRB6T8=.617c647f-97ee-4690-b7a3-aee5c96c2835@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <BLTahgtHIDyiZd-M7SBz_jdBC6xByNj5boeO_QRB6T8=.617c647f-97ee-4690-b7a3-aee5c96c2835@github.com>
Message-ID: <Jxs-SyDFNqFak4fyG-zaJ2gpIB1GkkF8kZH4qOdTzt8=.15a8d053-c082-4a1f-ae4d-3b5b9b6dcaed@github.com>

On Fri, 28 Apr 2023 19:15:59 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
>   
>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

Yes, I think we should check other calls in the TLS code to `new X500Principal()` that take the encoded bytes from the network to see if similar changes are needed.

I would also pass the cause to the `fatal()` method as this will provide additional information as to the reason of the parsing failure for debugging purposes.

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

PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1529997195

From duke at openjdk.org  Mon May  1 17:55:59 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Mon, 1 May 2023 17:55:59 GMT
Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling
 with NullPointerException
Message-ID: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>

In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods.

Thanks

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

Commit messages:
 - 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling with NullPointerException

Changes: https://git.openjdk.org/jdk/pull/13742/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13742&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290005
  Stats: 82 lines in 3 files changed: 51 ins; 20 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13742/head:pull/13742

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

From mullan at openjdk.org  Mon May  1 18:30:18 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 1 May 2023 18:30:18 GMT
Subject: RFR: 8304760: Add 2 Microsoft TLS roots
In-Reply-To: <7w4HxqhXN-jl_Yv-a0ga7m45P-FxMsscFvZyyn_UVck=.66b957f3-3ce8-4ba2-b8dc-b2da1e137144@github.com>
References: <7w4HxqhXN-jl_Yv-a0ga7m45P-FxMsscFvZyyn_UVck=.66b957f3-3ce8-4ba2-b8dc-b2da1e137144@github.com>
Message-ID: <pEunssLm7LwjldEBsnqHBVQgO8Rq5qQsfTk_tcS4prw=.7a0e295d-b15a-4611-bfe9-8fb77b3b16ff@github.com>

On Fri, 28 Apr 2023 19:04:20 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add two new TLS root certificates from Microsoft. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> The release-note is at [JDK-8307129](https://bugs.openjdk.org/browse/JDK-8307129)

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13726#pullrequestreview-1407896625

From rhalade at openjdk.org  Mon May  1 18:30:26 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Mon, 1 May 2023 18:30:26 GMT
Subject: Integrated: 8304760: Add 2 Microsoft TLS roots
In-Reply-To: <7w4HxqhXN-jl_Yv-a0ga7m45P-FxMsscFvZyyn_UVck=.66b957f3-3ce8-4ba2-b8dc-b2da1e137144@github.com>
References: <7w4HxqhXN-jl_Yv-a0ga7m45P-FxMsscFvZyyn_UVck=.66b957f3-3ce8-4ba2-b8dc-b2da1e137144@github.com>
Message-ID: <bts7n9kL5sXXuHVSoFT3cZ5KWOtPW2UWqAv7m0-ibjE=.8259a2d2-3c14-4a14-8ad5-5ecb0516ac9d@github.com>

On Fri, 28 Apr 2023 19:04:20 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> This PR is to add two new TLS root certificates from Microsoft. This CA has gone through https://www.oracle.com/java/technologies/javase/carootcertsprogram.html process.
> 
> The release-note is at [JDK-8307129](https://bugs.openjdk.org/browse/JDK-8307129)

This pull request has now been integrated.

Changeset: c7e1df83
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7e1df832837c2f19629cf0d5a5d3e65142ac208
Stats:     417 lines in 4 files changed: 414 ins; 0 del; 3 mod

8304760: Add 2 Microsoft TLS roots

Reviewed-by: mullan

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

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

From cslucas at openjdk.org  Mon May  1 18:41:26 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 1 May 2023 18:41:26 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v11]
In-Reply-To: <6I1KVkFSekhMTTDq6nXQNoKPE96bycERRtsPrTnZZvU=.c1933f7f-e659-4e22-93a3-e7fbbcdf53a1@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <6I1KVkFSekhMTTDq6nXQNoKPE96bycERRtsPrTnZZvU=.c1933f7f-e659-4e22-93a3-e7fbbcdf53a1@github.com>
Message-ID: <YI1BguYjOsPpRK9r2uYw6-tI7UNcI7z9U4a_VqlR0g0=.92e412b6-bf48-43f2-96b5-72415087c862@github.com>

On Wed, 26 Apr 2023 17:28:53 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address part of PR review 4 & fix a bug setting only_candidate

I have an update to this PR to make it possible to scalar replace allocations when the Phi is used in a CmpP (not for all cases). Is there any objection to me pushing these changes? I.e., will it complicate any ongoing review?

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1530047937

From cslucas at openjdk.org  Mon May  1 18:41:33 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 1 May 2023 18:41:33 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v10]
In-Reply-To: <LXuwj-aEpYq04Oyfa1Jt8D-slKC_xuQHapBO4xAeyv4=.d40c82a5-dda1-4370-9448-6c9da5075fe6@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <iGZ2Wdc6L3p5cys_sZxdZslylpQnF5q_zMk8q3uO-ro=.88cd8f67-17dc-4435-890a-b69d64059173@github.com>
 <hIoa1Z7p8xL1ZsJtyPm6795tNohDHS1RngYI3RcxXlk=.534b69a9-1d47-455c-a66f-72035e1c3e81@github.com>
 <O0V74R5bmBdXS3Notd8gBpwIK60vyHrmA3h6KM-HyJg=.365896ca-6010-44b5-8bc4-3505e5f53c83@github.com>
 <EoDfvRDKOpQGQTjwaPlPuISodyVu1pkKf6VUzbGtLlk=.7ea2b344-49d3-444a-b9a0-5f31e8d48ba2@github.com>
 <LXuwj-aEpYq04Oyfa1Jt8D-slKC_xuQHapBO4xAeyv4=.d40c82a5-dda1-4370-9448-6c9da5075fe6@github.com>
Message-ID: <RSVZpcqMZt84JpBD3NKAe3FnWYeaPQoQqyIwIMxDCok=.2229827b-12ba-401a-b5b4-064cde23d64e@github.com>

On Thu, 27 Apr 2023 23:36:06 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Can `ObjectCandidateValue` be a wrapper around a `ObjectAllocationValue`?
>> 
>> It does make sense to separate `ObjectMergeValue` and `ObjectValue`.
>
> I need to to study the code in more details. Seems like I'm missing something important here.

@iwanowww - how can I make it easier for you to review? Thanks for your comments so far.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1181781323

From valeriep at openjdk.org  Mon May  1 19:55:38 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 1 May 2023 19:55:38 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
Message-ID: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>

Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?

The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.

Thanks,
Valerie

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

Commit messages:
 - JDK-8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries

Changes: https://git.openjdk.org/jdk/pull/13743/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13743&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301154
  Stats: 405 lines in 7 files changed: 327 ins; 45 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/13743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13743/head:pull/13743

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

From cslucas at openjdk.org  Mon May  1 20:20:51 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 1 May 2023 20:20:51 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v12]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>

> Can I please get reviews for this PR? 
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
> 
> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges.
> 
> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
 - Address part of PR review 4 & fix a bug setting only_candidate
 - Catching up with master
   
   Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
 - Fix tests. Remember previous reducible Phis.
 - Address PR review 3. Some comments and be able to abort compilation.
 - Merge with Master
 - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.
 - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
 - Add support for SR'ing some inputs of merges used for field loads
 - Fix some typos and do some small refactorings.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1

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

Changes: https://git.openjdk.org/jdk/pull/12897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=11
  Stats: 2250 lines in 26 files changed: 1990 ins; 108 del; 152 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897

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

From valeriep at openjdk.org  Mon May  1 21:24:21 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 1 May 2023 21:24:21 GMT
Subject: RFR: 8305963: Typo in java.security.Security.getProperty
In-Reply-To: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
References: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
Message-ID: <BpUApJ_et3xzx5MHbvfaPkUw_AGGyAa7THLDNbd-yWM=.7b6a1153-86cf-4c08-a8da-c231145a0433@github.com>

On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Fix type-o and update returns message.

src/java.base/share/classes/java/security/Security.java line 2:

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

Seems incorrect to have 3 copyright years.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13729#discussion_r1181902336

From wetmore at openjdk.org  Tue May  2 00:26:16 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 2 May 2023 00:26:16 GMT
Subject: RFR: 8305963: Typo in java.security.Security.getProperty
In-Reply-To: <BpUApJ_et3xzx5MHbvfaPkUw_AGGyAa7THLDNbd-yWM=.7b6a1153-86cf-4c08-a8da-c231145a0433@github.com>
References: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
 <BpUApJ_et3xzx5MHbvfaPkUw_AGGyAa7THLDNbd-yWM=.7b6a1153-86cf-4c08-a8da-c231145a0433@github.com>
Message-ID: <FAUpA-1yZy33a_57ny-8GJZYKoCgkCByD4jOSkTyxps=.892afd8c-1d7a-4e3f-aeac-793513b9506f@github.com>

On Mon, 1 May 2023 21:21:15 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Fix type-o and update returns message.
>
> src/java.base/share/classes/java/security/Security.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1996, 2022, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Seems incorrect to have 3 copyright years.

Correct, only the beginning and current year.  `1996, 2023, Oracle...`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13729#discussion_r1181986205

From duke at openjdk.org  Tue May  2 12:42:23 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 2 May 2023 12:42:23 GMT
Subject: RFR: 8306014: Update javax.net.ssl TLS tests to use
 SSLContextTemplate or SSLEngineTemplate
In-Reply-To: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com>
References: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com>
Message-ID: <5bVEilLvrpWw22GYRX_9FBWdhk3tTbh4MGF_h-F5e-Q=.59ccfe4d-6b3b-4e2e-b41d-00d1aeac6b3c@github.com>

On Mon, 17 Apr 2023 13:25:53 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> I refactored tests in the test/jdk/javax/net/ssl directories to use the test template classes.

Could someone please review this PR? This directly related to https://github.com/openjdk/jdk/pull/13495 as well. 

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/13494#issuecomment-1531407356

From dfuchs at openjdk.org  Tue May  2 13:01:21 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 May 2023 13:01:21 GMT
Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling
 with NullPointerException
In-Reply-To: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
References: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
Message-ID: <5kB-OiJcwWcZcEZ209M3HwTsuychO6nWIrTCy5i1SQ0=.194f00b0-419b-4b2c-adb8-32900d2afcc1@github.com>

On Mon, 1 May 2023 17:39:02 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods.
> 
> Thanks

src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 767:

> 765:             if (context != null && // PRE or POST handshake
> 766:                     !conContext.handshakeContext.taskDelegated &&
> 767:                     !conContext.handshakeContext.delegatedActions.isEmpty()) {

Shouldn't you replace `conContext.handshakeContext` with `context` in those two lines as well?

src/java.base/share/classes/sun/security/ssl/TransportContext.java line 461:

> 459:         handshakeCtxLock.lock();
> 460:         handshakeContext = null;
> 461:         handshakeCtxLock.unlock();

The usual pattern is to use try { } finally { } with locks (even though in this particular case I don't see how the assignment would throw) - but if more things need to be done in the future here then at least the try { } finally { } will be in place.

Suggestion:

        handshakeCtxLock.lock();
        try {
            handshakeContext = null;
        } finally {
            handshakeCtxLock.unlock();
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182510718
PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182510815

From xuelei at openjdk.org  Tue May  2 13:46:21 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 2 May 2023 13:46:21 GMT
Subject: RFR: 8306014: Update javax.net.ssl TLS tests to use
 SSLContextTemplate or SSLEngineTemplate
In-Reply-To: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com>
References: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com>
Message-ID: <rV1VfoNRfehn8GpkEHtY34L6dR3XTIIRznTo1Es0Jzo=.e0f136ed-a29f-469d-bf21-086cce8359df@github.com>

On Mon, 17 Apr 2023 13:25:53 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> I refactored tests in the test/jdk/javax/net/ssl directories to use the test template classes.

Looks good to me.

The checks are not fully passed.  Please double check if the failures are related to this update.

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

Marked as reviewed by xuelei (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13494#pullrequestreview-1409133989
PR Comment: https://git.openjdk.org/jdk/pull/13494#issuecomment-1531504915

From duke at openjdk.org  Tue May  2 13:55:18 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 2 May 2023 13:55:18 GMT
Subject: RFR: 8306014: Update javax.net.ssl TLS tests to use
 SSLContextTemplate or SSLEngineTemplate
In-Reply-To: <rV1VfoNRfehn8GpkEHtY34L6dR3XTIIRznTo1Es0Jzo=.e0f136ed-a29f-469d-bf21-086cce8359df@github.com>
References: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com>
 <rV1VfoNRfehn8GpkEHtY34L6dR3XTIIRznTo1Es0Jzo=.e0f136ed-a29f-469d-bf21-086cce8359df@github.com>
Message-ID: <AWOmj2JKuFujSc551uplBEf9gTzftjZR_dygk2h5QSY=.f20be34a-d0be-4254-8878-e76cfcdc9d6e@github.com>

On Tue, 2 May 2023 13:43:52 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> The checks are not fully passed. Please double check if the failures are related to this update.

They are unrelated to these changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/13494#issuecomment-1531517933

From duke at openjdk.org  Tue May  2 14:31:38 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 2 May 2023 14:31:38 GMT
Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling
 with NullPointerException [v2]
In-Reply-To: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
References: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
Message-ID: <-2C5OXMu_wztFlkIwH9UPyUpLaOZMVycbBtmSxwJdGs=.c7858621-fc8d-4d2c-8428-37838c9f65d5@github.com>

> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods.
> 
> Thanks

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  using try/finally in terminateHandshakeContext and using local context variable in all places it should be

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13742/files
  - new: https://git.openjdk.org/jdk/pull/13742/files/fe2604aa..ce88caa0

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

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

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

From duke at openjdk.org  Tue May  2 14:31:40 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Tue, 2 May 2023 14:31:40 GMT
Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling
 with NullPointerException [v2]
In-Reply-To: <5kB-OiJcwWcZcEZ209M3HwTsuychO6nWIrTCy5i1SQ0=.194f00b0-419b-4b2c-adb8-32900d2afcc1@github.com>
References: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
 <5kB-OiJcwWcZcEZ209M3HwTsuychO6nWIrTCy5i1SQ0=.194f00b0-419b-4b2c-adb8-32900d2afcc1@github.com>
Message-ID: <QRZNGQDqcNprZE1vSTyKkOl60lmP5_jIFrsMcdrjqQk=.b1218111-12a5-48d8-be3a-1cdc84c0c2a1@github.com>

On Tue, 2 May 2023 12:56:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   using try/finally in terminateHandshakeContext and using local context variable in all places it should be
>
> src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 767:
> 
>> 765:             if (context != null && // PRE or POST handshake
>> 766:                     !conContext.handshakeContext.taskDelegated &&
>> 767:                     !conContext.handshakeContext.delegatedActions.isEmpty()) {
> 
> Shouldn't you replace `conContext.handshakeContext` with `context` in those two lines as well?

Yes, I definitely should have done that. Thanks.

> src/java.base/share/classes/sun/security/ssl/TransportContext.java line 461:
> 
>> 459:         handshakeCtxLock.lock();
>> 460:         handshakeContext = null;
>> 461:         handshakeCtxLock.unlock();
> 
> The usual pattern is to use try { } finally { } with locks (even though in this particular case I don't see how the assignment would throw) - but if more things need to be done in the future here then at least the try { } finally { } will be in place.
> 
> Suggestion:
> 
>         handshakeCtxLock.lock();
>         try {
>             handshakeContext = null;
>         } finally {
>             handshakeCtxLock.unlock();
>         }

I added the try/finally.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182625725
PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182626923

From dfuchs at openjdk.org  Tue May  2 14:32:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 May 2023 14:32:10 GMT
Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling
 with NullPointerException [v2]
In-Reply-To: <-2C5OXMu_wztFlkIwH9UPyUpLaOZMVycbBtmSxwJdGs=.c7858621-fc8d-4d2c-8428-37838c9f65d5@github.com>
References: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
 <-2C5OXMu_wztFlkIwH9UPyUpLaOZMVycbBtmSxwJdGs=.c7858621-fc8d-4d2c-8428-37838c9f65d5@github.com>
Message-ID: <Iv2LOSzPnhF9_LyLk1_tjhtJRlpT0OXOrAPQeiimBco=.7f0ff9c2-08d3-4be7-8e75-f886b34d9172@github.com>

On Tue, 2 May 2023 14:31:38 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   using try/finally in terminateHandshakeContext and using local context variable in all places it should be

src/java.base/share/classes/sun/security/ssl/TransportContext.java line 91:

> 89:     // handshake context
> 90:     HandshakeContext                handshakeContext = null;
> 91:     Lock                            handshakeCtxLock = new ReentrantLock();

`handshakeCtxLock` should be declared final.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13742#discussion_r1182634866

From jiangli at openjdk.org  Tue May  2 16:41:25 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 2 May 2023 16:41:25 GMT
Subject: RFR: 8307134: Add GTS root CAs
Message-ID: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>

This PR was requested by awarner at google.com. The updates are provided by awarner at google.com.

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

Commit messages:
 - Merge branch 'master' into JDK-8307134
 - 8307134: Add GTS root CAs

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

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

From mullan at openjdk.org  Tue May  2 17:28:16 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 2 May 2023 17:28:16 GMT
Subject: RFR: 8307134: Add GTS root CAs
In-Reply-To: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
Message-ID: <h6M1STTc5ya8mHa6ylpJGkvmkootDP3v6MygjBe6D3k=.16951a2f-e1df-40b5-b395-6a0ae02591e9@github.com>

On Tue, 2 May 2023 16:35:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.

Ideally, an infra test for testing test certs should also be added. @rhalade may be able to contribute this.

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

PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531864022

From rhalade at openjdk.org  Tue May  2 17:32:14 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 2 May 2023 17:32:14 GMT
Subject: RFR: 8307134: Add GTS root CAs
In-Reply-To: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
Message-ID: <N6BOfOo6-CAUNs4MBTHBk1H2ZCFnm-TrGmZdBSGFgCY=.0c0b3d89-373b-426e-9962-082e5716f760@github.com>

On Tue, 2 May 2023 16:35:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.

> 

I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1

src/java.base/share/data/cacerts/globalsigneccrootcar4 line 3:

> 1: Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
> 2: Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
> 3: Serial number: 203e57ef53f93fda50921b2a6

Why is this certificate changed?

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

PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531868773
PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1182843649

From weijun at openjdk.org  Tue May  2 17:54:31 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 2 May 2023 17:54:31 GMT
Subject: RFR: 8297878: KEM: Implementation [v13]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <gsq91Xj2HmicrNZdCUw_C5EDOKCcf1npARvvbvQtBDQ=.cf40f7af-3185-452d-9c6a-a78dff8d4582@github.com>

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

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

  providerName

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/51be3375..c2daf4e3

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

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

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

From weijun at openjdk.org  Tue May  2 17:55:30 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 2 May 2023 17:55:30 GMT
Subject: RFR: 8297878: KEM: Implementation [v12]
In-Reply-To: <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@github.com>
Message-ID: <Rc2inqzecBEBouclIcNKYP55uuQB34czbsatwNphvDY=.658ae5df-29d5-4c55-a761-dc62d77cd7a7@github.com>

On Thu, 27 Apr 2023 15:40:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more @since and about nulls

New commit pushed. `s/provider/providerName/`. Now we can claim the `Encapsulator` and `Decapsulator` classes are immutable.

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

PR Comment: https://git.openjdk.org/jdk/pull/13256#issuecomment-1531899641

From jiangli at openjdk.org  Tue May  2 17:56:18 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 2 May 2023 17:56:18 GMT
Subject: RFR: 8307134: Add GTS root CAs
In-Reply-To: <N6BOfOo6-CAUNs4MBTHBk1H2ZCFnm-TrGmZdBSGFgCY=.0c0b3d89-373b-426e-9962-082e5716f760@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <N6BOfOo6-CAUNs4MBTHBk1H2ZCFnm-TrGmZdBSGFgCY=.0c0b3d89-373b-426e-9962-082e5716f760@github.com>
Message-ID: <zsQsyuUJgxJMp4RgbvIJw6c0KMwfRZBQjZKcyNyi2b4=.0ca1d392-59c2-4443-8ae2-6b42fa941db0@github.com>

On Tue, 2 May 2023 17:29:07 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.
>
>> 
> 
> I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1

> Ideally, an infra test for testing test certs should also be added. @rhalade may be able to contribute this.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531899677

From jiangli at openjdk.org  Tue May  2 18:39:15 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 2 May 2023 18:39:15 GMT
Subject: RFR: 8307134: Add GTS root CAs
In-Reply-To: <N6BOfOo6-CAUNs4MBTHBk1H2ZCFnm-TrGmZdBSGFgCY=.0c0b3d89-373b-426e-9962-082e5716f760@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <N6BOfOo6-CAUNs4MBTHBk1H2ZCFnm-TrGmZdBSGFgCY=.0c0b3d89-373b-426e-9962-082e5716f760@github.com>
Message-ID: <bMmo2rNT7tQ0A84MhJhO1X-BoxPeejF-IZWmKkumMvA=.6cac592d-675f-4df1-81b7-79969b166390@github.com>

On Tue, 2 May 2023 17:29:07 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> > 
> 
> I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1

@rhalade, thanks! I have a minor comment below for your test/jdk/security/infra/java/security/cert/CertPathValidator/certification/GoogleCA.java test.  I'll defer to @awarner at google.com for detailed review, as I don't have much context.

Please fix the bug id, `8303394`:

/*
 * @test
 * @bug 8303394
 * @summary Interoperability tests with Google's GlobalSign R4 and GTS Root certificates
 ...


Could you please also let me know your plan on committing the GoogleCA.java? Do you plan to create a PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531961102

From rhalade at openjdk.org  Tue May  2 18:45:14 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 2 May 2023 18:45:14 GMT
Subject: RFR: 8307134: Add GTS root CAs
In-Reply-To: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
Message-ID: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>

On Tue, 2 May 2023 16:35:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.

> > > 
> > 
> > 
> > I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1
> 
> @rhalade, thanks! I have a minor comment below for your test/jdk/security/infra/java/security/cert/CertPathValidator/certification/GoogleCA.java test. I'll defer to @[awarner at google.com](mailto:awarner at google.com) for detailed review, as I don't have much context.
> 
> Please fix the bug id, `8303394`:
> 
> ```
> /*
>  * @test
>  * @bug 8303394
>  * @summary Interoperability tests with Google's GlobalSign R4 and GTS Root certificates
>  ...
> ```
> 
> Could you please also let me know your plan on committing the GoogleCA.java? Do you plan to create a PR?

You can include this contribution in your PR. Then it will be easier to backport to JDK 20u as one changeset. I updated bug id in the changeset.

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

PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531972274

From duke at openjdk.org  Tue May  2 19:02:22 2023
From: duke at openjdk.org (Andy Warner)
Date: Tue, 2 May 2023 19:02:22 GMT
Subject: RFR: 8307134: Add GTS root CAs
In-Reply-To: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>
Message-ID: <d3UsX5wFtxYV6eur1kzAIuF2FlTl9uo6teIxJHOy3_k=.b3dc9f45-9d3f-4aac-91bc-3b76de082cf2@github.com>

On Tue, 2 May 2023 18:42:36 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> > 
> 
> I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1

Aside from the bug number @jianglizhou raised, the interop tests look good to me.

> src/java.base/share/data/cacerts/globalsigneccrootcar4 line 3:
> 
>> 1: Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
>> 2: Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
>> 3: Serial number: 203e57ef53f93fda50921b2a6
> 
> Why is this certificate changed?

The original R4 did not have the digitalSignature keyUsage set. This root signs OCSP responses, so it needed to be reissued to comply with section 7.1.2.1 of the CA/B Forum baseline requirements. The only change between the two versions aside from the serial number is the addition of the digitalSignature key usage bit.

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

PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1531995277
PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1182931200

From mpowers at openjdk.org  Tue May  2 19:22:15 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 2 May 2023 19:22:15 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
Message-ID: <S4DgjyOxzv8W6FRU8XuXK6Q_rHxhkW-Yhqsi3BvvTT8=.5b513878-22ba-45fe-bd4b-560282bc2106@github.com>

On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
> 
> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
> 
> Thanks,
> Valerie

The changes LGTM.
Your comments helped a lot.

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

PR Review: https://git.openjdk.org/jdk/pull/13743#pullrequestreview-1409744045

From duke at openjdk.org  Tue May  2 20:39:21 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 20:39:21 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v3]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <QD7sOYyocbLH3fWlFNAvcDLVFhMy1DZx-k3ET6Cctns=.4ad0161c-8f21-4e99-b083-c6f01fea4bd9@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  addressing more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/d1e1763c..21018dd6

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

  Stats: 40 lines in 3 files changed: 22 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691

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

From duke at openjdk.org  Tue May  2 20:39:30 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 20:39:30 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v2]
In-Reply-To: <Ts8qdGtIJzCsJjC2C3TsDSPCBcdnikLeDRwlmLWOF_g=.edb9ebd7-c606-48dd-88d5-4b3873e0dd62@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <rSwIrXBCmI6sB04pVK1S5ZARNxxc26ibtVDHRXs9fFY=.51ca5802-5a9b-4f0f-bf3b-3366bf5a4969@github.com>
 <QQQlL4bdGZ3f74wNHrAb6HBJEXzKSqXVxQ-qI_RbQQA=.21e612b0-adac-4a31-99b6-3d9e876d4f2a@github.com>
 <Ts8qdGtIJzCsJjC2C3TsDSPCBcdnikLeDRwlmLWOF_g=.edb9ebd7-c606-48dd-88d5-4b3873e0dd62@github.com>
Message-ID: <_0_M2Qo1v6mk0HjUPr0oOHMAurij6E0amCiF_1Pldr4=.3f590478-73e9-4180-a7b0-fae5e48f8f73@github.com>

On Fri, 28 Apr 2023 19:54:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 423:
>> 
>>> 421: 
>>> 422:                 default:
>>> 423:                     throw new IllegalArgumentException("Unsupported or bad LMS type");
>> 
>> Could this be `InvalidParameterException` instead?
>
> Or should it be a `InvalidKeyException` if the method is called when creating a public key?
> 
> Anyway, we need to make sure the correct exceptions are thrown in public APIs. This needs a lot of tests.

I have caught this at the call sites and converted it to the relevant exceptions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183024501

From duke at openjdk.org  Tue May  2 20:39:23 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 20:39:23 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v3]
In-Reply-To: <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com>
Message-ID: <do-kpJJmkaidLAWD2yWzC8xiylTQyrQnys8WlDLCRVo=.9f3d2e95-814f-4307-8d84-e9f3c93ab6c7@github.com>

On Thu, 27 Apr 2023 17:39:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing more review comments
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 66:
> 
>> 64:         if (!(publicKey instanceof HSSPublicKey pub)) {
>> 65:             throw new InvalidKeyException("Not an HSS public key: ");
>> 66:         }
> 
> If not, we can try translating it using our `KeyFactory`.

Done

> src/java.base/share/classes/sun/security/provider/HSS.java line 758:
> 
>> 756:             if (key instanceof HSSPublicKey) {
>> 757:                 return key;
>> 758:             }
> 
> We need to be able to translate other HSS/LMS public keys into our own type as long as the algorithm and format are OK.
> 
> You can try this out by duplicating your implementation with a different provider name in a different package.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183022892
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183023531

From duke at openjdk.org  Tue May  2 20:39:32 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 20:39:32 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v3]
In-Reply-To: <9RRITm9kBt_cSdt_NMnOJoWpJ83acPy0Xnof8Ss7y9g=.4b23380d-1886-4925-aa8b-42ba63590045@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com>
 <k9YXvBneqn45SbCGKIFchWFFq-6IcZGGP_lwe-9tZbE=.9a26d14c-3d2e-475f-9dea-2395e5cc474b@github.com>
 <9RRITm9kBt_cSdt_NMnOJoWpJ83acPy0Xnof8Ss7y9g=.4b23380d-1886-4925-aa8b-42ba63590045@github.com>
Message-ID: <Bpaw5Hl8WOYE7bvhddqscRybAvTRr0UNNgFaDY7A7xY=.6abbb2d2-c12e-4a86-b993-38ee5a4be188@github.com>

On Fri, 28 Apr 2023 13:38:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I need it now, with the addWithAlias() change.
>
> `addWithAlias` search for an OID by its name using the `KnownOIDs` class.

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183023787

From duke at openjdk.org  Tue May  2 20:39:30 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 20:39:30 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v2]
In-Reply-To: <bfjDLLQq5iRP6upmpV33EB-qmY094XjnrsUBTpnzqw4=.e58581e5-e55f-4858-9735-526dc8936837@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <rSwIrXBCmI6sB04pVK1S5ZARNxxc26ibtVDHRXs9fFY=.51ca5802-5a9b-4f0f-bf3b-3366bf5a4969@github.com>
 <bfjDLLQq5iRP6upmpV33EB-qmY094XjnrsUBTpnzqw4=.e58581e5-e55f-4858-9735-526dc8936837@github.com>
Message-ID: <hJMoMif40zQAtdsxF1HFfS6taj9lHJ40U5L3mu9yGWs=.bac661fc-e8d2-484a-83fc-b65b75f3760c@github.com>

On Fri, 28 Apr 2023 13:52:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments addressed
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 86:
> 
>> 84:                 lmsPubKey = sig.pubList[i];
>> 85:             }
>> 86:             return result & lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray());
> 
> You should probably reset `messageStream` so that it can be called in another `update/verify` sequence. This is also worth a test.

Added.

> src/java.base/share/classes/sun/security/provider/HSS.java line 173:
> 
>> 171:             int m = lmParams.m;
>> 172:             if ((inLen < (24 + m)) || (checkExactLength && (inLen != (24 + m))) ||
>> 173:                     !LMOTSParams.of(otsType).hashAlgName.equals(lmParams.hashAlgStr)) {
> 
> This algorithm name comparison is not sufficient. You are using "SHA-256" for both M32 and M24 types. Either add a comparison on `LMParams.m` and `LMOTSParams.n`, or use "SHA-256/192" as the hash algorithm name.

Changed.

> src/java.base/share/classes/sun/security/provider/HSS.java line 213:
> 
>> 211: 
>> 212:     static class LMSUtils {
>> 213:         public final static int LMS_RESERVED = 0;
> 
> Is the `LMS_RESERVED` and `LMOTS_RESERVED` constants used anywhere?

No, but they are defined in the standard so it seemed to be a good idea to document that this way.

> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 274:
> 
>> 272:         store("DSA", KnownOIDs.DSA, KnownOIDs.OIW_DSA.value());
>> 273: 
>> 274:         store("HSS/LMS", KnownOIDs.HSSLMS, KnownOIDs.HSSLMS.value());
> 
> This is only necessary if an non-OID alias is needed. For example, if we want to use "LMS" as an alias of "HSS/LMS".

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183024118
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183024398
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183024209
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183023989

From duke at openjdk.org  Tue May  2 20:39:24 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 20:39:24 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v3]
In-Reply-To: <do-kpJJmkaidLAWD2yWzC8xiylTQyrQnys8WlDLCRVo=.9f3d2e95-814f-4307-8d84-e9f3c93ab6c7@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com>
 <do-kpJJmkaidLAWD2yWzC8xiylTQyrQnys8WlDLCRVo=.9f3d2e95-814f-4307-8d84-e9f3c93ab6c7@github.com>
Message-ID: <xVL9hA_8p3SRaNVOkyVxemp1ytaD2iE27reoEh3JtN4=.fd463f4e-6bc4-458c-9a9e-718cde427980@github.com>

On Tue, 2 May 2023 20:32:02 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 66:
>> 
>>> 64:         if (!(publicKey instanceof HSSPublicKey pub)) {
>>> 65:             throw new InvalidKeyException("Not an HSS public key: ");
>>> 66:         }
>> 
>> If not, we can try translating it using our `KeyFactory`.
>
> Done

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183023311

From jiangli at openjdk.org  Tue May  2 20:43:31 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 2 May 2023 20:43:31 GMT
Subject: RFR: 8307134: Add GTS root CAs [v2]
In-Reply-To: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
Message-ID: <MGaHkmf-eMyLi7S21MlhsTDVyXM2oMwGuNAt5i3AkdE=.12cd3018-5c46-4bb8-9836-d4da6efa2c8a@github.com>

> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Add GoogleCA.java test from @rhalade.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13754/files
  - new: https://git.openjdk.org/jdk/pull/13754/files/caedc4ed..37538f53

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

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

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

From jiangli at openjdk.org  Tue May  2 20:43:31 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 2 May 2023 20:43:31 GMT
Subject: RFR: 8307134: Add GTS root CAs
In-Reply-To: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>
Message-ID: <bfHs5GuO0_WHNZOVD-dti8FcQrVWXmFjcXms0fv0xZM=.f65f802a-3cf3-4a24-9204-e99d9382893f@github.com>

On Tue, 2 May 2023 18:42:36 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> You can include this contribution in your PR. Then it will be easier to backport to JDK 20u as one changeset. I updated bug id in the changeset.

Done. Please double check.

I ran the GoogleCA.java test with a test JDK binary built with this PR changes included. The test passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1532118040

From mullan at openjdk.org  Tue May  2 20:43:32 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 2 May 2023 20:43:32 GMT
Subject: RFR: 8307134: Add GTS root CAs [v2]
In-Reply-To: <d3UsX5wFtxYV6eur1kzAIuF2FlTl9uo6teIxJHOy3_k=.b3dc9f45-9d3f-4aac-91bc-3b76de082cf2@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>
 <d3UsX5wFtxYV6eur1kzAIuF2FlTl9uo6teIxJHOy3_k=.b3dc9f45-9d3f-4aac-91bc-3b76de082cf2@github.com>
Message-ID: <1T8Ao1eMFgQc4RFB7d_oOKZTjcpgO3KK5B_dp8vcVu4=.61e93ebd-36b5-46ba-b152-5ac0455a0997@github.com>

On Tue, 2 May 2023 18:51:52 GMT, Andy Warner <duke at openjdk.org> wrote:

>> src/java.base/share/data/cacerts/globalsigneccrootcar4 line 3:
>> 
>>> 1: Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
>>> 2: Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
>>> 3: Serial number: 203e57ef53f93fda50921b2a6
>> 
>> Why is this certificate changed?
>
> The original R4 did not have the digitalSignature keyUsage set. This root signs OCSP responses, so it needed to be reissued to comply with section 7.1.2.1 of the CA/B Forum baseline requirements. The only change between the two versions aside from the serial number is the addition of the digitalSignature key usage bit.

Thanks for the explanation. Please file a different issue for this change, since it is outside the scope of this issue, which is to specifically add new roots that have been approved by the Java SE CA Root Program processes. Updated roots, even for small changes such as this, should be handled and approved using an equivalent process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1183027007

From duke at openjdk.org  Tue May  2 20:44:27 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 20:44:27 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v4]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <udf6sRdg_25C7ppSf_VsAPH7rlxSdehmfar9ZAOKU4M=.8dec0a09-89c8-4806-a604-5c565ee63780@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

Ferenc Rakoczi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  addressing more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/21018dd6..a3f809ef

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

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

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

From weijun at openjdk.org  Tue May  2 20:53:14 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 2 May 2023 20:53:14 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v4]
In-Reply-To: <xVL9hA_8p3SRaNVOkyVxemp1ytaD2iE27reoEh3JtN4=.fd463f4e-6bc4-458c-9a9e-718cde427980@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com>
 <do-kpJJmkaidLAWD2yWzC8xiylTQyrQnys8WlDLCRVo=.9f3d2e95-814f-4307-8d84-e9f3c93ab6c7@github.com>
 <xVL9hA_8p3SRaNVOkyVxemp1ytaD2iE27reoEh3JtN4=.fd463f4e-6bc4-458c-9a9e-718cde427980@github.com>
Message-ID: <AaJm4gIasPEzUfvuN2dz8jsJFj_QUywU1jM1uW-aM6s=.36341fda-66f1-4c64-962d-5207cde98575@github.com>

On Tue, 2 May 2023 20:32:33 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Done
>
> Done.

Where?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183036679

From weijun at openjdk.org  Tue May  2 20:53:19 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 2 May 2023 20:53:19 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v4]
In-Reply-To: <udf6sRdg_25C7ppSf_VsAPH7rlxSdehmfar9ZAOKU4M=.8dec0a09-89c8-4806-a604-5c565ee63780@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <udf6sRdg_25C7ppSf_VsAPH7rlxSdehmfar9ZAOKU4M=.8dec0a09-89c8-4806-a604-5c565ee63780@github.com>
Message-ID: <4X51Yc_hE2AQwJWiO5oMG5yUz233j0ekvRtbHZ2lmvo=.fdc0f895-e169-478e-a4ff-72b5c42484b3@github.com>

On Tue, 2 May 2023 20:44:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   addressing more review comments

src/java.base/share/classes/sun/security/provider/HSS.java line 91:

> 89:             return result;
> 90:         } catch (Exception e) {
> 91:             messageStream.reset();

You can put this line in a `finally` block.

src/java.base/share/classes/sun/security/provider/HSS.java line 585:

> 583:                     params = new LMOTSParams(lmotsType, 32, 8, 0, 34, "SHA-256");
> 584:                     break;
> 585:                 case LMSUtils.LMOTS_SHA256_N24_W1:

Since you commented out the LMS constants for SHA-256/192. Do you want to do the same here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183034005
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183037689

From weijun at openjdk.org  Tue May  2 20:53:22 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 2 May 2023 20:53:22 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v2]
In-Reply-To: <hJMoMif40zQAtdsxF1HFfS6taj9lHJ40U5L3mu9yGWs=.bac661fc-e8d2-484a-83fc-b65b75f3760c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <rSwIrXBCmI6sB04pVK1S5ZARNxxc26ibtVDHRXs9fFY=.51ca5802-5a9b-4f0f-bf3b-3366bf5a4969@github.com>
 <bfjDLLQq5iRP6upmpV33EB-qmY094XjnrsUBTpnzqw4=.e58581e5-e55f-4858-9735-526dc8936837@github.com>
 <hJMoMif40zQAtdsxF1HFfS6taj9lHJ40U5L3mu9yGWs=.bac661fc-e8d2-484a-83fc-b65b75f3760c@github.com>
Message-ID: <lRjYCZOiC5Crfp6JEiUIBVf1BYtNJu8PSq6F6jtJaEo=.b93e171a-9c14-4823-a4f9-e8ee8d7d41e5@github.com>

On Tue, 2 May 2023 20:33:40 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 213:
>> 
>>> 211: 
>>> 212:     static class LMSUtils {
>>> 213:         public final static int LMS_RESERVED = 0;
>> 
>> Is the `LMS_RESERVED` and `LMOTS_RESERVED` constants used anywhere?
>
> No, but they are defined in the standard so it seemed to be a good idea to document that this way.

OK. No problem then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183036991

From jiangli at openjdk.org  Tue May  2 21:00:04 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 2 May 2023 21:00:04 GMT
Subject: RFR: 8307134: Add GTS root CAs [v3]
In-Reply-To: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
Message-ID: <Z7nY5acVCFiu4n9NXMyNJri1jNEBMo4QQTm7hvZhNSE=.147acde8-03c8-4586-b76e-9fce2bd0d1db@github.com>

> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Revert the src/java.base/share/data/cacerts/globalsigneccrootcar4 change.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13754/files
  - new: https://git.openjdk.org/jdk/pull/13754/files/37538f53..3abe98b2

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

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

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

From jiangli at openjdk.org  Tue May  2 21:14:17 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 2 May 2023 21:14:17 GMT
Subject: RFR: 8307134: Add GTS root CAs [v3]
In-Reply-To: <1T8Ao1eMFgQc4RFB7d_oOKZTjcpgO3KK5B_dp8vcVu4=.61e93ebd-36b5-46ba-b152-5ac0455a0997@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>
 <d3UsX5wFtxYV6eur1kzAIuF2FlTl9uo6teIxJHOy3_k=.b3dc9f45-9d3f-4aac-91bc-3b76de082cf2@github.com>
 <1T8Ao1eMFgQc4RFB7d_oOKZTjcpgO3KK5B_dp8vcVu4=.61e93ebd-36b5-46ba-b152-5ac0455a0997@github.com>
Message-ID: <jyER7iHJpB-Zp_AID-EoIylkppyoORZkjWEKG0IYijU=.a6549bda-5430-43b7-a3ff-278af1e6d9fc@github.com>

On Tue, 2 May 2023 20:36:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The original R4 did not have the digitalSignature keyUsage set. This root signs OCSP responses, so it needed to be reissued to comply with section 7.1.2.1 of the CA/B Forum baseline requirements. The only change between the two versions aside from the serial number is the addition of the digitalSignature key usage bit.
>
> Thanks for the explanation. Please file a different issue for this change, since it is outside the scope of this issue, which is to specifically add new roots that have been approved by the Java SE CA Root Program processes. Updated roots, even for small changes such as this, should be handled and approved using an equivalent process.

Reverted src/java.base/share/data/cacerts/globalsigneccrootcar4 in this PR. Looks like the update for "globalsigneccrootcar4 [jdk]" in test/jdk/sun/security/lib/cacerts/VerifyCACerts.java also needs to be reverted, otherwise the test fails with the following error. I'll go ahead and revert that as well.


ERROR: wrong checksum72:03:89:C2:7B:BF:87:87:E1:65:44:6E:43:5C:65:FF:B5:E8:F9:4C:8A:D1:63:6D:D1:91:4C:AD:1C:9A:CB:3B
Expected checksum23:6E:7A:1C:37:AD:82:31:FD:32:E8:31:63:4B:1A:88:BA:1A:4D:F6:D3:91:CD:0F:B4:09:EC:55:9A:B2:01:51
ERROR: globalsigneccrootcar4 [jdk] SHA-256 fingerprint is incorrect
java.lang.RuntimeException: At least one cacert test failed
        at VerifyCACerts.main(VerifyCACerts.java:380)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:578)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1592)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1183055459

From jiangli at openjdk.org  Tue May  2 21:27:18 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 2 May 2023 21:27:18 GMT
Subject: RFR: 8307134: Add GTS root CAs [v4]
In-Reply-To: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
Message-ID: <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com>

> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/sun/security/lib/cacerts/VerifyCACerts.java after reverting src/java.base/share/data/cacerts/globalsigneccrootcar4.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13754/files
  - new: https://git.openjdk.org/jdk/pull/13754/files/3abe98b2..ffc80326

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

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

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

From duke at openjdk.org  Tue May  2 21:29:20 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 21:29:20 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v4]
In-Reply-To: <4X51Yc_hE2AQwJWiO5oMG5yUz233j0ekvRtbHZ2lmvo=.fdc0f895-e169-478e-a4ff-72b5c42484b3@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <udf6sRdg_25C7ppSf_VsAPH7rlxSdehmfar9ZAOKU4M=.8dec0a09-89c8-4806-a604-5c565ee63780@github.com>
 <4X51Yc_hE2AQwJWiO5oMG5yUz233j0ekvRtbHZ2lmvo=.fdc0f895-e169-478e-a4ff-72b5c42484b3@github.com>
Message-ID: <WX53OEoA5xlDK0GvhQTjp8Uc8gkkPuDUorp7oB4W2sA=.5bd00390-954b-4c80-85a1-fc3d486bbf18@github.com>

On Tue, 2 May 2023 20:45:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   addressing more review comments
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 91:
> 
>> 89:             return result;
>> 90:         } catch (Exception e) {
>> 91:             messageStream.reset();
> 
> You can put this line in a `finally` block.

OK.

> src/java.base/share/classes/sun/security/provider/HSS.java line 585:
> 
>> 583:                     params = new LMOTSParams(lmotsType, 32, 8, 0, 34, "SHA-256");
>> 584:                     break;
>> 585:                 case LMSUtils.LMOTS_SHA256_N24_W1:
> 
> Since you commented out the LMS constants for SHA-256/192. Do you want to do the same here?

Oops...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183066920
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183067244

From jiangli at openjdk.org  Tue May  2 21:41:19 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 2 May 2023 21:41:19 GMT
Subject: RFR: 8307134: Add GTS root CAs [v4]
In-Reply-To: <jyER7iHJpB-Zp_AID-EoIylkppyoORZkjWEKG0IYijU=.a6549bda-5430-43b7-a3ff-278af1e6d9fc@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>
 <d3UsX5wFtxYV6eur1kzAIuF2FlTl9uo6teIxJHOy3_k=.b3dc9f45-9d3f-4aac-91bc-3b76de082cf2@github.com>
 <1T8Ao1eMFgQc4RFB7d_oOKZTjcpgO3KK5B_dp8vcVu4=.61e93ebd-36b5-46ba-b152-5ac0455a0997@github.com>
 <jyER7iHJpB-Zp_AID-EoIylkppyoORZkjWEKG0IYijU=.a6549bda-5430-43b7-a3ff-278af1e6d9fc@github.com>
Message-ID: <8Q2gWi9Z-962OZbespxRsn3hhDn_Jr7P47WRydcWFuM=.b159256a-2789-4209-b8c1-cf0d575bc3b3@github.com>

On Tue, 2 May 2023 21:11:09 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Thanks for the explanation. Please file a different issue for this change, since it is outside the scope of this issue, which is to specifically add new roots that have been approved by the Java SE CA Root Program processes. Updated roots, even for small changes such as this, should be handled and approved using an equivalent process.
>
> Reverted src/java.base/share/data/cacerts/globalsigneccrootcar4 in this PR. Looks like the update for "globalsigneccrootcar4 [jdk]" in test/jdk/sun/security/lib/cacerts/VerifyCACerts.java also needs to be reverted, otherwise the test fails with the following error. I'll go ahead and revert that as well.
> 
> 
> ERROR: wrong checksum72:03:89:C2:7B:BF:87:87:E1:65:44:6E:43:5C:65:FF:B5:E8:F9:4C:8A:D1:63:6D:D1:91:4C:AD:1C:9A:CB:3B
> Expected checksum23:6E:7A:1C:37:AD:82:31:FD:32:E8:31:63:4B:1A:88:BA:1A:4D:F6:D3:91:CD:0F:B4:09:EC:55:9A:B2:01:51
> ERROR: globalsigneccrootcar4 [jdk] SHA-256 fingerprint is incorrect
> java.lang.RuntimeException: At least one cacert test failed
>         at VerifyCACerts.main(VerifyCACerts.java:380)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>         at java.base/java.lang.Thread.run(Thread.java:1592)

Done. Also updated 'CHECKSUM' value in test/jdk/sun/security/lib/cacerts/VerifyCACerts.java reflectively.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13754#discussion_r1183075098

From duke at openjdk.org  Tue May  2 21:43:20 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 21:43:20 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <AaJm4gIasPEzUfvuN2dz8jsJFj_QUywU1jM1uW-aM6s=.36341fda-66f1-4c64-962d-5207cde98575@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <0Jc3e0oP32Tj4dabaqz2kHXr3_XxNXkaPaPat0gJoeI=.5f8fcfa0-e76a-41fb-9cac-edf0707b65cb@github.com>
 <do-kpJJmkaidLAWD2yWzC8xiylTQyrQnys8WlDLCRVo=.9f3d2e95-814f-4307-8d84-e9f3c93ab6c7@github.com>
 <xVL9hA_8p3SRaNVOkyVxemp1ytaD2iE27reoEh3JtN4=.fd463f4e-6bc4-458c-9a9e-718cde427980@github.com>
 <AaJm4gIasPEzUfvuN2dz8jsJFj_QUywU1jM1uW-aM6s=.36341fda-66f1-4c64-962d-5207cde98575@github.com>
Message-ID: <9DlF2lt1GkdjkvapVg5yTno5ALNRUK8Dz5o4b5NjhGA=.47d4107f-e017-40ef-a1e8-62e022a2cbb3@github.com>

On Tue, 2 May 2023 20:48:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Done.
>
> Where?

Done now. Sorry about it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1183075152

From duke at openjdk.org  Tue May  2 21:43:19 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 2 May 2023 21:43:19 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  adding key translation, finally block, removing 24-byte LMOTS parameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/a3f809ef..b546fdf0

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

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

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

From jnimeh at openjdk.org  Tue May  2 21:55:19 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 2 May 2023 21:55:19 GMT
Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
Message-ID: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>

This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.

This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).

JBS: https://bugs.openjdk.org/browse/JDK-8179502
CSR: https://bugs.openjdk.org/browse/JDK-8300722

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

Commit messages:
 - Fix more whitespace errors
 - Fix whitespace errors
 - 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts

Changes: https://git.openjdk.org/jdk/pull/13762/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8179502
  Stats: 873 lines in 7 files changed: 759 ins; 27 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/13762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13762/head:pull/13762

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

From weijun at openjdk.org  Tue May  2 22:36:15 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 2 May 2023 22:36:15 GMT
Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
In-Reply-To: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
Message-ID: <bo8XC8knsJsWbHpYcQXna39swJIqNS98u2bFG-pIly0=.7798c6ca-98ef-4039-9931-36b0631d4334@github.com>

On Tue, 2 May 2023 21:12:31 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
> 
> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
> 
> JBS: https://bugs.openjdk.org/browse/JDK-8179502
> CSR: https://bugs.openjdk.org/browse/JDK-8300722

src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 192:

> 190: 
> 191:         // Determine if "ms" is on the end of the string
> 192:         boolean isMillis = propVal.toLowerCase().endsWith("ms");

Shall we allow the `s` suffix as well? This makes it clear that a value is in seconds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1183107810

From jnimeh at openjdk.org  Tue May  2 23:23:17 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 2 May 2023 23:23:17 GMT
Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
In-Reply-To: <bo8XC8knsJsWbHpYcQXna39swJIqNS98u2bFG-pIly0=.7798c6ca-98ef-4039-9931-36b0631d4334@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <bo8XC8knsJsWbHpYcQXna39swJIqNS98u2bFG-pIly0=.7798c6ca-98ef-4039-9931-36b0631d4334@github.com>
Message-ID: <C8L2upyCMCqf1g11BIEPLczniKW6hSt3HqXlF9wd_sc=.8e2b6f4f-b809-48ce-b31a-fd2a044a8682@github.com>

On Tue, 2 May 2023 22:33:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
>> 
>> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
>> 
>> JBS: https://bugs.openjdk.org/browse/JDK-8179502
>> CSR: https://bugs.openjdk.org/browse/JDK-8300722
>
> src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 192:
> 
>> 190: 
>> 191:         // Determine if "ms" is on the end of the string
>> 192:         boolean isMillis = propVal.toLowerCase().endsWith("ms");
> 
> Shall we allow the `s` suffix as well? This makes it clear that a value is in seconds.

Well, all the existing documentation already states that they are in seconds.  That was why I didn't add any additional suffixes.  The goal was to make it so folks don't need to make any changes if the existing seconds-level granularity is sufficient for them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1183129362

From weijun at openjdk.org  Wed May  3 00:30:14 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 3 May 2023 00:30:14 GMT
Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
In-Reply-To: <C8L2upyCMCqf1g11BIEPLczniKW6hSt3HqXlF9wd_sc=.8e2b6f4f-b809-48ce-b31a-fd2a044a8682@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <bo8XC8knsJsWbHpYcQXna39swJIqNS98u2bFG-pIly0=.7798c6ca-98ef-4039-9931-36b0631d4334@github.com>
 <C8L2upyCMCqf1g11BIEPLczniKW6hSt3HqXlF9wd_sc=.8e2b6f4f-b809-48ce-b31a-fd2a044a8682@github.com>
Message-ID: <NVib8Swu8KLEHA7whmkUMGFywtNiKzUM-KMVxm8mty8=.9951ab27-3de3-4082-aaf7-50aaa6422e97@github.com>

On Tue, 2 May 2023 23:20:20 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 192:
>> 
>>> 190: 
>>> 191:         // Determine if "ms" is on the end of the string
>>> 192:         boolean isMillis = propVal.toLowerCase().endsWith("ms");
>> 
>> Shall we allow the `s` suffix as well? This makes it clear that a value is in seconds.
>
> Well, all the existing documentation already states that they are in seconds.  That was why I didn't add any additional suffixes.  The goal was to make it so folks don't need to make any changes if the existing seconds-level granularity is sufficient for them.

I don't mean not to support bare numbers. It's just a little unfair that millisecond has a suffix but second does not. We can support all of "1", "1s", and "1000ms".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1183156016

From wetmore at openjdk.org  Wed May  3 00:50:15 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 3 May 2023 00:50:15 GMT
Subject: RFR: 8305963: Typo in java.security.Security.getProperty
In-Reply-To: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
References: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
Message-ID: <XW2B3etz8BqX6SMUZKgvvXEMD0NtbFf9J_KK3MWw6GQ=.0bb709c6-2af7-42fb-86cc-3059d58a875c@github.com>

On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Fix type-o and update returns message.

I agree with Sean/Valerie's comments.  Otherwise, LGTM.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13729#pullrequestreview-1410050561

From jnimeh at openjdk.org  Wed May  3 03:39:12 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 3 May 2023 03:39:12 GMT
Subject: RFR: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
In-Reply-To: <NVib8Swu8KLEHA7whmkUMGFywtNiKzUM-KMVxm8mty8=.9951ab27-3de3-4082-aaf7-50aaa6422e97@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <bo8XC8knsJsWbHpYcQXna39swJIqNS98u2bFG-pIly0=.7798c6ca-98ef-4039-9931-36b0631d4334@github.com>
 <C8L2upyCMCqf1g11BIEPLczniKW6hSt3HqXlF9wd_sc=.8e2b6f4f-b809-48ce-b31a-fd2a044a8682@github.com>
 <NVib8Swu8KLEHA7whmkUMGFywtNiKzUM-KMVxm8mty8=.9951ab27-3de3-4082-aaf7-50aaa6422e97@github.com>
Message-ID: <YAxJcALC2eMSVjSqaNP6ckREGwSIce91wE3mQH6Qj24=.c8b052e0-ec96-48b0-bd1c-eab50c50bf69@github.com>

On Wed, 3 May 2023 00:27:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Well, all the existing documentation already states that they are in seconds.  That was why I didn't add any additional suffixes.  The goal was to make it so folks don't need to make any changes if the existing seconds-level granularity is sufficient for them.
>
> I don't mean not to support bare numbers. It's just a little unfair that millisecond has a suffix but second does not. We can support all of "1", "1s", and "1000ms".

Okay, we can make that change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1183212032

From ssahoo at openjdk.org  Wed May  3 09:43:40 2023
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 3 May 2023 09:43:40 GMT
Subject: RFR: 8297878: KEM: Implementation [v12]
In-Reply-To: <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@github.com>
Message-ID: <pyOXoeYS1IWerLMX_MwbdEvEETeNF9N6JlqW47C_AIg=.385ffc8c-2308-4543-a6a6-ff6f2e281054@github.com>

On Thu, 27 Apr 2023 15:40:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more @since and about nulls

test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 97:

> 95:         // Cannot detect invalid params before provider selection
> 96: //        Utils.runAndCheckException(
> 97: //                () -> KEM.getInstance("DHKEM", new KEMParameterSpec() {}),

Commented code block can be removed. Signature of getInstance() doesn't exist.

test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 112:

> 110:                 ExChecker.of(InvalidKeyException.class).by(DHKEM.class));
> 111: 
> 112:         // Not an EC key at all, rejected by framework coz SupportedClasses

Do you mean UnsupportedClasses in comment section?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1183247590
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1183269537

From duke at openjdk.org  Wed May  3 11:26:32 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 3 May 2023 11:26:32 GMT
Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling
 with NullPointerException [v3]
In-Reply-To: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
References: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
Message-ID: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com>

> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods.
> 
> Thanks

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  made handshake context lock final

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13742/files
  - new: https://git.openjdk.org/jdk/pull/13742/files/ce88caa0..92a48a70

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

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

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

From weijun at openjdk.org  Wed May  3 12:43:31 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 3 May 2023 12:43:31 GMT
Subject: RFR: 8297878: KEM: Implementation [v12]
In-Reply-To: <pyOXoeYS1IWerLMX_MwbdEvEETeNF9N6JlqW47C_AIg=.385ffc8c-2308-4543-a6a6-ff6f2e281054@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@github.com>
 <pyOXoeYS1IWerLMX_MwbdEvEETeNF9N6JlqW47C_AIg=.385ffc8c-2308-4543-a6a6-ff6f2e281054@github.com>
Message-ID: <E6LaIdjt39siPT1zTKSnSOIFPjPvrd3GSlocO_YLhPU=.a3da1916-0138-4e57-8a2a-3a062fdee503@github.com>

On Wed, 3 May 2023 05:22:04 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more @since and about nulls
>
> test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 97:
> 
>> 95:         // Cannot detect invalid params before provider selection
>> 96: //        Utils.runAndCheckException(
>> 97: //                () -> KEM.getInstance("DHKEM", new KEMParameterSpec() {}),
> 
> Commented code block can be removed. Signature of getInstance() doesn't exist.

Oops. Will remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1183631427

From weijun at openjdk.org  Wed May  3 12:50:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 3 May 2023 12:50:40 GMT
Subject: RFR: 8297878: KEM: Implementation [v14]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <pAEwG4CARR7ead8Wr7m4xRUCPTplBTP_1Yfd5T3VCWs=.c97dcf41-4db2-4085-8ea9-bdfcab9e6305@github.com>

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

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

  Resolve Siba's comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/c2daf4e3..c9f1d8f3

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

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

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

From weijun at openjdk.org  Wed May  3 12:50:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 3 May 2023 12:50:40 GMT
Subject: RFR: 8297878: KEM: Implementation [v12]
In-Reply-To: <pyOXoeYS1IWerLMX_MwbdEvEETeNF9N6JlqW47C_AIg=.385ffc8c-2308-4543-a6a6-ff6f2e281054@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <tIrupXk0-5gTq3VHHx6OmIJ_5XBC36BqUEnBbCIf6uU=.bde9bfa5-c981-44e2-9740-b70c35272570@github.com>
 <pyOXoeYS1IWerLMX_MwbdEvEETeNF9N6JlqW47C_AIg=.385ffc8c-2308-4543-a6a6-ff6f2e281054@github.com>
Message-ID: <Bvw3zhJtXXRx8LQNxWJU0LGRla1XKW90TrhdIoKaNMw=.99bd66c9-25fb-4039-ae20-5ad2a3dee6dd@github.com>

On Wed, 3 May 2023 06:04:51 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more @since and about nulls
>
> test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 112:
> 
>> 110:                 ExChecker.of(InvalidKeyException.class).by(DHKEM.class));
>> 111: 
>> 112:         // Not an EC key at all, rejected by framework coz SupportedClasses
> 
> Do you mean UnsupportedClasses in comment section?

I meant the "SupportedKeyClasses" attribute in `SunJCE.java`. Will fix the word.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1183635243

From dfuchs at openjdk.org  Wed May  3 12:56:16 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 3 May 2023 12:56:16 GMT
Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling
 with NullPointerException [v3]
In-Reply-To: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com>
References: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
 <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com>
Message-ID: <ggjrNys2kdQy9XcxCylnfUbrtZ12b2tEAyKYKfryPD8=.946e8262-d2c6-491d-a991-415a29e39ec3@github.com>

On Wed, 3 May 2023 11:26:32 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made handshake context lock final

LGTM. You will need approval from a security-dev Reviewer before pushing though.

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

PR Review: https://git.openjdk.org/jdk/pull/13742#pullrequestreview-1410830133

From mullan at openjdk.org  Wed May  3 13:14:19 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 3 May 2023 13:14:19 GMT
Subject: RFR: 8307134: Add GTS root CAs [v4]
In-Reply-To: <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com>
Message-ID: <mMT5Mhsdd7iOYhfFaDUAZvEtbNp6a-wIskJQ3MPVkRk=.0dc28515-ee76-4b9f-a083-db2dc63cd367@github.com>

On Tue, 2 May 2023 21:27:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/security/lib/cacerts/VerifyCACerts.java after reverting src/java.base/share/data/cacerts/globalsigneccrootcar4.

Looks good. Please also wait for approval from @rhalade before integrating.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13754#pullrequestreview-1410867004

From jnimeh at openjdk.org  Wed May  3 13:15:32 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Wed, 3 May 2023 13:15:32 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v2]
In-Reply-To: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
Message-ID: <eE6l8nbMN9i-wFxmV-DcTAM3MVgueMpPCYERIvD2uYU=.e344d03a-cec9-4c47-bd47-befd98956206@github.com>

> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
> 
> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
> 
> JBS: https://bugs.openjdk.org/browse/JDK-8179502
> CSR: https://bugs.openjdk.org/browse/JDK-8300722

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Add 's' suffix to allowed syntax

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13762/files
  - new: https://git.openjdk.org/jdk/pull/13762/files/3e0f5822..3c524e17

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

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

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

From jiangli at openjdk.org  Wed May  3 16:15:16 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 16:15:16 GMT
Subject: RFR: 8307134: Add GTS root CAs
In-Reply-To: <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <1g3rfuvsZwJMmYNeI6bY37XorGEv1VbgflPYQZhaBT8=.07d52106-fb01-4adb-bb8d-75605a20ad80@github.com>
Message-ID: <DTLY3XCjT09QlzR81GO8pInoqfvSNVP_cIUqN_tk_94=.db4714d2-5c08-45b7-b248-5537ec2775d8@github.com>

On Tue, 2 May 2023 18:42:36 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.
>
>> > > 
>> > 
>> > 
>> > I have infra tests for interop implemented. @jianglizhou, please check https://github.com/openjdk/jdk/compare/master...rhalade:jdk:googletrust-certify?expand=1
>> 
>> @rhalade, thanks! I have a minor comment below for your test/jdk/security/infra/java/security/cert/CertPathValidator/certification/GoogleCA.java test. I'll defer to @[awarner at google.com](mailto:awarner at google.com) for detailed review, as I don't have much context.
>> 
>> Please fix the bug id, `8303394`:
>> 
>> ```
>> /*
>>  * @test
>>  * @bug 8303394
>>  * @summary Interoperability tests with Google's GlobalSign R4 and GTS Root certificates
>>  ...
>> ```
>> 
>> Could you please also let me know your plan on committing the GoogleCA.java? Do you plan to create a PR?
> 
> You can include this contribution in your PR. Then it will be easier to backport to JDK 20u as one changeset. I updated bug id in the changeset.

> Looks good. Please also wait for approval from @rhalade before integrating.

Thanks @seanjmullan. Will wait for @rhalade's approval as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1533324346

From rhalade at openjdk.org  Wed May  3 17:45:25 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 3 May 2023 17:45:25 GMT
Subject: RFR: 8307134: Add GTS root CAs [v4]
In-Reply-To: <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com>
Message-ID: <oNepiTh7U7SAgtcC6w1V5srpSUS8pe-N0F9FerMb650=.8a04b1c7-fbdf-4773-9a3d-cf3f6f984d82@github.com>

On Tue, 2 May 2023 21:27:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/security/lib/cacerts/VerifyCACerts.java after reverting src/java.base/share/data/cacerts/globalsigneccrootcar4.

Looks good to me. Please don't forget to update the release note and backport to JDK 20u.

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

Marked as reviewed by rhalade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13754#pullrequestreview-1411431127

From duke at openjdk.org  Wed May  3 18:03:24 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Wed, 3 May 2023 18:03:24 GMT
Subject: Integrated: 8306014: Update javax.net.ssl TLS tests to use
 SSLContextTemplate or SSLEngineTemplate
In-Reply-To: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com>
References: <__lBtpJBPDts7rCXRNIpBQszgLbuaTaSNBZec8ub2-I=.3c56449a-3ff0-48b6-825f-a78cd61cf820@github.com>
Message-ID: <00r3bTPD2PRPwAHA3imWoaYaezEZ0PcK6FXVb6kp2zM=.631986ec-4c89-4c6f-b2c6-4400b29fb4b7@github.com>

On Mon, 17 Apr 2023 13:25:53 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> I refactored tests in the test/jdk/javax/net/ssl directories to use the test template classes.

This pull request has now been integrated.

Changeset: 705ad7d8
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/705ad7d829dcbf8f5e2f098275d0856f6b86db2d
Stats:     1002 lines in 6 files changed: 266 ins; 693 del; 43 mod

8306014: Update javax.net.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate

Reviewed-by: xuelei

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

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

From cslucas at openjdk.org  Wed May  3 20:28:32 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 3 May 2023 20:28:32 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v9]
In-Reply-To: <vcnGjfICEd6umoRJsqkPk8ay68P3FqCTdy2I6IJbkCQ=.bc9d87d2-c2f4-4738-b934-830688a5d922@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <0oNkCfUBIR1hpPwN0i_ONwwyjd0AYux7GkLm-G1PdsU=.b3a5e7ff-e9bf-45b6-b996-691f86aa7057@github.com>
 <W_0rFB3ABAoqAc8zlgxYp9NXzp_n4oNtBjrDviAm7P0=.5b83a96a-8e96-42aa-9b3a-e46908612416@github.com>
 <8AmU_ta4meiUmO99Em5bV7XLAV4H9fAcil519yh70fU=.1a28f4a9-a992-43a7-8c4a-d1cf96835963@github.com>
 <vcnGjfICEd6umoRJsqkPk8ay68P3FqCTdy2I6IJbkCQ=.bc9d87d2-c2f4-4738-b934-830688a5d922@github.com>
Message-ID: <8kDrmtWQJ9oAdm-sM916KB96TqI6HpAHrxjLFn_fRZU=.2d3d9d8e-3eb3-482e-9d1c-416908fa39ac@github.com>

On Fri, 21 Apr 2023 19:23:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> Again got failures in the test on Aarch64 running with -XX:-UseTLAB:
>>> 
>>> ```
>>> testCmpMergeWithNull(boolean,int,int):
>>> - Failed comparison: [found] 0 = 2 [given]
>>> testCmpMergeWithNull_Second(boolean,int,int)
>>> - Failed comparison: [found] 0 = 1 [given]
>>> testMergedAccessAfterCallNoWrite(boolean,int,int)
>>> - Failed comparison: [found] 2 = 3 [given]
>>> testMergedAccessAfterCallWithWrite(boolean,int,int)
>>> - Failed comparison: [found] 2 = 3 [given]
>>> testNestedObjectsArray(boolean,int,int)
>>> - Failed comparison: [found] 2 = 4 [given]
>>> ```
>> 
>> @vnkozlov - The reason for these failures is due to an issue in the test framework ALLOC Regex: https://bugs.openjdk.org/browse/JDK-8306625 . Since only the tests added in this PR are failing due to that problem do you think I should create a separate PR to fix the Regex or just include the fix in this PR?
>
>> Since only the tests added in this PR are failing due to that problem do you think I should create a separate PR to fix the Regex or just include the fix in this PR?
> 
> Create separate PR and fix it first. This PR still need review from @iwanowww and it may take time to address additional comments.

@vnkozlov - Please let me know if you have further questions.

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1533687457

From kdriver at openjdk.org  Wed May  3 20:38:21 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 3 May 2023 20:38:21 GMT
Subject: RFR: 8305963: Typo in java.security.Security.getProperty [v2]
In-Reply-To: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
References: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
Message-ID: <Dgak1r1Vy1Jn-Nrd6RsAdr4qNYNhJy54lYxSkF8HXoI=.ec5b3ff0-9c4f-4b98-b28d-7e136ff9e834@github.com>

> Fix type-o and update returns message.

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

 - address code review comments
 - JDK-8305963 fix type-o and update returns message
 - address code review comments
 - JDK-8305963 fix type-o and update returns message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13729/files
  - new: https://git.openjdk.org/jdk/pull/13729/files/e7046330..5241d394

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

  Stats: 11603 lines in 350 files changed: 7638 ins; 1986 del; 1979 mod
  Patch: https://git.openjdk.org/jdk/pull/13729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13729/head:pull/13729

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

From kdriver at openjdk.org  Wed May  3 20:45:13 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 3 May 2023 20:45:13 GMT
Subject: RFR: 8305963: Typo in java.security.Security.getProperty [v3]
In-Reply-To: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
References: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
Message-ID: <0-TfPm1uv00kCauPw3H0xiQPJ_Ixvwiwkitzs6yqa2E=.fafe2c78-2b81-4722-bd45-97e7dd192d2a@github.com>

> Fix type-o and update returns message.

Kevin Driver has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:

 - address code review comments
 - JDK-8305963 fix type-o and update returns message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13729/files
  - new: https://git.openjdk.org/jdk/pull/13729/files/5241d394..57e7f995

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

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

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

From kdriver at openjdk.org  Wed May  3 20:45:15 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 3 May 2023 20:45:15 GMT
Subject: RFR: 8305963: Typo in java.security.Security.getProperty
In-Reply-To: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
References: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
Message-ID: <tBjUC7r8R-8cu4UK1YwrciNfa8iu6e3xYzvT0oU4EDQ=.53d681e7-aa89-4d98-914e-44cd34548d31@github.com>

On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Fix type-o and update returns message.

@seanjmullan @valeriepeng : see 57e7f9951d21fe2be6466e1c10f3b3cdd53e64b4

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

PR Comment: https://git.openjdk.org/jdk/pull/13729#issuecomment-1533708955

From kdriver at openjdk.org  Wed May  3 20:50:25 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 3 May 2023 20:50:25 GMT
Subject: Integrated: 8305963: Typo in java.security.Security.getProperty
In-Reply-To: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
References: <E6QgBrhSJaouMc3kLIKJ3n0Fge1LkNieVuGBsD3UapY=.145d8b21-4488-46f1-a37d-8c625456272f@github.com>
Message-ID: <i9UFPsAC4cgUDBDfUZwWkKuNG0n2FNVy5bG5FwaZ5bQ=.957529e2-456e-4d18-bcb5-ea4985364711@github.com>

On Fri, 28 Apr 2023 20:55:33 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Fix type-o and update returns message.

This pull request has now been integrated.

Changeset: db8b3cd0
Author:    Kevin Driver <kdriver at openjdk.org>
Committer: Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db8b3cd0842c05396d74abe950a2103654519b61
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8305963: Typo in java.security.Security.getProperty

Co-authored-by: Sean Coffey <coffeys at openjdk.org>
Reviewed-by: coffeys, wetmore

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

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

From kdriver at openjdk.org  Wed May  3 20:51:32 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 3 May 2023 20:51:32 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
 [v2]
In-Reply-To: <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com>
References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
 <46VV0QjRRaN1QJ2B6hw8ibfrtL14iFpWuwfEAVG1bCg=.013b7924-2112-4141-8c72-8dcccfac9cde@github.com>
 <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com>
Message-ID: <wFP9aJLOGgZ3E1yNiekMEHKP1pCLte36q42m3Zbixac=.44c51618-0cb5-49db-bd3f-f436980055a5@github.com>

On Fri, 28 Apr 2023 21:58:04 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase.
>
> src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2022, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> No need for 2022.

@mcpowers : see 0754990b30d8f6b4bc2f977722fe5e679164d351

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13727#discussion_r1184259919

From kdriver at openjdk.org  Wed May  3 20:51:30 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 3 May 2023 20:51:30 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
 [v3]
In-Reply-To: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
Message-ID: <IMFPAb9UJivx7B2O5GNfwWzgjlwVPTsfAzZYU1KfZ1o=.fffabbf5-2dcc-46bd-a20b-b350d53f7a1c@github.com>

> Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`.

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

 - address code review comment
 - updated copyright
 - set consumer to null if we're not in client mode

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

Changes: https://git.openjdk.org/jdk/pull/13727/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13727&range=02
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13727/head:pull/13727

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

From kdriver at openjdk.org  Wed May  3 20:55:16 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 3 May 2023 20:55:16 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
 [v2]
In-Reply-To: <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com>
References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
 <46VV0QjRRaN1QJ2B6hw8ibfrtL14iFpWuwfEAVG1bCg=.013b7924-2112-4141-8c72-8dcccfac9cde@github.com>
 <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com>
Message-ID: <1O1K7-gg4FNOVcwG1g44zUW08CtEuCNz5qbjXNy8X6I=.9c87a9d0-52c8-4224-8e64-a6ce94efb80e@github.com>

On Fri, 28 Apr 2023 21:59:41 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase.
>
> src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 457:
> 
>> 455:             // For TLS 1.2 and prior versions, the HelloRequest message MAY
>> 456:             // be sent by the server at any time.
>> 457:             consumer = conContext.sslConfig.isClientMode ?
> 
> This seems reasonable, but could you update the bug report to say why this fixes the problem?

If we're in server mode, we want the consumer to be null so that we don't attempt to cast a Server object as a Client object further down in the stack. Having the consumer be null forces the check on the new line 463 to pass and throws the message for "unexpected handshake message".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13727#discussion_r1184268590

From jiangli at openjdk.org  Wed May  3 21:12:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 21:12:27 GMT
Subject: RFR: 8307134: Add GTS root CAs [v4]
In-Reply-To: <oNepiTh7U7SAgtcC6w1V5srpSUS8pe-N0F9FerMb650=.8a04b1c7-fbdf-4773-9a3d-cf3f6f984d82@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
 <9z1iBDP-o2ds0wjAGz7eg1pzkAXiAFtgoYwVrVql9cE=.e67939cc-5eae-4c4f-8a87-50bc2cebadd2@github.com>
 <oNepiTh7U7SAgtcC6w1V5srpSUS8pe-N0F9FerMb650=.8a04b1c7-fbdf-4773-9a3d-cf3f6f984d82@github.com>
Message-ID: <HryZMa116sbnh7ra-Ps8rDqTGZRishla_7QiOOCb8NQ=.6e18d43c-a750-48f0-a395-439874faa27e@github.com>

On Wed, 3 May 2023 17:42:14 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Looks good to me. Please don't forget to update the release note and backport to JDK 20u.

Thanks @rhalade. Will do.

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

PR Comment: https://git.openjdk.org/jdk/pull/13754#issuecomment-1533751038

From jiangli at openjdk.org  Wed May  3 21:12:29 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 21:12:29 GMT
Subject: Integrated: 8307134: Add GTS root CAs
In-Reply-To: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
References: <AnvhTDdcQuU_OT8QsN4ETG37uU6FQjFe3H7E75LyyPw=.15f32084-5325-4f47-9e57-98e036aad51a@github.com>
Message-ID: <1UUewea-gbxxlJcLjUIlzC9mXWTP1kqqiW-YNgVxVwU=.4bbe0700-624a-4f14-897a-2401e5abe5af@github.com>

On Tue, 2 May 2023 16:35:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR was requested by awarner at google.com. The updates were provided by awarner at google.com.

This pull request has now been integrated.

Changeset: 03030d47
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03030d47ebee5c20919fe0162ec86d3d400cd955
Stats:     748 lines in 6 files changed: 745 ins; 0 del; 3 mod

8307134: Add GTS root CAs

Co-authored-by: Andy Warner <awarner at google.com>
Co-authored-by: Rajan Halade <rhalade at openjdk.org>
Reviewed-by: mullan, rhalade

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

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

From kdriver at openjdk.org  Wed May  3 22:14:17 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 3 May 2023 22:14:17 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v3]
In-Reply-To: <BLTahgtHIDyiZd-M7SBz_jdBC6xByNj5boeO_QRB6T8=.617c647f-97ee-4690-b7a3-aee5c96c2835@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <BLTahgtHIDyiZd-M7SBz_jdBC6xByNj5boeO_QRB6T8=.617c647f-97ee-4690-b7a3-aee5c96c2835@github.com>
Message-ID: <cOSGEHmDgqIrJImmSziZ2lRLQMu2PpdXw9Si0btDQ7Q=.4e1c0324-78f5-406b-904b-7c62701ccdf0@github.com>

On Fri, 28 Apr 2023 19:15:59 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
>   
>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

As for other examples of the `X500Principal(byte[] ..)` constructor being called in TLS packages, here are the ones that don't seem to be handled nicely currently: 

- `consume` in `CertificateAuthoritiesExtension.CRCertificateAuthoritiesConsumer` (could throw IAE, which is an uncaught RuntimeException)
- `toString` in `CertificateAuthoritiesExtension.CertificateAuthoritiesSpec` (could throw IAE, which is an uncaught RuntimeException)
- `consume` in `CertificateRequest.T10CertificateRequestConsumer` (could throw IAE, which is an uncaught RuntimeException)
- `toString` in `CertificateRequest.T10CertificateRequestMessage` (could throw IAE, which is an uncaught RuntimeException)
- `consume` in `CertificateRequest.T12CertificateRequestConsumer` (could throw IAE, which is an uncaught RuntimeException)
- `toString` in `CertificateRequest.T12CertificateRequestMessage` (could throw IAE, which is an uncaught RuntimeException)

I will look at making related changes in these spots as well. 

@XueleiFan wrt your other question about updating the `getAuthorities` method, I considered this, but it looks like it would involve changing a method signature for that method. This may be fine, but similar changes would need to be made in all the above places anyway, I suspect, unless we can pass information about the context in order to throw an `SSL(Protocol)Exception` and have that bubble-up to where `IOException`s are usually checked. 

@seanjmullan @XueleiFan thoughts on that?

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

PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1533818757

From wetmore at openjdk.org  Thu May  4 00:21:17 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 4 May 2023 00:21:17 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
 [v3]
In-Reply-To: <IMFPAb9UJivx7B2O5GNfwWzgjlwVPTsfAzZYU1KfZ1o=.fffabbf5-2dcc-46bd-a20b-b350d53f7a1c@github.com>
References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
 <IMFPAb9UJivx7B2O5GNfwWzgjlwVPTsfAzZYU1KfZ1o=.fffabbf5-2dcc-46bd-a20b-b350d53f7a1c@github.com>
Message-ID: <ydkQH2Q4DUOv4280NkzzWzd9t7IkWSxcG61sj6Bjh48=.5477775b-95e9-412f-abc8-d480a4a0c894@github.com>

On Wed, 3 May 2023 20:51:30 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`.
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - address code review comment
>  - updated copyright
>  - set consumer to null if we're not in client mode

Other than the comment suggestion, LGTM.  

Putting comment in the bug as Mark suggested requires archeology, thus I suggest it be directly in the codebase.  I'm a huge proponent of comments when things aren't always obvious.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13727#pullrequestreview-1412071577

From wetmore at openjdk.org  Thu May  4 00:21:19 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 4 May 2023 00:21:19 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
 [v2]
In-Reply-To: <1O1K7-gg4FNOVcwG1g44zUW08CtEuCNz5qbjXNy8X6I=.9c87a9d0-52c8-4224-8e64-a6ce94efb80e@github.com>
References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
 <46VV0QjRRaN1QJ2B6hw8ibfrtL14iFpWuwfEAVG1bCg=.013b7924-2112-4141-8c72-8dcccfac9cde@github.com>
 <6BXxNg4GFFYBW45XqG79pNGrTZQsaJgrqoKh--ycLis=.dc8e1050-bc14-4cd4-afde-3d431b863479@github.com>
 <1O1K7-gg4FNOVcwG1g44zUW08CtEuCNz5qbjXNy8X6I=.9c87a9d0-52c8-4224-8e64-a6ce94efb80e@github.com>
Message-ID: <NiyYbiH9N9-jh5KR1jGg0jqZv9ClsaiFYyAWMLSpg88=.6fdcf8e2-943a-46b2-9b7a-9d687717aca8@github.com>

On Wed, 3 May 2023 20:52:34 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/HandshakeContext.java line 457:
>> 
>>> 455:             // For TLS 1.2 and prior versions, the HelloRequest message MAY
>>> 456:             // be sent by the server at any time.
>>> 457:             consumer = conContext.sslConfig.isClientMode ?
>> 
>> This seems reasonable, but could you update the bug report to say why this fixes the problem?
>
> If we're in server mode, we want the consumer to be null so that we don't attempt to cast a Server object as a Client object further down in the stack. Having the consumer be null forces the check on the new line 463 to pass and throws the message for "unexpected handshake message".

This would an good comment to have in the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13727#discussion_r1184417783

From valeriep at openjdk.org  Thu May  4 02:07:22 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 4 May 2023 02:07:22 GMT
Subject: RFR: 8155191: SunPKCS11's SecureRandom#nextBytes(byte[]) accepts null
 argument
Message-ID: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>

Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.

Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.

CSR has been filed.

Thanks,
Valerie

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

Commit messages:
 - 8155191: SunPKCS11's SecureRandom#nextBytes(byte[]) accepts null argument

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

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

From xuelei at openjdk.org  Thu May  4 02:33:14 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 4 May 2023 02:33:14 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
 [v3]
In-Reply-To: <IMFPAb9UJivx7B2O5GNfwWzgjlwVPTsfAzZYU1KfZ1o=.fffabbf5-2dcc-46bd-a20b-b350d53f7a1c@github.com>
References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
 <IMFPAb9UJivx7B2O5GNfwWzgjlwVPTsfAzZYU1KfZ1o=.fffabbf5-2dcc-46bd-a20b-b350d53f7a1c@github.com>
Message-ID: <VIkselSplETCRsU9g3i_YRqV3pBwGc9pyEF91EHRrBM=.aefc5598-db79-42f6-a80e-df012568ec4d@github.com>

On Wed, 3 May 2023 20:51:30 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`.
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - address code review comment
>  - updated copyright
>  - set consumer to null if we're not in client mode

Marked as reviewed by xuelei (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13727#pullrequestreview-1412177409

From mullan at openjdk.org  Thu May  4 13:02:17 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 4 May 2023 13:02:17 GMT
Subject: RFR: 8155191: SunPKCS11's SecureRandom#nextBytes(byte[]) accepts
 null argument
In-Reply-To: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
Message-ID: <T_qWQvoFmWZXajONWnJqdpPgSBjE_mMIpQ02v1Vpmjc=.5cfbd1c2-3b12-4123-8735-55d2d7f3e881@github.com>

On Thu, 4 May 2023 01:58:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.
> 
> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.
> 
> CSR has been filed.
> 
> Thanks,
> Valerie

I suggest the title of this issue should be changed to better reflect the proposed change: "Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null".

Also, would you consider making the same change to `SecureRandom.setSeed(byte[])` as part of this change? I'm pretty sure all JDK SR impls throw NPE if the array is null.

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

PR Comment: https://git.openjdk.org/jdk/pull/13788#issuecomment-1534734886

From duke at openjdk.org  Thu May  4 15:18:17 2023
From: duke at openjdk.org (Sergey Chernyshev)
Date: Thu, 4 May 2023 15:18:17 GMT
Subject: RFR: 8168469: Memory leak in JceSecurity
In-Reply-To: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
References: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
Message-ID: <V7-Ucq2gMAkD-t6JZL56Yu2nBmPL5JRmR4oKTykA2hg=.492d272e-1c00-49c9-a36c-30787c58a0db@github.com>

On Tue, 25 Apr 2023 21:16:41 GMT, Sergey Chernyshev <duke at openjdk.org> wrote:

> Hi all,
> 
> I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME.
> 
> The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap<Class<? extends Provider>, Object>` instead of `IdentityHashMap<Provider, Object>`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper<Provider> `objects that maintained the object identity while improved performance.
> 
> The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference<Object>` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called.
> 
> `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers.
> 
> I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test.
> 
> Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions
> 
> [1] https://mail.openjdk.org/pipermail/security-dev/2016-October/015024.html
> [2] https://bugs.openjdk.org/browse/JDK-8168469
> [3] https://bugs.openjdk.org/browse/JDK-7107615
> [4] https://github.com/openjdk/jdk/commit/74d45e481d1ad6aa5d7c6315ea86681e1a978ce0

@valeriepeng Could you please take a look at this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/13658#issuecomment-1534961823

From asotona at openjdk.org  Thu May  4 16:15:12 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 May 2023 16:15:12 GMT
Subject: RFR: 8250596: Update remaining manpage references from "OS X" to
 "macOS"
Message-ID: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>

Most of the manpages were updated a few years ago but some references remain.
This patch renames remaining references to "macOS".

Please review.

Thanks,
Adam

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

Commit messages:
 - 8250596: Update remaining manpage references from "OS X" to "macOS"

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

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

From hchao at openjdk.org  Thu May  4 16:48:14 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 4 May 2023 16:48:14 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
Message-ID: <DqqZaQeL8wh353TqOsLvJBSHsysFkPlSpO1SUhtqgXQ=.bbb8387d-837d-4877-a898-622edd7ac4c2@github.com>

On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
> 
> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
> 
> Thanks,
> Valerie

test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java line 176:

> 174: 
> 175:         // should only have "pk1" now
> 176:         checkEntry(ks, "pk1", pk1Chain);

When the kesytore should only have "pk1? now, how would checkEntry(ks, "pk1", pk1Chain) succeed as it expects to have the ?ca.cert? in the pk1Chain? The ?ca.cert? shall not be deleted because ?pk1.cert? depends on it. I may have missed something here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1183111954

From mullan at openjdk.org  Thu May  4 17:02:12 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 4 May 2023 17:02:12 GMT
Subject: RFR: 8250596: Update remaining manpage references from "OS X" to
 "macOS"
In-Reply-To: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
References: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
Message-ID: <A8lnR4HyVM50BarzAlTn5sgFWYB2w-qZQ7-27UPunp4=.3499ea36-81fb-4750-87b2-09ee5ff01ceb@github.com>

On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
> 
> Please review.
> 
> Thanks,
> Adam

keytool and jarsigner docs look good.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13807#pullrequestreview-1413524329

From valeriep at openjdk.org  Thu May  4 19:01:17 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 4 May 2023 19:01:17 GMT
Subject: RFR: 8155191: SunPKCS11's SecureRandom#nextBytes(byte[]) accepts
 null argument
In-Reply-To: <T_qWQvoFmWZXajONWnJqdpPgSBjE_mMIpQ02v1Vpmjc=.5cfbd1c2-3b12-4123-8735-55d2d7f3e881@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
 <T_qWQvoFmWZXajONWnJqdpPgSBjE_mMIpQ02v1Vpmjc=.5cfbd1c2-3b12-4123-8735-55d2d7f3e881@github.com>
Message-ID: <LuDLfkRhQGsAfDbIyZL0k9OQDS6N-GHKQ5EyKbM4RpI=.56a41088-29e2-45c4-8060-f23b7f9e955b@github.com>

On Thu, 4 May 2023 12:59:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I suggest the title of this issue should be changed to better reflect the proposed change: "Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null".

Ok.

> Also, would you consider making the same change to `SecureRandom.setSeed(byte[])` as part of this change? I'm pretty sure all JDK SR impls throw NPE if the array is null.

Hmm, let me try it out. If the behavior is consistent NPE, I can include that as part of this PR/CSR as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/13788#issuecomment-1535256656

From cjplummer at openjdk.org  Thu May  4 19:24:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 4 May 2023 19:24:13 GMT
Subject: RFR: 8250596: Update remaining manpage references from "OS X" to
 "macOS"
In-Reply-To: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
References: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
Message-ID: <WCM8_9S3idud9dlq_stYzAIwsozuGFR8RQYh3Kl3Avc=.39795392-6414-46a6-9643-fcce39adf319@github.com>

On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
> 
> Please review.
> 
> Thanks,
> Adam

The jstatd.1 and jstat.1 files look good.

Copyrights need updating on all the files.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13807#pullrequestreview-1413771872

From kdriver at openjdk.org  Thu May  4 19:29:05 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 4 May 2023 19:29:05 GMT
Subject: RFR: 8294983: SSLEngine throws ClassCastException during handshake
 [v4]
In-Reply-To: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
Message-ID: <a5z7MzemeFpdb357wOxzISYJqevdW6w5cAvVxZEHFsg=.e29ac03b-f5b0-408d-a817-a032ef6e9f27@github.com>

> Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`.

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

  added explanatory comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13727/files
  - new: https://git.openjdk.org/jdk/pull/13727/files/0754990b..24956f70

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

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

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

From kdriver at openjdk.org  Thu May  4 19:29:07 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 4 May 2023 19:29:07 GMT
Subject: Integrated: 8294983: SSLEngine throws ClassCastException during
 handshake
In-Reply-To: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
References: <1kkeSrj_ijTxQCy4CLLl_SjV0fe__XkUuZ4o1M84vmk=.28f68b76-c98e-4b68-8e6c-7755f140861c@github.com>
Message-ID: <xqTKT3AGPU3HxzLvwhZDWUBYcVGPyVOk2bL3gXbr76U=.309e5538-f84b-49ff-a4cd-941f9ecd1fd2@github.com>

On Fri, 28 Apr 2023 19:28:03 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> Fixes a scenario where a `ServerHandshakeContext` might be cast as a `ClientHandshakeContext`.

This pull request has now been integrated.

Changeset: 197d0cc6
Author:    Kevin Driver <kdriver at openjdk.org>
Committer: Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/197d0cc6031cb470f1bd7678796593ff1bf440ca
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

8294983: SSLEngine throws ClassCastException during handshake

Co-authored-by: Daniel Jeli?ski <djelinski at openjdk.org>
Reviewed-by: wetmore, xuelei

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

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

From dcubed at openjdk.org  Thu May  4 21:13:37 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 May 2023 21:13:37 GMT
Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on
 windows-x64
Message-ID: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>

Trivial fixes to ProblemList a few tests:
- [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
- [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
- [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64

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

Commit messages:
 - get rid of extra blank line.
 - 8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64
 - 8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
 - 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64

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

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

From darcy at openjdk.org  Thu May  4 21:24:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 21:24:14 GMT
Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java
 on windows-x64
In-Reply-To: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
References: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
Message-ID: <EY3NbZcRqVFRbEAUPmX2P0Av05zMpFltxvfV6gd52Jw=.33eb040d-d6f3-4e72-a6cb-6079dc17ea8e@github.com>

On Thu, 4 May 2023 20:49:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList a few tests:
> - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
> - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
> - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13816#pullrequestreview-1413942638

From dcubed at openjdk.org  Thu May  4 21:35:39 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 May 2023 21:35:39 GMT
Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java
 on windows-x64
In-Reply-To: <EY3NbZcRqVFRbEAUPmX2P0Av05zMpFltxvfV6gd52Jw=.33eb040d-d6f3-4e72-a6cb-6079dc17ea8e@github.com>
References: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
 <EY3NbZcRqVFRbEAUPmX2P0Av05zMpFltxvfV6gd52Jw=.33eb040d-d6f3-4e72-a6cb-6079dc17ea8e@github.com>
Message-ID: <bNAIHHKnuD_dPNv3KMdXkhdTujoTAPHtnYFYZlRgq98=.92a37688-c068-49e7-b63e-feae4a7b78e1@github.com>

On Thu, 4 May 2023 21:21:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial fixes to ProblemList a few tests:
>> - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
>> - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
>> - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/13816#issuecomment-1535438955

From dcubed at openjdk.org  Thu May  4 21:35:40 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 May 2023 21:35:40 GMT
Subject: Integrated: 8307489: ProblemList
 jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
In-Reply-To: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
References: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
Message-ID: <pMB1azRoke_aMHgRzPADeFvcOEuEt7vEvbyY3wFcYLo=.b4ff8a70-1c09-4c81-923e-b48325b282e9@github.com>

On Thu, 4 May 2023 20:49:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList a few tests:
> - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
> - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
> - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64

This pull request has now been integrated.

Changeset: 111858f3
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/111858f3ff86a15666537df515375fa04ffef048
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64

Reviewed-by: darcy

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

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

From weijun at openjdk.org  Thu May  4 21:52:28 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 4 May 2023 21:52:28 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
Message-ID: <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>

On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding key translation, finally block, removing 24-byte LMOTS parameters

src/java.base/share/classes/sun/security/provider/HSS.java line 94:

> 92:             result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray());
> 93:             return result;
> 94:         } catch (Exception e) {

If all exceptions thrown are already `SignatureException`, we can let them thrown out instead of returning false. According to the `engineVerify` spec, any problem inside the signature should throw a `SignatureException`. False is returned when the public key cannot verify the exception.

src/java.base/share/classes/sun/security/provider/HSS.java line 181:

> 179:             try {
> 180:                 lmParams = new LMParams(type);
> 181:                 lmotsParams = LMOTSParams.of(otsType);

Try to code `LMParams` and `LMOTSParams` the same style by choosing from using a constructor or static `of` method. Should `LMParams` be renamed to `LMSParams`?

src/java.base/share/classes/sun/security/provider/HSS.java line 294:

> 292:         LMOTSignature(byte[] sigArray, LMOTSParams lmotsParams) throws InvalidParameterException {
> 293:             int inLen = sigArray.length;
> 294:             if (inLen < 4)

Add braces around the one-line block. Same as in lines 300, 173, 461, 472, 487, 569, 571, and 783.

src/java.base/share/classes/sun/security/provider/HSS.java line 295:

> 293:             int inLen = sigArray.length;
> 294:             if (inLen < 4)
> 295:                 throw new InvalidParameterException("Invalid LMS signature");

This is LM-OTS signature. Also, give some explanation. Same on line 301.

src/java.base/share/classes/sun/security/provider/HSS.java line 357:

> 355:                     break;
> 356: 
> 357: /*

Remove commented-out lines if they cannot be supported on time.

src/java.base/share/classes/sun/security/provider/HSS.java line 459:

> 457:         final byte[] sigArr;
> 458: 
> 459:         public LMSignature(byte[] sigArray, int offset, boolean checkExactLen) throws InvalidParameterException {

How about we throw a `SignatureException` here. `new HSSSignature` and `new LMOTSignature` all throw it.

src/java.base/share/classes/sun/security/provider/HSS.java line 528:

> 526:         // update()-digest() sequence) which is parametrized so that the digest output is copied back into this buffer.
> 527:         // This way, we avoid memory allocations and some computations that would have to be done otherwise.
> 528:         final byte[] hashBuf;

I'm a little worried about the mutability of `hashBuf` and whether it's suitable to be put inside `LMOTSParams`.  By using `of` to return an `LMOTSParams` object we have the chance to return cached objects in the future. There should always be one `hashBuf` for each LM-OTS verification, and this is not clear from the current code.

src/java.base/share/classes/sun/security/provider/HSS.java line 659:

> 657:         }
> 658:         public byte[] lmotsPubKeyCandidate(LMSignature lmSig, byte[] message, LMSPublicKey pKey)
> 659:                 throws NoSuchAlgorithmException, DigestException {

`DigestException` should not happen because we allocate all the buffer ourselves. `NoSuchAlgorithmException` should not happen because we should have all the algorithms. If they do happen, that's not user problem at all. I think the usual way is to wrap them into a `ProviderException`. This is also true in `lmsVerify()`.

src/java.base/share/classes/sun/security/provider/HSS.java line 662:

> 660:             LMOTSignature lmOtSig = lmSig.lmotSig;
> 661:             if (lmOtSig.otSigType != pKey.otsType) {
> 662:                 throw new IllegalArgumentException("OTS public key type and OTS signature type do not match");

I'd rather throw `SignatureException`. This method is actually verifying an LM-OTS signature, right?

src/java.base/share/classes/sun/security/provider/HSS.java line 736:

> 734:                 }
> 735:             }
> 736:             throw new InvalidKeySpecException();

Give an error message. Try look at what other factories are doing. Same for lines 751, 768, 727, 44, 49, and 57.

src/java.base/share/classes/sun/security/provider/HSS.java line 745:

> 743: 
> 744:         @Override
> 745:         protected <T extends KeySpec> T engineGetKeySpec(Key key, Class<T> keySpec) throws InvalidKeySpecException {

Usually when `key` is null an `InvalidKeySpecException` is thrown. Here it's an NPE.

src/java.base/share/classes/sun/security/provider/HSS.java line 809:

> 807:         HSSSignature(byte[] sigArr, int pubKeyL, String pubKeyHashAlg) throws SignatureException {
> 808:             if (sigArr.length < 4) {
> 809:                 throw new SignatureException("Bad HSS signature");

Maybe you can say why it is bad. This also applies to "Invalid HSS public key", "Invalid LMS signature" and "Invalid LMS public key" messages.

src/java.base/share/classes/sun/security/provider/HSS.java line 823:

> 821:                     index += siglist[i].sigArrayLength();
> 822:                     pubList[i] = new LMSPublicKey(sigArr, index, false);
> 823:                     if (!pubList[i].getDigestAlgorithm().equals(pubKeyHashAlg)) {

Comparing hash algorithm is not enough. Length (`m`) should also be compared.

src/java.base/share/classes/sun/security/provider/HSS.java line 829:

> 827:                 }
> 828:                 siglist[Nspk] = new LMSignature(sigArr, index, true);
> 829:             } catch (Exception E) {

The `SignatureException` thrown on line 824 does not need to be wrapped into another `SignatureException`. Maybe just catch `InvalidKeyException` (if you throw `SignatureException` in `new LMSSignature`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185459409
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185523625
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185518085
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185540342
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185521512
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185512129
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185533184
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185503139
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185544334
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185546621
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185508073
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185535770
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185536879
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185497769

From weijun at openjdk.org  Thu May  4 21:57:19 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 4 May 2023 21:57:19 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
Message-ID: <oYPeVFp3vcCjdh4JUOU5N9iwjjVVkOgiY4D5MWkkaOI=.4528f68f-d254-4154-b666-f490f711b027@github.com>

On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding key translation, finally block, removing 24-byte LMOTS parameters

One more comment on exceptions.

src/java.base/share/classes/sun/security/provider/HSS.java line 467:

> 465:             qArr = Arrays.copyOfRange(sigArray, offset, offset + 4);
> 466:             sigOtsType = LMSUtils.fourBytesToInt(sigArray, offset + 4);
> 467:             LMOTSParams lmotsParams = LMOTSParams.of(sigOtsType);

Catch `IllegalArgumentException` here and rethrow a `SignatureException`. Same on line 482.

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

PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1413972348
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1185552104

From dholmes at openjdk.org  Thu May  4 22:51:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 May 2023 22:51:12 GMT
Subject: RFR: 8250596: Update remaining manpage references from "OS X" to
 "macOS"
In-Reply-To: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
References: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
Message-ID: <c3NlVDGlmtFB9EyfreO3wXoQkX4rzvdSq71OhuKF0p8=.cafa0011-5b08-4e76-b410-d4db5eec4b05@github.com>

On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
> 
> Please review.
> 
> Thanks,
> Adam

Looks good.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13807#pullrequestreview-1414016697

From valeriep at openjdk.org  Fri May  5 01:21:32 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 5 May 2023 01:21:32 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v2]
In-Reply-To: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
Message-ID: <9GKBTRwAn2vsNoXU6-raZPYjUq9n3JVxdSsANcL0EDA=.0840997c-882c-4c1a-97da-318d50901967@github.com>

> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.
> 
> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.
> 
> CSR has been filed.
> 
> Thanks,
> Valerie

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

  Add NPE for SecureRandom(byte[]) ctor and setSeed(byte[]) method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13788/files
  - new: https://git.openjdk.org/jdk/pull/13788/files/27687285..34ebdfa7

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

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

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

From sspitsyn at openjdk.org  Fri May  5 07:30:14 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 5 May 2023 07:30:14 GMT
Subject: RFR: 8250596: Update remaining manpage references from "OS X" to
 "macOS"
In-Reply-To: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
References: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
Message-ID: <HX5UhqTupkd2Lvdy0zr3Azk7-GpWcHQ_2GOQQIH0LgI=.dee743f7-64ea-4e06-bb81-61d4d88ee148@github.com>

On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13807#pullrequestreview-1414295424

From asotona at openjdk.org  Fri May  5 08:40:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 5 May 2023 08:40:27 GMT
Subject: RFR: 8250596: Update remaining manpage references from "OS X" to
 "macOS" [v2]
In-Reply-To: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
References: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
Message-ID: <w8owVxgYd4amJpb37Bl1CWoMBJyWxx8VIufU7zxb5V0=.0a32289f-7b47-428e-a478-915326f6f5f2@github.com>

> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13807/files
  - new: https://git.openjdk.org/jdk/pull/13807/files/88c2d42c..00e12f4b

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

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

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

From asotona at openjdk.org  Fri May  5 08:58:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 5 May 2023 08:58:54 GMT
Subject: Integrated: 8250596: Update remaining manpage references from "OS X"
 to "macOS"
In-Reply-To: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
References: <VL1AjRDZuWCaOIVHPC9Kf1sTLtIxtrT94AMLzZyPawI=.6cc5b2b6-021b-4bef-bb8f-0a840afafbc8@github.com>
Message-ID: <PkzozhiJazVVbrG7OqbOtk0J3I1vzvonWjS20LYK39U=.2012ee31-7af4-498b-92a7-cb761d49a411@github.com>

On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 3b430b9f
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b430b9f732bc94674bf598c28162e2f5e62bae6
Stats:     23 lines in 7 files changed: 0 ins; 0 del; 23 mod

8250596: Update remaining manpage references from "OS X" to "macOS"

Reviewed-by: mullan, cjplummer, dholmes, sspitsyn

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

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

From duke at openjdk.org  Fri May  5 11:34:27 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 5 May 2023 11:34:27 GMT
Subject: RFR: 8305169:
 java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server
 didn't start in timely manner
Message-ID: <e-SR5PD2uQtEm86wtmU5dV4QJRHp2fgTj9FZE99Dhnw=.a433d2db-de9d-42a2-ab44-361ff139d43f@github.com>

Could someone please review this PR? It is a small change to increase the time that the client waits for the server thread to start.

Thanks!

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

Commit messages:
 - 8305169: java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server didn't start in timely manner

Changes: https://git.openjdk.org/jdk/pull/13829/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13829&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305169
  Stats: 28 lines in 2 files changed: 17 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13829/head:pull/13829

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

From ssahoo at openjdk.org  Fri May  5 12:34:16 2023
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 5 May 2023 12:34:16 GMT
Subject: RFR: 8305169:
 java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server
 didn't start in timely manner
In-Reply-To: <e-SR5PD2uQtEm86wtmU5dV4QJRHp2fgTj9FZE99Dhnw=.a433d2db-de9d-42a2-ab44-361ff139d43f@github.com>
References: <e-SR5PD2uQtEm86wtmU5dV4QJRHp2fgTj9FZE99Dhnw=.a433d2db-de9d-42a2-ab44-361ff139d43f@github.com>
Message-ID: <5nRhiX0WNvw-Yicc4OEKgTmUScfKkb3SFEYLi8c0S24=.dd818fde-0723-47a8-b249-e6dfb37289d7@github.com>

On Fri, 5 May 2023 11:27:48 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Could someone please review this PR? It is a small change to increase the time that the client waits for the server thread to start.
> 
> Thanks!

Please wait for a reviewer to complete the review.

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

Marked as reviewed by ssahoo (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13829#pullrequestreview-1414699616

From jnimeh at openjdk.org  Fri May  5 14:05:24 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 5 May 2023 14:05:24 GMT
Subject: RFR: 8305169:
 java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server
 didn't start in timely manner
In-Reply-To: <e-SR5PD2uQtEm86wtmU5dV4QJRHp2fgTj9FZE99Dhnw=.a433d2db-de9d-42a2-ab44-361ff139d43f@github.com>
References: <e-SR5PD2uQtEm86wtmU5dV4QJRHp2fgTj9FZE99Dhnw=.a433d2db-de9d-42a2-ab44-361ff139d43f@github.com>
Message-ID: <MjGcAmHzjX2aJitBMWEk-hnN6tCwzmAuDTwnBO6NXXY=.f3af5408-e02e-4b32-8dd4-1988d2d3cf57@github.com>

On Fri, 5 May 2023 11:27:48 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Could someone please review this PR? It is a small change to increase the time that the client waits for the server thread to start.
> 
> Thanks!

Marked as reviewed by jnimeh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13829#pullrequestreview-1414857598

From duke at openjdk.org  Fri May  5 14:20:30 2023
From: duke at openjdk.org (Matthew Donovan)
Date: Fri, 5 May 2023 14:20:30 GMT
Subject: Integrated: 8305169:
 java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server
 didn't start in timely manner
In-Reply-To: <e-SR5PD2uQtEm86wtmU5dV4QJRHp2fgTj9FZE99Dhnw=.a433d2db-de9d-42a2-ab44-361ff139d43f@github.com>
References: <e-SR5PD2uQtEm86wtmU5dV4QJRHp2fgTj9FZE99Dhnw=.a433d2db-de9d-42a2-ab44-361ff139d43f@github.com>
Message-ID: <18WvSaSoJTJASLrZGZQYCJqtl9cqiXXYRofvah1cEPQ=.ce37667e-5e6e-4082-9c5c-8aa4565ae3e9@github.com>

On Fri, 5 May 2023 11:27:48 GMT, Matthew Donovan <duke at openjdk.org> wrote:

> Could someone please review this PR? It is a small change to increase the time that the client waits for the server thread to start.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 3f6a3545
Author:    Matthew Donovan <matthew.p.donovan at oracle.com>
Committer: Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f6a3545a255cbef3c3436ff26481f1cec4ccfc9
Stats:     28 lines in 2 files changed: 17 ins; 8 del; 3 mod

8305169: java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java -- test server didn't start in timely manner

Reviewed-by: ssahoo, jnimeh

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

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

From weijun at openjdk.org  Fri May  5 14:31:17 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 May 2023 14:31:17 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
Message-ID: <5jPCrDCpjkHcnEsquRdHiG1MpPcNnr3gduXawzaIXiA=.c8c0ee74-34ae-4767-ab52-a09b10683dee@github.com>

On Wed, 5 Apr 2023 16:45:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248)
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedback

We have quite some `standard-names.html#anchorName` links (Ex: https://github.com/openjdk/jdk/blob/f804f2ce8ef7a859aae021b20cbdcd9e34f9fb94/src/java.base/share/classes/java/security/Signature.java#L111). I don't see any of them here. Is this style allowed in a `@spec` tag?

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

PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1536346418

From mullan at openjdk.org  Fri May  5 14:59:24 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 5 May 2023 14:59:24 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
Message-ID: <I5VC1o20frwyUcKjqxIpTDIBNWoKdlLIT_ElQCz-xC4=.792a9510-cdf7-466a-9431-a0c4068b9b69@github.com>

On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding key translation, finally block, removing 24-byte LMOTS parameters

Some of the files (SunEntries, KnownOIDs, SHA2, P11Key) are missing 2023 copyright dates.

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

PR Comment: https://git.openjdk.org/jdk/pull/13691#issuecomment-1536384833

From mullan at openjdk.org  Fri May  5 15:07:18 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 5 May 2023 15:07:18 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
Message-ID: <6mj0683ApqoyzucG4pEp4c8S91Id9oyJliEJEmjKma8=.e7632576-8472-40b5-b5f1-aefe9471aeac@github.com>

On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding key translation, finally block, removing 24-byte LMOTS parameters

src/java.base/share/classes/sun/security/util/RawKeySpec.java line 30:

> 28: import java.security.spec.KeySpec;
> 29: 
> 30: public class RawKeySpec  implements KeySpec {

Nit, should be one space between `RawKeySpec` and `implements`.

src/java.base/share/classes/sun/security/util/RawKeySpec.java line 30:

> 28: import java.security.spec.KeySpec;
> 29: 
> 30: public class RawKeySpec  implements KeySpec {

Can you add some comments describing this class?

src/java.base/share/classes/sun/security/util/RawKeySpec.java line 31:

> 29: 
> 30: public class RawKeySpec  implements KeySpec {
> 31:     final private byte[] keyArr;

Put `private` before `final`.

src/java.base/share/classes/sun/security/util/RawKeySpec.java line 33:

> 31:     final private byte[] keyArr;
> 32:     /**
> 33:      * The sole constructor

Nit: add period at end of sentence and an empty line after this (before the `@param`).

src/java.base/share/classes/sun/security/util/RawKeySpec.java line 37:

> 35:      */
> 36:     public RawKeySpec(byte[] key) {
> 37:         keyArr = key.clone();

Does this need to be cloned if it is an internal class?

src/java.base/share/classes/sun/security/util/RawKeySpec.java line 41:

> 39: 
> 40:     /**
> 41:      * Getter function

Nit: add period at end of sentence and an empty line after this (before the @return).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186201989
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186202683
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186205743
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186204113
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186204543
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186205020

From weijun at openjdk.org  Fri May  5 17:00:17 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 May 2023 17:00:17 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
Message-ID: <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>

On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
> 
> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
> 
> Thanks,
> Valerie

Is it possible to generate the keys and certs on the fly?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2031:

> 2029:                             cert.getSubjectX500Principal() + "]");
> 2030:                     }
> 2031:                 } else {

If `destroyIt` is false for the 1st cert, are you going to return false? Maybe it does not matter.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2057:

> 2055:                         currHdl = ch[0];
> 2056:                     } else {
> 2057:                         currHdl = 0L;

Maybe just `break`?

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

PR Review: https://git.openjdk.org/jdk/pull/13743#pullrequestreview-1415118643
PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186303587
PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186299589

From weijun at openjdk.org  Fri May  5 18:04:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 May 2023 18:04:40 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2
Message-ID: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>

Update XML Security for Java to 3.0.2. Some change to tests:

1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

Commit messages:
 - the change

Changes: https://git.openjdk.org/jdk/pull/13840/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305972
  Stats: 1145 lines in 41 files changed: 845 ins; 203 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/13840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840

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

From valeriep at openjdk.org  Fri May  5 19:46:18 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 5 May 2023 19:46:18 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <DqqZaQeL8wh353TqOsLvJBSHsysFkPlSpO1SUhtqgXQ=.bbb8387d-837d-4877-a898-622edd7ac4c2@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <DqqZaQeL8wh353TqOsLvJBSHsysFkPlSpO1SUhtqgXQ=.bbb8387d-837d-4877-a898-622edd7ac4c2@github.com>
Message-ID: <RR9Vz339D48pes1YzeS_ky95PZK2ig_K852IwLrl3HU=.04660590-5cc3-41df-b5d3-619a8dd7c1c5@github.com>

On Tue, 2 May 2023 22:42:13 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
>> 
>> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
>> 
>> Thanks,
>> Valerie
>
> test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java line 176:
> 
>> 174: 
>> 175:         // should only have "pk1" now
>> 176:         checkEntry(ks, "pk1", pk1Chain);
> 
> When the kesytore should only have "pk1? now, how would checkEntry(ks, "pk1", pk1Chain) succeed as it expects to have the ?ca.cert? in the pk1Chain? The ?ca.cert? shall not be deleted because ?pk1.cert? depends on it. I may have missed something here.

I mean "pk1" entrry, not just "pk1" cert. As you can see, the test checks for the complete cert chain for "pk1" entry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186446763

From mullan at openjdk.org  Fri May  5 19:50:22 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 5 May 2023 19:50:22 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
Message-ID: <erFxtT_f73YLetiFFKAl4wZS2YCdDMk_eLV3jtnsqGo=.0f0ba2fc-ce0d-4e64-88e2-74b0b0982f15@github.com>

On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding key translation, finally block, removing 24-byte LMOTS parameters

src/java.base/share/classes/sun/security/provider/HSS.java line 37:

> 35: import java.util.Arrays;
> 36: import java.util.Objects;
> 37: 

Can you add some comments describing this class?

src/java.base/share/classes/sun/security/provider/HSS.java line 38:

> 36: import java.util.Objects;
> 37: 
> 38: public class HSS extends SignatureSpi {

Make the class `final`?

src/java.base/share/classes/sun/security/provider/HSS.java line 43:

> 41: 
> 42:     @Deprecated
> 43:     protected void engineSetParameter(String param, Object value) {

Technically, this API is not defined to throw UOE. I think throwing IPE is better and would be compliant with the specification. (I am aware that there are other JDK SignatureSpi implementations that already throw UOE for this method, but they should be fixed).

src/java.base/share/classes/sun/security/provider/HSS.java line 48:

> 46: 
> 47:     @Deprecated
> 48:     protected AlgorithmParameters engineGetParameter(String param) {

Same comment as above.

src/java.base/share/classes/sun/security/provider/HSS.java line 56:

> 54:     }
> 55: 
> 56:     protected byte[] engineSign() throws SignatureException {

This API is not defined to throw UOE. Suggest throwing `SignatureException` instead with a message "Signing is not supported".

Though, technically this method should never be called, as `Signature.sign()` will throw a `SignatureException` because it has not been initialized for signing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186440423
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186448496
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186443155
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186443576
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1186445307

From valeriep at openjdk.org  Fri May  5 20:10:13 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 5 May 2023 20:10:13 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
Message-ID: <bg2ULIcXFTdC53vZCGxfXd-23iPICYxAP8P3ol1gI38=.b04cbe5c-15be-427d-8ab8-a8e26a6b4ac2@github.com>

On Fri, 5 May 2023 16:57:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Is it possible to generate the keys and certs on the fly?

Possible. For testing things not related to generation, using existing key/certs simplifies the setup and can be reused easily. Or, do you know if there are JDK test utilities which support this?

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

PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536721503

From weijun at openjdk.org  Fri May  5 20:23:18 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 May 2023 20:23:18 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <bg2ULIcXFTdC53vZCGxfXd-23iPICYxAP8P3ol1gI38=.b04cbe5c-15be-427d-8ab8-a8e26a6b4ac2@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
 <bg2ULIcXFTdC53vZCGxfXd-23iPICYxAP8P3ol1gI38=.b04cbe5c-15be-427d-8ab8-a8e26a6b4ac2@github.com>
Message-ID: <QKDGH9-7kZrhwu-krHpikwstPOTijS3lSBFD4xEaI50=.d0c18ee0-d526-4034-ae46-2e47bbe15079@github.com>

On Fri, 5 May 2023 20:07:18 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Or, do you know if there are JDK test utilities which support this?

Just `SecurityTools.keytool`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536736209

From valeriep at openjdk.org  Fri May  5 20:23:20 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 5 May 2023 20:23:20 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
Message-ID: <i9a7l958CWYQX9ZaBWHEnSh06anTdmBG3xGhUyZZw-I=.fccf90b0-2683-4796-9b0f-98678142a265@github.com>

On Fri, 5 May 2023 16:43:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
>> 
>> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
>> 
>> Thanks,
>> Valerie
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2057:
> 
>> 2055:                         currHdl = ch[0];
>> 2056:                     } else {
>> 2057:                         currHdl = 0L;
> 
> Maybe just `break`?

Sure, that'll work also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186470638

From kdriver at openjdk.org  Fri May  5 20:33:19 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 5 May 2023 20:33:19 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v4]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <DJpv_dgPHWir6ykqc-fwv4wMledwTgoBzpUDhekxHiQ=.1388e27c-9539-404e-9ce8-d4fa402c4ebd@github.com>

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

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

 - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - updated copyright
 - fixes JDK-8294985: throw an SSLException wrapping the IAE

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

Changes: https://git.openjdk.org/jdk/pull/13466/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=03
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

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

From hchao at openjdk.org  Fri May  5 20:44:20 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 5 May 2023 20:44:20 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <RR9Vz339D48pes1YzeS_ky95PZK2ig_K852IwLrl3HU=.04660590-5cc3-41df-b5d3-619a8dd7c1c5@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <DqqZaQeL8wh353TqOsLvJBSHsysFkPlSpO1SUhtqgXQ=.bbb8387d-837d-4877-a898-622edd7ac4c2@github.com>
 <RR9Vz339D48pes1YzeS_ky95PZK2ig_K852IwLrl3HU=.04660590-5cc3-41df-b5d3-619a8dd7c1c5@github.com>
Message-ID: <h2roC7Zu63d2BH4J5s8yZX6Xj3Soh_J1pOz_7HieQ9U=.f7f9e195-02cb-4ebe-904a-9fc09ebd8908@github.com>

On Fri, 5 May 2023 19:43:31 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval.java line 176:
>> 
>>> 174: 
>>> 175:         // should only have "pk1" now
>>> 176:         checkEntry(ks, "pk1", pk1Chain);
>> 
>> When the kesytore should only have "pk1? now, how would checkEntry(ks, "pk1", pk1Chain) succeed as it expects to have the ?ca.cert? in the pk1Chain? The ?ca.cert? shall not be deleted because ?pk1.cert? depends on it. I may have missed something here.
>
> I mean "pk1" entrry, not just "pk1" cert. As you can see, the test checks for the complete cert chain for "pk1" entry.

I've the same understanding of this test. The test looks good to me. I was puzzled by its "pk1" comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186485506

From hchao at openjdk.org  Fri May  5 20:51:19 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 5 May 2023 20:51:19 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
Message-ID: <Mr6RbShs6qUJQi9Mumv8hOU5kn48oTa39MJyTOuRDeU=.a68ec85c-ce25-4200-979a-48100950a415@github.com>

On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
> 
> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
> 
> Thanks,
> Valerie

As Max pointed out to use SecurityTools.keytool to generate keys/certs, I'd like to suggest using it to add a test case for pk1->pk2->ca, to test when deleting an intermediate cert.

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

PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536764393

From jjg at openjdk.org  Fri May  5 20:55:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 May 2023 20:55:17 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <5jPCrDCpjkHcnEsquRdHiG1MpPcNnr3gduXawzaIXiA=.c8c0ee74-34ae-4767-ab52-a09b10683dee@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
 <5jPCrDCpjkHcnEsquRdHiG1MpPcNnr3gduXawzaIXiA=.c8c0ee74-34ae-4767-ab52-a09b10683dee@github.com>
Message-ID: <_4-xwqG0X3oF_UgPT1B5FlfCqsdtQZ21PpdXXkgSS6o=.e3747de4-d20f-4bb7-8d96-da63b668fd65@github.com>

On Fri, 5 May 2023 14:28:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> We have quite some `standard-names.html#anchorName` links (Ex:
> 
> https://github.com/openjdk/jdk/blob/f804f2ce8ef7a859aae021b20cbdcd9e34f9fb94/src/java.base/share/classes/java/security/Signature.java#L111
> 
> ). I don't see any of them here. Is this style allowed in a `@spec` tag?
> I also see no `#anchorName` for RFC links.
> 
> And in this case, shall I also spell out the section name in the text?

1. You can use a relative URL, relative to the `specs` directory, so something like:<br>
   `@spec security/standard-names.html Standard Names`

2. The intent of the `@spec` tag is to identify the overall/root URL for each specification, not to identify all the interesting places within that specification.

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

PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1536766590

From valeriep at openjdk.org  Fri May  5 21:42:13 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 5 May 2023 21:42:13 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
Message-ID: <r8caLHaGlfuuJ9_oA_QGVz4QOlLBXc4iOqRpaFfFH84=.4cb2737a-e2be-4b74-8431-20ac92311170@github.com>

On Fri, 5 May 2023 16:46:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
>> 
>> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
>> 
>> Thanks,
>> Valerie
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2031:
> 
>> 2029:                             cert.getSubjectX500Principal() + "]");
>> 2030:                     }
>> 2031:                 } else {
> 
> If `destroyIt` is false for the 1st cert, are you going to return false? Maybe it does not matter.

Hmm, I think the rest of chain should still be checked and removed if no dependents for them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186517535

From valeriep at openjdk.org  Fri May  5 22:23:33 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 5 May 2023 22:23:33 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <QKDGH9-7kZrhwu-krHpikwstPOTijS3lSBFD4xEaI50=.d0c18ee0-d526-4034-ae46-2e47bbe15079@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
 <bg2ULIcXFTdC53vZCGxfXd-23iPICYxAP8P3ol1gI38=.b04cbe5c-15be-427d-8ab8-a8e26a6b4ac2@github.com>
 <QKDGH9-7kZrhwu-krHpikwstPOTijS3lSBFD4xEaI50=.d0c18ee0-d526-4034-ae46-2e47bbe15079@github.com>
Message-ID: <jnlkpuThqtBdZSB_ygMw9xmocRh4kIilFjtptwUezN0=.8d9a048d-8c19-4eba-9211-4ceb1c680416@github.com>

On Fri, 5 May 2023 20:20:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> > Or, do you know if there are JDK test utilities which support this?
> 
> Just `SecurityTools.keytool`.

I can give it a try. But if it turns out taking much longer (time and code), then I'd prefer just to go with PEM data files as I don't see an obvious benefit for dynamically generating the key pairs for this particular test.

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

PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536847770

From weijun at openjdk.org  Fri May  5 22:56:13 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 May 2023 22:56:13 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
Message-ID: <zd70WNJU-_wba4E8agZqTmY3vnb2dnF5_i5VxTaGWjk=.28f3a5d6-a0da-425e-b512-dac0c5a0255c@github.com>

On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
> 
> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
> 
> Thanks,
> Valerie

It's your decision. My point is that PEM data files, although in text mode, are still binary data and not human readable. You probably need some explanation on how to recreate them and that is equivalent to adding several `keytool` calls inside the test. 

Yes, I understand with the key generation calls the test will run much slower.

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

PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1536869563

From weijun at openjdk.org  Fri May  5 23:02:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 May 2023 23:02:23 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <r8caLHaGlfuuJ9_oA_QGVz4QOlLBXc4iOqRpaFfFH84=.4cb2737a-e2be-4b74-8431-20ac92311170@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
 <r8caLHaGlfuuJ9_oA_QGVz4QOlLBXc4iOqRpaFfFH84=.4cb2737a-e2be-4b74-8431-20ac92311170@github.com>
Message-ID: <YvFV0TX8ERCosG73SdgXf3R1T2nNtFXIbkE1oHQeCzs=.05c1f0eb-7313-4f20-b259-d3ec776991ba@github.com>

On Fri, 5 May 2023 21:39:13 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java line 2031:
>> 
>>> 2029:                             cert.getSubjectX500Principal() + "]");
>>> 2030:                     }
>>> 2031:                 } else {
>> 
>> If `destroyIt` is false for the 1st cert, are you going to return false? Maybe it does not matter.
>
> Hmm, I think the rest of chain should still be checked and removed if no dependents for them.

Of course, I was only talking about the final return value.

And, I take back my words. This method should return true no matter what `destroyIt` is. The return value is only used in `deleteEntry` and it should be true even if the.cert is used elsewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1186547307

From liach at openjdk.org  Sat May  6 17:03:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 6 May 2023 17:03:13 GMT
Subject: RFR: 8307575: Migrate the serialization constructor accessors to
 Method Handles
Message-ID: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>

Apparently method handle linking doesn't impose extra checks on constructor invocation, so the special logic for the serialization constructor to call superclass constructor in MagicAccessorImpl can be removed altogether with old core reflection implementation.

Serialization and sun.reflect.ReflectionFactory tests pass. May be worth to think about the long-term treatment of ReflectionFactory.newConstructorForSerialization, as creating partial object is inherently unsafe, and behavior of `newConstructorForSerialization(ArrayList.class, String.class.getDeclaredConstructor(String.class))` etc. (which is accepted for now) may have unpredictable side effects.

#1830 has a similar patch; this one doesn't touch proxies and updates to the new post-JEP 416 reflection implementation.

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

Commit messages:
 - 8307575: Migrate the serialization constructor accessors to Method Handles

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

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

From liach at openjdk.org  Sun May  7 13:36:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 May 2023 13:36:16 GMT
Subject: RFR: 8307575: Migrate the serialization constructor accessors to
 Method Handles [v2]
In-Reply-To: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>
References: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>
Message-ID: <eJguOKvsmtcMCtVsbhufMqRLxFyRfAvBjq-cq_Tf3rs=.29134497-8bdf-4f04-8e59-0af8cb7bcd97@github.com>

> Apparently method handle linking doesn't impose extra checks on constructor invocation, so the special logic for the serialization constructor to call superclass constructor in MagicAccessorImpl can be removed altogether with old core reflection implementation.
> 
> Serialization and sun.reflect.ReflectionFactory tests pass. May be worth to think about the long-term treatment of ReflectionFactory.newConstructorForSerialization, as creating partial object is inherently unsafe, and behavior of `newConstructorForSerialization(ArrayList.class, String.class.getDeclaredConstructor(String.class))` etc. (which is accepted for now) may have unpredictable side effects.
> 
> #1830 has a similar patch; this one doesn't touch proxies and updates to the new post-JEP 416 reflection implementation.

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

  Remove invalid assertion (via sun.reflect.ReflectionFactory)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13853/files
  - new: https://git.openjdk.org/jdk/pull/13853/files/64a8f518..3a0393a9

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

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

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

From mdonovan at openjdk.org  Mon May  8 12:17:25 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 8 May 2023 12:17:25 GMT
Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling
 with NullPointerException [v3]
In-Reply-To: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com>
References: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
 <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com>
Message-ID: <n7ulnUiYFVLtZon6HbY4eRAxKITp4WWZfUcXIGwTUTc=.e816f434-ea81-424c-b606-90bc01252b11@github.com>

On Wed, 3 May 2023 11:26:32 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made handshake context lock final

Can a security-dev Reviewer take a look at this? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/13742#issuecomment-1538261029

From mullan at openjdk.org  Mon May  8 13:11:36 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 May 2023 13:11:36 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
Message-ID: <tQJNDZ_HvdoIsDJGJdOT3R8fWC5idKWAGhJ2bYVwxHQ=.a9249c7f-8c41-468b-9e36-8f828005a83b@github.com>

On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding key translation, finally block, removing 24-byte LMOTS parameters

src/java.base/share/classes/sun/security/provider/HSS.java line 746:

> 744:         @Override
> 745:         protected <T extends KeySpec> T engineGetKeySpec(Key key, Class<T> keySpec) throws InvalidKeySpecException {
> 746:             if (key.getFormat().equals("X.509") && key.getAlgorithm().equals("HSS/LMS")) {

Should check if `key` is `null` and if so, throw `InvalidKeySpecExc`.

src/java.base/share/classes/sun/security/provider/HSS.java line 746:

> 744:         @Override
> 745:         protected <T extends KeySpec> T engineGetKeySpec(Key key, Class<T> keySpec) throws InvalidKeySpecException {
> 746:             if (key.getFormat().equals("X.509") && key.getAlgorithm().equals("HSS/LMS")) {

Standard names are case-insensitive, so should use `equalsIgnoreCase`.

src/java.base/share/classes/sun/security/provider/HSS.java line 774:

> 772:     }
> 773: 
> 774:     public static class HSSPublicKey extends X509Key implements Length {

Can this be package-private instead of `public`?

src/java.base/share/classes/sun/security/provider/HSS.java line 781:

> 779: 
> 780:         @SuppressWarnings("deprecation")
> 781:         public HSSPublicKey(byte[] keyArray) throws InvalidKeyException {

Can this be package-private instead of public?

src/java.base/share/classes/sun/security/provider/HSS.java line 796:

> 794: 
> 795:         @Override
> 796:         @SuppressWarnings("deprecation")

Why do you need the `SuppressWarnings` annotation here? `sun.util.Length.length()` is not deprecated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187417447
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187421443
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187395653
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187397466
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187402001

From duke at openjdk.org  Mon May  8 13:36:39 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 8 May 2023 13:36:39 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <erFxtT_f73YLetiFFKAl4wZS2YCdDMk_eLV3jtnsqGo=.0f0ba2fc-ce0d-4e64-88e2-74b0b0982f15@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <erFxtT_f73YLetiFFKAl4wZS2YCdDMk_eLV3jtnsqGo=.0f0ba2fc-ce0d-4e64-88e2-74b0b0982f15@github.com>
Message-ID: <NMKJlkWquX8LpL4zaaTwoauSoyqv7CbMBLAbrQBly3A=.a7dd4d24-7f38-4a50-ac5d-af601e9da1e1@github.com>

On Fri, 5 May 2023 19:34:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding key translation, finally block, removing 24-byte LMOTS parameters
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 37:
> 
>> 35: import java.util.Arrays;
>> 36: import java.util.Objects;
>> 37: 
> 
> Can you add some comments describing this class?

Comment added.

> src/java.base/share/classes/sun/security/provider/HSS.java line 38:
> 
>> 36: import java.util.Objects;
>> 37: 
>> 38: public class HSS extends SignatureSpi {
> 
> Make the class `final`?

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 43:
> 
>> 41: 
>> 42:     @Deprecated
>> 43:     protected void engineSetParameter(String param, Object value) {
> 
> Technically, this API is not defined to throw UOE. I think throwing IPE is better and would be compliant with the specification. (I am aware that there are other JDK SignatureSpi implementations that already throw UOE for this method, but they should be fixed).

Changed to throw InvalidParameterException.

> src/java.base/share/classes/sun/security/provider/HSS.java line 48:
> 
>> 46: 
>> 47:     @Deprecated
>> 48:     protected AlgorithmParameters engineGetParameter(String param) {
> 
> Same comment as above.

Changed to throw InvalidParameterException.

> src/java.base/share/classes/sun/security/provider/HSS.java line 56:
> 
>> 54:     }
>> 55: 
>> 56:     protected byte[] engineSign() throws SignatureException {
> 
> This API is not defined to throw UOE. Suggest throwing `SignatureException` instead with a message "Signing is not supported".
> 
> Though, technically this method should never be called, as `Signature.sign()` will throw a `SignatureException` because it has not been initialized for signing.

Done.

> src/java.base/share/classes/sun/security/util/RawKeySpec.java line 30:
> 
>> 28: import java.security.spec.KeySpec;
>> 29: 
>> 30: public class RawKeySpec  implements KeySpec {
> 
> Nit, should be one space between `RawKeySpec` and `implements`.

Changed.

> src/java.base/share/classes/sun/security/util/RawKeySpec.java line 30:
> 
>> 28: import java.security.spec.KeySpec;
>> 29: 
>> 30: public class RawKeySpec  implements KeySpec {
> 
> Can you add some comments describing this class?

Added.

> src/java.base/share/classes/sun/security/util/RawKeySpec.java line 31:
> 
>> 29: 
>> 30: public class RawKeySpec  implements KeySpec {
>> 31:     final private byte[] keyArr;
> 
> Put `private` before `final`.

Changed the order.

> src/java.base/share/classes/sun/security/util/RawKeySpec.java line 33:
> 
>> 31:     final private byte[] keyArr;
>> 32:     /**
>> 33:      * The sole constructor
> 
> Nit: add period at end of sentence and an empty line after this (before the `@param`).

Added period.

> src/java.base/share/classes/sun/security/util/RawKeySpec.java line 37:
> 
>> 35:      */
>> 36:     public RawKeySpec(byte[] key) {
>> 37:         keyArr = key.clone();
> 
> Does this need to be cloned if it is an internal class?

Yes, I think so. If someone wants to test with several different keys by first creating RawKeySpec objects from an array in which a few bytes are changed between the calls and and then use these KeySpecs to create the actual keys, without the cloning they will end up with the same keys. So an immutable object is better.

> src/java.base/share/classes/sun/security/util/RawKeySpec.java line 41:
> 
>> 39: 
>> 40:     /**
>> 41:      * Getter function
> 
> Nit: add period at end of sentence and an empty line after this (before the @return).

Added period.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453794
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187454052
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453859
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453935
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453983
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453454
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453499
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453735
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453545
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453600
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453680

From duke at openjdk.org  Mon May  8 13:36:43 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 8 May 2023 13:36:43 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
Message-ID: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com>

On Thu, 4 May 2023 20:00:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding key translation, finally block, removing 24-byte LMOTS parameters
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 94:
> 
>> 92:             result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray());
>> 93:             return result;
>> 94:         } catch (Exception e) {
> 
> If all exceptions thrown are already `SignatureException`, we can let them thrown out instead of returning false. According to the `engineVerify` spec, any problem inside the signature should throw a `SignatureException`. False is returned when the public key cannot verify the exception.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 295:
> 
>> 293:             int inLen = sigArray.length;
>> 294:             if (inLen < 4)
>> 295:                 throw new InvalidParameterException("Invalid LMS signature");
> 
> This is LM-OTS signature. Also, give some explanation. Same on line 301.

Explained.

> src/java.base/share/classes/sun/security/provider/HSS.java line 459:
> 
>> 457:         final byte[] sigArr;
>> 458: 
>> 459:         public LMSignature(byte[] sigArray, int offset, boolean checkExactLen) throws InvalidParameterException {
> 
> How about we throw a `SignatureException` here. `new HSSSignature` and `new LMOTSignature` all throw it.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 467:
> 
>> 465:             qArr = Arrays.copyOfRange(sigArray, offset, offset + 4);
>> 466:             sigOtsType = LMSUtils.fourBytesToInt(sigArray, offset + 4);
>> 467:             LMOTSParams lmotsParams = LMOTSParams.of(sigOtsType);
> 
> Catch `IllegalArgumentException` here and rethrow a `SignatureException`. Same on line 482.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 659:
> 
>> 657:         }
>> 658:         public byte[] lmotsPubKeyCandidate(LMSignature lmSig, byte[] message, LMSPublicKey pKey)
>> 659:                 throws NoSuchAlgorithmException, DigestException {
> 
> `DigestException` should not happen because we allocate all the buffer ourselves. `NoSuchAlgorithmException` should not happen because we should have all the algorithms. If they do happen, that's not user problem at all. I think the usual way is to wrap them into a `ProviderException`. This is also true in `lmsVerify()`.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 662:
> 
>> 660:             LMOTSignature lmOtSig = lmSig.lmotSig;
>> 661:             if (lmOtSig.otSigType != pKey.otsType) {
>> 662:                 throw new IllegalArgumentException("OTS public key type and OTS signature type do not match");
> 
> I'd rather throw `SignatureException`. This method is actually verifying an LM-OTS signature, right? Avoid using unchecked exceptions instead of `ProviderException` unless you can be sure they are caught nicely.

Changed.

> src/java.base/share/classes/sun/security/provider/HSS.java line 736:
> 
>> 734:                 }
>> 735:             }
>> 736:             throw new InvalidKeySpecException();
> 
> Give an error message. Try look at what other factories are doing. Same for lines 751, 768, 727, 44, 49, and 57.

Added explanations.

> src/java.base/share/classes/sun/security/provider/HSS.java line 745:
> 
>> 743: 
>> 744:         @Override
>> 745:         protected <T extends KeySpec> T engineGetKeySpec(Key key, Class<T> keySpec) throws InvalidKeySpecException {
> 
> Usually when `key` is null an `InvalidKeySpecException` is thrown. Here it's an NPE.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 809:
> 
>> 807:         HSSSignature(byte[] sigArr, int pubKeyL, String pubKeyHashAlg) throws SignatureException {
>> 808:             if (sigArr.length < 4) {
>> 809:                 throw new SignatureException("Bad HSS signature");
> 
> Maybe you can say why it is bad. This also applies to "Invalid HSS public key", "Invalid LMS signature" and "Invalid LMS public key" messages.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 823:
> 
>> 821:                     index += siglist[i].sigArrayLength();
>> 822:                     pubList[i] = new LMSPublicKey(sigArr, index, false);
>> 823:                     if (!pubList[i].getDigestAlgorithm().equals(pubKeyHashAlg)) {
> 
> Comparing hash algorithm is not enough. Length (`m`) should also be compared.

Compared.

> src/java.base/share/classes/sun/security/provider/HSS.java line 829:
> 
>> 827:                 }
>> 828:                 siglist[Nspk] = new LMSignature(sigArr, index, true);
>> 829:             } catch (Exception E) {
> 
> The `SignatureException` thrown on line 824 does not need to be wrapped into another `SignatureException`. Maybe just catch `InvalidKeyException` (if you throw `SignatureException` in `new LMSSignature`).

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187452891
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453204
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453062
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453398
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187452980
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453253
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453292
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187452998
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453109
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187453175
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187452934

From duke at openjdk.org  Mon May  8 14:17:16 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 8 May 2023 14:17:16 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v6]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <MnSl1yMhrcBfdgeTgt1HYqQyXzVbTJfW1FzeJkOJwF0=.5a8c49bc-42a8-4651-ad40-ea6bfc30bbee@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  Addressing review comments from @wangweij and @seanjmullan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/b546fdf0..42184ff9

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

  Stats: 236 lines in 6 files changed: 38 ins; 125 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/13691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691

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

From duke at openjdk.org  Mon May  8 14:17:21 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 8 May 2023 14:17:21 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <tQJNDZ_HvdoIsDJGJdOT3R8fWC5idKWAGhJ2bYVwxHQ=.a9249c7f-8c41-468b-9e36-8f828005a83b@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <tQJNDZ_HvdoIsDJGJdOT3R8fWC5idKWAGhJ2bYVwxHQ=.a9249c7f-8c41-468b-9e36-8f828005a83b@github.com>
Message-ID: <NbDJS9roF7Mg0mstnsxwuQdY_QWFLzi_MR_-FMlmXmU=.b69398c0-3be8-488f-8804-5e7efe44ab5a@github.com>

On Mon, 8 May 2023 12:59:05 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding key translation, finally block, removing 24-byte LMOTS parameters
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 746:
> 
>> 744:         @Override
>> 745:         protected <T extends KeySpec> T engineGetKeySpec(Key key, Class<T> keySpec) throws InvalidKeySpecException {
>> 746:             if (key.getFormat().equals("X.509") && key.getAlgorithm().equals("HSS/LMS")) {
> 
> Should check if `key` is `null` and if so, throw `InvalidKeySpecExc`.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 746:
> 
>> 744:         @Override
>> 745:         protected <T extends KeySpec> T engineGetKeySpec(Key key, Class<T> keySpec) throws InvalidKeySpecException {
>> 746:             if (key.getFormat().equals("X.509") && key.getAlgorithm().equals("HSS/LMS")) {
> 
> Standard names are case-insensitive, so should use `equalsIgnoreCase`.

Changed.

> src/java.base/share/classes/sun/security/provider/HSS.java line 796:
> 
>> 794: 
>> 795:         @Override
>> 796:         @SuppressWarnings("deprecation")
> 
> Why do you need the `SuppressWarnings` annotation here? `sun.util.Length.length()` is not deprecated.

Without that, I get:

/Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:813: warning: [deprecation] key in X509Key has been deprecated
            key = new DerOutputStream().putOctetString(keyArray).toByteArray();
            ^

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187496671
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187496730
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187496615

From duke at openjdk.org  Mon May  8 14:22:27 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 8 May 2023 14:22:27 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <tQJNDZ_HvdoIsDJGJdOT3R8fWC5idKWAGhJ2bYVwxHQ=.a9249c7f-8c41-468b-9e36-8f828005a83b@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <tQJNDZ_HvdoIsDJGJdOT3R8fWC5idKWAGhJ2bYVwxHQ=.a9249c7f-8c41-468b-9e36-8f828005a83b@github.com>
Message-ID: <TPDZUyTjk1urxpsbPX3E-CKHuhb1WvH23vqbQKfkQDI=.56ca9132-0be4-43b9-a340-ab05362a9f35@github.com>

On Mon, 8 May 2023 12:38:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding key translation, finally block, removing 24-byte LMOTS parameters
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 781:
> 
>> 779: 
>> 780:         @SuppressWarnings("deprecation")
>> 781:         public HSSPublicKey(byte[] keyArray) throws InvalidKeyException {
> 
> Can this be package-private instead of public?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187506046

From duke at openjdk.org  Mon May  8 14:58:00 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 8 May 2023 14:58:00 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v7]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  Addressing more review comments from @wangweij and @seanjmullan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/42184ff9..b8064640

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

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

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

From weijun at openjdk.org  Mon May  8 16:02:29 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 16:02:29 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
 <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com>
Message-ID: <h5zf4dc9K1tgUT0JBadZsNIpRNvHK5xeu_LYGW4duQY=.a260fb49-b417-4df7-b90c-74278a452e15@github.com>

On Mon, 8 May 2023 13:32:21 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 94:
>> 
>>> 92:             result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray());
>>> 93:             return result;
>>> 94:         } catch (Exception e) {
>> 
>> If all exceptions thrown are already `SignatureException`, we can let them thrown out instead of returning false. According to the `engineVerify` spec, any problem inside the signature should throw a `SignatureException`. False is returned when the public key cannot verify the exception.
>
> Done.

`new HSSSignature` and `lmsVerify` are already throwing `SignatureExceptions` and they needn't be wrapped again into a new `SignatureException`.

In fact, it seems `SignatureException` is the only checked exception that can be thrown in these lines. Is your `catch (Exception e)` block trying to catch unchecked exceptions? Unchecked exceptions like `NumberFormatException` or `NullPointerException` might indicate input errors and should be rewrapped, but `ProviderException` are well-defined as internal errors and can be exposed to the final user.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187614920

From duke at openjdk.org  Mon May  8 16:02:33 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 8 May 2023 16:02:33 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <NbDJS9roF7Mg0mstnsxwuQdY_QWFLzi_MR_-FMlmXmU=.b69398c0-3be8-488f-8804-5e7efe44ab5a@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <tQJNDZ_HvdoIsDJGJdOT3R8fWC5idKWAGhJ2bYVwxHQ=.a9249c7f-8c41-468b-9e36-8f828005a83b@github.com>
 <NbDJS9roF7Mg0mstnsxwuQdY_QWFLzi_MR_-FMlmXmU=.b69398c0-3be8-488f-8804-5e7efe44ab5a@github.com>
Message-ID: <9wLugxZEyEoThvdIC4tKP0WK_KL5Bm9l3WkZa3zd5vw=.204c9526-4a08-46cb-8221-f8329680921f@github.com>

On Mon, 8 May 2023 14:10:54 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 796:
>> 
>>> 794: 
>>> 795:         @Override
>>> 796:         @SuppressWarnings("deprecation")
>> 
>> Why do you need the `SuppressWarnings` annotation here? `sun.util.Length.length()` is not deprecated.
>
> Without that, I get:
> 
> /Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:813: warning: [deprecation] key in X509Key has been deprecated
>             key = new DerOutputStream().putOctetString(keyArray).toByteArray();
>             ^

Sorry, that one is if I remove another deprecation suppression. But the root cause is the same here, without the message I get
/Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:705: warning: [deprecation] key in X509Key has been deprecated
            return key.length * 8; // length in bits
                   ^
error: warnings found and -Werror specified

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187556505

From duke at openjdk.org  Mon May  8 16:02:34 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 8 May 2023 16:02:34 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <9wLugxZEyEoThvdIC4tKP0WK_KL5Bm9l3WkZa3zd5vw=.204c9526-4a08-46cb-8221-f8329680921f@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <tQJNDZ_HvdoIsDJGJdOT3R8fWC5idKWAGhJ2bYVwxHQ=.a9249c7f-8c41-468b-9e36-8f828005a83b@github.com>
 <NbDJS9roF7Mg0mstnsxwuQdY_QWFLzi_MR_-FMlmXmU=.b69398c0-3be8-488f-8804-5e7efe44ab5a@github.com>
 <9wLugxZEyEoThvdIC4tKP0WK_KL5Bm9l3WkZa3zd5vw=.204c9526-4a08-46cb-8221-f8329680921f@github.com>
Message-ID: <CTaPMAyIlk9MiA3ri_DhxwGViAE-4fr00TYENYQaUdc=.a83ee6e3-d604-4b43-a965-bc58c7cff870@github.com>

On Mon, 8 May 2023 15:02:55 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Without that, I get:
>> 
>> /Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:813: warning: [deprecation] key in X509Key has been deprecated
>>             key = new DerOutputStream().putOctetString(keyArray).toByteArray();
>>             ^
>
> Sorry, that one is if I remove another deprecation suppression. But the root cause is the same here, without the message I get
> /Users/ferakocz/dev/git-repos/jdk/open/src/java.base/share/classes/sun/security/provider/HSS.java:705: warning: [deprecation] key in X509Key has been deprecated
>             return key.length * 8; // length in bits
>                    ^
> error: warnings found and -Werror specified

Grrrrh: "
without the message" -> "without suppressing the warning"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187559580

From weijun at openjdk.org  Mon May  8 16:05:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 16:05:51 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
 <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com>
Message-ID: <MpahSp64BUxTwS0KGka_Spnb9awcOyiTMy1G7tiOnyg=.fbf93a58-32af-45b7-8a95-d66e88229bf2@github.com>

On Mon, 8 May 2023 13:32:29 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 745:
>> 
>>> 743: 
>>> 744:         @Override
>>> 745:         protected <T extends KeySpec> T engineGetKeySpec(Key key, Class<T> keySpec) throws InvalidKeySpecException {
>> 
>> Usually when `key` is null an `InvalidKeySpecException` is thrown. Here it's an NPE.
>
> Done.

`key.equals(null)` would throw an NPE. Just use `key == null`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187618885

From mullan at openjdk.org  Mon May  8 16:19:34 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 May 2023 16:19:34 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v7]
In-Reply-To: <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
Message-ID: <9oyYOfazlu7cyszP6M-EeJ1q8HrkgBwOilN_YcJPV5Y=.ccfafdc1-8262-411d-8a76-90a62c3278ff@github.com>

On Mon, 8 May 2023 14:58:00 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing more review comments from @wangweij and @seanjmullan

src/java.base/share/classes/sun/security/provider/HSS.java line 99:

> 97:             result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray());
> 98:             return result;
> 99:         } catch (Exception e) {

Do we need this `catch`? I think only `SignatureException` can be thrown inside the `try` block.

src/java.base/share/classes/sun/security/provider/HSS.java line 172:

> 170:         private final byte[] T1;
> 171: 
> 172:         public static LMSPublicKey of(byte[] keyArray) throws InvalidKeyException {

The methods of `LMSPublicKey` can be package-private.

src/java.base/share/classes/sun/security/provider/HSS.java line 383:

> 381:         final byte[] sigArr;
> 382: 
> 383:         public LMSignature(byte[] sigArray, int offset, boolean checkExactLen) throws SignatureException {

The methods of `LMSignature` can be package-private.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187628502
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187624026
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187624515

From mullan at openjdk.org  Mon May  8 16:19:36 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 May 2023 16:19:36 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
Message-ID: <U9kaaNma3S2uTi1y-9bdDo84_G-UD9-H8slF8W8mpiU=.9bc77391-c470-4b28-8343-7944934e36c6@github.com>

On Tue, 2 May 2023 21:43:19 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding key translation, finally block, removing 24-byte LMOTS parameters

src/java.base/share/classes/sun/security/provider/HSS.java line 229:

> 227: 
> 228:     static class LMSUtils {
> 229:         public final static int LMS_RESERVED = 0;

The statics and methods of `LMSUtils` can all be package-private.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187500905

From weijun at openjdk.org  Mon May  8 16:19:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 16:19:38 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
 <9-PyNlc373tCBn7KoS9sONeXRl_r3Dlgiqwg_JgA38E=.dc995c87-6b8d-490f-9fe1-293cbd965be3@github.com>
Message-ID: <Mlj7268JyPST8gI8396Er6Db0M72Ak5Z0vxS0t_PdDc=.3ea1999c-0fb3-47e7-b246-2e0d50b76993@github.com>

On Mon, 8 May 2023 13:32:38 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 823:
>> 
>>> 821:                     index += siglist[i].sigArrayLength();
>>> 822:                     pubList[i] = new LMSPublicKey(sigArr, index, false);
>>> 823:                     if (!pubList[i].getDigestAlgorithm().equals(pubKeyHashAlg)) {
>> 
>> Comparing hash algorithm is not enough. Length (`m`) should also be compared.
>
> Compared.

How about we create a dedicated method for this `hasSameHash(LMParams, LMParams)`? Looks like the `getDigestAlgorithm` methods on lines 228 and 699 have no more other usages.

We can also create a new `hasSameHash(LMOTSParams, LMParams)` for the check in `new LMSPublicKey`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187628910

From mullan at openjdk.org  Mon May  8 16:19:41 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 May 2023 16:19:41 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <NMKJlkWquX8LpL4zaaTwoauSoyqv7CbMBLAbrQBly3A=.a7dd4d24-7f38-4a50-ac5d-af601e9da1e1@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <erFxtT_f73YLetiFFKAl4wZS2YCdDMk_eLV3jtnsqGo=.0f0ba2fc-ce0d-4e64-88e2-74b0b0982f15@github.com>
 <NMKJlkWquX8LpL4zaaTwoauSoyqv7CbMBLAbrQBly3A=.a7dd4d24-7f38-4a50-ac5d-af601e9da1e1@github.com>
Message-ID: <3JJT2FXkvXoKeI-eBx-2Js9cN3Yp4s1sbjF0VLGxY14=.6cc1d8ca-405d-476b-98d7-a4bf18e67fc7@github.com>

On Mon, 8 May 2023 13:33:01 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/RawKeySpec.java line 37:
>> 
>>> 35:      */
>>> 36:     public RawKeySpec(byte[] key) {
>>> 37:         keyArr = key.clone();
>> 
>> Does this need to be cloned if it is an internal class?
>
> Yes, I think so. If someone wants to test with several different keys by first creating RawKeySpec objects from an array in which a few bytes are changed between the calls and and then use these KeySpecs to create the actual keys, without the cloning they will end up with the same keys. So an immutable object is better.

Ok. Try to keep your line lengths to about 80 chars.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187577377

From weijun at openjdk.org  Mon May  8 16:19:42 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 16:19:42 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <3JJT2FXkvXoKeI-eBx-2Js9cN3Yp4s1sbjF0VLGxY14=.6cc1d8ca-405d-476b-98d7-a4bf18e67fc7@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <erFxtT_f73YLetiFFKAl4wZS2YCdDMk_eLV3jtnsqGo=.0f0ba2fc-ce0d-4e64-88e2-74b0b0982f15@github.com>
 <NMKJlkWquX8LpL4zaaTwoauSoyqv7CbMBLAbrQBly3A=.a7dd4d24-7f38-4a50-ac5d-af601e9da1e1@github.com>
 <3JJT2FXkvXoKeI-eBx-2Js9cN3Yp4s1sbjF0VLGxY14=.6cc1d8ca-405d-476b-98d7-a4bf18e67fc7@github.com>
Message-ID: <oZMF9CKi9WbgD2kErS9SyGj2P4Vgwm-MYLU_3oGVjsI=.97427f5d-69be-4634-9406-b9814ee4f80c@github.com>

On Mon, 8 May 2023 15:22:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Yes, I think so. If someone wants to test with several different keys by first creating RawKeySpec objects from an array in which a few bytes are changed between the calls and and then use these KeySpecs to create the actual keys, without the cloning they will end up with the same keys. So an immutable object is better.
>
> Ok. Try to keep your line lengths to about 80 chars.

I think so too. This class is only used by tests now so it will not have any negative performance impact on real users. If we want to move it into the public one day then we don't need to update it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187631611

From weijun at openjdk.org  Mon May  8 16:27:36 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 16:27:36 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v7]
In-Reply-To: <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
Message-ID: <DNFloZmonN6pp3bL9e07wBrtm7oY9HEVw3mWnF8yr94=.a56438ae-3d1b-4ca1-8a1f-169181a7f88e@github.com>

On Mon, 8 May 2023 14:58:00 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing more review comments from @wangweij and @seanjmullan

src/java.base/share/classes/sun/security/provider/HSS.java line 158:

> 156:             }
> 157:             return lmsPublicKey.isT1(tmpMsg, 22 + m);
> 158:         } catch (Exception e) {

Avoid using `catch (Exception e)` because that's too wide. In fact, here it seems the only checked exceptions that can be caught is `NoSuchAlgorithmException | DigestException`. I think we've agreed to throw `ProviderException` for them.

src/java.base/share/classes/sun/security/provider/HSS.java line 240:

> 238:         public final static int LMS_SHA256_M32_H20 = 8;
> 239:         public final static int LMS_SHA256_M32_H25 = 9;
> 240:         public final static int LMS_SHA256_M24_H5 = 10;

Shall we remove the SHA256_M24 and SHAKE constants at the moment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187637375
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187639689

From weijun at openjdk.org  Mon May  8 16:32:34 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 16:32:34 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v7]
In-Reply-To: <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
Message-ID: <3kJX5uh8UxbY852mLsh2XivNSl7jfVnx6M6m3LAHvsk=.119f255f-b4bb-483f-b967-9e93550983d4@github.com>

On Mon, 8 May 2023 14:58:00 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing more review comments from @wangweij and @seanjmullan

src/java.base/share/classes/sun/security/provider/HSS.java line 106:

> 104:     }
> 105: 
> 106:     protected boolean lmsVerify(LMSPublicKey lmsPublicKey, LMSignature sig, byte[] message) throws SignatureException {

We probably should put this method into an inner class and make it static.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187644587

From weijun at openjdk.org  Mon May  8 16:41:35 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 16:41:35 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
Message-ID: <KVBSwuvxuMjq2YoNL2BIvjVQBXtApHkK6vMSPqbDu_c=.3665c062-3b32-4501-922c-7598b67c84e7@github.com>

On Thu, 4 May 2023 21:24:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding key translation, finally block, removing 24-byte LMOTS parameters
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 528:
> 
>> 526:         // update()-digest() sequence) which is parametrized so that the digest output is copied back into this buffer.
>> 527:         // This way, we avoid memory allocations and some computations that would have to be done otherwise.
>> 528:         final byte[] hashBuf;
> 
> I'm a little worried about the mutability of `hashBuf` and whether it's suitable to be put inside `LMOTSParams`.  By using `of` to return an `LMOTSParams` object we have the chance to return cached objects in the future. There should always be one `hashBuf` for each LM-OTS verification, and this is not clear from the current code.

How will the performance change if we make `hashbufSha256_24` and `hashbufSha256_32` static and each time we want to verify an LM-OTS signature we clone one of them?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187651985

From weijun at openjdk.org  Mon May  8 16:51:35 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 16:51:35 GMT
Subject: RFR: 8297878: KEM: Implementation [v14]
In-Reply-To: <UFgMmvt8ugD3exa6OWVFbsVGByYpKEfmWMjsJ2l5pr4=.930fc1e8-e451-44a5-a7d3-39832c17f6c3@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <8WSBb3raSb1uB_jImPoQqYBuv6rJHrDT6_SS7_aWT4Q=.05c1e4ba-fd51-4a68-8aed-fc0a7100a7b2@github.com>
 <VjQ938kBYjTNg9TtI1p6UrWwjY1mWqqhufhBE_oG8OU=.b2388fe5-fd03-47a4-ac87-e94b0b946a08@github.com>
 <ivHF3RYi0DRrtF5bUzgaO9heJDzz1Oyo2oykxRhAPMg=.06bedb57-6ea2-465e-9d69-5fa5fcc6a13e@github.com>
 <edE3OeRCUzw3f70HjFFi4S4-GW-ma0GOhEksI5m5q80=.55beeb17-ebdf-4426-abf8-2f08eaa33805@github.com>
 <JSqC_YvbJqpt1Q2lu89x66JVzjJlHcOwkl38Xi6ZaFc=.f94e184b-d77d-48c6-baa0-6435e1cd8c03@github.com>
 <BrStk_E-pBfLshWoKkHXnC0OEZOFUH8YsQaDDwbwORo=.0b09d034-02c1-4714-bb82-fe6836d29030@github.com>
 <hPjy5_EtYyXQgzDRwWywIrLcR9GWjkx07YOUs5ttkxU=.a8ae73fb-5fc7-4c5b-afc0-2d6f5f4c2a5e@github.com>
 <M6an2C-rWAlx-1_j5__mlFxHfwc7qnUb6SO1PF-YtAs=.4e3e139a-7687-468e-b6d1-53e7e922445d@github.com>
 <k8NSBsDNASYYZZ9POh3UynWRz15K18wAbfXJhpOTKZU=.a0ef70aa-61d5-4111-9170-63cd9f5013b0@github.com>
 <hWPmrjW9tEViQVGSuF0QAY7PniK8J0LVvKJ
 0fThcvJA=.a61eae44-a0ed-44c3-82c9-cf2e031d6581@github.com>
 <sXLJgnHB8eEGdQnRlYikjc6R6PzNMCYzMosdEyr25IY=.4ed97eb8-b954-4ccb-8ed6-381ad73f9245@github.com>
 <B83h3J_JdLSr_QRc-ExkESDe-pyOxzpjXvGk6zCQhJE=.6a331882-35a4-4ce8-8136-30a03a80aa05@github.com>
 <N_7guPY4IKbVc3_2f7SQDf1KSOSXrUL7fIcn2T5ZuBk=.73250f06-f78c-4a68-a689-98db0af22881@github.com>
 <YBjgVCncT9koFcVMIFsws18mQe8oKzFc4yNx6KzrKsw=.9faa1118-d00a-4736-ba9a-ca63f34e4407@github.com>
 <LvnyLNDnIDmfWT4KyzlRfXe1ljCbUM9QEyD7vKkN5dI=.119644cf-99b4-45b4-a5bb-020be5743679@github.com>
 <UFgMmvt8ugD3exa6OWVFbsVGByYpKEfmWMjsJ2l5pr4=.930fc1e8-e451-44a5-a7d3-39832c17f6c3@github.com>
Message-ID: <0hPStmab_JXqCsAPhyC9Bk706LWHDMBVPn2sInf4_Uk=.8dd2ae39-faa5-40d6-a02b-41be58e002ce@github.com>

On Fri, 14 Apr 2023 16:33:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> I added another proposal in you PR at https://github.com/openjdk/jdk/pull/13470#issuecomment-1508915798.
>
>> I added another proposal in you PR at [#13470 (comment)](https://github.com/openjdk/jdk/pull/13470#issuecomment-1508915798).
> 
> I like the idea to use abstract class.  The concerns about provider() method get addressed.

I take back the proposal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1187661073

From weijun at openjdk.org  Mon May  8 16:51:36 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 16:51:36 GMT
Subject: RFR: 8297878: KEM: Implementation [v14]
In-Reply-To: <0hPStmab_JXqCsAPhyC9Bk706LWHDMBVPn2sInf4_Uk=.8dd2ae39-faa5-40d6-a02b-41be58e002ce@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <8WSBb3raSb1uB_jImPoQqYBuv6rJHrDT6_SS7_aWT4Q=.05c1e4ba-fd51-4a68-8aed-fc0a7100a7b2@github.com>
 <VjQ938kBYjTNg9TtI1p6UrWwjY1mWqqhufhBE_oG8OU=.b2388fe5-fd03-47a4-ac87-e94b0b946a08@github.com>
 <ivHF3RYi0DRrtF5bUzgaO9heJDzz1Oyo2oykxRhAPMg=.06bedb57-6ea2-465e-9d69-5fa5fcc6a13e@github.com>
 <edE3OeRCUzw3f70HjFFi4S4-GW-ma0GOhEksI5m5q80=.55beeb17-ebdf-4426-abf8-2f08eaa33805@github.com>
 <JSqC_YvbJqpt1Q2lu89x66JVzjJlHcOwkl38Xi6ZaFc=.f94e184b-d77d-48c6-baa0-6435e1cd8c03@github.com>
 <BrStk_E-pBfLshWoKkHXnC0OEZOFUH8YsQaDDwbwORo=.0b09d034-02c1-4714-bb82-fe6836d29030@github.com>
 <hPjy5_EtYyXQgzDRwWywIrLcR9GWjkx07YOUs5ttkxU=.a8ae73fb-5fc7-4c5b-afc0-2d6f5f4c2a5e@github.com>
 <M6an2C-rWAlx-1_j5__mlFxHfwc7qnUb6SO1PF-YtAs=.4e3e139a-7687-468e-b6d1-53e7e922445d@github.com>
 <k8NSBsDNASYYZZ9POh3UynWRz15K18wAbfXJhpOTKZU=.a0ef70aa-61d5-4111-9170-63cd9f5013b0@github.com>
 <hWPmrjW9tEViQVGSuF0QAY7PniK8J0LVvKJ
 0fThcvJA=.a61eae44-a0ed-44c3-82c9-cf2e031d6581@github.com>
 <sXLJgnHB8eEGdQnRlYikjc6R6PzNMCYzMosdEyr25IY=.4ed97eb8-b954-4ccb-8ed6-381ad73f9245@github.com>
 <B83h3J_JdLSr_QRc-ExkESDe-pyOxzpjXvGk6zCQhJE=.6a331882-35a4-4ce8-8136-30a03a80aa05@github.com>
 <N_7guPY4IKbVc3_2f7SQDf1KSOSXrUL7fIcn2T5ZuBk=.73250f06-f78c-4a68-a689-98db0af22881@github.com>
 <YBjgVCncT9koFcVMIFsws18mQe8oKzFc4yNx6KzrKsw=.9faa1118-d00a-4736-ba9a-ca63f34e4407@github.com>
 <LvnyLNDnIDmfWT4KyzlRfXe1ljCbUM9QEyD7vKkN5dI=.119644cf-99b4-45b4-a5bb-020be5743679@github.com>
 <UFgMmvt8ugD3exa6OWVFbsVGByYpKEfmWMjsJ2l5pr4=.930fc1e8-e451-44a5-a7d3-39832c17f6c3@github.com>
 <0hPStmab_JXqCsAPhyC9Bk706LWHDMBVPn2sInf4_Uk=.8dd2ae39-faa5-40d6-a02b-41be58e002ce@github.com>
Message-ID: <PvbLaagt2lFO0RwtrA8r-OP2WXCraD9XScESW-mDy7Y=.c526ca69-9cf3-487d-8a81-c15b7f96e71b@github.com>

On Mon, 8 May 2023 16:47:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> I added another proposal in you PR at [#13470 (comment)](https://github.com/openjdk/jdk/pull/13470#issuecomment-1508915798).
>> 
>> I like the idea to use abstract class.  The concerns about provider() method get addressed.
>
> I take back the proposal.

I take back the proposal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1187661541

From mpowers at openjdk.org  Mon May  8 16:55:42 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 8 May 2023 16:55:42 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <oZMF9CKi9WbgD2kErS9SyGj2P4Vgwm-MYLU_3oGVjsI=.97427f5d-69be-4634-9406-b9814ee4f80c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <erFxtT_f73YLetiFFKAl4wZS2YCdDMk_eLV3jtnsqGo=.0f0ba2fc-ce0d-4e64-88e2-74b0b0982f15@github.com>
 <NMKJlkWquX8LpL4zaaTwoauSoyqv7CbMBLAbrQBly3A=.a7dd4d24-7f38-4a50-ac5d-af601e9da1e1@github.com>
 <3JJT2FXkvXoKeI-eBx-2Js9cN3Yp4s1sbjF0VLGxY14=.6cc1d8ca-405d-476b-98d7-a4bf18e67fc7@github.com>
 <oZMF9CKi9WbgD2kErS9SyGj2P4Vgwm-MYLU_3oGVjsI=.97427f5d-69be-4634-9406-b9814ee4f80c@github.com>
Message-ID: <NsT3Y9GPkZIrBQGfdfVKmZNpkZu92uBdvWiPVtqkY8g=.3e6742af-ee2e-4a5c-bc5d-ee09ca03c11f@github.com>

On Mon, 8 May 2023 16:16:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ok. Try to keep your line lengths to about 80 chars.
>
> I think so too. This class is only used by tests now so it will not have any negative performance impact on real users. If we want to move it into the public one day then we don't need to update it.

The test currently converts input keys into RawKeySpec and x509 objects and performs verification on both. RawKeySpec is nice but I could live without it if I had to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187665316

From weijun at openjdk.org  Mon May  8 17:22:53 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 17:22:53 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v2]
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <uQY9mbvzjKKDLZatIjNOvaIhVl1vb3qrGbgNh0h5ukU=.e341eb1c-d37d-4ec8-b2c9-242b2294db0b@github.com>

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

  cleanup commented out code and unnecessary bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13840/files
  - new: https://git.openjdk.org/jdk/pull/13840/files/b99d0a1d..6cde121b

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

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

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

From mdonovan at openjdk.org  Mon May  8 17:56:41 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 8 May 2023 17:56:41 GMT
Subject: RFR: 8306015: Update sun.security.ssl TLS tests to use
 SSLContextTemplate or SSLEngineTemplate [v2]
In-Reply-To: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com>
References: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com>
Message-ID: <dsPJyqvzVS5DUe2v07wputEhkqJhyWc_gyFujYpZJdA=.3cb334de-9186-4d99-8ca4-29137dc08c50@github.com>

> I refactored tests in the test/jdk/sun/security/ssl directories to use the test template classes.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into sun.security.ssl
 - 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate

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

Changes: https://git.openjdk.org/jdk/pull/13495/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13495&range=01
  Stats: 2221 lines in 22 files changed: 162 ins; 1724 del; 335 mod
  Patch: https://git.openjdk.org/jdk/pull/13495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13495/head:pull/13495

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

From vlivanov at openjdk.org  Mon May  8 18:02:33 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 8 May 2023 18:02:33 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v12]
In-Reply-To: <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>
Message-ID: <_QCxNp2slZ7n9AQvfzl_a8ftbokD6fD44f6a538jsO0=.b7c658df-5a6e-42f6-b80b-4e09398f3d79@github.com>

On Mon, 1 May 2023 20:20:51 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>  - Address part of PR review 4 & fix a bug setting only_candidate
>  - Catching up with master
>    
>    Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>  - Fix tests. Remember previous reducible Phis.
>  - Address PR review 3. Some comments and be able to abort compilation.
>  - Merge with Master
>  - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.
>  - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>  - Add support for SR'ing some inputs of merges used for field loads
>  - Fix some typos and do some small refactorings.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1

It took longer than I expected, but I finished looking into debug info. 

A couple of minor comments first:
  * Please, ensure that the AllocationMergesTests.java has cases to trigger the case when SRs and NSRs meet at a merge point. I was not able to provoke it with the unit test.
  * diagnostic output becomes much harder to read (sample output follows).

Sample output:

- ordniary SR case

   Expression stack
    - @0: obj: ID=1335, only_merge_candidate=0, skip_field_assignment=0, N.Fields=4, klass: java.lang.String
Fields: 0, 0, 0, nullptr
...
   Objects
obj: ID=1335, only_merge_candidate=0, skip_field_assignment=0, N.Fields=4, klass: java.lang.String 
Fields: 0, 0, 0, nullptr 


- mixed merge case:

ScopeDesc(pc=0x00000001080bc664 offset=1824):
   java.lang.String::substring at 8 (line 2830)
   Locals 
    - l0: merge: ID=1781, N.Candidates=1
...
   Objects
merge: ID=1781, N.Candidates=1obj: ID=1782, only_merge_candidate=1, skip_field_assignment=0, N.Fields=4, klass: java.lang.String 
Fields: 0, 0, 0, reg rfp [58],oop

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1538801137

From vlivanov at openjdk.org  Mon May  8 18:24:24 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 8 May 2023 18:24:24 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v12]
In-Reply-To: <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>
Message-ID: <gChFPVnsZEo1FdVIkgEQmdF9NqlZr3S_9tCF1LIxSfE=.c7e51b1b-a75f-4e1f-838c-6f148f172783@github.com>

On Mon, 1 May 2023 20:20:51 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>  - Address part of PR review 4 & fix a bug setting only_candidate
>  - Catching up with master
>    
>    Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>  - Fix tests. Remember previous reducible Phis.
>  - Address PR review 3. Some comments and be able to abort compilation.
>  - Merge with Master
>  - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.
>  - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>  - Add support for SR'ing some inputs of merges used for field loads
>  - Fix some typos and do some small refactorings.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1

Speaking of debug info design, it seems there's a need for an additional transformation step now.

Originally, all the operations were performed right on the deserialized debug info representation. It was well-justified at first, but slowly accrued with special cases (nulls, autobox, vectors) and merges push it over the limit IMO.

I propose to introduce an additional pass which takes original debug info and, based on current JVM state (`frame` + `RegisterMap`), transforms it into a list of objects to be materialized and a graph of `ScopeValue`s which depend on them. It would isolate preprocessing logic you have scattered across multiple places, simplify rematerialization, make it easier to find out what happens during deoptimizaiton in each particular case. Moreover, it'll enable support for more complex scenarios (e.g., nested merges) which I expect to eventually emerge in followup enhancements.

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1538835019

From valeriep at openjdk.org  Mon May  8 18:50:25 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 8 May 2023 18:50:25 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries
In-Reply-To: <YvFV0TX8ERCosG73SdgXf3R1T2nNtFXIbkE1oHQeCzs=.05c1f0eb-7313-4f20-b259-d3ec776991ba@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <skyKJaIRZ6yK2m7lzVQOn6j9E4o0xi1y57w0AV_R534=.68b96468-7516-4f27-939a-3edcad2e4af2@github.com>
 <r8caLHaGlfuuJ9_oA_QGVz4QOlLBXc4iOqRpaFfFH84=.4cb2737a-e2be-4b74-8431-20ac92311170@github.com>
 <YvFV0TX8ERCosG73SdgXf3R1T2nNtFXIbkE1oHQeCzs=.05c1f0eb-7313-4f20-b259-d3ec776991ba@github.com>
Message-ID: <ifCK88q1f-9FIr5GTkU9Jwvq8tODZjZswPU4FWtvGgk=.2c0d87c7-4ba0-4299-a298-cd46f9bdfa95@github.com>

On Fri, 5 May 2023 22:59:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hmm, I think the rest of chain should still be checked and removed if no dependents for them.
>
> Of course, I was only talking about the final return value.
> 
> And, I take back my words. This method should return true no matter what `destroyIt` is. The return value is only used in `deleteEntry` and it should be true even if the.cert is used elsewhere.

Yes, I also think that true should be returned regardless of the destroyIt value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1187775836

From valeriep at openjdk.org  Mon May  8 19:02:15 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 8 May 2023 19:02:15 GMT
Subject: RFR: 8168469: Memory leak in JceSecurity
In-Reply-To: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
References: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
Message-ID: <Oua5QitS-A5USuHdv-qBCQwcjd8QojKy-iF5oRSP9T8=.624dcbb0-2488-446e-89e3-e131c42bde78@github.com>

On Tue, 25 Apr 2023 21:16:41 GMT, Sergey Chernyshev <duke at openjdk.org> wrote:

> Hi all,
> 
> I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME.
> 
> The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap<Class<? extends Provider>, Object>` instead of `IdentityHashMap<Provider, Object>`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper<Provider> `objects that maintained the object identity while improved performance.
> 
> The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference<Object>` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called.
> 
> `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers.
> 
> I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test.
> 
> Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions
> 
> [1] https://mail.openjdk.org/pipermail/security-dev/2016-October/015024.html
> [2] https://bugs.openjdk.org/browse/JDK-8168469
> [3] https://bugs.openjdk.org/browse/JDK-7107615
> [4] https://github.com/openjdk/jdk/commit/74d45e481d1ad6aa5d7c6315ea86681e1a978ce0

Ok, I will take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/13658#issuecomment-1538884786

From mpowers at openjdk.org  Mon May  8 20:16:44 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Mon, 8 May 2023 20:16:44 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v7]
In-Reply-To: <DNFloZmonN6pp3bL9e07wBrtm7oY9HEVw3mWnF8yr94=.a56438ae-3d1b-4ca1-8a1f-169181a7f88e@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
 <DNFloZmonN6pp3bL9e07wBrtm7oY9HEVw3mWnF8yr94=.a56438ae-3d1b-4ca1-8a1f-169181a7f88e@github.com>
Message-ID: <PyA71yvQs7mZQ5YwduUpAJ1j7UXJeYPXBUgQ7Zrwbjc=.fc94c223-eb7c-4665-9305-a2c1af1ea750@github.com>

On Mon, 8 May 2023 16:24:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing more review comments from @wangweij and @seanjmullan
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 240:
> 
>> 238:         public final static int LMS_SHA256_M32_H20 = 8;
>> 239:         public final static int LMS_SHA256_M32_H25 = 9;
>> 240:         public final static int LMS_SHA256_M24_H5 = 10;
> 
> Shall we remove the SHA256_M24 and SHAKE constants at the moment?

I think unused code is a distraction. That said, SHA256_M24 used to work. Can't we be better than BC and support M24?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1187853903

From mullan at openjdk.org  Mon May  8 20:48:26 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 May 2023 20:48:26 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v2]
In-Reply-To: <uQY9mbvzjKKDLZatIjNOvaIhVl1vb3qrGbgNh0h5ukU=.e341eb1c-d37d-4ec8-b2c9-242b2294db0b@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
 <uQY9mbvzjKKDLZatIjNOvaIhVl1vb3qrGbgNh0h5ukU=.e341eb1c-d37d-4ec8-b2c9-242b2294db0b@github.com>
Message-ID: <LRntQTAYwrelX_s0228jiq0NMX_9f_t6BnW9xQf3Voo=.46ac50eb-0b12-491d-afaa-577c785dcdf3@github.com>

On Mon, 8 May 2023 17:22:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Update XML Security for Java to 3.0.2. Some change to tests:
>> 
>> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
>> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup commented out code and unnecessary bug id

src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/SignatureMethod.java line 63:

> 61: public interface SignatureMethod extends XMLStructure, AlgorithmMethod {
> 62: 
> 63:     // All methods can be found in RFC 9231.

Only the ones with "xmldsig-more" in the URI, actually.

src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/SignatureMethod.java line 260:

> 258:     /**
> 259:      * The <a href="http://www.w3.org/2021/04/xmldsig-more#eddsa-ed25519">
> 260:      * ED25519</a> signature method algorithm URI.

I think it would be beneficial to add a reference to the standards. Most of these URIs are defined in RFC 9131, but a few are from the W3C Recommendation. I suggest adding the following sentence to the class description:

"The signature method algorithm URIs defined in this class are specified in the [W3C Recommendation for XML-Signature Syntax and Processing](http://www.w3.org/TR/xmldsig-core/) and [RFC 9131](https://www.rfc-editor.org/info/rfc9131)."

test/jdk/javax/xml/crypto/dsig/GenerationTests.java line 105:

> 103:             rsaSha1mgf1, rsaSha224mgf1, rsaSha256mgf1, rsaSha384mgf1, rsaSha512mgf1,
> 104:             rsaShaPSS,
> 105:             ed25519, ed448;

Nit: combine these lines.

test/jdk/javax/xml/crypto/dsig/XalanTest.java line 1:

> 1: /*

Can you add a comment to this test with more details, something like: "This test used to be part of ValidationTests but was moved into its own test because it tests a signature that contains the `here()` function which depends on Xalan internals. The Xalan dependency has been removed from the DSig implementation but can be optionally configured ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1187870857
PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1187866459
PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1187845348
PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1187862788

From mullan at openjdk.org  Mon May  8 21:17:22 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 8 May 2023 21:17:22 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v2]
In-Reply-To: <9GKBTRwAn2vsNoXU6-raZPYjUq9n3JVxdSsANcL0EDA=.0840997c-882c-4c1a-97da-318d50901967@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
 <9GKBTRwAn2vsNoXU6-raZPYjUq9n3JVxdSsANcL0EDA=.0840997c-882c-4c1a-97da-318d50901967@github.com>
Message-ID: <7mQCRQeIcvwi9Z6MTZeJ_yVtbW-fi_B4LnBL9bda3Uw=.df13a05f-2b45-48cb-9325-7c23a28b14e6@github.com>

On Fri, 5 May 2023 01:21:32 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.
>> 
>> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.
>> 
>> CSR has been filed.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add NPE for SecureRandom(byte[]) ctor and setSeed(byte[]) method.

test/jdk/sun/security/pkcs11/SecureRandom/NextBytesNull.java line 1:

> 1: /*

Since the null checks are now all in `SecureRandom`, it doesn't seem that useful to check the individual providers. Maybe combine these tests and just check that the API methods throw NPE?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1187904659

From weijun at openjdk.org  Mon May  8 22:23:44 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 8 May 2023 22:23:44 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v3]
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <Y7ImLAHS2T6c63hD03t-2FdKDNBuX1VmgfxqTdgsdZE=.18af676d-e9e1-421a-bbe5-b94d185822bd@github.com>

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

  more comment and spec refine

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13840/files
  - new: https://git.openjdk.org/jdk/pull/13840/files/6cde121b..3854752d

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

  Stats: 28 lines in 4 files changed: 19 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840

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

From cslucas at openjdk.org  Mon May  8 22:53:31 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 8 May 2023 22:53:31 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v12]
In-Reply-To: <gChFPVnsZEo1FdVIkgEQmdF9NqlZr3S_9tCF1LIxSfE=.c7e51b1b-a75f-4e1f-838c-6f148f172783@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>
 <gChFPVnsZEo1FdVIkgEQmdF9NqlZr3S_9tCF1LIxSfE=.c7e51b1b-a75f-4e1f-838c-6f148f172783@github.com>
Message-ID: <4PBnXq7Eci77beY5cjMGEiuqpRfDcQF9Hwln0ADgDb4=.20c74eb7-f7f8-46be-a005-34dbfd5cdd96@github.com>

On Mon, 8 May 2023 18:21:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>>  - Address part of PR review 4 & fix a bug setting only_candidate
>>  - Catching up with master
>>    
>>    Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>>  - Fix tests. Remember previous reducible Phis.
>>  - Address PR review 3. Some comments and be able to abort compilation.
>>  - Merge with Master
>>  - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.
>>  - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>>  - Add support for SR'ing some inputs of merges used for field loads
>>  - Fix some typos and do some small refactorings.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1
>
> Speaking of debug info design, it seems there's a need for an additional transformation step now.
> 
> Originally, all the operations were performed right on the deserialized debug info representation. It was well-justified at first, but slowly accrued with special cases (nulls, autobox, vectors) and merges push it over the limit IMO.
> 
> I propose to introduce an additional pass which takes original debug info and, based on current JVM state (`frame` + `RegisterMap`), transforms it into a list of objects to be materialized and a graph of `ScopeValue`s which depend on them. It would isolate preprocessing logic you have scattered across multiple places, simplify rematerialization, make it easier to find out what happens during deoptimizaiton in each particular case. Moreover, it'll enable support for more complex scenarios (e.g., nested merges) which I expect to eventually emerge in followup enhancements.

Thank you @iwanowww for taking the time to review this! Please let me ask you some clarifying questions.

> A couple of minor comments first [...]

I'll address those asap! Thanks.

> I propose to introduce an additional pass which takes original debug info [...]

What kind of pass are you referring to exactly? When would this pass run? By "original debug info" you mean the debug information stream?

> It would isolate preprocessing logic you have scattered across multiple places [...]

Which preprocessing logic are you referring to exactly?

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1539161396

From vlivanov at openjdk.org  Tue May  9 00:06:33 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 9 May 2023 00:06:33 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v12]
In-Reply-To: <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>
Message-ID: <JnQgYSu4RMufdETsreXNI7oaFUpdqpwhBMbH9ZA5EbM=.cd5ef1fe-4660-40d4-851d-f26eeab99960@github.com>

On Mon, 1 May 2023 20:20:51 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>  - Address part of PR review 4 & fix a bug setting only_candidate
>  - Catching up with master
>    
>    Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>  - Fix tests. Remember previous reducible Phis.
>  - Address PR review 3. Some comments and be able to abort compilation.
>  - Merge with Master
>  - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.
>  - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>  - Add support for SR'ing some inputs of merges used for field loads
>  - Fix some typos and do some small refactorings.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1

The new pass over deserialized debug info would adapt `ScopeDesc::objects()` (initialized by `decode_object_values(obj_decode_offset)` and accesses through `chunk->at(0)->scope()->objects()`) and produce 2 lists:
  * new list of objects which enumerates all scalarized instances which needs to be rematerialized;
  * complete set of objects referenced in the current scope (the purpose `chunk->at(0)->scope()->objects()` serves now).

It should be performed before `rematerialize_objects`.

By preprocessing I mean all the conditional checks before it is attempted to reallocate an `ObjectValue`. By the end of the new pass, it should be enough to just iterate over the new list of scalarized instances in `Deoptimization::realloc_objects`. And after `Deoptimization::realloc_objects` and `Deoptimization::reassign_fields` are over, debug info should be ready to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1539210279

From mdonovan at openjdk.org  Tue May  9 11:16:16 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 9 May 2023 11:16:16 GMT
Subject: RFR: 8306015: Update sun.security.ssl TLS tests to use
 SSLContextTemplate or SSLEngineTemplate [v2]
In-Reply-To: <dsPJyqvzVS5DUe2v07wputEhkqJhyWc_gyFujYpZJdA=.3cb334de-9186-4d99-8ca4-29137dc08c50@github.com>
References: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com>
 <dsPJyqvzVS5DUe2v07wputEhkqJhyWc_gyFujYpZJdA=.3cb334de-9186-4d99-8ca4-29137dc08c50@github.com>
Message-ID: <XK8-QM5S2Aliht8xBFJFuEf_JzqG24QMi4Un0NKS6oA=.9771b110-a608-4d40-80ae-c027684ad3c7@github.com>

On Mon, 8 May 2023 17:56:41 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> I refactored tests in the test/jdk/sun/security/ssl directories to use the test template classes.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into sun.security.ssl
>  - 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate

Could someone review this, please?

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/13495#issuecomment-1539978310

From duke at openjdk.org  Tue May  9 12:45:27 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 9 May 2023 12:45:27 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  agreeing with the newest review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/b8064640..68ab57b2

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

  Stats: 269 lines in 1 file changed: 84 ins; 116 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/13691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691

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

From duke at openjdk.org  Tue May  9 12:45:33 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 9 May 2023 12:45:33 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v7]
In-Reply-To: <9oyYOfazlu7cyszP6M-EeJ1q8HrkgBwOilN_YcJPV5Y=.ccfafdc1-8262-411d-8a76-90a62c3278ff@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
 <9oyYOfazlu7cyszP6M-EeJ1q8HrkgBwOilN_YcJPV5Y=.ccfafdc1-8262-411d-8a76-90a62c3278ff@github.com>
Message-ID: <5za3DV_aGB2MYCgO3BGSn8ay7FKaVl2ZB_vhu5kWvzA=.e2d5b97a-517e-4fbd-9d8d-8840d3dfe9a2@github.com>

On Mon, 8 May 2023 16:13:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing more review comments from @wangweij and @seanjmullan
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 99:
> 
>> 97:             result &= lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray());
>> 98:             return result;
>> 99:         } catch (Exception e) {
> 
> Do we need this `catch`? I think only `SignatureException` can be thrown inside the `try` block.

No, we don't. Removed.

> src/java.base/share/classes/sun/security/provider/HSS.java line 383:
> 
>> 381:         final byte[] sigArr;
>> 382: 
>> 383:         public LMSignature(byte[] sigArray, int offset, boolean checkExactLen) throws SignatureException {
> 
> The methods of `LMSignature` can be package-private.

Changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534132
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534269

From duke at openjdk.org  Tue May  9 12:45:38 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 9 May 2023 12:45:38 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v7]
In-Reply-To: <3kJX5uh8UxbY852mLsh2XivNSl7jfVnx6M6m3LAHvsk=.119f255f-b4bb-483f-b967-9e93550983d4@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
 <3kJX5uh8UxbY852mLsh2XivNSl7jfVnx6M6m3LAHvsk=.119f255f-b4bb-483f-b967-9e93550983d4@github.com>
Message-ID: <t3loZ_J7QPxdaz_C7hLYeXaVq5hhbNJr7x-m-qb0MsE=.9a99fcb6-a8c4-4e57-8287-b34156923c83@github.com>

On Mon, 8 May 2023 16:29:49 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing more review comments from @wangweij and @seanjmullan
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 106:
> 
>> 104:     }
>> 105: 
>> 106:     protected boolean lmsVerify(LMSPublicKey lmsPublicKey, LMSignature sig, byte[] message) throws SignatureException {
> 
> We probably should put this method into an inner class and make it static.

Good idea. I moved it to LMSUtils.

> src/java.base/share/classes/sun/security/provider/HSS.java line 158:
> 
>> 156:             }
>> 157:             return lmsPublicKey.isT1(tmpMsg, 22 + m);
>> 158:         } catch (Exception e) {
> 
> Avoid using `catch (Exception e)` because that's too wide. In fact, here it seems the only checked exceptions that can be caught is `NoSuchAlgorithmException | DigestException`. I think we've agreed to throw `ProviderException` for them.

Changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188533636
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188533908

From duke at openjdk.org  Tue May  9 12:45:41 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 9 May 2023 12:45:41 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
Message-ID: <PD6liMz8i9rD6MoUQe5bWabNe4IPamrvKtDt_CGazJ8=.686346bf-36c1-4c3b-8d45-7d6e1f138b4e@github.com>

On Thu, 4 May 2023 21:13:24 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding key translation, finally block, removing 24-byte LMOTS parameters
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 181:
> 
>> 179:             try {
>> 180:                 lmParams = new LMParams(type);
>> 181:                 lmotsParams = LMOTSParams.of(otsType);
> 
> Try to code `LMParams` and `LMOTSParams` the same style by choosing from using a constructor or static `of` method. Should `LMParams` be renamed to `LMSParams`?

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 294:
> 
>> 292:         LMOTSignature(byte[] sigArray, LMOTSParams lmotsParams) throws InvalidParameterException {
>> 293:             int inLen = sigArray.length;
>> 294:             if (inLen < 4)
> 
> Add braces around the one-line block. Same as in lines 300, 173, 461, 472, 487, 569, 571, and 783.

Done

> src/java.base/share/classes/sun/security/provider/HSS.java line 357:
> 
>> 355:                     break;
>> 356: 
>> 357: /*
> 
> Remove commented-out lines if they cannot be supported on time.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534977
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188535603
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188535363

From duke at openjdk.org  Tue May  9 12:45:47 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 9 May 2023 12:45:47 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v7]
In-Reply-To: <PyA71yvQs7mZQ5YwduUpAJ1j7UXJeYPXBUgQ7Zrwbjc=.fc94c223-eb7c-4665-9305-a2c1af1ea750@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <QZn4bcpjFWGs0zO_7GlTk4V42MWkFUeQT1sM2oe-2Oo=.0ce38c45-d61f-4eb4-bdb9-9a001806f87a@github.com>
 <DNFloZmonN6pp3bL9e07wBrtm7oY9HEVw3mWnF8yr94=.a56438ae-3d1b-4ca1-8a1f-169181a7f88e@github.com>
 <PyA71yvQs7mZQ5YwduUpAJ1j7UXJeYPXBUgQ7Zrwbjc=.fc94c223-eb7c-4665-9305-a2c1af1ea750@github.com>
Message-ID: <YdsQsBrKFGwMZU2YBXePGQYxSiKwRV2cliI476jhmUs=.7f47b05b-07b5-4194-a272-68f32d06dc0c@github.com>

On Mon, 8 May 2023 20:14:01 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 240:
>> 
>>> 238:         public final static int LMS_SHA256_M32_H20 = 8;
>>> 239:         public final static int LMS_SHA256_M32_H25 = 9;
>>> 240:         public final static int LMS_SHA256_M24_H5 = 10;
>> 
>> Shall we remove the SHA256_M24 and SHAKE constants at the moment?
>
> I think unused code is a distraction. That said, SHA256_M24 used to work. Can't we be better than BC and support M24?

I have removed everything that is not SHA-256, but kept a version of the code that has all those removed things so that in case we decide to put it back, it will be there in my work tree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188533796

From duke at openjdk.org  Tue May  9 12:45:48 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 9 May 2023 12:45:48 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <KVBSwuvxuMjq2YoNL2BIvjVQBXtApHkK6vMSPqbDu_c=.3665c062-3b32-4501-922c-7598b67c84e7@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <QxdQw19wl4lXxdifzZzEx1ptBeyMTVRTXprK3Uzz89c=.49c83638-3b48-4681-91cc-8c5583c4fbf6@github.com>
 <KVBSwuvxuMjq2YoNL2BIvjVQBXtApHkK6vMSPqbDu_c=.3665c062-3b32-4501-922c-7598b67c84e7@github.com>
Message-ID: <BUBnYRPDiYuqRYBPq9BSw70SttTd90zO7el1k_TEoHE=.9000d44b-0e8c-4b80-a1a0-3ab87e75cc32@github.com>

On Mon, 8 May 2023 16:38:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 528:
>> 
>>> 526:         // update()-digest() sequence) which is parametrized so that the digest output is copied back into this buffer.
>>> 527:         // This way, we avoid memory allocations and some computations that would have to be done otherwise.
>>> 528:         final byte[] hashBuf;
>> 
>> I'm a little worried about the mutability of `hashBuf` and whether it's suitable to be put inside `LMOTSParams`.  By using `of` to return an `LMOTSParams` object we have the chance to return cached objects in the future. There should always be one `hashBuf` for each LM-OTS verification, and this is not clear from the current code.
>
> How will the performance change if we make `hashbufSha256_24` and `hashbufSha256_32` static and each time we want to verify an LM-OTS signature we clone one of them?

Changed. There should not be noticeable performance difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534788

From duke at openjdk.org  Tue May  9 12:45:44 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 9 May 2023 12:45:44 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v5]
In-Reply-To: <U9kaaNma3S2uTi1y-9bdDo84_G-UD9-H8slF8W8mpiU=.9bc77391-c470-4b28-8343-7944934e36c6@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <Ud2kHygsp5UQhnwsFYtM92lnoACdNjQmiDemI4tiAuQ=.c284af8f-24c5-41a2-b600-cd5c995ef4b8@github.com>
 <U9kaaNma3S2uTi1y-9bdDo84_G-UD9-H8slF8W8mpiU=.9bc77391-c470-4b28-8343-7944934e36c6@github.com>
Message-ID: <-3epbCTTZfCU9BzyGqAlRmayTPkzOZhDI5dIAFp9g-M=.091cc064-30d1-408e-9d00-cf93001366aa@github.com>

On Mon, 8 May 2023 14:14:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding key translation, finally block, removing 24-byte LMOTS parameters
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 229:
> 
>> 227: 
>> 228:     static class LMSUtils {
>> 229:         public final static int LMS_RESERVED = 0;
> 
> The statics and methods of `LMSUtils` can all be package-private.

Changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188534400

From weijun at openjdk.org  Tue May  9 13:33:34 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 May 2023 13:33:34 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
Message-ID: <aY3bZAlx2MJIo1Ja0e_GcKVIIkl5_PP9otULI8lAYvg=.bb85f36a-f5d8-47a3-af3d-519c8a3ec246@github.com>

On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   agreeing with the newest review comments

src/java.base/share/classes/sun/security/provider/HSS.java line 97:

> 95: 
> 96:         result &= LMSUtils.lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray());
> 97:         messageStream.reset();

We still need the `messageStream.reset()` call in a `finally` block even if there is no `catch` block. It must be called even if an exception is thrown.

src/java.base/share/classes/sun/security/provider/HSS.java line 376:

> 374:                 qArr = Arrays.copyOfRange(sigArray, offset, offset + 4);
> 375:                 sigOtsType = LMSUtils.fourBytesToInt(sigArray, offset + 4);
> 376:                 lmotsParams = LMOTSParams.of(sigOtsType);

Only this single line needs to be put in the `try` block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188599102
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188603688

From mullan at openjdk.org  Tue May  9 13:33:35 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 9 May 2023 13:33:35 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
Message-ID: <rj5wB2syKUGPbOXQIrBX9JH8ZEldFJQ5G_aoA4vI60I=.51975759-2b6c-4ef6-8646-70d8a0574993@github.com>

On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   agreeing with the newest review comments

src/java.base/share/classes/sun/security/provider/HSS.java line 654:

> 652:     }
> 653: 
> 654:     static class HSSPublicKey extends X509Key implements Length {

Is there a significant value in extending `X509Key`? I think that is primarily to help in the parsing by calling `super()`, but you are not using that. You could override `toString()`, `getFormat()`, `getEncoded()`, etc and probably get the same functionality. @wangweij any thoughts on this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188605020

From weijun at openjdk.org  Tue May  9 13:40:28 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 May 2023 13:40:28 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
Message-ID: <JBQSg5GMuUziY-L2k1Rg6cZ-1xrDUKuKyd893oBr2SI=.e61bdc2a-4244-46fc-adff-61dd2727596b@github.com>

On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   agreeing with the newest review comments

src/java.base/share/classes/sun/security/provider/HSS.java line 474:

> 472:                 sha256Fix = new SHA2.SHA256();
> 473:             } else {
> 474:                 sha256Fix = null;

Or, shall we throw a `ProviderException` or even an `AssertionError` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188613928

From weijun at openjdk.org  Tue May  9 13:59:36 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 May 2023 13:59:36 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
Message-ID: <gQeXAyxNg4klgwnXNcZY-gcWKPZEgbqAUJWyws_8czE=.12cd8f70-c3ac-44ab-8b9b-13c0b8fd2327@github.com>

On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   agreeing with the newest review comments

src/java.base/share/classes/sun/security/provider/HSS.java line 101:

> 99:     }
> 100: 
> 101:     static class LMSPublicKey implements Serializable {

Add a `writeReplace` method. Look at other `PublicKey` implementations for an example.

src/java.base/share/classes/sun/security/provider/HSS.java line 540:

> 538:                 throw new ProviderException("Digest implementation not found", e);
> 539:             }
> 540:             byte[] result = new byte[md.getDigestLength()];

No need to allocate an array here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188643495
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188630397

From mullan at openjdk.org  Tue May  9 13:59:37 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 9 May 2023 13:59:37 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
Message-ID: <I38GCzgKGpk_M-PMSPKXIvgQC-7vFYm7ArZfcT27al8=.dbbfb1c9-af9d-42e2-a427-07c9d5c8ea05@github.com>

On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   agreeing with the newest review comments

src/java.base/share/classes/sun/security/provider/HSS.java line 661:

> 659: 
> 660:         @SuppressWarnings("deprecation")
> 661:         HSSPublicKey(byte[] keyArray) throws InvalidKeyException {

[I deleted my earlier comment]

I am wondering why you don't call `super()` or `decode()`  and override `parseKeyBits()` like other `X509Key` subclasses.

You should also override `writeReplace` so that serialization uses an alternate form when serializing.

It would probably be useful to override `toString()` as well. See other `X509Key` subclasses for more details.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188615922

From weijun at openjdk.org  Tue May  9 14:06:34 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 May 2023 14:06:34 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
Message-ID: <G7JNj9ltXC4ZtmKAmls7aPRLKf09XMunZY7DhUNJywg=.26175076-285f-4f5e-af9e-26444c8c2e2d@github.com>

On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   agreeing with the newest review comments

src/java.base/share/classes/sun/security/provider/HSS.java line 114:

> 112:         }
> 113: 
> 114:         public LMSPublicKey(byte[] keyArray, int offset, boolean checkExactLength) throws InvalidKeyException {

Two methods are still public.

src/java.base/share/classes/sun/security/provider/HSS.java line 255:

> 253:         final int otSigType;
> 254:         final LMOTSParams lmotsParams;
> 255:         final int n;

`n` and `p` can be private.

src/java.base/share/classes/sun/security/provider/HSS.java line 291:

> 289: 
> 290:     static class LMSParams {
> 291:         final int type;

`type` is actually used nowhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188651785
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188648524
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188652844

From weijun at openjdk.org  Tue May  9 14:30:06 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 May 2023 14:30:06 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <I38GCzgKGpk_M-PMSPKXIvgQC-7vFYm7ArZfcT27al8=.dbbfb1c9-af9d-42e2-a427-07c9d5c8ea05@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
 <I38GCzgKGpk_M-PMSPKXIvgQC-7vFYm7ArZfcT27al8=.dbbfb1c9-af9d-42e2-a427-07c9d5c8ea05@github.com>
Message-ID: <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com>

On Tue, 9 May 2023 13:38:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   agreeing with the newest review comments
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 661:
> 
>> 659: 
>> 660:         @SuppressWarnings("deprecation")
>> 661:         HSSPublicKey(byte[] keyArray) throws InvalidKeyException {
> 
> [I deleted my earlier comment]
> 
> I am wondering why you don't call `super()` or `decode()`  and override `parseKeyBits()` like other `X509Key` subclasses.
> 
> You should also override `writeReplace` so that serialization uses an alternate form when serializing.
> 
> It would probably be useful to override `toString()` as well. See other `X509Key` subclasses for more details.

Yes, I also think with `writeReplace` you can make `L` and `lmsPublicKey` transient and there is no need to make `LMSPublicKey` serializable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188692818

From xuelei at openjdk.org  Tue May  9 14:30:09 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 9 May 2023 14:30:09 GMT
Subject: RFR: 8306015: Update sun.security.ssl TLS tests to use
 SSLContextTemplate or SSLEngineTemplate [v2]
In-Reply-To: <dsPJyqvzVS5DUe2v07wputEhkqJhyWc_gyFujYpZJdA=.3cb334de-9186-4d99-8ca4-29137dc08c50@github.com>
References: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com>
 <dsPJyqvzVS5DUe2v07wputEhkqJhyWc_gyFujYpZJdA=.3cb334de-9186-4d99-8ca4-29137dc08c50@github.com>
Message-ID: <kFPPgaBF_T9qDqcwMCPmEYGZrADFPdQFoENLrWgn6fc=.7a6fb18c-567e-485e-b74f-71a5963128ee@github.com>

On Mon, 8 May 2023 17:56:41 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> I refactored tests in the test/jdk/sun/security/ssl directories to use the test template classes.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into sun.security.ssl
>  - 8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate

Marked as reviewed by xuelei (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13495#pullrequestreview-1418772038

From mdonovan at openjdk.org  Tue May  9 14:30:11 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 9 May 2023 14:30:11 GMT
Subject: Integrated: 8306015: Update sun.security.ssl TLS tests to use
 SSLContextTemplate or SSLEngineTemplate
In-Reply-To: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com>
References: <_95_M2lVVip-DoXQrI0SVKDI40NzFrdKfVmzsoYr7Q0=.5e15ff8a-615b-44ad-b392-06b673f741d8@github.com>
Message-ID: <atA8zytbSR0OOdRarv6i__e6dZJgiwE07xdrqNKTaFM=.ce4db358-5ce4-4e0b-a9e0-4f5f4a3c08cf@github.com>

On Mon, 17 Apr 2023 13:27:12 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> I refactored tests in the test/jdk/sun/security/ssl directories to use the test template classes.

This pull request has now been integrated.

Changeset: 5842fd5b
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5842fd5beb13f3458f61df7e7480a54bd2157253
Stats:     2221 lines in 22 files changed: 162 ins; 1724 del; 335 mod

8306015: Update sun.security.ssl TLS tests to use SSLContextTemplate or SSLEngineTemplate

Reviewed-by: xuelei

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

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

From weijun at openjdk.org  Tue May  9 14:40:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 May 2023 14:40:40 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
Message-ID: <XuFrhgEEQXxNHg2HfYzzeeapRcB6WfPq1tKaTnC6lUs=.3b4a29b8-7935-477b-8c84-d51efdad8291@github.com>

On Tue, 9 May 2023 12:45:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   agreeing with the newest review comments

src/java.base/share/classes/sun/security/provider/HSS.java line 47:

> 45: 
> 46:     @Deprecated
> 47:     protected void engineSetParameter(String param, Object value) {

Better to add `@Override` as much as you can.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1188709964

From mullan at openjdk.org  Tue May  9 15:04:19 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 9 May 2023 15:04:19 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v2]
In-Reply-To: <eE6l8nbMN9i-wFxmV-DcTAM3MVgueMpPCYERIvD2uYU=.e344d03a-cec9-4c47-bd47-befd98956206@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <eE6l8nbMN9i-wFxmV-DcTAM3MVgueMpPCYERIvD2uYU=.e344d03a-cec9-4c47-bd47-befd98956206@github.com>
Message-ID: <DsPdqVaxd3A3mHtndZGpuO1D7IQ-ldq1_lH_a0vvllg=.4147f3e2-75a9-4539-80bd-ba3a11df2d62@github.com>

On Wed, 3 May 2023 13:15:32 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
>> 
>> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
>> 
>> JBS: https://bugs.openjdk.org/browse/JDK-8179502
>> CSR: https://bugs.openjdk.org/browse/JDK-8300722
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add 's' suffix to allowed syntax

I think you should also apply the cert and CRL timeouts to the `LDAPCertStore` implementation, using the JNDI properties: `com.sun.jndi.ldap.connect.timeout` and `com.sun.jndi.ldap.read.timeout`.

src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 1:

> 1: /*

I see there is no way to individually control the OCSP read and connect timeouts like there is for certs and CRLs. Perhaps this isn't as big an issue, but when you set the OCSP timeout, it really means 2x what you set.

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

PR Comment: https://git.openjdk.org/jdk/pull/13762#issuecomment-1540310480
PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1188745318

From mullan at openjdk.org  Tue May  9 15:21:29 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 9 May 2023 15:21:29 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v3]
In-Reply-To: <Y7ImLAHS2T6c63hD03t-2FdKDNBuX1VmgfxqTdgsdZE=.18af676d-e9e1-421a-bbe5-b94d185822bd@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
 <Y7ImLAHS2T6c63hD03t-2FdKDNBuX1VmgfxqTdgsdZE=.18af676d-e9e1-421a-bbe5-b94d185822bd@github.com>
Message-ID: <c5aGO-7rLBz-Ll5F4YXHY7W02_dTdaCiVxe9i65wxq0=.7f2185b1-b2fb-44e9-a514-a441574e8378@github.com>

On Mon, 8 May 2023 22:23:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Update XML Security for Java to 3.0.2. Some change to tests:
>> 
>> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
>> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comment and spec refine

test/jdk/javax/xml/crypto/dsig/XalanTest.java line 105:

> 103:         if (!validator.validate("signature.xml", ks, new HttpURIDereferencer(), false)) {
> 104:             throw new Exception
> 105:                     ("At least one signature did not validate as expected");

There's only one signature in this test now, so change message to "Signature did not validate as expected".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1188766257

From jnimeh at openjdk.org  Tue May  9 15:59:34 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 9 May 2023 15:59:34 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v2]
In-Reply-To: <DsPdqVaxd3A3mHtndZGpuO1D7IQ-ldq1_lH_a0vvllg=.4147f3e2-75a9-4539-80bd-ba3a11df2d62@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <eE6l8nbMN9i-wFxmV-DcTAM3MVgueMpPCYERIvD2uYU=.e344d03a-cec9-4c47-bd47-befd98956206@github.com>
 <DsPdqVaxd3A3mHtndZGpuO1D7IQ-ldq1_lH_a0vvllg=.4147f3e2-75a9-4539-80bd-ba3a11df2d62@github.com>
Message-ID: <r1UX9Iejl-Gszfjm6RxsL1rPh9RuV0n7bpRAt-8wiOE=.a8f85e29-11e5-4c2f-91d0-33e68a3debae@github.com>

On Tue, 9 May 2023 15:01:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add 's' suffix to allowed syntax
>
> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 1:
> 
>> 1: /*
> 
> I see there is no way to individually control the OCSP read and connect timeouts like there is for certs and CRLs. Perhaps this isn't as big an issue, but when you set the OCSP timeout, it really means 2x what you set.

Yes, I noticed that too.  I wasn't sure if we needed to make a change there.  I opted to leave well-enough alone since nobody was asking for it and it's one less property to keep track of.  All of these property sets end up with a max latency of connect-timeout + read-timeout, and by default they are set to the same values.  So in practice much of the time they are all 2x.

It's easy enough I think to make a separate property for `com.sun.security.ocsp.readtimeout` and then the existing `.timeout` property would be for connect timeouts (keeping in line with the other props).  I don't think it will introduce significant risk but I will highlight that in the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1188816429

From jnimeh at openjdk.org  Tue May  9 15:59:34 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 9 May 2023 15:59:34 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v2]
In-Reply-To: <r1UX9Iejl-Gszfjm6RxsL1rPh9RuV0n7bpRAt-8wiOE=.a8f85e29-11e5-4c2f-91d0-33e68a3debae@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <eE6l8nbMN9i-wFxmV-DcTAM3MVgueMpPCYERIvD2uYU=.e344d03a-cec9-4c47-bd47-befd98956206@github.com>
 <DsPdqVaxd3A3mHtndZGpuO1D7IQ-ldq1_lH_a0vvllg=.4147f3e2-75a9-4539-80bd-ba3a11df2d62@github.com>
 <r1UX9Iejl-Gszfjm6RxsL1rPh9RuV0n7bpRAt-8wiOE=.a8f85e29-11e5-4c2f-91d0-33e68a3debae@github.com>
Message-ID: <AOzZHTAP9RRGAiofEiYyDagcjzWY-zx_dQ2iUyWlo_U=.ba035a6b-22d2-43ad-8b62-066534bf9e13@github.com>

On Tue, 9 May 2023 15:55:24 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/OCSP.java line 1:
>> 
>>> 1: /*
>> 
>> I see there is no way to individually control the OCSP read and connect timeouts like there is for certs and CRLs. Perhaps this isn't as big an issue, but when you set the OCSP timeout, it really means 2x what you set.
>
> Yes, I noticed that too.  I wasn't sure if we needed to make a change there.  I opted to leave well-enough alone since nobody was asking for it and it's one less property to keep track of.  All of these property sets end up with a max latency of connect-timeout + read-timeout, and by default they are set to the same values.  So in practice much of the time they are all 2x.
> 
> It's easy enough I think to make a separate property for `com.sun.security.ocsp.readtimeout` and then the existing `.timeout` property would be for connect timeouts (keeping in line with the other props).  I don't think it will introduce significant risk but I will highlight that in the CSR.

> I think you should also apply the cert and CRL timeouts to the `LDAPCertStore` implementation, using the JNDI properties: `com.sun.jndi.ldap.connect.timeout` and `com.sun.jndi.ldap.read.timeout`.

I will look into this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1188817169

From weijun at openjdk.org  Tue May  9 16:11:38 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 May 2023 16:11:38 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v3]
In-Reply-To: <c5aGO-7rLBz-Ll5F4YXHY7W02_dTdaCiVxe9i65wxq0=.7f2185b1-b2fb-44e9-a514-a441574e8378@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
 <Y7ImLAHS2T6c63hD03t-2FdKDNBuX1VmgfxqTdgsdZE=.18af676d-e9e1-421a-bbe5-b94d185822bd@github.com>
 <c5aGO-7rLBz-Ll5F4YXHY7W02_dTdaCiVxe9i65wxq0=.7f2185b1-b2fb-44e9-a514-a441574e8378@github.com>
Message-ID: <V8B0yqUeHEDH4Aih5MHH-bRn6bRozkZw3yUjR3-7CVA=.ff30bc05-855a-4915-8b33-cc71768bc58d@github.com>

On Tue, 9 May 2023 15:16:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more comment and spec refine
>
> test/jdk/javax/xml/crypto/dsig/XalanTest.java line 105:
> 
>> 103:         if (!validator.validate("signature.xml", ks, new HttpURIDereferencer(), false)) {
>> 104:             throw new Exception
>> 105:                     ("At least one signature did not validate as expected");
> 
> There's only one signature in this test now, so change message to "Signature did not validate as expected".

Oops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1188831040

From xuelei at openjdk.org  Tue May  9 16:34:11 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 9 May 2023 16:34:11 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v3]
In-Reply-To: <cOSGEHmDgqIrJImmSziZ2lRLQMu2PpdXw9Si0btDQ7Q=.4e1c0324-78f5-406b-904b-7c62701ccdf0@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <BLTahgtHIDyiZd-M7SBz_jdBC6xByNj5boeO_QRB6T8=.617c647f-97ee-4690-b7a3-aee5c96c2835@github.com>
 <cOSGEHmDgqIrJImmSziZ2lRLQMu2PpdXw9Si0btDQ7Q=.4e1c0324-78f5-406b-904b-7c62701ccdf0@github.com>
Message-ID: <e-VB5FOAGc3ekhs4hZ8d-yFQQqagD6WA8aY8i4YDnRQ=.406fc1a5-7f84-482b-b1dd-38f5ef3fa45b@github.com>

On Wed, 3 May 2023 22:11:20 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> I will look at making related changes in these spots as well.
> 
OK.

> @XueleiFan wrt your other question about updating the `getAuthorities` method, I considered this, but it looks like it would involve changing a method signature for that method.

Changing the signature should be fine as it is a internal method.  But I'm fine if the calls to getAuthorities() have considered the impact of illegal values of X500Principal.

Anyway, this is a typical example to show how hard to use runtime exception.  From the viewpoint of X500Principal, and unchecked exception should be thrown for invalid input values.  But for the caller, it may need to check the input values for sure everything is good.  However, an unchecked exception cannot be detected by Java compiler and thus the checking of unchecked exception could be missed.

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

PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1540501498

From cslucas at openjdk.org  Tue May  9 19:06:36 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 9 May 2023 19:06:36 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v12]
In-Reply-To: <JnQgYSu4RMufdETsreXNI7oaFUpdqpwhBMbH9ZA5EbM=.cd5ef1fe-4660-40d4-851d-f26eeab99960@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>
 <JnQgYSu4RMufdETsreXNI7oaFUpdqpwhBMbH9ZA5EbM=.cd5ef1fe-4660-40d4-851d-f26eeab99960@github.com>
Message-ID: <pzWh8m1u1Q3fG5us-6jRYnBzlAKMKpG_M_3-5q6NP9w=.632298da-8d43-4581-8472-f7d60f92ee2d@github.com>

On Tue, 9 May 2023 00:03:26 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>>  - Address part of PR review 4 & fix a bug setting only_candidate
>>  - Catching up with master
>>    
>>    Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>>  - Fix tests. Remember previous reducible Phis.
>>  - Address PR review 3. Some comments and be able to abort compilation.
>>  - Merge with Master
>>  - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.
>>  - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>>  - Add support for SR'ing some inputs of merges used for field loads
>>  - Fix some typos and do some small refactorings.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1
>
> The new pass over deserialized debug info would adapt `ScopeDesc::objects()` (initialized by `decode_object_values(obj_decode_offset)` and accesses through `chunk->at(0)->scope()->objects()`) and produce 2 lists:
>   * new list of objects which enumerates all scalarized instances which needs to be rematerialized;
>   * complete set of objects referenced in the current scope (the purpose `chunk->at(0)->scope()->objects()` serves now).
> 
> It should be performed before `rematerialize_objects`.
> 
> By preprocessing I mean all the conditional checks before it is attempted to reallocate an `ObjectValue`. By the end of the new pass, it should be enough to just iterate over the new list of scalarized instances in `Deoptimization::realloc_objects`. And after `Deoptimization::realloc_objects` and `Deoptimization::reassign_fields` are over, debug info should be ready to go.

Thanks a lot for clarifying @iwanowww . I'll start working on that.

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1540738709

From weijun at openjdk.org  Tue May  9 19:50:44 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 May 2023 19:50:44 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v4]
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <k9IwetFlS8AswiXVT7zo5bM3mAMvtG1iaZ0ZUPdgkxI=.0a65bb8c-a696-46df-94d7-f8ddcc2e424e@github.com>

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

  no more secret exports, one message change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13840/files
  - new: https://git.openjdk.org/jdk/pull/13840/files/3854752d..e3f7f632

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

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

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

From weijun at openjdk.org  Tue May  9 20:48:18 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 May 2023 20:48:18 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v5]
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <dszFl9YWei735POASdA67iBNzbSH3sAEohf4v1BKgOc=.dfea20cd-7f52-4334-97ef-7f29e2f03f0c@github.com>

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

  comment for new test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13840/files
  - new: https://git.openjdk.org/jdk/pull/13840/files/e3f7f632..b4cf0070

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

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

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

From mark.reinhold at oracle.com  Tue May  9 21:39:18 2023
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Tue, 9 May 2023 21:39:18 +0000
Subject: New candidate JEP: 452: Key Encapsulation Mechanism API
Message-ID: <20230509213917.1FCCA5D4CBC@eggemoggin.niobe.net>

https://openjdk.org/jeps/452

  Summary: Introduce an API for key encapsulation mechanisms (KEMs),
  an encryption technique for securing symmetric keys using public key
  cryptography.

- Mark

From valeriep at openjdk.org  Tue May  9 23:41:15 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 9 May 2023 23:41:15 GMT
Subject: RFR: 8168469: Memory leak in JceSecurity
In-Reply-To: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
References: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
Message-ID: <jeJtVhdiWa3dzMjI-Q9-PA37hHX0H8pzJUOfpHHdgYg=.2e5ab908-04de-4141-898a-320113f0f084@github.com>

On Tue, 25 Apr 2023 21:16:41 GMT, Sergey Chernyshev <duke at openjdk.org> wrote:

> Hi all,
> 
> I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME.
> 
> The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap<Class<? extends Provider>, Object>` instead of `IdentityHashMap<Provider, Object>`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper<Provider> `objects that maintained the object identity while improved performance.
> 
> The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference<Object>` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called.
> 
> `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers.
> 
> I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test.
> 
> Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions
> 
> [1] https://mail.openjdk.org/pipermail/security-dev/2016-October/015024.html
> [2] https://bugs.openjdk.org/browse/JDK-8168469
> [3] https://bugs.openjdk.org/browse/JDK-7107615
> [4] https://github.com/openjdk/jdk/commit/74d45e481d1ad6aa5d7c6315ea86681e1a978ce0

Rest looks good to me. Thanks!

src/java.base/share/classes/javax/crypto/JceSecurity.java.template line 217:

> 215:                         // recursion; return failure now
> 216:                         throw new IllegalStateException
> 217:                                 ("Recursion during verification");

nit: no need for repeating error message here since it's not really used in line 242 anyway.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13658#pullrequestreview-1419581596
PR Review Comment: https://git.openjdk.org/jdk/pull/13658#discussion_r1189220726

From duke at openjdk.org  Wed May 10 10:03:46 2023
From: duke at openjdk.org (Sergey Chernyshev)
Date: Wed, 10 May 2023 10:03:46 GMT
Subject: RFR: 8168469: Memory leak in JceSecurity [v2]
In-Reply-To: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
References: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
Message-ID: <IahdnuFEbYv21QTfI9BXLSmfrhLthDWKHtQrC63L3jY=.717c8920-193a-48ee-884c-3684f887c9bd@github.com>

> Hi all,
> 
> I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME.
> 
> The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap<Class<? extends Provider>, Object>` instead of `IdentityHashMap<Provider, Object>`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper<Provider> `objects that maintained the object identity while improved performance.
> 
> The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference<Object>` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called.
> 
> `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers.
> 
> I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test.
> 
> Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions
> 
> [1] https://mail.openjdk.org/pipermail/security-dev/2016-October/015024.html
> [2] https://bugs.openjdk.org/browse/JDK-8168469
> [3] https://bugs.openjdk.org/browse/JDK-7107615
> [4] https://github.com/openjdk/jdk/commit/74d45e481d1ad6aa5d7c6315ea86681e1a978ce0

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  addressed review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13658/files
  - new: https://git.openjdk.org/jdk/pull/13658/files/f8404bd5..ffea537b

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

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

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

From duke at openjdk.org  Wed May 10 10:03:47 2023
From: duke at openjdk.org (Sergey Chernyshev)
Date: Wed, 10 May 2023 10:03:47 GMT
Subject: RFR: 8168469: Memory leak in JceSecurity [v2]
In-Reply-To: <jeJtVhdiWa3dzMjI-Q9-PA37hHX0H8pzJUOfpHHdgYg=.2e5ab908-04de-4141-898a-320113f0f084@github.com>
References: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
 <jeJtVhdiWa3dzMjI-Q9-PA37hHX0H8pzJUOfpHHdgYg=.2e5ab908-04de-4141-898a-320113f0f084@github.com>
Message-ID: <zq_tBfTv0NQgkL28X7bfVmWKDFmbdQ-y68DgqjrD4Fw=.a22df077-d2b1-4155-8b18-82e031c7387f@github.com>

On Tue, 9 May 2023 23:37:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressed review comment
>
> src/java.base/share/classes/javax/crypto/JceSecurity.java.template line 217:
> 
>> 215:                         // recursion; return failure now
>> 216:                         throw new IllegalStateException
>> 217:                                 ("Recursion during verification");
> 
> nit: no need for repeating error message here since it's not really used in line 242 anyway.

Thank you! I updated the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13658#discussion_r1189668166

From jpai at openjdk.org  Wed May 10 12:28:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 May 2023 12:28:30 GMT
Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match
 resuming session [v2]
In-Reply-To: <EiV-EIgnQQUQj5XlZM4wm7k3hMsq-8a3yh54lzMLE6g=.2ca17327-6fd8-40ee-8231-06ac0a74b1d9@github.com>
References: <PeY1YjSnfIMjs-RT5W61EWfQMQD_PkuEiLqYznPvClE=.f15e7870-2286-42a0-bde0-ab17efadb4ec@github.com>
 <EiV-EIgnQQUQj5XlZM4wm7k3hMsq-8a3yh54lzMLE6g=.2ca17327-6fd8-40ee-8231-06ac0a74b1d9@github.com>
Message-ID: <XQKbk-QUHXFoZTQ-6NmMiNctqaqru8ecsHhMknos9fY=.5cdcb3bd-f361-4837-a728-1d8ec95d6e98@github.com>

On Wed, 26 Apr 2023 11:51:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686?
>> 
>> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. 
>> 
>> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. 
>> 
>> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key.  The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue.
>> 
>> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment - use SSLContextTemplate for SSLContext creation in test

Looking for additional reviews on this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/13669#issuecomment-1542117693

From duke at openjdk.org  Wed May 10 15:20:50 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 10 May 2023 15:20:50 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  serialization fixes, more code shaping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/68ab57b2..b363ce7f

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

  Stats: 114 lines in 1 file changed: 61 ins; 20 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/13691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691

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

From duke at openjdk.org  Wed May 10 15:20:53 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 10 May 2023 15:20:53 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <XuFrhgEEQXxNHg2HfYzzeeapRcB6WfPq1tKaTnC6lUs=.3b4a29b8-7935-477b-8c84-d51efdad8291@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
 <XuFrhgEEQXxNHg2HfYzzeeapRcB6WfPq1tKaTnC6lUs=.3b4a29b8-7935-477b-8c84-d51efdad8291@github.com>
Message-ID: <BI7Q_LYfBLLsS8ZwhUJDbooSHIcFzh6E6yj7nisDTyk=.07bb9916-e1c3-4fd7-89b5-4ca9988e1e1a@github.com>

On Tue, 9 May 2023 14:37:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   agreeing with the newest review comments
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 47:
> 
>> 45: 
>> 46:     @Deprecated
>> 47:     protected void engineSetParameter(String param, Object value) {
> 
> Better to add `@Override` as much as you can.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 97:
> 
>> 95: 
>> 96:         result &= LMSUtils.lmsVerify(lmsPubKey, sig.siglist[sig.Nspk], messageStream.toByteArray());
>> 97:         messageStream.reset();
> 
> We still need the `messageStream.reset()` call in a `finally` block even if there is no `catch` block. It must be called even if an exception is thrown.

Reintroduced try/finally.

> src/java.base/share/classes/sun/security/provider/HSS.java line 114:
> 
>> 112:         }
>> 113: 
>> 114:         public LMSPublicKey(byte[] keyArray, int offset, boolean checkExactLength) throws InvalidKeyException {
> 
> Two methods are still public.

One removed, the other changed.

> src/java.base/share/classes/sun/security/provider/HSS.java line 255:
> 
>> 253:         final int otSigType;
>> 254:         final LMOTSParams lmotsParams;
>> 255:         final int n;
> 
> `n` and `p` can be private.

Changed.

> src/java.base/share/classes/sun/security/provider/HSS.java line 376:
> 
>> 374:                 qArr = Arrays.copyOfRange(sigArray, offset, offset + 4);
>> 375:                 sigOtsType = LMSUtils.fourBytesToInt(sigArray, offset + 4);
>> 376:                 lmotsParams = LMOTSParams.of(sigOtsType);
> 
> Only this single line needs to be put in the `try` block.

OK.

> src/java.base/share/classes/sun/security/provider/HSS.java line 474:
> 
>> 472:                 sha256Fix = new SHA2.SHA256();
>> 473:             } else {
>> 474:                 sha256Fix = null;
> 
> Or, shall we throw a `ProviderException` or even an `AssertionError` here?

Doesn't really matter as now it can never be null. I left in the if() in preparation of adding the SHAKE version, but I removed it now.

> src/java.base/share/classes/sun/security/provider/HSS.java line 540:
> 
>> 538:                 throw new ProviderException("Digest implementation not found", e);
>> 539:             }
>> 540:             byte[] result = new byte[md.getDigestLength()];
> 
> No need to allocate an array here.

True. Removed allocation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190064400
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190060922
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190061753
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190061961
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190062147
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190062330
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190062543

From duke at openjdk.org  Wed May 10 15:20:53 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 10 May 2023 15:20:53 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
 <I38GCzgKGpk_M-PMSPKXIvgQC-7vFYm7ArZfcT27al8=.dbbfb1c9-af9d-42e2-a427-07c9d5c8ea05@github.com>
 <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com>
Message-ID: <9Ul0pXZe7p6zw0tCX8G3jc8thPuLhDRaXw11QnRb1sM=.46a9281c-0568-45ef-8f37-f7124634ffaf@github.com>

On Tue, 9 May 2023 14:26:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 661:
>> 
>>> 659: 
>>> 660:         @SuppressWarnings("deprecation")
>>> 661:         HSSPublicKey(byte[] keyArray) throws InvalidKeyException {
>> 
>> [I deleted my earlier comment]
>> 
>> I am wondering why you don't call `super()` or `decode()`  and override `parseKeyBits()` like other `X509Key` subclasses.
>> 
>> You should also override `writeReplace` so that serialization uses an alternate form when serializing.
>> 
>> It would probably be useful to override `toString()` as well. See other `X509Key` subclasses for more details.
>
> Yes, I also think with `writeReplace` you can make `L` and `lmsPublicKey` transient and there is no need to make `LMSPublicKey` serializable.

Overrided writeReplace, toString() and parseKeyBits().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190063347

From mullan at openjdk.org  Wed May 10 15:55:27 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 10 May 2023 15:55:27 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v3]
In-Reply-To: <e-VB5FOAGc3ekhs4hZ8d-yFQQqagD6WA8aY8i4YDnRQ=.406fc1a5-7f84-482b-b1dd-38f5ef3fa45b@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <BLTahgtHIDyiZd-M7SBz_jdBC6xByNj5boeO_QRB6T8=.617c647f-97ee-4690-b7a3-aee5c96c2835@github.com>
 <cOSGEHmDgqIrJImmSziZ2lRLQMu2PpdXw9Si0btDQ7Q=.4e1c0324-78f5-406b-904b-7c62701ccdf0@github.com>
 <e-VB5FOAGc3ekhs4hZ8d-yFQQqagD6WA8aY8i4YDnRQ=.406fc1a5-7f84-482b-b1dd-38f5ef3fa45b@github.com>
Message-ID: <k2z9BHAektTIawnAbxe8gb3_NpZmKTkxL1ldqJKkd3Q=.af5571d6-a372-4ef5-af48-c868547ff59c@github.com>

On Tue, 9 May 2023 16:30:22 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> As for other examples of the `X500Principal(byte[] ..)` constructor being called in TLS packages, here are the ones that don't seem to be handled nicely currently: 
>> 
>> - `consume` in `CertificateAuthoritiesExtension.CRCertificateAuthoritiesConsumer` (could throw IAE, which is an uncaught RuntimeException)
>> - `toString` in `CertificateAuthoritiesExtension.CertificateAuthoritiesSpec` (could throw IAE, which is an uncaught RuntimeException)
>> - `consume` in `CertificateRequest.T10CertificateRequestConsumer` (could throw IAE, which is an uncaught RuntimeException)
>> - `toString` in `CertificateRequest.T10CertificateRequestMessage` (could throw IAE, which is an uncaught RuntimeException)
>> - `consume` in `CertificateRequest.T12CertificateRequestConsumer` (could throw IAE, which is an uncaught RuntimeException)
>> - `toString` in `CertificateRequest.T12CertificateRequestMessage` (could throw IAE, which is an uncaught RuntimeException)
>> 
>> I will look at making related changes in these spots as well. 
>> 
>> @XueleiFan wrt your other question about updating the `getAuthorities` method, I considered this, but it looks like it would involve changing a method signature for that method. This may be fine, but similar changes would need to be made in all the above places anyway, I suspect, unless we can pass information about the context in order to throw an `SSL(Protocol)Exception` and have that bubble-up to where `IOException`s are usually checked. 
>> 
>> @seanjmullan @XueleiFan thoughts on that?
>
>> I will look at making related changes in these spots as well.
>> 
> OK.
> 
>> @XueleiFan wrt your other question about updating the `getAuthorities` method, I considered this, but it looks like it would involve changing a method signature for that method.
> 
> Changing the signature should be fine as it is a internal method.  But I'm fine if the calls to getAuthorities() have considered the impact of illegal values of X500Principal.
> 
> Anyway, this is a typical example to show how hard to use runtime exception.  From the viewpoint of X500Principal, and unchecked exception should be thrown for invalid input values.  But for the caller, it may need to check the input values for sure everything is good.  However, an unchecked exception cannot be detected by Java compiler and thus the checking of unchecked exception could be missed.

I would suggest catching the IAE and rethrowing as an IOE (with the IAE as the cause) if the data is coming from the network. If it is not coming from the network, then don't necessarily rethrow as the IAE could indicate a bug in the JSSE code. I agree with @XueleiFan that it is ok to change internal method signatures, by adding more parameters or throwing exceptions.

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

PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1542441464

From valeriep at openjdk.org  Wed May 10 18:04:15 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 10 May 2023 18:04:15 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v2]
In-Reply-To: <7mQCRQeIcvwi9Z6MTZeJ_yVtbW-fi_B4LnBL9bda3Uw=.df13a05f-2b45-48cb-9325-7c23a28b14e6@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
 <9GKBTRwAn2vsNoXU6-raZPYjUq9n3JVxdSsANcL0EDA=.0840997c-882c-4c1a-97da-318d50901967@github.com>
 <7mQCRQeIcvwi9Z6MTZeJ_yVtbW-fi_B4LnBL9bda3Uw=.df13a05f-2b45-48cb-9325-7c23a28b14e6@github.com>
Message-ID: <LKDXa49d69ZIwodEBWekD_BfkELrZo9fIEqdvOCJb0U=.e3c94dbb-9d49-4999-94f3-e83bc15835b7@github.com>

On Mon, 8 May 2023 21:14: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:
>> 
>>   Add NPE for SecureRandom(byte[]) ctor and setSeed(byte[]) method.
>
> test/jdk/sun/security/pkcs11/SecureRandom/NextBytesNull.java line 1:
> 
>> 1: /*
> 
> Since the null checks are now all in `SecureRandom`, it doesn't seem that useful to check the individual providers. Maybe combine these tests and just check that the API methods throw NPE?

Sounds reasonable, I will give it a try. Thanks~

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1190241279

From weijun at openjdk.org  Wed May 10 21:27:58 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 10 May 2023 21:27:58 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
Message-ID: <A1GTfQTJUqfSdI_P-y22Qiqnf6qYpCDoAptAb8Hk0E0=.ddc757ad-12d1-4cf2-bc77-11e01b1a0ffd@github.com>

On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   serialization fixes, more code shaping

src/java.base/share/classes/sun/security/provider/HSS.java line 672:

> 670:     }
> 671: 
> 672:     static class HSSPublicKey extends X509Key implements Serializable {

Why not implement `Length` anymore? This is useful when you want to print out information of the key or restrict weak keys.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190408445

From weijun at openjdk.org  Wed May 10 22:13:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 10 May 2023 22:13:56 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
Message-ID: <L_uiNSWGGvBbwmIo_2Rx6OFvZSpJOBV2Nak6wC3-35s=.5d5aca7a-9032-4e5d-9a4b-1d170810dd82@github.com>

On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   serialization fixes, more code shaping

src/java.base/share/classes/sun/security/provider/HSS.java line 571:

> 569:                 preCandidate[21] = (byte) 0x80;
> 570: 
> 571:                 byte[] preZi = hashBuf.clone();

We can just call `hashbufSha256_32.clone()` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190437259

From weijun at openjdk.org  Wed May 10 22:20:59 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 10 May 2023 22:20:59 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <BI7Q_LYfBLLsS8ZwhUJDbooSHIcFzh6E6yj7nisDTyk=.07bb9916-e1c3-4fd7-89b5-4ca9988e1e1a@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
 <XuFrhgEEQXxNHg2HfYzzeeapRcB6WfPq1tKaTnC6lUs=.3b4a29b8-7935-477b-8c84-d51efdad8291@github.com>
 <BI7Q_LYfBLLsS8ZwhUJDbooSHIcFzh6E6yj7nisDTyk=.07bb9916-e1c3-4fd7-89b5-4ca9988e1e1a@github.com>
Message-ID: <B0RvwMnttzZzgTMd-_FEiwLuD-KR7kcF5VyzC3xgz80=.aa0d20bc-9580-4965-bc99-0b1da82fdc28@github.com>

On Wed, 10 May 2023 15:15:55 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 47:
>> 
>>> 45: 
>>> 46:     @Deprecated
>>> 47:     protected void engineSetParameter(String param, Object value) {
>> 
>> Better to add `@Override` as much as you can.
>
> Done.

There are much more in this class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190440987

From valeriep at openjdk.org  Wed May 10 23:07:01 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 10 May 2023 23:07:01 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v3]
In-Reply-To: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
Message-ID: <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com>

> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.
> 
> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.
> 
> CSR has been filed.
> 
> Thanks,
> Valerie

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

  updated reg test with review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13788/files
  - new: https://git.openjdk.org/jdk/pull/13788/files/34ebdfa7..3ee76896

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

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

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

From mpowers at openjdk.org  Thu May 11 04:40:05 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 11 May 2023 04:40:05 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
Message-ID: <84M8kxMYfOJi32Wc13yevbm-e6tAjILd0gdLhvqfF-M=.25820c77-e2cd-4a2b-9402-80b6e6ea0432@github.com>

On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   serialization fixes, more code shaping

You might want to look at IntelliJ's suggestions (lower left Problems button). There are about 10 of them. The enhanced switch has a more "modern" look.

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

PR Comment: https://git.openjdk.org/jdk/pull/13691#issuecomment-1543320636

From duke at openjdk.org  Thu May 11 05:56:57 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 11 May 2023 05:56:57 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
Message-ID: <kXVdICvvYrq116GbVlx3CL4bfTrhxF8a_0KRyzj2p5M=.1646b821-c6ae-4018-be1b-87899bc69ac1@github.com>

On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   serialization fixes, more code shaping

Just for the more modern look I don't think we should use newer language features that might make backporting the code to older versions harder.

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

PR Comment: https://git.openjdk.org/jdk/pull/13691#issuecomment-1543378745

From duke at openjdk.org  Thu May 11 06:04:57 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 11 May 2023 06:04:57 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <L_uiNSWGGvBbwmIo_2Rx6OFvZSpJOBV2Nak6wC3-35s=.5d5aca7a-9032-4e5d-9a4b-1d170810dd82@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
 <L_uiNSWGGvBbwmIo_2Rx6OFvZSpJOBV2Nak6wC3-35s=.5d5aca7a-9032-4e5d-9a4b-1d170810dd82@github.com>
Message-ID: <6NWVBkRp6Q7t4iUk45El2XbaLlfbqEFSVrfdDZgK1HI=.c8ebc0d1-2d4d-4f83-ad30-592ec99438f2@github.com>

On Wed, 10 May 2023 22:11:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   serialization fixes, more code shaping
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 571:
> 
>> 569:                 preCandidate[21] = (byte) 0x80;
>> 570: 
>> 571:                 byte[] preZi = hashBuf.clone();
> 
> We can just call `hashbufSha256_32.clone()` here. We'll think about what to do when more params are supported in the future, together with the next line.

hashBuf is assigned at the initialisation of the LMOTSParams object. If (when) we introduce more algorithms, the initialisation code and the digestFixedLengthPreprocessed() code needs to be changed only (its first parameter should be such that it can use the hash algorithm that the object would be initialised to use).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190671593

From xuelei at openjdk.org  Thu May 11 06:16:55 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 11 May 2023 06:16:55 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
Message-ID: <NQ2FvSVuFYN9rDNmh5wO5ygxBVMi8Gwz7vI7W-civgw=.d508386b-5293-402b-87f0-ce04fb3c8cfc@github.com>

On Wed, 10 May 2023 15:20:50 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   serialization fixes, more code shaping

src/java.base/share/classes/sun/security/provider/HSS.java line 165:

> 163:     }
> 164: 
> 165:     static class LMSUtils {

It might be simpler and more efficient to use enum for lms and lmots types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190680173

From duke at openjdk.org  Thu May 11 06:30:55 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 11 May 2023 06:30:55 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <NQ2FvSVuFYN9rDNmh5wO5ygxBVMi8Gwz7vI7W-civgw=.d508386b-5293-402b-87f0-ce04fb3c8cfc@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
 <NQ2FvSVuFYN9rDNmh5wO5ygxBVMi8Gwz7vI7W-civgw=.d508386b-5293-402b-87f0-ce04fb3c8cfc@github.com>
Message-ID: <a4uUfN3Tpa8szUm9EHa2V2w5iAXV1Ix24nS-pnK2ydE=.3c0e395c-8516-4bca-b0eb-e9aeaa860857@github.com>

On Thu, 11 May 2023 06:14:10 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   serialization fixes, more code shaping
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 165:
> 
>> 163:     }
>> 164: 
>> 165:     static class LMSUtils {
> 
> It might be simpler and more efficient to use enum for lms and lmots types.

I had considered that and decided not to use it. In my opinion, Java Enum is much more complicated than it should be for this case. Efficiency is not a concern here, but I also don't see how enum could be more efficient.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190690480

From xuelei at openjdk.org  Thu May 11 06:38:55 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 11 May 2023 06:38:55 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <a4uUfN3Tpa8szUm9EHa2V2w5iAXV1Ix24nS-pnK2ydE=.3c0e395c-8516-4bca-b0eb-e9aeaa860857@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
 <NQ2FvSVuFYN9rDNmh5wO5ygxBVMi8Gwz7vI7W-civgw=.d508386b-5293-402b-87f0-ce04fb3c8cfc@github.com>
 <a4uUfN3Tpa8szUm9EHa2V2w5iAXV1Ix24nS-pnK2ydE=.3c0e395c-8516-4bca-b0eb-e9aeaa860857@github.com>
Message-ID: <g3SWj5I4hOUpIph12dD7aa1lCUfHGKfZgxPbQIcuifQ=.ac9b6927-bac4-4c25-8c7a-c198abe9f93c@github.com>

On Thu, 11 May 2023 06:27:39 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> I had considered that and decided not to use it. In my opinion, Java Enum is much more complicated than it should be for this case. 

OK.

> Efficiency is not a concern here

OK.

> but I also don't see how enum could be more efficient.

enum switch is O(1), while if-else not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190697557

From duke at openjdk.org  Thu May 11 09:22:58 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 11 May 2023 09:22:58 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <B0RvwMnttzZzgTMd-_FEiwLuD-KR7kcF5VyzC3xgz80=.aa0d20bc-9580-4965-bc99-0b1da82fdc28@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
 <XuFrhgEEQXxNHg2HfYzzeeapRcB6WfPq1tKaTnC6lUs=.3b4a29b8-7935-477b-8c84-d51efdad8291@github.com>
 <BI7Q_LYfBLLsS8ZwhUJDbooSHIcFzh6E6yj7nisDTyk=.07bb9916-e1c3-4fd7-89b5-4ca9988e1e1a@github.com>
 <B0RvwMnttzZzgTMd-_FEiwLuD-KR7kcF5VyzC3xgz80=.aa0d20bc-9580-4965-bc99-0b1da82fdc28@github.com>
Message-ID: <aCsNOoN-knb9ZF1XoIzPYMsXuJTOw0ZcS95X8XAlNzE=.34c2f610-ef18-4fbb-b11e-5a6cbd1aeaf0@github.com>

On Wed, 10 May 2023 22:17:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Done.
>
> There are much more in this class.

You are right. I have added many more. I hope I have found all of them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1190885719

From duke at openjdk.org  Thu May 11 09:36:17 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 11 May 2023 09:36:17 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  Reintroduced Length for HSSPublicKey, added more @Override annotations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/b363ce7f..b3ffdfd2

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

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

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

From weijun at openjdk.org  Thu May 11 12:38:59 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 May 2023 12:38:59 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v9]
In-Reply-To: <6NWVBkRp6Q7t4iUk45El2XbaLlfbqEFSVrfdDZgK1HI=.c8ebc0d1-2d4d-4f83-ad30-592ec99438f2@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uCY8SwPmeowUQDNKKMVxoo0Mz9lLzTH2h4ymU8c-uQU=.8e393a37-72b0-4fef-83d5-660d50e16473@github.com>
 <L_uiNSWGGvBbwmIo_2Rx6OFvZSpJOBV2Nak6wC3-35s=.5d5aca7a-9032-4e5d-9a4b-1d170810dd82@github.com>
 <6NWVBkRp6Q7t4iUk45El2XbaLlfbqEFSVrfdDZgK1HI=.c8ebc0d1-2d4d-4f83-ad30-592ec99438f2@github.com>
Message-ID: <H9BkuqKREZCTzpe55Bgb8lKi4MBMwIo0hSstfLHlPsE=.93052a72-d71d-4401-8888-8097fc14596f@github.com>

On Thu, 11 May 2023 06:02:01 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 571:
>> 
>>> 569:                 preCandidate[21] = (byte) 0x80;
>>> 570: 
>>> 571:                 byte[] preZi = hashBuf.clone();
>> 
>> We can just call `hashbufSha256_32.clone()` here. We'll think about what to do when more params are supported in the future, together with the next line.
>
> hashBuf is assigned at the initialisation of the LMOTSParams object. If (when) we introduce more algorithms, the initialisation code and the digestFixedLengthPreprocessed() code needs to be changed only (its first parameter should be such that it can use the hash algorithm that the object would be initialised to use).

That's OK. I see you already had `SHA2.SHA256 sha256 = new SHA2.SHA256()` as the next line and thought the selection of `hashBuf` and optimized hash impl will be local in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191113228

From weijun at openjdk.org  Thu May 11 14:03:08 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 May 2023 14:03:08 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
Message-ID: <hbR6qnrmosmkzgd57FWafvygvET0q_YAUe-Fp72U9Sc=.ef8be0b2-65e0-44e0-aec3-ea3e8f3149eb@github.com>

On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reintroduced Length for HSSPublicKey, added more @Override annotations

src/java.base/share/classes/sun/security/provider/HSS.java line 728:

> 726:         @Override
> 727:         public int length() {
> 728:             return getKey().length();

Debatable. `getKey` now contains 2 (OCTET STRING header) + 4 (L) + 4 (LMS type) + 4 (LM-OTS type) + 16 (I) + 32 (T) bytes. Should the 2 header bytes be included in the length? Should all fields other than T be included? The length is mainly used to compare strength and I suggest we refrain from implementing this method unless a well-known definition is accepted for HSS/LMS. Table 2 of [NIST SP 800-57 Part 1](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) and they are defined by modulus size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191214837

From weijun at openjdk.org  Thu May 11 15:15:01 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 May 2023 15:15:01 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
Message-ID: <vL_S1D0cxwLNSSaUrf4e_crGEGrt7WBO0UFLusZes0w=.bdf5d1eb-a032-4674-be28-a3954c3cef2a@github.com>

On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reintroduced Length for HSSPublicKey, added more @Override annotations

src/java.base/share/classes/sun/security/provider/HSS.java line 620:

> 618:             if (keySpec instanceof X509EncodedKeySpec x) {
> 619:                 try {
> 620:                     var val = new DerValue(new ByteArrayInputStream(x.getEncoded()));

Do not use `ByteArrayInputStream`, just use `new DerValue(x.getEncoded())`. Otherwise, the encoding might contain extra garbage bytes at the end and we still accept it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191332259

From weijun at openjdk.org  Thu May 11 15:22:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 May 2023 15:22:12 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
Message-ID: <2ehkcLfIY06iHC-3wjJDKMWlbuxGCtZMr1NmtIL4io0=.60b80bb2-fafe-4123-8ad6-942ecd17721c@github.com>

On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reintroduced Length for HSSPublicKey, added more @Override annotations

src/java.base/share/classes/sun/security/provider/HSS.java line 622:

> 620:                     var val = new DerValue(new ByteArrayInputStream(x.getEncoded()));
> 621:                     val.data.getDerValue();
> 622:                     return new HSSPublicKey(new DerValue(val.data.getBitString()).getOctetString());

The 2 lines above cannot detect wrong algorithm identifier and garbage data at the end. Now that you already have `parseBits` implementation, you should follow the usual `X509Key` convention to create a new `HSSPublicKey` constructor that takes in the whole encoding and call `decode` to decode it. See `ECKeyFactory` and `ECPublicKeyImpl.java` for an example.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191340263

From mullan at openjdk.org  Thu May 11 16:36:48 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 May 2023 16:36:48 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
Message-ID: <YmG-g4a57GPa-Zpg8BbgD26k0_W8i4YuJB9Ed5RSyEw=.45dd218d-224b-4671-8656-f16fed0693a6@github.com>

On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reintroduced Length for HSSPublicKey, added more @Override annotations

src/java.base/share/classes/sun/security/provider/HSS.java line 39:

> 37: /*
> 38:  * This class implements the Hierarchical Signature System using the
> 39:  * Leighton-Micali Signatures (LMS) as described in RFC 8554 and NIST Special publication 800-208

Nit: add period at end of sentence.

src/java.base/share/classes/sun/security/provider/HSS.java line 719:

> 717: 
> 718:         @java.io.Serial
> 719:         protected Object writeReplace() throws java.io.ObjectStreamException {

I think the serialized form of an HSSPublicKey should also be specified in the CSR since this Key is returned from a standard API. I think you can add a simple sentence such as:

"The Keys returned by an "HSS/LMS" `KeyFactory` are `Serializable` and use `java.security.KeyRep` as its serialized representation."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191420316
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191436386

From kdriver at openjdk.org  Thu May 11 16:40:07 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 11 May 2023 16:40:07 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v5]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <LtGJqKCGM4PyqnScik9ykgX_81n5G0AaD5iEjVF0EZY=.6dcaa24b-1ac4-48a4-9411-efeebfd34332@github.com>

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

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

 - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - updated copyright
 - fixes JDK-8294985: throw an SSLException wrapping the IAE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/33366412..87b47a03

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

  Stats: 99417 lines in 1498 files changed: 79732 ins; 8161 del; 11524 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

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

From mullan at openjdk.org  Thu May 11 17:11:15 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 May 2023 17:11:15 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
 <I38GCzgKGpk_M-PMSPKXIvgQC-7vFYm7ArZfcT27al8=.dbbfb1c9-af9d-42e2-a427-07c9d5c8ea05@github.com>
 <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com>
Message-ID: <NaeemUaTE6EKEacMHPIoxceo0iFPeQSblUf78VtRFJI=.d969ea83-0c5a-400a-b18d-a3af6f1fcf66@github.com>

On Tue, 9 May 2023 14:26:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/HSS.java line 661:
>> 
>>> 659: 
>>> 660:         @SuppressWarnings("deprecation")
>>> 661:         HSSPublicKey(byte[] keyArray) throws InvalidKeyException {
>> 
>> [I deleted my earlier comment]
>> 
>> I am wondering why you don't call `super()` or `decode()`  and override `parseKeyBits()` like other `X509Key` subclasses.
>> 
>> You should also override `writeReplace` so that serialization uses an alternate form when serializing.
>> 
>> It would probably be useful to override `toString()` as well. See other `X509Key` subclasses for more details.
>
> Yes, I also think with `writeReplace` you can make `L` and `lmsPublicKey` transient and there is no need to make `LMSPublicKey` serializable.

`L` should be `transient` too as @wangweij noted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191465361

From mullan at openjdk.org  Thu May 11 17:11:18 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 May 2023 17:11:18 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
Message-ID: <GoH_S0bnPkwifpxJGLzESanL4AGK4JOU95J5yMs3S5Y=.ddf74b7b-b829-47ef-ae1b-d63edb547563@github.com>

On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reintroduced Length for HSSPublicKey, added more @Override annotations

src/java.base/share/classes/sun/security/provider/HSS.java line 698:

> 696:         @Override
> 697:         public String toString() {
> 698:             HexDumpEncoder  encoder = new HexDumpEncoder();

Nit: one space after `HexDumpEncoder`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191466810

From mullan at openjdk.org  Thu May 11 17:20:29 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 May 2023 17:20:29 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v3]
In-Reply-To: <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
 <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com>
Message-ID: <b38AZyfaiK1o_UBmIhXfj95aW0mSHcykHI8ZneJ7mt0=.1c839900-43c8-4e2f-95e4-904739c5f6ee@github.com>

On Wed, 10 May 2023 23:07:01 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.
>> 
>> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.
>> 
>> CSR has been filed.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated reg test with review comments.

test/jdk/java/security/SecureRandom/NextBytesNull.java line 29:

> 27:  * @summary check NPE is thrown for various methods of SecureRandom class,
> 28:  *     e.g. SecureRandom(byte[]), nextBytes(byte[]), and setSeed(byte[]).
> 29:  * @run main/othervm NextBytesNull

Does this need to be run in othervm mode?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1191480288

From weijun at openjdk.org  Thu May 11 17:31:48 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 May 2023 17:31:48 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <YmG-g4a57GPa-Zpg8BbgD26k0_W8i4YuJB9Ed5RSyEw=.45dd218d-224b-4671-8656-f16fed0693a6@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
 <YmG-g4a57GPa-Zpg8BbgD26k0_W8i4YuJB9Ed5RSyEw=.45dd218d-224b-4671-8656-f16fed0693a6@github.com>
Message-ID: <Gvf1-Oc8T-kKvjH8pFp5w_4xx8qus77FSa9looNF85s=.b63200b2-9dc8-4d4d-a8b4-93c7b7b5c127@github.com>

On Thu, 11 May 2023 16:33:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reintroduced Length for HSSPublicKey, added more @Override annotations
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 719:
> 
>> 717: 
>> 718:         @java.io.Serial
>> 719:         protected Object writeReplace() throws java.io.ObjectStreamException {
> 
> I think the serialized form of an HSSPublicKey should also be specified in the CSR since this Key is returned from a standard API. I think you can add a simple sentence such as:
> 
> "The Keys returned by an "HSS/LMS" `KeyFactory` are `Serializable` and use `java.security.KeyRep` as its serialized representation with the fields set as follows: type = `KeyRep.Type.PUBLIC`, algorithm = "HSS/LMS", format = "X.509", and encoded = the DER encoded bytes ..."

I added a paragraph to the CSR, although it's already approved several days ago.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191492222

From mullan at openjdk.org  Thu May 11 17:51:36 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 May 2023 17:51:36 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v5]
In-Reply-To: <LtGJqKCGM4PyqnScik9ykgX_81n5G0AaD5iEjVF0EZY=.6dcaa24b-1ac4-48a4-9411-efeebfd34332@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <LtGJqKCGM4PyqnScik9ykgX_81n5G0AaD5iEjVF0EZY=.6dcaa24b-1ac4-48a4-9411-efeebfd34332@github.com>
Message-ID: <ExD_x40mNvwRQ9Ol01kRN1b1gb0lLHGPjRnsHLOUvts=.52f581b6-f190-4c00-8ca6-c83ca5e362bc@github.com>

On Thu, 11 May 2023 16:40:07 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - updated copyright
>  - fixes JDK-8294985: throw an SSLException wrapping the IAE

Not sure if you have more changes coming, but there are still a few other places where IAE could be thrown. I would change `getAuthorities()` (in both CertificateRequest.java and CertificateAuthoritiesExtension.java) to catch `IllegalArgumentException` and rethrow it as an `SSLException`, as this will ensure all existing and future calls to this method are handled consistently.

Also, I would change the `toString()` method to also catch IAE but not propagate it, instead print something like "unparseable X500Principal".

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

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1423140554

From valeriep at openjdk.org  Thu May 11 19:30:34 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 11 May 2023 19:30:34 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v3]
In-Reply-To: <b38AZyfaiK1o_UBmIhXfj95aW0mSHcykHI8ZneJ7mt0=.1c839900-43c8-4e2f-95e4-904739c5f6ee@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
 <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com>
 <b38AZyfaiK1o_UBmIhXfj95aW0mSHcykHI8ZneJ7mt0=.1c839900-43c8-4e2f-95e4-904739c5f6ee@github.com>
Message-ID: <ZTNKagz9acMg3cWjZ-FlWN5lFOWhPOd526mFFF7a57w=.b550f33a-2b2a-47f3-ae51-a1d66fd9bb69@github.com>

On Thu, 11 May 2023 17:16:19 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated reg test with review comments.
>
> test/jdk/java/security/SecureRandom/NextBytesNull.java line 29:
> 
>> 27:  * @summary check NPE is thrown for various methods of SecureRandom class,
>> 28:  *     e.g. SecureRandom(byte[]), nextBytes(byte[]), and setSeed(byte[]).
>> 29:  * @run main/othervm NextBytesNull
> 
> Does this need to be run in othervm mode?

Probably not. Will remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1191603458

From mullan at openjdk.org  Thu May 11 19:35:39 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 11 May 2023 19:35:39 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v3]
In-Reply-To: <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
 <0FxNPXIDHRdcGI9TmXrAVQ8aMP2xtcxBvUKtM9wOdR4=.c337ed61-cc53-4da5-88ff-a82bdcb0cd68@github.com>
Message-ID: <sIdAB-kfdHK57ZZNFPE9wTif9gaAllcWV827gA65uEc=.8d429708-2d16-4901-bbd0-60bb429214b0@github.com>

On Wed, 10 May 2023 23:07:01 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.
>> 
>> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.
>> 
>> CSR has been filed.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated reg test with review comments.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13788#pullrequestreview-1423299217

From weijun at openjdk.org  Thu May 11 19:35:54 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 May 2023 19:35:54 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
Message-ID: <EKZZQek5jK9NXQcSQ4AoGEXbWP281hWzuTRg8P2zCIg=.bc1ebeb6-80c8-4314-b2b7-270b6248c026@github.com>

On Thu, 11 May 2023 09:36:17 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reintroduced Length for HSSPublicKey, added more @Override annotations

src/java.base/share/classes/sun/security/provider/HSS.java line 436:

> 434:             int sigArrLen = (12 + n * (p + 1) + m * h);
> 435:             if ((q >= (1 << h)) || (inLen < sigArrLen) || (checkExactLen && (inLen != sigArrLen))) {
> 436:                 throw new InvalidParameterException("LMS signature length is incorrect");

Should be a `SignatureException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1191608083

From jlu at openjdk.org  Thu May 11 20:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:21:57 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Convert the merged master changes to UTF-8
 - Merge master and fix conflicts
 - Close streams when finished loading into props
 - Adjust CF test to read in with UTF-8 to fix failing test
 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties
 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

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

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05
  Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726

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

From kdriver at openjdk.org  Thu May 11 20:43:49 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 11 May 2023 20:43:49 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v6]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>

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

Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:

 - update copyright
 - reworking the fix in light of encouragement to change the problematic method signature

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/87b47a03..0017c094

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

  Stats: 54 lines in 2 files changed: 31 ins; 5 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

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

From weijun at openjdk.org  Thu May 11 20:56:54 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 11 May 2023 20:56:54 GMT
Subject: RFR: 8297878: KEM: Implementation [v15]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <lpPWUxJJLhlJo40d9UBbZ2jVsFaXXCoYo6VgBcHP0iU=.419f0b74-d671-4d7d-91a7-4e68537d715e@github.com>

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

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

  deterministic randomness

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/c9f1d8f3..128cefe7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=13-14

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

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

From valeriep at openjdk.org  Thu May 11 21:06:37 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 11 May 2023 21:06:37 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v4]
In-Reply-To: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
Message-ID: <VtJY70UK_Zv-t5Pepb5PamCibL_vwBaKMs1jGdblW2o=.cb853ddd-5305-43ba-a291-84b0a8272880@github.com>

> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.
> 
> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.
> 
> CSR has been filed.
> 
> Thanks,
> Valerie

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

  minor test update, remove pkcs11 reg test as it's covered by the other
  test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13788/files
  - new: https://git.openjdk.org/jdk/pull/13788/files/3ee76896..a2564259

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

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

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

From jlu at openjdk.org  Thu May 11 21:39:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:39:50 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <w-aBr-h4WVCyWPDEHHatqoQcdQJp6dN4eld2Y-85Ak4=.558819ae-881a-42fb-8b67-7a6b5618e323@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. 

Although the default file-encoding for .properties can be switched to UTF-8, it is not the default.

Wondering what some solutions/thoughts to this are.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830

From naoto at openjdk.org  Thu May 11 21:51:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 21:51:13 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480

From clanger at openjdk.org  Thu May 11 21:51:58 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 11 May 2023 21:51:58 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates
Message-ID: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>

With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.

The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.

This change does the following:
1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.

I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.

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

Commit messages:
 - JDK-8303465

Changes: https://git.openjdk.org/jdk/pull/13945/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13945&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303465
  Stats: 272 lines in 3 files changed: 204 ins; 31 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/13945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13945/head:pull/13945

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

From valeriep at openjdk.org  Fri May 12 02:23:17 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 12 May 2023 02:23:17 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries [v2]
In-Reply-To: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
Message-ID: <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>

> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
> 
> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
> 
> Thanks,
> Valerie

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

  Changed to use keytool to generate keypairs instead of importing from
  data files.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13743/files
  - new: https://git.openjdk.org/jdk/pull/13743/files/f194733c..4c72e3a6

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

  Stats: 277 lines in 7 files changed: 82 ins; 137 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/13743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13743/head:pull/13743

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

From ssahoo at openjdk.org  Fri May 12 10:29:58 2023
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Fri, 12 May 2023 10:29:58 GMT
Subject: RFR: 8297878: KEM: Implementation [v15]
In-Reply-To: <lpPWUxJJLhlJo40d9UBbZ2jVsFaXXCoYo6VgBcHP0iU=.419f0b74-d671-4d7d-91a7-4e68537d715e@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <lpPWUxJJLhlJo40d9UBbZ2jVsFaXXCoYo6VgBcHP0iU=.419f0b74-d671-4d7d-91a7-4e68537d715e@github.com>
Message-ID: <xq23k5HWAZZVvb0AJilp6uXAFUr78JSchzYw085K8vg=.5b453dda-b3da-4745-9c10-d62ddd41829f@github.com>

On Thu, 11 May 2023 20:56:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   deterministic randomness

test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 205:

> 203:         byte[] enc1 = e.encapsulate().encapsulation();
> 204:         byte[] enc2 = e.encapsulate().encapsulation();
> 205:         Asserts.assertFalse(Arrays.equals(enc1, enc2));

Another case,
KEM kem = KEM.getInstance("DHKEM");
   KEM.Encapsulator e1 = kem.newEncapsulator(pk, random);
KEM kem1 = KEM.getInstance("DHKEM");
   KEM.Encapsulator e2 = kem1.newEncapsulator(pk, random);
byte[] enc1 = e1.encapsulate().encapsulation();
byte[] enc2 = e2.encapsulate().encapsulation();
Asserts.assertFalse(Arrays.equals(enc1, enc2));

Can this case be added too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1192194605

From duke at openjdk.org  Fri May 12 12:43:01 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 12 May 2023 12:43:01 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <YmG-g4a57GPa-Zpg8BbgD26k0_W8i4YuJB9Ed5RSyEw=.45dd218d-224b-4671-8656-f16fed0693a6@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
 <YmG-g4a57GPa-Zpg8BbgD26k0_W8i4YuJB9Ed5RSyEw=.45dd218d-224b-4671-8656-f16fed0693a6@github.com>
Message-ID: <iSg02SRxYc8wNMMVMIKZHlIMBS_t7xc_z720rQqq5TE=.da34984c-4ed4-4f3b-9758-0c6e70f62b74@github.com>

On Thu, 11 May 2023 16:19:01 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reintroduced Length for HSSPublicKey, added more @Override annotations
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 39:
> 
>> 37: /*
>> 38:  * This class implements the Hierarchical Signature System using the
>> 39:  * Leighton-Micali Signatures (LMS) as described in RFC 8554 and NIST Special publication 800-208
> 
> Nit: add period at end of sentence.

Added period.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192312218

From duke at openjdk.org  Fri May 12 12:43:02 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 12 May 2023 12:43:02 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v8]
In-Reply-To: <NaeemUaTE6EKEacMHPIoxceo0iFPeQSblUf78VtRFJI=.d969ea83-0c5a-400a-b18d-a3af6f1fcf66@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <O2tbK4CgdfYJUsVof4Ri4ZVYHNda-fTce4Vy6KC1wvI=.c5f8635e-c860-4291-85fe-01f0cd2dedfd@github.com>
 <I38GCzgKGpk_M-PMSPKXIvgQC-7vFYm7ArZfcT27al8=.dbbfb1c9-af9d-42e2-a427-07c9d5c8ea05@github.com>
 <_jYDHUCUxw4GDD2Hi-ZjF6thUq4oMCYFyZ9Iqd24_n8=.c06f50e0-5571-480c-bc92-a81950fa0201@github.com>
 <NaeemUaTE6EKEacMHPIoxceo0iFPeQSblUf78VtRFJI=.d969ea83-0c5a-400a-b18d-a3af6f1fcf66@github.com>
Message-ID: <5-iCin1c7rUpxYSrQdafZo3sUXBiRE94Xl0ynZYH3z4=.2ddc7397-7d5c-472b-9c74-50746b2388b0@github.com>

On Thu, 11 May 2023 17:01:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Yes, I also think with `writeReplace` you can make `L` and `lmsPublicKey` transient and there is no need to make `LMSPublicKey` serializable.
>
> `L` should be `transient` too as @wangweij noted.

Made L transient

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192308943

From mullan at openjdk.org  Fri May 12 13:42:47 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 12 May 2023 13:42:47 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v4]
In-Reply-To: <VtJY70UK_Zv-t5Pepb5PamCibL_vwBaKMs1jGdblW2o=.cb853ddd-5305-43ba-a291-84b0a8272880@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
 <VtJY70UK_Zv-t5Pepb5PamCibL_vwBaKMs1jGdblW2o=.cb853ddd-5305-43ba-a291-84b0a8272880@github.com>
Message-ID: <JkqM9zwzZoj4UNL0jLf9uC3Jz-z4J9odYYtg8LzI5lM=.9a5e1103-835f-4d1e-a14b-2542ae6e5ec2@github.com>

On Thu, 11 May 2023 21:06:37 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.
>> 
>> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.
>> 
>> CSR has been filed.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor test update, remove pkcs11 reg test as it's covered by the other
>   test

test/jdk/java/security/SecureRandom/NextBytesNull.java line 29:

> 27:  * @summary check NPE is thrown for various methods of SecureRandom class,
> 28:  *     e.g. SecureRandom(byte[]), nextBytes(byte[]), and setSeed(byte[]).
> 29:  * @run main NextBytesNull

You don't need an `@run` line now as this is the default if no `@run` line is specified. See https://openjdk.org/jtreg/tag-spec.html#DEFAULTS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1192393216

From duke at openjdk.org  Fri May 12 14:20:01 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 12 May 2023 14:20:01 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v10]
In-Reply-To: <EKZZQek5jK9NXQcSQ4AoGEXbWP281hWzuTRg8P2zCIg=.bc1ebeb6-80c8-4314-b2b7-270b6248c026@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <L0gNAfoRJiNvXq4l5c8BNgqQM-QY7dAQ8WQ76W0Vr5s=.dccf4e82-5102-41d2-a020-2b9d1aeeaf64@github.com>
 <EKZZQek5jK9NXQcSQ4AoGEXbWP281hWzuTRg8P2zCIg=.bc1ebeb6-80c8-4314-b2b7-270b6248c026@github.com>
Message-ID: <Dy0xu8delLE54ER7IAeIsI5xxJiu2xAImoDkG7nKXkE=.3875c2fa-14c8-43da-8f15-67e13de37123@github.com>

On Thu, 11 May 2023 19:32:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reintroduced Length for HSSPublicKey, added more @Override annotations
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 436:
> 
>> 434:             int sigArrLen = (12 + n * (p + 1) + m * h);
>> 435:             if ((q >= (1 << h)) || (inLen < sigArrLen) || (checkExactLen && (inLen != sigArrLen))) {
>> 436:                 throw new InvalidParameterException("LMS signature length is incorrect");
> 
> Should be a `SignatureException`.

Changed.

> src/java.base/share/classes/sun/security/provider/HSS.java line 622:
> 
>> 620:                     var val = new DerValue(new ByteArrayInputStream(x.getEncoded()));
>> 621:                     val.data.getDerValue();
>> 622:                     return new HSSPublicKey(new DerValue(val.data.getBitString()).getOctetString());
> 
> The 2 lines above cannot detect wrong algorithm identifier and garbage data at the end. Now that you already have `parseBits` implementation, you should follow the usual `X509Key` convention to create a new `HSSPublicKey` constructor that takes in the whole encoding and call `decode` to decode it. See `ECKeyFactory` and `ECPublicKeyImpl.java` for an example.

Changed as suggested.

> src/java.base/share/classes/sun/security/provider/HSS.java line 728:
> 
>> 726:         @Override
>> 727:         public int length() {
>> 728:             return getKey().length();
> 
> Debatable. `getKey` now contains 2 (OCTET STRING header) + 4 (L) + 4 (LMS type) + 4 (LM-OTS type) + 16 (I) + 32 (T) bytes. Should the 2 header bytes be included in the length? Should all fields other than T be included? The length is mainly used to compare strength and I suggest we refrain from implementing this method until a well-known definition is accepted for HSS/LMS. Table 2 of [NIST SP 800-57 Part 1](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) and they are defined by modulus size. In this sense, the size of the hash is more suitable to be defined as the size of the key.

Removed length, I agree that it doesn't make much sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192438720
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192437225
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192438203

From duke at openjdk.org  Fri May 12 14:27:18 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 12 May 2023 14:27:18 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v11]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <dMtOSIVz5KVImiQlKtvohDyPZWhDKmBuyaLnF1fACPA=.781607aa-edd9-4992-b3b0-54f94b14488b@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  Removed Length from HSSPublicKey, changed the handling of X509 encoded keys in the factory, did some more beautification.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/b3ffdfd2..1830eee7

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

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

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

From mbaesken at openjdk.org  Fri May 12 14:30:02 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 12 May 2023 14:30:02 GMT
Subject: Withdrawn: JDK-8303465: KeyStore of type KeychainStore,
 provider Apple shows different behavior after 8278449
In-Reply-To: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
References: <gqNG3LhxhfUDFES0BqQJXtMmXJbRq-Zs_v14h_drov0=.6a936333-cfa6-405b-be07-9328c76214f7@github.com>
Message-ID: <zLTXmygtKy1eRYSYDpRj6IzjOhUQ5wuNucy3G7pjfF0=.022bc57e-4f69-4c2c-a98a-d76ad6c4c332@github.com>

On Thu, 2 Mar 2023 13:33:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After 8278449, we seem to ignore in the call
> 
> `  if (SecTrustSettingsCopyTrustSettings(certRef, kSecTrustSettingsDomainUser, &trustSettings) == errSecItemNotFound) `
> 
> all trusted certs from admin and system domains, so a lot more certs are ignored than necessary.
> Probably we should take at least the certs with trust settings from kSecTrustSettingsDomainUser, kSecTrustSettingsDomainAdmin and kSecTrustSettingsDomainSystem domains .

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Fri May 12 16:24:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 May 2023 16:24:49 GMT
Subject: RFR: 8308016: Use snippets in java.io package
Message-ID: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>

Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...>`.

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

Commit messages:
 - 8308016: Use snippets in java.io package

Changes: https://git.openjdk.org/jdk/pull/13957/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308016
  Stats: 178 lines in 21 files changed: 27 ins; 7 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

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

From weijun at openjdk.org  Fri May 12 16:29:52 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 12 May 2023 16:29:52 GMT
Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end
Message-ID: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>

When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end.

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/13958/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13958&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308010
  Stats: 80 lines in 3 files changed: 62 ins; 9 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13958/head:pull/13958

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

From jlu at openjdk.org  Fri May 12 17:34:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 17:34:47 GMT
Subject: RFR: 8308016: Use snippets in java.io package
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>

On Fri, 12 May 2023 16:17:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

src/java.base/share/classes/java/io/Console.java line 124:

> 122:      *         if (con != null) {
> 123:      *             Scanner sc = new Scanner(con.reader());
> 124:      *             ...

I'm not sure how you feel about this, but when I have been converting `<pre>` blocks to `@snippet`, I usually try to get rid of non code. Since snippet allows user's to copy the example code, I feel like it's redudant to leave in non code, since they will likely delete it anyways.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192635740

From hchao at openjdk.org  Fri May 12 17:53:47 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 12 May 2023 17:53:47 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries [v2]
In-Reply-To: <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>
Message-ID: <llDJBFqu7ZoQGUiOqxVUW619DC5bso6THFWGTogWB3M=.b6406c3c-4b63-4cb9-b76f-e09a61effb0a@github.com>

On Fri, 12 May 2023 02:23:17 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
>> 
>> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed to use keytool to generate keypairs instead of importing from
>   data files.

Marked as reviewed by hchao (Committer).

Changes look good to me. Nice to add the cert chain (i.e. root/ca1/pk1) to the test case. The raw file `temp.ks` is shown in the webrev (to be created by the test), so will not be part of the integration, right?

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

PR Review: https://git.openjdk.org/jdk/pull/13743#pullrequestreview-1424933567
PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1546085439

From bpb at openjdk.org  Fri May 12 17:55:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 May 2023 17:55:44 GMT
Subject: RFR: 8308016: Use snippets in java.io package
In-Reply-To: <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>
Message-ID: <iOi1uN2Paot06qwac9kgaOPDuJxnxO2Lx7HHkqk4UKg=.22146c6c-9471-4806-a109-d0c17a9f9bf7@github.com>

On Fri, 12 May 2023 17:31:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> src/java.base/share/classes/java/io/Console.java line 124:
> 
>> 122:      *         if (con != null) {
>> 123:      *             Scanner sc = new Scanner(con.reader());
>> 124:      *             ...
> 
> I'm not sure how you feel about this, but when I have been converting `<pre>` blocks to `@snippet`, I usually try to get rid of non code. Since snippet allows user's to copy the example code, I feel like it's redudant to leave in non code, since they will likely delete it anyways.

I have been just trying to keep it as similar visually as possible but what you say is reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192652789

From lancea at openjdk.org  Fri May 12 18:02:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 12 May 2023 18:02:48 GMT
Subject: RFR: 8308016: Use snippets in java.io package
In-Reply-To: <iOi1uN2Paot06qwac9kgaOPDuJxnxO2Lx7HHkqk4UKg=.22146c6c-9471-4806-a109-d0c17a9f9bf7@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>
 <iOi1uN2Paot06qwac9kgaOPDuJxnxO2Lx7HHkqk4UKg=.22146c6c-9471-4806-a109-d0c17a9f9bf7@github.com>
Message-ID: <6nU_GjadVokt6GDAMNBo1-RUglHvk5eqkdeZwHu2EsY=.5ed4c3b5-a44b-49b9-90e9-c77afb8ffa94@github.com>

On Fri, 12 May 2023 17:52:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 124:
>> 
>>> 122:      *         if (con != null) {
>>> 123:      *             Scanner sc = new Scanner(con.reader());
>>> 124:      *             ...
>> 
>> I'm not sure how you feel about this, but when I have been converting `<pre>` blocks to `@snippet`, I usually try to get rid of non code. Since snippet allows user's to copy the example code, I feel like it's redudant to leave in non code, since they will likely delete it anyways.
>
> I have been just trying to keep it as similar visually as possible but what you say is reasonable.

Agree, that I would make the code valid when using a snippet

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192658575

From bpb at openjdk.org  Fri May 12 19:02:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 May 2023 19:02:46 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Remove ellipses ("...") from snippets

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/8a555a76..bc5c0358

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

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

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

From valeriep at openjdk.org  Fri May 12 19:23:45 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 12 May 2023 19:23:45 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries [v2]
In-Reply-To: <llDJBFqu7ZoQGUiOqxVUW619DC5bso6THFWGTogWB3M=.b6406c3c-4b63-4cb9-b76f-e09a61effb0a@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>
 <llDJBFqu7ZoQGUiOqxVUW619DC5bso6THFWGTogWB3M=.b6406c3c-4b63-4cb9-b76f-e09a61effb0a@github.com>
Message-ID: <3z1OA2qWuiwGjP9YQbwVnqOXIEnmQVz5lF-sarQMw0E=.879ad473-4780-4116-aa28-1f48a085b8c6@github.com>

On Fri, 12 May 2023 17:50:22 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Changes look good to me. Nice to add the cert chain (i.e. root/ca1/pk1) to the test case. The raw file `temp.ks` is shown in the webrev (to be created by the test), so will not be part of the integration, right?

temp,ks will be part of integration to save time on key pair generation. If for any reason that it needs to be re-generated, just remove the file and test will generate one on the fly.

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

PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1546176018

From valeriep at openjdk.org  Fri May 12 19:27:55 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 12 May 2023 19:27:55 GMT
Subject: RFR: 8168469: Memory leak in JceSecurity [v2]
In-Reply-To: <IahdnuFEbYv21QTfI9BXLSmfrhLthDWKHtQrC63L3jY=.717c8920-193a-48ee-884c-3684f887c9bd@github.com>
References: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
 <IahdnuFEbYv21QTfI9BXLSmfrhLthDWKHtQrC63L3jY=.717c8920-193a-48ee-884c-3684f887c9bd@github.com>
Message-ID: <4-_rgIDUj2_c-8NgkBtWUd4vybIfpBeBXvcn-43Zxts=.44c6f860-038e-4895-97e2-d3db8619df9d@github.com>

On Wed, 10 May 2023 10:03:46 GMT, Sergey Chernyshev <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME.
>> 
>> The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap<Class<? extends Provider>, Object>` instead of `IdentityHashMap<Provider, Object>`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper<Provider> `objects that maintained the object identity while improved performance.
>> 
>> The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference<Object>` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called.
>> 
>> `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers.
>> 
>> I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test.
>> 
>> Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressio...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review comment

Marked as reviewed by valeriep (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13658#pullrequestreview-1425046189

From duke at openjdk.org  Fri May 12 19:27:57 2023
From: duke at openjdk.org (Sergey Chernyshev)
Date: Fri, 12 May 2023 19:27:57 GMT
Subject: Integrated: 8168469: Memory leak in JceSecurity
In-Reply-To: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
References: <VZbM3fto0rwy2Am93NnkdPf9FjQSj5vZZmg0PhhvIuA=.a7b5da4d-e542-435c-80ed-86ab0f778a02@github.com>
Message-ID: <guztJFK1GzXPBZQu2sHCpx0JfWI8xh4pADu7EEjyqM8=.9aabf820-d566-4d84-9637-7cce9ae12b47@github.com>

On Tue, 25 Apr 2023 21:16:41 GMT, Sergey Chernyshev <duke at openjdk.org> wrote:

> Hi all,
> 
> I would like to propose a patch for an issue discussed in [1][2] that fixes an OOME in the current code base. The issue appears when a SunJCE provider object reference is stored in a non-static variable, which eventually leads to a Java heap OOME.
> 
> The solution proposed earlier [1] raised a concern that the identity of provider objects may be somehow broken when using `WeakHashMap<Class<? extends Provider>, Object>` instead of `IdentityHashMap<Provider, Object>`. The solution hasn't been integrated that time. Later in 2019 a performance improvement was introduced with [3][4] that changed `IdentityHashMap` to `ConcurrentHashMap` of `IdentityWrapper<Provider> `objects that maintained the object identity while improved performance.
> 
> The solution being proposed keeps up with performance improvement in [3], further narrowing the synchronization down to the hash table node, avoids lambdas that may cause startup time regressions and maintains providers identity using `WeakIdentityWrapper` that extends `WeakReference<Object>` while avoiding depletion of Java heap by using weak pointers as the mapping key. Once a provider object becomes weakly reachable it is queued along with its reference object to the `ReferenceQueue` (a new static member in `JceSecurity`). The `equals()` method of the `WeakIdentityWrapper` will never match a new wrapper object to anything inside the hash table after the corresponding element's `WeakReference.get()` returned null. This leads to accumulating "empty" elements in the hash table. The new static function `expungeStaleWrappers()` drops the "empty" elements queued by GC each time the `getVerificationResult()` method is called.
> 
> `ConcurrentHashMap`'s `computeIfAbsent()` does (partially) detect recursive updates for keys that are being added to empty bins. For such keys an `IllegalStateException` is thrown prior to recursive execution of the `mappingFunction`. For nodes that are added to existing TreeBins or linked lists, in which case no recursion detection is done prior to calling `mappingFunction`, the recursion detection relies on old method with `IdentityMap` of Providers.
> 
> I include a test that runs under memory constrained conditions (128M) that hits the heap limit in current VMs where it is impossible to reclaim providers' memory (unless they've been cached under weak references). The updated jdk versions pass the test.
> 
> Testing: jtreg + JCK on a downport of the patch to JDK 17 with no regressions
> 
> [1] http...

This pull request has now been integrated.

Changeset: a284920b
Author:    Sergey Chernyshev <serge.chernyshev at bell-sw.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a284920b3432b00496a2a32a284a91a9bd49fb06
Stats:     111 lines in 2 files changed: 84 ins; 8 del; 19 mod

8168469: Memory leak in JceSecurity

Reviewed-by: valeriep

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

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

From mullan at openjdk.org  Fri May 12 20:17:46 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 12 May 2023 20:17:46 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v6]
In-Reply-To: <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>
Message-ID: <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>

On Thu, 11 May 2023 20:43:49 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update copyright
>  - reworking the fix in light of encouragement to change the problematic method signature

Do you have any plans to write a test? If not, the bug needs a `noreg` label.

src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 136:

> 134:             } catch (IllegalArgumentException iae) {
> 135:                 throw new SSLException("X500Principal could not be parsed " +
> 136:                         "successfully", iae);

Is it ok to throw a general `SSLException` here? Or do you need to call `TransportContext.fatal()` so that additional cleanup happens? Perhaps @XueleiFan would know.

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

PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1546242429
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1192759621

From kdriver at openjdk.org  Fri May 12 20:32:50 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 12 May 2023 20:32:50 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v6]
In-Reply-To: <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>
 <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>
Message-ID: <jeCXT2QNr-PwP9LaDAzc8Cq-y2JQxLJYXWk4AlOY6SI=.54f7080a-80d5-42b2-a285-63f8b7171a93@github.com>

On Fri, 12 May 2023 20:14:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Do you have any plans to write a test? If not, the bug needs a `noreg` label.

As discussed internally, the test that surfaced this issue will be incorporated into regular testing.

> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 136:
> 
>> 134:             } catch (IllegalArgumentException iae) {
>> 135:                 throw new SSLException("X500Principal could not be parsed " +
>> 136:                         "successfully", iae);
> 
> Is it ok to throw a general `SSLException` here? Or do you need to call `TransportContext.fatal()` so that additional cleanup happens? Perhaps @XueleiFan would know.

Yes, let's wait for @XueleiFan

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

PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1546257007
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1192769497

From cslucas at openjdk.org  Fri May 12 21:09:01 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 12 May 2023 21:09:01 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v13]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <Yx1OcjTUO1iQV7ibbT71njBcVZz7-bJsYBRN6Iom94I=.e6657a24-5a0e-4e15-9229-8ef2b49a7fef@github.com>

> Can I please get reviews for this PR? 
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
> 
> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges.
> 
> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Address PR review 5: refactor on rematerialization & add tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12897/files
  - new: https://git.openjdk.org/jdk/pull/12897/files/542c5ef1..68694126

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

  Stats: 225 lines in 10 files changed: 98 ins; 97 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897

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

From cslucas at openjdk.org  Fri May 12 21:09:04 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 12 May 2023 21:09:04 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v12]
In-Reply-To: <JnQgYSu4RMufdETsreXNI7oaFUpdqpwhBMbH9ZA5EbM=.cd5ef1fe-4660-40d4-851d-f26eeab99960@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <KfB40TIZR-_ho1ek-ijTFD556aHZZEd803k6eV7XReY=.84cc7dcf-18d7-4842-972b-8b6cb75183e3@github.com>
 <JnQgYSu4RMufdETsreXNI7oaFUpdqpwhBMbH9ZA5EbM=.cd5ef1fe-4660-40d4-851d-f26eeab99960@github.com>
Message-ID: <8pyn8ASJ6-PLoNIfI9FGvA6rfZXpc3Ud4hDWpesNlxg=.de6be879-e4cf-45a2-beca-00d7f3cd7429@github.com>

On Tue, 9 May 2023 00:03:26 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>>  - Address part of PR review 4 & fix a bug setting only_candidate
>>  - Catching up with master
>>    
>>    Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
>>  - Fix tests. Remember previous reducible Phis.
>>  - Address PR review 3. Some comments and be able to abort compilation.
>>  - Merge with Master
>>  - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.
>>  - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges.
>>  - Add support for SR'ing some inputs of merges used for field loads
>>  - Fix some typos and do some small refactorings.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/561ec9c5...542c5ef1
>
> The new pass over deserialized debug info would adapt `ScopeDesc::objects()` (initialized by `decode_object_values(obj_decode_offset)` and accesses through `chunk->at(0)->scope()->objects()`) and produce 2 lists:
>   * new list of objects which enumerates all scalarized instances which needs to be rematerialized;
>   * complete set of objects referenced in the current scope (the purpose `chunk->at(0)->scope()->objects()` serves now).
> 
> It should be performed before `rematerialize_objects`.
> 
> By preprocessing I mean all the conditional checks before it is attempted to reallocate an `ObjectValue`. By the end of the new pass, it should be enough to just iterate over the new list of scalarized instances in `Deoptimization::realloc_objects`. And after `Deoptimization::realloc_objects` and `Deoptimization::reassign_fields` are over, debug info should be ready to go.

@iwanowww - I pushed some changes to address your feedback about the rematerialization part. I added only two more tests for now, but I'm working on adding others.

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1546298856

From valeriep at openjdk.org  Fri May 12 23:02:58 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 12 May 2023 23:02:58 GMT
Subject: RFR: 8155191: Specify that SecureRandom.nextBytes(byte[]) throws
 NullPointerException when byte array is null [v4]
In-Reply-To: <JkqM9zwzZoj4UNL0jLf9uC3Jz-z4J9odYYtg8LzI5lM=.9a5e1103-835f-4d1e-a14b-2542ae6e5ec2@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
 <VtJY70UK_Zv-t5Pepb5PamCibL_vwBaKMs1jGdblW2o=.cb853ddd-5305-43ba-a291-84b0a8272880@github.com>
 <JkqM9zwzZoj4UNL0jLf9uC3Jz-z4J9odYYtg8LzI5lM=.9a5e1103-835f-4d1e-a14b-2542ae6e5ec2@github.com>
Message-ID: <uxy76sU8hYoI4BtOTt99XQdfX5jhbgEExtKR86Z7b1A=.31062cc0-0908-4db9-9eae-877bdbdbbac9@github.com>

On Fri, 12 May 2023 13:39: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:
>> 
>>   minor test update, remove pkcs11 reg test as it's covered by the other
>>   test
>
> test/jdk/java/security/SecureRandom/NextBytesNull.java line 29:
> 
>> 27:  * @summary check NPE is thrown for various methods of SecureRandom class,
>> 28:  *     e.g. SecureRandom(byte[]), nextBytes(byte[]), and setSeed(byte[]).
>> 29:  * @run main NextBytesNull
> 
> You don't need an `@run` line now as this is the default if no `@run` line is specified. See https://openjdk.org/jtreg/tag-spec.html#DEFAULTS.

Sorry, didn't see this until I integrated it...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13788#discussion_r1192853571

From valeriep at openjdk.org  Fri May 12 23:03:00 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Fri, 12 May 2023 23:03:00 GMT
Subject: Integrated: 8155191: Specify that SecureRandom.nextBytes(byte[])
 throws NullPointerException when byte array is null
In-Reply-To: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
References: <Hy1ZDrEV-yTcx5aIJ-6zgQ1S13a9feytisyA5fE2avg=.4486944e-fd16-46cd-8763-f5f9eb523527@github.com>
Message-ID: <EWJAacfF_7wMsOggl_mwahBmP56Tse6GmQxYZkZJKVM=.2e02df7d-1963-4e0c-ac94-d16c5b8393e8@github.com>

On Thu, 4 May 2023 01:58:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Just a trivial change for enforcing consistent NullPointerException behavior for the SecureRandom.nextBytes(byte[]) method.
> 
> Other similar methods such as Random.nextByte(byte[]) and its other subclasses all throw NPE for null byte[] argument. Most JDK default providers' SecureRandom impls also check and throw NPE. Thus, this should be moved up and enforced by the SecureRandom class to ensure consistency.
> 
> CSR has been filed.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: 46e3d24a
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46e3d24a6ff7d52d11f441d92628669d86d8bfaf
Stats:     104 lines in 4 files changed: 90 ins; 7 del; 7 mod

8155191: Specify that SecureRandom.nextBytes(byte[]) throws NullPointerException when byte array is null

Reviewed-by: mullan

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

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

From weijun at openjdk.org  Fri May 12 23:16:09 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 12 May 2023 23:16:09 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v11]
In-Reply-To: <dMtOSIVz5KVImiQlKtvohDyPZWhDKmBuyaLnF1fACPA=.781607aa-edd9-4992-b3b0-54f94b14488b@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <dMtOSIVz5KVImiQlKtvohDyPZWhDKmBuyaLnF1fACPA=.781607aa-edd9-4992-b3b0-54f94b14488b@github.com>
Message-ID: <cyM7A8H-EFI_MvuO3-wEtp7JXikPImta4YgVwUKmxTY=.a1feec21-c7ea-4853-b055-0c19831ec0d7@github.com>

On Fri, 12 May 2023 14:27:18 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed Length from HSSPublicKey, changed the handling of X509 encoded keys in the factory, did some more beautification.

Except for putting 3 lines into the try block for `engineVerify`, I only have some format comments. There are quite some long lines in `HSS.java`. Better make them less than 80 characters.

Everything else looks fine to me. Thanks for the hard work.

src/java.base/share/classes/sun/security/provider/HSS.java line 38:

> 36: 
> 37: /*
> 38:  * This class implements the Hierarchical Signature System using the

Add the short name "(HSS)" after the long name.

src/java.base/share/classes/sun/security/provider/HSS.java line 96:

> 94:         HSSSignature sig = new HSSSignature(signature, pubKey);
> 95:         LMSPublicKey lmsPubKey = pubKey.lmsPublicKey;
> 96:         boolean result = true;

Please put all 3 lines above into the `try` block so we make sure `messageStream.reset()` is always called.

src/java.base/share/classes/sun/security/provider/SHA2.java line 51:

> 49: 
> 50:     private static final int ITERATION = 64;
> 51:     private static final int BLOCKSIZE = 64;

I'm not sure if it's worth defining this. A lot of other numbers (like 56 and 120) are hardcoded and it's not easy to modify this number to implement a different algorithm.

src/java.base/share/classes/sun/security/provider/SunEntries.java line 221:

> 219:         addWithAlias(p, "KeyFactory", "DSA",
> 220:                 "sun.security.provider.DSAKeyFactory", attrs);
> 221:         addWithAlias(p, "KeyFactory", "HSS/LMS", "sun.security.provider.HSS$KeyFactoryImpl", attrs);

This line can be shorter. Overall, it will be nice to keep lines (including comment lines) shorter than 80 chars. If the code does look really ugly, better no more than 120 chars.

src/java.base/share/classes/sun/security/util/RawKeySpec.java line 32:

> 30: /**
> 31:  * This is a KeySpec that is used to specify a key by its byte array implementation.
> 32:  * It is intended to be used in testing algorithms where the algorithm specification describes the key in this form.

This comment line can be shorter.

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

PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1425204741
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192829509
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192830859
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192828015
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192828938
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1192829128

From tvaleev at openjdk.org  Sun May 14 05:53:56 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 14 May 2023 05:53:56 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
Message-ID: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>

On Fri, 12 May 2023 19:02:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308016: Remove ellipses ("...") from snippets

src/java.base/share/classes/java/io/FilePermission.java line 1033:

> 1031:      *
> 1032:      * {@snippet lang=java :
> 1033:      *     "/tmp/scratch/foo", "read,write",

This doesn't look like a valid Java code. This is not even a well-formed expression. I'm not sure whether there are any standard requirements about this (the spec is vague here), but IntelliJ IDEA assumes that the Java snippet is a member, a statement, or an expression. It's likely that parse error will be displayed here in the IDE.

src/java.base/share/classes/java/io/ObjectStreamField.java line 179:

> 177:      * Returns character encoding of field type.  The encoding is as follows:
> 178:      * {@snippet lang=java :
> 179:      *     B            byte

This is even less Java code. I don't think that snippet is appropriate here.

src/java.base/share/classes/java/io/RandomAccessFile.java line 904:

> 902:      * {@code b7}, and {@code b8,} where:
> 903:      * {@snippet lang=java :
> 904:      *         0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255,

Same: this is not Java language syntax. Code or pre tags are fine here, they are not deprecated.

src/java.base/share/classes/java/io/StreamTokenizer.java line 394:

> 392:      * characters:
> 393:      * {@snippet lang=java :
> 394:      *         0 1 2 3 4 5 6 7 8 9 . -

But Java as well

src/java.base/share/classes/java/io/StreamTokenizer.java line 774:

> 772:      *
> 773:      * {@snippet lang=java :
> 774:      *         Token['a'], line 10

Also not Java.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193078718
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193078810
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193078975
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193079002
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193079017

From tvaleev at openjdk.org  Sun May 14 05:58:54 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 14 May 2023 05:58:54 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <6nU_GjadVokt6GDAMNBo1-RUglHvk5eqkdeZwHu2EsY=.5ed4c3b5-a44b-49b9-90e9-c77afb8ffa94@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>
 <iOi1uN2Paot06qwac9kgaOPDuJxnxO2Lx7HHkqk4UKg=.22146c6c-9471-4806-a109-d0c17a9f9bf7@github.com>
 <6nU_GjadVokt6GDAMNBo1-RUglHvk5eqkdeZwHu2EsY=.5ed4c3b5-a44b-49b9-90e9-c77afb8ffa94@github.com>
Message-ID: <nb3UL06DiOQGeGcJhe6xMek-tmVwijvDIBXnCqKIriQ=.1c0cb146-6a2a-48eb-828d-57506008169b@github.com>

On Fri, 12 May 2023 17:59:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I have been just trying to keep it as similar visually as possible but what you say is reasonable.
>
> Agree, that I would make the code valid when using a snippet

There's a replacement tag for this. Some people use label, e.g.

code: // @replace substring="code:" replacement="..."


This way, the snippet remains compilable and rendered the same as before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193079515

From alanb at openjdk.org  Sun May 14 06:25:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 14 May 2023 06:25:47 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
Message-ID: <FycGtSqdssuXP44EPAvf9HQfxaN79lCatiU49JXgVAQ=.8237c7a6-c558-4fb9-8044-9840288d4d5f@github.com>

On Fri, 12 May 2023 19:02:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308016: Remove ellipses ("...") from snippets

src/java.base/share/classes/java/io/Console.java line 89:

> 87:  * if ((cons = System.console()) != null &&
> 88:  *     (passwd = cons.readPassword("[%s]", "Password:")) != null) {
> 89:  *     ...

I assume you didn't mean to remove this, this is show that there is other code in this block before the passwd is cleared.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193082310

From alanb at openjdk.org  Sun May 14 06:25:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 14 May 2023 06:25:48 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
 <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
Message-ID: <s6F-7Nm9A1b2m7Di4fv68KEC8IvjJo7uHYcJYutKJwQ=.8adf808c-6b1b-4188-b119-240781304efe@github.com>

On Sun, 14 May 2023 05:47:50 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8308016: Remove ellipses ("...") from snippets
>
> src/java.base/share/classes/java/io/FilePermission.java line 1033:
> 
>> 1031:      *
>> 1032:      * {@snippet lang=java :
>> 1033:      *     "/tmp/scratch/foo", "read,write",
> 
> This doesn't look like a valid Java code. This is not even a well-formed expression. I'm not sure whether there are any standard requirements about this (the spec is vague here), but IntelliJ IDEA assumes that the Java snippet is a member, a statement, or an expression. It's likely that parse error will be displayed here in the IDE.

Indeed, maybe a script was used to replace the <pre> </pre> tags, in which case it will checking for other non-code examples.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193082481

From asotona at openjdk.org  Mon May 15 08:47:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 May 2023 08:47:02 GMT
Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant become
 obsolete
Message-ID: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>

Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). 
All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and  `java.lang.constant.PackageDesc`. 
`jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. 
Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted.
Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed:
- `PackageDesc::packageName` to `PackageDesc::name`
- `PackageDesc::packageInternalName` to `PackageDesc::internalName`
- `ModuleDesc::moduleName` to `ModuleDesc::name`.

Please review this pull request.

Thanks,
Adam

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

Commit messages:
 - 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete

Changes: https://git.openjdk.org/jdk/pull/13979/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13979&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307326
  Stats: 503 lines in 46 files changed: 0 ins; 446 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/13979.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13979/head:pull/13979

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

From duke at openjdk.org  Mon May 15 09:33:07 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 15 May 2023 09:33:07 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v11]
In-Reply-To: <cyM7A8H-EFI_MvuO3-wEtp7JXikPImta4YgVwUKmxTY=.a1feec21-c7ea-4853-b055-0c19831ec0d7@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <dMtOSIVz5KVImiQlKtvohDyPZWhDKmBuyaLnF1fACPA=.781607aa-edd9-4992-b3b0-54f94b14488b@github.com>
 <cyM7A8H-EFI_MvuO3-wEtp7JXikPImta4YgVwUKmxTY=.a1feec21-c7ea-4853-b055-0c19831ec0d7@github.com>
Message-ID: <-9CaELTHAECXXB8GuQAwrK1-BotxTOO6-bPwNOxISSE=.e97b4e6d-183c-4d27-b649-51345dd25b4e@github.com>

On Fri, 12 May 2023 22:11:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed Length from HSSPublicKey, changed the handling of X509 encoded keys in the factory, did some more beautification.
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 38:
> 
>> 36: 
>> 37: /*
>> 38:  * This class implements the Hierarchical Signature System using the
> 
> Add the short name "(HSS)" after the long name.

Added.

> src/java.base/share/classes/sun/security/provider/HSS.java line 96:
> 
>> 94:         HSSSignature sig = new HSSSignature(signature, pubKey);
>> 95:         LMSPublicKey lmsPubKey = pubKey.lmsPublicKey;
>> 96:         boolean result = true;
> 
> Please put all 3 lines above into the `try` block so we make sure `messageStream.reset()` is always called.

Done.

> src/java.base/share/classes/sun/security/provider/SHA2.java line 51:
> 
>> 49: 
>> 50:     private static final int ITERATION = 64;
>> 51:     private static final int BLOCKSIZE = 64;
> 
> I'm not sure if it's worth defining this. A lot of other numbers (like 56 and 120) are hardcoded and it's not easy to modify this number to implement a different algorithm.

This is not about modifiability but about readability. It is easier to understand the code if the constants have names. Especially when there exist constants with the same value that serve different purposes.

> src/java.base/share/classes/sun/security/provider/SunEntries.java line 221:
> 
>> 219:         addWithAlias(p, "KeyFactory", "DSA",
>> 220:                 "sun.security.provider.DSAKeyFactory", attrs);
>> 221:         addWithAlias(p, "KeyFactory", "HSS/LMS", "sun.security.provider.HSS$KeyFactoryImpl", attrs);
> 
> This line can be shorter. Overall, it will be nice to keep lines (including comment lines) shorter than 80 chars. If the code does look really ugly, better no more than 120 chars.

I think in the 21st century (when 80 column punch cards and 80-character wide screens are long gone) the 80 character line length is quite  an unreasonable requirement for code (decreases readability in most cases). Still, I made the lines shorter.

> src/java.base/share/classes/sun/security/util/RawKeySpec.java line 32:
> 
>> 30: /**
>> 31:  * This is a KeySpec that is used to specify a key by its byte array implementation.
>> 32:  * It is intended to be used in testing algorithms where the algorithm specification describes the key in this form.
> 
> This comment line can be shorter.

Split the line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578661
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578727
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578474
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578546
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193578593

From duke at openjdk.org  Mon May 15 09:45:10 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 15 May 2023 09:45:10 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v12]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <9A97Hr3aBDW5mwW4GEDmA_1BSfLzSKDzfuQcTciH2hc=.29ea7bac-1f2d-4332-964c-ed50b9782001@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  Shortened lines, moved two lines into the try block.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/1830eee7..1abc1d78

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

  Stats: 118 lines in 3 files changed: 61 ins; 1 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/13691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691

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

From weijun at openjdk.org  Mon May 15 12:57:08 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 15 May 2023 12:57:08 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v12]
In-Reply-To: <9A97Hr3aBDW5mwW4GEDmA_1BSfLzSKDzfuQcTciH2hc=.29ea7bac-1f2d-4332-964c-ed50b9782001@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <9A97Hr3aBDW5mwW4GEDmA_1BSfLzSKDzfuQcTciH2hc=.29ea7bac-1f2d-4332-964c-ed50b9782001@github.com>
Message-ID: <w0N0nQXijgRmbNOOE6jm-DOyc9JAp-qvYlar4ZexrX4=.a06382e9-bc5d-44a1-a46d-0ac9c8ac2646@github.com>

On Mon, 15 May 2023 09:45:10 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shortened lines, moved two lines into the try block.

Everything looks fine to me now. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1426491992

From erikj at openjdk.org  Mon May 15 13:20:47 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 15 May 2023 13:20:47 GMT
Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant
 become obsolete
In-Reply-To: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
References: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
Message-ID: <er5mBWPE5TDhZV4lq-AuBaWoSp7RzsHiOC3NJ2TcXag=.6c9b1325-d46e-4934-96ae-4e73e22e405e@github.com>

On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). 
> All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and  `java.lang.constant.PackageDesc`. 
> `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. 
> Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted.
> Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed:
> - `PackageDesc::packageName` to `PackageDesc::name`
> - `PackageDesc::packageInternalName` to `PackageDesc::internalName`
> - `ModuleDesc::moduleName` to `ModuleDesc::name`.
> 
> Please review this pull request.
> 
> Thanks,
> Adam

Build changes look ok.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13979#pullrequestreview-1426543240

From duke at openjdk.org  Mon May 15 13:44:27 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 15 May 2023 13:44:27 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v13]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <FmKFLrv3b2fUjh7inHqR8y3g0GjQlGjM7DUJYHOskuk=.ea734424-22c5-4e88-98a5-811f29441953@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  Removed a comment line.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/1abc1d78..3bc2a355

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

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

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

From weijun at openjdk.org  Mon May 15 15:00:08 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 15 May 2023 15:00:08 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v13]
In-Reply-To: <FmKFLrv3b2fUjh7inHqR8y3g0GjQlGjM7DUJYHOskuk=.ea734424-22c5-4e88-98a5-811f29441953@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <FmKFLrv3b2fUjh7inHqR8y3g0GjQlGjM7DUJYHOskuk=.ea734424-22c5-4e88-98a5-811f29441953@github.com>
Message-ID: <qDwNPv0T_IDGnTn8p3ZepsNFYXveMshZ4D82QvChlV8=.95693541-6f9a-4b4b-9a6a-5e691c33c096@github.com>

On Mon, 15 May 2023 13:44:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed a comment line.

src/java.base/share/classes/sun/security/util/RawKeySpec.java line 29:

> 27: 
> 28: import java.security.spec.KeySpec;
> 29: //12345678901234567890123456789012345678901234567890123456789012345678901234567890

There is one extra line here as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193966319

From weijun at openjdk.org  Mon May 15 15:04:07 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 15 May 2023 15:04:07 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v11]
In-Reply-To: <-9CaELTHAECXXB8GuQAwrK1-BotxTOO6-bPwNOxISSE=.e97b4e6d-183c-4d27-b649-51345dd25b4e@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <dMtOSIVz5KVImiQlKtvohDyPZWhDKmBuyaLnF1fACPA=.781607aa-edd9-4992-b3b0-54f94b14488b@github.com>
 <cyM7A8H-EFI_MvuO3-wEtp7JXikPImta4YgVwUKmxTY=.a1feec21-c7ea-4853-b055-0c19831ec0d7@github.com>
 <-9CaELTHAECXXB8GuQAwrK1-BotxTOO6-bPwNOxISSE=.e97b4e6d-183c-4d27-b649-51345dd25b4e@github.com>
Message-ID: <KgQXy5JfMcQkEIFCzMDcAEJ6akDCTVF15FgkprBrFDo=.12e5268a-4948-4a8d-a0dd-9e804454a92f@github.com>

On Mon, 15 May 2023 09:30:04 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/SHA2.java line 51:
>> 
>>> 49: 
>>> 50:     private static final int ITERATION = 64;
>>> 51:     private static final int BLOCKSIZE = 64;
>> 
>> I'm not sure if it's worth defining this. A lot of other numbers (like 56 and 120) are hardcoded and it's not easy to modify this number to implement a different algorithm.
>
> This is not about modifiability but about readability. It is easier to understand the code if the constants have names. Especially when there exist constants with the same value that serve different purposes.

Good.

>> src/java.base/share/classes/sun/security/provider/SunEntries.java line 221:
>> 
>>> 219:         addWithAlias(p, "KeyFactory", "DSA",
>>> 220:                 "sun.security.provider.DSAKeyFactory", attrs);
>>> 221:         addWithAlias(p, "KeyFactory", "HSS/LMS", "sun.security.provider.HSS$KeyFactoryImpl", attrs);
>> 
>> This line can be shorter. Overall, it will be nice to keep lines (including comment lines) shorter than 80 chars. If the code does look really ugly, better no more than 120 chars.
>
> I think in the 21st century (when 80 column punch cards and 80-character wide screens are long gone) the 80 character line length is quite  an unreasonable requirement for code (decreases readability in most cases). Still, I made the lines shorter.

It's still useful when reviewing code with split panes.

We can discuss on this rule.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193972006
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1193971543

From weijun at openjdk.org  Mon May 15 15:20:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 15 May 2023 15:20:04 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v13]
In-Reply-To: <FmKFLrv3b2fUjh7inHqR8y3g0GjQlGjM7DUJYHOskuk=.ea734424-22c5-4e88-98a5-811f29441953@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <FmKFLrv3b2fUjh7inHqR8y3g0GjQlGjM7DUJYHOskuk=.ea734424-22c5-4e88-98a5-811f29441953@github.com>
Message-ID: <AJkX7tsRPzVNzUCs_0vLQXFpUwBGk174IDtltbuaDMA=.9bfcecc0-ce82-4f89-a2f9-8e7c633ba5a7@github.com>

On Mon, 15 May 2023 13:44:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed a comment line.

Oops, more comments:

1. `engineSetParameter(AlgorithmParameterSpec params)` should be overridden. Existing implementations that does not require parameters (RSA and DSA) succeeds if input is null.
2. `engineGetParameters()` should be overridden and return null.

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

PR Comment: https://git.openjdk.org/jdk/pull/13691#issuecomment-1548063322

From weijun at openjdk.org  Mon May 15 15:25:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 15 May 2023 15:25:04 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v13]
In-Reply-To: <FmKFLrv3b2fUjh7inHqR8y3g0GjQlGjM7DUJYHOskuk=.ea734424-22c5-4e88-98a5-811f29441953@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <FmKFLrv3b2fUjh7inHqR8y3g0GjQlGjM7DUJYHOskuk=.ea734424-22c5-4e88-98a5-811f29441953@github.com>
Message-ID: <omhtJ2vXOrPnIPBCbHvdCDUQsFkog4BxS_fxoHXLN6E=.e2e9cb6c-bf31-4e3f-a3ed-ebcf84138431@github.com>

On Mon, 15 May 2023 13:44:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed a comment line.

Oops, more comments:

1. `engineSetParameter(AlgorithmParameterSpec params)` should be overridden. Existing implementations that does not require parameters (RSA and DSA) succeeds if input is null.
2. `engineGetParameters()` should be overridden and return null.

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

Changes requested by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1426814309

From duke at openjdk.org  Mon May 15 16:14:24 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 15 May 2023 16:14:24 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v14]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <P953_3F0A5yKztqHelsOvdltKNp3j6h9FWZ1xTuaGyE=.a54cdf05-2012-4391-a8bf-eaa57612ec98@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  Overrided engineSetParameters() and engineGetParameters(). Removed a comment line.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/3bc2a355..cf06b52a

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

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

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

From bpb at openjdk.org  Mon May 15 18:44:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 May 2023 18:44:53 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v3]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <UWP85Qx7yl8rLEis19oxDeWxCfR2kyqPI2J2jnwBByg=.f686e941-2a14-4f23-8ec6-cabdfea50c4f@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Address reviewer comments since previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/bc5c0358..614eeda6

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

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

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

From ascarpino at openjdk.org  Mon May 15 19:10:59 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 15 May 2023 19:10:59 GMT
Subject: RFR: 8297878: KEM: Implementation [v15]
In-Reply-To: <lpPWUxJJLhlJo40d9UBbZ2jVsFaXXCoYo6VgBcHP0iU=.419f0b74-d671-4d7d-91a7-4e68537d715e@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <lpPWUxJJLhlJo40d9UBbZ2jVsFaXXCoYo6VgBcHP0iU=.419f0b74-d671-4d7d-91a7-4e68537d715e@github.com>
Message-ID: <Aoo5wZ_NjKsz1huPmgBXlwYw8maSs5mdOUCcxCfOX_s=.4e0fe983-e996-4509-b46c-4a9201d60512@github.com>

On Thu, 11 May 2023 20:56:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   deterministic randomness

src/java.base/share/classes/javax/crypto/KEM.java line 217:

> 215:          * <p>
> 216:          * An implementation may choose to not support arbitrary combinations
> 217:          * of {@code from}, {@code to}, and {@code algorithm}.

As previously discussed, I think having a code example of the `from` and `to` would be good idea.  That way it's very clear going from 0 to 32 is 32 bytes and not 33.  And an example would be a good idea in the SPI.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1194258367

From xuelei at openjdk.org  Mon May 15 19:19:47 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 15 May 2023 19:19:47 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v6]
In-Reply-To: <jeCXT2QNr-PwP9LaDAzc8Cq-y2JQxLJYXWk4AlOY6SI=.54f7080a-80d5-42b2-a285-63f8b7171a93@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>
 <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>
 <jeCXT2QNr-PwP9LaDAzc8Cq-y2JQxLJYXWk4AlOY6SI=.54f7080a-80d5-42b2-a285-63f8b7171a93@github.com>
Message-ID: <2E68n8ptBDIBE8DrraCFWAexlFEX2O70M9dS-VCjzQ0=.a89aabf5-8fad-4b64-be44-e557f123713a@github.com>

On Fri, 12 May 2023 20:30:04 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 136:
>> 
>>> 134:             } catch (IllegalArgumentException iae) {
>>> 135:                 throw new SSLException("X500Principal could not be parsed " +
>>> 136:                         "successfully", iae);
>> 
>> Is it ok to throw a general `SSLException` here? Or do you need to call `TransportContext.fatal()` so that additional cleanup happens? Perhaps @XueleiFan would know.
>
> Yes, let's wait for @XueleiFan

It is not easy to understand the final behavior if throwing SSLException here.  I would like to call `TransportContext.fatal()` directly to make the behavior more accuracy, by using Alert.DECODE_ERROR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1194266764

From mullan at openjdk.org  Mon May 15 19:40:46 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 15 May 2023 19:40:46 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v6]
In-Reply-To: <2E68n8ptBDIBE8DrraCFWAexlFEX2O70M9dS-VCjzQ0=.a89aabf5-8fad-4b64-be44-e557f123713a@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>
 <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>
 <jeCXT2QNr-PwP9LaDAzc8Cq-y2JQxLJYXWk4AlOY6SI=.54f7080a-80d5-42b2-a285-63f8b7171a93@github.com>
 <2E68n8ptBDIBE8DrraCFWAexlFEX2O70M9dS-VCjzQ0=.a89aabf5-8fad-4b64-be44-e557f123713a@github.com>
Message-ID: <rDgSnYBC_1sryyEJkPwIKi0lwtPeHAaSYORs6ljs2_w=.2f6535f9-26ad-430f-9aaa-00aea6b8ec96@github.com>

On Mon, 15 May 2023 19:17:18 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Yes, let's wait for @XueleiFan
>
> It is not easy to understand the final behavior if throwing SSLException here.  I would like to call `TransportContext.fatal()` directly to make the behavior more accuracy, by using Alert.DECODE_ERROR.

You will need to pass in `TransportContext` as a parameter if you do that, unless you go back changing the callers of `getAuthorities()` to catch `IllegalArgumentException`. I'm now thinking it is better for the callers of `getAuthorities()` to catch `IllegalArgumentException` and then call `fatal`.

One other minor comment:

- I would remove the word "successfully" as this is a failure case so it is implied.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1194286609

From kdriver at openjdk.org  Mon May 15 19:48:47 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 15 May 2023 19:48:47 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v6]
In-Reply-To: <rDgSnYBC_1sryyEJkPwIKi0lwtPeHAaSYORs6ljs2_w=.2f6535f9-26ad-430f-9aaa-00aea6b8ec96@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>
 <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>
 <jeCXT2QNr-PwP9LaDAzc8Cq-y2JQxLJYXWk4AlOY6SI=.54f7080a-80d5-42b2-a285-63f8b7171a93@github.com>
 <2E68n8ptBDIBE8DrraCFWAexlFEX2O70M9dS-VCjzQ0=.a89aabf5-8fad-4b64-be44-e557f123713a@github.com>
 <rDgSnYBC_1sryyEJkPwIKi0lwtPeHAaSYORs6ljs2_w=.2f6535f9-26ad-430f-9aaa-00aea6b8ec96@github.com>
Message-ID: <lkv994rwkMVbCta5ek0C1M0UvHJvUinhjuVA6dxIkzQ=.130a9dc2-e8cb-4ee3-a6a9-9c20caa36706@github.com>

On Mon, 15 May 2023 19:37:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> It is not easy to understand the final behavior if throwing SSLException here.  I would like to call `TransportContext.fatal()` directly to make the behavior more accuracy, by using Alert.DECODE_ERROR.
>
> You will need to pass in `TransportContext` as a parameter if you do that, unless you go back changing the callers of `getAuthorities()` to catch `IllegalArgumentException`. I'm now thinking it is better for the callers of `getAuthorities()` to catch `IllegalArgumentException` and then call `fatal`.
> 
> One other minor comment:
> 
> - I would remove the word "successfully" as this is a failure case so it is implied.

Sean, agreed. I had considered the above previously. 

Also, I'll remove "successfully" with the next round of edits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1194292927

From shade at openjdk.org  Mon May 15 20:28:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 May 2023 20:28:50 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey
Message-ID: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>

One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, which would take a while, and would likely require multiple patches, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey.

Example profile is in the bug.

On new benchmark and M1 Mac:


Benchmark       Mode  Cnt    Score   Error  Units

# Before
AESReinit.test  avgt   15  873,842 ? 6,911  ns/op

# After
AESReinit.test  avgt   15  533,018 ? 4,048  ns/op


Additional testing:
 - [x] Benchmarks
 - [x] macos-aarch64-server-release, `jdk_security`
 - [ ] linux-x86_64-server-fastdebug, `tier1 tier2`
 - [ ] linux-aarch64-server-fastdebug, `tier1 tier2`

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

Commit messages:
 - Fix
 - Fix

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

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

From bpb at openjdk.org  Mon May 15 20:48:47 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 May 2023 20:48:47 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v4]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <skLx4Vvti_Vnqnofwh6CyD14wVtELmdjcD1vXfPvJIU=.5e9fe1e7-c6c1-4a34-8f71-fbbecb99dea9@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Fix link in snippet of File::toPath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/614eeda6..da7c2004

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

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

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

From xuelei at openjdk.org  Mon May 15 20:53:45 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 15 May 2023 20:53:45 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey
In-Reply-To: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
Message-ID: <jlx8O3oM5B8hg-PKMNZUKOM4S6nM_-VZAG4DwroAx6E=.7902b84a-2b4e-471f-9eb0-2a07d9399f3e@github.com>

On Mon, 15 May 2023 19:59:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, which would take a while, and would likely require multiple patches, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey.
> 
> Example profile is in the bug.
> 
> On new benchmark and M1 Mac:
> 
> 
> Benchmark       Mode  Cnt    Score   Error  Units
> 
> # Before
> AESReinit.test  avgt   15  873,842 ? 6,911  ns/op
> 
> # After
> AESReinit.test  avgt   15  533,018 ? 4,048  ns/op
> 
> 
> Additional testing:
>  - [x] Benchmarks
>  - [x] macos-aarch64-server-release, `jdk_security`
>  - [ ] linux-x86_64-server-fastdebug, `tier1 tier2`
>  - [ ] linux-aarch64-server-fastdebug, `tier1 tier2`

src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1372:

> 1370: 
> 1371:         // It is significantly faster to allocate individual arrays,
> 1372:         // instead of doing the multi-array allocation. See JDK-8308105.

Alternatively, could the multi-array allocation get improved?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194351546

From weijun at openjdk.org  Tue May 16 01:10:10 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 16 May 2023 01:10:10 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v6]
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <C8g5cwz0NUSj61V9hvMn-yrEfFjRiOP70IOZ7B7W2K0=.3d3f04cf-7862-4d25-b7d3-ec878fde8129@github.com>

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

 - add here() back
 - Merge branch 'master' into 8305972
 - comment for new test
 - no more secret exports, one message change
 - more comment and spec refine
 - cleanup commented out code and unnecessary bug id
 - the change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13840/files
  - new: https://git.openjdk.org/jdk/pull/13840/files/b4cf0070..79ad37be

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

  Stats: 18366 lines in 550 files changed: 13234 ins; 2765 del; 2367 mod
  Patch: https://git.openjdk.org/jdk/pull/13840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840

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

From duke at openjdk.org  Tue May 16 01:54:45 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 16 May 2023 01:54:45 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey
In-Reply-To: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
Message-ID: <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com>

On Mon, 15 May 2023 19:59:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, which would take a while, and would likely require multiple patches, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey.
> 
> Example profile is in the bug.
> 
> On new benchmark and M1 Mac:
> 
> 
> Benchmark       Mode  Cnt    Score   Error  Units
> 
> # Before
> AESReinit.test  avgt   15  873,842 ? 6,911  ns/op
> 
> # After
> AESReinit.test  avgt   15  533,018 ? 4,048  ns/op
> 
> 
> Additional testing:
>  - [x] Benchmarks
>  - [x] macos-aarch64-server-release, `jdk_security`
>  - [ ] linux-x86_64-server-fastdebug, `tier1 tier2`
>  - [ ] linux-aarch64-server-fastdebug, `tier1 tier2`

src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1369:

> 1367:         int BC = 4;
> 1368:         int[][] Ke = new int[ROUNDS + 1][]; // encryption round keys
> 1369:         int[][] Kd = new int[ROUNDS + 1][]; // decryption round keys

This is more a question of curiosity and likely beyond the scope of this PR/bug ID -- would it be beneficial to refactor this to allocate and operate over just two arrays, one for Ke and one for Kd, effectively removing the need for allocation in `expandToSubKey` as well?


int[] Ke = new int[4 * (ROUNDS + 1)];
int[] Kd = new int[4 * (ROUNDS + 1)];

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194511682

From weijun at openjdk.org  Tue May 16 02:01:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 16 May 2023 02:01:04 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v7]
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <PygWGvXvzNiGL01zru5XwVEEkMLMV4CG4OtcYaZeqdQ=.fddebdc3-222d-4eca-b4b8-864d931f861e@github.com>

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

  update version in comment
  
  only in patch2:
  unchanged:

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13840/files
  - new: https://git.openjdk.org/jdk/pull/13840/files/79ad37be..e4dc75b0

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

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

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

From shade at openjdk.org  Tue May 16 06:31:45 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 May 2023 06:31:45 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey
In-Reply-To: <jlx8O3oM5B8hg-PKMNZUKOM4S6nM_-VZAG4DwroAx6E=.7902b84a-2b4e-471f-9eb0-2a07d9399f3e@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <jlx8O3oM5B8hg-PKMNZUKOM4S6nM_-VZAG4DwroAx6E=.7902b84a-2b4e-471f-9eb0-2a07d9399f3e@github.com>
Message-ID: <fZ0uYIb-v8xLQut9CXzkDMxoZmpbv5E385eHAV6kwuY=.d43e71cf-817d-4a5d-bbe9-a685a5a1eba6@github.com>

On Mon, 15 May 2023 20:51:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. 
>> 
>> Meanwhile, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey. This workaround is straight-forward and backportable.
>> 
>> Example profile is in the bug.
>> 
>> On new benchmark and M1 Mac:
>> 
>> 
>> Benchmark       Mode  Cnt    Score   Error  Units
>> 
>> # Before
>> AESReinit.test  avgt   15  873,842 ? 6,911  ns/op
>> 
>> # After
>> AESReinit.test  avgt   15  533,018 ? 4,048  ns/op
>> 
>> 
>> Additional testing:
>>  - [x] Benchmarks
>>  - [x] macos-aarch64-server-release, `jdk_security`
>>  - [ ] linux-x86_64-server-fastdebug, `tier1 tier2`
>>  - [x] linux-aarch64-server-fastdebug, `tier1 tier2`
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1372:
> 
>> 1370: 
>> 1371:         // It is significantly faster to allocate individual arrays,
>> 1372:         // instead of doing the multi-array allocation. See JDK-8308105.
> 
> Alternatively, could the multi-array allocation get improved?

Yes, it could and it eventually would, but it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. This workaround, on the other hand, is straight-forward and backportable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194673153

From mbaesken at openjdk.org  Tue May 16 07:49:46 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 16 May 2023 07:49:46 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates
In-Reply-To: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
Message-ID: <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com>

On Thu, 11 May 2023 21:38:35 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
> 
> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
> 
> This change does the following:
> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
> 
> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.

Hi Christoph, I do not see any reference to kSecTrustSettingsDomainSystem in your coding.  Handling at least kSecTrustSettingsDomainUser  and  kSecTrustSettingsDomainAdmin is good but I am not sure about kSecTrustSettingsDomainSystem . Did you find some documentation why it should be omitted ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1549166364

From alanb at openjdk.org  Tue May 16 08:00:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 May 2023 08:00:51 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v4]
In-Reply-To: <skLx4Vvti_Vnqnofwh6CyD14wVtELmdjcD1vXfPvJIU=.5e9fe1e7-c6c1-4a34-8f71-fbbecb99dea9@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <skLx4Vvti_Vnqnofwh6CyD14wVtELmdjcD1vXfPvJIU=.5e9fe1e7-c6c1-4a34-8f71-fbbecb99dea9@github.com>
Message-ID: <MygMOR35zTxuM0vUsEpc_lt0IpUaryt_3nEPkr3Mim4=.b25c1ffc-b3ec-498a-852c-dd559140acf9@github.com>

On Mon, 15 May 2023 20:48:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308016: Fix link in snippet of File::toPath

src/java.base/share/classes/java/io/File.java line 2375:

> 2373:      * {@snippet lang=java :
> 2374:      *         // @link substring="getDefault" target="java.nio.file.FileSystems#getDefault" @link regex="getPath(?=\(t)" target="java.nio.file.FileSystem#getPath" @link regex="getPath(?=\(\))" target="#getPath" :
> 2375:      *         FileSystems.getDefault().getPath(this.getPath());

There is already a link to FileSystems.getDefault() in the previous paragraph so I think you can remove the linking in the snippet to:

`// @link regex="getPath(?=(t)" target="java.nio.file.FileSystem#getPath" :`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1194767344

From shade at openjdk.org  Tue May 16 08:32:47 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 May 2023 08:32:47 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey
In-Reply-To: <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com>
Message-ID: <PPBTndMOzt34Ei7bT1T6ztZLgt0Hnt0Qq64KYAAMqD0=.36a7dd5b-bb84-411d-a721-a0e485d76845@github.com>

On Tue, 16 May 2023 01:44:24 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. 
>> 
>> Meanwhile, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey. This workaround is straight-forward and backportable.
>> 
>> Example profile is in the bug.
>> 
>> On new benchmark and M1 Mac:
>> 
>> 
>> Benchmark       Mode  Cnt    Score   Error  Units
>> 
>> # Before
>> AESReinit.test  avgt   15  873,842 ? 6,911  ns/op
>> 
>> # After
>> AESReinit.test  avgt   15  533,018 ? 4,048  ns/op
>> 
>> 
>> Additional testing:
>>  - [x] Benchmarks
>>  - [x] macos-aarch64-server-release, `jdk_security`
>>  - [ ] linux-x86_64-server-fastdebug, `tier1 tier2`
>>  - [x] linux-aarch64-server-fastdebug, `tier1 tier2`
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1369:
> 
>> 1367:         int BC = 4;
>> 1368:         int[][] Ke = new int[ROUNDS + 1][]; // encryption round keys
>> 1369:         int[][] Kd = new int[ROUNDS + 1][]; // decryption round keys
> 
> This is more a question of curiosity and likely beyond the scope of this PR/bug ID -- would it be beneficial to refactor this to allocate and operate over just two arrays, one for Ke and one for Kd, effectively removing the need for allocation in `expandToSubKey` as well?
> 
> 
> int[] Ke = new int[4 * (ROUNDS + 1)];
> int[] Kd = new int[4 * (ROUNDS + 1)];

True, let me try that!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194807087

From mbaesken at openjdk.org  Tue May 16 08:55:43 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 16 May 2023 08:55:43 GMT
Subject: RFR: JDK-8308156: VerifyCACerts.java misses blank in error output
Message-ID: <DnlI2GotQjD8YQBucIwhxLuSiYhJaVYHnbU6zHvQ4nw=.bdac2e93-f328-499b-ba07-3efb875c96c4@github.com>

In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum.

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

Commit messages:
 - JDK-8308156

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

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

From mbaesken at openjdk.org  Tue May 16 09:12:48 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 16 May 2023 09:12:48 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates
In-Reply-To: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
Message-ID: <yQq5WSWQELWss88NWubEI8bpQLZmod4wLDrfqwDNkj0=.e7a00fbf-be52-4435-a744-79cc9080ca8d@github.com>

On Thu, 11 May 2023 21:38:35 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
> 
> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
> 
> This change does the following:
> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
> 
> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.

Additionally, the return value of SecTrustSettingsCopyTrustSettings (https://developer.apple.com/documentation/security/1400261-sectrustsettingscopytrustsetting) should  better be checked.

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1549289885

From shade at openjdk.org  Tue May 16 09:18:57 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 May 2023 09:18:57 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
Message-ID: <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>

> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there. While [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) is being fixed, it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. 
> 
> Meanwhile, we can work this issue around by avoiding the multiarray allocations in AESCrypt.makeSessionKey. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely.
> 
> 
> Example profile is in the bug.
> 
> On new benchmark and M1 Mac:
> 
> 
> Benchmark       Mode  Cnt    Score   Error  Units
> 
> # Before
> AESReinit.test  avgt   15  873,842 ? 6,911  ns/op
> 
> # After
> AESReinit.test  avgt   15  347,632 ? 8,764  ns/op
> 
> 
> Additional testing:
>  - [x] Benchmarks
>  - [ ] macos-aarch64-server-release, `jdk_security`
>  - [ ] linux-x86_64-server-fastdebug, `tier1 tier2`
>  - [ ] linux-aarch64-server-fastdebug, `tier1 tier2`

Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:

 - Micro-optimizations
 - Handle Kd
 - Handle Ke

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13996/files
  - new: https://git.openjdk.org/jdk/pull/13996/files/7842e0e2..bb712183

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

  Stats: 72 lines in 1 file changed: 9 ins; 43 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/13996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13996/head:pull/13996

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

From clanger at openjdk.org  Tue May 16 09:19:55 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 16 May 2023 09:19:55 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v2]
In-Reply-To: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
Message-ID: <EUMw-ZpBY9ZjAm29VO9uEGm9gpCsSYtgopv2E1h-ync=.1492de85-50c1-43a2-81c4-3743ab7fb317@github.com>

> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
> 
> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
> 
> This change does the following:
> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
> 
> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Add some more initializations to avoid crashes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13945/files
  - new: https://git.openjdk.org/jdk/pull/13945/files/3c4424b6..22303e1c

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

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

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

From shade at openjdk.org  Tue May 16 09:30:45 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 May 2023 09:30:45 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <PPBTndMOzt34Ei7bT1T6ztZLgt0Hnt0Qq64KYAAMqD0=.36a7dd5b-bb84-411d-a721-a0e485d76845@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com>
 <PPBTndMOzt34Ei7bT1T6ztZLgt0Hnt0Qq64KYAAMqD0=.36a7dd5b-bb84-411d-a721-a0e485d76845@github.com>
Message-ID: <Pjz4dD0guzNoV-Q3bp3vq1Sf97FXr6z_EcGdNDPCKuw=.3497b7bd-ed59-471e-93e2-357e8278b5d9@github.com>

On Tue, 16 May 2023 08:29:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1369:
>> 
>>> 1367:         int BC = 4;
>>> 1368:         int[][] Ke = new int[ROUNDS + 1][]; // encryption round keys
>>> 1369:         int[][] Kd = new int[ROUNDS + 1][]; // decryption round keys
>> 
>> This is more a question of curiosity and likely beyond the scope of this PR/bug ID -- would it be beneficial to refactor this to allocate and operate over just two arrays, one for Ke and one for Kd, effectively removing the need for allocation in `expandToSubKey` as well?
>> 
>> 
>> int[] Ke = new int[4 * (ROUNDS + 1)];
>> int[] Kd = new int[4 * (ROUNDS + 1)];
>
> True, let me try that!

New commit implements this, with even more performance benefits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194883146

From shade at openjdk.org  Tue May 16 09:43:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 May 2023 09:43:50 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <fZ0uYIb-v8xLQut9CXzkDMxoZmpbv5E385eHAV6kwuY=.d43e71cf-817d-4a5d-bbe9-a685a5a1eba6@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <jlx8O3oM5B8hg-PKMNZUKOM4S6nM_-VZAG4DwroAx6E=.7902b84a-2b4e-471f-9eb0-2a07d9399f3e@github.com>
 <fZ0uYIb-v8xLQut9CXzkDMxoZmpbv5E385eHAV6kwuY=.d43e71cf-817d-4a5d-bbe9-a685a5a1eba6@github.com>
Message-ID: <j0Eee5uDJdPmVG4xPBbQumm-qfUnTN9Bpxyn751eE8c=.2140636d-d228-494b-8776-da0835c408b0@github.com>

On Tue, 16 May 2023 06:28:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1372:
>> 
>>> 1370: 
>>> 1371:         // It is significantly faster to allocate individual arrays,
>>> 1372:         // instead of doing the multi-array allocation. See JDK-8308105.
>> 
>> Alternatively, could the multi-array allocation get improved?
>
> Yes, it could and it eventually would, but it would take significantly more work: there are multiple issues of differing complexity, impact, and risk. This workaround, on the other hand, is straight-forward and backportable.

Please look again, I think we can improve this code even further, and that is where JVM optos would not help us much :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1194898514

From duke at openjdk.org  Tue May 16 10:46:44 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 16 May 2023 10:46:44 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
Message-ID: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>

Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,

I didn't add any new tests but ran tier 1-3 with no issues

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

Commit messages:
 - added some case conversions missed previously
 - updated copyright year and cleaned up some formatting of imports
 - merged master into branch
 - Specify use of Locale.Root to avoid issues with case conversion

Changes: https://git.openjdk.org/jdk/pull/14006/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7065228
  Stats: 76 lines in 21 files changed: 15 ins; 0 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/14006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14006/head:pull/14006

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

From duke at openjdk.org  Tue May 16 11:51:45 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 16 May 2023 11:51:45 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <Pjz4dD0guzNoV-Q3bp3vq1Sf97FXr6z_EcGdNDPCKuw=.3497b7bd-ed59-471e-93e2-357e8278b5d9@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <01zw2Dz6cfUyDKp4_n2LNqfF_HCk2tg-B4BU2q4K8Gs=.c7003809-d81b-489a-a74d-06d60b5b8fd6@github.com>
 <PPBTndMOzt34Ei7bT1T6ztZLgt0Hnt0Qq64KYAAMqD0=.36a7dd5b-bb84-411d-a721-a0e485d76845@github.com>
 <Pjz4dD0guzNoV-Q3bp3vq1Sf97FXr6z_EcGdNDPCKuw=.3497b7bd-ed59-471e-93e2-357e8278b5d9@github.com>
Message-ID: <RuEMpNQVOatgnW0X1XjBWxNDWln00XXlborXG_3LudA=.ca31af9b-fa7e-4995-8e59-9fa68277d6d0@github.com>

On Tue, 16 May 2023 09:28:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> True, let me try that!
>
> New commit implements this, with even more performance benefits.

Excellent, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13996#discussion_r1195043072

From dfuchs at openjdk.org  Tue May 16 13:35:49 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 16 May 2023 13:35:49 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <DHtnnoADW3f5RUt0In8xkkrn09PAMAP-uQF-KUFS-9A=.c5b232c6-bf43-4f16-a0f9-4f9bed8eef69@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

Looks generally like a good improvement. In those places `toLowerCase` is called on strings (or substrings) that are expected to be ASCII, so using Locale.ROOT looks appropriate.
Would be good to get @Michael-Mc-Mahon validate these changes too.

src/java.base/share/classes/java/io/StreamTokenizer.java line 632:

> 630:             sval = String.copyValueOf(buf, 0, i);
> 631:             if (forceLower)
> 632:                 sval = sval.toLowerCase(Locale.ROOT);

This one gave me pause. AFAICS it's probably OK - but it might warant a CSR and an update of the specification to explicitly state how the lower case conversion is performed (update the `lowerCaseMode` method spec). Could we handle that in a separate PR?

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

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1428569684
PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1195156280

From naoto at openjdk.org  Tue May 16 15:59:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 May 2023 15:59:44 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <E8ot4-f4CJyVS8gx-EF6NL6p9Q_QASWAYOk4aZfERcg=.0b7e9507-d3ca-4e72-9d0c-fb92f8273d6d@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

LGTM. Nice clean-up!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1428917297

From mullan at openjdk.org  Tue May 16 16:18:46 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 16 May 2023 16:18:46 GMT
Subject: RFR: JDK-8308156: VerifyCACerts.java misses blank in error output
In-Reply-To: <DnlI2GotQjD8YQBucIwhxLuSiYhJaVYHnbU6zHvQ4nw=.bdac2e93-f328-499b-ba07-3efb875c96c4@github.com>
References: <DnlI2GotQjD8YQBucIwhxLuSiYhJaVYHnbU6zHvQ4nw=.bdac2e93-f328-499b-ba07-3efb875c96c4@github.com>
Message-ID: <FWab1ssSoGascNpTYMNw-BHZqbxiG2ONR3kybz5RPiA=.5a9d7785-710d-4bbe-9152-d6d2210cb636@github.com>

On Tue, 16 May 2023 08:48:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum.

Please add a `noreg-self` label to the bug as this is a fix to the test.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14003#pullrequestreview-1428953153

From weijun at openjdk.org  Tue May 16 16:28:30 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 16 May 2023 16:28:30 GMT
Subject: RFR: 8297878: KEM: Implementation [v15]
In-Reply-To: <Aoo5wZ_NjKsz1huPmgBXlwYw8maSs5mdOUCcxCfOX_s=.4e0fe983-e996-4509-b46c-4a9201d60512@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <lpPWUxJJLhlJo40d9UBbZ2jVsFaXXCoYo6VgBcHP0iU=.419f0b74-d671-4d7d-91a7-4e68537d715e@github.com>
 <Aoo5wZ_NjKsz1huPmgBXlwYw8maSs5mdOUCcxCfOX_s=.4e0fe983-e996-4509-b46c-4a9201d60512@github.com>
Message-ID: <MYGTCGs-CcPk6jFLgdztJiv_4wocherjcudzEhZzsTE=.54716bc0-5945-4696-8988-72c2f0894424@github.com>

On Mon, 15 May 2023 19:07:59 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   deterministic randomness
>
> src/java.base/share/classes/javax/crypto/KEM.java line 217:
> 
>> 215:          * <p>
>> 216:          * An implementation may choose to not support arbitrary combinations
>> 217:          * of {@code from}, {@code to}, and {@code algorithm}.
> 
> As previously discussed, I think having a code example of the `from` and `to` would be good idea.  That way it's very clear going from 0 to 32 is 32 bytes and not 33.  And an example would be a good idea in the SPI.

Added some comments and example lines. And I found A REAL BUG in `DHKEM`!!! Having two styles of slicing an array is indeed a problem.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1195412465

From weijun at openjdk.org  Tue May 16 16:28:26 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 16 May 2023 16:28:26 GMT
Subject: RFR: 8297878: KEM: Implementation [v16]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <uN39t0EK8nQJMoRTwsNP8sHsAWxB1a05Ep7gPHDsFpw=.040f8a46-b995-4550-ad8e-67c6e4518952@github.com>

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

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

  to and length and comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/128cefe7..ea8f7964

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=14-15

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

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

From rhalade at openjdk.org  Tue May 16 16:26:46 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 16 May 2023 16:26:46 GMT
Subject: RFR: JDK-8308156: VerifyCACerts.java misses blank in error output
In-Reply-To: <DnlI2GotQjD8YQBucIwhxLuSiYhJaVYHnbU6zHvQ4nw=.bdac2e93-f328-499b-ba07-3efb875c96c4@github.com>
References: <DnlI2GotQjD8YQBucIwhxLuSiYhJaVYHnbU6zHvQ4nw=.bdac2e93-f328-499b-ba07-3efb875c96c4@github.com>
Message-ID: <i5Hkr6267FHSH58hqKmicGdnKodE_zGSWkzn4XiDN5E=.c8f30fe9-1c6e-4fbf-a856-4cd308294be4@github.com>

On Tue, 16 May 2023 08:48:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum.

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14003#pullrequestreview-1428965817

From bpb at openjdk.org  Tue May 16 16:30:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 16 May 2023 16:30:08 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v5]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <ymR2gUt7Hmp2K5RKYYOWNd6f5b02DbmJt3wg7DTNhC4=.c9c79507-7557-40da-90de-d4aeeb6d01fc@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Reduce linking in File::toPath snippet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/da7c2004..724a74a9

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

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

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

From liach at openjdk.org  Tue May 16 18:20:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 May 2023 18:20:45 GMT
Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant
 become obsolete
In-Reply-To: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
References: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
Message-ID: <5CjNjAQme8BTCA-TJzjjV8Zb7e-xYvuHvQENi7nUkrs=.5c407434-4d8f-42a7-aec6-37961ea9afe3@github.com>

On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). 
> All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and  `java.lang.constant.PackageDesc`. 
> `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. 
> Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted.
> Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed:
> - `PackageDesc::packageName` to `PackageDesc::name`
> - `PackageDesc::packageInternalName` to `PackageDesc::internalName`
> - `ModuleDesc::moduleName` to `ModuleDesc::name`.
> 
> Please review this pull request.
> 
> Thanks,
> Adam

I think these are all the occurrences of jdk.internal.classfile.java.lang.constant package.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/13979#pullrequestreview-1429153817

From kdriver at openjdk.org  Tue May 16 19:38:10 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 16 May 2023 19:38:10 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v7]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <eqJwbrpDMb_Esp2cEjuks5rMr1c9FEYQta1jn3bqqig=.d2cb1730-63c0-4847-a66d-7511ea728534@github.com>

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

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

 - update copyright
 - reworking the fix in light of encouragement to change the problematic method signature
 - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - updated copyright
 - fixes JDK-8294985: throw an SSLException wrapping the IAE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/0017c094..fa31ddb6

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

  Stats: 10844 lines in 494 files changed: 6394 ins; 1103 del; 3347 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

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

From valeriep at openjdk.org  Tue May 16 23:45:00 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 16 May 2023 23:45:00 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v2]
In-Reply-To: <7CAUW1aHjrYSDR2wg0tigIApQDNNta3TCjwR_5D1dxA=.51cdb2c0-61f9-4945-8c93-86fe54327c2b@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <7CAUW1aHjrYSDR2wg0tigIApQDNNta3TCjwR_5D1dxA=.51cdb2c0-61f9-4945-8c93-86fe54327c2b@github.com>
Message-ID: <9-eGBQs-MoQ0PUC2i1M5dCkr2KdmftuVd3qrpuyaMzs=.18aea3e5-38b0-4c2c-9303-a2c9adfc3e57@github.com>

On Tue, 21 Mar 2023 20:31:44 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

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

> 60:      * IvParameterSpec).
> 61:      */
> 62:     public final static class PBES2Params {

nit; static final?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1195785390

From mpowers at openjdk.org  Tue May 16 23:50:04 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 16 May 2023 23:50:04 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v14]
In-Reply-To: <P953_3F0A5yKztqHelsOvdltKNp3j6h9FWZ1xTuaGyE=.a54cdf05-2012-4391-a8bf-eaa57612ec98@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <P953_3F0A5yKztqHelsOvdltKNp3j6h9FWZ1xTuaGyE=.a54cdf05-2012-4391-a8bf-eaa57612ec98@github.com>
Message-ID: <LzxyEvtwmqL1vsX7wsfGhBQ6QG3XFgnqEjUv9Q-3Suk=.80eaa163-b22d-4511-af9b-d86445b881fd@github.com>

On Mon, 15 May 2023 16:14:24 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Overrided engineSetParameters() and engineGetParameters(). Removed a comment line.

src/java.base/share/classes/sun/security/provider/HSS.java line 354:

> 352:         final String hashAlgStr;
> 353: 
> 354:         LMSParams(int type, int m, int h, String hashAlgStr) {

`type` is unused

src/java.base/share/classes/sun/security/provider/HSS.java line 667:

> 665:         protected PublicKey engineGeneratePublic(KeySpec keySpec)
> 666:                 throws InvalidKeySpecException {
> 667:             if (keySpec instanceof X509EncodedKeySpec x) {

`x` does not appear to be used

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1195787655
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1195787782

From mbalao at openjdk.org  Wed May 17 03:11:54 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 17 May 2023 03:11:54 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) ...

Martin Balao 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:

 - Rebase fix after JDK-8306033. Replace called functions with their new names.
 - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
   
   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - 8301553: Support Password-Based Cryptography in SunPKCS11
   
   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12396/files
  - new: https://git.openjdk.org/jdk/pull/12396/files/f1b2006a..cd48dc20

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

  Stats: 888953 lines in 8327 files changed: 625265 ins; 187201 del; 76487 mod
  Patch: https://git.openjdk.org/jdk/pull/12396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12396/head:pull/12396

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

From mbaesken at openjdk.org  Wed May 17 06:45:53 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 May 2023 06:45:53 GMT
Subject: RFR: JDK-8308156: VerifyCACerts.java misses blank in error output
In-Reply-To: <DnlI2GotQjD8YQBucIwhxLuSiYhJaVYHnbU6zHvQ4nw=.bdac2e93-f328-499b-ba07-3efb875c96c4@github.com>
References: <DnlI2GotQjD8YQBucIwhxLuSiYhJaVYHnbU6zHvQ4nw=.bdac2e93-f328-499b-ba07-3efb875c96c4@github.com>
Message-ID: <5gbs_pm0Y1zcl0-wEKWX_Kh4SkAsKxb5MALrKdEAA7c=.6200b2e5-2173-4229-ac2f-394331a37f84@github.com>

On Tue, 16 May 2023 08:48:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum.

Hi Rajan and Sean, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/14003#issuecomment-1550828250

From mbaesken at openjdk.org  Wed May 17 06:45:54 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 May 2023 06:45:54 GMT
Subject: Integrated: JDK-8308156: VerifyCACerts.java misses blank in error
 output
In-Reply-To: <DnlI2GotQjD8YQBucIwhxLuSiYhJaVYHnbU6zHvQ4nw=.bdac2e93-f328-499b-ba07-3efb875c96c4@github.com>
References: <DnlI2GotQjD8YQBucIwhxLuSiYhJaVYHnbU6zHvQ4nw=.bdac2e93-f328-499b-ba07-3efb875c96c4@github.com>
Message-ID: <aSxn9tulNAzjLNOBXTlQ-nfqZ9H_Vq9U9lAie-cFKxk=.7f268eac-8a66-44a7-827a-5bc89c3f4115@github.com>

On Tue, 16 May 2023 08:48:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the checksum-related check, we miss blanks in the error output of the calculated and expected checksum.

This pull request has now been integrated.

Changeset: 5a92aae1
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a92aae1d967f5be01f05d9cc56c433a5eca61e8
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8308156: VerifyCACerts.java misses blank in error output

Reviewed-by: mullan, rhalade

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

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

From duke at openjdk.org  Wed May 17 07:16:02 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 17 May 2023 07:16:02 GMT
Subject: RFR: 8297878: KEM: Implementation [v16]
In-Reply-To: <uN39t0EK8nQJMoRTwsNP8sHsAWxB1a05Ep7gPHDsFpw=.040f8a46-b995-4550-ad8e-67c6e4518952@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <uN39t0EK8nQJMoRTwsNP8sHsAWxB1a05Ep7gPHDsFpw=.040f8a46-b995-4550-ad8e-67c6e4518952@github.com>
Message-ID: <A27GQJ9uRKt-lLCS6NHBYMN5pBck64InR-j1Q39rsRI=.9651737b-8e52-4b44-8186-380b545ad7b6@github.com>

On Tue, 16 May 2023 16:28:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   to and length and comments

src/java.base/share/classes/javax/crypto/KEM.java line 233:

> 231:          *          of the shared secret as a 128-bit AES key.
> 232:          * @throws IndexOutOfBoundsException if {@code from < 0},
> 233:          *     {@code from > to}, or {@code to > secretSize()}

Shouldn't this say "{@code to - from > secretSize()}"?

src/java.base/share/classes/javax/crypto/KEM.java line 356:

> 354:          *          decapsulation process
> 355:          * @throws IndexOutOfBoundsException if {@code from < 0},
> 356:          *          {@code from > to}, or {@code to > secretSize()}

Shouldn't this say "{@code to - from > secretSize()}"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1196042549
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1196043626

From clanger at openjdk.org  Wed May 17 07:16:47 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 17 May 2023 07:16:47 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates
In-Reply-To: <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com>
Message-ID: <FKuZecr_QCKZTxDF-dLL71eNu1Z2DSQtrR2LbsaYEFw=.e236529b-f2e1-4fe6-8bb4-ea856eda0b5b@github.com>

On Tue, 16 May 2023 07:46:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Christoph, I do not see any reference to kSecTrustSettingsDomainSystem in your coding. Handling at least kSecTrustSettingsDomainUser and kSecTrustSettingsDomainAdmin is good but I am not sure about kSecTrustSettingsDomainSystem . Did you find some documentation why it should be omitted ?

Hi Matthias,
yes, I think it is not nicely documented. I've seen in testing, that kSecTrustSettingsDomainSystem merely holds information for trusted root CAs. So in theory, we could add this. However, other code in that area that we've found out in the wild doesn't do it as well. Let's see what others think about this.

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1550872311

From mbaesken at openjdk.org  Wed May 17 07:39:45 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 May 2023 07:39:45 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates
In-Reply-To: <FKuZecr_QCKZTxDF-dLL71eNu1Z2DSQtrR2LbsaYEFw=.e236529b-f2e1-4fe6-8bb4-ea856eda0b5b@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com>
 <FKuZecr_QCKZTxDF-dLL71eNu1Z2DSQtrR2LbsaYEFw=.e236529b-f2e1-4fe6-8bb4-ea856eda0b5b@github.com>
Message-ID: <DqOWwFAGETlWXsN46lBj2hbwlPvAG2tHHtZnhZiuygk=.022327bb-dfac-4e7e-ba31-0a2ec8e54b8a@github.com>

On Wed, 17 May 2023 07:14:06 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> > Hi Christoph, I do not see any reference to kSecTrustSettingsDomainSystem in your coding. Handling at least kSecTrustSettingsDomainUser and kSecTrustSettingsDomainAdmin is good but I am not sure about kSecTrustSettingsDomainSystem . Did you find some documentation why it should be omitted ?
> 
> Hi Matthias, yes, I think it is not nicely documented. I've seen in testing, that kSecTrustSettingsDomainSystem merely holds information for trusted root CAs. So in theory, we could add this. However, other code in that area that we've found out in the wild doesn't do it as well. Let's see what others think about this.

Yes this seems to be the case.  Could you maybe add a one liner comment to  libosxsecurity/KeystoreImpl.m (near to the user and admin domain handling)  summarizing what you said? And I still prefer checking the return values of the calls to SecTrustSettingsCopyTrustSettings .

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1550901380

From clanger at openjdk.org  Wed May 17 08:06:56 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 17 May 2023 08:06:56 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
Message-ID: <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>

> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
> 
> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
> 
> This change does the following:
> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
> 
> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Check return code of SecTrustSettingsCopyTrustSettings and address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13945/files
  - new: https://git.openjdk.org/jdk/pull/13945/files/22303e1c..b14e5f2c

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

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

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

From clanger at openjdk.org  Wed May 17 08:06:57 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 17 May 2023 08:06:57 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates
In-Reply-To: <DqOWwFAGETlWXsN46lBj2hbwlPvAG2tHHtZnhZiuygk=.022327bb-dfac-4e7e-ba31-0a2ec8e54b8a@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9v1G1PxIulaLuQgurjP2B6318ytB4MEMEx-LtLSsIgI=.931be474-206e-41ad-a446-da33b66d4e9c@github.com>
 <FKuZecr_QCKZTxDF-dLL71eNu1Z2DSQtrR2LbsaYEFw=.e236529b-f2e1-4fe6-8bb4-ea856eda0b5b@github.com>
 <DqOWwFAGETlWXsN46lBj2hbwlPvAG2tHHtZnhZiuygk=.022327bb-dfac-4e7e-ba31-0a2ec8e54b8a@github.com>
Message-ID: <LWU0DENLVLaGQSq_r5lTqLm5QGpwn9JGCAKl--MNbwc=.94fff02f-04c7-458b-af65-bc3fe623ca51@github.com>

On Wed, 17 May 2023 07:36:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Yes this seems to be the case. Could you maybe add a one liner comment to libosxsecurity/KeystoreImpl.m (near to the user and admin domain handling) summarizing what you said? And I still prefer checking the return values of the calls to SecTrustSettingsCopyTrustSettings .

Done. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1550937990

From djelinski at openjdk.org  Wed May 17 10:44:47 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 17 May 2023 10:44:47 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <khArxt__ygRlbr63kl1DtT4hHdV8MV7t649XSfhCvhI=.1c153e15-b509-4b30-833d-cdb196ea0ff7@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 516:

> 514: 
> 515:         if (nccount != -1) {
> 516:             ncstring = Integer.toHexString (nccount).toLowerCase(Locale.ROOT);

Suggestion:

            ncstring = Integer.toHexString(nccount);

`toHexString` returns lowercase string

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1196296029

From duke at openjdk.org  Wed May 17 11:15:41 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 17 May 2023 11:15:41 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v15]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <0iVXog22Aqp-aEW4CTr8QpLyhM3Svmw2Rk1xL6M_yUc=.a9f92ff7-4c6d-41cf-a0a5-8a6c258d1183@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  Accepted suggestions from Mark Powers' code review and Intellij.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/cf06b52a..b5701a90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=13-14

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

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

From asemenov at openjdk.org  Wed May 17 12:35:47 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 17 May 2023 12:35:47 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
Message-ID: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>

When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
They can be fixed with small changes.

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

Commit messages:
 - 8308286 Fix clang warnings in linux code

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

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

From mbaesken at openjdk.org  Wed May 17 12:45:48 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 May 2023 12:45:48 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
Message-ID: <uYig4qeFuq7b3MJxbvpu-Ep_Z-5C2L0qI6FiRHmK03U=.4776c2ef-ae08-4dc7-9ed9-7029622c575c@github.com>

On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
>> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
>> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
>> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check return code of SecTrustSettingsCopyTrustSettings and address review comments

src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 1:

> 1: /*

Regarding CFArrayGetValueAtIndex, when looking at other usages of the function in the codebase the result is NULL checked usually. Should we do this here too? I admit the old coding does not have it as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1196455175

From asotona at openjdk.org  Wed May 17 12:48:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 May 2023 12:48:53 GMT
Subject: Integrated: 8307326: Package jdk.internal.classfile.java.lang.constant
 become obsolete
In-Reply-To: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
References: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
Message-ID: <yez7C-OQ79w_Zj_sNrbot7UcgLI3V9m74U4HSLUZgXw=.76b1ed60-4741-4bdb-91a2-821344991400@github.com>

On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). 
> All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and  `java.lang.constant.PackageDesc`. 
> `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. 
> Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted.
> Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed:
> - `PackageDesc::packageName` to `PackageDesc::name`
> - `PackageDesc::packageInternalName` to `PackageDesc::internalName`
> - `ModuleDesc::moduleName` to `ModuleDesc::name`.
> 
> Please review this pull request.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 5763be72
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5763be726700be322de3bbaf345d80e11936b472
Stats:     503 lines in 46 files changed: 0 ins; 446 del; 57 mod

8307326: Package jdk.internal.classfile.java.lang.constant become obsolete

Reviewed-by: erikj, liach

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

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

From weijun at openjdk.org  Wed May 17 12:56:11 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 17 May 2023 12:56:11 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v15]
In-Reply-To: <0iVXog22Aqp-aEW4CTr8QpLyhM3Svmw2Rk1xL6M_yUc=.a9f92ff7-4c6d-41cf-a0a5-8a6c258d1183@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <0iVXog22Aqp-aEW4CTr8QpLyhM3Svmw2Rk1xL6M_yUc=.a9f92ff7-4c6d-41cf-a0a5-8a6c258d1183@github.com>
Message-ID: <_mqzzRAbtglasUWLo6ND-k3VZ4meqj4g7pLfEen1Imo=.7c3653f3-ed33-4b06-829b-5b94851ef116@github.com>

On Wed, 17 May 2023 11:15:41 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Accepted suggestions from Mark Powers' code review and Intellij.

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1430613514

From mbaesken at openjdk.org  Wed May 17 12:57:47 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 May 2023 12:57:47 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
Message-ID: <4wyu3eHMx4T_OG28OBuAHYJqLxPE_x5gIkB9-BIWiJg=.76f8fe70-600f-4c1e-a985-02b127c229a4@github.com>

On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
>> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
>> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
>> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check return code of SecTrustSettingsCopyTrustSettings and address review comments

So please check the CFArrayGetValueAtIndex usage, but otherwise looks okay to me now, thanks for the adjustments.

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13945#pullrequestreview-1430620036

From shade at openjdk.org  Wed May 17 12:59:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 May 2023 12:59:49 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
Message-ID: <PB1TAIfO7Vl-7AsOB2QN39azNr_GRJUuipSjS-mZMlA=.13b4c80a-f8ec-4aeb-9875-8698fe9305c6@github.com>

On Tue, 16 May 2023 09:18:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there.
>> 
>> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely.
>> 
>> Example original profile is in the bug.
>> 
>> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns.
>> 
>> On new benchmark:
>> 
>> 
>> Benchmark       Mode  Cnt    Score   Error  Units
>> 
>> ## Mac M1
>> 
>> # Before
>> AESReinit.test  avgt   15   873,842 ? 6,911  ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   347,632 ? 8,764  ns/op  ; <--- 2.5x faster
>> 
>> ## Xeon, c6.8xlarge
>> 
>> # Before
>> AESReinit.test  avgt   15  1524.307 ? 24.231 ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   554.727 ? 12.876 ns/op  ; <--- 2.75x faster
>> 
>> ## Graviton, m6g.4xlarge
>> 
>> # Before
>> AESReinit.test  avgt   15  1913.492 ? 23.489 ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   639.701 ? 5.033  ns/op  ; <--- 2.99x faster
>> 
>> 
>> Additional testing:
>>  - [x] Benchmarks
>>  - [x] macos-aarch64-server-release, `jdk_security`
>>  - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3`
>
> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Micro-optimizations
>  - Handle Kd
>  - Handle Ke

@XueleiFan, or anyone else, please take a look?

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

PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1551343907

From weijun at openjdk.org  Wed May 17 13:11:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 17 May 2023 13:11:04 GMT
Subject: RFR: 8297878: KEM: Implementation [v16]
In-Reply-To: <A27GQJ9uRKt-lLCS6NHBYMN5pBck64InR-j1Q39rsRI=.9651737b-8e52-4b44-8186-380b545ad7b6@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <uN39t0EK8nQJMoRTwsNP8sHsAWxB1a05Ep7gPHDsFpw=.040f8a46-b995-4550-ad8e-67c6e4518952@github.com>
 <A27GQJ9uRKt-lLCS6NHBYMN5pBck64InR-j1Q39rsRI=.9651737b-8e52-4b44-8186-380b545ad7b6@github.com>
Message-ID: <xnw-uwQL27_i2hiBJZq7NKN8_OVLMMgpYEuArgKbxuc=.a47b3a74-e58f-4319-8485-96958a970d9c@github.com>

On Wed, 17 May 2023 07:10:49 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   to and length and comments
>
> src/java.base/share/classes/javax/crypto/KEM.java line 233:
> 
>> 231:          *          of the shared secret as a 128-bit AES key.
>> 232:          * @throws IndexOutOfBoundsException if {@code from < 0},
>> 233:          *     {@code from > to}, or {@code to > secretSize()}
> 
> Shouldn't this say "{@code to - from > secretSize()}"?

`from` and `to` are indexes into the secret itself, so it's indeed `to` cannot exceed `secretSize()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1196492411

From duke at openjdk.org  Wed May 17 13:53:55 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 17 May 2023 13:53:55 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - removed StreamTokenizer changes, will make seperate ticket for those

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14006/files
  - new: https://git.openjdk.org/jdk/pull/14006/files/a79969c2..6d40e1c8

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

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

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

From duke at openjdk.org  Wed May 17 13:53:57 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 17 May 2023 13:53:57 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <khArxt__ygRlbr63kl1DtT4hHdV8MV7t649XSfhCvhI=.1c153e15-b509-4b30-833d-cdb196ea0ff7@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <khArxt__ygRlbr63kl1DtT4hHdV8MV7t649XSfhCvhI=.1c153e15-b509-4b30-833d-cdb196ea0ff7@github.com>
Message-ID: <Og1RmemzWJrIVkwiivXnQs7MCuO7eFHzNkH2PPDLNLc=.56c9a06d-1ef9-4d53-a38f-408bdcd9ce4d@github.com>

On Wed, 17 May 2023 10:41:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>>    
>>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>>  - removed StreamTokenizer changes, will make seperate ticket for those
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 516:
> 
>> 514: 
>> 515:         if (nccount != -1) {
>> 516:             ncstring = Integer.toHexString (nccount).toLowerCase(Locale.ROOT);
> 
> Suggestion:
> 
>             ncstring = Integer.toHexString(nccount);
> 
> `toHexString` returns lowercase string

Thanks for pointing that out!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1196555183

From kdriver at openjdk.org  Wed May 17 15:10:54 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 17 May 2023 15:10:54 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v8]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <G3v5eiLZAtq4Q-gnPbr7cI1S3i2J5Yxrgih7H35tXz8=.db54af45-2b9b-4df2-92d3-4361c67932a9@github.com>

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

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

 - update copyright
 - reworking the fix in light of encouragement to change the problematic method signature
 - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - updated copyright
 - fixes JDK-8294985: throw an SSLException wrapping the IAE

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

Changes: https://git.openjdk.org/jdk/pull/13466/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=07
  Stats: 50 lines in 2 files changed: 32 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

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

From rriggs at openjdk.org  Wed May 17 15:52:58 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 May 2023 15:52:58 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
 <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
Message-ID: <A4cl0OLlMYnjcv-85F4iGTfC3IS7lvT6_f563gGxz9U=.fa8f3b04-5c24-4401-8c4a-995fb6c06f3a@github.com>

On Sun, 14 May 2023 05:50:20 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8308016: Remove ellipses ("...") from snippets
>
> src/java.base/share/classes/java/io/RandomAccessFile.java line 904:
> 
>> 902:      * {@code b7}, and {@code b8,} where:
>> 903:      * {@snippet lang=java :
>> 904:      *         0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255,
> 
> Same: this is not Java language syntax. Code or pre tags are fine here, they are not deprecated.

I would keep the snippet markup but change the language to "text"; removing the expectation of language support.
The benefits of a consistent look are still desirable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1196733214

From xuelei at openjdk.org  Wed May 17 15:53:05 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 17 May 2023 15:53:05 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v6]
In-Reply-To: <jeCXT2QNr-PwP9LaDAzc8Cq-y2JQxLJYXWk4AlOY6SI=.54f7080a-80d5-42b2-a285-63f8b7171a93@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>
 <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>
 <jeCXT2QNr-PwP9LaDAzc8Cq-y2JQxLJYXWk4AlOY6SI=.54f7080a-80d5-42b2-a285-63f8b7171a93@github.com>
Message-ID: <c1T5UivPBQtSYlRgBCpRnaaGzGQNWPELnsF_fY-14VE=.2b95c70f-4850-4b33-8d7b-c81875ec70f7@github.com>

On Fri, 12 May 2023 20:29:47 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Do you have any plans to write a test? If not, the bug needs a `noreg` label.
>
>> Do you have any plans to write a test? If not, the bug needs a `noreg` label.
> 
> As discussed internally, the test that surfaced this issue will be incorporated into regular testing. I have added `noreg-other` since none of the other labels seemed quite appropriate.

> @driverkt Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information.

@driverkt I'm not very sure.  But per this message and the webrevs, it looks like the git use for the PR request might be able to improved by working on git branches, so that you can push the commit for every little change, and avoid force-push.

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

PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1551644675

From mpowers at openjdk.org  Wed May 17 16:58:07 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Wed, 17 May 2023 16:58:07 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification
Message-ID: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>

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

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

Commit messages:
 - added more tests
 - remove carriage return
 - micro benchmark and jarsigner test
 - Ferenc's comments
 - Max's comments
 - iteration 2
 - iteration 1

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

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

From bpb at openjdk.org  Wed May 17 17:07:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 May 2023 17:07:15 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v6]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <u0EfE6vknEnro8Kb928c0VEvUOATFGlY0aLqfG59tyk=.6e423c95-b737-4a8f-8f45-c39dcf0f3052@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Reinstate @snippet for RandomAccessFile::readLong

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/724a74a9..8ae42cf2

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

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

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

From mullan at openjdk.org  Wed May 17 17:37:50 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 17 May 2023 17:37:50 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
Message-ID: <gmSpFHgiMDVBsRNToQMajsfyQugUetSNCfiCwuGqJ48=.2455a854-4288-457a-ab20-4f33fedaaf29@github.com>

On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
>> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
>> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
>> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check return code of SecTrustSettingsCopyTrustSettings and address review comments

Please don't integrate this until I or someone from my team reviews it. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1551804692

From mullan at openjdk.org  Wed May 17 18:17:50 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 17 May 2023 18:17:50 GMT
Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end
In-Reply-To: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>
References: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>
Message-ID: <yPfAohJhvVYv30pnwQ96KdolyXDtK7l2gvXb-J8l0vY=.a7cf1c5f-d902-4aeb-9eb6-e870d9f9f0db@github.com>

On Fri, 12 May 2023 16:23:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end.

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

> 97:         } catch (IOException e) {
> 98:             throw new InvalidKeyException("IOException: " +
> 99:                     e.getMessage());

How about including the cause in the IKE? Also, I suggest an error message such as "unable to decode key".

Same comments for `X509Key`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13958#discussion_r1196897272

From weijun at openjdk.org  Wed May 17 18:30:06 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 17 May 2023 18:30:06 GMT
Subject: RFR: 8297878: KEM: Implementation [v17]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <O5joLZ8ZLvSurDyJCXZ6t6jVpgcDqL1YdiAZj3NCcj4=.72b8e672-132d-4523-a21e-1a24958af07e@github.com>

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

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

 - Merge branch 'master' into 8297878
 - to and length and comments
 - deterministic randomness
 - Resolve Siba's comment
 - providerName
 - more @since and about nulls
 - Merge branch 'master' into 8297878
 - no more pk/sk, AIOOBE to IOOBE
 - small spec change
 - some constants, no local reverse
 - ... and 7 more: https://git.openjdk.org/jdk/compare/e1e90f92...655d2523

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/ea8f7964..655d2523

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=15-16

  Stats: 145061 lines in 2474 files changed: 112277 ins; 13968 del; 18816 mod
  Patch: https://git.openjdk.org/jdk/pull/13256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256

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

From xuelei at openjdk.org  Wed May 17 18:52:51 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 17 May 2023 18:52:51 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <PB1TAIfO7Vl-7AsOB2QN39azNr_GRJUuipSjS-mZMlA=.13b4c80a-f8ec-4aeb-9875-8698fe9305c6@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
 <PB1TAIfO7Vl-7AsOB2QN39azNr_GRJUuipSjS-mZMlA=.13b4c80a-f8ec-4aeb-9875-8698fe9305c6@github.com>
Message-ID: <P8p4c803MG_Z02SUIM2iP8EKKbFc2hGPgXhPkAdHReA=.8b2c2f55-b221-41d8-8c77-fe6264499fa1@github.com>

On Wed, 17 May 2023 12:57:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> @XueleiFan, or anyone else, please take a look?

I will have a look, but I may need more time.

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

PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1551895053

From dfuchs at openjdk.org  Wed May 17 18:54:20 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 17 May 2023 18:54:20 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks
Message-ID: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>

Please find here a change that revisits usage of monitors in the HttpClient.

With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.

This change aims at avoiding situations where the carrier threads might get pinned.

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

Commit messages:
 - 8308310

Changes: https://git.openjdk.org/jdk/pull/14038/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308310
  Stats: 886 lines in 31 files changed: 518 ins; 110 del; 258 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

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

From mullan at openjdk.org  Wed May 17 18:55:54 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 17 May 2023 18:55:54 GMT
Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end
In-Reply-To: <-ky9hEDy-CUetTuhH5uqbTjkpO81TpMz7ixudOw5bUg=.a2d78b86-0daf-4dba-98ec-a0317bafae7c@github.com>
References: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>
 <yPfAohJhvVYv30pnwQ96KdolyXDtK7l2gvXb-J8l0vY=.a7cf1c5f-d902-4aeb-9eb6-e870d9f9f0db@github.com>
 <-ky9hEDy-CUetTuhH5uqbTjkpO81TpMz7ixudOw5bUg=.a2d78b86-0daf-4dba-98ec-a0317bafae7c@github.com>
Message-ID: <gZ7i8eA8Z7hskoVgoITrlBMGe1qHAMw0uQ9_L6noEPo=.fee5de55-2f63-4292-9d69-46d779f95f30@github.com>

On Wed, 17 May 2023 18:51:11 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 99:
>> 
>>> 97:         } catch (IOException e) {
>>> 98:             throw new InvalidKeyException("IOException: " +
>>> 99:                     e.getMessage());
>> 
>> How about including the cause in the IKE? Also, I suggest an error message such as "unable to decode key".
>> 
>> Same comments for `X509Key`.
>
> Oh, that was old behavior. Would you like the same for https://github.com/openjdk/jdk/blob/199c84a0a2b74f855d75871a26205e05bcf8dc4b/src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java#L138 as well?

Sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13958#discussion_r1196935852

From weijun at openjdk.org  Wed May 17 18:55:53 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 17 May 2023 18:55:53 GMT
Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end
In-Reply-To: <yPfAohJhvVYv30pnwQ96KdolyXDtK7l2gvXb-J8l0vY=.a7cf1c5f-d902-4aeb-9eb6-e870d9f9f0db@github.com>
References: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>
 <yPfAohJhvVYv30pnwQ96KdolyXDtK7l2gvXb-J8l0vY=.a7cf1c5f-d902-4aeb-9eb6-e870d9f9f0db@github.com>
Message-ID: <-ky9hEDy-CUetTuhH5uqbTjkpO81TpMz7ixudOw5bUg=.a2d78b86-0daf-4dba-98ec-a0317bafae7c@github.com>

On Wed, 17 May 2023 18:14:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end.
>
> src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java line 99:
> 
>> 97:         } catch (IOException e) {
>> 98:             throw new InvalidKeyException("IOException: " +
>> 99:                     e.getMessage());
> 
> How about including the cause in the IKE? Also, I suggest an error message such as "unable to decode key".
> 
> Same comments for `X509Key`.

Oh, that was old behavior. Would you like the same for https://github.com/openjdk/jdk/blob/199c84a0a2b74f855d75871a26205e05bcf8dc4b/src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java#L138 as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13958#discussion_r1196933541

From valeriep at openjdk.org  Wed May 17 19:12:08 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 17 May 2023 19:12:08 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
Message-ID: <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>

On Wed, 17 May 2023 03:11:54 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Rebase fix after JDK-8306033. Replace called functions with their new names.
>  - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8301553: Support Password-Based Cryptography in SunPKCS11
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>

src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java line 115:

> 113:         try {
> 114:             derivedKey = PKCS12PBECipherCore.derive(
> 115:                     keySpec.getPassword(), keySpec.getSalt(),

Comparing to the original impl, this new call of keySpec.getPassword() produces extra copy of password which needs to be cleared as well.

src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java line 121:

> 119:             keySpec.clearPassword();
> 120:         }
> 121:         SecretKey cipherKey = new SecretKeySpec(derivedKey, "HmacSHA1");

Can clear out the "derivedKey" bytes if no longer needed.

src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 165:

> 163:         byte[] derivedKey = s.getEncoded();
> 164:         s.clearPassword();
> 165:         SecretKeySpec cipherKey = new SecretKeySpec(derivedKey, cipherAlgo);

Clear out the "derivedKey" bytes if no longer needed.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 345:

> 343:                 throw new InvalidKeyException("Encoded format must be RAW");
> 344:             }
> 345:             byte[] encoded = key.getEncoded();

Would be nice to clear out "encoded" bytes afterwards.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 362:

> 360:             session = token.getObjSession();
> 361:             CK_MECHANISM ckMech;
> 362:             char[] password = keySpec.getPassword();

Should clear out "password" afterwards.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 391:

> 389:             }
> 390: 
> 391:             char[] encPassword;

Same, clear out "encPassword" afterwards.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 444:

> 442:         int keyLength = 0;
> 443:         if ("RAW".equalsIgnoreCase(pbeKey.getFormat())) {
> 444:             byte[] encoded = pbeKey.getEncoded();

Should clear out "encoded" afterwards.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 450:

> 448:         }
> 449:         int ic = pbeKey.getIterationCount();
> 450:         char[] pwd = pbeKey.getPassword();

Should clear out "pwd" afterwards.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 562:

> 560:         } else if (algorithm.equalsIgnoreCase("DES")) {
> 561:             if (keySpec instanceof DESKeySpec desKeySpec) {
> 562:                 byte[] keyBytes = desKeySpec.getKey();

Would be nice to clear out "keyBytes" afterwards. Same goes for the other "keyBytes" in the same method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196925886
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196926732
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196936604
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196940708
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196942089
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196943128
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196944774
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196946761
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1196951831

From duke at openjdk.org  Wed May 17 20:01:26 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 17 May 2023 20:01:26 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v16]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <cNHb-8UB5diAiQ9dHXmh_iPYXBUwKcx_YH1l109zbfw=.20548615-8d32-4c1a-8e4d-9f5335d86849@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  More input checks.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/b5701a90..9801b158

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=14-15

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

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

From kdriver at openjdk.org  Wed May 17 20:06:08 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 17 May 2023 20:06:08 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v9]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <C1q-T6XQv1vzCv0IZ-DmOUUPrMeZx3RLq2uGY0GXrfA=.310659b9-2676-4983-aa64-fd83a10fd38e@github.com>

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

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

 - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
 - update copyright
 - reworking the fix in light of encouragement to change the problematic method signature
 - Update src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - updated copyright
 - fixes JDK-8294985: throw an SSLException wrapping the IAE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/d02cfd1c..3ffdfd63

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

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

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

From xuelei at openjdk.org  Wed May 17 20:12:49 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 17 May 2023 20:12:49 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
Message-ID: <n6FPUG6Z1yYHToQIo1WOxK9PwwIriLPqdAvUd6aOp_4=.bef0db52-3714-43f6-bc08-834bdc695768@github.com>

On Tue, 16 May 2023 09:18:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there.
>> 
>> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely.
>> 
>> Example original profile is in the bug.
>> 
>> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns.
>> 
>> On new benchmark:
>> 
>> 
>> Benchmark       Mode  Cnt    Score   Error  Units
>> 
>> ## Mac M1
>> 
>> # Before
>> AESReinit.test  avgt   15   873,842 ? 6,911  ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   347,632 ? 8,764  ns/op  ; <--- 2.5x faster
>> 
>> ## Xeon, c6.8xlarge
>> 
>> # Before
>> AESReinit.test  avgt   15  1524.307 ? 24.231 ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   554.727 ? 12.876 ns/op  ; <--- 2.75x faster
>> 
>> ## Graviton, m6g.4xlarge
>> 
>> # Before
>> AESReinit.test  avgt   15  1913.492 ? 23.489 ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   639.701 ? 5.033  ns/op  ; <--- 2.99x faster
>> 
>> 
>> Additional testing:
>>  - [x] Benchmarks
>>  - [x] macos-aarch64-server-release, `jdk_security`
>>  - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3`
>
> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Micro-optimizations
>  - Handle Kd
>  - Handle Ke

Looks good to me.  Please make sure the security regression testing passed.

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

Marked as reviewed by xuelei (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13996#pullrequestreview-1431510226

From duke at openjdk.org  Wed May 17 20:48:52 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Wed, 17 May 2023 20:48:52 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
Message-ID: <d2f_BSXDE5Tk_fkFjoTQGeMNw8QoReAkUelJwBrXIgU=.c7a5ba33-2da7-41d9-a0a3-8aad8868baa2@github.com>

On Tue, 16 May 2023 09:18:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there.
>> 
>> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely.
>> 
>> Example original profile is in the bug.
>> 
>> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns.
>> 
>> On new benchmark:
>> 
>> 
>> Benchmark       Mode  Cnt    Score   Error  Units
>> 
>> ## Mac M1
>> 
>> # Before
>> AESReinit.test  avgt   15   873,842 ? 6,911  ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   347,632 ? 8,764  ns/op  ; <--- 2.5x faster
>> 
>> ## Xeon, c6.8xlarge
>> 
>> # Before
>> AESReinit.test  avgt   15  1524.307 ? 24.231 ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   554.727 ? 12.876 ns/op  ; <--- 2.75x faster
>> 
>> ## Graviton, m6g.4xlarge
>> 
>> # Before
>> AESReinit.test  avgt   15  1913.492 ? 23.489 ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   639.701 ? 5.033  ns/op  ; <--- 2.99x faster
>> 
>> 
>> Additional testing:
>>  - [x] Benchmarks
>>  - [x] macos-aarch64-server-release, `jdk_security`
>>  - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3`
>
> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Micro-optimizations
>  - Handle Kd
>  - Handle Ke

I don't think my review counts, but this looks good to me

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

Marked as reviewed by schlosna at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/13996#pullrequestreview-1431597342

From bpb at openjdk.org  Wed May 17 20:51:29 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 May 2023 20:51:29 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v7]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <jPkoZCShs1oyBRYLRaXDWQwNeVZC-SoDRDa36kTjMeg=.3b17b331-7817-4528-8e45-4957c2315829@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

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

 - Merge
 - 8308016: Reinstate @snippet for RandomAccessFile::readLong
 - 8308016: Reduce linking in File::toPath snippet
 - 8308016: Fix link in snippet of File::toPath
 - 8308016: Address reviewer comments since previous commit
 - 8308016: Remove ellipses ("...") from snippets
 - 8308016: Use snippets in java.io package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/8ae42cf2..d0dce640

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

  Stats: 13770 lines in 553 files changed: 8566 ins; 1596 del; 3608 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

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

From weijun at openjdk.org  Wed May 17 20:52:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 17 May 2023 20:52:51 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
Message-ID: <7VtFRAbOyuD3iAwIUq0SPrylxAg4SOkjDdLKVBMytoY=.fc9dd81c-1442-4d11-a850-fcb17d64452b@github.com>

On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
>> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
>> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
>> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check return code of SecTrustSettingsCopyTrustSettings and address review comments

No matter what `SecTrustSettingsCopyTrustSettings` returns, you will always call `jm_createTrustedCertEntry`. This means if I add a self-signed certificate but has not added any trusted settings onto it, it will be always trusted. Is this intended?

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1552066526

From clanger at openjdk.org  Wed May 17 21:13:49 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 17 May 2023 21:13:49 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <gmSpFHgiMDVBsRNToQMajsfyQugUetSNCfiCwuGqJ48=.2455a854-4288-457a-ab20-4f33fedaaf29@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
 <gmSpFHgiMDVBsRNToQMajsfyQugUetSNCfiCwuGqJ48=.2455a854-4288-457a-ab20-4f33fedaaf29@github.com>
Message-ID: <cTgIgqYMdw5-YU7dxm5GB6asJ_xkoxs3pmrJFToR67o=.acd2d61c-31fc-41aa-8a16-5d7aea0220ff@github.com>

On Wed, 17 May 2023 17:34:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Please don't integrate this until I or someone from my team reviews it. Thanks.

Sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1552088991

From clanger at openjdk.org  Wed May 17 21:32:50 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 17 May 2023 21:32:50 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <7VtFRAbOyuD3iAwIUq0SPrylxAg4SOkjDdLKVBMytoY=.fc9dd81c-1442-4d11-a850-fcb17d64452b@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
 <7VtFRAbOyuD3iAwIUq0SPrylxAg4SOkjDdLKVBMytoY=.fc9dd81c-1442-4d11-a850-fcb17d64452b@github.com>
Message-ID: <jzgdhD2OhQTiR9Y1pxxtXHmZDx8lR4_XLNSt4VCa29Q=.83f51e9e-b9a9-4249-8e08-564c21e61b99@github.com>

On Wed, 17 May 2023 20:49:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> No matter what `SecTrustSettingsCopyTrustSettings` returns, you will always call `jm_createTrustedCertEntry`. This means if I add a self-signed certificate but has not added any trusted settings onto it, it will be always trusted. Is this intended?

Yes, I will call `jm_createTrustedCertEntry` for every certificate, at least independent from the results of the `SecTrustSettingsCopyTrustSettings` calls.

As I outlined in my initial PR description, point 3, the actual check whether a certificate is self-signed is done in the `createTrustedCertEntry` Java method. So, yes, when there is a self-signed certificate without explicit trust settings, it is always trusted. I thought that this was the intentional behavior even before my changes. However, the difference to the code before is that I look at the certificate and check whether it is a real plain self-signed certificate that can be used for TLS communication - which would be trusted. But what's not trusted now are CA root certificates which also means self-signed but additionally key usage 'keyCertSign' and/or 'cRLSign'. See [this code](https://github.com/RealCLanger/jdk/blob/b14e5f2c78ff4aded84410a2b58d83138349d9ab/src/java.base/macosx/classes/apple/security/KeychainStore.java#L857)

Makes sense?

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1552107272

From clanger at openjdk.org  Wed May 17 21:32:54 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 17 May 2023 21:32:54 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <uYig4qeFuq7b3MJxbvpu-Ep_Z-5C2L0qI6FiRHmK03U=.4776c2ef-ae08-4dc7-9ed9-7029622c575c@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
 <uYig4qeFuq7b3MJxbvpu-Ep_Z-5C2L0qI6FiRHmK03U=.4776c2ef-ae08-4dc7-9ed9-7029622c575c@github.com>
Message-ID: <ayIJBfSyOskc3kZHkEQUpeW1AI_kTkuy5eb3eBKHqZY=.13ecfa4b-2c2b-4b8e-83ff-d0b2182c1549@github.com>

On Wed, 17 May 2023 12:42:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check return code of SecTrustSettingsCopyTrustSettings and address review comments
>
> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m line 1:
> 
>> 1: /*
> 
> Regarding CFArrayGetValueAtIndex, when looking at other usages of the function in the codebase the result is NULL checked usually. Should we do this here too? I admit the old coding does not have it as well.

Hm, can it really be NULL? I mean before we check the array size and then iterate the valid range.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1197070738

From kdriver at openjdk.org  Wed May 17 21:54:20 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 17 May 2023 21:54:20 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v10]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <VYgeSaPAxkzGX4gQFQYU-NgkMVH7Pv4D6-l3tyaXaYs=.96658c3a-187b-46b9-9865-fae7d0cf155e@github.com>

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

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

  rework based upon code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/3ffdfd63..0aa93e2a

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

  Stats: 52 lines in 2 files changed: 17 ins; 15 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

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

From kdriver at openjdk.org  Wed May 17 21:58:53 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Wed, 17 May 2023 21:58:53 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v6]
In-Reply-To: <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>
 <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>
Message-ID: <_N61Dcd8QmAoinlIlYD3K40_78FlXVCdh513OFeq7ME=.01dae3ad-be0a-4763-9022-c03bdc534992@github.com>

On Fri, 12 May 2023 20:14:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Driver has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> Do you have any plans to write a test? If not, the bug needs a `noreg` label.

@seanjmullan @XueleiFan - ready for another round of reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1552140738

From weijun at openjdk.org  Thu May 18 00:03:50 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 18 May 2023 00:03:50 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
Message-ID: <2dBwm9ZtkuIaWeJdSnE-_rZdaGxLowoeuT77pdXrM_U=.10eefa2c-be1c-4b78-878a-e9bd73d7ca5c@github.com>

On Wed, 17 May 2023 08:06:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
>> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
>> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
>> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check return code of SecTrustSettingsCopyTrustSettings and address review comments

Before your new change, such a certificate is not trusted, because `SecTrustSettingsCopyTrustSettings` returns `errSecItemNotFound` so `jm_createTrustedCertEntry` is not called at all.

I am not sure if such a certificate is meant to be always trusted. Note that you can create such an entry with only `security add-certificates` but not `security add-trusted-cert`. macOS allows anyone to run the first command but prompts you for an administrator password when running the second. The name of the second command also implies that it's the only way to assign trust to a certificate, IMHO.

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1552229495

From xuelei at openjdk.org  Thu May 18 04:08:55 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 18 May 2023 04:08:55 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v10]
In-Reply-To: <VYgeSaPAxkzGX4gQFQYU-NgkMVH7Pv4D6-l3tyaXaYs=.96658c3a-187b-46b9-9865-fae7d0cf155e@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <VYgeSaPAxkzGX4gQFQYU-NgkMVH7Pv4D6-l3tyaXaYs=.96658c3a-187b-46b9-9865-fae7d0cf155e@github.com>
Message-ID: <OoSZIw_oJF2O6qhuHbkzoj_fE6IrI9xzETaX2cFv10M=.66972a57-f04f-4a4b-a510-34cc9cf20181@github.com>

On Wed, 17 May 2023 21:54:20 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rework based upon code review comments

Similar comments for update in CertificateRequest.java

Similar comments for update in CertificateRequest.java

src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 126:

> 124:         }
> 125: 
> 126:         X500Principal[] getAuthorities() throws IllegalArgumentException {

IAE is unchecked exception, and should not be throwing explicitly in method signature/statement.  I'm not sure if this throwing is really helpful for caller to check the exception.

src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 147:

> 145:                     builder.append(principal.toString());
> 146:                 } catch (IllegalArgumentException iae) {
> 147:                     builder.append("unparseable X500Principal");

I may use the iae message as well for better debugging.

src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 289:

> 287:                 shc.peerSupportedAuthorities = spec.getAuthorities();
> 288:             } catch (IllegalArgumentException iae) {
> 289:                 shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed");

To easy debugging, I may use the exception with fatal(Alert alert, String diagnostic, Throwable cause).  Considering this point, I may prefer to throw SSLException in getAuthorities() method.


X500Principal[] getAuthorities() throws SSLException {
...
try {
    shc.peerSupportedAuthorities = spec.getAuthorities();
} catch (SSLException ssle) {
    shc.conContext.fatal(Alert.DECODE_ERROR, "Cannot parse peer supported authorities", ssle);
}

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

Changes requested by xuelei (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1431961001
PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1431970382
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197326576
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197327083
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197334523

From shade at openjdk.org  Thu May 18 06:46:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 18 May 2023 06:46:49 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <n6FPUG6Z1yYHToQIo1WOxK9PwwIriLPqdAvUd6aOp_4=.bef0db52-3714-43f6-bc08-834bdc695768@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
 <n6FPUG6Z1yYHToQIo1WOxK9PwwIriLPqdAvUd6aOp_4=.bef0db52-3714-43f6-bc08-834bdc695768@github.com>
Message-ID: <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com>

On Wed, 17 May 2023 20:09:50 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Looks good to me. Please make sure the security regression testing passed.

Thanks! By "security regression testing" that you mean `jdk_security`, or something else?

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

PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1552552955

From xuelei at openjdk.org  Thu May 18 07:20:54 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 18 May 2023 07:20:54 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
 <n6FPUG6Z1yYHToQIo1WOxK9PwwIriLPqdAvUd6aOp_4=.bef0db52-3714-43f6-bc08-834bdc695768@github.com>
 <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com>
Message-ID: <C9D7I2QMZaTjo1SKdwLN2SZiaWLCjjo1vFMl8J6YPSk=.1341d110-c3bc-4e7a-9a13-62f6d81e28aa@github.com>

On Thu, 18 May 2023 06:44:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Looks good to me. Please make sure the security regression testing passed.
> 
> Thanks! By "security regression testing" that you mean `jdk_security`, or something else?

jdk_security or tier2.

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

PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1552616281

From shade at openjdk.org  Thu May 18 07:20:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 18 May 2023 07:20:54 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <C9D7I2QMZaTjo1SKdwLN2SZiaWLCjjo1vFMl8J6YPSk=.1341d110-c3bc-4e7a-9a13-62f6d81e28aa@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
 <n6FPUG6Z1yYHToQIo1WOxK9PwwIriLPqdAvUd6aOp_4=.bef0db52-3714-43f6-bc08-834bdc695768@github.com>
 <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com>
 <C9D7I2QMZaTjo1SKdwLN2SZiaWLCjjo1vFMl8J6YPSk=.1341d110-c3bc-4e7a-9a13-62f6d81e28aa@github.com>
Message-ID: <wXbpjqVmqj2UPXnDDLisTIuREhgpmFitW9q8ZzpTwos=.4ddc9f67-cfb0-4f18-89a1-3aa768a902ba@github.com>

On Thu, 18 May 2023 07:16:31 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> jdk_security or tier2.

Gotcha, I already tested both, see "Additional Testing" section in PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1552619095

From duke at openjdk.org  Thu May 18 08:54:49 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 18 May 2023 08:54:49 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification
In-Reply-To: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
Message-ID: <H1xs3Zgl6EQnfU4mQPxd2ErvvWqn69rRD1HigROx6G8=.66bdb833-fb30-4a3f-94cb-4d8d0da0cd40@github.com>

On Thu, 11 May 2023 19:06:59 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8307794

I suggest the following:
 1. Separate the data from the code and put the data to the end of the files (e.g. create a " TestCase[] testCases;" array and let the TestCase class handle the creation of the byte arrays from the hex strings. A testCase can have expected outcome, along with the data, too, that might make the actual testing code more compact.
 2. Reformat all the data similarly to the one in DisableLMS.java (about 80 character long lines) - there are some very long lines in HssLms.java and very short ones in TestLMS.java and HssLms.java .
 3. Don't us simply LMS in the file names. HSS or HSSLMS would align better with what you are testing.
 4. Remove the SHAKE tests (test11-13 in HssLms.java .

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

PR Comment: https://git.openjdk.org/jdk/pull/13940#issuecomment-1552743471

From djelinski at openjdk.org  Thu May 18 09:47:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 18 May 2023 09:47:52 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <Agw1U8jJIdnuZuC_WY3nK8Ht5oZi6J3rN17BQVLK2HI=.8056e5a9-caa7-43f1-9f6c-b55e899820fd@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1432388069

From dfuchs at openjdk.org  Thu May 18 10:04:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 10:04:51 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <0GxhPfV9kjdGq_66qtf-4bnWOhVwd5wZKr4HVDbBvkE=.fd5017df-882c-48a8-b373-34d6204664a1@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1432410653

From mullan at openjdk.org  Thu May 18 12:53:57 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 18 May 2023 12:53:57 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v10]
In-Reply-To: <OoSZIw_oJF2O6qhuHbkzoj_fE6IrI9xzETaX2cFv10M=.66972a57-f04f-4a4b-a510-34cc9cf20181@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <VYgeSaPAxkzGX4gQFQYU-NgkMVH7Pv4D6-l3tyaXaYs=.96658c3a-187b-46b9-9865-fae7d0cf155e@github.com>
 <OoSZIw_oJF2O6qhuHbkzoj_fE6IrI9xzETaX2cFv10M=.66972a57-f04f-4a4b-a510-34cc9cf20181@github.com>
Message-ID: <I1Z9ULLaFPEJC3Knm1qwMZY6BaTkSZVJ1Msk71q6pvg=.301f760c-a4af-4b90-beea-6d6eae0884b3@github.com>

On Thu, 18 May 2023 03:51:55 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rework based upon code review comments
>
> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 126:
> 
>> 124:         }
>> 125: 
>> 126:         X500Principal[] getAuthorities() throws IllegalArgumentException {
> 
> IAE is unchecked exception, and should not be throwing explicitly in method signature/statement.  I'm not sure if this throwing is really helpful for caller to check the exception.

Yes, I agree with that comment. I suggest adding a comment above the method to remind callers they may need to catch IAE, something like:

// This method will throw IllegalArgumentException if the X500Principal cannot be parsed.

> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 147:
> 
>> 145:                     builder.append(principal.toString());
>> 146:                 } catch (IllegalArgumentException iae) {
>> 147:                     builder.append("unparseable X500Principal");
> 
> I may use the iae message as well for better debugging.

Yes, suggest:

`builder.append("unparseable X500Principal: " + iae.getMessage());`

> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 289:
> 
>> 287:                 shc.peerSupportedAuthorities = spec.getAuthorities();
>> 288:             } catch (IllegalArgumentException iae) {
>> 289:                 shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed");
> 
> To easy debugging, I may use the exception with fatal(Alert alert, String diagnostic, Throwable cause).  Considering this point, I may prefer to throw SSLException in getAuthorities() method.
> 
> 
> X500Principal[] getAuthorities() throws SSLException {
> ...
> try {
>     shc.peerSupportedAuthorities = spec.getAuthorities();
> } catch (SSLException ssle) {
>     shc.conContext.fatal(Alert.DECODE_ERROR, "Cannot parse peer supported authorities", ssle);
> }

@XueleiFan Seems like an unnecessary wrapping of IAE when it is going to be rethrown anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197768251
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197771043
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197773420

From mullan at openjdk.org  Thu May 18 12:53:59 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 18 May 2023 12:53:59 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v10]
In-Reply-To: <VYgeSaPAxkzGX4gQFQYU-NgkMVH7Pv4D6-l3tyaXaYs=.96658c3a-187b-46b9-9865-fae7d0cf155e@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <VYgeSaPAxkzGX4gQFQYU-NgkMVH7Pv4D6-l3tyaXaYs=.96658c3a-187b-46b9-9865-fae7d0cf155e@github.com>
Message-ID: <2jKNqaE6Q3u17GL1X_dLvnrHkNQKbYoyzLhsSxj3Dyk=.3be8d3aa-aff3-42cd-bfb9-623d75e17918@github.com>

On Wed, 17 May 2023 21:54:20 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rework based upon code review comments

src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 738:

> 736:             try {
> 737:                 chc.peerSupportedAuthorities = crm.getAuthorities();
> 738:             }

Move the `catch` line up to line 738.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197776053

From mullan at openjdk.org  Thu May 18 13:25:55 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 18 May 2023 13:25:55 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification
In-Reply-To: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
Message-ID: <ycNtWro5Gety4qKb0t6mYfRpFc70c2C6F9-bK7-0hxA=.d946b93d-1352-493a-b2f3-b206ffcb0a7d@github.com>

On Thu, 11 May 2023 19:06:59 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8307794

test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug JDK-8307794

I think the bug here should be what it is testing, which is the HSS/LMS implementation (JDK-8298127). Same comment for other tests.

test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 28:

> 26:  * @bug JDK-8307794
> 27:  * @summary verify JAR files signed with HSS/LMS
> 28:  * @author Wang Weijun

We don't usually put `@author` labels in code/tests anymore.

test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 39:

> 37: import java.util.Base64;
> 38: 
> 39: public class DisableLMS {

The name of this test seems too specific, since it also tests a signed JAR when HSS/LMS is not disabled. Perhaps rename this to `VerifyHSSLMSSignedJar`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197812930
PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197814003
PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197818398

From weijun at openjdk.org  Thu May 18 13:39:10 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 18 May 2023 13:39:10 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v8]
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <4IiFTRwAih-0sEDpmyqSSTulbp6L4mFy93M2Ye0oWGM=.dde82a5b-de60-4148-94a6-e7acedbe29a8@github.com>

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported".
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

 - Merge branch 'master' into 8305972
 - fix here
 - update version in comment
   
   only in patch2:
   unchanged:
 - add here() back
 - Merge branch 'master' into 8305972
 - comment for new test
 - no more secret exports, one message change
 - more comment and spec refine
 - cleanup commented out code and unnecessary bug id
 - the change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13840/files
  - new: https://git.openjdk.org/jdk/pull/13840/files/e4dc75b0..ba36ae3d

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

  Stats: 110983 lines in 1856 files changed: 86609 ins; 9774 del; 14600 mod
  Patch: https://git.openjdk.org/jdk/pull/13840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840

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

From mullan at openjdk.org  Thu May 18 13:45:53 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 18 May 2023 13:45:53 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v8]
In-Reply-To: <4IiFTRwAih-0sEDpmyqSSTulbp6L4mFy93M2Ye0oWGM=.dde82a5b-de60-4148-94a6-e7acedbe29a8@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
 <4IiFTRwAih-0sEDpmyqSSTulbp6L4mFy93M2Ye0oWGM=.dde82a5b-de60-4148-94a6-e7acedbe29a8@github.com>
Message-ID: <HMKkoS35EVblb30BtcU6J_7WSMX60oAlHBToyDgJjpE=.c184bfc6-a30b-44de-8448-fefe0ed421a5@github.com>

On Thu, 18 May 2023 13:39:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Update XML Security for Java to 3.0.2. Some change to tests:
>> 
>> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported".
>> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8305972
>  - fix here
>  - update version in comment
>    
>    only in patch2:
>    unchanged:
>  - add here() back
>  - Merge branch 'master' into 8305972
>  - comment for new test
>  - no more secret exports, one message change
>  - more comment and spec refine
>  - cleanup commented out code and unnecessary bug id
>  - the change

Just one wording suggestion. Otherwise looks good

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13840#pullrequestreview-1429167827

From mullan at openjdk.org  Thu May 18 13:45:57 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 18 May 2023 13:45:57 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v6]
In-Reply-To: <C8g5cwz0NUSj61V9hvMn-yrEfFjRiOP70IOZ7B7W2K0=.3d3f04cf-7862-4d25-b7d3-ec878fde8129@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
 <C8g5cwz0NUSj61V9hvMn-yrEfFjRiOP70IOZ7B7W2K0=.3d3f04cf-7862-4d25-b7d3-ec878fde8129@github.com>
Message-ID: <Dd9jjrnw8cqGLCKnIWCXPkJcSh6fwYylsdyCA9ln_Mc=.e53cbf02-4fd2-4db0-a419-6d7c0e8f2a98@github.com>

On Tue, 16 May 2023 01:10:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Update XML Security for Java to 3.0.2. Some change to tests:
>> 
>> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported".
>> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - add here() back
>  - Merge branch 'master' into 8305972
>  - comment for new test
>  - no more secret exports, one message change
>  - more comment and spec refine
>  - cleanup commented out code and unnecessary bug id
>  - the change

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

> 1003: 
> 1004: #
> 1005: # Support here() function

s/Support/Support for the/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13840#discussion_r1195545852

From xuelei at openjdk.org  Thu May 18 14:16:01 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 18 May 2023 14:16:01 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v10]
In-Reply-To: <OoSZIw_oJF2O6qhuHbkzoj_fE6IrI9xzETaX2cFv10M=.66972a57-f04f-4a4b-a510-34cc9cf20181@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <VYgeSaPAxkzGX4gQFQYU-NgkMVH7Pv4D6-l3tyaXaYs=.96658c3a-187b-46b9-9865-fae7d0cf155e@github.com>
 <OoSZIw_oJF2O6qhuHbkzoj_fE6IrI9xzETaX2cFv10M=.66972a57-f04f-4a4b-a510-34cc9cf20181@github.com>
Message-ID: <_L3NRbs51f14oTrJnV9i46E3ZhfHGjg2V2UQi90in10=.52c3d975-a656-40e7-bc11-a40a75c6eb46@github.com>

On Thu, 18 May 2023 04:04:17 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rework based upon code review comments
>
> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 289:
> 
>> 287:                 shc.peerSupportedAuthorities = spec.getAuthorities();
>> 288:             } catch (IllegalArgumentException iae) {
>> 289:                 shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed");
> 
> To easy debugging, I may use the exception with fatal(Alert alert, String diagnostic, Throwable cause).  Considering this point, I may prefer to throw SSLException in getAuthorities() method.
> 
> 
> X500Principal[] getAuthorities() throws SSLException {
> ...
> try {
>     shc.peerSupportedAuthorities = spec.getAuthorities();
> } catch (SSLException ssle) {
>     shc.conContext.fatal(Alert.DECODE_ERROR, "Cannot parse peer supported authorities", ssle);
> }

> @XueleiFan Seems like an unnecessary wrapping of IAE when it is going to be rethrown anyway.

I'm fine if IAE get checked for every call to getAuthorities().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1197881532

From xuelei at openjdk.org  Thu May 18 14:17:51 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 18 May 2023 14:17:51 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <wXbpjqVmqj2UPXnDDLisTIuREhgpmFitW9q8ZzpTwos=.4ddc9f67-cfb0-4f18-89a1-3aa768a902ba@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
 <n6FPUG6Z1yYHToQIo1WOxK9PwwIriLPqdAvUd6aOp_4=.bef0db52-3714-43f6-bc08-834bdc695768@github.com>
 <9-ftYEvMXPoyCmQUYzS1GR39kE39RuDNkq0dd9K_nAM=.afbd4630-9eba-4e2f-a637-ad00db036fd5@github.com>
 <C9D7I2QMZaTjo1SKdwLN2SZiaWLCjjo1vFMl8J6YPSk=.1341d110-c3bc-4e7a-9a13-62f6d81e28aa@github.com>
 <wXbpjqVmqj2UPXnDDLisTIuREhgpmFitW9q8ZzpTwos=.4ddc9f67-cfb0-4f18-89a1-3aa768a902ba@github.com>
Message-ID: <D4RgJd7EmM7Dk-K4F2STT7CoGI_t7J3SnkPRofu2ED8=.84ee56c2-d654-4f82-846d-5722ef0141f2@github.com>

On Thu, 18 May 2023 07:18:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > jdk_security or tier2.
> 
> Gotcha, I already tested both, see "Additional Testing" section in PR.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1553126729

From weijun at openjdk.org  Thu May 18 14:24:02 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 18 May 2023 14:24:02 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v9]
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <86ADeAGG-onak6Mna95bcb5ptptuiqYWXvup40EdH0M=.8ff8e417-d676-4636-9c6c-5baacde743c9@github.com>

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported".
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

  title in java.security

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13840/files
  - new: https://git.openjdk.org/jdk/pull/13840/files/ba36ae3d..407832d0

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

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

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

From weijun at openjdk.org  Thu May 18 14:48:58 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 18 May 2023 14:48:58 GMT
Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end
 [v2]
In-Reply-To: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>
References: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>
Message-ID: <IYMIONVS6yeb-fdyA0Aqfdqh2GW2N58E8-s2Jr5DeJs=.5aec563e-497c-4117-8cd3-a26af46f67c7@github.com>

> When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end.

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

  add reasons

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13958/files
  - new: https://git.openjdk.org/jdk/pull/13958/files/199c84a0..65357365

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

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

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

From weijun at openjdk.org  Thu May 18 15:15:30 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 18 May 2023 15:15:30 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v10]
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <hte8KYWgCR3l8J9czArup-NF8clsbGkUSpNH26yELs8=.a156f962-1273-41b3-8651-9410f30ad30e@github.com>

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported".
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

  test modifies policy should run in othervm mode
  
  only in patch2:
  unchanged:

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13840/files
  - new: https://git.openjdk.org/jdk/pull/13840/files/407832d0..c98e2edd

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

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

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

From mpowers at openjdk.org  Thu May 18 15:39:53 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 18 May 2023 15:39:53 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification
In-Reply-To: <ycNtWro5Gety4qKb0t6mYfRpFc70c2C6F9-bK7-0hxA=.d946b93d-1352-493a-b2f3-b206ffcb0a7d@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <ycNtWro5Gety4qKb0t6mYfRpFc70c2C6F9-bK7-0hxA=.d946b93d-1352-493a-b2f3-b206ffcb0a7d@github.com>
Message-ID: <sdhQzihM27ivVHmECKfTcBAHBB4GhVB1hw5dpgiqpBE=.38745aa6-21d4-4d03-9956-7082be6cd5b1@github.com>

On Thu, 18 May 2023 13:18:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug JDK-8307794
> 
> I think the bug here should be what it is testing, which is the HSS/LMS implementation (JDK-8298127). Same comment for other tests.

fixed

> test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 28:
> 
>> 26:  * @bug JDK-8307794
>> 27:  * @summary verify JAR files signed with HSS/LMS
>> 28:  * @author Wang Weijun
> 
> We don't usually put `@author` labels in code/tests anymore.

removed` @author`

> test/jdk/sun/security/tools/jarsigner/DisableLMS.java line 39:
> 
>> 37: import java.util.Base64;
>> 38: 
>> 39: public class DisableLMS {
> 
> The name of this test seems too specific, since it also tests a signed JAR when HSS/LMS is not disabled. Perhaps rename this to `VerifyHSSLMSSignedJar`?

renamed to `VerifyHSSLMSSignedJar`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197973701
PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197974502
PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1197975370

From kdriver at openjdk.org  Thu May 18 16:07:59 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 16:07:59 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v10]
In-Reply-To: <I1Z9ULLaFPEJC3Knm1qwMZY6BaTkSZVJ1Msk71q6pvg=.301f760c-a4af-4b90-beea-6d6eae0884b3@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <VYgeSaPAxkzGX4gQFQYU-NgkMVH7Pv4D6-l3tyaXaYs=.96658c3a-187b-46b9-9865-fae7d0cf155e@github.com>
 <OoSZIw_oJF2O6qhuHbkzoj_fE6IrI9xzETaX2cFv10M=.66972a57-f04f-4a4b-a510-34cc9cf20181@github.com>
 <I1Z9ULLaFPEJC3Knm1qwMZY6BaTkSZVJ1Msk71q6pvg=.301f760c-a4af-4b90-beea-6d6eae0884b3@github.com>
Message-ID: <QOlE3fSSssWdEbO15hFiDY78L1BKlbp6hTS3iXxlAX0=.13f89dc9-5d0c-499d-8f6c-173d5dafebcc@github.com>

On Thu, 18 May 2023 12:42:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 126:
>> 
>>> 124:         }
>>> 125: 
>>> 126:         X500Principal[] getAuthorities() throws IllegalArgumentException {
>> 
>> IAE is unchecked exception, and should not be throwing explicitly in method signature/statement.  I'm not sure if this throwing is really helpful for caller to check the exception.
>
> Yes, I agree with that comment. I suggest adding a comment above the method to remind callers they may need to catch IAE, something like:
> 
> // This method will throw IllegalArgumentException if the X500Principal cannot be parsed.

Agreed. It's atypical (at least) to include a RuntimeException in the method signature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198005604

From aturbanov at openjdk.org  Thu May 18 16:12:12 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 May 2023 16:12:12 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v16]
In-Reply-To: <cNHb-8UB5diAiQ9dHXmh_iPYXBUwKcx_YH1l109zbfw=.20548615-8d32-4c1a-8e4d-9f5335d86849@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <cNHb-8UB5diAiQ9dHXmh_iPYXBUwKcx_YH1l109zbfw=.20548615-8d32-4c1a-8e4d-9f5335d86849@github.com>
Message-ID: <6N04iO3eVgcUvVAMzFPIsKrHeTJ6FPdiKzCfhs8BDrI=.77854da9-17a3-4e96-9335-103f54412477@github.com>

On Wed, 17 May 2023 20:01:26 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More input checks.

src/java.base/share/classes/sun/security/provider/HSS.java line 191:

> 189: 
> 190:     static class LMSUtils {
> 191:         final static int LMS_RESERVED = 0;

use blessed modifiers order
Suggestion:

        static final int LMS_RESERVED = 0;

src/java.base/share/classes/sun/security/provider/HSS.java line 216:

> 214:         final static int LMOTS_SHA256_N32_W2 = 2;
> 215:         final static int LMOTS_SHA256_N32_W4 = 3;
> 216:         final static int LMOTS_SHA256_N32_W8 = 4;

Suggestion:

        static final int LMOTS_RESERVED = 0;
        static final int LMOTS_SHA256_N32_W1 = 1;
        static final int LMOTS_SHA256_N32_W2 = 2;
        static final int LMOTS_SHA256_N32_W4 = 3;
        static final int LMOTS_SHA256_N32_W8 = 4;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198008506
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198009083

From kdriver at openjdk.org  Thu May 18 16:15:39 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 16:15:39 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v11]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>

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

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

  review comments addressed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/0aa93e2a..5a20371e

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

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

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

From kdriver at openjdk.org  Thu May 18 16:23:59 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 16:23:59 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v6]
In-Reply-To: <c1T5UivPBQtSYlRgBCpRnaaGzGQNWPELnsF_fY-14VE=.2b95c70f-4850-4b33-8d7b-c81875ec70f7@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <urVYD0vp3jnd3hcV5LdNvd7cQoodepYHwxmNClZ3V_I=.012506ab-d9c9-4fa3-9012-786a92eef6da@github.com>
 <XLpMVBi2lu_8raRksm7CtpJAOUMinEtT8CbV4I5vBgs=.d99e827e-345d-42ca-9018-7bdfd44cec29@github.com>
 <jeCXT2QNr-PwP9LaDAzc8Cq-y2JQxLJYXWk4AlOY6SI=.54f7080a-80d5-42b2-a285-63f8b7171a93@github.com>
 <c1T5UivPBQtSYlRgBCpRnaaGzGQNWPELnsF_fY-14VE=.2b95c70f-4850-4b33-8d7b-c81875ec70f7@github.com>
Message-ID: <dQOnkEoX5ckUIDVfRDkBIgsh0LFXkLpHksPwYMp3myk=.fe5839f9-6fcd-4cc5-9046-7c16791a6772@github.com>

On Wed, 17 May 2023 15:49:27 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> Do you have any plans to write a test? If not, the bug needs a `noreg` label.
>> 
>> As discussed internally, the test that surfaced this issue will be incorporated into regular testing. I have added `noreg-other` since none of the other labels seemed quite appropriate.
>
>> @driverkt Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information.
> 
> @driverkt I'm not very sure.  But per this message and the webrevs, it looks like the git use for the PR request might be able to improved by working on git branches, so that you can push the commit for every little change, and avoid force-push.

@XueleiFan @seanjmullan all comments have been addressed.

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

PR Comment: https://git.openjdk.org/jdk/pull/13466#issuecomment-1553300216

From aturbanov at openjdk.org  Thu May 18 16:24:17 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 May 2023 16:24:17 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v16]
In-Reply-To: <cNHb-8UB5diAiQ9dHXmh_iPYXBUwKcx_YH1l109zbfw=.20548615-8d32-4c1a-8e4d-9f5335d86849@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <cNHb-8UB5diAiQ9dHXmh_iPYXBUwKcx_YH1l109zbfw=.20548615-8d32-4c1a-8e4d-9f5335d86849@github.com>
Message-ID: <F1prd6smzsdp5j9Szsb2EvGHsAQbaRB0uXnXVOHE-BA=.2d5fa8c7-f504-4cd8-930f-cc09d2623be1@github.com>

On Wed, 17 May 2023 20:01:26 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More input checks.

src/java.base/share/classes/sun/security/provider/HSS.java line 36:

> 34: import java.util.Arrays;
> 35: 
> 36: /*

Can we make it a javadoc?
Suggestion:

/**

src/java.base/share/classes/sun/security/provider/HSS.java line 410:

> 408:         final int sigLmType;
> 409:         final int sigOtsType;
> 410:         final private byte[] qArr;

let's remove `private` to be consistent with other fields
Suggestion:

        final byte[] qArr;

src/java.base/share/classes/sun/security/provider/HSS.java line 415:

> 413:         final int n; // output length of the hash function used in the OTS
> 414:         final int p; // number of hash chains in the signature
> 415:         final int m; // output length of the hash fubction used in the Merkle tree

typo `fubction`

src/java.base/share/classes/sun/security/provider/HSS.java line 428:

> 426: 
> 427:             LMOTSParams lmotsParams;
> 428:                 q = LMSUtils.fourBytesToInt(sigArray, offset);

indentations is confusing here

src/java.base/share/classes/sun/security/provider/HSS.java line 512:

> 510:         // Precomputed block for SHA256 when the message size is 55 bytes
> 511:         // (i.e. when SHA256 is used)
> 512:         private final static byte[] hashbufSha256_32 = {

Suggestion:

        private static final byte[] hashbufSha256_32 = {

src/java.base/share/classes/sun/security/provider/HSS.java line 711:

> 709:         protected Key engineTranslateKey(Key key) throws InvalidKeyException {
> 710:             if (key == null) {
> 711:                 throw  new InvalidKeyException("key cannot be null");

Suggestion:

                throw new InvalidKeyException("key cannot be null");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198023023
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198020705
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198020959
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198018892
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198018138
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198024479

From mullan at openjdk.org  Thu May 18 16:46:56 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 18 May 2023 16:46:56 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v11]
In-Reply-To: <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>
Message-ID: <V7oExf9r9_yuKJiOoBphL8JcVw3Dns1tYiffZN-kX2k=.06c036f8-137d-49c3-9841-cfad1aff88e6@github.com>

On Thu, 18 May 2023 16:15:39 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments addressed

src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 33:

> 31: import java.text.MessageFormat;
> 32: import java.util.*;
> 33: import javax.net.ssl.SSLException;

This import is not needed anymore.

src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 35:

> 33: import java.util.*;
> 34: import javax.net.ssl.SSLEngine;
> 35: import javax.net.ssl.SSLException;

This import is not needed anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198042070
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198043800

From xuelei at openjdk.org  Thu May 18 16:46:58 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 18 May 2023 16:46:58 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v11]
In-Reply-To: <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>
Message-ID: <ctWFax0-oBX02R6vC0_JMMAb_-vjuMxOkB1n4fcubro=.bfc91fe5-bdd4-4019-a5e2-77e837345776@github.com>

On Thu, 18 May 2023 16:15:39 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments addressed

src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 148:

> 146:                     builder.append(principal.toString());
> 147:                 } catch (IllegalArgumentException iae) {
> 148:                     builder.append("unparseable X500Principal: " + iae.getMessage());

Throwable.getMessage() may return `null`.  I may use iae.toString() instead.

`builder.append("unparseable X500Principal: " + iae);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198044980

From djelinski at openjdk.org  Thu May 18 16:57:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 18 May 2023 16:57:52 GMT
Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match
 AES-GCM
In-Reply-To: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
Message-ID: <55PJuNTFQVH_K3zqyzRFWCpu2L6T6BKERX0lV91_HdA=.729132f2-7533-4a3c-9965-5698f05e8991@github.com>

On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fixes an issue where the key/nonce reuse policy for SunJCE ChaCha20 and ChaCha20-Poly1305 was overly strict in enforcing no-reuse when the Cipher was in DECRYPT_MODE.  For decryption, this should be allowed and be consistent with the AES-GCM decryption initialization behavior.
> 
> - Issue: https://bugs.openjdk.org/browse/JDK-8305091
> - CSR: https://bugs.openjdk.org/browse/JDK-8305822

Thank you for that. This is actually required for decrypting QUIC packets; the QUIC specification permits dropping duplicate packets only after fully decrypting them.

LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13428#pullrequestreview-1433082578

From xuelei at openjdk.org  Thu May 18 16:59:40 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 18 May 2023 16:59:40 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v11]
In-Reply-To: <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>
Message-ID: <y4romaRbjG3tbg1CUFXyxRCzbeW2FvwKdFm7uTvBMFY=.7a00faa1-7051-471a-9034-5fe5a37bd867@github.com>

On Thu, 18 May 2023 16:15:39 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments addressed

src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 290:

> 288:                 shc.peerSupportedAuthorities = spec.getAuthorities();
> 289:             } catch (IllegalArgumentException iae) {
> 290:                 shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed", iae);

In the context, it may be easier to catch the idea if the message is about the authorities, and easier to update getAuthorities() implementation, for example X500Principal is not used any longer, if needed in the future.

- "X500Principal could not be parsed"
+ "Peer authorities could not be parsed"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198051462

From kdriver at openjdk.org  Thu May 18 16:59:32 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 16:59:32 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v12]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <YqCiLEdLxFPJfQV1yZzY-0xe40F_DSKa-9v1wL1RZCo=.1e9711a4-bb48-4a2e-9e67-ba337df678c6@github.com>

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

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

  optimize imports and change toString

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/5a20371e..e33a9b0b

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

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

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

From kdriver at openjdk.org  Thu May 18 16:59:38 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 16:59:38 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v11]
In-Reply-To: <ctWFax0-oBX02R6vC0_JMMAb_-vjuMxOkB1n4fcubro=.bfc91fe5-bdd4-4019-a5e2-77e837345776@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>
 <ctWFax0-oBX02R6vC0_JMMAb_-vjuMxOkB1n4fcubro=.bfc91fe5-bdd4-4019-a5e2-77e837345776@github.com>
Message-ID: <0NGU7VDtItrnf0Pu4i0afJb7e0RB-MJIQAUxMYx4WyU=.4166cd66-9872-4f7b-90ee-a34c5e77e461@github.com>

On Thu, 18 May 2023 16:42:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments addressed
>
> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 148:
> 
>> 146:                     builder.append(principal.toString());
>> 147:                 } catch (IllegalArgumentException iae) {
>> 148:                     builder.append("unparseable X500Principal: " + iae.getMessage());
> 
> Throwable.getMessage() may return `null`.  I may use iae.toString() instead.
> 
> `builder.append("unparseable X500Principal: " + iae);`

`toString` would be called implicitly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198052098

From bpb at openjdk.org  Thu May 18 17:01:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 May 2023 17:01:54 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <A4cl0OLlMYnjcv-85F4iGTfC3IS7lvT6_f563gGxz9U=.fa8f3b04-5c24-4401-8c4a-995fb6c06f3a@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
 <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
 <A4cl0OLlMYnjcv-85F4iGTfC3IS7lvT6_f563gGxz9U=.fa8f3b04-5c24-4401-8c4a-995fb6c06f3a@github.com>
Message-ID: <ql09L2uOj696eUdJhr9W8LLBhZvJQXUqulqBE_OlfKc=.a42c2a2b-d09a-4feb-adae-a91916345b41@github.com>

On Wed, 17 May 2023 15:50:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/RandomAccessFile.java line 904:
>> 
>>> 902:      * {@code b7}, and {@code b8,} where:
>>> 903:      * {@snippet lang=java :
>>> 904:      *         0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255,
>> 
>> Same: this is not Java language syntax. Code or pre tags are fine here, they are not deprecated.
>
> I would keep the snippet markup but change the language to "text"; removing the expectation of language support.
> The benefits of a consistent look are still desirable.

Changed to unspecified language in 8ae42cf24b931d21dc643d233f33d4ccc5b32d6f.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198061816

From kdriver at openjdk.org  Thu May 18 17:02:01 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 17:02:01 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v11]
In-Reply-To: <y4romaRbjG3tbg1CUFXyxRCzbeW2FvwKdFm7uTvBMFY=.7a00faa1-7051-471a-9034-5fe5a37bd867@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>
 <y4romaRbjG3tbg1CUFXyxRCzbeW2FvwKdFm7uTvBMFY=.7a00faa1-7051-471a-9034-5fe5a37bd867@github.com>
Message-ID: <EFf39A9PrrbEtLBRXUOCMGWCWytL9DlbzC85vSQhJ6I=.e855ef05-b84f-4fe6-91af-b2aa4a22170a@github.com>

On Thu, 18 May 2023 16:48:34 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments addressed
>
> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 290:
> 
>> 288:                 shc.peerSupportedAuthorities = spec.getAuthorities();
>> 289:             } catch (IllegalArgumentException iae) {
>> 290:                 shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed", iae);
> 
> In the context, it may be easier to catch the idea if the message is about the authorities, and easier to update getAuthorities() implementation, for example X500Principal is not used any longer, if needed in the future.
> 
> - "X500Principal could not be parsed"
> + "Peer authorities could not be parsed"

I'm inclined to keep the current version. It seems more specific in guiding the caller to the fix needed. However, I understand your point. 

@seanjmullan comments?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198061874

From weijun at openjdk.org  Thu May 18 17:07:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 18 May 2023 17:07:40 GMT
Subject: RFR: 8297878: KEM: Implementation [v18]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <YfHJ3qqBwrxM7Ft-CR8SYUUPdSAyn3TLOas8gX870Us=.05ddc735-6275-46f2-82eb-b08364f48b71@github.com>

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

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

 - Merge branch 'master' into 8297878
 - Merge branch 'master' into 8297878
 - to and length and comments
 - deterministic randomness
 - Resolve Siba's comment
 - providerName
 - more @since and about nulls
 - Merge branch 'master' into 8297878
 - no more pk/sk, AIOOBE to IOOBE
 - small spec change
 - ... and 8 more: https://git.openjdk.org/jdk/compare/bccb8927...7cace182

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/655d2523..7cace182

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=16-17

  Stats: 5872 lines in 78 files changed: 4595 ins; 1087 del; 190 mod
  Patch: https://git.openjdk.org/jdk/pull/13256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256

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

From mullan at openjdk.org  Thu May 18 17:14:55 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 18 May 2023 17:14:55 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v11]
In-Reply-To: <EFf39A9PrrbEtLBRXUOCMGWCWytL9DlbzC85vSQhJ6I=.e855ef05-b84f-4fe6-91af-b2aa4a22170a@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <5NdiagFXnbJrmYwb7SWjgopF0jf_-tHN-yFjUGA1aFQ=.a2de69d7-d52d-452f-8040-1c383caa8ae9@github.com>
 <y4romaRbjG3tbg1CUFXyxRCzbeW2FvwKdFm7uTvBMFY=.7a00faa1-7051-471a-9034-5fe5a37bd867@github.com>
 <EFf39A9PrrbEtLBRXUOCMGWCWytL9DlbzC85vSQhJ6I=.e855ef05-b84f-4fe6-91af-b2aa4a22170a@github.com>
Message-ID: <4rBEcllezxknzMpU7_41PpuAqv8K5xPuBkSmCB9yODs=.201f77bd-b055-4c15-9375-4338633dbc51@github.com>

On Thu, 18 May 2023 16:58:50 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 290:
>> 
>>> 288:                 shc.peerSupportedAuthorities = spec.getAuthorities();
>>> 289:             } catch (IllegalArgumentException iae) {
>>> 290:                 shc.conContext.fatal(Alert.DECODE_ERROR, "X500Principal could not be parsed", iae);
>> 
>> In the context, it may be easier to catch the idea if the message is about the authorities, and easier to update getAuthorities() implementation, for example X500Principal is not used any longer, if needed in the future.
>> 
>> - "X500Principal could not be parsed"
>> + "Peer authorities could not be parsed"
>
> I'm inclined to keep the current version. It seems more specific in guiding the caller to the fix needed. However, I understand your point. 
> 
> @seanjmullan comments?

I tend to agree with Xuelei in that we should try to use terms as specified in the TLS RFCs in error messages as that will give a user a better indication of where the issue is. I would even be a bit more specific and suggest:

"The distinguished names of the peer's certificate authorities could not be parsed"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198073492

From kdriver at openjdk.org  Thu May 18 17:49:07 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 17:49:07 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v13]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>

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

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

  all review comments applied

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/e33a9b0b..335fb052

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

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

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

From mullan at openjdk.org  Thu May 18 17:57:55 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 18 May 2023 17:57:55 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v13]
In-Reply-To: <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
Message-ID: <cUvtw51AGqo8q6eYVIvcUXDyaQ9fYrneHtvkY5ylai4=.8aad040d-3fc9-4003-b850-0ec963f54d64@github.com>

On Thu, 18 May 2023 17:49:07 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   all review comments applied

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1433176661

From xuelei at openjdk.org  Thu May 18 18:05:52 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 18 May 2023 18:05:52 GMT
Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match
 AES-GCM
In-Reply-To: <55PJuNTFQVH_K3zqyzRFWCpu2L6T6BKERX0lV91_HdA=.729132f2-7533-4a3c-9965-5698f05e8991@github.com>
References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
 <55PJuNTFQVH_K3zqyzRFWCpu2L6T6BKERX0lV91_HdA=.729132f2-7533-4a3c-9965-5698f05e8991@github.com>
Message-ID: <TInUCkM1xdf15ay9yVCQvDPihnCQ_445nn3zjyUgGFw=.f0f3245b-4b94-4673-a746-8705e4d85aba@github.com>

On Thu, 18 May 2023 16:55:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> the QUIC specification permits dropping duplicate packets only after fully decrypting them.

May I have a reference, for example the section number, of the specification?

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

PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1553425386

From xuelei at openjdk.org  Thu May 18 18:09:56 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 18 May 2023 18:09:56 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v13]
In-Reply-To: <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
Message-ID: <GFl8qeT4ZqlY_VgAt99clA8NYS-JuRbdWrVQ4svm348=.210b7980-5dec-4cf9-9f60-6dbbe19cda1d@github.com>

On Thu, 18 May 2023 17:49:07 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   all review comments applied

Marked as reviewed by xuelei (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1433195956

From djelinski at openjdk.org  Thu May 18 18:19:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 18 May 2023 18:19:52 GMT
Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match
 AES-GCM
In-Reply-To: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
Message-ID: <t7z3JmBHxoQq6w1EAPbNejRckgp7iQTTSMWM9k6qURg=.0af07748-d6cb-42ac-a6d1-64b22b2343e1@github.com>

On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fixes an issue where the key/nonce reuse policy for SunJCE ChaCha20 and ChaCha20-Poly1305 was overly strict in enforcing no-reuse when the Cipher was in DECRYPT_MODE.  For decryption, this should be allowed and be consistent with the AES-GCM decryption initialization behavior.
> 
> - Issue: https://bugs.openjdk.org/browse/JDK-8305091
> - CSR: https://bugs.openjdk.org/browse/JDK-8305822

Here you go:
https://www.rfc-editor.org/rfc/rfc9000.html#name-packet-numbers
> A receiver MUST discard a newly unprotected packet unless it is certain that it has not processed another packet with the same packet number from the same packet number space. Duplicate suppression MUST happen after removing packet protection for the reasons described in [Section 9.5](https://www.rfc-editor.org/rfc/rfc9001#section-9.5) of [[QUIC-TLS](https://www.rfc-editor.org/rfc/rfc9000.html#QUIC-TLS)].

https://www.rfc-editor.org/rfc/rfc9001#section-9.5
> If the recipient of a packet discards packets with duplicate packet numbers without attempting to remove packet protection, they could reveal through timing side channels that the packet number matches a received packet. For authentication to be free from side channels, the entire process of header protection removal, packet number recovery, and packet protection removal MUST be applied together without timing and other side channels.

Additionally check out the header protection section https://www.rfc-editor.org/rfc/rfc9001#name-chacha20-based-header-prote:

  header_protection(hp_key, sample):
  counter = sample[0..3]
  nonce = sample[4..15]
  mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})

`sample` is taken from AES-encrypted data, so basically random; there's a (minimal) chance that the sample will be the same between unrelated packets, and a 100% chance that duplicate packets will have the same sample. Without this PR, header protection fails on duplicate samples. With this PR `ChaCha20` is usable (in decrypt mode, but both modes produce identical output)

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

PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1553440682

From xuelei at openjdk.org  Thu May 18 18:32:51 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 18 May 2023 18:32:51 GMT
Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match
 AES-GCM
In-Reply-To: <t7z3JmBHxoQq6w1EAPbNejRckgp7iQTTSMWM9k6qURg=.0af07748-d6cb-42ac-a6d1-64b22b2343e1@github.com>
References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
 <t7z3JmBHxoQq6w1EAPbNejRckgp7iQTTSMWM9k6qURg=.0af07748-d6cb-42ac-a6d1-64b22b2343e1@github.com>
Message-ID: <V8rj3KcDSxl0aj_Fdxpmn-Q9AvvwQS2bMiYmKn-3RRQ=.2354dea6-d20a-4173-80d5-5cb717902d56@github.com>

On Thu, 18 May 2023 18:16:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Here you go:

@djelinski Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1553459091

From rriggs at openjdk.org  Thu May 18 18:36:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 May 2023 18:36:55 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v7]
In-Reply-To: <jPkoZCShs1oyBRYLRaXDWQwNeVZC-SoDRDa36kTjMeg=.3b17b331-7817-4528-8e45-4957c2315829@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <jPkoZCShs1oyBRYLRaXDWQwNeVZC-SoDRDa36kTjMeg=.3b17b331-7817-4528-8e45-4957c2315829@github.com>
Message-ID: <MKOPt7rHfUgCNG6jb9ZrdSXpDGIx9nCdgn_fdlXK0HQ=.1d0f5117-2ca8-4761-a10b-d2c22e2afdf6@github.com>

On Wed, 17 May 2023 20:51:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge
>  - 8308016: Reinstate @snippet for RandomAccessFile::readLong
>  - 8308016: Reduce linking in File::toPath snippet
>  - 8308016: Fix link in snippet of File::toPath
>  - 8308016: Address reviewer comments since previous commit
>  - 8308016: Remove ellipses ("...") from snippets
>  - 8308016: Use snippets in java.io package

src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 284:

> 282:      * array such that:
> 283:      * {@snippet lang=java :
> 284:      *         c == (char)(((hibyte & 0xff) << 8) | (b & 0xff))

I'd skip the extra indentation for just the single line example.

src/java.base/share/classes/java/io/CharArrayWriter.java line 189:

> 187:      *
> 188:      * {@snippet lang=java :
> 189:      *     out.write(csq.subSequence(start, end).toString())

a trailing ";' would be useful for copy/paste; butr that's not the existing style.  Your call.

src/java.base/share/classes/java/io/Console.java line 125:

> 123:      *             Scanner sc = new Scanner(con.reader());
> 124:      *             code: // @replace substring="code:" replacement="..."
> 125:      *         }

4 space indentation would be enough.

src/java.base/share/classes/java/io/RandomAccessFile.java line 762:

> 760:      * then the result is:
> 761:      * {@snippet lang=java :
> 762:      *         (byte)(b)

4 space indent is sufficient in this file

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198146819
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198147802
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198151689
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198160636

From duke at openjdk.org  Thu May 18 19:11:32 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 18 May 2023 19:11:32 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v17]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <ida3mujwIQIHFT6PiBNIKwv4hzOyHX503iN050lND_g=.e6ea1f2f-cddb-4cc8-a1ce-62cf7a348d22@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

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

  Removed dead code, accepted code style suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/9801b158..8f14964c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=15-16

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

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

From duke at openjdk.org  Thu May 18 19:11:36 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 18 May 2023 19:11:36 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v16]
In-Reply-To: <F1prd6smzsdp5j9Szsb2EvGHsAQbaRB0uXnXVOHE-BA=.2d5fa8c7-f504-4cd8-930f-cc09d2623be1@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <cNHb-8UB5diAiQ9dHXmh_iPYXBUwKcx_YH1l109zbfw=.20548615-8d32-4c1a-8e4d-9f5335d86849@github.com>
 <F1prd6smzsdp5j9Szsb2EvGHsAQbaRB0uXnXVOHE-BA=.2d5fa8c7-f504-4cd8-930f-cc09d2623be1@github.com>
Message-ID: <jJd2Q2jL_gutWpgL7PpGqfYBLcKYJx4DAKt-0tjNI9I=.68205ba7-6391-4a64-b11f-8a602c9c52ac@github.com>

On Thu, 18 May 2023 16:18:02 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More input checks.
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 410:
> 
>> 408:         final int sigLmType;
>> 409:         final int sigOtsType;
>> 410:         final private byte[] qArr;
> 
> let's remove `private` to be consistent with other fields
> Suggestion:
> 
>         final byte[] qArr;

I wanted to express that the array should be immutable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1198201763

From bpb at openjdk.org  Thu May 18 19:14:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 May 2023 19:14:02 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v8]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <M9zVErlCn0A2sEt_iOGlAh3pypQmmY43hB1QVOncwlA=.22a1d957-3165-465d-80db-f678d31f4048@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Address reviewer comments since previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/d0dce640..b6abb2e4

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

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

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

From bpb at openjdk.org  Thu May 18 19:14:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 May 2023 19:14:06 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v7]
In-Reply-To: <MKOPt7rHfUgCNG6jb9ZrdSXpDGIx9nCdgn_fdlXK0HQ=.1d0f5117-2ca8-4761-a10b-d2c22e2afdf6@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <jPkoZCShs1oyBRYLRaXDWQwNeVZC-SoDRDa36kTjMeg=.3b17b331-7817-4528-8e45-4957c2315829@github.com>
 <MKOPt7rHfUgCNG6jb9ZrdSXpDGIx9nCdgn_fdlXK0HQ=.1d0f5117-2ca8-4761-a10b-d2c22e2afdf6@github.com>
Message-ID: <fYT0w_SlJjMaStDmuOTmAgb_fjUF59I7a8qDxdyl838=.bcaeb567-18bf-43a4-9ff8-b80c7f44f93e@github.com>

On Thu, 18 May 2023 18:23:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge
>>  - 8308016: Reinstate @snippet for RandomAccessFile::readLong
>>  - 8308016: Reduce linking in File::toPath snippet
>>  - 8308016: Fix link in snippet of File::toPath
>>  - 8308016: Address reviewer comments since previous commit
>>  - 8308016: Remove ellipses ("...") from snippets
>>  - 8308016: Use snippets in java.io package
>
> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 284:
> 
>> 282:      * array such that:
>> 283:      * {@snippet lang=java :
>> 284:      *         c == (char)(((hibyte & 0xff) << 8) | (b & 0xff))
> 
> I'd skip the extra indentation for just the single line example.

So changed in b6abb2e40fe574f40ebdfc0c5b1e28ed4b09126e.

> src/java.base/share/classes/java/io/CharArrayWriter.java line 189:
> 
>> 187:      *
>> 188:      * {@snippet lang=java :
>> 189:      *     out.write(csq.subSequence(start, end).toString())
> 
> a trailing ";' would be useful for copy/paste; butr that's not the existing style.  Your call.

These statements in general do not have a trailing `;`; left unchanged.

> src/java.base/share/classes/java/io/Console.java line 125:
> 
>> 123:      *             Scanner sc = new Scanner(con.reader());
>> 124:      *             code: // @replace substring="code:" replacement="..."
>> 125:      *         }
> 
> 4 space indentation would be enough.

So changed in b6abb2e40fe574f40ebdfc0c5b1e28ed4b09126e.

> src/java.base/share/classes/java/io/RandomAccessFile.java line 762:
> 
>> 760:      * then the result is:
>> 761:      * {@snippet lang=java :
>> 762:      *         (byte)(b)
> 
> 4 space indent is sufficient in this file

So changed in b6abb2e40fe574f40ebdfc0c5b1e28ed4b09126e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198203067
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198203673
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198204033
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198203822

From mbalao at openjdk.org  Thu May 18 19:30:57 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 18 May 2023 19:30:57 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v2]
In-Reply-To: <9-eGBQs-MoQ0PUC2i1M5dCkr2KdmftuVd3qrpuyaMzs=.18aea3e5-38b0-4c2c-9303-a2c9adfc3e57@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <7CAUW1aHjrYSDR2wg0tigIApQDNNta3TCjwR_5D1dxA=.51cdb2c0-61f9-4945-8c93-86fe54327c2b@github.com>
 <9-eGBQs-MoQ0PUC2i1M5dCkr2KdmftuVd3qrpuyaMzs=.18aea3e5-38b0-4c2c-9303-a2c9adfc3e57@github.com>
Message-ID: <n4kNaIs1bKNMk6k2_IsIEissHZGp3P_7INtpa--xuD4=.2097e8e7-a8e0-4ad4-a063-3de4aeb6d165@github.com>

On Tue, 16 May 2023 23:42:08 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/java.base/share/classes/sun/security/util/PBEUtil.java line 62:
> 
>> 60:      * IvParameterSpec).
>> 61:      */
>> 62:     public final static class PBES2Params {
> 
> nit; static final?

Good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198223925

From mbalao at openjdk.org  Thu May 18 19:48:04 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 18 May 2023 19:48:04 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
Message-ID: <f2Yw_44VLNBrsjEgaI8QHBLtDv8nLBEFKaCC30Q86n4=.28bba90e-9973-40b1-8f42-a06f05c6a267@github.com>

On Wed, 17 May 2023 18:44:08 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao 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:
>> 
>>  - Rebase fix after JDK-8306033. Replace called functions with their new names.
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java line 115:
> 
>> 113:         try {
>> 114:             derivedKey = PKCS12PBECipherCore.derive(
>> 115:                     keySpec.getPassword(), keySpec.getSalt(),
> 
> Comparing to the original impl, this new call of keySpec.getPassword() produces extra copy of password which needs to be cleared as well.

Good. We have some doubts about the effectiveness of this but we will clear them anyways.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198237296

From mbalao at openjdk.org  Thu May 18 20:10:10 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 18 May 2023 20:10:10 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
Message-ID: <QxTjp0i171upiuC6pf446VzggQpbqUruRkbT7DU9yOk=.030abeb4-752f-472b-b8f2-a209866ea762@github.com>

On Wed, 17 May 2023 18:45:06 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao 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:
>> 
>>  - Rebase fix after JDK-8306033. Replace called functions with their new names.
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java line 121:
> 
>> 119:             keySpec.clearPassword();
>> 120:         }
>> 121:         SecretKey cipherKey = new SecretKeySpec(derivedKey, "HmacSHA1");
> 
> Can clear out the "derivedKey" bytes if no longer needed.

Good

> src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java line 165:
> 
>> 163:         byte[] derivedKey = s.getEncoded();
>> 164:         s.clearPassword();
>> 165:         SecretKeySpec cipherKey = new SecretKeySpec(derivedKey, cipherAlgo);
> 
> Clear out the "derivedKey" bytes if no longer needed.

Good

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 345:
> 
>> 343:                 throw new InvalidKeyException("Encoded format must be RAW");
>> 344:             }
>> 345:             byte[] encoded = key.getEncoded();
> 
> Would be nice to clear out "encoded" bytes afterwards.

Good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198250758
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198254721
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198256947

From mbalao at openjdk.org  Thu May 18 20:16:01 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 18 May 2023 20:16:01 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
Message-ID: <5ZXXd3HjHKBKX3vWtUqfOnx14lF3nRwKWZW3McXD3Tg=.965da1b5-580f-4a1a-b2d0-2e4df6a0f563@github.com>

On Wed, 17 May 2023 18:57:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Rebase fix after JDK-8306033. Replace called functions with their new names.
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 362:
> 
>> 360:             session = token.getObjSession();
>> 361:             CK_MECHANISM ckMech;
>> 362:             char[] password = keySpec.getPassword();
> 
> Should clear out "password" afterwards.

Good

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 391:
> 
>> 389:             }
>> 390: 
>> 391:             char[] encPassword;
> 
> Same, clear out "encPassword" afterwards.

Good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198258848
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198260824

From mbalao at openjdk.org  Thu May 18 20:30:58 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 18 May 2023 20:30:58 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
Message-ID: <dbWHq29dMV81QGCTRnJABfv55eFtW8aWs6iPtcMlj9c=.6d552a4a-7f29-4c24-b57b-38297adaac2a@github.com>

On Wed, 17 May 2023 19:00:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Rebase fix after JDK-8306033. Replace called functions with their new names.
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 444:
> 
>> 442:         int keyLength = 0;
>> 443:         if ("RAW".equalsIgnoreCase(pbeKey.getFormat())) {
>> 444:             byte[] encoded = pbeKey.getEncoded();
> 
> Should clear out "encoded" afterwards.

Good

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 450:
> 
>> 448:         }
>> 449:         int ic = pbeKey.getIterationCount();
>> 450:         char[] pwd = pbeKey.getPassword();
> 
> Should clear out "pwd" afterwards.

Good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198271443
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198273022

From mullan at openjdk.org  Thu May 18 21:22:51 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 18 May 2023 21:22:51 GMT
Subject: RFR: 8308010: X509Key and PKCS8Key allows garbage bytes at the end
 [v2]
In-Reply-To: <IYMIONVS6yeb-fdyA0Aqfdqh2GW2N58E8-s2Jr5DeJs=.5aec563e-497c-4117-8cd3-a26af46f67c7@github.com>
References: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>
 <IYMIONVS6yeb-fdyA0Aqfdqh2GW2N58E8-s2Jr5DeJs=.5aec563e-497c-4117-8cd3-a26af46f67c7@github.com>
Message-ID: <VU_kCyzSCP7DVjBlGzNnzt44pU7s319Aalb3kDr3hzE=.e1fdde16-7fb0-4237-aa80-79c169d83900@github.com>

On Thu, 18 May 2023 14:48:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add reasons

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13958#pullrequestreview-1433473416

From weijun at openjdk.org  Thu May 18 21:27:02 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 18 May 2023 21:27:02 GMT
Subject: Integrated: 8308010: X509Key and PKCS8Key allows garbage bytes at the
 end
In-Reply-To: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>
References: <xi120S2nnbATMCpmZG8ml1pZlwqreHbjGZ9yVaLiiT8=.973c260e-3e5d-4034-8cb3-2067ce6a1dae@github.com>
Message-ID: <bhyz-cpHjv714FOuzPSObYvlpB7XWxUYx8VqLvb2qDk=.4a93d4e3-dfe6-4fd7-bcfb-5dd355c763ab@github.com>

On Fri, 12 May 2023 16:23:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> When parsing a byte array to a private or public key, it's now converted to a `ByteArrayInputStream` and the parser does not report an error if there are extra bytes at the end.

This pull request has now been integrated.

Changeset: 148df533
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/148df533af618a959ca2f3601d9ab897c3515d77
Stats:     86 lines in 3 files changed: 60 ins; 13 del; 13 mod

8308010: X509Key and PKCS8Key allows garbage bytes at the end

Reviewed-by: mullan

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

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

From wetmore at openjdk.org  Thu May 18 21:56:54 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 18 May 2023 21:56:54 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v13]
In-Reply-To: <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
Message-ID: <O_SxZ7ZCkdTZfoBgzoWeMDLm4js44mhrWseOSnqRIZE=.9862107d-e53a-4e04-8a34-5faf006b02d5@github.com>

On Thu, 18 May 2023 17:49:07 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   all review comments applied

src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 385:

> 383:             X509ExtendedKeyManager km = chc.sslContext.getX509KeyManager();
> 384:             String clientAlias = null;
> 385: 

Many of these lines are > 80 chars, which makes side-by-side challenging.  Please keep line changes to a max of 80 chars.

Didn't check the other file, but think I saw similar things there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198340417

From kdriver at openjdk.org  Thu May 18 22:05:57 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 22:05:57 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v13]
In-Reply-To: <O_SxZ7ZCkdTZfoBgzoWeMDLm4js44mhrWseOSnqRIZE=.9862107d-e53a-4e04-8a34-5faf006b02d5@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
 <O_SxZ7ZCkdTZfoBgzoWeMDLm4js44mhrWseOSnqRIZE=.9862107d-e53a-4e04-8a34-5faf006b02d5@github.com>
Message-ID: <ARt9xch3vOJV5Oye1gsRzmRcsKJMVvFIJjt6f9xKAJ0=.be2b7532-2093-4f0d-b391-dacf5894067f@github.com>

On Thu, 18 May 2023 21:52:37 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   all review comments applied
>
> src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 385:
> 
>> 383:             X509ExtendedKeyManager km = chc.sslContext.getX509KeyManager();
>> 384:             String clientAlias = null;
>> 385: 
> 
> Many of these lines are > 80 chars, which makes side-by-side challenging.  Please keep line changes to a max of 80 chars.
> 
> Didn't check the other file, but think I saw similar things there.

This might be something on your end @bradfordwetmore. I opened this in my IDE and went to the end of the line... It was right under the "String clientAlias" capital "S".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198346964

From kdriver at openjdk.org  Thu May 18 22:05:58 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 22:05:58 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v13]
In-Reply-To: <ARt9xch3vOJV5Oye1gsRzmRcsKJMVvFIJjt6f9xKAJ0=.be2b7532-2093-4f0d-b391-dacf5894067f@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
 <O_SxZ7ZCkdTZfoBgzoWeMDLm4js44mhrWseOSnqRIZE=.9862107d-e53a-4e04-8a34-5faf006b02d5@github.com>
 <ARt9xch3vOJV5Oye1gsRzmRcsKJMVvFIJjt6f9xKAJ0=.be2b7532-2093-4f0d-b391-dacf5894067f@github.com>
Message-ID: <QN5RVfD4zQu6CT-VdJWPLu2iaWknEps7z-pW729VHII=.b28475be-f86c-4a3e-b422-3d9325f9a684@github.com>

On Thu, 18 May 2023 22:00:35 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line 385:
>> 
>>> 383:             X509ExtendedKeyManager km = chc.sslContext.getX509KeyManager();
>>> 384:             String clientAlias = null;
>>> 385: 
>> 
>> Many of these lines are > 80 chars, which makes side-by-side challenging.  Please keep line changes to a max of 80 chars.
>> 
>> Didn't check the other file, but think I saw similar things there.
>
> This might be something on your end @bradfordwetmore. I opened this in my IDE and went to the end of the line... It was right under the "String clientAlias" capital "S".

<img width="174" alt="image" src="https://github.com/openjdk/jdk/assets/1783591/c549e612-5ec7-47ce-add5-828cf79c31d9">

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198348358

From wetmore at openjdk.org  Thu May 18 22:36:00 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 18 May 2023 22:36:00 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v13]
In-Reply-To: <QN5RVfD4zQu6CT-VdJWPLu2iaWknEps7z-pW729VHII=.b28475be-f86c-4a3e-b422-3d9325f9a684@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
 <O_SxZ7ZCkdTZfoBgzoWeMDLm4js44mhrWseOSnqRIZE=.9862107d-e53a-4e04-8a34-5faf006b02d5@github.com>
 <ARt9xch3vOJV5Oye1gsRzmRcsKJMVvFIJjt6f9xKAJ0=.be2b7532-2093-4f0d-b391-dacf5894067f@github.com>
 <QN5RVfD4zQu6CT-VdJWPLu2iaWknEps7z-pW729VHII=.b28475be-f86c-4a3e-b422-3d9325f9a684@github.com>
Message-ID: <j9mz46o2d3gNmquOMIigy32RxlJOGF-9YAPUldZRrGs=.3998b629-6538-42ca-aad6-75ec3d6ed214@github.com>

On Thu, 18 May 2023 22:02:55 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> This might be something on your end @bradfordwetmore. I opened this in my IDE and went to the end of the line... It was right under the "String clientAlias" capital "S".
>
> <img width="174" alt="image" src="https://github.com/openjdk/jdk/assets/1783591/c549e612-5ec7-47ce-add5-828cf79c31d9">

Slacked with Kevin and pointed out locations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198365130

From kdriver at openjdk.org  Thu May 18 23:28:24 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 18 May 2023 23:28:24 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v14]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <1P2PoVtr4zPioOQlOvqA5MRRIbmUFjINHBUdJLGlft8=.36819598-528f-4008-8792-d3477d80a669@github.com>

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

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

  whitespace adjustments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/335fb052..cae5e1bc

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

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

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

From wetmore at openjdk.org  Fri May 19 00:07:55 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 19 May 2023 00:07:55 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v13]
In-Reply-To: <j9mz46o2d3gNmquOMIigy32RxlJOGF-9YAPUldZRrGs=.3998b629-6538-42ca-aad6-75ec3d6ed214@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <EHTHG2AuCgQpFIcv6wAul6Z81VKkNbeGcd8Gpv2-XM0=.fc9c4ed9-4535-4298-9f41-3f4c6561cf8a@github.com>
 <O_SxZ7ZCkdTZfoBgzoWeMDLm4js44mhrWseOSnqRIZE=.9862107d-e53a-4e04-8a34-5faf006b02d5@github.com>
 <ARt9xch3vOJV5Oye1gsRzmRcsKJMVvFIJjt6f9xKAJ0=.be2b7532-2093-4f0d-b391-dacf5894067f@github.com>
 <QN5RVfD4zQu6CT-VdJWPLu2iaWknEps7z-pW729VHII=.b28475be-f86c-4a3e-b422-3d9325f9a684@github.com>
 <j9mz46o2d3gNmquOMIigy32RxlJOGF-9YAPUldZRrGs=.3998b629-6538-42ca-aad6-75ec3d6ed214@github.com>
Message-ID: <nLKR_aFIep4LZPwPhxCoB8qDxxUv5J_EztoW10_HKFg=.9e4ec928-6fe8-4a32-b4e2-75411382e690@github.com>

On Thu, 18 May 2023 22:33:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> <img width="174" alt="image" src="https://github.com/openjdk/jdk/assets/1783591/c549e612-5ec7-47ce-add5-828cf79c31d9">
>
> Slacked with Kevin and pointed out locations.

Slacked with Kevin and resolved my concern.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1198406416

From wetmore at openjdk.org  Fri May 19 00:41:58 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 19 May 2023 00:41:58 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v14]
In-Reply-To: <1P2PoVtr4zPioOQlOvqA5MRRIbmUFjINHBUdJLGlft8=.36819598-528f-4008-8792-d3477d80a669@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <1P2PoVtr4zPioOQlOvqA5MRRIbmUFjINHBUdJLGlft8=.36819598-528f-4008-8792-d3477d80a669@github.com>
Message-ID: <zNuajvQFQXT40nAb9P4dHxm8fTBNRB0G3OgEY9-GI-8=.df286e35-1969-494b-95b2-26c7d2f57a4e@github.com>

On Thu, 18 May 2023 23:28:24 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace adjustments

New code LGTM, minus the one outstanding test issue.  Pending that, I can sponsor.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1433626170

From mbalao at openjdk.org  Fri May 19 02:22:05 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 19 May 2023 02:22:05 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <5ZXXd3HjHKBKX3vWtUqfOnx14lF3nRwKWZW3McXD3Tg=.965da1b5-580f-4a1a-b2d0-2e4df6a0f563@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
 <5ZXXd3HjHKBKX3vWtUqfOnx14lF3nRwKWZW3McXD3Tg=.965da1b5-580f-4a1a-b2d0-2e4df6a0f563@github.com>
Message-ID: <Pai2nWI88k0FxiXgwT1a3chm0_Zcp9hTH1KOvrHdTiQ=.449fc49b-1949-4323-ba89-5005a4ad378d@github.com>

On Thu, 18 May 2023 20:10:04 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 362:
>> 
>>> 360:             session = token.getObjSession();
>>> 361:             CK_MECHANISM ckMech;
>>> 362:             char[] password = keySpec.getPassword();
>> 
>> Should clear out "password" afterwards.
>
> Good

I've just noticed that in this case in particular we can clean it up here but we need to save a copy in P11PBEKey because if the key has to be transferred to a different P11 token, we need to re-derive from the password, salt and iteration count. This case would happen for example if you have a P11 key from one token and you want to use it in a P11 service from a different token. Code is in P11SecretKeyFactory::convertKey. For safety, I'll clone the password in the P11PBEKey constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1198481207

From vlivanov at openjdk.org  Fri May 19 04:10:00 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 19 May 2023 04:10:00 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v13]
In-Reply-To: <Yx1OcjTUO1iQV7ibbT71njBcVZz7-bJsYBRN6Iom94I=.e6657a24-5a0e-4e15-9229-8ef2b49a7fef@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <Yx1OcjTUO1iQV7ibbT71njBcVZz7-bJsYBRN6Iom94I=.e6657a24-5a0e-4e15-9229-8ef2b49a7fef@github.com>
Message-ID: <QUC45ZUDN81px7FNYS6xD_Ab9QUaltXctjSNQiUF-JM=.f562109a-036a-4ba1-8f97-9b6bacfad5d4@github.com>

On Fri, 12 May 2023 21:09:01 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Can I please get reviews for this PR? 
>> 
>> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
>> 
>> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
>> 
>> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
>> 
>> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
>> 
>> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
>> 
>> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges.
>> 
>> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
>> 
>> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR review 5: refactor on rematerialization & add tests.

Very nice, Cesar. I like how the code shapes now.

I verified that the new test cases do trigger SR+NSR scenario. 

How do you test that deoptimization works as expected? 

Diagnostic output is still hard to read. On one hand, it's too verbose when it comes to PcDesc/ScopeDesc sections  ("pc-bytecode offsets" and "scopes")  in nmethod output (enabled either w/ `-XX:+PrintAssembly` or `-XX:CompileCommand=print,...`). On the other hand, it lacks some important details, like `selector` and `merge_ptr` location information which is essential to make sense of debug information at a safepoint in the code.

FTR `_skip_rematerialization` flag is unused now.

Speaking of `_only_merge_candidate` flag, I find it easier about the code when the property being tracked is whether the `ObjectValue` is referenced from corresponding JVM state or not. (Maybe call it `is_root()`?) So, `ScopeDesc::objects_to_rematerialize()` would skip everything not referenced from JVM state, but then unconditionally accept anything returned by `ObjectMergeValue::select()` which doesn't need to adjust the flag before returning selected object. Also, it's safer to track the flag status for every `ObjectValues`, even for `ObjectMergeValue`. 

Are you sure there's no way to end up with nested `ObjectMergeValue`s in presence of iterative EA?

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1553966589

From jpai at openjdk.org  Fri May 19 05:18:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 May 2023 05:18:50 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <Exw7vHSSx1vZBRx6gEBLZoeMu_ttiiGWbOFZAKtHK38=.485a27a9-2d3d-4b8a-850c-fa1f928880d8@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

These changes look fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1433788568

From shade at openjdk.org  Fri May 19 06:57:10 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 19 May 2023 06:57:10 GMT
Subject: RFR: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey [v2]
In-Reply-To: <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
 <nZf4D6TtcjmtS895djtM25CUzSD5vKBlqJTBEpPin8Q=.703d2b54-fc40-4bc2-a6c9-b7ea402c1a45@github.com>
Message-ID: <OWS0kR3Ow3SHdowI2lAsyvQwpIp0XHX8_pV83bQCR2I=.64ad248e-45a7-4a51-9794-2cb95c6c0675@github.com>

On Tue, 16 May 2023 09:18:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there.
>> 
>> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely.
>> 
>> Example original profile is in the bug.
>> 
>> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns.
>> 
>> On new benchmark:
>> 
>> 
>> Benchmark       Mode  Cnt    Score   Error  Units
>> 
>> ## Mac M1
>> 
>> # Before
>> AESReinit.test  avgt   15   873,842 ? 6,911  ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   347,632 ? 8,764  ns/op  ; <--- 2.5x faster
>> 
>> ## Xeon, c6.8xlarge
>> 
>> # Before
>> AESReinit.test  avgt   15  1524.307 ? 24.231 ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   554.727 ? 12.876 ns/op  ; <--- 2.75x faster
>> 
>> ## Graviton, m6g.4xlarge
>> 
>> # Before
>> AESReinit.test  avgt   15  1913.492 ? 23.489 ns/op
>> 
>> # After
>> AESReinit.test  avgt   15   639.701 ? 5.033  ns/op  ; <--- 2.99x faster
>> 
>> 
>> Additional testing:
>>  - [x] Benchmarks
>>  - [x] macos-aarch64-server-release, `jdk_security`
>>  - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3`
>
> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Micro-optimizations
>  - Handle Kd
>  - Handle Ke

Rechecked `jdk_security`, passes. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/13996#issuecomment-1554093536

From shade at openjdk.org  Fri May 19 06:57:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 19 May 2023 06:57:12 GMT
Subject: Integrated: 8308118: Avoid multiarray allocations in
 AESCrypt.makeSessionKey
In-Reply-To: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
References: <zJozhi047URNijDphGDqosuxBMIc_ARr6PjQ2thaKfs=.4a284c65-f451-4d7a-a409-1b26e89a0ea0@github.com>
Message-ID: <BxHuWBz0FsSynfE5_lWPIlzwEQPrHD-r55jVCGOhTE8=.9972d0fe-b1a8-4771-b19f-b7d4532789c1@github.com>

On Mon, 15 May 2023 19:59:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> One of our services has a hot path with AES/GCM cipher reuse. The JDK code reinitializes the session key on that path, and [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) shows up prominently there.
> 
> Fixing [JDK-8308105](https://bugs.openjdk.org/browse/JDK-8308105) would take a while, as would likely require multiple patches in VM internals. Meanwhile, we can avoid the multiarray allocations in AESCrypt.makeSessionKey completely, reaping performance benefits. We can go even deeper: replace the multi-array with the flat array and drop `expandToSubKey` completely.
> 
> Example original profile is in the bug.
> 
> There are other things we can polish in that code, but experiments show those polishings have rather diminshed returns.
> 
> On new benchmark:
> 
> 
> Benchmark       Mode  Cnt    Score   Error  Units
> 
> ## Mac M1
> 
> # Before
> AESReinit.test  avgt   15   873,842 ? 6,911  ns/op
> 
> # After
> AESReinit.test  avgt   15   347,632 ? 8,764  ns/op  ; <--- 2.5x faster
> 
> ## Xeon, c6.8xlarge
> 
> # Before
> AESReinit.test  avgt   15  1524.307 ? 24.231 ns/op
> 
> # After
> AESReinit.test  avgt   15   554.727 ? 12.876 ns/op  ; <--- 2.75x faster
> 
> ## Graviton, m6g.4xlarge
> 
> # Before
> AESReinit.test  avgt   15  1913.492 ? 23.489 ns/op
> 
> # After
> AESReinit.test  avgt   15   639.701 ? 5.033  ns/op  ; <--- 2.99x faster
> 
> 
> Additional testing:
>  - [x] Benchmarks
>  - [x] macos-aarch64-server-release, `jdk_security`
>  - [x] linux-x86_64-server-fastdebug, `tier1 tier2 tier3`

This pull request has now been integrated.

Changeset: 67657610
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6765761075361459f764f4f17a52ac6ecbe67f4e
Stats:     133 lines in 2 files changed: 78 ins; 38 del; 17 mod

8308118: Avoid multiarray allocations in AESCrypt.makeSessionKey

Reviewed-by: xuelei

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

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

From djelinski at openjdk.org  Fri May 19 07:33:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 May 2023 07:33:52 GMT
Subject: RFR: 8301686: TLS 1.3 handshake fails if server_name doesn't match
 resuming session [v2]
In-Reply-To: <EiV-EIgnQQUQj5XlZM4wm7k3hMsq-8a3yh54lzMLE6g=.2ca17327-6fd8-40ee-8231-06ac0a74b1d9@github.com>
References: <PeY1YjSnfIMjs-RT5W61EWfQMQD_PkuEiLqYznPvClE=.f15e7870-2286-42a0-bde0-ab17efadb4ec@github.com>
 <EiV-EIgnQQUQj5XlZM4wm7k3hMsq-8a3yh54lzMLE6g=.2ca17327-6fd8-40ee-8231-06ac0a74b1d9@github.com>
Message-ID: <kEesGGOCo7zSM8ho8h_1B_mMseBs0lfXyAk8SDnqTng=.b063d23e-95cf-428e-a323-76d236bfc02d@github.com>

On Wed, 26 Apr 2023 11:51:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8301686?
>> 
>> The internal implementation of SSLContext caches SSLSession(s). These sessions are for a particular combination or peer host and port. When a TLS handshake completes successfully, the session is then stored in this cache. If/when subsequent handshake attempts against the same host/port combination happens, using this same SSLContext instance, then the internal implementation triggers a session resumption, which is allowed by the TLS RFC. During session resumption, the client then uses the pre-shared key from the previous successful handshake and sends it as part of the `ClientHello` message. 
>> 
>> One other part of the TLS handshake is the `server_name` extension. The client sends a `SNI` in the handshake which the server side can either reject or accept. To facilitate this matching on the server side, the `javax.net.ssl.SNIMatcher` can be configured on the (server side) `SSLParameters`. Setting of `SNIMatcher` is optional. 
>> 
>> If a successful handshake session (that was cached by the client) used a SNI name which the server accepted, then this SNI name is sent as part of the session resumption `ClientHello` along with the pre-shared key.  The current issue is that, during session resumption, on the server side, if the `SNIMatcher` is no longer present, then the server rightly aborts the session resumption, but still ends up sending the pre-shared key extension as part of the `ServerHello` message. The client, upon seeing this pre-shared key extension in the `ServerHello` considers that the session resumption succeeded and ends up using that pre-shared key to derive the early secret. On the server side though, the server has already rejected this resumption request and thus when the client next sends data, the server will no longer be able to decode the data and will fail with `javax.crypto.AEADBadTagException: Tag mismatch` as noted in the JBS issue.
>> 
>> The change in this PR, removes the pre-shared key extension data from the `ServerHello` message, when the server side notices that the session resumption is being aborted.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix. Existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment - use SSLContextTemplate for SSLContext creation in test

The changes look fine to me.

On a side note, TLS 1.3 spec permits resuming sessions with a different server_name:
https://www.rfc-editor.org/rfc/rfc8446.html#page-57

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13669#pullrequestreview-1433925085

From clanger at openjdk.org  Fri May 19 09:15:49 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 19 May 2023 09:15:49 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v3]
In-Reply-To: <2dBwm9ZtkuIaWeJdSnE-_rZdaGxLowoeuT77pdXrM_U=.10eefa2c-be1c-4b78-878a-e9bd73d7ca5c@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <i-XdISCD44_PS9sbXqjXuErVdu1ei6TLkMAaPF3Y0Bg=.dc4b6f05-1fb7-4ed3-97a1-148aa02cdf83@github.com>
 <2dBwm9ZtkuIaWeJdSnE-_rZdaGxLowoeuT77pdXrM_U=.10eefa2c-be1c-4b78-878a-e9bd73d7ca5c@github.com>
Message-ID: <32RNMEoT0Ay7zwaTkvXnVUtAeGN5shOJ4jt9BwzLKzk=.15b1f857-0ab7-4007-8d82-127be21ddf54@github.com>

On Thu, 18 May 2023 00:00:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Before your new change, such a certificate is not trusted, because `SecTrustSettingsCopyTrustSettings` returns `errSecItemNotFound` so `jm_createTrustedCertEntry` is not called at all.
> 
> I am not sure if such a certificate is meant to be always trusted. Note that you can create such an entry with only `security add-certificates` but not `security add-trusted-cert`. macOS allows anyone to run the first command but prompts you for an administrator password when running the second. The name of the second command also implies that it's the only way to assign trust to a certificate, IMHO.

Hm, after thinking about this again and also comparing with behavior of curl, I think you're right. A self-signed certificate should only be trusted if it has a trust entry (e.g. added by `security add-trusted-cert`). Somehow I was under the impression that self-signed certificates should be trusted when they exist. But after reading comments etc. again I'm not sure why I thought so at all. ? Will update the PR...

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1554278565

From michaelm at openjdk.org  Fri May 19 11:26:52 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 19 May 2023 11:26:52 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <MIanutU-5zaHU08XWWykYRu2HSZhUfGSr70gu9SZ2ug=.77440635-04f7-4cbe-b573-a2322fed985b@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

Seems like a useful change and I can see how issues could arise if strings were stored somewhere after being upper/lower cased and then reused in a different locale. 

Is it correct to say that the assumption is these strings are all supposed to be US ASCII (eg protocol defined identifiers, or hostnames etc) rather than user generated text strings? That seems to be the case as far as I can see.

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

PR Comment: https://git.openjdk.org/jdk/pull/14006#issuecomment-1554431858

From michaelm at openjdk.org  Fri May 19 11:45:50 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 19 May 2023 11:45:50 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <lVPhG5xf1OqkUt02UdnjCSXVoF-H4KW_PGfrKQJ-Tto=.3980eaab-78e7-4ee4-8a62-6925757d9f9f@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

Marked as reviewed by michaelm (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1434277855

From clanger at openjdk.org  Fri May 19 12:02:27 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 19 May 2023 12:02:27 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v4]
In-Reply-To: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
Message-ID: <LVjK4hRhjRRMidnUjAu2kJTZNFiKg7166SxZeeQUVNA=.d4486c39-7059-4bfd-889a-5569954a74b6@github.com>

> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
> 
> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
> 
> This change does the following:
> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
> 
> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.

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

 - Do not trust self signed certificates without trust settings
 - Merge branch 'master' into JDK-8303465
 - Check return code of SecTrustSettingsCopyTrustSettings and address review comments
 - Add some more initializations to avoid crashes
 - JDK-8303465

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13945/files
  - new: https://git.openjdk.org/jdk/pull/13945/files/b14e5f2c..890e12bf

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

  Stats: 19714 lines in 628 files changed: 12808 ins; 2901 del; 4005 mod
  Patch: https://git.openjdk.org/jdk/pull/13945.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13945/head:pull/13945

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

From clanger at openjdk.org  Fri May 19 12:17:01 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 19 May 2023 12:17:01 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v5]
In-Reply-To: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
Message-ID: <B60ISZ-nHG96dVdx9CLtZDPmKP_bdYCTOdRIEeuiCS4=.313591fc-5d3c-446b-9e3c-1ee9aa97bde4@github.com>

> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
> 
> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
> 
> This change does the following:
> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
> 
> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Remove further unnecessary changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13945/files
  - new: https://git.openjdk.org/jdk/pull/13945/files/890e12bf..8085b901

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

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

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

From clanger at openjdk.org  Fri May 19 12:19:56 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 19 May 2023 12:19:56 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
Message-ID: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>

> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
> 
> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
> 
> This change does the following:
> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
> 
> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Remove another obsolete comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13945/files
  - new: https://git.openjdk.org/jdk/pull/13945/files/8085b901..023c9a76

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

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

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

From mdonovan at openjdk.org  Fri May 19 12:24:05 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 19 May 2023 12:24:05 GMT
Subject: RFR: 8301381: Verify DTLS 1.0 cannot be negotiated
Message-ID: <ccZIyB7cFz9rMdKPn0xmSjUO7zoyGGTn_ocCbbnitYg=.ad3b72f9-e5bf-499d-bca1-27f3ee241fc8@github.com>

This PR implements a test to verify that a DTLS server running "out of the box" (i.e., DTLSv1.0 disabled in java.security) will not handshake with a client requesting DTLSv1.0. The test also implements the opposite: a client won't handshake with a server that uses DTLSv1.0.

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

Commit messages:
 - 8301381: Verify DTLS 1.0 cannot be negotiated

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

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

From xuelei at openjdk.org  Fri May 19 14:26:51 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 19 May 2023 14:26:51 GMT
Subject: RFR: 8301381: Verify DTLS 1.0 cannot be negotiated
In-Reply-To: <ccZIyB7cFz9rMdKPn0xmSjUO7zoyGGTn_ocCbbnitYg=.ad3b72f9-e5bf-499d-bca1-27f3ee241fc8@github.com>
References: <ccZIyB7cFz9rMdKPn0xmSjUO7zoyGGTn_ocCbbnitYg=.ad3b72f9-e5bf-499d-bca1-27f3ee241fc8@github.com>
Message-ID: <GiIJyn2gk53FjNEXPzPYBGdDueSE0Ym17y2T_hF6mEU=.7bcf8754-7304-470b-8baf-f06dae6578e4@github.com>

On Fri, 19 May 2023 12:03:54 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR implements a test to verify that a DTLS server running "out of the box" (i.e., DTLSv1.0 disabled in java.security) will not handshake with a client requesting DTLSv1.0. The test also implements the opposite: a client won't handshake with a server that uses DTLSv1.0.

Marked as reviewed by xuelei (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14059#pullrequestreview-1434532784

From mpowers at openjdk.org  Fri May 19 16:59:58 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 19 May 2023 16:59:58 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2]
In-Reply-To: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
Message-ID: <ttNsYCz3wf2Eq0oxPwP-lGFmUGy0mFkEqGNv-CDOjV0=.bc4d2e52-d0d8-407d-b72d-5933c5cd648d@github.com>

> https://bugs.openjdk.org/browse/JDK-8307794

Mark Powers has updated the pull request incrementally with four additional commits since the last revision:

 - Ferenc: comments 2 and 4
 - oops
 - Sean's comments
 - added @run

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13940/files
  - new: https://git.openjdk.org/jdk/pull/13940/files/23349514..7598bc74

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

  Stats: 5043 lines in 3 files changed: 1202 ins; 1948 del; 1893 mod
  Patch: https://git.openjdk.org/jdk/pull/13940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940

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

From mullan at openjdk.org  Fri May 19 17:29:50 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 19 May 2023 17:29:50 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2 [v10]
In-Reply-To: <hte8KYWgCR3l8J9czArup-NF8clsbGkUSpNH26yELs8=.a156f962-1273-41b3-8651-9410f30ad30e@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
 <hte8KYWgCR3l8J9czArup-NF8clsbGkUSpNH26yELs8=.a156f962-1273-41b3-8651-9410f30ad30e@github.com>
Message-ID: <tHo9CswYcc3DrrCMtrOctvzRkUrDE8PhvgVn2ne3yns=.7a433eae-5df0-4040-a522-cd453d6d91b5@github.com>

On Thu, 18 May 2023 15:15:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Update XML Security for Java to 3.0.2. Some change to tests:
>> 
>> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported".
>> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test modifies policy should run in othervm mode
>   
>   only in patch2:
>   unchanged:

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13840#pullrequestreview-1434822801

From kdriver at openjdk.org  Fri May 19 17:49:07 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 19 May 2023 17:49:07 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v15]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com>

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

Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:

 - fix bug id in test header
 - reworked example into a jtreg test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/cae5e1bc..d4ffde32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=13-14

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

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

From weijun at openjdk.org  Fri May 19 17:50:05 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 19 May 2023 17:50:05 GMT
Subject: Integrated: 8305972: Update XML Security for Java to 3.0.2
In-Reply-To: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
References: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>
Message-ID: <7r1MCM8GgB2uQHqIgpONSfAIrM7AFIxzfuNC9lvwGwI=.175a34ba-2855-41ad-849b-ce3d5b2cae28@github.com>

On Fri, 5 May 2023 17:57:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Update XML Security for Java to 3.0.2. Some change to tests:
> 
> 1. A new `HereFunction.java` to test the new security property "jdk.xml.dsig.hereFunctionSupported".
> 2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

This pull request has now been integrated.

Changeset: f0aebc81
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0aebc8141de5a50c88658a40caa01967a9afc53
Stats:     1175 lines in 38 files changed: 922 ins; 142 del; 111 mod

8305972: Update XML Security for Java to 3.0.2

Reviewed-by: mullan

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

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

From kdriver at openjdk.org  Fri May 19 19:38:09 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 19 May 2023 19:38:09 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v16]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <b8xpkkyQVml33xi5rehfsgrkKM9zkW3UrrFYDiTcpls=.8e260859-4c34-4dd7-95c6-bd58e17f2d58@github.com>

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

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

  removing block that isn't reached

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/d4ffde32..40a35bc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=14-15

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

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

From mullan at openjdk.org  Fri May 19 19:41:11 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 19 May 2023 19:41:11 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v16]
In-Reply-To: <b8xpkkyQVml33xi5rehfsgrkKM9zkW3UrrFYDiTcpls=.8e260859-4c34-4dd7-95c6-bd58e17f2d58@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <b8xpkkyQVml33xi5rehfsgrkKM9zkW3UrrFYDiTcpls=.8e260859-4c34-4dd7-95c6-bd58e17f2d58@github.com>
Message-ID: <cTKnmfQqk0AoyFg-b165sYUQ0jqdXuQ6li-aKLOJqPY=.5d3f7722-d6b4-4b39-8be2-93cd12e5eecb@github.com>

On Fri, 19 May 2023 19:38:09 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing block that isn't reached

test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 28:

> 26:  * @bug 8164879
> 27:  * @library /test/lib
> 28:  * @summary test for proper exception handling

Suggest adding more details here, ex: "Check that an improperly encoded CA distinguished name causes a handshake failure"

test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 45:

> 43: 
> 44: 
> 45: public class Test8294985 {

I would avoid putting the bug number in the test name and use something more descriptive, like InvalidEncodedCaName.

test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 64:

> 62:             + "/../../../../javax/net/ssl/etc/keystore";
> 63: 
> 64:     private static byte[] payload = Base64.getDecoder().decode(

Can you add a comment as to what is in this payload?

test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 91:

> 89:         }
> 90: 
> 91:         System.out.println("payload len:" + payload.length);

Is this println necessary?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199282222
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199283420
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199283669
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199284615

From kdriver at openjdk.org  Fri May 19 19:53:03 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 19 May 2023 19:53:03 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v17]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <Xyj66Yyrzy0u6QkWlsLDL22zcNeqg0eqVN0NaYG5tDU=.f2a43569-14eb-42fd-bd11-1d1cf9b1bf67@github.com>

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

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

  rename class and remove bug id from test header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/40a35bc1..8b672b0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=15-16

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

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

From jnimeh at openjdk.org  Fri May 19 20:05:07 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 19 May 2023 20:05:07 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v3]
In-Reply-To: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
Message-ID: <1wyNJs2Z552P0pkJ_uryplhjWS6ewVranGl3VafKS74=.81eb5594-a17c-4cdd-93e4-396f84a1e78b@github.com>

> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
> 
> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
> 
> JBS: https://bugs.openjdk.org/browse/JDK-8179502
> CSR: https://bugs.openjdk.org/browse/JDK-8300722

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Add OCSP readtimeout property

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13762/files
  - new: https://git.openjdk.org/jdk/pull/13762/files/3c524e17..81c7cb35

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

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

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

From jnimeh at openjdk.org  Fri May 19 20:05:09 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Fri, 19 May 2023 20:05:09 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v2]
In-Reply-To: <AOzZHTAP9RRGAiofEiYyDagcjzWY-zx_dQ2iUyWlo_U=.ba035a6b-22d2-43ad-8b62-066534bf9e13@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <eE6l8nbMN9i-wFxmV-DcTAM3MVgueMpPCYERIvD2uYU=.e344d03a-cec9-4c47-bd47-befd98956206@github.com>
 <DsPdqVaxd3A3mHtndZGpuO1D7IQ-ldq1_lH_a0vvllg=.4147f3e2-75a9-4539-80bd-ba3a11df2d62@github.com>
 <r1UX9Iejl-Gszfjm6RxsL1rPh9RuV0n7bpRAt-8wiOE=.a8f85e29-11e5-4c2f-91d0-33e68a3debae@github.com>
 <AOzZHTAP9RRGAiofEiYyDagcjzWY-zx_dQ2iUyWlo_U=.ba035a6b-22d2-43ad-8b62-066534bf9e13@github.com>
Message-ID: <D91zsOjSRuohKUFs0HOuVF3rOIMOvL-Mt0UsZw94W8M=.a3148cff-ed49-4ea9-a6f3-9ed95a7962f5@github.com>

On Tue, 9 May 2023 15:56:02 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> Yes, I noticed that too.  I wasn't sure if we needed to make a change there.  I opted to leave well-enough alone since nobody was asking for it and it's one less property to keep track of.  All of these property sets end up with a max latency of connect-timeout + read-timeout, and by default they are set to the same values.  So in practice much of the time they are all 2x.
>> 
>> It's easy enough I think to make a separate property for `com.sun.security.ocsp.readtimeout` and then the existing `.timeout` property would be for connect timeouts (keeping in line with the other props).  I don't think it will introduce significant risk but I will highlight that in the CSR.
>
>> I think you should also apply the cert and CRL timeouts to the `LDAPCertStore` implementation, using the JNDI properties: `com.sun.jndi.ldap.connect.timeout` and `com.sun.jndi.ldap.read.timeout`.
> 
> I will look into this.

I've added the OCSP readtimeout property, seems to be working well.  As discussed offline we'll hold off on the LDAP changes for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1199323604

From mullan at openjdk.org  Fri May 19 20:15:53 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 19 May 2023 20:15:53 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2]
In-Reply-To: <ttNsYCz3wf2Eq0oxPwP-lGFmUGy0mFkEqGNv-CDOjV0=.bc4d2e52-d0d8-407d-b72d-5933c5cd648d@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <ttNsYCz3wf2Eq0oxPwP-lGFmUGy0mFkEqGNv-CDOjV0=.bc4d2e52-d0d8-407d-b72d-5933c5cd648d@github.com>
Message-ID: <nvV6x1hPXgkPE3RfaP1y7sPyL0w5PJyle2bA00fC1Wk=.d183dd39-d980-4fcd-a13f-13f50768463e@github.com>

On Fri, 19 May 2023 16:59:58 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> Mark Powers has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Ferenc: comments 2 and 4
>  - oops
>  - Sean's comments
>  - added @run

test/jdk/sun/security/provider/lms/TestLMS.java line 30:

> 28:  * @summary tests for HSS/LMS provider
> 29:  * @modules java.base/sun.security.util
> 30:  * @run testng/othervm TestLMS

Why is the test run with `testng`, can this just be `main/othervm`?

test/jdk/sun/security/tools/jarsigner/VerifyHSSLMSSignedJar.java line 29:

> 27:  * @summary verify JAR files signed with HSS/LMS
> 28:  * @library /test/lib
> 29:  * @run testng/othervm VerifyHSSLMSSignedJar

I don't see anything that is using testng in this test, can we just run as `main/othervm`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199329785
PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199322468

From wetmore at openjdk.org  Fri May 19 20:26:59 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 19 May 2023 20:26:59 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v15]
In-Reply-To: <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com>
Message-ID: <qGRei0ZSp5IvUz8L_7SyI8HpLBI0J1mRU5Q1myhbAgM=.38d7e710-a3fe-473c-a916-f72a17748eb3@github.com>

On Fri, 19 May 2023 17:49:07 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix bug id in test header
>  - reworked example into a jtreg test

Mostly nits here.  Take or leave...

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

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1435046400

From weijun at openjdk.org  Fri May 19 20:31:49 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 19 May 2023 20:31:49 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
Message-ID: <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com>

On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. No trust settings will be reported as "inputTrust" being null. If the certificate is trusted with no specific records, "inputTrust" will be an empty list.
>> 3. The Java Method to add a certificate now checks for "self signed" certificate not only by checking whether it was signed with its own key but it must also not be a root certificate that can be used to sign other certificates. This is done by inspecting the key usage extension.
>> 4. We now trust certificates that are either "real" self-signed certificates or certificates that have an explicit trust entry with no sub-records that would deny the certificate for any purpose.
>> 5. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove another obsolete comment

Since you removed the key usage checks, can you update the PR description please?

src/java.base/macosx/classes/apple/security/KeychainStore.java line 808:

> 806:             // Check whether a certificate with same alias already exists and is the same
> 807:             // If yes, we can return here - the existing entry must have the same
> 808:             // properties and trust settings

This is always true, right? I'm not sure how this could happen.

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1555202314
PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1199343595

From weijun at openjdk.org  Fri May 19 20:54:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 19 May 2023 20:54:57 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2]
In-Reply-To: <nvV6x1hPXgkPE3RfaP1y7sPyL0w5PJyle2bA00fC1Wk=.d183dd39-d980-4fcd-a13f-13f50768463e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <ttNsYCz3wf2Eq0oxPwP-lGFmUGy0mFkEqGNv-CDOjV0=.bc4d2e52-d0d8-407d-b72d-5933c5cd648d@github.com>
 <nvV6x1hPXgkPE3RfaP1y7sPyL0w5PJyle2bA00fC1Wk=.d183dd39-d980-4fcd-a13f-13f50768463e@github.com>
Message-ID: <RR3U_5dOre4RTs3AXK1zcMtUjxriEPXNoxLITCi31B0=.20d0ba94-bbba-440e-8bbe-adcc0cb4c80f@github.com>

On Fri, 19 May 2023 20:08:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Ferenc: comments 2 and 4
>>  - oops
>>  - Sean's comments
>>  - added @run
>
> test/jdk/sun/security/provider/lms/TestLMS.java line 30:
> 
>> 28:  * @summary tests for HSS/LMS provider
>> 29:  * @modules java.base/sun.security.util
>> 30:  * @run testng/othervm TestLMS
> 
> Why is the test run with `testng`, can this just be `main/othervm`?

I think there is even no need to use `othervm`. I see no system property modification or mutable static fields.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199390793

From mpowers at openjdk.org  Fri May 19 21:29:53 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 19 May 2023 21:29:53 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2]
In-Reply-To: <nvV6x1hPXgkPE3RfaP1y7sPyL0w5PJyle2bA00fC1Wk=.d183dd39-d980-4fcd-a13f-13f50768463e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <ttNsYCz3wf2Eq0oxPwP-lGFmUGy0mFkEqGNv-CDOjV0=.bc4d2e52-d0d8-407d-b72d-5933c5cd648d@github.com>
 <nvV6x1hPXgkPE3RfaP1y7sPyL0w5PJyle2bA00fC1Wk=.d183dd39-d980-4fcd-a13f-13f50768463e@github.com>
Message-ID: <q8lDgozBAN1rpwusmQhrUu6xit2iwbgJQgV2fspynLM=.e5a617fa-75e0-4bab-bb68-7b25836aee2f@github.com>

On Fri, 19 May 2023 19:58:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Ferenc: comments 2 and 4
>>  - oops
>>  - Sean's comments
>>  - added @run
>
> test/jdk/sun/security/tools/jarsigner/VerifyHSSLMSSignedJar.java line 29:
> 
>> 27:  * @summary verify JAR files signed with HSS/LMS
>> 28:  * @library /test/lib
>> 29:  * @run testng/othervm VerifyHSSLMSSignedJar
> 
> I don't see anything that is using testng in this test, can we just run as `main/othervm`?

You are right. Changed to `@run main VerifyHSSLMSSignedJar`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199416397

From mpowers at openjdk.org  Fri May 19 21:29:49 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 19 May 2023 21:29:49 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v2]
In-Reply-To: <RR3U_5dOre4RTs3AXK1zcMtUjxriEPXNoxLITCi31B0=.20d0ba94-bbba-440e-8bbe-adcc0cb4c80f@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <ttNsYCz3wf2Eq0oxPwP-lGFmUGy0mFkEqGNv-CDOjV0=.bc4d2e52-d0d8-407d-b72d-5933c5cd648d@github.com>
 <nvV6x1hPXgkPE3RfaP1y7sPyL0w5PJyle2bA00fC1Wk=.d183dd39-d980-4fcd-a13f-13f50768463e@github.com>
 <RR3U_5dOre4RTs3AXK1zcMtUjxriEPXNoxLITCi31B0=.20d0ba94-bbba-440e-8bbe-adcc0cb4c80f@github.com>
Message-ID: <RheHbRxtyEE5g8jDC9OFAlP76gmIGV8ENEA_rpXvTQs=.fa1461a7-bdfd-4e83-a6e7-a8d7bf005640@github.com>

On Fri, 19 May 2023 20:51:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/sun/security/provider/lms/TestLMS.java line 30:
>> 
>>> 28:  * @summary tests for HSS/LMS provider
>>> 29:  * @modules java.base/sun.security.util
>>> 30:  * @run testng/othervm TestLMS
>> 
>> Why is the test run with `testng`, can this just be `main/othervm`?
>
> I think there is even no need to use `othervm`. I see no system property modification or mutable static fields.

You are right. Changed to `@run main TestLMS`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1199416586

From mbalao at openjdk.org  Sat May 20 01:01:12 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 20 May 2023 01:01:12 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <QxTjp0i171upiuC6pf446VzggQpbqUruRkbT7DU9yOk=.030abeb4-752f-472b-b8f2-a209866ea762@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
 <QxTjp0i171upiuC6pf446VzggQpbqUruRkbT7DU9yOk=.030abeb4-752f-472b-b8f2-a209866ea762@github.com>
Message-ID: <w8oTRyHvL3artvfFP09WYJrvc9WBTff_7FFrnZZ3t7A=.04885848-0f22-4b0b-afda-54ed0cf4e3c3@github.com>

On Thu, 18 May 2023 20:07:37 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 345:
>> 
>>> 343:                 throw new InvalidKeyException("Encoded format must be RAW");
>>> 344:             }
>>> 345:             byte[] encoded = key.getEncoded();
>> 
>> Would be nice to clear out "encoded" bytes afterwards.
>
> Good

We discussed this change with @franferrax and have some concerns. The method Key::getEncoded does not document that a copy will be returned, and this would change the current behavior and affect non-PBE cases. In practical terms, it would mean that a key directly or indirectly converted to a P11Key would be destroyed if it does not return a clone in its getEncoded method. We suggest to make the caller responsible and keep the existing behavior. I.e.: if we call with a SecretKeySpec ?whose ::getEncoded returns a clone?, the caller will need to (optionally) clear the key. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1199513839

From mbalao at openjdk.org  Sat May 20 01:10:06 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 20 May 2023 01:10:06 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <Pai2nWI88k0FxiXgwT1a3chm0_Zcp9hTH1KOvrHdTiQ=.449fc49b-1949-4323-ba89-5005a4ad378d@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
 <5ZXXd3HjHKBKX3vWtUqfOnx14lF3nRwKWZW3McXD3Tg=.965da1b5-580f-4a1a-b2d0-2e4df6a0f563@github.com>
 <Pai2nWI88k0FxiXgwT1a3chm0_Zcp9hTH1KOvrHdTiQ=.449fc49b-1949-4323-ba89-5005a4ad378d@github.com>
Message-ID: <5vT8f4dDuNC0CGA8LxQLdu1xQfdV0wql-fUdDVSDHzk=.c6e09e8f-a0d2-4177-926f-7a79312b2819@github.com>

On Fri, 19 May 2023 02:19:00 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Good
>
> I've just noticed that in this case in particular we can clean it up here but we need to save a copy in P11PBEKey because if the key has to be transferred to a different P11 token, we need to re-derive from the password, salt and iteration count. This case would happen for example if you have a P11 key from one token and you want to use it in a P11 service from a different token. Code is in P11SecretKeyFactory::convertKey. For safety, I'll clone the password in the P11PBEKey constructor.

Update: we finally decided to do what I described in my previous comment but in those PBE MAC and Cipher cases in which we know that the key was derived for the same token than the service AND the key cannot be accessed from outside ?in other words, there are strong guarantees that the key won't need to be derived again?, we will clear the password.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1199514984

From mbalao at openjdk.org  Sat May 20 01:25:29 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 20 May 2023 01:25:29 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v4]
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <CQ3ewpagljjtXDXN-IWSEtyS2gDMQ7sXPHM7PjxD0O4=.8f6d702b-c2e6-42b5-b0c8-f41d57bc6a1d@github.com>

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) ...

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #2)
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12396/files
  - new: https://git.openjdk.org/jdk/pull/12396/files/cd48dc20..41b14723

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

  Stats: 253 lines in 13 files changed: 145 ins; 53 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/12396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12396/head:pull/12396

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

From mbalao at openjdk.org  Sat May 20 01:25:29 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 20 May 2023 01:25:29 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
Message-ID: <lMfCKixSxDIyaG1NML_FZIssxpsqsps8IkyS_o2CjWg=.a84231c6-2a54-4ead-92bb-9f09b7f0d9d2@github.com>

On Wed, 17 May 2023 19:08:26 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Rebase fix after JDK-8306033. Replace called functions with their new names.
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java line 562:
> 
>> 560:         } else if (algorithm.equalsIgnoreCase("DES")) {
>> 561:             if (keySpec instanceof DESKeySpec desKeySpec) {
>> 562:                 byte[] keyBytes = desKeySpec.getKey();
> 
> Would be nice to clear out "keyBytes" afterwards. Same goes for the other "keyBytes" in the same method.

Good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1199516764

From mbalao at openjdk.org  Sat May 20 01:25:29 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 20 May 2023 01:25:29 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
Message-ID: <rodHJ4q6YCe62mc7iMNTM1sX5rrxsxhSmPZzoFrCgz0=.aca62528-3ac4-4fad-8829-d8bf410254c6@github.com>

On Wed, 17 May 2023 03:11:54 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Rebase fix after JDK-8306033. Replace called functions with their new names.
>  - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - 8301553: Support Password-Based Cryptography in SunPKCS11
>    
>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>

We found several more cases of passwords and encoded keys not cleared that were addressed in out Iteration # 2 commit. These cases were both in Java and native code. We still have doubts about the effectiveness and need for these actions, but prefer to have the discussion on a different channel.

We also found that invalid keys (not starting with the name "PBE") passed to PBES2Core::engineInit or P11PBECipher::engineInit were being cleared and this could be unexpected to the caller. This is related to my comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1199513839). For these cases, we decided not to invoke ::getEncoded and not to clean. As said, we have concerns about these undocumented mutations to objects passed by argument.

No test regressions observed in jdk/com/sun/crypto/provider or jdk/sun/security/pkcs11.

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

PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1555410153

From ascarpino at openjdk.org  Sat May 20 02:13:11 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sat, 20 May 2023 02:13:11 GMT
Subject: RFR: 8305091: Change ChaCha20 cipher init behavior to match
 AES-GCM
In-Reply-To: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
Message-ID: <YgWiGmUK2icoZtCX43PU4NLPLodCr4L2ShX4Kr_nC1w=.42b13532-27ec-4a05-b6ab-6374cd08db30@github.com>

On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fixes an issue where the key/nonce reuse policy for SunJCE ChaCha20 and ChaCha20-Poly1305 was overly strict in enforcing no-reuse when the Cipher was in DECRYPT_MODE.  For decryption, this should be allowed and be consistent with the AES-GCM decryption initialization behavior.
> 
> - Issue: https://bugs.openjdk.org/browse/JDK-8305091
> - CSR: https://bugs.openjdk.org/browse/JDK-8305822

Marked as reviewed by ascarpino (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13428#pullrequestreview-1435312854

From clanger at openjdk.org  Sun May 21 21:32:59 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Sun, 21 May 2023 21:32:59 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
 <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com>
Message-ID: <x3saOo63TUqjPsoxhIZmRM1xp3rl2UfRa96iwfFLVj4=.a756a52c-5766-464f-acda-554dc8c07ddb@github.com>

On Fri, 19 May 2023 20:28:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Since you removed the key usage checks, can you update the PR description please?

Done.

> src/java.base/macosx/classes/apple/security/KeychainStore.java line 808:
> 
>> 806:             // Check whether a certificate with same alias already exists and is the same
>> 807:             // If yes, we can return here - the existing entry must have the same
>> 808:             // properties and trust settings
> 
> This is always true, right? I'm not sure how this could happen.

This handles the case, when a certificate is in both, the login (user) and system keychain.

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

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1556296651
PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1199830388

From duke at openjdk.org  Mon May 22 10:22:56 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 22 May 2023 10:22:56 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <MIanutU-5zaHU08XWWykYRu2HSZhUfGSr70gu9SZ2ug=.77440635-04f7-4cbe-b573-a2322fed985b@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
 <MIanutU-5zaHU08XWWykYRu2HSZhUfGSr70gu9SZ2ug=.77440635-04f7-4cbe-b573-a2322fed985b@github.com>
Message-ID: <_gCEzkKMiIQiTGFQMSmpM0E4xnXPig7RaUPT3tbZNts=.e904c7f1-cf98-4987-ad0f-861689b83078@github.com>

On Fri, 19 May 2023 11:24:30 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Seems like a useful change and I can see how issues could arise if strings were stored somewhere after being upper/lower cased and then reused in a different locale.
> 
> Is it correct to say that the assumption is these strings are all supposed to be US ASCII (eg protocol defined identifiers, or hostnames etc) rather than user generated text strings? That seems to be the case as far as I can see.

Yes

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

PR Comment: https://git.openjdk.org/jdk/pull/14006#issuecomment-1556955595

From duke at openjdk.org  Mon May 22 10:57:02 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 22 May 2023 10:57:02 GMT
Subject: Integrated: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <UAfznS1njzmi0P8cL1j0-1NSA3gF-qhhWRAmqgiK0qM=.d8f27bbc-31d2-4936-9e23-1b7570696181@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

This pull request has now been integrated.

Changeset: 05e99db4
Author:    Darragh Clarke <darraghclarke98 at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05e99db466e7ef5c26f089db772a21cb2ca62e93
Stats:     74 lines in 20 files changed: 14 ins; 0 del; 60 mod

7065228: To interpret case-insensitive string locale independently

Reviewed-by: dfuchs, naoto, djelinski, jpai, michaelm

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

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

From mdonovan at openjdk.org  Mon May 22 12:06:03 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 22 May 2023 12:06:03 GMT
Subject: Integrated: 8301381: Verify DTLS 1.0 cannot be negotiated
In-Reply-To: <ccZIyB7cFz9rMdKPn0xmSjUO7zoyGGTn_ocCbbnitYg=.ad3b72f9-e5bf-499d-bca1-27f3ee241fc8@github.com>
References: <ccZIyB7cFz9rMdKPn0xmSjUO7zoyGGTn_ocCbbnitYg=.ad3b72f9-e5bf-499d-bca1-27f3ee241fc8@github.com>
Message-ID: <mc-okVHTsNAX11vnZJ92anJ8hN9MjmrBfAuby9ZYmvw=.014f6a5e-6165-49e6-8d79-aa3989d52a7c@github.com>

On Fri, 19 May 2023 12:03:54 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR implements a test to verify that a DTLS server running "out of the box" (i.e., DTLSv1.0 disabled in java.security) will not handshake with a client requesting DTLSv1.0. The test also implements the opposite: a client won't handshake with a server that uses DTLSv1.0.

This pull request has now been integrated.

Changeset: 18e24464
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18e2446420d3376acaa2652d70474c2d3a85e2ac
Stats:     320 lines in 1 file changed: 320 ins; 0 del; 0 mod

8301381: Verify DTLS 1.0 cannot be negotiated

Reviewed-by: xuelei

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

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

From avu at openjdk.org  Mon May 22 14:21:56 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 22 May 2023 14:21:56 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <zpNLQSOrVJgeXGKdOj7HN7OzGZLg376AEB9rRUqOMok=.79d48b95-421c-40fc-b007-b6815f710413@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

I would suggest either disable warnings on per file basis or rewrite problematic code.  Disabling warnings per fragment of code makes it less readable.

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

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1557306893

From weijun at openjdk.org  Mon May 22 15:10:14 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 22 May 2023 15:10:14 GMT
Subject: RFR: 8308540: On Kerberos TGT referral, if krb5.conf is missing realm,
 bad exception message
Message-ID: <ap8nqgK6Odt7uHcbElh1oewPKPB90NaWvWcI_K5vBu8=.5f6503f5-078c-4d67-a867-36ecaba37e5d@github.com>

Add realm name to the exception message, and make it the primary exception (retry exception added suppressed).

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

Commit messages:
 - the fix

Changes: https://git.openjdk.org/jdk/pull/14086/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14086&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308540
  Stats: 62 lines in 3 files changed: 33 ins; 15 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14086.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14086/head:pull/14086

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

From mullan at openjdk.org  Mon May 22 16:02:54 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 22 May 2023 16:02:54 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v3]
In-Reply-To: <1wyNJs2Z552P0pkJ_uryplhjWS6ewVranGl3VafKS74=.81eb5594-a17c-4cdd-93e4-396f84a1e78b@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <1wyNJs2Z552P0pkJ_uryplhjWS6ewVranGl3VafKS74=.81eb5594-a17c-4cdd-93e4-396f84a1e78b@github.com>
Message-ID: <rrM_3ej0ZkjVvnGwGZ5NdiJUMuvKe2XT0mYoCPfoTS8=.96aa13f9-23e7-4661-997a-d4d224624b29@github.com>

On Fri, 19 May 2023 20:05:07 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
>> 
>> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
>> 
>> JBS: https://bugs.openjdk.org/browse/JDK-8179502
>> CSR: https://bugs.openjdk.org/browse/JDK-8300722
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add OCSP readtimeout property

src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 186:

> 184:         }
> 185: 
> 186:         String propVal = System.getProperty(prop, "").trim();

You should call `privilegedGetProperty` here instead of `System.getProperty` so the call is wrapped in `doPrivileged` when an SM is active.

src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 202:

> 200:         // Next check to make sure the string is built only from digits
> 201:         if (propVal.matches("^\\d+$")) {
> 202:             int timeout = Integer.parseInt(propVal);

Is this guaranteed never to throw `NumberFormatException`? It might be safer to catch it just in case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200714709
PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200716014

From jnimeh at openjdk.org  Mon May 22 16:10:59 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 22 May 2023 16:10:59 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v3]
In-Reply-To: <rrM_3ej0ZkjVvnGwGZ5NdiJUMuvKe2XT0mYoCPfoTS8=.96aa13f9-23e7-4661-997a-d4d224624b29@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <1wyNJs2Z552P0pkJ_uryplhjWS6ewVranGl3VafKS74=.81eb5594-a17c-4cdd-93e4-396f84a1e78b@github.com>
 <rrM_3ej0ZkjVvnGwGZ5NdiJUMuvKe2XT0mYoCPfoTS8=.96aa13f9-23e7-4661-997a-d4d224624b29@github.com>
Message-ID: <ESmJzKhFlpnBlawaZBstuNKDbCs1Ld8-HM2GwNv06ds=.8e3342bc-37ef-462e-bbc8-cef69193ea84@github.com>

On Mon, 22 May 2023 15:58:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add OCSP readtimeout property
>
> src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 186:
> 
>> 184:         }
>> 185: 
>> 186:         String propVal = System.getProperty(prop, "").trim();
> 
> You should call `privilegedGetProperty` here instead of `System.getProperty` so the call is wrapped in `doPrivileged` when an SM is active.

Good catch.  Will fix.

> src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 202:
> 
>> 200:         // Next check to make sure the string is built only from digits
>> 201:         if (propVal.matches("^\\d+$")) {
>> 202:             int timeout = Integer.parseInt(propVal);
> 
> Is this guaranteed never to throw `NumberFormatException`? It might be safer to catch it just in case.

I'll change this to catch NFE, but I'm pretty sure the pattern will only ever return on true if the string is comprised solely of digits from start to end - I could never get a string that would pass when it shouldn't.  But point taken, better safe than sorry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200729759
PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200728908

From aph at openjdk.org  Mon May 22 16:20:01 2023
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 22 May 2023 16:20:01 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics
Message-ID: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>

This provides a solid speedup of about 3-4x over the Java implementation.

I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time.

Benchmarks:


ThunderX (2, I think):

Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score         Error  Units
Poly1305DigestBench.updateBytes          64              thrpt    3  14078352.014 ? 4201407.966  ops/s
Poly1305DigestBench.updateBytes         256              thrpt    3   5154958.794 ? 1717146.980  ops/s
Poly1305DigestBench.updateBytes        1024              thrpt    3   1416563.273 ? 1311809.454  ops/s
Poly1305DigestBench.updateBytes       16384              thrpt    3     94059.570 ?    2913.021  ops/s
Poly1305DigestBench.updateBytes     1048576              thrpt    3      1441.024 ?     164.443  ops/s

Benchmark                        (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
Poly1305DigestBench.updateBytes          64              thrpt    3  4516486.795 ? 419624.224  ops/s
Poly1305DigestBench.updateBytes         256              thrpt    3  1228542.774 ? 202815.694  ops/s
Poly1305DigestBench.updateBytes        1024              thrpt    3   316051.912 ?  23066.449  ops/s
Poly1305DigestBench.updateBytes       16384              thrpt    3    20649.561 ?   1094.687  ops/s
Poly1305DigestBench.updateBytes     1048576              thrpt    3      310.564 ?     31.053  ops/s

Apple M1:

Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
Poly1305DigestBench.updateBytes          64              thrpt    3  33551968.946 ? 849843.905  ops/s
Poly1305DigestBench.updateBytes         256              thrpt    3   9911637.214 ?  63417.224  ops/s
Poly1305DigestBench.updateBytes        1024              thrpt    3   2604370.740 ?  29208.265  ops/s
Poly1305DigestBench.updateBytes       16384              thrpt    3    165183.633 ?   1975.998  ops/s
Poly1305DigestBench.updateBytes     1048576              thrpt    3      2587.132 ?     40.240  ops/s

Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
Poly1305DigestBench.updateBytes          64              thrpt    3  12373649.589 ? 184757.721  ops/s
Poly1305DigestBench.updateBytes         256              thrpt    3   3112536.605 ?  14436.410  ops/s
Poly1305DigestBench.updateBytes        1024              thrpt    3    777184.018 ?   8774.478  ops/s
Poly1305DigestBench.updateBytes       16384              thrpt    3     50224.072 ?     29.004  ops/s
Poly1305DigestBench.updateBytes     1048576              thrpt    3       776.229 ?      8.086  ops/s

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

Commit messages:
 - Test
 - Cleanup
 - Initial commit

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

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

From jnimeh at openjdk.org  Mon May 22 16:59:15 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 22 May 2023 16:59:15 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v4]
In-Reply-To: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
Message-ID: <d9-oOxpXmEeFrUemoFxD2i5UsUtTuozjnIuXo4xYLkk=.7de1d45a-309b-4be7-837d-0e79876a9de8@github.com>

> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
> 
> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
> 
> JBS: https://bugs.openjdk.org/browse/JDK-8179502
> CSR: https://bugs.openjdk.org/browse/JDK-8300722

Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:

  Use privilegedGetProperty, catch NFE following string match

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13762/files
  - new: https://git.openjdk.org/jdk/pull/13762/files/81c7cb35..e73818ef

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

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

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

From jnimeh at openjdk.org  Mon May 22 17:30:50 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 22 May 2023 17:30:50 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v2]
In-Reply-To: <DsPdqVaxd3A3mHtndZGpuO1D7IQ-ldq1_lH_a0vvllg=.4147f3e2-75a9-4539-80bd-ba3a11df2d62@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <eE6l8nbMN9i-wFxmV-DcTAM3MVgueMpPCYERIvD2uYU=.e344d03a-cec9-4c47-bd47-befd98956206@github.com>
 <DsPdqVaxd3A3mHtndZGpuO1D7IQ-ldq1_lH_a0vvllg=.4147f3e2-75a9-4539-80bd-ba3a11df2d62@github.com>
Message-ID: <sMENPzbMIZJzkVYEF3_Q8v3BQnwbI5T5E9-gc1Z6Gkc=.4e9a6848-04cf-4d10-bb25-6f300ad171ff@github.com>

On Tue, 9 May 2023 14:59:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add 's' suffix to allowed syntax
>
> I think you should also apply the cert and CRL timeouts to the `LDAPCertStore` implementation, using the JNDI properties: `com.sun.jndi.ldap.connect.timeout` and `com.sun.jndi.ldap.read.timeout`.

@seanjmullan if you have a chance would you mind taking a quick look at the release note for this change? (https://bugs.openjdk.org/browse/JDK-8308582)
It is pretty close to the CSR solution text, but I tried to trim it down a little.  It's still pretty long, but there's a lot to convey.

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

PR Comment: https://git.openjdk.org/jdk/pull/13762#issuecomment-1557618613

From mullan at openjdk.org  Mon May 22 17:37:53 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 22 May 2023 17:37:53 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v4]
In-Reply-To: <d9-oOxpXmEeFrUemoFxD2i5UsUtTuozjnIuXo4xYLkk=.7de1d45a-309b-4be7-837d-0e79876a9de8@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <d9-oOxpXmEeFrUemoFxD2i5UsUtTuozjnIuXo4xYLkk=.7de1d45a-309b-4be7-837d-0e79876a9de8@github.com>
Message-ID: <FoFPE_3mm0lPW7TSCeltW8Q3NKJAeLrN15zxKPw9LnI=.6339a6ce-4e60-4d60-b841-bcb7e2791746@github.com>

On Mon, 22 May 2023 16:59:15 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
>> 
>> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
>> 
>> JBS: https://bugs.openjdk.org/browse/JDK-8179502
>> CSR: https://bugs.openjdk.org/browse/JDK-8300722
>
> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use privilegedGetProperty, catch NFE following string match

src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 211:

> 209:                             " for timeout value " + propVal +
> 210:                             ". Using default value of " + def + " msec.");
> 211:                 }

This would also be useful debug for the else case on line 214-216 if the value is not an integer.

src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java line 131:

> 129:     private static final int DEFAULT_CRL_READ_TIMEOUT = 15000;
> 130: 
> 131:     // Default connect and read timeouts for CA certificate fetching (15 sec)

Does 15 seconds make sense as the default timeout, especially for certs? CRLs are generally larger than certs, so a longer read timeout makes sense.

I'm ok with keeping these default values the same for consistency, but I think we should re-evaluate each of these default timeouts and compare them to other products/technologies to see if some adjustments may be needed - can you file a follow-on RFE for that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200805069
PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200812030

From jnimeh at openjdk.org  Mon May 22 17:42:54 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 22 May 2023 17:42:54 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v4]
In-Reply-To: <FoFPE_3mm0lPW7TSCeltW8Q3NKJAeLrN15zxKPw9LnI=.6339a6ce-4e60-4d60-b841-bcb7e2791746@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <d9-oOxpXmEeFrUemoFxD2i5UsUtTuozjnIuXo4xYLkk=.7de1d45a-309b-4be7-837d-0e79876a9de8@github.com>
 <FoFPE_3mm0lPW7TSCeltW8Q3NKJAeLrN15zxKPw9LnI=.6339a6ce-4e60-4d60-b841-bcb7e2791746@github.com>
Message-ID: <vfWzS2qyQ1KwvLiMXxvjZEsmdUN5YVmEznd5kCnsVDc=.8f400cac-1fb1-42ee-9006-27448d4d1e9b@github.com>

On Mon, 22 May 2023 17:17:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use privilegedGetProperty, catch NFE following string match
>
> src/java.base/share/classes/sun/security/action/GetPropertyAction.java line 211:
> 
>> 209:                             " for timeout value " + propVal +
>> 210:                             ". Using default value of " + def + " msec.");
>> 211:                 }
> 
> This would also be useful debug for the else case on line 214-216 if the value is not an integer.

Sounds good, I can add that.

> src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java line 131:
> 
>> 129:     private static final int DEFAULT_CRL_READ_TIMEOUT = 15000;
>> 130: 
>> 131:     // Default connect and read timeouts for CA certificate fetching (15 sec)
> 
> Does 15 seconds make sense as the default timeout, especially for certs? CRLs are generally larger than certs, so a longer read timeout makes sense.
> 
> I'm ok with keeping these default values the same for consistency, but I think we should re-evaluate each of these default timeouts and compare them to other products/technologies to see if some adjustments may be needed - can you file a follow-on RFE for that?

Yes, I can make a follow on for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200831410
PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1200832770

From cslucas at openjdk.org  Mon May 22 18:00:00 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 22 May 2023 18:00:00 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v13]
In-Reply-To: <QUC45ZUDN81px7FNYS6xD_Ab9QUaltXctjSNQiUF-JM=.f562109a-036a-4ba1-8f97-9b6bacfad5d4@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <Yx1OcjTUO1iQV7ibbT71njBcVZz7-bJsYBRN6Iom94I=.e6657a24-5a0e-4e15-9229-8ef2b49a7fef@github.com>
 <QUC45ZUDN81px7FNYS6xD_Ab9QUaltXctjSNQiUF-JM=.f562109a-036a-4ba1-8f97-9b6bacfad5d4@github.com>
Message-ID: <hYEuOI4VfEYMy-dc9EVXl94l6HgVPC6Qpzl-XM9j0mo=.3aa74c45-eb15-4fe7-9d1b-73873f31d7a3@github.com>

On Fri, 19 May 2023 04:06:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I verified that the new test cases do trigger SR+NSR scenario.
> 
> How do you test that deoptimization works as expected?
> 

I have a copy of the tests in AllocationMergesTests.java in a separate file (not included in this PR) and I run the tests with a tool that compares the output of the test with RAM enabled and disabled. So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled.

> Diagnostic output is still hard to read. On one hand, it's too verbose when it comes to PcDesc/ScopeDesc sections ("pc-bytecode offsets" and "scopes") in nmethod output (enabled either w/ `-XX:+PrintAssembly` or `-XX:CompileCommand=print,...`). On the other hand, it lacks some important details, like `selector` and `merge_ptr` location information which is essential to make sense of debug information at a safepoint in the code.
> 

I'll take care of that. I was testing only with PrintDebugInfo.

> FTR `_skip_rematerialization` flag is unused now.
> 

yeah, I forgot to remove that. Thanks.

> Speaking of `_only_merge_candidate` flag, I find it easier about the code when the property being tracked is whether the `ObjectValue` is referenced from corresponding JVM state or not. (Maybe call it `is_root()`?) So, `ScopeDesc::objects_to_rematerialize()` would skip everything not referenced from JVM state, but then unconditionally accept anything returned by `ObjectMergeValue::select()` which doesn't need to adjust the flag before returning selected object. Also, it's safer to track the flag status for every `ObjectValues`, even for `ObjectMergeValue`.
> 

Sounds like a good idea. I'll do that. Thanks.

> Are you sure there's no way to end up with nested `ObjectMergeValue`s in presence of iterative EA?

I don't think so. This current patch only handle Phis that don't have NULL as input. As part of the reduction process we set at least one of the reducible Phi inputs to NULL. Therefore, subsequent iterations of EA won't reduce the same Phi.

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

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1557655811

From prr at openjdk.org  Mon May 22 18:04:51 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 22 May 2023 18:04:51 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <x_mmgeePvt94ApbI3L5Ubj7b0rwLdJI5CE5tSf7kTuk=.131f868d-52b7-4439-9957-a9b39a996046@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

I don't like this approach at all. if github had a "reject" button I'd be pushing it now.
updating the makefiles is the normal way to do this but I don't know if we even want that.
Until clang is the supported compiler for Linux then I see no reason for this to be in JDK at all.

Code changes which make it so there's no warning would be the preferred way but I'd expect that to be tested properly. Also if the warning is spurious - sometimes they are - then that would NOT be appropriate.

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

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1437172390

From weijun at openjdk.org  Mon May 22 18:25:50 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 22 May 2023 18:25:50 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries [v2]
In-Reply-To: <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>
Message-ID: <mK3RVNw5J_xVuXvt1xjutSFTe1rGG33KE-IMwIQHP0M=.78df60f3-2d65-448d-8979-8ea28ea9ddd5@github.com>

On Fri, 12 May 2023 02:23:17 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
>> 
>> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed to use keytool to generate keypairs instead of importing from
>   data files.

test/jdk/sun/security/pkcs11/KeyStore/CertChainRemoval/temp.ks line 1:

> 1: ????
root
??c?0??0


is this file useful?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13743#discussion_r1200876867

From weijun at openjdk.org  Mon May 22 19:00:53 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 22 May 2023 19:00:53 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries [v2]
In-Reply-To: <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>
Message-ID: <D5-HbkqWOdlfzeRjpcVJDrG2q3yT8_BNH46xpNTsYq4=.98b78da6-096c-40f3-8d06-9024669e5797@github.com>

On Fri, 12 May 2023 02:23:17 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
>> 
>> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed to use keytool to generate keypairs instead of importing from
>   data files.

Looks fine to me. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13743#pullrequestreview-1437265848

From ascarpino at openjdk.org  Mon May 22 19:30:12 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 22 May 2023 19:30:12 GMT
Subject: RFR: 8297878: KEM: Implementation [v18]
In-Reply-To: <YfHJ3qqBwrxM7Ft-CR8SYUUPdSAyn3TLOas8gX870Us=.05ddc735-6275-46f2-82eb-b08364f48b71@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <YfHJ3qqBwrxM7Ft-CR8SYUUPdSAyn3TLOas8gX870Us=.05ddc735-6275-46f2-82eb-b08364f48b71@github.com>
Message-ID: <vVYu1a3Mlx6RwM50MjiOU3NHMBRzgJgf_KG1OhkFsjs=.188ab359-a82e-4c68-855c-49be5c19bac8@github.com>

On Thu, 18 May 2023 17:07:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8297878
>  - Merge branch 'master' into 8297878
>  - to and length and comments
>  - deterministic randomness
>  - Resolve Siba's comment
>  - providerName
>  - more @since and about nulls
>  - Merge branch 'master' into 8297878
>  - no more pk/sk, AIOOBE to IOOBE
>  - small spec change
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/b1a8e951...7cace182

I'm fine with the changes

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13256#pullrequestreview-1437321126

From rriggs at openjdk.org  Mon May 22 19:31:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 May 2023 19:31:03 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v8]
In-Reply-To: <M9zVErlCn0A2sEt_iOGlAh3pypQmmY43hB1QVOncwlA=.22a1d957-3165-465d-80db-f678d31f4048@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <M9zVErlCn0A2sEt_iOGlAh3pypQmmY43hB1QVOncwlA=.22a1d957-3165-465d-80db-f678d31f4048@github.com>
Message-ID: <70nu7qZqJSWf13HVFRnxYCbE1QJovmEuJXZ2M7dVVIg=.0da39bf9-c641-41d5-b090-a071e8bd97d7@github.com>

On Thu, 18 May 2023 19:14:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308016: Address reviewer comments since previous commit

Thanks for the updates.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13957#pullrequestreview-1437322626

From kdriver at openjdk.org  Mon May 22 19:36:16 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 22 May 2023 19:36:16 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v18]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <OZfmIurBR9nXQdVjIur0QkrkjYGdzLQxEZIzJZDZnJI=.2cfdc2c5-f148-4af4-8b28-d0d46082f4d2@github.com>

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

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

  additional code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/8b672b0c..10c18fa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=16-17

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

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

From kdriver at openjdk.org  Mon May 22 19:36:16 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 22 May 2023 19:36:16 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v18]
In-Reply-To: <cTKnmfQqk0AoyFg-b165sYUQ0jqdXuQ6li-aKLOJqPY=.5d3f7722-d6b4-4b39-8be2-93cd12e5eecb@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <b8xpkkyQVml33xi5rehfsgrkKM9zkW3UrrFYDiTcpls=.8e260859-4c34-4dd7-95c6-bd58e17f2d58@github.com>
 <cTKnmfQqk0AoyFg-b165sYUQ0jqdXuQ6li-aKLOJqPY=.5d3f7722-d6b4-4b39-8be2-93cd12e5eecb@github.com>
Message-ID: <qPP97anNMd0LEQ_JTStqZYWKVM-kmuXtDPqhGzpsHlc=.36bef911-338e-46d9-8d41-b89cb49910db@github.com>

On Fri, 19 May 2023 19:00:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional code review comments
>
> test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 28:
> 
>> 26:  * @bug 8164879
>> 27:  * @library /test/lib
>> 28:  * @summary test for proper exception handling
> 
> Suggest adding more details here, ex: "Check that an improperly encoded CA distinguished name causes a handshake failure"

addressed

> test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 45:
> 
>> 43: 
>> 44: 
>> 45: public class Test8294985 {
> 
> I would avoid putting the bug number in the test name and use something more descriptive, like InvalidEncodedCaName.

addressed

> test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 64:
> 
>> 62:             + "/../../../../javax/net/ssl/etc/keystore";
>> 63: 
>> 64:     private static byte[] payload = Base64.getDecoder().decode(
> 
> Can you add a comment as to what is in this payload?

addressed

> test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 91:
> 
>> 89:         }
>> 90: 
>> 91:         System.out.println("payload len:" + payload.length);
> 
> Is this println necessary?

addressed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200954942
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955022
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955117
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955187

From kdriver at openjdk.org  Mon May 22 19:36:17 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 22 May 2023 19:36:17 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v15]
In-Reply-To: <Iv-DfVWckd_pqsWFPc-Z089CFBpnGFqM4xsqZ11UuY4=.196f7879-1db5-4450-a550-5e8605c6fe09@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com>
 <Iv-DfVWckd_pqsWFPc-Z089CFBpnGFqM4xsqZ11UuY4=.196f7879-1db5-4450-a550-5e8605c6fe09@github.com>
Message-ID: <ExHcFs2QzHnuoBYICA7RaQhUrKLhf66MYbrF_4s0xSU=.be1ac422-7f57-4122-b88c-f423e68d7066@github.com>

On Fri, 19 May 2023 20:21:16 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix bug id in test header
>>  - reworked example into a jtreg test
>
> test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 48:
> 
>> 46: 
>> 47:     // Test was originally written for TLSv1.2
>> 48:     private static String proto = "TLSv1.2";
> 
> Many of these could final.  Some of these are no longer used.

addressed

> test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 86:
> 
>> 84:      * Main entry point for this demo.
>> 85:      */
>> 86:     public static void main(String args[]) throws Exception {
> 
> Nit.  C Style args here instead of Java style.

addressed

> test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 104:
> 
>> 102:     }
>> 103: 
>> 104:     static Test8294985 fuzzdemoref = null;
> 
> No longer used.

addressed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955290
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955420
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1200955349

From wetmore at openjdk.org  Mon May 22 19:36:17 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Mon, 22 May 2023 19:36:17 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v15]
In-Reply-To: <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <8LyDN3KLcNKLM0Eg0EuGPUVku7o_K0Nm5Vj60SkBGD4=.9b9596bb-70e1-40eb-a697-4b6a920e40bb@github.com>
Message-ID: <Iv-DfVWckd_pqsWFPc-Z089CFBpnGFqM4xsqZ11UuY4=.196f7879-1db5-4450-a550-5e8605c6fe09@github.com>

On Fri, 19 May 2023 17:49:07 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix bug id in test header
>  - reworked example into a jtreg test

test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 48:

> 46: 
> 47:     // Test was originally written for TLSv1.2
> 48:     private static String proto = "TLSv1.2";

Many of these could final.  Some of these are no longer used.

test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 86:

> 84:      * Main entry point for this demo.
> 85:      */
> 86:     public static void main(String args[]) throws Exception {

Nit.  C Style args here instead of Java style.

test/jdk/sun/security/ssl/SSLEngineImpl/Test8294985.java line 104:

> 102:     }
> 103: 
> 104:     static Test8294985 fuzzdemoref = null;

No longer used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199338944
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199339757
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1199339499

From kdriver at openjdk.org  Mon May 22 19:41:25 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Mon, 22 May 2023 19:41:25 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v19]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <QqFyno7sQZ-MCBisuC5clXff1WnGflGCv_BStRr-1UI=.77fd50a7-ad0b-41db-aa3c-f468df0b5703@github.com>

> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8294985
 - additional code review comments
 - rename class and remove bug id from test header
 - removing block that isn't reached
 - fix bug id in test header
 - reworked example into a jtreg test
 - whitespace adjustments
 - all review comments applied
 - optimize imports and change toString
 - review comments addressed
 - ... and 7 more: https://git.openjdk.org/jdk/compare/bdf0d8ad...d9f0c667

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/10c18fa1..d9f0c667

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=17-18

  Stats: 21455 lines in 699 files changed: 12606 ins; 6112 del; 2737 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

PR: https://git.openjdk.org/jdk/pull/13466

From bpb at openjdk.org  Mon May 22 19:52:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 May 2023 19:52:50 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v8]
In-Reply-To: <70nu7qZqJSWf13HVFRnxYCbE1QJovmEuJXZ2M7dVVIg=.0da39bf9-c641-41d5-b090-a071e8bd97d7@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <M9zVErlCn0A2sEt_iOGlAh3pypQmmY43hB1QVOncwlA=.22a1d957-3165-465d-80db-f678d31f4048@github.com>
 <70nu7qZqJSWf13HVFRnxYCbE1QJovmEuJXZ2M7dVVIg=.0da39bf9-c641-41d5-b090-a071e8bd97d7@github.com>
Message-ID: <BuWN-2JkVJnyrnBGcjIn57p7UC7v2rCEuVSE4ubkAWw=.b60c66b4-e0d3-4907-ada1-324b17116435@github.com>

On Mon, 22 May 2023 19:28:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Thanks for the updates.

Thanks for all the comments (and the approval).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13957#issuecomment-1557863535

From jnimeh at openjdk.org  Mon May 22 21:55:12 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 22 May 2023 21:55:12 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v5]
In-Reply-To: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
Message-ID: <aXObcS4KUCqObaYCOnYBM_l1Fmv2FfPqmwMMSz4kkpY=.667c9e68-b152-4d9e-b096-1a5f476163f0@github.com>

> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
> 
> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
> 
> JBS: https://bugs.openjdk.org/browse/JDK-8179502
> CSR: https://bugs.openjdk.org/browse/JDK-8300722

Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Add additional debug message in timeout property parser
 - Merge with main
 - Use privilegedGetProperty, catch NFE following string match
 - Add OCSP readtimeout property
 - Add 's' suffix to allowed syntax
 - Fix more whitespace errors
 - Fix whitespace errors
 - 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13762/files
  - new: https://git.openjdk.org/jdk/pull/13762/files/e73818ef..659da859

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13762&range=03-04

  Stats: 183453 lines in 3181 files changed: 133144 ins; 26618 del; 23691 mod
  Patch: https://git.openjdk.org/jdk/pull/13762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13762/head:pull/13762

PR: https://git.openjdk.org/jdk/pull/13762

From valeriep at openjdk.org  Mon May 22 22:20:57 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 22 May 2023 22:20:57 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <w8oTRyHvL3artvfFP09WYJrvc9WBTff_7FFrnZZ3t7A=.04885848-0f22-4b0b-afda-54ed0cf4e3c3@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
 <QxTjp0i171upiuC6pf446VzggQpbqUruRkbT7DU9yOk=.030abeb4-752f-472b-b8f2-a209866ea762@github.com>
 <w8oTRyHvL3artvfFP09WYJrvc9WBTff_7FFrnZZ3t7A=.04885848-0f22-4b0b-afda-54ed0cf4e3c3@github.com>
Message-ID: <q55sEbcEbchk4O-YUUiIKwlK1H8epcq5Q8IcMiGRLm4=.1f48bb6a-3e6f-415f-aa41-cf08bf592cfe@github.com>

On Sat, 20 May 2023 00:58:05 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Good
>
> We discussed this change with @franferrax and have some concerns. The method Key::getEncoded does not document that a copy will be returned, and this would change the current behavior and affect non-PBE cases. In practical terms, it would mean that a key directly or indirectly converted to a P11Key would be destroyed if it does not return a clone in its getEncoded method. We suggest to make the caller responsible and keep the existing behavior. I.e.: if we call with a SecretKeySpec ?whose ::getEncoded returns a clone?, the caller will need to (optionally) clear the key. What do you think?

Hmm, so you are aware of a provider whose Key.getEncoded() impl returns the internal key bytes directly? Although the javadoc does NOT state a copy is being returned, it's very likely because an "encoding" is returned. If internal key bytes are returned, it seems bad programming practice, e.g. no protection for internal states/values?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1201228024

From weijun at openjdk.org  Mon May 22 22:45:53 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 22 May 2023 22:45:53 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <x3saOo63TUqjPsoxhIZmRM1xp3rl2UfRa96iwfFLVj4=.a756a52c-5766-464f-acda-554dc8c07ddb@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
 <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com>
 <x3saOo63TUqjPsoxhIZmRM1xp3rl2UfRa96iwfFLVj4=.a756a52c-5766-464f-acda-554dc8c07ddb@github.com>
Message-ID: <1OR86ZvM6Mpz2cNutPBANDqA6JRgbZdCDT1KJNG2VrA=.67402af5-ffdd-4fff-8b19-4e918d8e7641@github.com>

On Sun, 21 May 2023 21:29:50 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> src/java.base/macosx/classes/apple/security/KeychainStore.java line 808:
>> 
>>> 806:             // Check whether a certificate with same alias already exists and is the same
>>> 807:             // If yes, we can return here - the existing entry must have the same
>>> 808:             // properties and trust settings
>> 
>> This is always true, right? I'm not sure how this could happen.
>
> This handles the case, when a certificate is in both, the login (user) and system keychain.

How do you know "the existing entry must have the same properties and trust settings"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1201258508

From jnimeh at openjdk.org  Mon May 22 23:54:49 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Mon, 22 May 2023 23:54:49 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v4]
In-Reply-To: <vfWzS2qyQ1KwvLiMXxvjZEsmdUN5YVmEznd5kCnsVDc=.8f400cac-1fb1-42ee-9006-27448d4d1e9b@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <d9-oOxpXmEeFrUemoFxD2i5UsUtTuozjnIuXo4xYLkk=.7de1d45a-309b-4be7-837d-0e79876a9de8@github.com>
 <FoFPE_3mm0lPW7TSCeltW8Q3NKJAeLrN15zxKPw9LnI=.6339a6ce-4e60-4d60-b841-bcb7e2791746@github.com>
 <vfWzS2qyQ1KwvLiMXxvjZEsmdUN5YVmEznd5kCnsVDc=.8f400cac-1fb1-42ee-9006-27448d4d1e9b@github.com>
Message-ID: <nuT3G27Aceu_8NgEQL2aMcnMGMlgj_PX5xK3QjFiu0k=.2091a5a7-782e-4845-9102-2d0851c65fc7@github.com>

On Mon, 22 May 2023 17:39:59 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java line 131:
>> 
>>> 129:     private static final int DEFAULT_CRL_READ_TIMEOUT = 15000;
>>> 130: 
>>> 131:     // Default connect and read timeouts for CA certificate fetching (15 sec)
>> 
>> Does 15 seconds make sense as the default timeout, especially for certs? CRLs are generally larger than certs, so a longer read timeout makes sense.
>> 
>> I'm ok with keeping these default values the same for consistency, but I think we should re-evaluate each of these default timeouts and compare them to other products/technologies to see if some adjustments may be needed - can you file a follow-on RFE for that?
>
> Yes, I can make a follow on for that.

Filed https://bugs.openjdk.org/browse/JDK-8308601

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13762#discussion_r1201306717

From mpowers at openjdk.org  Tue May 23 00:36:26 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 23 May 2023 00:36:26 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v3]
In-Reply-To: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
Message-ID: <dMFztjD4qfNXh2bQX8gmoA35Nu2LS1mFd1DqjQSygHE=.cc92cd6a-78d8-4f90-bea6-ba37a1dc52f8@github.com>

> https://bugs.openjdk.org/browse/JDK-8307794

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  Ferenc: comments 1 and 2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13940/files
  - new: https://git.openjdk.org/jdk/pull/13940/files/7598bc74..eaace224

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=01-02

  Stats: 1479 lines in 1 file changed: 179 ins; 664 del; 636 mod
  Patch: https://git.openjdk.org/jdk/pull/13940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940

PR: https://git.openjdk.org/jdk/pull/13940

From fgao at openjdk.org  Tue May 23 01:59:58 2023
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 23 May 2023 01:59:58 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics
In-Reply-To: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
Message-ID: <HXahANqm_QZnq5SOxT_QH7mOUp2Jlbx7r9ddnT5h-k8=.f15d292f-a677-4927-9873-745501b97e08@github.com>

On Mon, 22 May 2023 14:23:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This provides a solid speedup of about 3-4x over the Java implementation.
> 
> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time.
> 
> Benchmarks:
> 
> 
> ThunderX (2, I think):
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score         Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  14078352.014 ? 4201407.966  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3   5154958.794 ? 1717146.980  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   1416563.273 ? 1311809.454  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3     94059.570 ?    2913.021  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      1441.024 ?     164.443  ops/s
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  4516486.795 ? 419624.224  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3  1228542.774 ? 202815.694  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   316051.912 ?  23066.449  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3    20649.561 ?   1094.687  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      310.564 ?     31.053  ops/s
> 
> Apple M1:
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  33551968.946 ? 849843.905  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3   9911637.214 ?  63417.224  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   2604370.740 ?  29208.265  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3    165183.633 ?   1975.998  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      2587.132 ?     40.240  ops/s
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  12373649.589 ? 184757.721  ops/s
> Poly1305DigestBench.updateBytes         256              th...

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 573:

> 571:   }
> 572: 
> 573:     if (FLAG_IS_DEFAULT(UsePoly1305Intrinsics)) {

Incorrect indention: extra space.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1201408065

From clanger at openjdk.org  Tue May 23 06:54:49 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 23 May 2023 06:54:49 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <1OR86ZvM6Mpz2cNutPBANDqA6JRgbZdCDT1KJNG2VrA=.67402af5-ffdd-4fff-8b19-4e918d8e7641@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
 <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com>
 <x3saOo63TUqjPsoxhIZmRM1xp3rl2UfRa96iwfFLVj4=.a756a52c-5766-464f-acda-554dc8c07ddb@github.com>
 <1OR86ZvM6Mpz2cNutPBANDqA6JRgbZdCDT1KJNG2VrA=.67402af5-ffdd-4fff-8b19-4e918d8e7641@github.com>
Message-ID: <HwqPoHzM9Jzo-0KvhJivGlO-ySgsXKwyZpDn2rESIXQ=.b30b30de-baac-441b-b822-2c2921fa17cb@github.com>

On Mon, 22 May 2023 22:43:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This handles the case, when a certificate is in both, the login (user) and system keychain.
>
> How do you know "the existing entry must have the same properties and trust settings"?

Trust settings are stored per certificate. That is, when you do `security add-trusted-cert`, you have to pass a certificate that the entry is created for. It does not matter then, if the certificate is actually present/loaded into any keychain. If the certificate is not in the keychain, a `security dump-trust-settings` will not show the trust entry then but after you add it, it gets visible.

So, that means, if two certificates are the same, no matter if they were loaded from different keychains or under different aliases (don't know whether the latter is possible though), they will share the same trust records.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1201622626

From weijun at openjdk.org  Tue May 23 15:10:50 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 23 May 2023 15:10:50 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
Message-ID: <enY-uaemHxRqrF3qXKTBOXUp9Cpg3wWpVAstDpyfHhw=.4777c659-0a0d-4da0-8ebf-c1c962524e75@github.com>

On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. We now trust self-signed certificates that have an explicit trust entry with no sub-records or no sub-records that would deny the certificate usage for any purpose.
>> 3. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove another obsolete comment

The code change looks fine to me. Thanks.

Since this is rather a big behavior change, I think a CSR and a release note are required. The previous release note on this is at https://www.oracle.com/java/technologies/javase/19-relnote-issues.html#JDK-8278449.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1559419631

From weijun at openjdk.org  Tue May 23 15:10:58 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 23 May 2023 15:10:58 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <HwqPoHzM9Jzo-0KvhJivGlO-ySgsXKwyZpDn2rESIXQ=.b30b30de-baac-441b-b822-2c2921fa17cb@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
 <1p5ZwtdO2jVASTziHPEVdcHzBN6ZARyjysCfSgnlIwk=.4fa4eed8-ae0e-4045-9475-8b596f79a038@github.com>
 <x3saOo63TUqjPsoxhIZmRM1xp3rl2UfRa96iwfFLVj4=.a756a52c-5766-464f-acda-554dc8c07ddb@github.com>
 <1OR86ZvM6Mpz2cNutPBANDqA6JRgbZdCDT1KJNG2VrA=.67402af5-ffdd-4fff-8b19-4e918d8e7641@github.com>
 <HwqPoHzM9Jzo-0KvhJivGlO-ySgsXKwyZpDn2rESIXQ=.b30b30de-baac-441b-b822-2c2921fa17cb@github.com>
Message-ID: <QdJlKUoarWKw57TduTzcVkgL0hbbt2yFhB2OV-t7fR0=.ff4ea52c-112d-4f41-95fa-30ea006fb154@github.com>

On Tue, 23 May 2023 06:52:01 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> How do you know "the existing entry must have the same properties and trust settings"?
>
> Trust settings are stored per certificate. That is, when you do `security add-trusted-cert`, you have to pass a certificate that the entry is created for. It does not matter then, if the certificate is actually present/loaded into any keychain. If the certificate is not in the keychain, a `security dump-trust-settings` will not show the trust entry then but after you add it, it gets visible.
> 
> So, that means, if two certificates are the same, no matter if they were loaded from different keychains or under different aliases (don't know whether the latter is possible though), they will share the same trust records.

I see. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13945#discussion_r1202347175

From duke at openjdk.org  Tue May 23 15:11:11 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 23 May 2023 15:11:11 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v3]
In-Reply-To: <dMFztjD4qfNXh2bQX8gmoA35Nu2LS1mFd1DqjQSygHE=.cc92cd6a-78d8-4f90-bea6-ba37a1dc52f8@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <dMFztjD4qfNXh2bQX8gmoA35Nu2LS1mFd1DqjQSygHE=.cc92cd6a-78d8-4f90-bea6-ba37a1dc52f8@github.com>
Message-ID: <AnmNQg-rOnZS7yi51C3aaDZMQdRvmR1RGOW9FzYZKUY=.e8eb7ed7-c230-4565-a123-78b23bafca17@github.com>

On Tue, 23 May 2023 00:36:26 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ferenc: comments 1 and 2

The code looks good to me now. I still suggest to change the file names, though.

test/jdk/sun/security/provider/lms/TestLMS.java line 59:

> 57:         for (TestCase t : TestCases) {
> 58:             if (!kat(t)) {
> 59:                 throw new RuntimeException("test case #" +i+ " failed");

Nit: "+i+" -> "+ i +"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13940#issuecomment-1559062663
PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202062133

From wetmore at openjdk.org  Tue May 23 15:14:26 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Tue, 23 May 2023 15:14:26 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v19]
In-Reply-To: <QqFyno7sQZ-MCBisuC5clXff1WnGflGCv_BStRr-1UI=.77fd50a7-ad0b-41db-aa3c-f468df0b5703@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <QqFyno7sQZ-MCBisuC5clXff1WnGflGCv_BStRr-1UI=.77fd50a7-ad0b-41db-aa3c-f468df0b5703@github.com>
Message-ID: <MihRTIglp0mUxOKiLAMbXdLyWwcAyuf5vVGZwDR_8r0=.258888a2-a8cf-4b90-8198-3d88eb52cb18@github.com>

On Mon, 22 May 2023 19:41:25 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8294985
>  - additional code review comments
>  - rename class and remove bug id from test header
>  - removing block that isn't reached
>  - fix bug id in test header
>  - reworked example into a jtreg test
>  - whitespace adjustments
>  - all review comments applied
>  - optimize imports and change toString
>  - review comments addressed
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/6825bcbe...d9f0c667

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 27:

> 25:  * @test
> 26:  * @library /test/lib
> 27:  * @summary verify correct exception handling in the event of an unparseable

Missing @bug field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1202513519

From mullan at openjdk.org  Tue May 23 15:17:48 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 23 May 2023 15:17:48 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <rodHJ4q6YCe62mc7iMNTM1sX5rrxsxhSmPZzoFrCgz0=.aca62528-3ac4-4fad-8829-d8bf410254c6@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <rodHJ4q6YCe62mc7iMNTM1sX5rrxsxhSmPZzoFrCgz0=.aca62528-3ac4-4fad-8829-d8bf410254c6@github.com>
Message-ID: <D_TyjFSqX8Kt7vB5-IFqG4gZiaIEKPd_HjrervXzsks=.82f024a0-8b3c-4264-b156-5a874defabb1@github.com>

On Sat, 20 May 2023 01:20:20 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Martin Balao 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:
>> 
>>  - Rebase fix after JDK-8306033. Replace called functions with their new names.
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #1)
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>>  - 8301553: Support Password-Based Cryptography in SunPKCS11
>>    
>>    Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> We found several more cases of passwords and encoded keys not cleared that were addressed in out Iteration # 2 commit. These cases were both in Java and native code. We still have doubts about the effectiveness and need for these actions, but prefer to have the discussion on a different channel.
> 
> We also found that invalid keys (not starting with the name "PBE") passed to PBES2Core::engineInit or P11PBECipher::engineInit were being cleared and this could be unexpected to the caller. This is related to my comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1199513839). For these cases, we decided not to invoke ::getEncoded and not to clean. As said, we have concerns about these undocumented mutations to objects passed by argument.
> 
> No test regressions observed in jdk/com/sun/crypto/provider or jdk/sun/security/pkcs11.

@martinuy I am adding a CSR requirement for this issue. In this Enhancement, you are adding support for new algorithms in a JCE provider. This type of change requires a CSR as you are adding support for algorithms that can be used by applications and not just inside the JDK, thus it is a type of exported interface of JDK scope. For an example of a similar issue, see [JDK-8274174](https://bugs.openjdk.org/browse/JDK-8274174). The CSR should also include details about any behavioral changes or differences that affect use of the algorithms through the standard JCE APIs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1559447733

From jnimeh at openjdk.org  Tue May 23 15:18:51 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 23 May 2023 15:18:51 GMT
Subject: Integrated: 8305091: Change ChaCha20 cipher init behavior to match
 AES-GCM
In-Reply-To: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
References: <544YuQ5XweT0r3iiDlcBGncCm1PWKZ2Bc4hxGiuGhr0=.00c0b6f8-3261-448c-b857-30bd83f7b841@github.com>
Message-ID: <Fpz6Efd5vNMqPmSI6FPQJHNi5MdEFJZHaB7yiAK0cuA=.b648df07-794f-476f-a0d4-1c7e3b410901@github.com>

On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This fixes an issue where the key/nonce reuse policy for SunJCE ChaCha20 and ChaCha20-Poly1305 was overly strict in enforcing no-reuse when the Cipher was in DECRYPT_MODE.  For decryption, this should be allowed and be consistent with the AES-GCM decryption initialization behavior.
> 
> - Issue: https://bugs.openjdk.org/browse/JDK-8305091
> - CSR: https://bugs.openjdk.org/browse/JDK-8305822

This pull request has now been integrated.

Changeset: bb0ff48a
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb0ff48aa94c4648a2f929226dd8d252431bcd03
Stats:     77 lines in 2 files changed: 31 ins; 14 del; 32 mod

8305091: Change ChaCha20 cipher init behavior to match AES-GCM

Reviewed-by: djelinski, ascarpino

-------------

PR: https://git.openjdk.org/jdk/pull/13428

From mullan at openjdk.org  Tue May 23 15:30:18 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 23 May 2023 15:30:18 GMT
Subject: RFR: 8179502: Enhance OCSP,
 CRL and Certificate Fetch Timeouts [v5]
In-Reply-To: <aXObcS4KUCqObaYCOnYBM_l1Fmv2FfPqmwMMSz4kkpY=.667c9e68-b152-4d9e-b096-1a5f476163f0@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
 <aXObcS4KUCqObaYCOnYBM_l1Fmv2FfPqmwMMSz4kkpY=.667c9e68-b152-4d9e-b096-1a5f476163f0@github.com>
Message-ID: <432KzSlo3CzO7O7_Qy14cENyYO3JHS9T2qC4oPrt9jA=.199b454b-8506-4c2f-88a7-426ba88f43ab@github.com>

On Mon, 22 May 2023 21:55:12 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
>> 
>> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
>> 
>> JBS: https://bugs.openjdk.org/browse/JDK-8179502
>> CSR: https://bugs.openjdk.org/browse/JDK-8300722
>
> Jamil Nimeh has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Add additional debug message in timeout property parser
>  - Merge with main
>  - Use privilegedGetProperty, catch NFE following string match
>  - Add OCSP readtimeout property
>  - Add 's' suffix to allowed syntax
>  - Fix more whitespace errors
>  - Fix whitespace errors
>  - 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts

Looks good. I think there may be value in moving some of the test code into the testlibrary, like the AIA and CRL https servers so other tests can use it, but we can explore that more later if the opportunity arises.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13762#pullrequestreview-1439694604

From clanger at openjdk.org  Tue May 23 15:58:04 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 23 May 2023 15:58:04 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <enY-uaemHxRqrF3qXKTBOXUp9Cpg3wWpVAstDpyfHhw=.4777c659-0a0d-4da0-8ebf-c1c962524e75@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
 <enY-uaemHxRqrF3qXKTBOXUp9Cpg3wWpVAstDpyfHhw=.4777c659-0a0d-4da0-8ebf-c1c962524e75@github.com>
Message-ID: <uuavMSRNNergZWERd8ys9EWNOeUIwAllEnG-6wLfNZE=.2c56a56e-622a-4ad5-9a17-8f6344a7b7f0@github.com>

On Tue, 23 May 2023 13:50:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The code change looks fine to me. Thanks.
> 
> Since this is rather a big behavior change, I think a CSR and a release note are required. The previous release note on this is at https://www.oracle.com/java/technologies/javase/19-relnote-issues.html#JDK-8278449.

Thanks for the review. As for CSR and release note, I guess one could do both, sure. However, it's quite a bit of overhead. And, for JDK-8278449, I don't see a CSR either. ? I would consider this change rather as a bugfix for JDK-8278449. So, if you really want me to do it, I'll do it. But please help me to get this processed quickly as I want to get this fix integrated ideally through this week. Please let me know your decision. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1559722249

From bpb at openjdk.org  Tue May 23 16:03:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 May 2023 16:03:43 GMT
Subject: Integrated: 8308016: Use snippets in java.io package
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <ybcD57nW2pl9rrY_JMES3uILD07v3JVCYuhBKQT4Ip0=.65ec3938-0742-462f-a12e-c79a0430a0d4@github.com>

On Fri, 12 May 2023 16:17:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

This pull request has now been integrated.

Changeset: 710453c6
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/710453c676712d021bf856dc601d965e4e270805
Stats:     159 lines in 20 files changed: 27 ins; 7 del; 125 mod

8308016: Use snippets in java.io package

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/13957

From mpowers at openjdk.org  Tue May 23 16:29:10 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 23 May 2023 16:29:10 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v4]
In-Reply-To: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
Message-ID: <QD-ly9HqLWLaC54dROIUKRiXCE3u5LVsAVQ6fPxil24=.7a309f0d-401d-4f87-a260-570c56c4cef9@github.com>

> https://bugs.openjdk.org/browse/JDK-8307794

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  Ferenc: comment 3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13940/files
  - new: https://git.openjdk.org/jdk/pull/13940/files/eaace224..5a851046

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=02-03

  Stats: 0 lines in 2 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940

PR: https://git.openjdk.org/jdk/pull/13940

From cslucas at openjdk.org  Tue May 23 16:39:22 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 23 May 2023 16:39:22 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v13]
In-Reply-To: <hYEuOI4VfEYMy-dc9EVXl94l6HgVPC6Qpzl-XM9j0mo=.3aa74c45-eb15-4fe7-9d1b-73873f31d7a3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <Yx1OcjTUO1iQV7ibbT71njBcVZz7-bJsYBRN6Iom94I=.e6657a24-5a0e-4e15-9229-8ef2b49a7fef@github.com>
 <QUC45ZUDN81px7FNYS6xD_Ab9QUaltXctjSNQiUF-JM=.f562109a-036a-4ba1-8f97-9b6bacfad5d4@github.com>
 <hYEuOI4VfEYMy-dc9EVXl94l6HgVPC6Qpzl-XM9j0mo=.3aa74c45-eb15-4fe7-9d1b-73873f31d7a3@github.com>
Message-ID: <pecw_mAPXwpefB166CpnLN9BdLb-9qkfU1yNxI9P8qQ=.5d63f1a4-1af5-45fe-b579-b34ab6804cc8@github.com>

On Mon, 22 May 2023 17:56:41 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Speaking of _only_merge_candidate flag, I find it easier about the code when the property being tracked is whether the ObjectValue is referenced from corresponding JVM state or not. (Maybe call it is_root()?) So, ScopeDesc::objects_to_rematerialize() would skip everything not referenced from JVM state [...]

@iwanowww - I want to make sure I understood "is_root(sv)" correctly. Are you suggesting to implement it as `ScopeDesc::is_root(ScopeValue* sv)` and the body of the method would just check if the `sv` is referenced in locals/expressions/monitor? Did I get it right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1559796992

From kdriver at openjdk.org  Tue May 23 16:51:45 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 23 May 2023 16:51:45 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v19]
In-Reply-To: <MihRTIglp0mUxOKiLAMbXdLyWwcAyuf5vVGZwDR_8r0=.258888a2-a8cf-4b90-8198-3d88eb52cb18@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <QqFyno7sQZ-MCBisuC5clXff1WnGflGCv_BStRr-1UI=.77fd50a7-ad0b-41db-aa3c-f468df0b5703@github.com>
 <MihRTIglp0mUxOKiLAMbXdLyWwcAyuf5vVGZwDR_8r0=.258888a2-a8cf-4b90-8198-3d88eb52cb18@github.com>
Message-ID: <R4K_Idv2aBbupYX5LN1fHPyXHVnYm0Zug559QJKCSTA=.b4772c1c-85ad-4d0e-b036-a0ec20db2282@github.com>

On Tue, 23 May 2023 15:09:39 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8294985
>>  - additional code review comments
>>  - rename class and remove bug id from test header
>>  - removing block that isn't reached
>>  - fix bug id in test header
>>  - reworked example into a jtreg test
>>  - whitespace adjustments
>>  - all review comments applied
>>  - optimize imports and change toString
>>  - review comments addressed
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/98f1821e...d9f0c667
>
> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 27:
> 
>> 25:  * @test
>> 26:  * @library /test/lib
>> 27:  * @summary verify correct exception handling in the event of an unparseable
> 
> Missing @bug field.

I was asked to remove it previously. I can add it back. Just looking for a consistent POV here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1202704091

From weijun at openjdk.org  Tue May 23 17:08:03 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 23 May 2023 17:08:03 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
Message-ID: <_aMfZRowhoTiFT0z_kZoxa7ewtoUnOqsEc12QaBrVoM=.0abd1e4f-4ac9-4bd2-95fa-ef0a1c996519@github.com>

On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. We now trust self-signed certificates that have an explicit trust entry with no sub-records or no sub-records that would deny the certificate usage for any purpose.
>> 3. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove another obsolete comment

I've started the CSR at https://bugs.openjdk.org/browse/JDK-8308690. Please edit if there is any issue. At the same time, please write a release note. See https://openjdk.org/guide/#release-notes for the process.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1559835489

From mpowers at openjdk.org  Tue May 23 17:14:42 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 23 May 2023 17:14:42 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v5]
In-Reply-To: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
Message-ID: <aF58lSjU-4jZOrFZAy299O7DF-zvlpXCUxqRTsR9qwI=.70ba030c-cb4e-4d62-b0bf-f13aa3c49a3b@github.com>

> https://bugs.openjdk.org/browse/JDK-8307794

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  change class names and fix nit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13940/files
  - new: https://git.openjdk.org/jdk/pull/13940/files/5a851046..a5aaeac0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=03-04

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940

PR: https://git.openjdk.org/jdk/pull/13940

From vlivanov at openjdk.org  Tue May 23 17:15:07 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 23 May 2023 17:15:07 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v13]
In-Reply-To: <pecw_mAPXwpefB166CpnLN9BdLb-9qkfU1yNxI9P8qQ=.5d63f1a4-1af5-45fe-b579-b34ab6804cc8@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <Yx1OcjTUO1iQV7ibbT71njBcVZz7-bJsYBRN6Iom94I=.e6657a24-5a0e-4e15-9229-8ef2b49a7fef@github.com>
 <QUC45ZUDN81px7FNYS6xD_Ab9QUaltXctjSNQiUF-JM=.f562109a-036a-4ba1-8f97-9b6bacfad5d4@github.com>
 <hYEuOI4VfEYMy-dc9EVXl94l6HgVPC6Qpzl-XM9j0mo=.3aa74c45-eb15-4fe7-9d1b-73873f31d7a3@github.com>
 <pecw_mAPXwpefB166CpnLN9BdLb-9qkfU1yNxI9P8qQ=.5d63f1a4-1af5-45fe-b579-b34ab6804cc8@github.com>
Message-ID: <s2_l--C7OkaVcOKhvj4T0OaxyPrYF9dXoFeJ-uxWN6c=.b71b6de1-e812-4551-91a4-c8e344af6fc8@github.com>

On Tue, 23 May 2023 16:36:32 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>  Are you suggesting to implement it as ScopeDesc::is_root(ScopeValue* sv) and the body of the method would just check if the sv is referenced in locals/expressions/monitor? Did I get it right?

I didn't propose exactly that, but I like your idea. I'm not against having it cached on `ScopeValue` side (and serialized in debug info), but implementing it as a query on `ScopeDesc` does look like a better alternative. (If it turns out to matter from performance POV, the check can be then turned into an assert and the cached value is used.)

Maybe call it `ScopeDesc::has_reference_to(ScopeValue* sv)` then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1559844211

From mpowers at openjdk.org  Tue May 23 17:17:07 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 23 May 2023 17:17:07 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v3]
In-Reply-To: <AnmNQg-rOnZS7yi51C3aaDZMQdRvmR1RGOW9FzYZKUY=.e8eb7ed7-c230-4565-a123-78b23bafca17@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <dMFztjD4qfNXh2bQX8gmoA35Nu2LS1mFd1DqjQSygHE=.cc92cd6a-78d8-4f90-bea6-ba37a1dc52f8@github.com>
 <AnmNQg-rOnZS7yi51C3aaDZMQdRvmR1RGOW9FzYZKUY=.e8eb7ed7-c230-4565-a123-78b23bafca17@github.com>
Message-ID: <kxiHiZmEsUehckTySOphnVDk52fALBqaLUMozChXS_Y=.5841b44d-bed9-418e-b3fd-b6210110cdbe@github.com>

On Tue, 23 May 2023 10:49:17 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ferenc: comments 1 and 2
>
> test/jdk/sun/security/provider/lms/TestLMS.java line 59:
> 
>> 57:         for (TestCase t : TestCases) {
>> 58:             if (!kat(t)) {
>> 59:                 throw new RuntimeException("test case #" +i+ " failed");
> 
> Nit: "+i+" -> "+ i +"

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202736729

From xuelei at openjdk.org  Tue May 23 18:19:09 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 23 May 2023 18:19:09 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v19]
In-Reply-To: <QqFyno7sQZ-MCBisuC5clXff1WnGflGCv_BStRr-1UI=.77fd50a7-ad0b-41db-aa3c-f468df0b5703@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <QqFyno7sQZ-MCBisuC5clXff1WnGflGCv_BStRr-1UI=.77fd50a7-ad0b-41db-aa3c-f468df0b5703@github.com>
Message-ID: <35aaSxH44qUrq8mfvwC0Hy4xYyvWTxZaLcTSfGv5fYk=.b5b66d89-ccca-495a-b173-31a20361be1c@github.com>

On Mon, 22 May 2023 19:41:25 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8294985
>  - additional code review comments
>  - rename class and remove bug id from test header
>  - removing block that isn't reached
>  - fix bug id in test header
>  - reworked example into a jtreg test
>  - whitespace adjustments
>  - all review comments applied
>  - optimize imports and change toString
>  - review comments addressed
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/1950bd92...d9f0c667

Changes requested by xuelei (Reviewer).

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 29:

> 27:  * @summary verify correct exception handling in the event of an unparseable
> 28:  *  DN in the peer CA
> 29:  */

Please run tests for JSSE/TLS in othervm mode.  Otherwise, the behavior may be impacted with each other, and the failure debugging is pretty hard.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1440319320
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1202812974

From xuelei at openjdk.org  Tue May 23 18:19:11 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 23 May 2023 18:19:11 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v19]
In-Reply-To: <R4K_Idv2aBbupYX5LN1fHPyXHVnYm0Zug559QJKCSTA=.b4772c1c-85ad-4d0e-b036-a0ec20db2282@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <QqFyno7sQZ-MCBisuC5clXff1WnGflGCv_BStRr-1UI=.77fd50a7-ad0b-41db-aa3c-f468df0b5703@github.com>
 <MihRTIglp0mUxOKiLAMbXdLyWwcAyuf5vVGZwDR_8r0=.258888a2-a8cf-4b90-8198-3d88eb52cb18@github.com>
 <R4K_Idv2aBbupYX5LN1fHPyXHVnYm0Zug559QJKCSTA=.b4772c1c-85ad-4d0e-b036-a0ec20db2282@github.com>
Message-ID: <8enBn6p_vJgOD0rgn4FZ5n0ZMnMBYMlzdQ3qzxQvE34=.70497115-c1c7-497f-aaae-3548a6edc185@github.com>

On Tue, 23 May 2023 16:48:52 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @library /test/lib
>>> 27:  * @summary verify correct exception handling in the event of an unparseable
>> 
>> Missing @bug field.
>
> I was asked to remove it previously. I can add it back. Just looking for a consistent POV here.

Generally, the @bug tag should be there to easy maintenance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1202809318

From mbalao at openjdk.org  Tue May 23 18:59:04 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 23 May 2023 18:59:04 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <q55sEbcEbchk4O-YUUiIKwlK1H8epcq5Q8IcMiGRLm4=.1f48bb6a-3e6f-415f-aa41-cf08bf592cfe@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
 <QxTjp0i171upiuC6pf446VzggQpbqUruRkbT7DU9yOk=.030abeb4-752f-472b-b8f2-a209866ea762@github.com>
 <w8oTRyHvL3artvfFP09WYJrvc9WBTff_7FFrnZZ3t7A=.04885848-0f22-4b0b-afda-54ed0cf4e3c3@github.com>
 <q55sEbcEbchk4O-YUUiIKwlK1H8epcq5Q8IcMiGRLm4=.1f48bb6a-3e6f-415f-aa41-cf08bf592cfe@github.com>
Message-ID: <CwW1456xinJUEFGd-n4NMxlYv1wSq-keoyJgpqub8UI=.6107dec1-477f-4e74-b6c6-a03ec6e7dc29@github.com>

On Mon, 22 May 2023 22:18:13 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> We discussed this change with @franferrax and have some concerns. The method Key::getEncoded does not document that a copy will be returned, and this would change the current behavior and affect non-PBE cases. In practical terms, it would mean that a key directly or indirectly converted to a P11Key would be destroyed if it does not return a clone in its getEncoded method. We suggest to make the caller responsible and keep the existing behavior. I.e.: if we call with a SecretKeySpec ?whose ::getEncoded returns a clone?, the caller will need to (optionally) clear the key. What do you think?
>
> Hmm, so you are aware of a provider whose Key.getEncoded() impl returns the internal key bytes directly? Although the javadoc does NOT state a copy is being returned, it's very likely because an "encoding" is returned. If internal key bytes are returned, it seems bad programming practice, e.g. no protection for internal states/values?

Thanks for your feedback. We've discussed this further and will move forward with the change but Just for the record let me document our conclusions here:

- This affect non-PBE scenarios and will change [previous JDK behavior](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L190).
- We have found one type of key in OpenJDK whose getEncoded method does not return a clone [here](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPublicKey.java#L86). While we acknowledge that it's unlikely, there can be more in non-OpenJDK security providers.
- We find that making the callee potentially mutate the arguments without documentation explicitly stating so can be confusing. While the clone pattern is known in Java to overcome limitations in the language and keep object immutability, it's inefficient as copies of objects need to be generated. We hope that the removal of the Security Manager and the untrusted code model provides more incentives for a different approach to this problem in the future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1202859208

From mullan at openjdk.org  Tue May 23 19:06:58 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 23 May 2023 19:06:58 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v5]
In-Reply-To: <aF58lSjU-4jZOrFZAy299O7DF-zvlpXCUxqRTsR9qwI=.70ba030c-cb4e-4d62-b0bf-f13aa3c49a3b@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <aF58lSjU-4jZOrFZAy299O7DF-zvlpXCUxqRTsR9qwI=.70ba030c-cb4e-4d62-b0bf-f13aa3c49a3b@github.com>
Message-ID: <iao1XvtxEg-Hen4-WnBufiH2Qe_U2oVGmWGHsyIMylg=.3b167f86-a91d-42ec-9b5f-a28091c44a9e@github.com>

On Tue, 23 May 2023 17:14:42 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change class names and fix nit

test/micro/org/openjdk/bench/java/security/HSSLMS.java line 70:

> 68:     public void test01_RFC_8554() throws Exception {
> 69:         // RFC 8554 Test Case 1
> 70:         var pk = decode("""

If we are primarily interested in measuring the performance of the HSS/LMS verification, the decode parts should really be left out of that calculation and moved to `setup()` methods. Consider having separate inner/static subclasses for each test, and moving the decoding code to the `setup()` methods in each of those subclasses. See `test/micro/org/openjdk/bench/java/security/Signatures.java` for an example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202868477

From valeriep at openjdk.org  Tue May 23 19:10:06 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 23 May 2023 19:10:06 GMT
Subject: RFR: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling
 PrivateKey entries [v2]
In-Reply-To: <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
 <mokHyEJx0EJ-g8ZgOR8LcSj-NpoeBc1VHeICDNUHCeU=.4b0e28d3-144e-4e9b-b83d-fe45731682b0@github.com>
Message-ID: <7rV8nQEnTG5Vv_VF7foNk35CM5OtfKGYK_SULGtGe2U=.761fcc04-47d6-465a-bd91-6be20db62eca@github.com>

On Fri, 12 May 2023 02:23:17 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
>> 
>> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed to use keytool to generate keypairs instead of importing from
>   data files.

Thanks all for review~

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13743#issuecomment-1559988606

From mullan at openjdk.org  Tue May 23 19:19:02 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 23 May 2023 19:19:02 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v5]
In-Reply-To: <aF58lSjU-4jZOrFZAy299O7DF-zvlpXCUxqRTsR9qwI=.70ba030c-cb4e-4d62-b0bf-f13aa3c49a3b@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <aF58lSjU-4jZOrFZAy299O7DF-zvlpXCUxqRTsR9qwI=.70ba030c-cb4e-4d62-b0bf-f13aa3c49a3b@github.com>
Message-ID: <sEzN577sIfs5gkH6Bv5QqnE6pU4IMvToN3rqMKacOog=.9c6408d9-258c-4975-9a9d-f4e9711ce711@github.com>

On Tue, 23 May 2023 17:14:42 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change class names and fix nit

test/jdk/sun/security/provider/hss/TestHSSLMS.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug JDK-8298127

Should just be `@bug 8298127`.

test/jdk/sun/security/provider/hss/TestHSSLMS.java line 83:

> 81:                 verify(t.pk, t.sig, t.msg);
> 82:                 return false;
> 83:             } catch (InvalidKeySpecException | SignatureException ex) {

It would be nice to test for the expected exception, either `InvalidKeySpecException` or `SignatureException`. You could add an additional field to the `TestCase` record which checks for the expected exception type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202871587
PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1202877384

From weijun at openjdk.org  Tue May 23 19:29:48 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 23 May 2023 19:29:48 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <CwW1456xinJUEFGd-n4NMxlYv1wSq-keoyJgpqub8UI=.6107dec1-477f-4e74-b6c6-a03ec6e7dc29@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <Da4IgWoy8tLsnsPhRM4v4Gb8tCMqSpSj02QAo1BO-MU=.5e988805-4fd5-4a94-87bf-dd0ef01850e1@github.com>
 <QxTjp0i171upiuC6pf446VzggQpbqUruRkbT7DU9yOk=.030abeb4-752f-472b-b8f2-a209866ea762@github.com>
 <w8oTRyHvL3artvfFP09WYJrvc9WBTff_7FFrnZZ3t7A=.04885848-0f22-4b0b-afda-54ed0cf4e3c3@github.com>
 <q55sEbcEbchk4O-YUUiIKwlK1H8epcq5Q8IcMiGRLm4=.1f48bb6a-3e6f-415f-aa41-cf08bf592cfe@github.com>
 <CwW1456xinJUEFGd-n4NMxlYv1wSq-keoyJgpqub8UI=.6107dec1-477f-4e74-b6c6-a03ec6e7dc29@github.com>
Message-ID: <s2AQLdNeZWbdZJtgiJL989mcanXX-yZuQUH1Y6jJwEs=.f98bfa1a-3670-4daf-a529-97681ee6333c@github.com>

On Tue, 23 May 2023 18:55:46 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hmm, so you are aware of a provider whose Key.getEncoded() impl returns the internal key bytes directly? Although the javadoc does NOT state a copy is being returned, it's very likely because an "encoding" is returned. If internal key bytes are returned, it seems bad programming practice, e.g. no protection for internal states/values?
>
> Thanks for your feedback. We've discussed this further and will move forward with the change but Just for the record let me document our conclusions here:
> 
> - This affect non-PBE scenarios and will change [previous JDK behavior](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L190).
> - We have found one type of key in OpenJDK whose getEncoded method does not return a clone [here](https://git.openjdk.org/jdk/blob/jdk-21%2B23/src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CPublicKey.java#L86). While we acknowledge that it's unlikely, there can be more in non-OpenJDK security providers.
> - We find that making the callee potentially mutate the arguments without documentation explicitly stating so can be confusing. While the clone pattern is known in Java to overcome limitations in the language and keep object immutability, it's inefficient as copies of objects need to be generated. We hope that the removal of the Security Manager and the untrusted code model provides more incentives for a different approach to this problem in the future.

The SunMSCAPI `getEncoded()` returning an internal cached encoding is a bug. I'll fix it. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1202885740

From mbalao at openjdk.org  Tue May 23 19:29:47 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 23 May 2023 19:29:47 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) ...

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12396/files
  - new: https://git.openjdk.org/jdk/pull/12396/files/41b14723..80575ccb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=03-04

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12396/head:pull/12396

PR: https://git.openjdk.org/jdk/pull/12396

From hchao at openjdk.org  Tue May 23 19:37:57 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 23 May 2023 19:37:57 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v5]
In-Reply-To: <aF58lSjU-4jZOrFZAy299O7DF-zvlpXCUxqRTsR9qwI=.70ba030c-cb4e-4d62-b0bf-f13aa3c49a3b@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <aF58lSjU-4jZOrFZAy299O7DF-zvlpXCUxqRTsR9qwI=.70ba030c-cb4e-4d62-b0bf-f13aa3c49a3b@github.com>
Message-ID: <ESZjBiHHobXkfsHIpzrM_li3K7MqE272vGrEcAb9b5k=.11697b39-2b58-474c-b974-31e170efdd1d@github.com>

On Tue, 23 May 2023 17:14:42 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change class names and fix nit

Test VerifyHSSLMSSignedJar.java looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13940#issuecomment-1560018158

From valeriep at openjdk.org  Tue May 23 21:15:06 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 23 May 2023 21:15:06 GMT
Subject: Integrated: 8301154: SunPKCS11 KeyStore deleteEntry results in
 dangling PrivateKey entries
In-Reply-To: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
References: <eWx2QCelJ_no1BvsnEXqAn_eBPU1Us_zvyjEZya0SUs=.f801625a-feb8-4452-b332-d10c5ce07a47@github.com>
Message-ID: <YrL2_eI8hJtgMRSNMFSYIKpOqvk8lIJO9Oo8GKsI-fI=.2fcddb2b-e378-497e-a1c5-c839063db367@github.com>

On Mon, 1 May 2023 19:49:05 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Could someone help review this PKCS11KeyStore fix regarding the cert chain removal?
> 
> The proposed fix will not remove the cert if it has a corresponding private key or is an issuer of other entities in the same keystore.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: 6b27dad7
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b27dad76e20131503da15119d930df17dd517d9
Stats:     348 lines in 4 files changed: 264 ins; 37 del; 47 mod

8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries

Reviewed-by: weijun, hchao

-------------

PR: https://git.openjdk.org/jdk/pull/13743

From clanger at openjdk.org  Tue May 23 21:20:57 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 23 May 2023 21:20:57 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <_aMfZRowhoTiFT0z_kZoxa7ewtoUnOqsEc12QaBrVoM=.0abd1e4f-4ac9-4bd2-95fa-ef0a1c996519@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
 <_aMfZRowhoTiFT0z_kZoxa7ewtoUnOqsEc12QaBrVoM=.0abd1e4f-4ac9-4bd2-95fa-ef0a1c996519@github.com>
Message-ID: <FZ_Ddv-HJ6fhbjPtcqpJO0pfzn6eZaTi_vk9Bdj-iDU=.ea153907-3276-43c9-b09f-6f242286cb0e@github.com>

On Tue, 23 May 2023 17:05:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I've started the CSR at https://bugs.openjdk.org/browse/JDK-8308690. Please edit if there is any issue. At the same time, please write a release note. See https://openjdk.org/guide/#release-notes for the process.

Thanks. I've created a release note and Edited the CSR. Please review both. When you are fine with the CSR, I can finalize it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1560135796

From jnimeh at openjdk.org  Tue May 23 21:36:09 2023
From: jnimeh at openjdk.org (Jamil Nimeh)
Date: Tue, 23 May 2023 21:36:09 GMT
Subject: Integrated: 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
In-Reply-To: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
References: <sqsZrhiiGBqjG9qlwkYH0el0GcE8uXLF9-nzNhbs8dE=.3fba0258-26b6-4fba-aff5-111d018908a7@github.com>
Message-ID: <-8MaW0PKCc_ysgT24jw73ETHVSAlLG1KcV-uuyjhLpM=.508b5616-5220-4dd0-80bf-af246a6c437d@github.com>

On Tue, 2 May 2023 21:12:31 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> This set of enhancements extends the allowed syntax for the `com.sun.security.ocsp.timeout`, `com.sun.security.crl.timeout` and `com.sun.security.crl.readtimeout` System properties.  These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.
> 
> This enhancement also adds two new System properties: `com.sun.security.cert.timeout` and `com.sun.security.cert.readtimeout` which follow the same new allowed syntax.  These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the `com.sun.security.enableAIAcaIssuers` property is true (default false).
> 
> JBS: https://bugs.openjdk.org/browse/JDK-8179502
> CSR: https://bugs.openjdk.org/browse/JDK-8300722

This pull request has now been integrated.

Changeset: 2836c34b
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2836c34b64e4626e25c86a53e5bef2bf32f95d2e
Stats:     913 lines in 7 files changed: 795 ins; 25 del; 93 mod

8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts

Reviewed-by: mullan

-------------

PR: https://git.openjdk.org/jdk/pull/13762

From ssahoo at openjdk.org  Wed May 24 07:10:25 2023
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 24 May 2023 07:10:25 GMT
Subject: RFR: 8308711: Develop additional Tests for KEM implementation
Message-ID: <Eo8xO4BX-UPh6nwDVHYd0ZjCutudkdOmFVVtKT6zB8Q=.0694d42f-7861-469c-9959-8e725a6c8dd5@github.com>

Additional Tests for KEM API.

-------------

Commit messages:
 - 8308711: Develop additional Tests for KEM implementation

Changes: https://git.openjdk.org/jdk/pull/14113/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308711
  Stats: 540 lines in 3 files changed: 540 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14113/head:pull/14113

PR: https://git.openjdk.org/jdk/pull/14113

From aph at openjdk.org  Wed May 24 09:25:06 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 24 May 2023 09:25:06 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2]
In-Reply-To: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
Message-ID: <geIFUmhzy-Z-wem8ADTGaoZIwNiSgBawkNPHQzkiDeY=.335958a1-61a9-426f-8bb2-ae9aa49cf7d4@github.com>

> This provides a solid speedup of about 3-4x over the Java implementation.
> 
> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time.
> 
> Benchmarks:
> 
> 
> ThunderX (2, I think):
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score         Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  14078352.014 ? 4201407.966  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3   5154958.794 ? 1717146.980  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   1416563.273 ? 1311809.454  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3     94059.570 ?    2913.021  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      1441.024 ?     164.443  ops/s
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  4516486.795 ? 419624.224  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3  1228542.774 ? 202815.694  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   316051.912 ?  23066.449  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3    20649.561 ?   1094.687  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      310.564 ?     31.053  ops/s
> 
> Apple M1:
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  33551968.946 ? 849843.905  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3   9911637.214 ?  63417.224  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   2604370.740 ?  29208.265  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3    165183.633 ?   1975.998  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      2587.132 ?     40.240  ops/s
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  12373649.589 ? 184757.721  ops/s
> Poly1305DigestBench.updateBytes         256              th...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14085/files
  - new: https://git.openjdk.org/jdk/pull/14085/files/ec0aa80d..c74ed2c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14085/head:pull/14085

PR: https://git.openjdk.org/jdk/pull/14085

From redestad at openjdk.org  Wed May 24 10:11:55 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 24 May 2023 10:11:55 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2]
In-Reply-To: <geIFUmhzy-Z-wem8ADTGaoZIwNiSgBawkNPHQzkiDeY=.335958a1-61a9-426f-8bb2-ae9aa49cf7d4@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
 <geIFUmhzy-Z-wem8ADTGaoZIwNiSgBawkNPHQzkiDeY=.335958a1-61a9-426f-8bb2-ae9aa49cf7d4@github.com>
Message-ID: <IqmCaLd9reRCUOlIIEx2IM2I-rFgRyaDtYLUylPIGJk=.70e8194f-266d-49e1-ae9f-f1b1cb1ce333@github.com>

On Wed, 24 May 2023 09:25:06 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This provides a solid speedup of about 3-4x over the Java implementation.
>> 
>> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time.
>> 
>> Benchmarks:
>> 
>> 
>> ThunderX (2, I think):
>> 
>> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score         Error  Units
>> Poly1305DigestBench.updateBytes          64              thrpt    3  14078352.014 ? 4201407.966  ops/s
>> Poly1305DigestBench.updateBytes         256              thrpt    3   5154958.794 ? 1717146.980  ops/s
>> Poly1305DigestBench.updateBytes        1024              thrpt    3   1416563.273 ? 1311809.454  ops/s
>> Poly1305DigestBench.updateBytes       16384              thrpt    3     94059.570 ?    2913.021  ops/s
>> Poly1305DigestBench.updateBytes     1048576              thrpt    3      1441.024 ?     164.443  ops/s
>> 
>> Benchmark                        (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.updateBytes          64              thrpt    3  4516486.795 ? 419624.224  ops/s
>> Poly1305DigestBench.updateBytes         256              thrpt    3  1228542.774 ? 202815.694  ops/s
>> Poly1305DigestBench.updateBytes        1024              thrpt    3   316051.912 ?  23066.449  ops/s
>> Poly1305DigestBench.updateBytes       16384              thrpt    3    20649.561 ?   1094.687  ops/s
>> Poly1305DigestBench.updateBytes     1048576              thrpt    3      310.564 ?     31.053  ops/s
>> 
>> Apple M1:
>> 
>> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
>> Poly1305DigestBench.updateBytes          64              thrpt    3  33551968.946 ? 849843.905  ops/s
>> Poly1305DigestBench.updateBytes         256              thrpt    3   9911637.214 ?  63417.224  ops/s
>> Poly1305DigestBench.updateBytes        1024              thrpt    3   2604370.740 ?  29208.265  ops/s
>> Poly1305DigestBench.updateBytes       16384              thrpt    3    165183.633 ?   1975.998  ops/s
>> Poly1305DigestBench.updateBytes     1048576              thrpt    3      2587.132 ?     40.240  ops/s
>> 
>> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
>> Poly1305DigestBench.updateBytes          64              thrpt    3  12373649.589 ? 184757.721  ops/s
>> Poly1305DigestBench.upd...
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7097:

> 7095:       // together partial products without any risk of needing to
> 7096:       // propagate a carry out.
> 7097:       wide_mul(U_0, U_0HI, S_0, R_0);  wide_madd(U_0, U_0HI, S_1, RR_1); wide_madd(U_0, U_0HI, S_2, RR_0);

What is `r` corresponding to here? This asserts that 'the top four bits of each 32-bit subword of "r" are zero'. If `r` is `R_0...R_2` it would seem broken since we're packing 26-bit values into `R_0...R_2` above in a way that would break this invariant?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1203838423

From aph at openjdk.org  Wed May 24 10:21:56 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 24 May 2023 10:21:56 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2]
In-Reply-To: <IqmCaLd9reRCUOlIIEx2IM2I-rFgRyaDtYLUylPIGJk=.70e8194f-266d-49e1-ae9f-f1b1cb1ce333@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
 <geIFUmhzy-Z-wem8ADTGaoZIwNiSgBawkNPHQzkiDeY=.335958a1-61a9-426f-8bb2-ae9aa49cf7d4@github.com>
 <IqmCaLd9reRCUOlIIEx2IM2I-rFgRyaDtYLUylPIGJk=.70e8194f-266d-49e1-ae9f-f1b1cb1ce333@github.com>
Message-ID: <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com>

On Wed, 24 May 2023 10:07:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7097:
> 
>> 7095:       // together partial products without any risk of needing to
>> 7096:       // propagate a carry out.
>> 7097:       wide_mul(U_0, U_0HI, S_0, R_0);  wide_madd(U_0, U_0HI, S_1, RR_1); wide_madd(U_0, U_0HI, S_2, RR_0);
> 
> What is `r` corresponding to here? This asserts that 'the top four bits of each 32-bit subword of "r" are zero'. If `r` is `R_0...R_2` it would seem broken since we're packing 26-bit values into `R_0...R_2` above in a way that would break this invariant?

No, it doesn't break the invariants.

R is the randomly-chosen 128-bit key. It is generated from an initial 128-bit-log string or random bits, then
`r &= 0x0ffffffc0ffffffc0ffffffc0fffffff`

This 128-bit-long string is split into 26-bit limbs before the intrinsic is called. The zero bits remain zero.
When we repack R into two 64-bit registers those zero bits are still zero.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1203850178

From aph at openjdk.org  Wed May 24 11:13:13 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 24 May 2023 11:13:13 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v3]
In-Reply-To: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
Message-ID: <4sG1ZCZbdkhSv3YMaKNJJgeScmCHjhAQamhVloF-5EY=.359451be-9627-4aac-896e-abbb1126fde0@github.com>

> This provides a solid speedup of about 3-4x over the Java implementation.
> 
> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time.
> 
> Benchmarks:
> 
> 
> ThunderX (2, I think):
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score         Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  14078352.014 ? 4201407.966  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3   5154958.794 ? 1717146.980  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   1416563.273 ? 1311809.454  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3     94059.570 ?    2913.021  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      1441.024 ?     164.443  ops/s
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  4516486.795 ? 419624.224  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3  1228542.774 ? 202815.694  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   316051.912 ?  23066.449  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3    20649.561 ?   1094.687  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      310.564 ?     31.053  ops/s
> 
> Apple M1:
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  33551968.946 ? 849843.905  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3   9911637.214 ?  63417.224  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   2604370.740 ?  29208.265  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3    165183.633 ?   1975.998  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      2587.132 ?     40.240  ops/s
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  12373649.589 ? 184757.721  ops/s
> Poly1305DigestBench.updateBytes         256              th...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Comment change only

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14085/files
  - new: https://git.openjdk.org/jdk/pull/14085/files/c74ed2c6..9cc899b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=01-02

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14085/head:pull/14085

PR: https://git.openjdk.org/jdk/pull/14085

From aph at openjdk.org  Wed May 24 11:13:16 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 24 May 2023 11:13:16 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2]
In-Reply-To: <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
 <geIFUmhzy-Z-wem8ADTGaoZIwNiSgBawkNPHQzkiDeY=.335958a1-61a9-426f-8bb2-ae9aa49cf7d4@github.com>
 <IqmCaLd9reRCUOlIIEx2IM2I-rFgRyaDtYLUylPIGJk=.70e8194f-266d-49e1-ae9f-f1b1cb1ce333@github.com>
 <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com>
Message-ID: <LxIPUk3COEvzCCDa05mhARn0mRpdhMtrpyBq2w3YPQ4=.a88cb1e4-5106-483f-a0da-cce34f9ac90f@github.com>

On Wed, 24 May 2023 10:18:39 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 7097:
>> 
>>> 7095:       // together partial products without any risk of needing to
>>> 7096:       // propagate a carry out.
>>> 7097:       wide_mul(U_0, U_0HI, S_0, R_0);  wide_madd(U_0, U_0HI, S_1, RR_1); wide_madd(U_0, U_0HI, S_2, RR_0);
>> 
>> What is `r` corresponding to here? This asserts that 'the top four bits of each 32-bit subword of "r" are zero'. If `r` is `R_0...R_2` it would seem broken since we're packing 26-bit values into `R_0...R_2` above in a way that would break this invariant?
>
> No, it doesn't break the invariants.
> 
> R is the randomly-chosen 128-bit key. It is generated from an initial 128-bit-log string of random bits, then
> `r &= 0x0ffffffc0ffffffc0ffffffc0fffffff`
> 
> This 128-bit-long string is split into 26-bit limbs before the intrinsic is called. The zero bits remain zero.
> When we repack R into two 64-bit registers those zero bits are still zero.

See https://loup-vaillant.fr/tutorials/poly1305-design for more explanation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1203912143

From weijun at openjdk.org  Wed May 24 13:24:00 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 24 May 2023 13:24:00 GMT
Subject: RFR: 8308711: Develop additional Tests for KEM implementation
In-Reply-To: <Eo8xO4BX-UPh6nwDVHYd0ZjCutudkdOmFVVtKT6zB8Q=.0694d42f-7861-469c-9959-8e725a6c8dd5@github.com>
References: <Eo8xO4BX-UPh6nwDVHYd0ZjCutudkdOmFVVtKT6zB8Q=.0694d42f-7861-469c-9959-8e725a6c8dd5@github.com>
Message-ID: <P_6yhISa3oOzMSED5dcYcbWKk2_98MLGw75EDJAWvKA=.1843e6ff-7552-4c5d-ab2b-7d2e25921326@github.com>

On Wed, 24 May 2023 07:02:55 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> Additional Tests for KEM API.

test/jdk/javax/crypto/KEM/GenLargeNumberOfKeys.java line 1:

> 1: /*

1. `testXDH` and `testEC` are mostly identical. Maybe you can write a single method with 2 extra arguments.
2. According to the spec, multiple keys generated from a *single* `Encapsulator` are different. The `test` method is creating a new encapsulators each time.
3. There is no guarantee that a `SecretKey` follows the `hashCode/equals` convention and can be put inside a `Set` to detect duplication. It happens that in this implementation the key is a `SecretKeySpec` object so it works.

test/jdk/javax/crypto/KEM/KemInterop.java line 77:

> 75:                 KEM.Encapsulated enc2 = encT1.encapsulate();
> 76: 
> 77:                 Asserts.assertEQ(enc.key(), enc.key());

Again, we cannot guarantee `equals` between 2 `SecretKey` objects. However, since it's a positive test here, it's OK to do this. If we really modify the implementation later and return a different kind of `SecretKey`, we can update the test later.

test/jdk/javax/crypto/KEM/KemInterop.java line 81:

> 79:                 Asserts.assertTrue(Arrays.equals(enc.encapsulation(), enc.encapsulation()));
> 80: 
> 81:                 Asserts.assertNE(enc.key(), enc1.key());

This is a negative test and we should rely on `!equals` here. I think we can drop this check. If the `enc.key()` check below already shows they are different, then the key will be different too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1204090836
PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1204119149
PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1204120540

From redestad at openjdk.org  Wed May 24 13:41:56 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 24 May 2023 13:41:56 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2]
In-Reply-To: <LxIPUk3COEvzCCDa05mhARn0mRpdhMtrpyBq2w3YPQ4=.a88cb1e4-5106-483f-a0da-cce34f9ac90f@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
 <geIFUmhzy-Z-wem8ADTGaoZIwNiSgBawkNPHQzkiDeY=.335958a1-61a9-426f-8bb2-ae9aa49cf7d4@github.com>
 <IqmCaLd9reRCUOlIIEx2IM2I-rFgRyaDtYLUylPIGJk=.70e8194f-266d-49e1-ae9f-f1b1cb1ce333@github.com>
 <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com>
 <LxIPUk3COEvzCCDa05mhARn0mRpdhMtrpyBq2w3YPQ4=.a88cb1e4-5106-483f-a0da-cce34f9ac90f@github.com>
Message-ID: <s46ZbuSHCvVxALZV46cqz3KyEIuZHGyOjXsEWNIeuuk=.4b149c2f-b62f-41ba-b35e-c40af50f6882@github.com>

On Wed, 24 May 2023 11:08:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> No, it doesn't break the invariants.
>> 
>> R is the randomly-chosen 128-bit key. It is generated from an initial 128-bit-log string of random bits, then
>> `r &= 0x0ffffffc0ffffffc0ffffffc0fffffff`
>> 
>> This 128-bit-long string is split into 26-bit limbs before the intrinsic is called. The zero bits remain zero.
>> When we repack R into two 64-bit registers those zero bits are still zero.
>
> See https://loup-vaillant.fr/tutorials/poly1305-design for more explanation

Thanks for the link! 

So `r` refers to the value passed via `r_start` and it wasn't clear from the immediate context that `r_start` is already split into 26-bit limbs. So the `pack26` takes the 5 26-bit limbs and repacks them so that `R_0` has the low 64-bit of `r`, `R_1` the high bits. Makes sense. 

`R_2` is unused and could be reclaimed. Perhaps an override for `pack26` that only takes two registers and discards the last 2 bits? Might help clarify the setup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1204159348

From mullan at openjdk.org  Wed May 24 15:46:24 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 24 May 2023 15:46:24 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v17]
In-Reply-To: <ida3mujwIQIHFT6PiBNIKwv4hzOyHX503iN050lND_g=.e6ea1f2f-cddb-4cc8-a1ce-62cf7a348d22@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <ida3mujwIQIHFT6PiBNIKwv4hzOyHX503iN050lND_g=.e6ea1f2f-cddb-4cc8-a1ce-62cf7a348d22@github.com>
Message-ID: <KgyeOH8weryDNNjSch-bHlR9zq1TCkqvw6yPRxQIokw=.ac0be3ec-60d9-4eba-8f92-b1708af134fd@github.com>

On Thu, 18 May 2023 19:11:32 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed dead code, accepted code style suggestions.

src/java.base/share/classes/sun/security/provider/HSS.java line 664:

> 662:         protected PublicKey engineGeneratePublic(KeySpec keySpec)
> 663:                 throws InvalidKeySpecException {
> 664:             if (keySpec instanceof X509EncodedKeySpec) {

Can you also use `instanceof x` here and avoid the cast on line 666?

src/java.base/share/classes/sun/security/provider/HSS.java line 695:

> 693:                 throw new InvalidKeySpecException("key should not be null");
> 694:             }
> 695:             if (key.getFormat().equals("X.509") &&

Would it make sense to also check if `key` is an instance of `HSSPublicKey`?

src/java.base/share/classes/sun/security/provider/HSS.java line 700:

> 698:                     return keySpec.cast(new X509EncodedKeySpec(key.getEncoded()));
> 699:                 }
> 700:                 throw new InvalidKeySpecException("keySpec is not an X509 one");

Suggest saying name of class: "keySpec is not an X509EncodedKeySpec"

src/java.base/share/classes/sun/security/provider/HSS.java line 787:

> 785: 
> 786:         @java.io.Serial
> 787:         protected Object writeReplace() throws java.io.ObjectStreamException {

Make this `private` instead of `protected`. Also, add an overridden private `readObject` method that simply throws an exception, ex: 

`throw new InvalidObjectException("HSS public keys are not directly deserializable");
`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204336773
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204361545
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204353785
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204415763

From aph at openjdk.org  Wed May 24 16:17:14 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 24 May 2023 16:17:14 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4]
In-Reply-To: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
Message-ID: <JR_1VDYxSCsfv-54ZaW6dZZK0sgePVqLtHIgWeQVlNs=.ccdad947-1311-464a-89a9-4fbf3a432cb9@github.com>

> This provides a solid speedup of about 3-4x over the Java implementation.
> 
> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time.
> 
> Benchmarks:
> 
> 
> ThunderX (2, I think):
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score         Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  14078352.014 ? 4201407.966  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3   5154958.794 ? 1717146.980  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   1416563.273 ? 1311809.454  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3     94059.570 ?    2913.021  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      1441.024 ?     164.443  ops/s
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  4516486.795 ? 419624.224  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3  1228542.774 ? 202815.694  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   316051.912 ?  23066.449  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3    20649.561 ?   1094.687  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      310.564 ?     31.053  ops/s
> 
> Apple M1:
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  33551968.946 ? 849843.905  ops/s
> Poly1305DigestBench.updateBytes         256              thrpt    3   9911637.214 ?  63417.224  ops/s
> Poly1305DigestBench.updateBytes        1024              thrpt    3   2604370.740 ?  29208.265  ops/s
> Poly1305DigestBench.updateBytes       16384              thrpt    3    165183.633 ?   1975.998  ops/s
> Poly1305DigestBench.updateBytes     1048576              thrpt    3      2587.132 ?     40.240  ops/s
> 
> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
> Poly1305DigestBench.updateBytes          64              thrpt    3  12373649.589 ? 184757.721  ops/s
> Poly1305DigestBench.updateBytes         256              th...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14085/files
  - new: https://git.openjdk.org/jdk/pull/14085/files/9cc899b9..93a03c62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14085&range=02-03

  Stats: 26 lines in 1 file changed: 19 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14085/head:pull/14085

PR: https://git.openjdk.org/jdk/pull/14085

From aph at openjdk.org  Wed May 24 16:17:16 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 24 May 2023 16:17:16 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v2]
In-Reply-To: <s46ZbuSHCvVxALZV46cqz3KyEIuZHGyOjXsEWNIeuuk=.4b149c2f-b62f-41ba-b35e-c40af50f6882@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
 <geIFUmhzy-Z-wem8ADTGaoZIwNiSgBawkNPHQzkiDeY=.335958a1-61a9-426f-8bb2-ae9aa49cf7d4@github.com>
 <IqmCaLd9reRCUOlIIEx2IM2I-rFgRyaDtYLUylPIGJk=.70e8194f-266d-49e1-ae9f-f1b1cb1ce333@github.com>
 <0nXXI8mO78thf163WFvVhOS2FTLhbaqs694CxjWtLn0=.e80cbcf0-ffb0-4d6f-b313-c715accbb889@github.com>
 <LxIPUk3COEvzCCDa05mhARn0mRpdhMtrpyBq2w3YPQ4=.a88cb1e4-5106-483f-a0da-cce34f9ac90f@github.com>
 <s46ZbuSHCvVxALZV46cqz3KyEIuZHGyOjXsEWNIeuuk=.4b149c2f-b62f-41ba-b35e-c40af50f6882@github.com>
Message-ID: <eOKEBrd1_doDNor2jfh_Ri4P9Ijw6jmr0GCG6Mh-nq8=.754ae819-0b7f-404d-a25d-14d265723145@github.com>

On Wed, 24 May 2023 13:39:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> See https://loup-vaillant.fr/tutorials/poly1305-design for more explanation
>
> Thanks for the link! 
> 
> So `r` refers to the value passed via `r_start` and it wasn't clear from the immediate context that `r_start` is already split into 26-bit limbs. So the `pack26` takes the 5 26-bit limbs and repacks them so that `R_0` has the low 64-bit of `r`, `R_1` the high bits. Makes sense. 
> 
> `R_2` is unused and could be reclaimed. Perhaps an override for `pack26` that only takes two registers and discards the last 2 bits? Might help clarify the setup.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14085#discussion_r1204459514

From mullan at openjdk.org  Wed May 24 16:26:20 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 24 May 2023 16:26:20 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v17]
In-Reply-To: <ida3mujwIQIHFT6PiBNIKwv4hzOyHX503iN050lND_g=.e6ea1f2f-cddb-4cc8-a1ce-62cf7a348d22@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <ida3mujwIQIHFT6PiBNIKwv4hzOyHX503iN050lND_g=.e6ea1f2f-cddb-4cc8-a1ce-62cf7a348d22@github.com>
Message-ID: <TqqV5OMokDtsSMZTvCZp1jGI9QAwTjUjktE3rY3jwKA=.3a0b5153-a50f-40dd-b73b-45fa21520086@github.com>

On Thu, 18 May 2023 19:11:32 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed dead code, accepted code style suggestions.

src/java.base/share/classes/sun/security/provider/HSS.java line 58:

> 56: 
> 57:     @Override
> 58:     protected void engineInitSign(PrivateKey privateKey)

I think you should also override `engineInitSign(PrivateKey, SecureRandom)` even though the default impl. calls `engineInitSign(PrivateKey)`. It also assigns the `SecureRandom` to the protected `appRandom` field, which is probably best avoided.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204473301

From valeriep at openjdk.org  Wed May 24 18:42:10 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 24 May 2023 18:42:10 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
Message-ID: <cOdMxB-RhdE0UQMEz7S7CAKtB2bOUtyjtBwF3hKA2DE=.296c398f-2be0-4a9a-bdb9-2336870e959a@github.com>

On Tue, 23 May 2023 19:29:47 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java line 71:

> 69:     private Mac prf;
> 70:     @SuppressWarnings("serial")
> 71:     private Cleaner.Cleanable cleaner;

why not directly mark "cleaner" as transient? Then you should not need `@SuppressWarnings` tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204616897

From redestad at openjdk.org  Wed May 24 19:19:00 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 24 May 2023 19:19:00 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4]
In-Reply-To: <JR_1VDYxSCsfv-54ZaW6dZZK0sgePVqLtHIgWeQVlNs=.ccdad947-1311-464a-89a9-4fbf3a432cb9@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
 <JR_1VDYxSCsfv-54ZaW6dZZK0sgePVqLtHIgWeQVlNs=.ccdad947-1311-464a-89a9-4fbf3a432cb9@github.com>
Message-ID: <M1VDkYPffgxlFvVB_XDTBxRpCPT3NdC-JSu4ddA-kE8=.41322482-858e-4a0d-b26b-e4e634be519b@github.com>

On Wed, 24 May 2023 16:17:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This provides a solid speedup of about 3-4x over the Java implementation.
>> 
>> I have a vectorized version of this which uses a bunch of tricks to speed it up, but it's complex and can still be improved. We're getting close to ramp down, so I'm submitting this simple intrinsic so that we can get it reviewed in time.
>> 
>> Benchmarks:
>> 
>> 
>> ThunderX (2, I think):
>> 
>> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score         Error  Units
>> Poly1305DigestBench.updateBytes          64              thrpt    3  14078352.014 ? 4201407.966  ops/s
>> Poly1305DigestBench.updateBytes         256              thrpt    3   5154958.794 ? 1717146.980  ops/s
>> Poly1305DigestBench.updateBytes        1024              thrpt    3   1416563.273 ? 1311809.454  ops/s
>> Poly1305DigestBench.updateBytes       16384              thrpt    3     94059.570 ?    2913.021  ops/s
>> Poly1305DigestBench.updateBytes     1048576              thrpt    3      1441.024 ?     164.443  ops/s
>> 
>> Benchmark                        (dataSize)  (provider)   Mode  Cnt        Score        Error  Units
>> Poly1305DigestBench.updateBytes          64              thrpt    3  4516486.795 ? 419624.224  ops/s
>> Poly1305DigestBench.updateBytes         256              thrpt    3  1228542.774 ? 202815.694  ops/s
>> Poly1305DigestBench.updateBytes        1024              thrpt    3   316051.912 ?  23066.449  ops/s
>> Poly1305DigestBench.updateBytes       16384              thrpt    3    20649.561 ?   1094.687  ops/s
>> Poly1305DigestBench.updateBytes     1048576              thrpt    3      310.564 ?     31.053  ops/s
>> 
>> Apple M1:
>> 
>> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
>> Poly1305DigestBench.updateBytes          64              thrpt    3  33551968.946 ? 849843.905  ops/s
>> Poly1305DigestBench.updateBytes         256              thrpt    3   9911637.214 ?  63417.224  ops/s
>> Poly1305DigestBench.updateBytes        1024              thrpt    3   2604370.740 ?  29208.265  ops/s
>> Poly1305DigestBench.updateBytes       16384              thrpt    3    165183.633 ?   1975.998  ops/s
>> Poly1305DigestBench.updateBytes     1048576              thrpt    3      2587.132 ?     40.240  ops/s
>> 
>> Benchmark                        (dataSize)  (provider)   Mode  Cnt         Score        Error  Units
>> Poly1305DigestBench.updateBytes          64              thrpt    3  12373649.589 ? 184757.721  ops/s
>> Poly1305DigestBench.upd...
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks for your patience in answering my questions and addressing my comments.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14085#pullrequestreview-1442592376

From mbalao at openjdk.org  Wed May 24 19:27:08 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 24 May 2023 19:27:08 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <cOdMxB-RhdE0UQMEz7S7CAKtB2bOUtyjtBwF3hKA2DE=.296c398f-2be0-4a9a-bdb9-2336870e959a@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <cOdMxB-RhdE0UQMEz7S7CAKtB2bOUtyjtBwF3hKA2DE=.296c398f-2be0-4a9a-bdb9-2336870e959a@github.com>
Message-ID: <I-RAdYFHa3EtwW8rnIpaTuOrR0lvnsVu2_sJqJSrdRg=.7347b0ce-b7e3-4630-8948-42a0194ab4bb@github.com>

On Wed, 24 May 2023 18:36:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java line 71:
> 
>> 69:     private Mac prf;
>> 70:     @SuppressWarnings("serial")
>> 71:     private Cleaner.Cleanable cleaner;
> 
> why not directly mark "cleaner" as transient? Then you should not need `@SuppressWarnings` tag.

We thought about transient and then changed to suppress the warning to keep consistency with ```private Mac prf```. I'll change both to transient then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204661418

From mullan at openjdk.org  Wed May 24 19:36:23 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 24 May 2023 19:36:23 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v17]
In-Reply-To: <ida3mujwIQIHFT6PiBNIKwv4hzOyHX503iN050lND_g=.e6ea1f2f-cddb-4cc8-a1ce-62cf7a348d22@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <ida3mujwIQIHFT6PiBNIKwv4hzOyHX503iN050lND_g=.e6ea1f2f-cddb-4cc8-a1ce-62cf7a348d22@github.com>
Message-ID: <grOZPzqB_E4bnPBCu5n018hjFV0ElrGLVri-ld2ywNo=.f53aa518-0a94-4b87-b5a2-174f23dcdbfd@github.com>

On Thu, 18 May 2023 19:11:32 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed dead code, accepted code style suggestions.

src/java.base/share/classes/sun/security/provider/HSS.java line 156:

> 154:             if ((inLen < (24 + m)) || (checkExactLength && (inLen != (24 + m))) ||
> 155:                     !lmsParams.hasSameHash(lmotsParams)) {
> 156:                 throw new InvalidKeyException("Wrong LMS public Key length");

s/Key/key/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1204658926

From valeriep at openjdk.org  Wed May 24 20:00:06 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 24 May 2023 20:00:06 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
Message-ID: <eKXzRK8fIc4q2TDKWh11_mI7Bt4I27re7iY2k7eJKyY=.7d9575b3-f3fe-439d-a105-2641afb03a18@github.com>

On Tue, 23 May 2023 19:29:47 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 517:

> 515:         @Override
> 516:         public char[] getPassword() {
> 517:             return password.clone();

Would you consider throw IllegalStateException if password is cleared? This would help flag the wrong usage case of calling getPassword() after the password has been cleared.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204693499

From mbalao at openjdk.org  Wed May 24 20:29:15 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 24 May 2023 20:29:15 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <eKXzRK8fIc4q2TDKWh11_mI7Bt4I27re7iY2k7eJKyY=.7d9575b3-f3fe-439d-a105-2641afb03a18@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <eKXzRK8fIc4q2TDKWh11_mI7Bt4I27re7iY2k7eJKyY=.7d9575b3-f3fe-439d-a105-2641afb03a18@github.com>
Message-ID: <3mMwN6_EHlM6fQa5PQXabDEEQbIJ6ApNlnfzTUHpEG8=.9a99433d-a332-41c0-9f11-57196065e93e@github.com>

On Wed, 24 May 2023 19:56:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 517:
> 
>> 515:         @Override
>> 516:         public char[] getPassword() {
>> 517:             return password.clone();
> 
> Would you consider throw IllegalStateException if password is cleared? This would help flag the wrong usage case of calling getPassword() after the password has been cleared.

Sounds good

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204725201

From mbalao at redhat.com  Wed May 24 21:03:15 2023
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 24 May 2023 17:03:15 -0400
Subject: RFD: Services lockdown for security providers
In-Reply-To: <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
 <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>
Message-ID: <b95af756-d4ff-fd7d-3c95-e5f6678ce3d1@redhat.com>

Hi,

Thanks Anthony for your feedback.

We've been exploring the syntax and semantics for this new property 
further, with the goal of making it more consistent and simple while 
retaining expressiveness power. We understand the importance of clarity 
to minimize the risk of security providers, service types or algorithms 
being unexpectedly enabled.

In this new iteration of the proposal, we explore a filter that has 
similarities to the serialization filter (jdk.serialFilter). We think 
that it could be beneficial to leverage on a specification to which the 
user is familiar already.


General structure
====================

jdk.security.providers.filter=pattern-1; pattern-2; ...; pattern-n

The property jdk.security.providers.filter is an overrideable Security 
property. Thus, a System property with the same name exists and, when 
specified, overrides any value in its Security counterpart. When not 
specified (value is null), filtering capabilities are completely 
disabled: all installed security providers, service types and algorithms 
are allowed. If any of these properties are set during run time, the 
filter could be initialized already and the new value may not take effect.

When filtering capabilities are enabled, each service is checked against 
the filter before registration. Notice that this affects both the 
initial list of security providers as well as those dynamically 
installed during run time. Once a service is registered, instances of it 
can be obtained and used without any other checks that could affect 
performance.

The registration of a service involves a combination of a security 
provider, service type and algorithm. Each combination is evaluated 
against the filter patterns, from left to right. When a pattern matches 
?or, in other words, the rule concerns the service to be registered?, a 
decision is made: the service will be allowed or denied. When a decision 
is made, remaining patterns are not checked for the service under 
consideration. When all patterns are checked and a decision is not made, 
the default behavior is to deny the service registration.

Contrary to the serialization filter, white spaces between patterns do 
not have any significance.


Pattern matching
=====================================================

pattern := ! security-provider.service-type.algorithm

pattern := security-provider.service-type.algorithm

A canonical pattern consists of 3 hierarchical levels separated by ".". 
 From left to right in lexicographic order, these levels denote a 
security provider, a service type and an algorithm. If a pattern starts 
with "!", the decision made upon matching is to deny the service 
registration. Otherwise, the service registration is allowed. White 
spaces between "!" and the rest of the pattern do not have any significance.

For a match to be successful, the security provider name, the service 
type and the algorithm have to match the pattern exactly (case 
insensitive). If the service type of a security provider interprets the 
algorithm as a transformation composed of different parts, the full 
transformation has to be specified in the pattern: the filter takes a 
conservative approach and does not make any assumptions of what an 
algorithm name means. For example, "AES" as the algorithm of a canonical 
filter pattern will not match an "AES/ECB/PKCS5Padding" transformation.

If an algorithm alias is specified in the filter pattern, a service 
registering the alias will be matched.

For convenience, it's possible to specify patterns in non-canonical forms:

1) At any level, the security provider, the service type or the 
algorithm name can contain wildcards ("*") to represent zero or more 
repetitions of any character;

2) The .algorithm part can be omitted to imply all algorithms under the 
security provider and service type;

3) The .service-type.algorithm part can be omitted to imply all service 
types and algorithms under the security provider; and,

4) The non-canonical form #1 can be combined with either #2 or #3.


Security provider, service type and algorithm names escaping
=================================================================

If the security provider, service type or algorithm name contains any of 
the characters "\", ".", ";" or "*", they have to be escaped by 
prepending the character "\". If the character "\" is found not escaping 
a character, it's silently discarded.

White spaces are discarded at the beginning and end of names.

It's worth mentioning that the described escaping rules apply to the 
jdk.security.providers.filter property value as read in 
java.lang.System::getProperty or java.security.Security::getProperty. 
Additional escaping might be needed depending on how the property is 
passed. For example, Security properties require "\" characters to be 
escaped. Thus, to match a provider name whose name is "\.", a filter 
would require the "jdk.security.providers.filter=\\\\\\." entry in the 
java.security file. See more about this in java.util.Properties::load [1].


Examples (correct)
====================

--

Enable all security providers, service types and algorithms:

jdk.security.providers.filter=

or

jdk.security.providers.filter=*

or

jdk.security.providers.filter=*.*

or

jdk.security.providers.filter=*.*.*

--

Enable everything except for the MD5 algorithm in MessageDigest services 
when implemented by the SUN security provider:

jdk.security.providers.filter=!SUN.MessageDigest.MD5; *

--

Enable everything except for the MD5 algorithm in MessageDigest 
services, irrespective of the security provider:

jdk.security.providers.filter=!*.MessageDigest.MD5; *

--

Enable everything except for algorithms using MD5, irrespective of the 
security provider and the service type:

jdk.security.providers.filter=!*.*.*MD5*; *

Notice that in this case there are wildcards at the beginning and end of 
the algorithm name. The reason is to match MD5 uses in algorithms such 
as HmacMD5, MD5withRSA, PBEWithMD5AndDES, etc.

--

Enable everything except for the RC4 algorithm in Cipher services when 
implemented by the SunJCE security provider:

jdk.security.providers.filter=!SunJCE.Cipher.ARCFOUR; *

or

jdk.security.providers.filter=!SunJCE.Cipher.RC4; *

or

jdk.security.providers.filter=!SunJCE.Cipher.1\.2\.840\.113549\.3\.4; *

--

Enable the SUN security provider only, with all its service types and 
algorithms. Other security providers must be disabled.

jdk.security.providers.filter=SUN

--

Enable the SUN security provider only, with all its service types and 
algorithms except for MessageDigest. Other security providers must be 
disabled.

jdk.security.providers.filter=!SUN.MessageDigest; SUN

--


Examples (mistakes)
====================

--

Enable everything except for the MD5 algorithm, irrespective of the 
security provider and the service type:

jdk.security.providers.filter=*; !*.*.MD5

This is wrong because the pattern "*" is matched first and a decision 
allowing MD5 will be made immediately after. The pattern "!*.*.MD5" will 
never be checked.

--

Enable all SUN service types except for MessageDigest. Disable other 
security providers.

jdk.security.providers.filter=!SUN.MessageDigest

While non-SUN security providers are effectively disabled, this is wrong 
because SUN services other than MessageDigest will not match any pattern 
and, by default, the decision is to deny registration.

--

Enable the SunPKCS11 security provider only.

jdk.security.providers.filter=SunPKCS11

This is wrong because the SunPKCS11 provider has to be identified by its 
name instead of its class. A possible name would have the form of 
SunPKCS11-NAME. In a filter, this can be matched either by 
"SunPKCS11-NAME" or "SunPKCS11-*".

--


Look forward to your thoughts.

Thanks.-


--
[1] - 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Properties.html#load%28java.io.Reader%29

(?) - Thanks to Francisco Ferrari (@fferrari) for his contributions to 
this proposal.




On 2/24/23 14:49, Anthony Scarpino wrote:
> Hi Martin,
> 
> Interesting proposal.? I think Alternative 1 is a better direction to 
> explore from a code structure standpoint.? If I remember correctly, 
> Preferred Provider is accessed when getting a service or instance of the 
> algorithm.? That happens on a per-operation basis.? What you describe is 
> something that would reshape contents of the ProviderList where 
> algorithms or services would not be in the list at all.? That is were I 
> think #2 gets too complex in trying to handle both in the same property. 
>  ?#2 may end up putting all checks in a per-operation check, hindering 
> performance every time as the list grows.
> 
> I agree this is mostly used in the FIPS situation or where someone wants 
> to disable an algorithm completely, say MD5.? In those cases it's best 
> to just prevent the algorithm from ever being available.
> 
> On the smaller details side that you list.? I think the name ".enabled" 
> doesn't fit, particularly as the first thing in the example disables all 
> Ciphers :).? I don't have any suggestions at this time.
> 
> As far as the syntax.? I think it maybe a bit difficult to parse in code 
> and mental to disable all Ciphers, then enable just for SunJCE and SUN. 
> The SUN '*" confused me until I realized you were enabling Ciphers. 
> Seems too easy to get wrong.? I know you weren't making a formal spec, 
> but we have to start somewhere.
> 
> thanks
> 
> Tony
> 
> 
> On 2/17/23 10:52 AM, Martin Balao wrote:
>> Hi,
>>
>> We would like to discuss a limitation in the current configuration 
>> capabilities for security providers and possible solutions that we are 
>> exploring (?).
>>
>> As you know, current configuration capabilities in java.security allow 
>> users to install security providers, decide their priority in a list 
>> (security.provider.<n> properties) and even circumvent this priority 
>> for specific algorithms (jdk.security.provider.preferred property). 
>> However, there is no granularity in terms of what service types and 
>> algorithms are enabled once a security provider is installed: it's an 
>> all or nothing scheme. It is worth noting that security providers can 
>> bring with them a diverse range of service types. As an example, the 
>> SUN security provider comes with the following service types: 
>> SecureRandom, Signature, KeyPairGenerator, 
>> AlgorithmParameterGenerator, AlgorithmParameters, KeyFactory, 
>> MessageDigest, CertificateFactory, KeyStore, CertStore, Policy, 
>> Configuration, CertPathBuilder and CertPathValidator [1].
>>
>> In some cases, the user may need to enforce that all cryptographic 
>> primitives come from a specific security provider. This could happen, 
>> for example, when operating in a FIPS-compliant environment or under 
>> strict security policies. To better illustrate, let's say that the 
>> user requires that all cryptographic operations are performed in a 
>> Hardware Security Module (HSM). On the OpenJDK side, this means that 
>> the implementation for Cipher, Signature, Mac and other cryptographic 
>> services must be the one in the SunPKCS11 security provider. Let's 
>> also suppose that other non-cryptographic services such as those for 
>> certificates validation and TLS are required, and their implementation 
>> is in the SUN and SunJSSE security providers respectively. Setting 
>> SunPKCS11 at the highest priority of the list is not a strong 
>> guarantee to ensure that all cryptographic operations come from it: 
>> it's possible that an algorithm for Signature is not implemented in 
>> SunPKCS11 or in its underlying token but in the SUN security provider. 
>> Disabling the SUN security provider wouldn't be an option in this case 
>> because we need its certificates validation service.
>>
>> This problem goes beyond OpenJDK default security providers. Even if 
>> we come up with a new layout for service types, algorithms and 
>> providers ?putting backward compatibility issues aside?, there is 
>> always the possibility that a 3rd party security provider does not 
>> follow any services grouping convention. It might also be the case 
>> that we need to disable a specific algorithm only ?i.e. for 
>> cryptographic policy reasons? and TLS or JAR signing properties fall 
>> short.
>>
>> In our view, it would be beneficial to add more configuration 
>> flexibility and control to the existing API in which any security 
>> provider can be plugged in, in the form of deciding which service 
>> types and algorithms are enabled for each installed provider.
>>
>> There are 2 alternatives that we are exploring to tackle this problem.
>>
>> Alternative #1
>> ===========================
>>
>> Introduce a new security property to decide which service types and 
>> algorithms are enabled for each security provider. The default value 
>> for this property would be empty, which keeps this feature disabled 
>> and all services from installed security providers available.
>>
>> As for the new property's syntax and semantics, we've been considering 
>> an allow-list along the lines of:
>>
>> jdk.security.provider.enabled = security-provider-1 { service-type-1 : 
>> alg-1, ... ; ... } , ...
>>
>> Note: we need a formal syntax specification, this is for illustration 
>> only.
>>
>> As part of the syntax we are considering the use of wildcards (*) to 
>> match multiple security providers, service types and algorithms, and 
>> minus signs (-) to remove service types. When a service type is 
>> removed, the action applies to all algorithms and any attempt to 
>> specify them explicitly would be an error. The minus sign cannot be 
>> used at the algorithm level. We are also thinking that in case of a 
>> partial or total contradiction between conditions, the right-most 
>> value applies on top of the others. If a security provider, service 
>> type or algorithm does not exist, we can simply write a debug warning 
>> and ignore it. As for the name of the algorithms, we can also include 
>> Ciphers transformations.
>>
>> Example:
>>
>> jdk.security.provider.enabled = * { -Cipher }, SunJCE { Cipher : 
>> AES/GCM/NoPadding, DES ; Signature }, SUN { * ; -Signature }
>>
>> This would be interpreted as:
>>
>> ??* Irrespective of the provider (*), Cipher services should be 
>> removed (-). This rule would be superfluous in this case because the 
>> property itself is an allow-list and there is nothing to the left that 
>> enables Cipher service types for any provider.
>> ??* From the SunJCE security provider, Cipher services with 
>> AES/GCM/NoPadding and DES transformations are allowed, and Signature 
>> services with any algorithm are allowed. Notice that there is a 
>> shortcut here: the algorithm list that follows the service name, "': 
>> alg-1, ..." is optional. When omitted all the service's algorithms are 
>> enabled.
>> ??* From the SUN security provider, every service type is allowed 
>> except Signature (recall that a minus sign can only apply to a 
>> service, removing all associated algorithms).
>>
>> It's not the goal of this proposal to invalidate property values that 
>> lead to inconsistent internal states, such as "the Cipher service of 
>> SunJCE depends on AlgorithmParameters from SUN". This is because the 
>> combinations for a check are virtually infinite: there can be 3rd 
>> party security providers with their own semantics and dependencies. In 
>> the same way, we cannot determine at start time any application 
>> dependencies. It's up to the user to analyze all types of dependencies 
>> before setting a value.
>>
>>
>> Alternative #2
>> ===========================
>>
>> Introduce a boolean security property to turn the value of the 
>> existing jdk.security.provider.preferred property into the only 
>> combinations of algorithm, service and provider that are allowed:
>>
>> jdk.security.provider.preferredOnly = true
>>
>> The default value for the new property would be "false", keeping the 
>> current "preferred" behavior in which all algorithms and services from 
>> installed security providers are available.
>>
>> Contrary to Alternative #1, the user has to explicitly list the 
>> algorithms and cannot rely on wildcards to express wide categories 
>> such as "all Cipher algorithms from SunJCE" or "all algorithms from 
>> SunJCE". The use of minus signs to remove service types or algorithms 
>> wouldn't be available either.
>>
>> In order to mitigate the burden on users we can consider extending 
>> jdk.security.provider.preferred syntax as long as we keep 
>> backward-compatibility and stay within the boundaries of a "preferred" 
>> semantics. For example, we can accept a value of 
>> "jdk.security.provider.preferred=SunJCE" to mean that any service and 
>> any algorithm from SunJCE is either preferred or allowed, depending on 
>> the value of jdk.security.provider.preferredOnly. This case would be a 
>> service type and algorithm wildcard. We can also define an 
>> algorithms-only wildcard, such as Cipher.*:SunJCE.
>>
>> Alternative #2 has the advantage of reusing most or all of the 
>> existing syntax. However, it's worth noticing that it implies an 
>> overloaded semantic that can turn confusing or inconvenient in some 
>> cases. As an example, a user that relies on the prioritized security 
>> providers list for most of the algorithms and has only a few preferred 
>> exceptions, would need to express preferences by extension upon 
>> turning on this feature. Alternative #1 keeps preferences and 
>> availability as two separate concepts, in a more clear way.
>>
>>
>> Thanks,
>> Martin.-
>>
>> -- 
>> [1] - 
>> https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D
>> (?) - Thanks to @fferrari for his contributions to this proposal.
>>
> 


From weijun.wang at oracle.com  Wed May 24 22:30:56 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Wed, 24 May 2023 22:30:56 +0000
Subject: RFD: Services lockdown for security providers
In-Reply-To: <b95af756-d4ff-fd7d-3c95-e5f6678ce3d1@redhat.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
 <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>
 <b95af756-d4ff-fd7d-3c95-e5f6678ce3d1@redhat.com>
Message-ID: <FF8E1101-7E69-4D81-9B11-34EF1966A9CD@oracle.com>



> On May 24, 2023, at 5:03 PM, Martin Balao <mbalao at redhat.com> wrote:
> 
>>> To better illustrate, let's say that the user requires that all cryptographic operations are performed in a Hardware Security Module (HSM). On the OpenJDK side, this means that the implementation for Cipher, Signature, Mac and other cryptographic services must be the one in the SunPKCS11 security provider. Let's also suppose that other non-cryptographic services such as those for certificates validation and TLS are required, and their implementation is in the SUN and SunJSSE security providers respectively. Setting SunPKCS11 at the highest priority of the list is not a strong guarantee to ensure that all cryptographic operations come from it: it's possible that an algorithm for Signature is not implemented in SunPKCS11 or in its underlying token but in the SUN security provider. Disabling the SUN security provider wouldn't be an option in this case because we need its certificates validation service.

You listed "Signature" as one of the "cryptographic services", but signature verification is also used in "certificates validation" which is a "non-cryptographic service". Do you mean signing must be in SunPKCS11 but verification needn't be? How do you configure that?

Thanks,
Max


From peter.firmstone at zeus.net.au  Wed May 24 22:48:43 2023
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 25 May 2023 08:48:43 +1000
Subject: RFD: Services lockdown for security providers
In-Reply-To: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
Message-ID: <00e811b6-1942-6246-2992-37e834d7aba9@zeus.net.au>

These are examples of how we currently lock down the JVM, to limit 
providers, policy files are generated using a tool, it may do as an 
interim control measure, until something else is provided, it is of 
course a deprecated feature, subject to future removal, but it may do 
the job temporarily, without introducing code dependencies.

https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#LL194C27-L194C27

https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L621

https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L644

https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L688

-- 
Regards,
  
Peter.

On 18/02/2023 4:52 am, Martin Balao wrote:
> Hi,
>
> We would like to discuss a limitation in the current configuration 
> capabilities for security providers and possible solutions that we are 
> exploring (?).
>
> As you know, current configuration capabilities in java.security allow 
> users to install security providers, decide their priority in a list 
> (security.provider.<n> properties) and even circumvent this priority 
> for specific algorithms (jdk.security.provider.preferred property). 
> However, there is no granularity in terms of what service types and 
> algorithms are enabled once a security provider is installed: it's an 
> all or nothing scheme. It is worth noting that security providers can 
> bring with them a diverse range of service types. As an example, the 
> SUN security provider comes with the following service types: 
> SecureRandom, Signature, KeyPairGenerator, 
> AlgorithmParameterGenerator, AlgorithmParameters, KeyFactory, 
> MessageDigest, CertificateFactory, KeyStore, CertStore, Policy, 
> Configuration, CertPathBuilder and CertPathValidator [1].
>
> In some cases, the user may need to enforce that all cryptographic 
> primitives come from a specific security provider. This could happen, 
> for example, when operating in a FIPS-compliant environment or under 
> strict security policies. To better illustrate, let's say that the 
> user requires that all cryptographic operations are performed in a 
> Hardware Security Module (HSM). On the OpenJDK side, this means that 
> the implementation for Cipher, Signature, Mac and other cryptographic 
> services must be the one in the SunPKCS11 security provider. Let's 
> also suppose that other non-cryptographic services such as those for 
> certificates validation and TLS are required, and their implementation 
> is in the SUN and SunJSSE security providers respectively. Setting 
> SunPKCS11 at the highest priority of the list is not a strong 
> guarantee to ensure that all cryptographic operations come from it: 
> it's possible that an algorithm for Signature is not implemented in 
> SunPKCS11 or in its underlying token but in the SUN security provider. 
> Disabling the SUN security provider wouldn't be an option in this case 
> because we need its certificates validation service.
>
> This problem goes beyond OpenJDK default security providers. Even if 
> we come up with a new layout for service types, algorithms and 
> providers ?putting backward compatibility issues aside?, there is 
> always the possibility that a 3rd party security provider does not 
> follow any services grouping convention. It might also be the case 
> that we need to disable a specific algorithm only ?i.e. for 
> cryptographic policy reasons? and TLS or JAR signing properties fall 
> short.
>
> In our view, it would be beneficial to add more configuration 
> flexibility and control to the existing API in which any security 
> provider can be plugged in, in the form of deciding which service 
> types and algorithms are enabled for each installed provider.
>
> There are 2 alternatives that we are exploring to tackle this problem.
>
> Alternative #1
> ===========================
>
> Introduce a new security property to decide which service types and 
> algorithms are enabled for each security provider. The default value 
> for this property would be empty, which keeps this feature disabled 
> and all services from installed security providers available.
>
> As for the new property's syntax and semantics, we've been considering 
> an allow-list along the lines of:
>
> jdk.security.provider.enabled = security-provider-1 { service-type-1 : 
> alg-1, ... ; ... } , ...
>
> Note: we need a formal syntax specification, this is for illustration 
> only.
>
> As part of the syntax we are considering the use of wildcards (*) to 
> match multiple security providers, service types and algorithms, and 
> minus signs (-) to remove service types. When a service type is 
> removed, the action applies to all algorithms and any attempt to 
> specify them explicitly would be an error. The minus sign cannot be 
> used at the algorithm level. We are also thinking that in case of a 
> partial or total contradiction between conditions, the right-most 
> value applies on top of the others. If a security provider, service 
> type or algorithm does not exist, we can simply write a debug warning 
> and ignore it. As for the name of the algorithms, we can also include 
> Ciphers transformations.
>
> Example:
>
> jdk.security.provider.enabled = * { -Cipher }, SunJCE { Cipher : 
> AES/GCM/NoPadding, DES ; Signature }, SUN { * ; -Signature }
>
> This would be interpreted as:
>
> ?* Irrespective of the provider (*), Cipher services should be removed 
> (-). This rule would be superfluous in this case because the property 
> itself is an allow-list and there is nothing to the left that enables 
> Cipher service types for any provider.
> ?* From the SunJCE security provider, Cipher services with 
> AES/GCM/NoPadding and DES transformations are allowed, and Signature 
> services with any algorithm are allowed. Notice that there is a 
> shortcut here: the algorithm list that follows the service name, "': 
> alg-1, ..." is optional. When omitted all the service's algorithms are 
> enabled.
> ?* From the SUN security provider, every service type is allowed 
> except Signature (recall that a minus sign can only apply to a 
> service, removing all associated algorithms).
>
> It's not the goal of this proposal to invalidate property values that 
> lead to inconsistent internal states, such as "the Cipher service of 
> SunJCE depends on AlgorithmParameters from SUN". This is because the 
> combinations for a check are virtually infinite: there can be 3rd 
> party security providers with their own semantics and dependencies. In 
> the same way, we cannot determine at start time any application 
> dependencies. It's up to the user to analyze all types of dependencies 
> before setting a value.
>
>
> Alternative #2
> ===========================
>
> Introduce a boolean security property to turn the value of the 
> existing jdk.security.provider.preferred property into the only 
> combinations of algorithm, service and provider that are allowed:
>
> jdk.security.provider.preferredOnly = true
>
> The default value for the new property would be "false", keeping the 
> current "preferred" behavior in which all algorithms and services from 
> installed security providers are available.
>
> Contrary to Alternative #1, the user has to explicitly list the 
> algorithms and cannot rely on wildcards to express wide categories 
> such as "all Cipher algorithms from SunJCE" or "all algorithms from 
> SunJCE". The use of minus signs to remove service types or algorithms 
> wouldn't be available either.
>
> In order to mitigate the burden on users we can consider extending 
> jdk.security.provider.preferred syntax as long as we keep 
> backward-compatibility and stay within the boundaries of a "preferred" 
> semantics. For example, we can accept a value of 
> "jdk.security.provider.preferred=SunJCE" to mean that any service and 
> any algorithm from SunJCE is either preferred or allowed, depending on 
> the value of jdk.security.provider.preferredOnly. This case would be a 
> service type and algorithm wildcard. We can also define an 
> algorithms-only wildcard, such as Cipher.*:SunJCE.
>
> Alternative #2 has the advantage of reusing most or all of the 
> existing syntax. However, it's worth noticing that it implies an 
> overloaded semantic that can turn confusing or inconvenient in some 
> cases. As an example, a user that relies on the prioritized security 
> providers list for most of the algorithms and has only a few preferred 
> exceptions, would need to express preferences by extension upon 
> turning on this feature. Alternative #1 keeps preferences and 
> availability as two separate concepts, in a more clear way.
>
>
> Thanks,
> Martin.-
>
> -- 
> [1] - 
> https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D
> (?) - Thanks to @fferrari for his contributions to this proposal.
>

From peter.firmstone at zeus.net.au  Wed May 24 23:05:36 2023
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 25 May 2023 09:05:36 +1000
Subject: RFD: Services lockdown for security providers
In-Reply-To: <00e811b6-1942-6246-2992-37e834d7aba9@zeus.net.au>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
 <00e811b6-1942-6246-2992-37e834d7aba9@zeus.net.au>
Message-ID: <7390f6bc-83a5-6781-5ad9-911da56feb69@zeus.net.au>

Or this, which is an example of limiting a codebase by it's SHA-384 
signature:

https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L2241

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.

On 25/05/2023 8:48 am, Peter Firmstone wrote:
> These are examples of how we currently lock down the JVM, to limit 
> providers, policy files are generated using a tool, it may do as an 
> interim control measure, until something else is provided, it is of 
> course a deprecated feature, subject to future removal, but it may do 
> the job temporarily, without introducing code dependencies.
>
> https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#LL194C27-L194C27 
>
>
> https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L621 
>
>
> https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L644 
>
>
> https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L688 
>
>

From valeriep at openjdk.org  Wed May 24 23:39:14 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 24 May 2023 23:39:14 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
Message-ID: <fy85rzxpo2ZUpMB6zMnliOIOquXt5f0H9h0zeXZAAss=.ccf62779-952e-4144-a93d-1fe644c2a4c0@github.com>

On Tue, 23 May 2023 19:29:47 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 210:

> 208:                 // because this is a PBE Mac service. In addition to checking
> 209:                 // the key, check that params (if passed) are consistent.
> 210:                 PBEUtil.checkKeyAndParams(key, params, algorithm);

After this call, shouldn't you store key internally as p11Key?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204853313

From valeriep at openjdk.org  Thu May 25 00:15:05 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 25 May 2023 00:15:05 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
Message-ID: <oWXcUWQoRtbjdACuSw2f3trT62XPXsAC3lbLUX3m-2o=.091f1132-5043-4ab8-9428-ad52657d005a@github.com>

On Tue, 23 May 2023 19:29:47 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 112:

> 110:         return pbes2Params.getAlgorithmParameters(
> 111:                 blkSize, pbeAlg, P11Util.getSunJceProvider(),
> 112:                 JCAUtil.getSecureRandom());

The random source should be the one supplied through CipherSpi.engineInit(...) call if there is one available (see line 118). There is Cipher javadoc specifying this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1204871684

From duke at openjdk.org  Thu May 25 14:10:26 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 25 May 2023 14:10:26 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v17]
In-Reply-To: <TqqV5OMokDtsSMZTvCZp1jGI9QAwTjUjktE3rY3jwKA=.3a0b5153-a50f-40dd-b73b-45fa21520086@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <ida3mujwIQIHFT6PiBNIKwv4hzOyHX503iN050lND_g=.e6ea1f2f-cddb-4cc8-a1ce-62cf7a348d22@github.com>
 <TqqV5OMokDtsSMZTvCZp1jGI9QAwTjUjktE3rY3jwKA=.3a0b5153-a50f-40dd-b73b-45fa21520086@github.com>
Message-ID: <KayEkDJC2SR1Ga1ugkqZnWebeV5hiKmHzNiZQgTTNCU=.33a2201b-3fa1-46ae-80c9-053be4b6b018@github.com>

On Wed, 24 May 2023 16:22:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed dead code, accepted code style suggestions.
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 58:
> 
>> 56: 
>> 57:     @Override
>> 58:     protected void engineInitSign(PrivateKey privateKey)
> 
> I think you should also override `engineInitSign(PrivateKey, SecureRandom)` even though the default impl. calls `engineInitSign(PrivateKey)`. It also assigns the `SecureRandom` to the protected `appRandom` field, which is probably best avoided.

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 156:
> 
>> 154:             if ((inLen < (24 + m)) || (checkExactLength && (inLen != (24 + m))) ||
>> 155:                     !lmsParams.hasSameHash(lmotsParams)) {
>> 156:                 throw new InvalidKeyException("Wrong LMS public Key length");
> 
> s/Key/key/

Changed.

> src/java.base/share/classes/sun/security/provider/HSS.java line 664:
> 
>> 662:         protected PublicKey engineGeneratePublic(KeySpec keySpec)
>> 663:                 throws InvalidKeySpecException {
>> 664:             if (keySpec instanceof X509EncodedKeySpec) {
> 
> Can you also use `instanceof x` here and avoid the cast on line 666?

Done.

> src/java.base/share/classes/sun/security/provider/HSS.java line 700:
> 
>> 698:                     return keySpec.cast(new X509EncodedKeySpec(key.getEncoded()));
>> 699:                 }
>> 700:                 throw new InvalidKeySpecException("keySpec is not an X509 one");
> 
> Suggest saying name of class: "keySpec is not an X509EncodedKeySpec"

Said.

> src/java.base/share/classes/sun/security/provider/HSS.java line 787:
> 
>> 785: 
>> 786:         @java.io.Serial
>> 787:         protected Object writeReplace() throws java.io.ObjectStreamException {
> 
> Make this `private` instead of `protected`. Also, add an overridden private `readObject` method that simply throws an exception, ex: 
> 
> `throw new InvalidObjectException("HSS public keys are not directly deserializable");
> `

Privatized writeReplaced() and added readObject().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205575050
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205574950
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205575467
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205575343
PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205575158

From mbaesken at openjdk.org  Thu May 25 14:37:18 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 May 2023 14:37:18 GMT
Subject: RFR: JDK-8308872: enhance logging and some exception in
 krb5/Config.java
Message-ID: <5RaRlndPHhI5EOrPIqvDhZeAah8zeFMu8DvpU0Mlouk=.a588f0a0-b30e-44be-bdae-a43b3350c694@github.com>

There exists already some logging in krb5/Config.java (enabled by -Dsun.security.krb5.debug=true), this could be enhanced for easier analysis of problems. Additionally some exception(s) might be slightly adjusted.

-------------

Commit messages:
 - JDK-8308872

Changes: https://git.openjdk.org/jdk/pull/14151/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308872
  Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14151/head:pull/14151

PR: https://git.openjdk.org/jdk/pull/14151

From duke at openjdk.org  Thu May 25 15:52:25 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 25 May 2023 15:52:25 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v17]
In-Reply-To: <KgyeOH8weryDNNjSch-bHlR9zq1TCkqvw6yPRxQIokw=.ac0be3ec-60d9-4eba-8f92-b1708af134fd@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <ida3mujwIQIHFT6PiBNIKwv4hzOyHX503iN050lND_g=.e6ea1f2f-cddb-4cc8-a1ce-62cf7a348d22@github.com>
 <KgyeOH8weryDNNjSch-bHlR9zq1TCkqvw6yPRxQIokw=.ac0be3ec-60d9-4eba-8f92-b1708af134fd@github.com>
Message-ID: <OsaVMB9VMws2Pkr58YI1MNNzwnVTh7_pmjdQ33WWmuE=.be2ceda9-1010-48e2-b13b-faeeac760448@github.com>

On Wed, 24 May 2023 15:14:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed dead code, accepted code style suggestions.
>
> src/java.base/share/classes/sun/security/provider/HSS.java line 695:
> 
>> 693:                 throw new InvalidKeySpecException("key should not be null");
>> 694:             }
>> 695:             if (key.getFormat().equals("X.509") &&
> 
> Would it make sense to also check if `key` is an instance of `HSSPublicKey`?

I don't think so, the check here is not too heavy, it covers that case and it is called rarely enough that this kind of optimisation would be worthwhile

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13691#discussion_r1205716056

From duke at openjdk.org  Thu May 25 16:00:51 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 25 May 2023 16:00:51 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v18]
In-Reply-To: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
Message-ID: <uYCvKeiHFozJoxiCiLWkiZ_wapi2fYsSb7M-Ptz6chQ=.66d6f195-5843-4ba4-8aa3-7e8295dfc0db@github.com>

> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Addressing Sean's review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13691/files
  - new: https://git.openjdk.org/jdk/pull/13691/files/8f14964c..46326497

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13691&range=16-17

  Stats: 22 lines in 1 file changed: 15 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13691/head:pull/13691

PR: https://git.openjdk.org/jdk/pull/13691

From mullan at openjdk.org  Thu May 25 16:36:19 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 25 May 2023 16:36:19 GMT
Subject: RFR: 8298127: HSS/LMS Signature Verification [v18]
In-Reply-To: <uYCvKeiHFozJoxiCiLWkiZ_wapi2fYsSb7M-Ptz6chQ=.66d6f195-5843-4ba4-8aa3-7e8295dfc0db@github.com>
References: <c8ngm234T6_E_q7AQZzSf3P6TvnAxhrrib83L9KI0e4=.20f31268-b806-4712-8212-95c059e1af2c@github.com>
 <uYCvKeiHFozJoxiCiLWkiZ_wapi2fYsSb7M-Ptz6chQ=.66d6f195-5843-4ba4-8aa3-7e8295dfc0db@github.com>
Message-ID: <Ccgf_lXdKVnjuzmbGbQE1wiMe1D3v3YOtr8Zqz4p2og=.a544d6df-bdf7-4a6c-a1b3-8fc3e5093e9f@github.com>

On Thu, 25 May 2023 16:00:51 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Implement support for Leighton-Micali Signatures (LMS) as described in RFC 8554. LMS is an approved software signing algorithm for CNSA 2.0, with SHA-256/192 parameters recommended.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing Sean's review comments.

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13691#pullrequestreview-1444279703

From mullan at openjdk.org  Thu May 25 19:21:15 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 25 May 2023 19:21:15 GMT
Subject: RFR: 8297878: KEM: Implementation [v18]
In-Reply-To: <YfHJ3qqBwrxM7Ft-CR8SYUUPdSAyn3TLOas8gX870Us=.05ddc735-6275-46f2-82eb-b08364f48b71@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <YfHJ3qqBwrxM7Ft-CR8SYUUPdSAyn3TLOas8gX870Us=.05ddc735-6275-46f2-82eb-b08364f48b71@github.com>
Message-ID: <RZ4Yu4XLSXSrMmdBnGhX6Vuj6dqq9anKhMOASWdtBaQ=.91eab649-6f76-4c9f-a642-25af03e9fda8@github.com>

On Thu, 18 May 2023 17:07:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8297878
>  - Merge branch 'master' into 8297878
>  - to and length and comments
>  - deterministic randomness
>  - Resolve Siba's comment
>  - providerName
>  - more @since and about nulls
>  - Merge branch 'master' into 8297878
>  - no more pk/sk, AIOOBE to IOOBE
>  - small spec change
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/86c6bb79...7cace182

test/jdk/com/sun/crypto/provider/DHKEM/Compliance.java line 62:

> 60:     }
> 61: 
> 62:     // Encapsulated comformance checks

s/comformance/conformance/

test/jdk/javax/crypto/KEM/RSA_KEM.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8149417

bugid is wrong

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1205831599
PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1205918247

From valeriep at openjdk.org  Thu May 25 19:33:10 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 25 May 2023 19:33:10 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
Message-ID: <s4KBfLBf28vfb0MJxJ-f6oApOE2rw7aTO0BzhOdssno=.f3fe4059-42ce-4841-aaf3-a4b6c2ab0d06@github.com>

On Tue, 23 May 2023 19:29:47 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 214:

> 212:     protected int engineGetKeySize(Key key)
> 213:             throws InvalidKeyException {
> 214:         return cipher.engineGetKeySize(key);

I am not too sure that this would work for all types of key... Based on the current impl, cipher is an AES cipher, but the specified key here can be P11Key or a PBEKey object. The key algorithms for both would be PBE-related, but then you are using a AES cipher to retrieve the key size?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205929004

From valeriep at openjdk.org  Thu May 25 20:29:11 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 25 May 2023 20:29:11 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
Message-ID: <ma2h-xonfuTGxyW7-TU7qjxRXyC6sD8fney7DzU9iz8=.29e9c63b-c460-440c-a22c-c545c2abf61f@github.com>

On Tue, 23 May 2023 19:29:47 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 34:

> 32: import java.nio.charset.Charset;
> 33: import java.security.*;
> 34: import java.util.Arrays;

Not used?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 36:

> 34: import java.util.Arrays;
> 35: 
> 36: import jdk.internal.access.SharedSecrets;

Not used?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 93:

> 91:         while (passwordBytes.hasRemaining()) {
> 92:             encPassword[i] = (char) (passwordBytes.get() & 0xFF);
> 93:             passwordBytes.put(i++, (byte) 0);

nit: add a comment // for erasing bytes in 'passwordBytes'

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java line 213:

> 211:         sb.append(Constants.INDENT);
> 212:         sb.append("pParameter:");
> 213:         sb.append(Constants.NEWLINE);

Is this intended? It seems NEWLINE is not added beforehand for other fields.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205970312
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205969903
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205969334
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1205972334

From duke at openjdk.org  Thu May 25 20:44:04 2023
From: duke at openjdk.org (zhurs)
Date: Thu, 25 May 2023 20:44:04 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
Message-ID: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>

When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

-------------

Commit messages:
 - 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader

Changes: https://git.openjdk.org/jdk/pull/14159/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14159&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308144
  Stats: 190 lines in 2 files changed: 188 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14159/head:pull/14159

PR: https://git.openjdk.org/jdk/pull/14159

From weijun at openjdk.org  Thu May 25 20:51:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 25 May 2023 20:51:55 GMT
Subject: RFR: 8297878: KEM: Implementation [v19]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <uh83jbQUHgsuwtk8evVAqVs7hkjOdp2MqfRUkq1b2j0=.4c8d71c9-03c2-4c9a-8005-105cdbaa1b56@github.com>

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  test update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/7cace182..b3982bdb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=17-18

  Stats: 26 lines in 2 files changed: 14 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256

PR: https://git.openjdk.org/jdk/pull/13256

From weijun at openjdk.org  Thu May 25 20:51:59 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 25 May 2023 20:51:59 GMT
Subject: RFR: 8297878: KEM: Implementation [v18]
In-Reply-To: <YfHJ3qqBwrxM7Ft-CR8SYUUPdSAyn3TLOas8gX870Us=.05ddc735-6275-46f2-82eb-b08364f48b71@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <YfHJ3qqBwrxM7Ft-CR8SYUUPdSAyn3TLOas8gX870Us=.05ddc735-6275-46f2-82eb-b08364f48b71@github.com>
Message-ID: <elEH2LKP3lkg_Si9-EdDWzhlIo0dmwdrRSKyVr781iE=.2f199efc-a57b-4bf0-925f-8c3207d5197a@github.com>

On Thu, 18 May 2023 17:07:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8297878
>  - Merge branch 'master' into 8297878
>  - to and length and comments
>  - deterministic randomness
>  - Resolve Siba's comment
>  - providerName
>  - more @since and about nulls
>  - Merge branch 'master' into 8297878
>  - no more pk/sk, AIOOBE to IOOBE
>  - small spec change
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/288e6369...7cace182

New commit. Resolve Sean's comments. Make SecureRandom settable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13256#issuecomment-1563486984

From weijun at openjdk.org  Thu May 25 20:52:02 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 25 May 2023 20:52:02 GMT
Subject: RFR: 8297878: KEM: Implementation [v18]
In-Reply-To: <RZ4Yu4XLSXSrMmdBnGhX6Vuj6dqq9anKhMOASWdtBaQ=.91eab649-6f76-4c9f-a642-25af03e9fda8@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <YfHJ3qqBwrxM7Ft-CR8SYUUPdSAyn3TLOas8gX870Us=.05ddc735-6275-46f2-82eb-b08364f48b71@github.com>
 <RZ4Yu4XLSXSrMmdBnGhX6Vuj6dqq9anKhMOASWdtBaQ=.91eab649-6f76-4c9f-a642-25af03e9fda8@github.com>
Message-ID: <4_pxCr3QWPRRMsPkicNfa1JsdKR93-l7Aonswz84cSA=.15631de8-465d-46b6-bd0e-a6ad67c1075f@github.com>

On Thu, 25 May 2023 19:17:51 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8297878
>>  - Merge branch 'master' into 8297878
>>  - to and length and comments
>>  - deterministic randomness
>>  - Resolve Siba's comment
>>  - providerName
>>  - more @since and about nulls
>>  - Merge branch 'master' into 8297878
>>  - no more pk/sk, AIOOBE to IOOBE
>>  - small spec change
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/288e6369...7cace182
>
> test/jdk/javax/crypto/KEM/RSA_KEM.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8149417
> 
> bugid is wrong

Oops, where did I copy it from?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13256#discussion_r1205987629

From mullan at openjdk.org  Thu May 25 21:09:13 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 25 May 2023 21:09:13 GMT
Subject: RFR: 8297878: KEM: Implementation [v19]
In-Reply-To: <uh83jbQUHgsuwtk8evVAqVs7hkjOdp2MqfRUkq1b2j0=.4c8d71c9-03c2-4c9a-8005-105cdbaa1b56@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
 <uh83jbQUHgsuwtk8evVAqVs7hkjOdp2MqfRUkq1b2j0=.4c8d71c9-03c2-4c9a-8005-105cdbaa1b56@github.com>
Message-ID: <ZrB_MhMiBsHUzfzwdHoBiJkel6HtKTxOJN1jDeFUeas=.bcec85af-5c8e-4669-9a8a-772892699ec5@github.com>

On Thu, 25 May 2023 20:51:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test update

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13256#pullrequestreview-1444650953

From valeriep at openjdk.org  Thu May 25 21:33:12 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 25 May 2023 21:33:12 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
Message-ID: <i6D18Wzqw6-YxisELTKXu25wCD4VdvRVuGaVmfAyl8E=.690e0355-80ff-4c8d-9bfb-fbda2f6dd9d1@github.com>

On Tue, 23 May 2023 19:29:47 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 2:

> 1: /*
> 2:  * Copyright (c) 2003, 2023, Oracle and/or its affiliates. All rights reserved.

No changes in this file, should not update the year?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206022563

From mbalao at openjdk.org  Thu May 25 21:39:10 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 25 May 2023 21:39:10 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <fy85rzxpo2ZUpMB6zMnliOIOquXt5f0H9h0zeXZAAss=.ccf62779-952e-4144-a93d-1fe644c2a4c0@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <fy85rzxpo2ZUpMB6zMnliOIOquXt5f0H9h0zeXZAAss=.ccf62779-952e-4144-a93d-1fe644c2a4c0@github.com>
Message-ID: <lJ7d3YR5IA-3R_p2mybbLs9N1sVxKwcOZWnGIv5Sj9Y=.1426ec37-5bf1-4b51-b7ef-f9a23f20cab7@github.com>

On Wed, 24 May 2023 23:35:55 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java line 210:
> 
>> 208:                 // because this is a PBE Mac service. In addition to checking
>> 209:                 // the key, check that params (if passed) are consistent.
>> 210:                 PBEUtil.checkKeyAndParams(key, params, algorithm);
> 
> After this call, shouldn't you store key internally as p11Key? Not sure if this is being taken care of by the P11SecretKeyFactory.convertKey(...) call on line 248.

The key is stored as in the internal field p11Key a bit later. The reason is because we need P11SecretKeyFactory::convertKey to check if the P11 key is from a different token and, eventually, re-derive it. The path taken is the same as for non-PBE Mac services. It's only in the PBE Mac case in which we had to derive the PBE key that we have absolute guarantees that calling P11SecretKeyFactory::convertKey would be useless, and we cut it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206027982

From dfuchs at openjdk.org  Thu May 25 21:43:55 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 25 May 2023 21:43:55 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <ItT6wFvg6mZlISFClWaOA1oiT_UD-kNstEIrkZsbsTw=.5f0ecfa7-ae0e-46dc-a89c-e0e265bcf7a7@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

Hi, thanks a lot for the bug report and the fix.

The fix looks reasonable, however the test fails quite consistently in our CI on many platform:


java.lang.RuntimeException: Too large intermediate buffer, server sent 10x300000 bytes
	at HttpsBackpressureTest.main(HttpsBackpressureTest.java:87)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1583)


I'm not sure I understand the logic of the test either. Does it depend on some assumption about the size of the socket buffers? From where do the various constants in the test come from? Also could there be a better solution than `sleep(2000)` ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1563538468

From duke at openjdk.org  Thu May 25 22:10:55 2023
From: duke at openjdk.org (zhurs)
Date: Thu, 25 May 2023 22:10:55 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <ItT6wFvg6mZlISFClWaOA1oiT_UD-kNstEIrkZsbsTw=.5f0ecfa7-ae0e-46dc-a89c-e0e265bcf7a7@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
 <ItT6wFvg6mZlISFClWaOA1oiT_UD-kNstEIrkZsbsTw=.5f0ecfa7-ae0e-46dc-a89c-e0e265bcf7a7@github.com>
Message-ID: <sDoh9D7x8WFB3hIzWo2S_VpEnJ1tYG9Q1p0a5wB7jIE=.e8451673-06a3-411b-b1bc-2e0377108802@github.com>

On Thu, 25 May 2023 21:40:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
>> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.
>
> Hi, thanks a lot for the bug report and the fix.
> 
> The fix looks reasonable, however the test fails quite consistently in our CI on many platform:
> 
> 
> java.lang.RuntimeException: Too large intermediate buffer, server sent 10x300000 bytes
> 	at HttpsBackpressureTest.main(HttpsBackpressureTest.java:87)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> 
> I'm not sure I understand the logic of the test either. Does it depend on some assumption about the size of the socket buffers? From where do the various constants in the test come from? Also could there be a better solution than `sleep(2000)` ?

@dfuch, thanks for your lightning-fast reply.

Indeed it relies on buffer sizes.
The test works for me on Linux and Mac, but real life seems to be more diverse.

Unfortunately, I don't know how else to reproduce the problem and test the fix - the tested logic is hidden deep.

It may be possible to commit the fix without unit-test?
The regression is not affected, and the behavior can be checked manually using the recipe from the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1563562380

From mbalao at redhat.com  Thu May 25 22:40:04 2023
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 25 May 2023 18:40:04 -0400
Subject: RFD: Services lockdown for security providers
In-Reply-To: <FF8E1101-7E69-4D81-9B11-34EF1966A9CD@oracle.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
 <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>
 <b95af756-d4ff-fd7d-3c95-e5f6678ce3d1@redhat.com>
 <FF8E1101-7E69-4D81-9B11-34EF1966A9CD@oracle.com>
Message-ID: <841a0cf8-b0c4-f467-7910-0c30c6f73ecd@redhat.com>

Hi Max,

In this example, we want certificates validation from SUN but signature 
verification from SunPKCS11 (only). The problem with the current design 
is that there could be a signature algorithm implemented in SUN but not 
in SunPKCS11. If that is the case, there is no way to prevent SUN from 
verifying the signature: any order of security providers preference 
(i.e. SUN -> SunPKCS11 or SunPKCS11 -> SUN) would lead to SUN bringing 
the implementation. What we propose is a way to cherry-pick what we want 
(or what we don't) from each security provider in a configurable way.

Regards,
Martin.-


On 5/24/23 18:30, Wei-Jun Wang wrote:
> 
> 
>> On May 24, 2023, at 5:03 PM, Martin Balao <mbalao at redhat.com> wrote:
>>
>>>> To better illustrate, let's say that the user requires that all cryptographic operations are performed in a Hardware Security Module (HSM). On the OpenJDK side, this means that the implementation for Cipher, Signature, Mac and other cryptographic services must be the one in the SunPKCS11 security provider. Let's also suppose that other non-cryptographic services such as those for certificates validation and TLS are required, and their implementation is in the SUN and SunJSSE security providers respectively. Setting SunPKCS11 at the highest priority of the list is not a strong guarantee to ensure that all cryptographic operations come from it: it's possible that an algorithm for Signature is not implemented in SunPKCS11 or in its underlying token but in the SUN security provider. Disabling the SUN security provider wouldn't be an option in this case because we need its certificates validation service.
> 
> You listed "Signature" as one of the "cryptographic services", but signature verification is also used in "certificates validation" which is a "non-cryptographic service". Do you mean signing must be in SunPKCS11 but verification needn't be? How do you configure that?
> 
> Thanks,
> Max
> 


From cslucas at openjdk.org  Thu May 25 22:54:15 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 25 May 2023 22:54:15 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v14]
In-Reply-To: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
Message-ID: <DxBJJAG4B9PjG74ga0TIPaQrMYEWb-zFpTmtqAj21xw=.107db450-5c68-4273-a6d7-96fbca1f7447@github.com>

> Can I please get reviews for this PR? 
> 
> The most common and frequent use of NonEscaping Phis merging object allocations is for debugging information. The two graphs below show numbers for Renaissance and DaCapo benchmarks - similar results are obtained for all other applications that I tested.
> 
> With what frequency does each IR node type occurs as an allocation merge user? I.e., if the same node type uses a Phi N times the counter is incremented by N:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280517-4dcf5871-2564-4207-b49e-22aee47fa49d.png)
> 
> What are the most common users of allocation merges? I.e., if the same node type uses a Phi N times the counter is incremented by 1:
> 
> ![image](https://user-images.githubusercontent.com/2249648/222280608-ca742a4e-1622-4e69-a778-e4db6805ea02.png)
> 
> This PR adds support scalar replacing allocations participating in merges used as debug information OR as a base for field loads. I plan to create subsequent PRs to enable scalar replacement of merges used by other node types (CmpP is next on the list) subsequently.
> 
> The approach I used for _rematerialization_ is pretty straightforward. It consists basically of the following. 1) New IR node (suggested by V. Kozlov), named SafePointScalarMergeNode, to represent a set of SafePointScalarObjectNode; 2) Each scalar replaceable input participating in a merge will get a SafePointScalarObjectNode like if it weren't part of a merge. 3) Add a new Class to support the rematerialization of SR objects that are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize debug information related to allocation merges; 5) Patch C2 to generate unique types for SR objects participating in some allocation merges.
> 
> The approach I used for _enabling the scalar replacement of some of the inputs of the allocation merge_ is also pretty straightforward: call `MemNode::split_through_phi` to, well, split AddP->Load* through the merge which will render the Phi useless.
> 
> I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't see regression. I also experimented with several applications and didn't see any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related failures.

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Catching up with master branch.
   
   Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
 - Address PR review 6: refactoring around rematerialization & improve test cases.
 - Address PR review 5: refactor on rematerialization & add tests.
 - Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
 - Address part of PR review 4 & fix a bug setting only_candidate
 - Catching up with master
   
   Merge remote-tracking branch 'origin/master' into rematerialization-of-merges
 - Fix tests. Remember previous reducible Phis.
 - Address PR review 3. Some comments and be able to abort compilation.
 - Merge with Master
 - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/46c4da7f...8f81a7c8

-------------

Changes: https://git.openjdk.org/jdk/pull/12897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=13
  Stats: 2760 lines in 25 files changed: 2508 ins; 113 del; 139 mod
  Patch: https://git.openjdk.org/jdk/pull/12897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897

PR: https://git.openjdk.org/jdk/pull/12897

From vlivanov at openjdk.org  Thu May 25 22:54:15 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 25 May 2023 22:54:15 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v13]
In-Reply-To: <hYEuOI4VfEYMy-dc9EVXl94l6HgVPC6Qpzl-XM9j0mo=.3aa74c45-eb15-4fe7-9d1b-73873f31d7a3@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <Yx1OcjTUO1iQV7ibbT71njBcVZz7-bJsYBRN6Iom94I=.e6657a24-5a0e-4e15-9229-8ef2b49a7fef@github.com>
 <QUC45ZUDN81px7FNYS6xD_Ab9QUaltXctjSNQiUF-JM=.f562109a-036a-4ba1-8f97-9b6bacfad5d4@github.com>
 <hYEuOI4VfEYMy-dc9EVXl94l6HgVPC6Qpzl-XM9j0mo=.3aa74c45-eb15-4fe7-9d1b-73873f31d7a3@github.com>
Message-ID: <ESwD6J1FJEtz7_z6zNcDEJ9X_w2gxYOL87yvbEIjVHQ=.7afcd323-b3f9-4e1d-bcb4-cc1e8c57a1f5@github.com>

On Mon, 22 May 2023 17:56:41 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Are you sure there's no way to end up with nested ObjectMergeValues in presence of iterative EA?
> I don't think so. 

Ok. Please, add asserts to catch such situation and a check which bails out compilation (triggering recompilation w/ ReduceAllocationMerges turned off) if it happens with product binaries.

> So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled.

Please, enhance `AllocationMergesTests` to cover deoptimization (e.g., using WhiteBox API or additional run w/ -XX:+DeoptimizeALot) and ensure that tests are sensitive enough to fail when wrong state is rematerialized.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1559847061
PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1559852990

From weijun at openjdk.org  Thu May 25 23:21:35 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 25 May 2023 23:21:35 GMT
Subject: RFR: 8297878: KEM: Implementation [v20]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <ZfTipB1GmG9FPU_Ipu8y2Dl364ru2WrzO-8LgOhVwds=.0f3906c7-7711-4930-a98e-bccab587022f@github.com>

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  comment for RSA-KEM

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/b3982bdb..2c7ef3d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=18-19

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256

PR: https://git.openjdk.org/jdk/pull/13256

From mbalao at openjdk.org  Thu May 25 23:29:09 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 25 May 2023 23:29:09 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <oWXcUWQoRtbjdACuSw2f3trT62XPXsAC3lbLUX3m-2o=.091f1132-5043-4ab8-9428-ad52657d005a@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <oWXcUWQoRtbjdACuSw2f3trT62XPXsAC3lbLUX3m-2o=.091f1132-5043-4ab8-9428-ad52657d005a@github.com>
Message-ID: <t2K_wkdHz5AV4rItSSL7ojlUjiTPKZH8IPZ1PvWyDmo=.d1e32ba7-be37-4f15-8115-926241047f37@github.com>

On Thu, 25 May 2023 00:11:54 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 112:
> 
>> 110:         return pbes2Params.getAlgorithmParameters(
>> 111:                 blkSize, pbeAlg, P11Util.getSunJceProvider(),
>> 112:                 JCAUtil.getSecureRandom());
> 
> The random source should be the one supplied through CipherSpi.engineInit(...) call if there is one available (see line 118). There is Cipher javadoc specifying this.

Good point. As I see it, the problem is not in the random source itself but in the values. There are a couple of P11PBECipher::engineInit paths in which P11PBECipher initialization succeeds but the pbes2Params does not have the salt, iCount and ivSpec in use. These paths are those in which the P11 key was already derived (it's a P11PBEKey): we check consistency but record nothing for future P11PBECipher::engineGetParameters calls. I think that we can get the right values from the P11PBEKey and PBEParameterSpec. Notice that if the ivSpec is not passed, it's value could be randomly generated in the underlying Cipher. @franferrax what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206085880

From mbalao at openjdk.org  Thu May 25 23:48:12 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 25 May 2023 23:48:12 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <s4KBfLBf28vfb0MJxJ-f6oApOE2rw7aTO0BzhOdssno=.f3fe4059-42ce-4841-aaf3-a4b6c2ab0d06@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <s4KBfLBf28vfb0MJxJ-f6oApOE2rw7aTO0BzhOdssno=.f3fe4059-42ce-4841-aaf3-a4b6c2ab0d06@github.com>
Message-ID: <PptyXPEZBh8EKuxXsKxDXcVRvhuFQV3n43lRx6x6uA0=.6d759490-9170-463a-b181-d7b3a7632ba3@github.com>

On Thu, 25 May 2023 19:30:36 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 214:
> 
>> 212:     protected int engineGetKeySize(Key key)
>> 213:             throws InvalidKeyException {
>> 214:         return cipher.engineGetKeySize(key);
> 
> I am not too sure that this would work for all types of key... Based on the current impl, cipher is an AES cipher, but the specified key here can be P11Key or a PBEKey object. The key algorithms for both would be PBE-related, but then you are using a AES cipher to retrieve the key size?

If the key is a P11PBEKey, the underlying Cipher will call P11SecretKeyFactory::convertKey with a non-PBE service algorithm and, assuming that it's in the same token and that the key is suitable for the service, will return the same key. This case should return the key length used during derivation. If the key is a PBEKey but not a P11PBEKey, there will be a call to P11SecretKeyFactory::convertKey with a non-PBE service algorithm and the key algorithm is PBE. Looks to me that, assuming that the key algorithm is suitable for the service, there will be a key derivation to finally get the length from a derived P11PBEKey. This case should not be different than using a PBEKey in a non-PBE service. @franferrax what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206093462

From mbalao at openjdk.org  Thu May 25 23:52:08 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Thu, 25 May 2023 23:52:08 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <ma2h-xonfuTGxyW7-TU7qjxRXyC6sD8fney7DzU9iz8=.29e9c63b-c460-440c-a22c-c545c2abf61f@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <ma2h-xonfuTGxyW7-TU7qjxRXyC6sD8fney7DzU9iz8=.29e9c63b-c460-440c-a22c-c545c2abf61f@github.com>
Message-ID: <1odt4e9y_NlyscVwUfYvTfFwURwOr_Ar9anouCwoYtU=.b31ab1f7-6499-4227-b3e3-eb9908bcc74f@github.com>

On Thu, 25 May 2023 20:22:03 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 93:
> 
>> 91:         while (passwordBytes.hasRemaining()) {
>> 92:             encPassword[i] = (char) (passwordBytes.get() & 0xFF);
>> 93:             passwordBytes.put(i++, (byte) 0);
> 
> nit: add a comment // for erasing bytes in 'passwordBytes'

Good

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206095317

From weijun.wang at oracle.com  Thu May 25 23:54:58 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Thu, 25 May 2023 23:54:58 +0000
Subject: RFD: Services lockdown for security providers
In-Reply-To: <841a0cf8-b0c4-f467-7910-0c30c6f73ecd@redhat.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
 <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>
 <b95af756-d4ff-fd7d-3c95-e5f6678ce3d1@redhat.com>
 <FF8E1101-7E69-4D81-9B11-34EF1966A9CD@oracle.com>
 <841a0cf8-b0c4-f467-7910-0c30c6f73ecd@redhat.com>
Message-ID: <2E4541EC-3E40-4A39-AE50-3B55E5293587@oracle.com>

I see.

So, the filter will look like this?

   SunPKCS11-Name.Signature.*,!*.Signature.*,*

--Max

> On May 25, 2023, at 6:40 PM, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Max,
> 
> In this example, we want certificates validation from SUN but signature verification from SunPKCS11 (only). The problem with the current design is that there could be a signature algorithm implemented in SUN but not in SunPKCS11. If that is the case, there is no way to prevent SUN from verifying the signature: any order of security providers preference (i.e. SUN -> SunPKCS11 or SunPKCS11 -> SUN) would lead to SUN bringing the implementation. What we propose is a way to cherry-pick what we want (or what we don't) from each security provider in a configurable way.
> 
> Regards,
> Martin.-
> 
> 
> On 5/24/23 18:30, Wei-Jun Wang wrote:
>>> On May 24, 2023, at 5:03 PM, Martin Balao <mbalao at redhat.com> wrote:
>>> 
>>>>> To better illustrate, let's say that the user requires that all cryptographic operations are performed in a Hardware Security Module (HSM). On the OpenJDK side, this means that the implementation for Cipher, Signature, Mac and other cryptographic services must be the one in the SunPKCS11 security provider. Let's also suppose that other non-cryptographic services such as those for certificates validation and TLS are required, and their implementation is in the SUN and SunJSSE security providers respectively. Setting SunPKCS11 at the highest priority of the list is not a strong guarantee to ensure that all cryptographic operations come from it: it's possible that an algorithm for Signature is not implemented in SunPKCS11 or in its underlying token but in the SUN security provider. Disabling the SUN security provider wouldn't be an option in this case because we need its certificates validation service.
>> You listed "Signature" as one of the "cryptographic services", but signature verification is also used in "certificates validation" which is a "non-cryptographic service". Do you mean signing must be in SunPKCS11 but verification needn't be? How do you configure that?
>> Thanks,
>> Max
> 


From mbalao at openjdk.org  Fri May 26 00:07:09 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 May 2023 00:07:09 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <D_TyjFSqX8Kt7vB5-IFqG4gZiaIEKPd_HjrervXzsks=.82f024a0-8b3c-4264-b156-5a874defabb1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <rodHJ4q6YCe62mc7iMNTM1sX5rrxsxhSmPZzoFrCgz0=.aca62528-3ac4-4fad-8829-d8bf410254c6@github.com>
 <D_TyjFSqX8Kt7vB5-IFqG4gZiaIEKPd_HjrervXzsks=.82f024a0-8b3c-4264-b156-5a874defabb1@github.com>
Message-ID: <o-LZAUS1rR70hqAyorvmggQK42UhIJ2ShVMixqei_Gs=.420534ff-a775-4b56-951e-183e3250c294@github.com>

On Tue, 23 May 2023 14:00:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We found several more cases of passwords and encoded keys not cleared that were addressed in out Iteration # 2 commit. These cases were both in Java and native code. We still have doubts about the effectiveness and need for these actions, but prefer to have the discussion on a different channel.
>> 
>> We also found that invalid keys (not starting with the name "PBE") passed to PBES2Core::engineInit or P11PBECipher::engineInit were being cleared and this could be unexpected to the caller. This is related to my comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1199513839). For these cases, we decided not to invoke ::getEncoded and not to clean. As said, we have concerns about these undocumented mutations to objects passed by argument.
>> 
>> No test regressions observed in jdk/com/sun/crypto/provider or jdk/sun/security/pkcs11.
>
> @martinuy I am adding a CSR requirement for this issue. In this Enhancement, you are adding support for new algorithms in a JCE provider. This type of change requires a CSR as you are adding support for algorithms that can be used by applications and not just inside the JDK, thus it is a type of exported interface of JDK scope. For an example of a similar issue, see [JDK-8274174](https://bugs.openjdk.org/browse/JDK-8274174). The CSR should also include details about any behavioral changes or differences that affect use of the algorithms through the standard JCE APIs.

@seanjmullan @valeriepeng , can you please take a look at the proposed [JDK-8308719](https://bugs.openjdk.org/browse/JDK-8308719) CSR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1563647821

From mbalao at redhat.com  Fri May 26 00:15:02 2023
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 25 May 2023 20:15:02 -0400
Subject: RFD: Services lockdown for security providers
In-Reply-To: <2E4541EC-3E40-4A39-AE50-3B55E5293587@oracle.com>
References: <42a97a54-4301-e0f2-c746-b45d63d1b63d@redhat.com>
 <800238c6-56ff-a3b0-7af8-c01c3aa402a0@oracle.com>
 <b95af756-d4ff-fd7d-3c95-e5f6678ce3d1@redhat.com>
 <FF8E1101-7E69-4D81-9B11-34EF1966A9CD@oracle.com>
 <841a0cf8-b0c4-f467-7910-0c30c6f73ecd@redhat.com>
 <2E4541EC-3E40-4A39-AE50-3B55E5293587@oracle.com>
Message-ID: <de26606f-02b3-a4b5-6ef3-aaf6044a96c9@redhat.com>

On 5/25/23 19:54, Wei-Jun Wang wrote:
> So, the filter will look like this?
> 
>     SunPKCS11-Name.Signature.*,!*.Signature.*,*
> 

Yes, that's right. The filter that you showed will do the following:

1) Accept Signature services provided by SunPKCS11-Name, irrespective of 
the algorithm;

2) Block Signature services from all non-SunPKCS11-Name providers; and,

3) Accept anything else (including certificates validation).


From djelinski at openjdk.org  Fri May 26 07:50:56 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 26 May 2023 07:50:56 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <VpEl4v3oeJJGf7hCma44tp9IG-d6T1jyRjemqZN8Kfg=.8338f76a-37e5-4524-9cfe-83b2a774b3bc@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

According to our docs, [clang is a supported compiler for Linux](https://github.com/openjdk/jdk/blob/master/doc/building.md#native-compiler-toolchain-requirements).

Here's an example how warning exclusion is implemented today:
https://github.com/openjdk/jdk/blob/master/make/modules/java.desktop/lib/Awt2dLibraries.gmk#L827

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1563956337

From mbaesken at openjdk.org  Fri May 26 08:04:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 May 2023 08:04:58 GMT
Subject: RFR: JDK-8308872: enhance logging and some exception in
 krb5/Config.java [v2]
In-Reply-To: <5RaRlndPHhI5EOrPIqvDhZeAah8zeFMu8DvpU0Mlouk=.a588f0a0-b30e-44be-bdae-a43b3350c694@github.com>
References: <5RaRlndPHhI5EOrPIqvDhZeAah8zeFMu8DvpU0Mlouk=.a588f0a0-b30e-44be-bdae-a43b3350c694@github.com>
Message-ID: <4UJC2KPBhqZoUpTkK1Ee5V_fcv_6UCI8Rg_xcnZNOmY=.b97a10b2-c572-471d-93a1-319982ec1ffc@github.com>

> There exists already some logging in krb5/Config.java (enabled by -Dsun.security.krb5.debug=true), this could be enhanced for easier analysis of problems. Additionally some exception(s) might be slightly adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  enhance exception

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14151/files
  - new: https://git.openjdk.org/jdk/pull/14151/files/15ab2d27..74cdfe35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14151&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14151&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14151/head:pull/14151

PR: https://git.openjdk.org/jdk/pull/14151

From dfuchs at openjdk.org  Fri May 26 08:29:58 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 08:29:58 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <tHDZDBHPlHFtsFJdP2NYBO-cX0b5AUpfSkuqLbIvh3k=.532b5504-92b9-4995-9fba-b3aa729603c0@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

The HttpClient supports properties that can be used to tune the SEND and RCV buffer sizes. I would not recommend to use them in production unless you absolutely know what you do, because setting them can prevent underlying OD optimizations which in turn can affect performance negatively. However - using them in tests is fair game. If you could explain the relationship between the constants in the test and the assumed socket buffer sizes (on the client size I assume) then we may try to experiment forcing the test's client to use some specific value for SNDBUF and RCVBUF, and see if that works. It may not, but maybe we could explore this possibility before ditching the test. If we notice that there are some platforms where the test always pass reliably we could also experiment with using `@requires` to restrict the test to run on these platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1564006762

From dfuchs at openjdk.org  Fri May 26 08:34:01 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 08:34:01 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <yNsNbfybht3tIQ-lV25F8RDXSRVCZvHq3XfJUQ1wmaM=.16cc32d3-3877-4a28-ae56-88aa9038c965@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

See https://docs.oracle.com/en/java/javase/20/docs/api/java.net.http/module-summary.html

- jdk.httpclient.receiveBufferSize (default: operating system default): The HTTP client[ socket receive buffer size](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/StandardSocketOptions.html#SO_RCVBUF) in bytes.

- jdk.httpclient.sendBufferSize (default: operating system default): The HTTP client socket [send buffer size](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/StandardSocketOptions.html#SO_SNDBUF). Values less than or equal to zero are ignored.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1564011270

From dfuchs at openjdk.org  Fri May 26 08:53:55 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 08:53:55 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <t9GFwrWd3YpTqrBnuZ7TCgAO-qjoT72IxH3GP5JuRC4=.bde198aa-6284-4f30-a489-f03d714c61ac@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

>From the CI results it seems it only passes on macOS and fails consistently on all Linux or Windows flavors. But if it depends on socket buffer sizes it may actually depend on how these machines are configured by default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1564038114

From duke at openjdk.org  Fri May 26 09:20:55 2023
From: duke at openjdk.org (zhurs)
Date: Fri, 26 May 2023 09:20:55 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <gQRy8DtWqKlVlh0oonOd3ImdFILJOT9uPIXQM1_SWEU=.9371a0ff-51cf-49e8-89e8-dbde699e4ed2@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

Thank you, I will look at these options.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1564081579

From aph at openjdk.org  Fri May 26 15:01:56 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 26 May 2023 15:01:56 GMT
Subject: RFR: 8296411: AArch64: Accelerated Poly1305 intrinsics [v4]
In-Reply-To: <M1VDkYPffgxlFvVB_XDTBxRpCPT3NdC-JSu4ddA-kE8=.41322482-858e-4a0d-b26b-e4e634be519b@github.com>
References: <BIQSqMQrUHegfVtNzacsvWAj31FqfNuxdTy2ZtU6mU0=.43db3ae7-a67d-4f33-829a-9125eeb83aa2@github.com>
 <JR_1VDYxSCsfv-54ZaW6dZZK0sgePVqLtHIgWeQVlNs=.ccdad947-1311-464a-89a9-4fbf3a432cb9@github.com>
 <M1VDkYPffgxlFvVB_XDTBxRpCPT3NdC-JSu4ddA-kE8=.41322482-858e-4a0d-b26b-e4e634be519b@github.com>
Message-ID: <Yd1DGYj3ShRb_sNxlVpUKZCiTvXwY5oDFrZ-jptlMPU=.e939db78-ffa9-48b4-941d-2054c16e9dcb@github.com>

On Wed, 24 May 2023 19:16:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Thanks for your patience in answering my questions and addressing my comments.

Thank you for asking questions that made the patch better, and even removed an instruction in what I thought was a tightly-written intrinsic!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14085#issuecomment-1564522080

From cslucas at openjdk.org  Fri May 26 17:46:03 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 26 May 2023 17:46:03 GMT
Subject: RFR: JDK-8287061: Support for rematerializing scalar replaced
 objects participating in allocation merges [v13]
In-Reply-To: <ESwD6J1FJEtz7_z6zNcDEJ9X_w2gxYOL87yvbEIjVHQ=.7afcd323-b3f9-4e1d-bcb4-cc1e8c57a1f5@github.com>
References: <7nqFW-lgT1FzuMHPMUQiCj1ATcV_bQtroolf4V_kCc4=.ccd12605-aad0-433e-ba44-5772d972f05d@github.com>
 <Yx1OcjTUO1iQV7ibbT71njBcVZz7-bJsYBRN6Iom94I=.e6657a24-5a0e-4e15-9229-8ef2b49a7fef@github.com>
 <QUC45ZUDN81px7FNYS6xD_Ab9QUaltXctjSNQiUF-JM=.f562109a-036a-4ba1-8f97-9b6bacfad5d4@github.com>
 <hYEuOI4VfEYMy-dc9EVXl94l6HgVPC6Qpzl-XM9j0mo=.3aa74c45-eb15-4fe7-9d1b-73873f31d7a3@github.com>
 <ESwD6J1FJEtz7_z6zNcDEJ9X_w2gxYOL87yvbEIjVHQ=.7afcd323-b3f9-4e1d-bcb4-cc1e8c57a1f5@github.com>
Message-ID: <SJaqjW3QDCWGNnDbTo1GYECkNTPPaQxJNe_ehHJYcOI=.7c1e3eb1-ac2d-4476-a0c8-59984e6bc436@github.com>

On Tue, 23 May 2023 17:19:23 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> I verified that the new test cases do trigger SR+NSR scenario.
>>> 
>>> How do you test that deoptimization works as expected?
>>> 
>> 
>> I have a copy of the tests in AllocationMergesTests.java in a separate file (not included in this PR) and I run the tests with a tool that compares the output of the test with RAM enabled and disabled. So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled.
>> 
>>> Diagnostic output is still hard to read. On one hand, it's too verbose when it comes to PcDesc/ScopeDesc sections ("pc-bytecode offsets" and "scopes") in nmethod output (enabled either w/ `-XX:+PrintAssembly` or `-XX:CompileCommand=print,...`). On the other hand, it lacks some important details, like `selector` and `merge_ptr` location information which is essential to make sense of debug information at a safepoint in the code.
>>> 
>> 
>> I'll take care of that. I was testing only with PrintDebugInfo.
>> 
>>> FTR `_skip_rematerialization` flag is unused now.
>>> 
>> 
>> yeah, I forgot to remove that. Thanks.
>> 
>>> Speaking of `_only_merge_candidate` flag, I find it easier about the code when the property being tracked is whether the `ObjectValue` is referenced from corresponding JVM state or not. (Maybe call it `is_root()`?) So, `ScopeDesc::objects_to_rematerialize()` would skip everything not referenced from JVM state, but then unconditionally accept anything returned by `ObjectMergeValue::select()` which doesn't need to adjust the flag before returning selected object. Also, it's safer to track the flag status for every `ObjectValues`, even for `ObjectMergeValue`.
>>> 
>> 
>> Sounds like a good idea. I'll do that. Thanks.
>> 
>>> Are you sure there's no way to end up with nested `ObjectMergeValue`s in presence of iterative EA?
>> 
>> I don't think so. This current patch only handle Phis that don't have NULL as input. As part of the reduction process we set at least one of the reducible Phi inputs to NULL. Therefore, subsequent iterations of EA won't reduce the same Phi.
>
>> So, the way I test that deoptimization worked is basically just making sure the tests that "deoptimize" have the same output with RAM enabled and disabled.
> 
> Please, enhance `AllocationMergesTests` to cover deoptimization (e.g., using WhiteBox API or additional run w/ -XX:+DeoptimizeALot) and ensure that tests are sensitive enough to fail when wrong state is rematerialized.

Hi @iwanowww - I pushed some changes to address your latest feedback.

> Please, enhance AllocationMergesTests to cover deoptimization (e.g., using WhiteBox API or additional run w/ -XX:+DeoptimizeALot) and ensure that tests are sensitive enough to fail when wrong state is rematerialized.

I added the "+DeoptimizeALot" flag on the tests execution. I also refactored the tests so that each test is executed in the Interpreter and in C2 with the same parameters so that we can confirm that result of the test with RAM enabled is correct.

> Please, add asserts to catch such situation and a check which bails out compilation (triggering recompilation w/ ReduceAllocationMerges turned off) if it happens with product binaries.

I added a new static method `ConnectionGraph::verify_ram_nodes` that does some verification in the inputs and users of RAM nodes. I decided to call the method after each iteration of EA->IGVN->MacroNodeElimination so that we also check that IGVN or `eliminate_macro_nodes` transformations didn't mess with RAM nodes.

> I didn't propose exactly that, but I like your idea. I'm not against having it cached on ScopeValue side (and serialized in debug info), but implementing it as a query on ScopeDesc does look like a better alternative. [...]

I ended up implementing this a little bit different from what I mentioned earlier. I had some problems with the approach that I described before... In current approach I set the `is_root` flag of ObjectValue's right before the object pool is serialized in output.cpp.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12897#issuecomment-1564718582

From macarte at openjdk.org  Fri May 26 21:25:59 2023
From: macarte at openjdk.org (Mat Carter)
Date: Fri, 26 May 2023 21:25:59 GMT
Subject: RFR: 8306688: Support Windows serialized keystores (SST files)
Message-ID: <Vd015xi-nOLmoJ1vEsnjZEsSl0SDBk9-tCzlCeWNLao=.ec1b00fd-2f90-47d0-8ef8-ac3306134ae6@github.com>

Added ability to load keystores from SST files on Windows.  Example usage:

KeyStore keyStore = KeyStore.getInstance("Windows-SST");
try (FileInputStream fis = new FileInputStream("mykeystore.sst")) {
   keyStore.load(fis, null);
}

Note that its not limited to file streams, it can be any stream.

The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional

tier1 tests for linux/macos/Windows for x86_64

-------------

Commit messages:
 - Removed whitespace
 - Merge branch 'openjdk:master' into macarte/8306688
 - Add support for SST files on Windows

Changes: https://git.openjdk.org/jdk/pull/14187/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14187&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306688
  Stats: 191 lines in 3 files changed: 145 ins; 40 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14187/head:pull/14187

PR: https://git.openjdk.org/jdk/pull/14187

From kdriver at openjdk.org  Fri May 26 21:34:41 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 26 May 2023 21:34:41 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v20]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <uhUNmwzubfdE8-RE016EqtksG35cc0GhVLAfNBDMwzM=.994a780b-c8da-4957-9294-f023164531d7@github.com>

> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

Kevin Driver has updated the pull request incrementally with four additional commits since the last revision:

 - working testcase for CertificateRequest for TLS1.2
 - new version of second test
 - initial commit of second test
 - reintroduce bug id to test header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/d9f0c667..b1382e57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=18-19

  Stats: 217 lines in 2 files changed: 217 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

PR: https://git.openjdk.org/jdk/pull/13466

From kdriver at openjdk.org  Fri May 26 21:39:29 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 26 May 2023 21:39:29 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v21]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <-MOGkoEmievYZ_WXwQW5E1IMLi2LrV3R6iMyMMSRT0o=.cee3fc88-ced4-437e-9edc-7b09bc33b117@github.com>

> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:

 - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
 - run tests with othervm
 - working testcase for CertificateRequest for TLS1.2
 - new version of second test
 - initial commit of second test
 - reintroduce bug id to test header
 - Merge remote-tracking branch 'upstream/master' into JDK-8294985
 - additional code review comments
 - rename class and remove bug id from test header
 - removing block that isn't reached
 - ... and 13 more: https://git.openjdk.org/jdk/compare/2fcd42f3...a0bfd0c7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/b1382e57..a0bfd0c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=19-20

  Stats: 28953 lines in 542 files changed: 21073 ins; 3066 del; 4814 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

PR: https://git.openjdk.org/jdk/pull/13466

From kdriver at openjdk.org  Fri May 26 21:39:32 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 26 May 2023 21:39:32 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v19]
In-Reply-To: <35aaSxH44qUrq8mfvwC0Hy4xYyvWTxZaLcTSfGv5fYk=.b5b66d89-ccca-495a-b173-31a20361be1c@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <QqFyno7sQZ-MCBisuC5clXff1WnGflGCv_BStRr-1UI=.77fd50a7-ad0b-41db-aa3c-f468df0b5703@github.com>
 <35aaSxH44qUrq8mfvwC0Hy4xYyvWTxZaLcTSfGv5fYk=.b5b66d89-ccca-495a-b173-31a20361be1c@github.com>
Message-ID: <-pJ0buQ5hUfRgmbqsUqvPLPFLD8kC1HkLJsLlBAhffI=.e493425f-6cef-4681-9ead-d810895d8460@github.com>

On Tue, 23 May 2023 18:15:57 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8294985
>>  - additional code review comments
>>  - rename class and remove bug id from test header
>>  - removing block that isn't reached
>>  - fix bug id in test header
>>  - reworked example into a jtreg test
>>  - whitespace adjustments
>>  - all review comments applied
>>  - optimize imports and change toString
>>  - review comments addressed
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/47d94ef0...d9f0c667
>
> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 29:
> 
>> 27:  * @summary verify correct exception handling in the event of an unparseable
>> 28:  *  DN in the peer CA
>> 29:  */
> 
> Please run tests for JSSE/TLS in othervm mode.  Otherwise, the behavior may be impacted with each other, and the failure debugging is pretty hard.  For an example, please refer to test/jdk/javax/net/ssl/SSLEngine/IllegalHandshakeMessage.java

See: https://github.com/openjdk/jdk/pull/13466/commits/67506a21231793df250e08ea090e6c3461d7b4f8

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1207388554

From mbalao at openjdk.org  Fri May 26 22:10:08 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 May 2023 22:10:08 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <PptyXPEZBh8EKuxXsKxDXcVRvhuFQV3n43lRx6x6uA0=.6d759490-9170-463a-b181-d7b3a7632ba3@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <s4KBfLBf28vfb0MJxJ-f6oApOE2rw7aTO0BzhOdssno=.f3fe4059-42ce-4841-aaf3-a4b6c2ab0d06@github.com>
 <PptyXPEZBh8EKuxXsKxDXcVRvhuFQV3n43lRx6x6uA0=.6d759490-9170-463a-b181-d7b3a7632ba3@github.com>
Message-ID: <mqrKXVBlwz-PL_lc27qCvdq1GsMteQMmIMETAlpfHtc=.ad83fec7-dab6-44cb-accd-ea4d894dc0a8@github.com>

On Thu, 25 May 2023 23:44:44 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 214:
>> 
>>> 212:     protected int engineGetKeySize(Key key)
>>> 213:             throws InvalidKeyException {
>>> 214:         return cipher.engineGetKeySize(key);
>> 
>> I am not too sure that this would work for all types of key... Based on the current impl, cipher is an AES cipher, but the specified key here can be P11Key or a PBEKey object. The key algorithms for both would be PBE-related, but then you are using a AES cipher to retrieve the key size?
>
> If the key is a P11PBEKey, the underlying Cipher will call P11SecretKeyFactory::convertKey with a non-PBE service algorithm and, assuming that it's in the same token and that the key is suitable for the service, will return the same key. This case should return the key length used during derivation. If the key is a PBEKey but not a P11PBEKey, there will be a call to P11SecretKeyFactory::convertKey with a non-PBE service algorithm and the key algorithm is PBE. Looks to me that, assuming that the key algorithm is suitable for the service, there will be a key derivation to finally get the length from a derived P11PBEKey. This case should not be different than using a PBEKey in a non-PBE service. @franferrax what do you think?

We discussed this further with @franferrax and changed the approach.

While the previous approach was working for cases such as P11PBEKey and other javax.crypto.interfaces.PBEKey keys whose information was the same as used for derivation in engineInit later, we found that some cases were not working because engineGetKeySize does not have access to parameters. In particular, com.sun.crypto.provider.PBEKey keys need parameter information for a proper derivation and there could also be javax.crypto.interfaces.PBEKey keys whose information is different than passed later by parameters.

In addition to the aforementioned problems, deriving twice (in many cases) was not the best for efficiency.

There is a strong guarantee that when PBE Cipher service initialization is successful, the key size is the same as the service key size (obtained from the P11SecretKeyFactory::keyInfo map, passing the service algorithm for the lookup). This is because all keys that can successfully land on P11 PBE Cipher service are either 1) derived keys of the same algorithm, or 2) keys to be derived in which the derived key length is taken from the service key length.

As part of this change, you will see in our next commit a code fix to hold the invariant "derived PBE Cipher keys that reach a PBE Cipher service must have the same algorithm". We missed this check before because such cases are not calling P11SecretKeyFactory::convertKey ?which implements the checks?, and were forwarding the key to the underlying cipher service. Notice that the underlying cipher service does not apply the same enforcement and that the underlying cipher is AES, so it will accept both 128-bit and 256-bit AES keys. Thus, the following key would have mistakenly succeeded: a PBEWithHmacSHA512AndAES_256 key passed to a PBEWithHmacSHA512AndAES_128 PBE Cipher service. We don't want to call P11SecretKeyFactory::convertKey for the case described in P11 PBE Cipher for efficiency, we just need to check the algorithms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1207418757

From mbalao at openjdk.org  Fri May 26 22:10:12 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 May 2023 22:10:12 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <ma2h-xonfuTGxyW7-TU7qjxRXyC6sD8fney7DzU9iz8=.29e9c63b-c460-440c-a22c-c545c2abf61f@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <ma2h-xonfuTGxyW7-TU7qjxRXyC6sD8fney7DzU9iz8=.29e9c63b-c460-440c-a22c-c545c2abf61f@github.com>
Message-ID: <l446xHCJ70yAyV41qqTzZa6zWOuSVwQ1KOw0fTZzu5Y=.8e10da5a-2884-4203-b89b-430f27f95aa6@github.com>

On Thu, 25 May 2023 20:23:19 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>>   
>>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>>   Co-authored-by: Martin Balao <mbalao at redhat.com>
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 34:
> 
>> 32: import java.nio.charset.Charset;
>> 33: import java.security.*;
>> 34: import java.util.Arrays;
> 
> Not used?

Good

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 36:
> 
>> 34: import java.util.Arrays;
>> 35: 
>> 36: import jdk.internal.access.SharedSecrets;
> 
> Not used?

Good

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java line 213:
> 
>> 211:         sb.append(Constants.INDENT);
>> 212:         sb.append("pParameter:");
>> 213:         sb.append(Constants.NEWLINE);
> 
> Is this intended? It seems NEWLINE is not added beforehand for other fields.

We found it more clear to start in a new line when showing the inner parameters. The reason is that inner parameters can be a structure (as in the PBE case) which has its own "member-name:" and new lines. It looked a bit odd when we had for example "    pParameter:    pInitVector:" in the first line and the rest of the inner structure below.

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2003, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> No changes in this file, should not update the year?

Good point. There were changes at some point that were undone in one of the iterations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206095706
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206095604
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206098715
PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1206099551

From mbalao at openjdk.org  Fri May 26 22:22:05 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 May 2023 22:22:05 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <t2K_wkdHz5AV4rItSSL7ojlUjiTPKZH8IPZ1PvWyDmo=.d1e32ba7-be37-4f15-8115-926241047f37@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <oWXcUWQoRtbjdACuSw2f3trT62XPXsAC3lbLUX3m-2o=.091f1132-5043-4ab8-9428-ad52657d005a@github.com>
 <t2K_wkdHz5AV4rItSSL7ojlUjiTPKZH8IPZ1PvWyDmo=.d1e32ba7-be37-4f15-8115-926241047f37@github.com>
Message-ID: <AFHtq0a_e22D18mAXbvsi-XIfHRtj-mTSFGWfI8XwYU=.ca1994e9-fc74-4456-9769-e2d70a5332a0@github.com>

On Thu, 25 May 2023 23:26:06 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 112:
>> 
>>> 110:         return pbes2Params.getAlgorithmParameters(
>>> 111:                 blkSize, pbeAlg, P11Util.getSunJceProvider(),
>>> 112:                 JCAUtil.getSecureRandom());
>> 
>> The random source should be the one supplied through CipherSpi.engineInit(...) call if there is one available (see line 118). There is Cipher javadoc specifying this.
>
> Good point. As I see it, the problem is not in the random source itself but in the values. There are a couple of P11PBECipher::engineInit paths in which P11PBECipher initialization succeeds but the pbes2Params does not have the salt, iCount and ivSpec in use. These paths are those in which the P11 key was already derived (it's a P11PBEKey): we check consistency but record nothing for future P11PBECipher::engineGetParameters calls. I think that we can get the right values from the P11PBEKey and PBEParameterSpec. Notice that if the ivSpec is not passed, it's value could be randomly generated in the underlying Cipher. @franferrax what do you think?

We can confirm that the problem was indeed as in my previous comment. As part of fixing this issue, we did some internal refactoring to PBEUtil.PBES2Params which have simplified the code. In particular, PBEUtil.PBES2Params has a method called "initialize" which consolidate all possible state initialization and is called from P11PBECipher::engineGetParameters, PBEUtil.PBES2Params::getPBEKeySpec and PBEUtil.PBES2Params::getAlgorithmParameters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1207425826

From mbalao at openjdk.org  Fri May 26 22:22:06 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 May 2023 22:22:06 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <AFHtq0a_e22D18mAXbvsi-XIfHRtj-mTSFGWfI8XwYU=.ca1994e9-fc74-4456-9769-e2d70a5332a0@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <oWXcUWQoRtbjdACuSw2f3trT62XPXsAC3lbLUX3m-2o=.091f1132-5043-4ab8-9428-ad52657d005a@github.com>
 <t2K_wkdHz5AV4rItSSL7ojlUjiTPKZH8IPZ1PvWyDmo=.d1e32ba7-be37-4f15-8115-926241047f37@github.com>
 <AFHtq0a_e22D18mAXbvsi-XIfHRtj-mTSFGWfI8XwYU=.ca1994e9-fc74-4456-9769-e2d70a5332a0@github.com>
Message-ID: <soTqdClYSfVvh95bwAJYvpEkBcf9sTanPtmLRxF-gyA=.bff25637-f292-4d86-9524-9667d037ab36@github.com>

On Fri, 26 May 2023 22:17:01 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Good point. As I see it, the problem is not in the random source itself but in the values. There are a couple of P11PBECipher::engineInit paths in which P11PBECipher initialization succeeds but the pbes2Params does not have the salt, iCount and ivSpec in use. These paths are those in which the P11 key was already derived (it's a P11PBEKey): we check consistency but record nothing for future P11PBECipher::engineGetParameters calls. I think that we can get the right values from the P11PBEKey and PBEParameterSpec. Notice that if the ivSpec is not passed, it's value could be randomly generated in the underlying Cipher. @franferrax what do you think?
>
> We can confirm that the problem was indeed as in my previous comment. As part of fixing this issue, we did some internal refactoring to PBEUtil.PBES2Params which have simplified the code. In particular, PBEUtil.PBES2Params has a method called "initialize" which consolidate all possible state initialization and is called from P11PBECipher::engineGetParameters, PBEUtil.PBES2Params::getPBEKeySpec and PBEUtil.PBES2Params::getAlgorithmParameters.

One more comment. You will see JCAUtil.getSecureRandom still passed BUT this is used only if the PBEUtil.PBES2Params instance was not initialized before from engineInit. Notice that if it was initialized before, a random passed to engineInit was used to generate the IV and salt values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1207427324

From mpowers at openjdk.org  Fri May 26 23:11:58 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 26 May 2023 23:11:58 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v5]
In-Reply-To: <sEzN577sIfs5gkH6Bv5QqnE6pU4IMvToN3rqMKacOog=.9c6408d9-258c-4975-9a9d-f4e9711ce711@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <aF58lSjU-4jZOrFZAy299O7DF-zvlpXCUxqRTsR9qwI=.70ba030c-cb4e-4d62-b0bf-f13aa3c49a3b@github.com>
 <sEzN577sIfs5gkH6Bv5QqnE6pU4IMvToN3rqMKacOog=.9c6408d9-258c-4975-9a9d-f4e9711ce711@github.com>
Message-ID: <dimsuZWUxfmyfQzwHukvfW8uMz4Eomt9JAGD_PAWxWs=.f9dc8603-6e6f-41b6-8a31-3e9d8843887a@github.com>

On Tue, 23 May 2023 19:07:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change class names and fix nit
>
> test/jdk/sun/security/provider/hss/TestHSSLMS.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug JDK-8298127
> 
> Should just be `@bug 8298127`.

Fixed.

> test/jdk/sun/security/provider/hss/TestHSSLMS.java line 83:
> 
>> 81:                 verify(t.pk, t.sig, t.msg);
>> 82:                 return false;
>> 83:             } catch (InvalidKeySpecException | SignatureException ex) {
> 
> It would be nice to test for the expected exception, either `InvalidKeySpecException` or `SignatureException`. You could add an additional field to the `TestCase` record which checks for the expected exception type.

Fixed.

> test/micro/org/openjdk/bench/java/security/HSSLMS.java line 70:
> 
>> 68:     public void test01_RFC_8554() throws Exception {
>> 69:         // RFC 8554 Test Case 1
>> 70:         var pk = decode("""
> 
> If we are primarily interested in measuring the performance of the HSS/LMS verification, the decode parts should really be left out of that calculation and moved to `setup()` methods. Consider having separate inner/static subclasses for each test, and moving the decoding code to the `setup()` methods in each of those subclasses. See `test/micro/org/openjdk/bench/java/security/Signatures.java` for an example.

Fixed. It made a measurable difference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1207464618
PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1207464673
PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1207464557

From mpowers at openjdk.org  Fri May 26 23:24:38 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 26 May 2023 23:24:38 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v6]
In-Reply-To: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
Message-ID: <RsNx_O4aQKgt48CeX1qOXQKhsaF7MTCDenidkP8tCfE=.adaaeeb8-3042-4d12-b432-38d10a9685fe@github.com>

> https://bugs.openjdk.org/browse/JDK-8307794

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  Sean's additional comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13940/files
  - new: https://git.openjdk.org/jdk/pull/13940/files/a5aaeac0..3f5e8272

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=04-05

  Stats: 0 lines in 3 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940

PR: https://git.openjdk.org/jdk/pull/13940

From wetmore at openjdk.org  Sat May 27 00:34:30 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Sat, 27 May 2023 00:34:30 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v21]
In-Reply-To: <-MOGkoEmievYZ_WXwQW5E1IMLi2LrV3R6iMyMMSRT0o=.cee3fc88-ced4-437e-9edc-7b09bc33b117@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <-MOGkoEmievYZ_WXwQW5E1IMLi2LrV3R6iMyMMSRT0o=.cee3fc88-ced4-437e-9edc-7b09bc33b117@github.com>
Message-ID: <aSy7-ubenosZRelIFuR5yHfx-jvqcEQtpytfQSmkxXI=.3e9dee21-d76d-40cb-a2ea-6bb98e3e5f9c@github.com>

On Fri, 26 May 2023 21:39:29 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:
> 
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
>  - run tests with othervm
>  - working testcase for CertificateRequest for TLS1.2
>  - new version of second test
>  - initial commit of second test
>  - reintroduce bug id to test header
>  - Merge remote-tracking branch 'upstream/master' into JDK-8294985
>  - additional code review comments
>  - rename class and remove bug id from test header
>  - removing block that isn't reached
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/a0c80510...a0bfd0c7

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 28:

> 26:  * @bug 8294985
> 27:  * @library /test/lib
> 28:  * @summary verify correct exception handling in the event of an unparseable

The @summary should generally match the bug synopsis:

SSLEngine throws IAE during parsing of X500Principal

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 29:

> 27:  * @library /test/lib
> 28:  * @summary verify correct exception handling in the event of an unparseable
> 29:  *  DN in the peer CA

Generally this should be indented as well.  4 spaces minimum, or to be at the same position as the word "verify."  Your choice.

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 49:

> 47: 
> 48:     // Test was originally written for TLSv1.2
> 49:     private static final String proto = "TLSv1.2";

I would suggest changing this to "TLSv1.3", just so it's immediately clear that you're testing the 1.3 code, not the 1.2 which is in the other test.

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 65:

> 63:             + "/../../../../javax/net/ssl/etc/keystore";
> 64: 
> 65:     // the following contains a certificate with an invalid/unparseable

"The following ClientHello handshake message..." so that folks aren't wondering what this binary data actually is.

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 67:

> 65:     // the following contains a certificate with an invalid/unparseable
> 66:     // distinguished name
> 67:     private static final byte[] payload = Base64.getDecoder().decode(

Minor nit:  It's a little inconsistent to have similar tests use two different encodings.  i.e. base64 vs. hex.   The advantage to base64 is that the decoder exists in JDK 8 which this bug will be backported to.  The HexConvert wasn't added until JDK 17, so when this is backported, they will have to convert it or add their own Hex converter (or use the BigInteger trick).

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 28:

> 26:  * @bug 8294985
> 27:  * @library /test/lib
> 28:  * @summary verify correct exception handling in the event of an unparseable

Same as above:

The @summary should generally match the bug synopsis:

SSLEngine throws IAE during parsing of X500Principal

and indention below.

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 215:

> 213:         }
> 214:     }
> 215: 

Nits:  I generally delete multiple blank lines in situations like this.

        }
    }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1207457534
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1207459701
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1207467826
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1207469384
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1207461770
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1207458791
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1207485286

From valeriep at openjdk.org  Sat May 27 01:56:02 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 27 May 2023 01:56:02 GMT
Subject: RFR: 8297885: misc sun/security/pkcs11 tests timed out
Message-ID: <8QVEYBnBZ_3K5s26Wh7TwceB07Xvo8PufUzKe3xq8bE=.663052f5-d1d6-46b8-b25f-d56c1808bc43@github.com>

Increase the timeout value of the "LargeDSAKey,java" test to address the intermittent test failure(s). As for the other mentioned test failures, the execution time fluctuates even less, so leaving them alone for now.

Thanks in advance for the review~

-------------

Commit messages:
 - 8297885: misc sun/security/pkcs11 tests timed out

Changes: https://git.openjdk.org/jdk/pull/14190/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14190&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297885
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14190/head:pull/14190

PR: https://git.openjdk.org/jdk/pull/14190

From xuelei at openjdk.org  Sat May 27 02:59:52 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 27 May 2023 02:59:52 GMT
Subject: RFR: 8297885: misc sun/security/pkcs11 tests timed out
In-Reply-To: <8QVEYBnBZ_3K5s26Wh7TwceB07Xvo8PufUzKe3xq8bE=.663052f5-d1d6-46b8-b25f-d56c1808bc43@github.com>
References: <8QVEYBnBZ_3K5s26Wh7TwceB07Xvo8PufUzKe3xq8bE=.663052f5-d1d6-46b8-b25f-d56c1808bc43@github.com>
Message-ID: <7ZgeR9bbjZb9HeAAM44jmj0tdLn7QmJvpc8ktQzXku0=.9266d789-4271-4df7-b5c6-b8d5b1009e88@github.com>

On Sat, 27 May 2023 01:49:22 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Increase the timeout value of the "LargeDSAKey,java" test to address the intermittent test failure(s). As for the other mentioned test failures, the execution time fluctuates even less, so leaving them alone for now.
> 
> Thanks in advance for the review~

Marked as reviewed by xuelei (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14190#pullrequestreview-1447129035

From mbalao at openjdk.org  Sat May 27 06:24:36 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 27 May 2023 06:24:36 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v6]
In-Reply-To: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
Message-ID: <onz_7DOZAZkgGr-DGGj45BGLcjptpMEQvOFJnw3OW68=.746c265f-3c61-4d8a-bbe9-33f5447d7af6@github.com>

> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
> 
> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
> 
>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple overloads) ...

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4)
  
  Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
  Co-authored-by: Martin Balao <mbalao at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12396/files
  - new: https://git.openjdk.org/jdk/pull/12396/files/80575ccb..1c596e14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12396&range=04-05

  Stats: 157 lines in 7 files changed: 72 ins; 51 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/12396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12396/head:pull/12396

PR: https://git.openjdk.org/jdk/pull/12396

From mbalao at openjdk.org  Sat May 27 06:25:17 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 27 May 2023 06:25:17 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
Message-ID: <8jk68QALKpCL1Ga5ibnCXsMwe__93HSytpusH4b5a-I=.a0507fbc-9aeb-49b7-b7cf-8b180ec74a55@github.com>

On Tue, 23 May 2023 19:29:47 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #3)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

Iteration # 4 proposed, addressing comments above.

No test regressions observed in jdk/com/sun/crypto/provider or jdk/sun/security/pkcs11.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1565229361

From weijun at openjdk.org  Sat May 27 22:50:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 27 May 2023 22:50:56 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
Message-ID: <VkY0YuZcvKlzgsmJPJgQn5yNT9556BhRhtPn_oXd-Qg=.e9ba63fa-e182-4cd6-9419-a81193770cc9@github.com>

On Fri, 19 May 2023 12:19:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> With this PR we try to be better in loading certificates from the MacOS Keychain into a JDK Trust store.
>> 
>> The current implementation after JDK-8278449 would only load/trust certificates from an identity (with private key available) and certificates that have explicit trust set in the user domain (as shown by security dump-trust-settings). This, however is not sufficient and does not match the MacOS system behavior, e.g. if you compare with tools like curl or Safari.
>> 
>> This change does the following:
>> 1. The native method that reads trust settings will call the API SecTrustSettingsCopyTrustSettings on a certificate for both, User and Admin domain.
>> 2. We now trust self-signed certificates that have an explicit trust entry with no sub-records or no sub-records that would deny the certificate usage for any purpose.
>> 3. The check for double aliases has been augmented by comparing whether the certificate to be added is the same as the one that is already present. This can happen if a certificate is contained in both, the user and the system keychain, for instance.
>> 
>> I have added a test that verifies whether certificates that should be trusted from "security dump-trust-settings" are contained in the keystore and those that should be disallowed are absent.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove another obsolete comment

I think you can finalize the CSR now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1565722384

From kbarrett at openjdk.org  Sun May 28 03:39:10 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 28 May 2023 03:39:10 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <VpEl4v3oeJJGf7hCma44tp9IG-d6T1jyRjemqZN8Kfg=.8338f76a-37e5-4524-9cfe-83b2a774b3bc@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <VpEl4v3oeJJGf7hCma44tp9IG-d6T1jyRjemqZN8Kfg=.8338f76a-37e5-4524-9cfe-83b2a774b3bc@github.com>
Message-ID: <63Q15YTSJDgsIJb4fYQYdrtBYkSNebRm7Q8jVgzTiW8=.86a710d5-1930-4b3c-80a2-743a83653831@github.com>

On Fri, 26 May 2023 07:48:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> According to our docs, [clang is a supported compiler for Linux](https://github.com/openjdk/jdk/blob/master/doc/building.md#native-compiler-toolchain-requirements).

I think that's aspirational rather than actual.  Clang has been included in
that list for a long time (since at least JDK 9), but I think there's never
been anyone claiming to provide such support, be a maintainer, or even
build/test on some regular basis:
https://wiki.openjdk.org/display/Build/Supported+Build+Platforms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1565842012

From kbarrett at openjdk.org  Sun May 28 04:14:04 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 28 May 2023 04:14:04 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

All of the -Wformat-nonliteral changes make me wonder why we're seeing these
with clang but not with gcc.  Figuring that out will likely give a better
chance of acceptance.

src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1163:

> 1161: #if defined(__clang__)
> 1162: #pragma clang diagnostic push
> 1163: #pragma clang diagnostic ignored "-Wparentheses"

I think this warning is because of the several `if (init_result = ...)`?  Better would be to just add the extra parens.

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 575:

> 573: if (ps_pdread(ph, (char *)link_map_addr + LINK_MAP_LD_OFFSET,
> 574:                &lib_ld, sizeof(uintptr_t)) != PS_OK) {
> 575: #else

What problem is being "fixed" by these?  I'm dubious that this is the best solution to whatever the problem
is, but can't evaluate or suggest alternatives without knowing what it is.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1447852014
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1208298799
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1208302906

From asemenov at openjdk.org  Mon May 29 22:29:26 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 29 May 2023 22:29:26 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v2]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <So49itlN8iwiVZ4-LlECl3FlQEgc_aCTxdIO3lcHW9k=.1d9e68b9-acec-4bb3-b5cc-8abb93482b35@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/86077cdf..3f343c26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=00-01

  Stats: 134 lines in 15 files changed: 12 ins; 122 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From avu at openjdk.org  Tue May 30 08:20:04 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 30 May 2023 08:20:04 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v2]
In-Reply-To: <So49itlN8iwiVZ4-LlECl3FlQEgc_aCTxdIO3lcHW9k=.1d9e68b9-acec-4bb3-b5cc-8abb93482b35@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <So49itlN8iwiVZ4-LlECl3FlQEgc_aCTxdIO3lcHW9k=.1d9e68b9-acec-4bb3-b5cc-8abb93482b35@github.com>
Message-ID: <fgcUzu1tyHuca8vlNWH_YqiTnDDHDvUZd7M3DB1vjsc=.b847b5af-1adb-414a-b4db-eca9d209f3a5@github.com>

On Mon, 29 May 2023 22:29:26 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Changes requested by avu (Committer).

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 655:

> 653:       // linker loaded it. We use "base diff" in read_lib_segments call below.
> 654: 
> 655:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_ADDR_OFFSET,

Extra white spaces before 'if'

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 662:

> 660: 
> 661:       // read address of the name
> 662:                       if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NAME_OFFSET,

Extra white-spaces before 'if'

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 717:

> 715: 
> 716:     // read next link_map address
> 717:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NEXT_OFFSET,

Extra white-spaces before 'if'

src/jdk.jpackage/share/native/common/tstrings.cpp line 60:

> 58: #endif
> 59:         // With g++ this compiles only with '-std=gnu++0x' option
> 60:                 ret = vsnprintf(&*fmtout.begin(), fmtout.size(), format, args);

Extra white-spaces before 'ret'

-------------

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1450367357
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209893589
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209894667
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209895275
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209895801

From clanger at openjdk.org  Tue May 30 09:01:57 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 30 May 2023 09:01:57 GMT
Subject: RFR: 8303465: KeyStore of type KeychainStore,
 provider Apple does not show all trusted certificates [v6]
In-Reply-To: <VkY0YuZcvKlzgsmJPJgQn5yNT9556BhRhtPn_oXd-Qg=.e9ba63fa-e182-4cd6-9419-a81193770cc9@github.com>
References: <h5LkH0vEV59WrHmU5NjEwgam87wY89Ci-ALvkmhY-1g=.1246f000-f9ec-403f-96d9-1c02ad0b21c6@github.com>
 <9vLju4KLej9wIUFuY1CT4Y3aHrt6TtVk5FCnbTgvw3o=.3762d181-f941-48f7-8610-29f55883bafc@github.com>
 <VkY0YuZcvKlzgsmJPJgQn5yNT9556BhRhtPn_oXd-Qg=.e9ba63fa-e182-4cd6-9419-a81193770cc9@github.com>
Message-ID: <n9AYneP1YhBWKf3rMm6GFtmENQGH96uqol_TmhGvwdw=.726a0f72-3c98-4bb2-8345-ed60c4af5ee9@github.com>

On Sat, 27 May 2023 22:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I think you can finalize the CSR now.

Thx for the hint, done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13945#issuecomment-1568048939

From mdonovan at openjdk.org  Tue May 30 10:57:55 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 30 May 2023 10:57:55 GMT
Subject: RFR: 8290005: com/sun/jndi/ldap/LdapCBPropertiesTest.java failling
 with NullPointerException [v3]
In-Reply-To: <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com>
References: <f5TtWZ2nBmY-nG4wgUthBfi5tU_cz3Z8ZUxU3hf-H7E=.39d7d99e-3ecd-4f77-8ed8-4220b35d7653@github.com>
 <_Q0R_ffxNgj8akEl9DzdoO7Cl17ULr9vKiY-NXNx5g8=.f1eacd05-32c8-4976-9c80-bb8c59c53ea0@github.com>
Message-ID: <qna9EOuDV1cK5e5P9WBjDT4Ld2jLCBVRK0RmS8oLl3Y=.84daf8f1-6d0e-4d60-9e87-196cbd6b6b7f@github.com>

On Wed, 3 May 2023 11:26:32 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I added methods to the TransportContext class to synchronize access to the handshakeContext field. I also updated locations in the code that rely on the handshakeContext field to not be null to use the synchronized methods.
>> 
>> Thanks
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made handshake context lock final

Hi, I'm still looking for a Reviewer for this PR. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13742#issuecomment-1568221732

From mullan at openjdk.org  Tue May 30 12:43:06 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 30 May 2023 12:43:06 GMT
Subject: RFR: 8306688: Support Windows serialized keystores (SST files)
In-Reply-To: <Vd015xi-nOLmoJ1vEsnjZEsSl0SDBk9-tCzlCeWNLao=.ec1b00fd-2f90-47d0-8ef8-ac3306134ae6@github.com>
References: <Vd015xi-nOLmoJ1vEsnjZEsSl0SDBk9-tCzlCeWNLao=.ec1b00fd-2f90-47d0-8ef8-ac3306134ae6@github.com>
Message-ID: <MfY4qkiWs9Qg8g-yhUPlaRL-SUI6zPluWnLd-kvXY4I=.7029ea2a-7641-44ac-b7a6-6d0f00ea8ed9@github.com>

On Fri, 26 May 2023 21:09:35 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Added ability to load keystores from SST files on Windows.  Example usage:
> 
> KeyStore keyStore = KeyStore.getInstance("Windows-SST");
> try (FileInputStream fis = new FileInputStream("mykeystore.sst")) {
>    keyStore.load(fis, null);
> }
> 
> Note that its not limited to file streams, it can be any stream.
> 
> The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional
> 
> tier1 tests for linux/macos/Windows for x86_64

This Enhancement requires a CSR as you are introducing a new KeyStore type and system property. RDP 1 for JDK 21 is on June 8, so there is not much time left to review and approve the CSR and code for this issue. I recommend you retarget this to JDK 22.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1568364970

From weijun at openjdk.org  Tue May 30 14:03:06 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 May 2023 14:03:06 GMT
Subject: RFR: 8297878: KEM: Implementation [v21]
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <KyzU5wDFFEKX1zgyJOrs-JMmT2NsWSHlvu1evU4q1Js=.f2d1f31d-c742-46ec-9621-21105d1bff65@github.com>

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  New and old SunJCE entries in class comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13256/files
  - new: https://git.openjdk.org/jdk/pull/13256/files/2c7ef3d5..bdd0c63b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13256&range=19-20

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13256/head:pull/13256

PR: https://git.openjdk.org/jdk/pull/13256

From weijun at openjdk.org  Tue May 30 14:36:01 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 May 2023 14:36:01 GMT
Subject: RFR: 8306688: Support Windows serialized keystores (SST files)
In-Reply-To: <Vd015xi-nOLmoJ1vEsnjZEsSl0SDBk9-tCzlCeWNLao=.ec1b00fd-2f90-47d0-8ef8-ac3306134ae6@github.com>
References: <Vd015xi-nOLmoJ1vEsnjZEsSl0SDBk9-tCzlCeWNLao=.ec1b00fd-2f90-47d0-8ef8-ac3306134ae6@github.com>
Message-ID: <viAyFtTt9bR7rr0IiQda0A4cKKvGZM2VWuORroSWLoI=.5608ca0a-ed8a-4092-b017-2831c6d54462@github.com>

On Fri, 26 May 2023 21:09:35 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Added ability to load keystores from SST files on Windows.  Example usage:
> 
> KeyStore keyStore = KeyStore.getInstance("Windows-SST");
> try (FileInputStream fis = new FileInputStream("mykeystore.sst")) {
>    keyStore.load(fis, null);
> }
> 
> Note that its not limited to file streams, it can be any stream.
> 
> The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional
> 
> tier1 tests for linux/macos/Windows for x86_64

I thought you meant this keystore to be read-only. What happens when set/delete/store is called?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1568544214

From kdriver at openjdk.org  Tue May 30 14:45:42 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 30 May 2023 14:45:42 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v22]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <8B9hinYCLfqj-2WgThndO3Amm3_l7Vir6zVwPfa34ZI=.b2d48ea5-26d8-4fef-9731-008df2245ee1@github.com>

> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  addressed remaining code review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/a0bfd0c7..9bd9b458

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=20-21

  Stats: 46 lines in 2 files changed: 1 ins; 38 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

PR: https://git.openjdk.org/jdk/pull/13466

From kdriver at openjdk.org  Tue May 30 14:45:54 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 30 May 2023 14:45:54 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v21]
In-Reply-To: <aSy7-ubenosZRelIFuR5yHfx-jvqcEQtpytfQSmkxXI=.3e9dee21-d76d-40cb-a2ea-6bb98e3e5f9c@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <-MOGkoEmievYZ_WXwQW5E1IMLi2LrV3R6iMyMMSRT0o=.cee3fc88-ced4-437e-9edc-7b09bc33b117@github.com>
 <aSy7-ubenosZRelIFuR5yHfx-jvqcEQtpytfQSmkxXI=.3e9dee21-d76d-40cb-a2ea-6bb98e3e5f9c@github.com>
Message-ID: <kQE1WafJ9FVMfGR4wbwOdw91GRJKTdc4NvzM0r50ILo=.305199fa-a332-4018-99bf-3df7254f74ca@github.com>

On Fri, 26 May 2023 23:00:40 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
>>  - run tests with othervm
>>  - working testcase for CertificateRequest for TLS1.2
>>  - new version of second test
>>  - initial commit of second test
>>  - reintroduce bug id to test header
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8294985
>>  - additional code review comments
>>  - rename class and remove bug id from test header
>>  - removing block that isn't reached
>>  - ... and 13 more: https://git.openjdk.org/jdk/compare/257152e8...a0bfd0c7
>
> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 28:
> 
>> 26:  * @bug 8294985
>> 27:  * @library /test/lib
>> 28:  * @summary verify correct exception handling in the event of an unparseable
> 
> The @summary should generally match the bug synopsis:
> 
> SSLEngine throws IAE during parsing of X500Principal

addressed in https://github.com/openjdk/jdk/pull/13466/commits/9bd9b4583444f2b469bd39e445424d01524601f9

> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 29:
> 
>> 27:  * @library /test/lib
>> 28:  * @summary verify correct exception handling in the event of an unparseable
>> 29:  *  DN in the peer CA
> 
> Generally this should be indented as well.  4 spaces minimum, or to be at the same position as the word "verify."  Your choice.

addressed in https://github.com/openjdk/jdk/pull/13466/commits/9bd9b4583444f2b469bd39e445424d01524601f9

> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 49:
> 
>> 47: 
>> 48:     // Test was originally written for TLSv1.2
>> 49:     private static final String proto = "TLSv1.2";
> 
> I would suggest changing this to "TLSv1.3", just so it's immediately clear that you're testing the 1.3 code, not the 1.2 which is in the other test.

addressed in https://github.com/openjdk/jdk/pull/13466/commits/9bd9b4583444f2b469bd39e445424d01524601f9

> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 65:
> 
>> 63:             + "/../../../../javax/net/ssl/etc/keystore";
>> 64: 
>> 65:     // the following contains a certificate with an invalid/unparseable
> 
> "The following ClientHello handshake message..." so that folks aren't wondering what this binary data actually is.

addressed in https://github.com/openjdk/jdk/pull/13466/commits/9bd9b4583444f2b469bd39e445424d01524601f9

> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 67:
> 
>> 65:     // the following contains a certificate with an invalid/unparseable
>> 66:     // distinguished name
>> 67:     private static final byte[] payload = Base64.getDecoder().decode(
> 
> Minor nit:  It's a little inconsistent to have similar tests use two different encodings.  i.e. base64 vs. hex.   The advantage to base64 is that the decoder exists in JDK 8 which this bug will be backported to.  The HexConvert wasn't added until JDK 17, so when this is backported, they will have to convert it or add their own Hex converter (or use the BigInteger trick).

addressed in https://github.com/openjdk/jdk/pull/13466/commits/9bd9b4583444f2b469bd39e445424d01524601f9

> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 28:
> 
>> 26:  * @bug 8294985
>> 27:  * @library /test/lib
>> 28:  * @summary verify correct exception handling in the event of an unparseable
> 
> Same as above:
> 
> The @summary should generally match the bug synopsis:
> 
> SSLEngine throws IAE during parsing of X500Principal
> 
> and indention below.

addressed in https://github.com/openjdk/jdk/pull/13466/commits/9bd9b4583444f2b469bd39e445424d01524601f9

> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 215:
> 
>> 213:         }
>> 214:     }
>> 215: 
> 
> Nits:  I generally delete multiple blank lines in situations like this.
> 
>         }
>     }
> }

addressed in https://github.com/openjdk/jdk/pull/13466/commits/9bd9b4583444f2b469bd39e445424d01524601f9

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1210387386
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1210388001
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1210388504
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1210388799
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1210389671
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1210387703
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1210389289

From kdriver at openjdk.org  Tue May 30 14:52:48 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 30 May 2023 14:52:48 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v23]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <a7H4SgagHDZyunTKG14YJwbJ_z4tECn4kzAfDDbGl8w=.c60e2b71-1c4f-48bd-942d-5abff7ba7d56@github.com>

> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:

  wrapping

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/9bd9b458..16d6d74e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=21-22

  Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

PR: https://git.openjdk.org/jdk/pull/13466

From kdriver at openjdk.org  Tue May 30 14:59:11 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 30 May 2023 14:59:11 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v24]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <oWD0Wk9agQo1_5LgNFFBu0gsZ5fW4ok_HepENOiWHlo=.e5c7e31b-c958-4fd7-9319-46e099c644e6@github.com>

> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:

 - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
 - wrapping
 - addressed remaining code review comments
 - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
 - run tests with othervm
 - working testcase for CertificateRequest for TLS1.2
 - new version of second test
 - initial commit of second test
 - reintroduce bug id to test header
 - Merge remote-tracking branch 'upstream/master' into JDK-8294985
 - ... and 16 more: https://git.openjdk.org/jdk/compare/805511ea...2a35a7cc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/16d6d74e..2a35a7cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=22-23

  Stats: 2692 lines in 105 files changed: 1642 ins; 582 del; 468 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

PR: https://git.openjdk.org/jdk/pull/13466

From mullan at openjdk.org  Tue May 30 15:13:02 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 30 May 2023 15:13:02 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v6]
In-Reply-To: <RsNx_O4aQKgt48CeX1qOXQKhsaF7MTCDenidkP8tCfE=.adaaeeb8-3042-4d12-b432-38d10a9685fe@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <RsNx_O4aQKgt48CeX1qOXQKhsaF7MTCDenidkP8tCfE=.adaaeeb8-3042-4d12-b432-38d10a9685fe@github.com>
Message-ID: <HpFNZ4CHll1ZFttZ7kb_7L-QYrPitgW5Xfy9I0mw920=.fb480a20-6181-42e6-bf41-9914d67caa76@github.com>

On Fri, 26 May 2023 23:24:38 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sean's additional comments

I don't see my comments resolved in the latest commit. Did you not push them yet?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13940#issuecomment-1568614089

From mullan at openjdk.org  Tue May 30 15:27:10 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 30 May 2023 15:27:10 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v24]
In-Reply-To: <oWD0Wk9agQo1_5LgNFFBu0gsZ5fW4ok_HepENOiWHlo=.e5c7e31b-c958-4fd7-9319-46e099c644e6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <oWD0Wk9agQo1_5LgNFFBu0gsZ5fW4ok_HepENOiWHlo=.e5c7e31b-c958-4fd7-9319-46e099c644e6@github.com>
Message-ID: <xdPsbMYsrBGiDzvjKnd2MKQ12Y4L6uHU3nNwxPMhn5s=.b5ffd5b9-9f49-4037-8407-d341f0251d08@github.com>

On Tue, 30 May 2023 14:59:11 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
>  - wrapping
>  - addressed remaining code review comments
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
>  - run tests with othervm
>  - working testcase for CertificateRequest for TLS1.2
>  - new version of second test
>  - initial commit of second test
>  - reintroduce bug id to test header
>  - Merge remote-tracking branch 'upstream/master' into JDK-8294985
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/38960d7b...2a35a7cc

src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 28:

> 26: package sun.security.ssl;
> 27: 
> 28: import sun.security.ssl.SSLExtension.ExtensionConsumer;

Please keep the previous import order for consistency with other code in this package. All code in `sun.security.ssl` generally orders the imports as `java`, `javax`, then internal (`sun`), etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1210451045

From mullan at openjdk.org  Tue May 30 15:45:18 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 30 May 2023 15:45:18 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v24]
In-Reply-To: <oWD0Wk9agQo1_5LgNFFBu0gsZ5fW4ok_HepENOiWHlo=.e5c7e31b-c958-4fd7-9319-46e099c644e6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <oWD0Wk9agQo1_5LgNFFBu0gsZ5fW4ok_HepENOiWHlo=.e5c7e31b-c958-4fd7-9319-46e099c644e6@github.com>
Message-ID: <hvF7aZzRlw791J0x89uHBxRTY3nsuq18xc2uwIVvnRU=.36211a5c-111f-43c6-8758-09afa19da763@github.com>

On Tue, 30 May 2023 14:59:11 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
>  - wrapping
>  - addressed remaining code review comments
>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
>  - run tests with othervm
>  - working testcase for CertificateRequest for TLS1.2
>  - new version of second test
>  - initial commit of second test
>  - reintroduce bug id to test header
>  - Merge remote-tracking branch 'upstream/master' into JDK-8294985
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/5217509f...2a35a7cc

I'll defer to Brad for a review of the tests, but otherwise looks good to me.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1451270775

From macarte at openjdk.org  Tue May 30 15:47:57 2023
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 30 May 2023 15:47:57 GMT
Subject: RFR: 8306688: Support Windows serialized keystores (SST files)
In-Reply-To: <viAyFtTt9bR7rr0IiQda0A4cKKvGZM2VWuORroSWLoI=.5608ca0a-ed8a-4092-b017-2831c6d54462@github.com>
References: <Vd015xi-nOLmoJ1vEsnjZEsSl0SDBk9-tCzlCeWNLao=.ec1b00fd-2f90-47d0-8ef8-ac3306134ae6@github.com>
 <viAyFtTt9bR7rr0IiQda0A4cKKvGZM2VWuORroSWLoI=.5608ca0a-ed8a-4092-b017-2831c6d54462@github.com>
Message-ID: <3WZTHipqAq0PX73nJaJduRogtZRRR1CoJuJrrM6SwcI=.4143c4e0-faf7-4c51-a4a6-e05ad5c9605a@github.com>

On Tue, 30 May 2023 14:32:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Added ability to load keystores from SST files on Windows.  Example usage:
>> 
>> KeyStore keyStore = KeyStore.getInstance("Windows-SST");
>> try (FileInputStream fis = new FileInputStream("mykeystore.sst")) {
>>    keyStore.load(fis, null);
>> }
>> 
>> Note that its not limited to file streams, it can be any stream.
>> 
>> The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional
>> 
>> tier1 tests for linux/macos/Windows for x86_64
>
> I thought you meant this keystore to be read-only. What happens when set/delete/store is called?

@wangweij - the set and delete will modify the in memory store instance.  However as of now, the store is a nop - historically as setting/removing from the MY/ROOT stores persists the changes (but not the case for in-memory stores using SST).

So I see three ways forward, either (1) leave as is, (2) open the memory store with CERT_STORE_READONLY_FLAG [exceptions will be thrown when trying to modify the store] or (3) support persisting the store to an output stream. 

(1) has value as it allows you to create in memory stores on Windows using windows APIs (vs PKS etc) 

(2) seems limited - but supports my customer needs

(3) expands beyond my current needs, but might offer the most flexibility

In cases (1) and (3): perhaps we should allow in-memory stores that don't need to be loaded from SST, ie create them empty and available to update and potentially persist

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1568665628

From weijun at openjdk.org  Tue May 30 16:27:55 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 May 2023 16:27:55 GMT
Subject: RFR: 8306688: Support Windows serialized keystores (SST files)
In-Reply-To: <Vd015xi-nOLmoJ1vEsnjZEsSl0SDBk9-tCzlCeWNLao=.ec1b00fd-2f90-47d0-8ef8-ac3306134ae6@github.com>
References: <Vd015xi-nOLmoJ1vEsnjZEsSl0SDBk9-tCzlCeWNLao=.ec1b00fd-2f90-47d0-8ef8-ac3306134ae6@github.com>
Message-ID: <CW8OtKifYwr7tKz4PxlfYsKU_39w1QCuQK_T4zLBt4c=.1de4de0b-d934-412d-8ba3-cbe2cfc4db60@github.com>

On Fri, 26 May 2023 21:09:35 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Added ability to load keystores from SST files on Windows.  Example usage:
> 
> KeyStore keyStore = KeyStore.getInstance("Windows-SST");
> try (FileInputStream fis = new FileInputStream("mykeystore.sst")) {
>    keyStore.load(fis, null);
> }
> 
> Note that its not limited to file streams, it can be any stream.
> 
> The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional
> 
> tier1 tests for linux/macos/Windows for x86_64

If you only do (1) without (3), user might have a false feeling that they can modify the content but persist it. Worse, because `KeyStore::store` works on an output stream, they are likely to wipe out the original SST file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1568728472

From weijun at openjdk.org  Tue May 30 16:34:26 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 30 May 2023 16:34:26 GMT
Subject: Integrated: 8297878: KEM: Implementation
In-Reply-To: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
References: <Q7h2WIGd3UpnvYmsWn-XPulH639SVNLXrDc0VVJhMC4=.c3317c07-92cd-4e97-ab3f-cd7057b93490@github.com>
Message-ID: <klyEKccbTVQTvZfWaBSI4G8iySuTQmqjBMQ45DuV0JY=.f5f0c0d4-d6e6-46d2-89ce-e85b5eb1f825@github.com>

On Fri, 31 Mar 2023 02:25:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The KEM API and DHKEM impl. Note that this PR uses new methods in https://github.com/openjdk/jdk/pull/13250.

This pull request has now been integrated.

Changeset: 6b90b051
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b90b0519e89429300838fa598b2ea9ffda984a2
Stats:     2327 lines in 12 files changed: 2306 ins; 3 del; 18 mod

8297878: KEM: Implementation

Reviewed-by: ascarpino, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/13256

From mpowers at openjdk.org  Tue May 30 16:47:03 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 30 May 2023 16:47:03 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v7]
In-Reply-To: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
Message-ID: <0rm32dgNPxsrj1ErRROktUDMRbce0lJWGPWsUw6YOSw=.e7d7f8b2-b8dd-4783-8e9c-76b188dd3034@github.com>

> https://bugs.openjdk.org/browse/JDK-8307794

Mark Powers has updated the pull request incrementally with one additional commit since the last revision:

  Sean's additional comments take 2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13940/files
  - new: https://git.openjdk.org/jdk/pull/13940/files/3f5e8272..c72fada8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13940&range=05-06

  Stats: 239 lines in 3 files changed: 104 ins; 32 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/13940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13940/head:pull/13940

PR: https://git.openjdk.org/jdk/pull/13940

From mpowers at openjdk.org  Tue May 30 16:55:56 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 30 May 2023 16:55:56 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v6]
In-Reply-To: <HpFNZ4CHll1ZFttZ7kb_7L-QYrPitgW5Xfy9I0mw920=.fb480a20-6181-42e6-bf41-9914d67caa76@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <RsNx_O4aQKgt48CeX1qOXQKhsaF7MTCDenidkP8tCfE=.adaaeeb8-3042-4d12-b432-38d10a9685fe@github.com>
 <HpFNZ4CHll1ZFttZ7kb_7L-QYrPitgW5Xfy9I0mw920=.fb480a20-6181-42e6-bf41-9914d67caa76@github.com>
Message-ID: <UMJXmRv37Readwg964wAVaidrRYNmZO-bknOAeHnuew=.2b243efd-a2ab-4df5-85b9-5eb6ecc07138@github.com>

On Tue, 30 May 2023 15:09:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Sean's additional comments
>
> I don't see my comments resolved in the latest commit. Did you not push them yet?

@seanjmullan I pushed an empty commit. Sorry. Look for "take 2".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13940#issuecomment-1568762795

From hchao at openjdk.org  Tue May 30 17:06:16 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Tue, 30 May 2023 17:06:16 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v7]
In-Reply-To: <0rm32dgNPxsrj1ErRROktUDMRbce0lJWGPWsUw6YOSw=.e7d7f8b2-b8dd-4783-8e9c-76b188dd3034@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <0rm32dgNPxsrj1ErRROktUDMRbce0lJWGPWsUw6YOSw=.e7d7f8b2-b8dd-4783-8e9c-76b188dd3034@github.com>
Message-ID: <RIi26PUMIbCQU-4CiphJtx-qhSXil-9zpuKQHklNt6A=.a12a2ea8-f7f1-4fce-8a60-67c6ad28608a@github.com>

On Tue, 30 May 2023 16:47:03 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sean's additional comments take 2

test/jdk/sun/security/tools/jarsigner/VerifyHSSSignedJar.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug JDK-8298127

s/JDK-8298127/8298127

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1210570893

From valeriep at openjdk.org  Tue May 30 17:54:08 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 30 May 2023 17:54:08 GMT
Subject: Integrated: 8297885: misc sun/security/pkcs11 tests timed out
In-Reply-To: <8QVEYBnBZ_3K5s26Wh7TwceB07Xvo8PufUzKe3xq8bE=.663052f5-d1d6-46b8-b25f-d56c1808bc43@github.com>
References: <8QVEYBnBZ_3K5s26Wh7TwceB07Xvo8PufUzKe3xq8bE=.663052f5-d1d6-46b8-b25f-d56c1808bc43@github.com>
Message-ID: <gl9xnUXVmPkUwu4vAjcaNcwgcxHIQBWwOZwpsp9VDus=.7b9069e2-0213-4beb-b490-170ffa4e23c8@github.com>

On Sat, 27 May 2023 01:49:22 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> Increase the timeout value of the "LargeDSAKey,java" test to address the intermittent test failure(s). As for the other mentioned test failures, the execution time fluctuates even less, so leaving them alone for now.
> 
> Thanks in advance for the review~

This pull request has now been integrated.

Changeset: 7891de33
Author:    Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7891de331a42719234652e0fb3da6827c083707c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8297885: misc sun/security/pkcs11 tests timed out

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.org/jdk/pull/14190

From valeriep at openjdk.org  Tue May 30 18:03:17 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 30 May 2023 18:03:17 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <l446xHCJ70yAyV41qqTzZa6zWOuSVwQ1KOw0fTZzu5Y=.8e10da5a-2884-4203-b89b-430f27f95aa6@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <ma2h-xonfuTGxyW7-TU7qjxRXyC6sD8fney7DzU9iz8=.29e9c63b-c460-440c-a22c-c545c2abf61f@github.com>
 <l446xHCJ70yAyV41qqTzZa6zWOuSVwQ1KOw0fTZzu5Y=.8e10da5a-2884-4203-b89b-430f27f95aa6@github.com>
Message-ID: <QALb47MGwoTUJcA-0bOCj42va1qZFaDf9UL_p23DBeg=.0b9da92e-719b-4f9a-8176-539a8b3169d8@github.com>

On Thu, 25 May 2023 23:58:00 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java line 213:
>> 
>>> 211:         sb.append(Constants.INDENT);
>>> 212:         sb.append("pParameter:");
>>> 213:         sb.append(Constants.NEWLINE);
>> 
>> Is this intended? It seems NEWLINE is not added beforehand for other fields.
>
> We found it more clear to start in a new line when showing the inner parameters. The reason is that inner parameters can be a structure (as in the PBE case) which has its own "member-name:" and new lines. It looked a bit odd when we had for example "    pParameter:    pInitVector:" in the first line and the rest of the inner structure below.

I see. Sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1210633926

From valeriep at openjdk.org  Tue May 30 18:07:07 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 30 May 2023 18:07:07 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v5]
In-Reply-To: <I-RAdYFHa3EtwW8rnIpaTuOrR0lvnsVu2_sJqJSrdRg=.7347b0ce-b7e3-4630-8948-42a0194ab4bb@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <DEATY5iUruWYuhIA1PfmNujX8_qrY5iPqPFePgBdweM=.f996bdf3-4215-4fdb-b097-8733fe3fb2b9@github.com>
 <cOdMxB-RhdE0UQMEz7S7CAKtB2bOUtyjtBwF3hKA2DE=.296c398f-2be0-4a9a-bdb9-2336870e959a@github.com>
 <I-RAdYFHa3EtwW8rnIpaTuOrR0lvnsVu2_sJqJSrdRg=.7347b0ce-b7e3-4630-8948-42a0194ab4bb@github.com>
Message-ID: <5_wCKHaI1JDgUcT3sK5FJpzrVOw9oVoUAxQbod4Z0go=.adcd4796-97aa-433e-b448-3aa9182e43c4@github.com>

On Wed, 24 May 2023 19:23:39 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java line 71:
>> 
>>> 69:     private Mac prf;
>>> 70:     @SuppressWarnings("serial")
>>> 71:     private Cleaner.Cleanable cleaner;
>> 
>> why not directly mark "cleaner" as transient? Then you should not need `@SuppressWarnings` tag.
>
> We thought about transient and then changed to suppress the warning to keep consistency with ```private Mac prf```. I'll change both to transient then.

Sure, I think using transient is clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1210638477

From mullan at openjdk.org  Tue May 30 18:34:59 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 30 May 2023 18:34:59 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v7]
In-Reply-To: <0rm32dgNPxsrj1ErRROktUDMRbce0lJWGPWsUw6YOSw=.e7d7f8b2-b8dd-4783-8e9c-76b188dd3034@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <0rm32dgNPxsrj1ErRROktUDMRbce0lJWGPWsUw6YOSw=.e7d7f8b2-b8dd-4783-8e9c-76b188dd3034@github.com>
Message-ID: <r8iODd3STAppAgxjwB_cCERK8YvxbptjHY2wjusW7jo=.232f18ae-fbc2-4d34-bde9-524ce391cec2@github.com>

On Tue, 30 May 2023 16:47:03 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sean's additional comments take 2

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13940#pullrequestreview-1451579965

From kdriver at openjdk.org  Tue May 30 19:12:10 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 30 May 2023 19:12:10 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v24]
In-Reply-To: <xdPsbMYsrBGiDzvjKnd2MKQ12Y4L6uHU3nNwxPMhn5s=.b5ffd5b9-9f49-4037-8407-d341f0251d08@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <oWD0Wk9agQo1_5LgNFFBu0gsZ5fW4ok_HepENOiWHlo=.e5c7e31b-c958-4fd7-9319-46e099c644e6@github.com>
 <xdPsbMYsrBGiDzvjKnd2MKQ12Y4L6uHU3nNwxPMhn5s=.b5ffd5b9-9f49-4037-8407-d341f0251d08@github.com>
Message-ID: <xL2sgHcX1pAgmWGZC4EHxWUIpZrmXodymukHyGuB2sU=.aad21d80-932f-4318-83a3-04d4ee7ddaef@github.com>

On Tue, 30 May 2023 15:23:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
>>  - wrapping
>>  - addressed remaining code review comments
>>  - Merge branch 'master' of github.com:openjdk/jdk into JDK-8294985
>>  - run tests with othervm
>>  - working testcase for CertificateRequest for TLS1.2
>>  - new version of second test
>>  - initial commit of second test
>>  - reintroduce bug id to test header
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8294985
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/bbf628a3...2a35a7cc
>
> src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java line 28:
> 
>> 26: package sun.security.ssl;
>> 27: 
>> 28: import sun.security.ssl.SSLExtension.ExtensionConsumer;
> 
> Please keep the previous import order for consistency with other code in this package. All code in `sun.security.ssl` generally orders the imports as `java`, `javax`, then internal (`sun`), etc.

we need a code style template for IDEs :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1210712213

From kdriver at openjdk.org  Tue May 30 19:24:09 2023
From: kdriver at openjdk.org (Kevin Driver)
Date: Tue, 30 May 2023 19:24:09 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v25]
In-Reply-To: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
Message-ID: <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>

> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)

Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:

 - undo import changes
 - undo import changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13466/files
  - new: https://git.openjdk.org/jdk/pull/13466/files/2a35a7cc..af035c39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13466&range=23-24

  Stats: 28 lines in 2 files changed: 3 ins; 14 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13466/head:pull/13466

PR: https://git.openjdk.org/jdk/pull/13466

From valeriep at openjdk.org  Tue May 30 19:42:12 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 30 May 2023 19:42:12 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <D_TyjFSqX8Kt7vB5-IFqG4gZiaIEKPd_HjrervXzsks=.82f024a0-8b3c-4264-b156-5a874defabb1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <rodHJ4q6YCe62mc7iMNTM1sX5rrxsxhSmPZzoFrCgz0=.aca62528-3ac4-4fad-8829-d8bf410254c6@github.com>
 <D_TyjFSqX8Kt7vB5-IFqG4gZiaIEKPd_HjrervXzsks=.82f024a0-8b3c-4264-b156-5a874defabb1@github.com>
Message-ID: <bRvTlDeYeYyt2fjMbOsyBVHIPL0qPdVmuaof1LRcap0=.70319dd9-e68b-4ea6-9eb5-3a82934c82bf@github.com>

On Tue, 23 May 2023 14:00:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We found several more cases of passwords and encoded keys not cleared that were addressed in out Iteration # 2 commit. These cases were both in Java and native code. We still have doubts about the effectiveness and need for these actions, but prefer to have the discussion on a different channel.
>> 
>> We also found that invalid keys (not starting with the name "PBE") passed to PBES2Core::engineInit or P11PBECipher::engineInit were being cleared and this could be unexpected to the caller. This is related to my comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1199513839). For these cases, we decided not to invoke ::getEncoded and not to clean. As said, we have concerns about these undocumented mutations to objects passed by argument.
>> 
>> No test regressions observed in jdk/com/sun/crypto/provider or jdk/sun/security/pkcs11.
>
> @martinuy I am adding a CSR requirement for this issue. In this Enhancement, you are adding support for new algorithms in a JCE provider. This type of change requires a CSR as you are adding support for algorithms that can be used by applications and not just inside the JDK, thus it is a type of exported interface of JDK scope. For an example of a similar issue, see [JDK-8274174](https://bugs.openjdk.org/browse/JDK-8274174). The CSR should also include details about any behavioral changes or differences that affect use of the algorithms through the standard JCE APIs.

> @seanjmullan @valeriepeng , can you please take a look at the proposed [JDK-8308719](https://bugs.openjdk.org/browse/JDK-8308719) CSR?

Under the "Specification" section, the Cipher ones list out the required mech(s). But the rest, e.g. SecretKeyFactory and Mac, have X and Y. Based on the code in SunPKCS11.java, it seems Y is the required one and X is the one which is used. We should either follow the convention as in Cipher or explain what "X and Y" means.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1568981784

From xuelei at openjdk.org  Tue May 30 20:08:08 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 30 May 2023 20:08:08 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v25]
In-Reply-To: <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
Message-ID: <e1B08r3xyN9DJOt5v3L5FqozhF9kduj7GAdGHIhdOc8=.bea7c6f4-7035-4fd7-8650-006f9260bfab@github.com>

On Tue, 30 May 2023 19:24:09 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo import changes
>  - undo import changes

My concerns for tests were addressed.  Thanks!

-------------

Marked as reviewed by xuelei (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1451732655

From valeriep at openjdk.org  Tue May 30 22:07:11 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 30 May 2023 22:07:11 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v6]
In-Reply-To: <onz_7DOZAZkgGr-DGGj45BGLcjptpMEQvOFJnw3OW68=.746c265f-3c61-4d8a-bbe9-33f5447d7af6@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <onz_7DOZAZkgGr-DGGj45BGLcjptpMEQvOFJnw3OW68=.746c265f-3c61-4d8a-bbe9-33f5447d7af6@github.com>
Message-ID: <CPOAd7ntP29ikGyR2FtbBWpEi8AMk6b46wCHygWWIfw=.e70b8231-6ba3-47c1-b7b8-2126e3603c5a@github.com>

On Sat, 27 May 2023 06:24:36 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/java.base/share/classes/sun/security/util/PBEUtil.java line 105:

> 103:                                 "needed for decryption");
> 104:                     }
> 105:                 }

Isn't there also default value for iteration count? 'params' can be PBEParameterSpec (line 82) but its salt and iteration count values aren't used comparing to the IvParameterSpec inside. Seems a bit inconsistent?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1210867785

From valeriep at openjdk.org  Tue May 30 22:50:12 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 30 May 2023 22:50:12 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v6]
In-Reply-To: <onz_7DOZAZkgGr-DGGj45BGLcjptpMEQvOFJnw3OW68=.746c265f-3c61-4d8a-bbe9-33f5447d7af6@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <onz_7DOZAZkgGr-DGGj45BGLcjptpMEQvOFJnw3OW68=.746c265f-3c61-4d8a-bbe9-33f5447d7af6@github.com>
Message-ID: <c64haOhRFnD0u_8--7I_qzjR75wDguCyfKycq3U0xP8=.e813257f-290e-477b-8ae1-0c5f37cc5fcd@github.com>

On Sat, 27 May 2023 06:24:36 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/java.base/share/classes/sun/security/util/PBEUtil.java line 182:

> 180:                     // salt should be non-null per PBEParameterSpec
> 181:                     iCountInit = check(pbeParams.getIterationCount());
> 182:                     saltInit = check(pbeParams.getSalt());

Why not override params with the IvParameterSpec inside the PBEParameterSpec here? Then the PBES2Params.initialize(...) method does not need to handle PBEParameterSpec type? Seems more consistent this way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1210898390

From valeriep at openjdk.org  Tue May 30 23:45:09 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 30 May 2023 23:45:09 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v6]
In-Reply-To: <onz_7DOZAZkgGr-DGGj45BGLcjptpMEQvOFJnw3OW68=.746c265f-3c61-4d8a-bbe9-33f5447d7af6@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <onz_7DOZAZkgGr-DGGj45BGLcjptpMEQvOFJnw3OW68=.746c265f-3c61-4d8a-bbe9-33f5447d7af6@github.com>
Message-ID: <d56SvIlZYRTYgsGG2Ngzwj0cUqaRZQc1inSM3dL7qYs=.0b153bc3-f1aa-479b-9c16-6a91b58c2286@github.com>

On Sat, 27 May 2023 06:24:36 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> We would like to propose an implementation for the [JDK-8301553: Support Password-Based Cryptography in SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement requirement.
>> 
>> In addition to pursuing the requirement goals and guidelines of [JDK-8301553](https://bugs.openjdk.org/browse/JDK-8301553), we want to share the following implementation notes (grouped per altered file):
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/HmacPKCS12PBECore.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #12 General Method for Password Integrity](https://datatracker.ietf.org/doc/html/rfc7292#appendix-B) algorithms. It has been modified with the intent of consolidating all parameter checks in a common file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can be used both by ```SunJCE``` and ```SunPKCS11```. This change does not only serve the purpose of avoiding duplicated code but also ensuring alignment and compatibility between different implementations of the same algorithms. No changes have been made to parameter checks themselves.
>>     * The new ```PBEUtil::getPBAKeySpec``` method introduced for parameters checking takes both a ```Key``` and a ```AlgorithmParameterSpec``` instance (same as the ```HmacPKCS12PBECore::engineInit``` method), and returns a ```PBEKeySpec``` instance which consolidates all the data later required to proceed with the computation (password, salt and iteration count).
>> 
>>   * ```src/java.base/share/classes/com/sun/crypto/provider/PBES2Core.java``` (modified)
>>     * This file contains the ```SunJCE``` implementation for the [PKCS #5 Password-Based Encryption Scheme](https://datatracker.ietf.org/doc/html/rfc8018#section-6.2) algorithms, which use PBKD2 algorithms underneath for key derivation. In the same spirit than for the ```HmacPKCS12PBECore``` case, we decided to consolidate common code for parameters validation and default values in a single file (```src/java.base/share/classes/sun/security/util/PBEUtil.java```), that can serve both ```SunJCE``` and ```SunPKCS11``` and ensure compatibility. However, instead of a single static method at the implementation level (see ```PBEUtil::getPBAKeySpec```), we create an instance of an auxiliary class and invoke an instance method (```PBEUtil.PBES2Params::getPBEKeySpec```). The reason is to persist parameters data that has to be consistent between calls to ```PBES2Core::engineInit``` (in its multiple ...
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301553: Support Password-Based Cryptography in SunPKCS11 (iteration #4)
>   
>   Co-authored-by: Francisco Ferrari <fferrari at redhat.com>
>   Co-authored-by: Martin Balao <mbalao at redhat.com>

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java line 221:

> 219:         // for the underlying cipher is equal to the PBE service key length.
> 220:         // Otherwise, initialization fails.
> 221:         return svcPbeKi.keyLen;

This method "Returns the key size of the given key object in bits. " 
How do you ensure that this key is the one used in the initialization? This method may also throw InvalidKeyException though, With this impl, even if passing a null key, this would return an int value and not detecting the key is invalid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1210940229

From wetmore at openjdk.org  Wed May 31 04:46:08 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 31 May 2023 04:46:08 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v25]
In-Reply-To: <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
Message-ID: <DCpxFbaTlMmQZCPTRawBcO4Ma2WcQ2SnJUbbcFwZA1w=.6d89afe6-886c-4e9c-98ab-1629075aaebb@github.com>

On Tue, 30 May 2023 19:24:09 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo import changes
>  - undo import changes

These are minor nits, can go as is.

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 147:

> 145:         createBuffers();
> 146: 
> 147:         System.out.println("forcing client hello");

"Create" rather than "forcing?"

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 148:

> 146: 
> 147:         System.out.println("forcing client hello");
> 148:         //sTOc = ByteBuffer.wrap(serverHello);

Might as well delete this.  Dead code is confusing.

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 161:

> 159: 
> 160:         sTOc.compact();
> 161:         cTOs.compact();

It doesn't really matter since the code will bomb out, but I don't think this line is doing what you expected.  cTOs is already pointing at the beginning of the Buffer.

-------------

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13466#pullrequestreview-1452190853
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211077478
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211077197
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211080473

From djelinski at openjdk.org  Wed May 31 05:28:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 31 May 2023 05:28:10 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v25]
In-Reply-To: <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
Message-ID: <OWo7JrWkI4gVu1HAysbHvjuDzRSowQ5N3aWzf66zKQw=.d5dd3f78-cc55-484c-8d8f-93e27f51ff0a@github.com>

On Tue, 30 May 2023 19:24:09 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo import changes
>  - undo import changes

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 29:

> 27:  * @library /test/lib
> 28:  * @summary SSLEngine throws IAE during parsing of X500Principal
> 29:  * @run main/othervm TestBadDNForPeerCA

Suggestion:

 * @run main/othervm TestBadDNForPeerCA
 * @run main/othervm -Djavax.net.debug=all TestBadDNForPeerCA

and then remove the `debug` field.

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 55:

> 53:     private SSLEngine serverEngine;     // server Engine
> 54:     private ByteBuffer serverIn;        // read side of serverEngine
> 55:     private ByteBuffer clientOut;        // read side of serverEngine

Not used

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 140:

> 138:         System.out.println("injecting client hello");
> 139: 
> 140:         for (int i = 0; i < 10; i++) { //retry if survived

Is this loop really needed?

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 160:

> 158:         serverIn = ByteBuffer.allocateDirect(65536);
> 159: 
> 160:         cTOs = ByteBuffer.allocateDirect(65536);

not used - you immediately overwrite this value in runTest

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 29:

> 27:  * @library /test/lib
> 28:  * @summary SSLEngine throws IAE during parsing of X500Principal
> 29:  * @run main/othervm TestBadDNForPeerCA12

Suggestion:

 * @run main/othervm TestBadDNForPeerCA12
 * @run main/othervm -Djavax.net.debug=all TestBadDNForPeerCA12

and then remove the debug field.

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 182:

> 180:         clientOut = ByteBuffer.wrap("Hi Server, I'm Client".getBytes());
> 181: 
> 182:         sTOc = ByteBuffer.allocateDirect(65536);

not used - you immediately overwrite this value in runTest

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211096065
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211098585
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211100260
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211099134
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211097088
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211101845

From ssahoo at openjdk.org  Wed May 31 05:51:25 2023
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 31 May 2023 05:51:25 GMT
Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v2]
In-Reply-To: <Eo8xO4BX-UPh6nwDVHYd0ZjCutudkdOmFVVtKT6zB8Q=.0694d42f-7861-469c-9959-8e725a6c8dd5@github.com>
References: <Eo8xO4BX-UPh6nwDVHYd0ZjCutudkdOmFVVtKT6zB8Q=.0694d42f-7861-469c-9959-8e725a6c8dd5@github.com>
Message-ID: <zivctb1u-wiIKqvwL2efZSKTudH6c2xR_0bgyzHeE7I=.d3a01dca-8faa-4159-9080-237059dab1db@github.com>

> Additional Tests for KEM API.

Sibabrata Sahoo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge kEM
 - 8308711: Develop additional Tests for KEM implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14113/files
  - new: https://git.openjdk.org/jdk/pull/14113/files/dd210d4c..d66d7277

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=00-01

  Stats: 27879 lines in 529 files changed: 21742 ins; 3018 del; 3119 mod
  Patch: https://git.openjdk.org/jdk/pull/14113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14113/head:pull/14113

PR: https://git.openjdk.org/jdk/pull/14113

From ssahoo at openjdk.org  Wed May 31 06:27:09 2023
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 31 May 2023 06:27:09 GMT
Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v3]
In-Reply-To: <Eo8xO4BX-UPh6nwDVHYd0ZjCutudkdOmFVVtKT6zB8Q=.0694d42f-7861-469c-9959-8e725a6c8dd5@github.com>
References: <Eo8xO4BX-UPh6nwDVHYd0ZjCutudkdOmFVVtKT6zB8Q=.0694d42f-7861-469c-9959-8e725a6c8dd5@github.com>
Message-ID: <g0958ReP0--Zcy_Tpu_2vg7klvwBl0Ul0afIbl6rEkY=.c4c44d5a-5680-466c-b4b3-86c41de74c35@github.com>

> Additional Tests for KEM API.

Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:

  8308711: Comment addressed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14113/files
  - new: https://git.openjdk.org/jdk/pull/14113/files/d66d7277..610156ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14113&range=01-02

  Stats: 75 lines in 3 files changed: 21 ins; 31 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/14113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14113/head:pull/14113

PR: https://git.openjdk.org/jdk/pull/14113

From ssahoo at openjdk.org  Wed May 31 06:27:11 2023
From: ssahoo at openjdk.org (Sibabrata Sahoo)
Date: Wed, 31 May 2023 06:27:11 GMT
Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v3]
In-Reply-To: <P_6yhISa3oOzMSED5dcYcbWKk2_98MLGw75EDJAWvKA=.1843e6ff-7552-4c5d-ab2b-7d2e25921326@github.com>
References: <Eo8xO4BX-UPh6nwDVHYd0ZjCutudkdOmFVVtKT6zB8Q=.0694d42f-7861-469c-9959-8e725a6c8dd5@github.com>
 <P_6yhISa3oOzMSED5dcYcbWKk2_98MLGw75EDJAWvKA=.1843e6ff-7552-4c5d-ab2b-7d2e25921326@github.com>
Message-ID: <LqXe-XNXvLc6oH3ywMTUUfCPnMGlSQLAM1LosrR4xVM=.0e1d3762-bdc0-49af-a0b8-1d145fd9c234@github.com>

On Wed, 24 May 2023 13:00:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8308711: Comment addressed
>
> test/jdk/javax/crypto/KEM/GenLargeNumberOfKeys.java line 1:
> 
>> 1: /*
> 
> 1. `testXDH` and `testEC` are mostly identical. Maybe you can write a single method with 2 extra arguments.
> 2. According to the spec, multiple keys generated from a *single* `Encapsulator` are different. The `test` method is creating a new encapsulators each time.
> 3. There is no guarantee that a `SecretKey` follows the `hashCode/equals` convention and can be put inside a `Set` to detect duplication. It happens that in this implementation the key is a `SecretKeySpec` object so it works.

Updated accordingly.

> test/jdk/javax/crypto/KEM/KemInterop.java line 77:
> 
>> 75:                 KEM.Encapsulated enc2 = encT1.encapsulate();
>> 76: 
>> 77:                 Asserts.assertEQ(enc.key(), enc.key());
> 
> Again, we cannot guarantee `equals` between 2 `SecretKey` objects. However, since it's a positive test here, it's OK to do this. If we really modify the implementation later and return a different kind of `SecretKey`, we can update the test later.

Removed Key equals() comparison.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1211141295
PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1211141000

From wetmore at openjdk.org  Wed May 31 06:32:08 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 31 May 2023 06:32:08 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v25]
In-Reply-To: <OWo7JrWkI4gVu1HAysbHvjuDzRSowQ5N3aWzf66zKQw=.d5dd3f78-cc55-484c-8d8f-93e27f51ff0a@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
 <OWo7JrWkI4gVu1HAysbHvjuDzRSowQ5N3aWzf66zKQw=.d5dd3f78-cc55-484c-8d8f-93e27f51ff0a@github.com>
Message-ID: <l06GBiYphIqw-FstVAHzFQMyUtlQZ5ReypB1-7um1i8=.ecdacde2-0661-49de-b4b2-58cf7dda0b26@github.com>

On Wed, 31 May 2023 05:10:34 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - undo import changes
>>  - undo import changes
>
> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 29:
> 
>> 27:  * @library /test/lib
>> 28:  * @summary SSLEngine throws IAE during parsing of X500Principal
>> 29:  * @run main/othervm TestBadDNForPeerCA
> 
> Suggestion:
> 
>  * @run main/othervm TestBadDNForPeerCA
>  * @run main/othervm -Djavax.net.debug=all TestBadDNForPeerCA
> 
> and then remove the `debug` field.

When we put in the debug field into the template, it was to allow folks to quickly add debugging output to their test, but in general it won't be turned on during regular test runs.

> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 160:
> 
>> 158:         serverIn = ByteBuffer.allocateDirect(65536);
>> 159: 
>> 160:         cTOs = ByteBuffer.allocateDirect(65536);
> 
> not used - you immediately overwrite this value in runTest

He updated the Template code but didn't take all of the unused stuff out.  I'm ok with it either way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211146002
PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211147351

From djelinski at openjdk.org  Wed May 31 07:19:04 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 31 May 2023 07:19:04 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v25]
In-Reply-To: <l06GBiYphIqw-FstVAHzFQMyUtlQZ5ReypB1-7um1i8=.ecdacde2-0661-49de-b4b2-58cf7dda0b26@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
 <OWo7JrWkI4gVu1HAysbHvjuDzRSowQ5N3aWzf66zKQw=.d5dd3f78-cc55-484c-8d8f-93e27f51ff0a@github.com>
 <l06GBiYphIqw-FstVAHzFQMyUtlQZ5ReypB1-7um1i8=.ecdacde2-0661-49de-b4b2-58cf7dda0b26@github.com>
Message-ID: <tPBkH2aedSKsyculdX4r4skCtSjsjbVOybISXqbSVbY=.5c7ddc44-36a9-430f-a618-376a04c1c263@github.com>

On Wed, 31 May 2023 06:27:41 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA.java line 29:
>> 
>>> 27:  * @library /test/lib
>>> 28:  * @summary SSLEngine throws IAE during parsing of X500Principal
>>> 29:  * @run main/othervm TestBadDNForPeerCA
>> 
>> Suggestion:
>> 
>>  * @run main/othervm TestBadDNForPeerCA
>>  * @run main/othervm -Djavax.net.debug=all TestBadDNForPeerCA
>> 
>> and then remove the `debug` field.
>
> When we put in the debug field into the template, it was to allow folks to quickly add debugging output to their test, but in general it won't be turned on during regular test runs.

I'd like to enable this in the test runs as well; otherwise the changes to `toString` method will not be tested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211196467

From djelinski at openjdk.org  Wed May 31 07:19:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 31 May 2023 07:19:06 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v25]
In-Reply-To: <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
Message-ID: <JpTd4xkHsejz_oobNZGiIKlzaz82d1X9g9k1gjpNavU=.02c2c141-f56e-4eac-b322-005d2e3eef7d@github.com>

On Tue, 30 May 2023 19:24:09 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> Fixes: [JDK-8294985](https://bugs.openjdk.org/browse/JDK-8294985)
>
> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo import changes
>  - undo import changes

test/jdk/sun/security/ssl/SSLEngineImpl/TestBadDNForPeerCA12.java line 66:

> 64: 
> 65:     // this contains a server response with invalid DNs
> 66:     private static final byte[] serverPayload = Base64.getDecoder().decode(

I executed this test with debug output enabled, and didn't see any invalid DNs in the test output. The exception thrown was `Fatal (CERTIFICATE_UNKNOWN): No trusted certificate found`. Are you using the right server payload here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211198613

From weijun at openjdk.org  Wed May 31 13:15:04 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 May 2023 13:15:04 GMT
Subject: RFR: 8308711: Develop additional Tests for KEM implementation [v3]
In-Reply-To: <g0958ReP0--Zcy_Tpu_2vg7klvwBl0Ul0afIbl6rEkY=.c4c44d5a-5680-466c-b4b3-86c41de74c35@github.com>
References: <Eo8xO4BX-UPh6nwDVHYd0ZjCutudkdOmFVVtKT6zB8Q=.0694d42f-7861-469c-9959-8e725a6c8dd5@github.com>
 <g0958ReP0--Zcy_Tpu_2vg7klvwBl0Ul0afIbl6rEkY=.c4c44d5a-5680-466c-b4b3-86c41de74c35@github.com>
Message-ID: <uTYgcRIVyZqhjpN5z7EX1n7Y7RiGjMSituJAZX_j8U8=.7528b201-007c-4894-a5b6-9ee342ca9906@github.com>

On Wed, 31 May 2023 06:27:09 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> Additional Tests for KEM API.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308711: Comment addressed

test/jdk/javax/crypto/KEM/GenLargeNumberOfKeys.java line 45:

> 43:      * X448 produce keysize of 64 bytes which is larger in it's class
> 44:      * secp521r1 produce keysize of 64 bytes which is larger in it's class
> 45:      */

I don't quite understand what the comment mean.

test/jdk/javax/crypto/KEM/GenLargeNumberOfKeys.java line 64:

> 62:     private static KeyPair genKeyPair(String algo, String curveId) throws Exception {
> 63:         KeyPairGenerator kpg = KeyPairGenerator.getInstance(algo);
> 64:         kpg.initialize(new ECGenParameterSpec(curveId));

Although `ECGenParameterSpec` is a `NamedParameterSpec`, we usually don't create XDH keys using it. How about following the same style in `KemTest` and only call `initialize` when it's EC. For XDH, just use `X448` as the `algo` and there is no need to initialize it.

test/jdk/javax/crypto/KEM/KemTest.java line 129:

> 127:                 Asserts.assertEQ(encT.encapsulationSize(), decT.encapsulationSize());
> 128:                 Asserts.assertEQ(encT.secretSize(), enc.key().getEncoded().length);
> 129:                 Asserts.assertEQ(encT.secretSize(), decT.secretSize());

Since the decapsulator also has `secretSize` and `encapsulationSize` methods, you can add some more lines testing the output of them as well.

test/jdk/javax/crypto/KEM/KemTest.java line 195:

> 193:                 Callable<KEM.Encapsulator> task = () -> {
> 194:                     return kem.newEncapsulator(kp.getPublic());
> 195:                 };

Just use `() -> kem.newEncapsulator(kp.getPublic())`. Same on lines 229, 262, 300.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1211680963
PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1211685868
PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1211691568
PR Review Comment: https://git.openjdk.org/jdk/pull/14113#discussion_r1211695732

From asemenov at openjdk.org  Wed May 31 13:37:06 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 May 2023 13:37:06 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/3f343c26..d5b70cb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Wed May 31 13:40:57 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 May 2023 13:40:57 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com>
Message-ID: <E-QSGAHArixYuyceaYoN2y82lb6c5I46k4zTUySaPxg=.85916dea-e82e-48b9-9dcf-988eb89c7d2a@github.com>

On Sun, 28 May 2023 03:57:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1163:
> 
>> 1161: #if defined(__clang__)
>> 1162: #pragma clang diagnostic push
>> 1163: #pragma clang diagnostic ignored "-Wparentheses"
> 
> I think this warning is because of the several `if (init_result = ...)`?  Better would be to just add the extra parens.

done

> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 575:
> 
>> 573: if (ps_pdread(ph, (char *)link_map_addr + LINK_MAP_LD_OFFSET,
>> 574:                &lib_ld, sizeof(uintptr_t)) != PS_OK) {
>> 575: #else
> 
> What problem is being "fixed" by these?  I'm dubious that this is the best solution to whatever the problem
> is, but can't evaluate or suggest alternatives without knowing what it is.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211733228
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211732832

From asemenov at openjdk.org  Wed May 31 13:41:04 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 May 2023 13:41:04 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v2]
In-Reply-To: <fgcUzu1tyHuca8vlNWH_YqiTnDDHDvUZd7M3DB1vjsc=.b847b5af-1adb-414a-b4db-eca9d209f3a5@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <So49itlN8iwiVZ4-LlECl3FlQEgc_aCTxdIO3lcHW9k=.1d9e68b9-acec-4bb3-b5cc-8abb93482b35@github.com>
 <fgcUzu1tyHuca8vlNWH_YqiTnDDHDvUZd7M3DB1vjsc=.b847b5af-1adb-414a-b4db-eca9d209f3a5@github.com>
Message-ID: <pvomQkHL-opfRcxvMmsLepCi6JxuDQJjxecSeLZQ56w=.5992045c-32ab-44a7-9a96-a5bdc0c9dae5@github.com>

On Tue, 30 May 2023 08:14:59 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 655:
> 
>> 653:       // linker loaded it. We use "base diff" in read_lib_segments call below.
>> 654: 
>> 655:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_ADDR_OFFSET,
> 
> Extra white spaces before 'if'

done

> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 662:
> 
>> 660: 
>> 661:       // read address of the name
>> 662:                       if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NAME_OFFSET,
> 
> Extra white-spaces before 'if'

done

> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 717:
> 
>> 715: 
>> 716:     // read next link_map address
>> 717:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NEXT_OFFSET,
> 
> Extra white-spaces before 'if'

done

> src/jdk.jpackage/share/native/common/tstrings.cpp line 60:
> 
>> 58: #endif
>> 59:         // With g++ this compiles only with '-std=gnu++0x' option
>> 60:                 ret = vsnprintf(&*fmtout.begin(), fmtout.size(), format, args);
> 
> Extra white-spaces before 'ret'

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211732345
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211734132
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211734711
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211735111

From weijun at openjdk.org  Wed May 31 13:55:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 May 2023 13:55:57 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
Message-ID: <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>

On Wed, 31 May 2023 13:37:06 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:

> 45: 
> 46: // Condition was copied from
> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h

In the current version of the file above, it's written as

#if defined(__APPLE__) && (defined(__ppc__) ||...

Is it better?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211757380

From weijun at openjdk.org  Wed May 31 14:38:56 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 May 2023 14:38:56 GMT
Subject: RFR: JDK-8308872: enhance logging and some exception in
 krb5/Config.java [v2]
In-Reply-To: <4UJC2KPBhqZoUpTkK1Ee5V_fcv_6UCI8Rg_xcnZNOmY=.b97a10b2-c572-471d-93a1-319982ec1ffc@github.com>
References: <5RaRlndPHhI5EOrPIqvDhZeAah8zeFMu8DvpU0Mlouk=.a588f0a0-b30e-44be-bdae-a43b3350c694@github.com>
 <4UJC2KPBhqZoUpTkK1Ee5V_fcv_6UCI8Rg_xcnZNOmY=.b97a10b2-c572-471d-93a1-319982ec1ffc@github.com>
Message-ID: <blG-sdXeP7UWSnmyrjtZHR4vZbwlM566a5-rxMg9VE4=.e20c0429-80a1-4720-ac6d-09cc9f67b423@github.com>

On Fri, 26 May 2023 08:04:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There exists already some logging in krb5/Config.java (enabled by -Dsun.security.krb5.debug=true), this could be enhanced for easier analysis of problems. Additionally some exception(s) might be slightly adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enhance exception

Marked as reviewed by weijun (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14151#pullrequestreview-1453401469

From mbaesken at openjdk.org  Wed May 31 14:46:09 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 31 May 2023 14:46:09 GMT
Subject: RFR: JDK-8308872: enhance logging and some exception in
 krb5/Config.java [v2]
In-Reply-To: <4UJC2KPBhqZoUpTkK1Ee5V_fcv_6UCI8Rg_xcnZNOmY=.b97a10b2-c572-471d-93a1-319982ec1ffc@github.com>
References: <5RaRlndPHhI5EOrPIqvDhZeAah8zeFMu8DvpU0Mlouk=.a588f0a0-b30e-44be-bdae-a43b3350c694@github.com>
 <4UJC2KPBhqZoUpTkK1Ee5V_fcv_6UCI8Rg_xcnZNOmY=.b97a10b2-c572-471d-93a1-319982ec1ffc@github.com>
Message-ID: <h4qoOAj5iG9S5zvuCIeEifsOLXbLN_VJEyajHBo4v4Q=.45403bef-b22e-42f2-b30f-94fd3dd8ad9d@github.com>

On Fri, 26 May 2023 08:04:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There exists already some logging in krb5/Config.java (enabled by -Dsun.security.krb5.debug=true), this could be enhanced for easier analysis of problems. Additionally some exception(s) might be slightly adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enhance exception

Thanks for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14151#issuecomment-1570371987

From mbaesken at openjdk.org  Wed May 31 14:46:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 31 May 2023 14:46:10 GMT
Subject: Integrated: JDK-8308872: enhance logging and some exception in
 krb5/Config.java
In-Reply-To: <5RaRlndPHhI5EOrPIqvDhZeAah8zeFMu8DvpU0Mlouk=.a588f0a0-b30e-44be-bdae-a43b3350c694@github.com>
References: <5RaRlndPHhI5EOrPIqvDhZeAah8zeFMu8DvpU0Mlouk=.a588f0a0-b30e-44be-bdae-a43b3350c694@github.com>
Message-ID: <TVFPoDacX_2QR_bAdu3fgXdwLURzcwHLKPJzD3_QB18=.adce5198-fba7-480d-9d42-63cb35e284f3@github.com>

On Thu, 25 May 2023 14:31:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There exists already some logging in krb5/Config.java (enabled by -Dsun.security.krb5.debug=true), this could be enhanced for easier analysis of problems. Additionally some exception(s) might be slightly adjusted.

This pull request has now been integrated.

Changeset: 70670b4a
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70670b4af617699782f892ae4cb5228ec655a2d0
Stats:     15 lines in 1 file changed: 13 ins; 0 del; 2 mod

8308872: enhance logging and some exception in krb5/Config.java

Reviewed-by: weijun

-------------

PR: https://git.openjdk.org/jdk/pull/14151

From wetmore at openjdk.org  Wed May 31 14:54:07 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Wed, 31 May 2023 14:54:07 GMT
Subject: RFR: 8294985: SSLEngine throws IAE during parsing of X500Principal
 [v25]
In-Reply-To: <tPBkH2aedSKsyculdX4r4skCtSjsjbVOybISXqbSVbY=.5c7ddc44-36a9-430f-a618-376a04c1c263@github.com>
References: <107gTkhTRaIJqORWxnRuHWIOwQIgDToHjyeCB9IQcoA=.659ce7af-5533-4561-9c50-82f52a38eeb6@github.com>
 <YFnLz5B30Z3gc4FII-ejCzp8quMiLfHcu_wsqyjVooU=.ed4cb706-ce51-46d9-aafb-a3e207023b20@github.com>
 <OWo7JrWkI4gVu1HAysbHvjuDzRSowQ5N3aWzf66zKQw=.d5dd3f78-cc55-484c-8d8f-93e27f51ff0a@github.com>
 <l06GBiYphIqw-FstVAHzFQMyUtlQZ5ReypB1-7um1i8=.ecdacde2-0661-49de-b4b2-58cf7dda0b26@github.com>
 <tPBkH2aedSKsyculdX4r4skCtSjsjbVOybISXqbSVbY=.5c7ddc44-36a9-430f-a618-376a04c1c263@github.com>
Message-ID: <jrmDaUX32SWdcGrwjSvLjCeOrLKG2YVqWAe6jnvtIIE=.37c16b81-bddf-42b4-82f7-dd97ee5c1248@github.com>

On Wed, 31 May 2023 07:14:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> When we put in the debug field into the template, it was to allow folks to quickly add debugging output to their test, but in general it won't be turned on during regular test runs.
>
> I'd like to enable this in the test runs as well; otherwise the changes to `toString` method will not be tested.

Ah!  Thanks for clarifying.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13466#discussion_r1211849050

From hchao at openjdk.org  Wed May 31 15:19:00 2023
From: hchao at openjdk.org (Hai-May Chao)
Date: Wed, 31 May 2023 15:19:00 GMT
Subject: RFR: JDK-8307794 Test for HSS/LMS Signature Verification [v7]
In-Reply-To: <0rm32dgNPxsrj1ErRROktUDMRbce0lJWGPWsUw6YOSw=.e7d7f8b2-b8dd-4783-8e9c-76b188dd3034@github.com>
References: <wq33mwbxSkG2IU71dqpGmUb4TdpkYt0Z94GYjGmftgs=.c4cdfce3-01f6-4e96-b949-bc68122e060e@github.com>
 <0rm32dgNPxsrj1ErRROktUDMRbce0lJWGPWsUw6YOSw=.e7d7f8b2-b8dd-4783-8e9c-76b188dd3034@github.com>
Message-ID: <ehCDbb0YFwt33yjBfoEtwFoX73NhPpLXScoD5b1Qwc8=.cd22f898-fd93-409e-b8a4-aa497fd747c8@github.com>

On Tue, 30 May 2023 16:47:03 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8307794
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sean's additional comments take 2

test/micro/org/openjdk/bench/java/security/HSS.java line 1:

> 1: /*

HSS.java looks good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13940#discussion_r1211884102

From rhalade at openjdk.org  Wed May 31 21:11:41 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 31 May 2023 21:11:41 GMT
Subject: RFR: 8308592: Update CA interop test certificates
In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com>
References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com>
Message-ID: <FhztUQl5U-RWeFRz2PRqxA4fbNOhvogrTRQv8NcAtC4=.de85a696-6e3a-46c2-99ad-521f23509c19@github.com>

On Wed, 31 May 2023 18:03:57 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date.

Only Actalis and BuyPass CA tests are updated with latest design. Will update others soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14252#issuecomment-1570951600

From rhalade at openjdk.org  Wed May 31 21:11:41 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 31 May 2023 21:11:41 GMT
Subject: RFR: 8308592: Update CA interop test certificates
Message-ID: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com>

The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date.

-------------

Commit messages:
 - 8308592: verify inter CA
 - 8308592: Update CA interop tests
 - 8308592: Update CA interop tests

Changes: https://git.openjdk.org/jdk/pull/14252/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308592
  Stats: 4662 lines in 15 files changed: 280 ins; 3953 del; 429 mod
  Patch: https://git.openjdk.org/jdk/pull/14252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252

PR: https://git.openjdk.org/jdk/pull/14252

From duke at openjdk.org  Wed May 31 21:22:23 2023
From: duke at openjdk.org (Francisco Ferrari Bihurriet)
Date: Wed, 31 May 2023 21:22:23 GMT
Subject: RFR: 8301553: Support Password-Based Cryptography in SunPKCS11
 [v3]
In-Reply-To: <D_TyjFSqX8Kt7vB5-IFqG4gZiaIEKPd_HjrervXzsks=.82f024a0-8b3c-4264-b156-5a874defabb1@github.com>
References: <HLqPI-MYwRCRRkC8OcJapWaTD_ED7KU-UaJvtYzt-Mg=.190eb35e-1065-43b1-9bf1-45315139b2e4@github.com>
 <60dmA9kZPvvmndp73oxq9vlM8hggVY477Zm-0uGBIAQ=.9c80c67c-c41a-4e58-85a5-a3331e686bbe@github.com>
 <rodHJ4q6YCe62mc7iMNTM1sX5rrxsxhSmPZzoFrCgz0=.aca62528-3ac4-4fad-8829-d8bf410254c6@github.com>
 <D_TyjFSqX8Kt7vB5-IFqG4gZiaIEKPd_HjrervXzsks=.82f024a0-8b3c-4264-b156-5a874defabb1@github.com>
Message-ID: <S86qfOfXz7VKOKnWqUQkEVOif-L0zSBFFGZkHm6UZa8=.ee45d2d9-d070-4ae9-a419-9d0eae2abb46@github.com>

On Tue, 23 May 2023 14:00:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We found several more cases of passwords and encoded keys not cleared that were addressed in out Iteration # 2 commit. These cases were both in Java and native code. We still have doubts about the effectiveness and need for these actions, but prefer to have the discussion on a different channel.
>> 
>> We also found that invalid keys (not starting with the name "PBE") passed to PBES2Core::engineInit or P11PBECipher::engineInit were being cleared and this could be unexpected to the caller. This is related to my comment [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1199513839). For these cases, we decided not to invoke ::getEncoded and not to clean. As said, we have concerns about these undocumented mutations to objects passed by argument.
>> 
>> No test regressions observed in jdk/com/sun/crypto/provider or jdk/sun/security/pkcs11.
>
> @martinuy I am adding a CSR requirement for this issue. In this Enhancement, you are adding support for new algorithms in a JCE provider. This type of change requires a CSR as you are adding support for algorithms that can be used by applications and not just inside the JDK, thus it is a type of exported interface of JDK scope. For an example of a similar issue, see [JDK-8274174](https://bugs.openjdk.org/browse/JDK-8274174). The CSR should also include details about any behavioral changes or differences that affect use of the algorithms through the standard JCE APIs.

>> @seanjmullan @valeriepeng , can you please take a look at the proposed [JDK-8308719](https://bugs.openjdk.org/browse/JDK-8308719) CSR?
>
> Under the "Specification" section, the Cipher ones list out the required mech(s). But the rest, e.g. SecretKeyFactory and Mac, have X and Y. Based on the code in SunPKCS11.java, it seems Y is the required one and X is the one which is used.

@valeriepeng: I think there are a couple of things worth clarifying. Let's take one example of each service type.


## Cipher.PBEWithHmacSHA1AndAES_128

https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java#L883-L885

Here, one of `CKM_AES_CBC_PAD` or `CKM_AES_CBC` must be present for the _encryption/decryption_ operation (performed by the [underlying _Cipher_](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PBECipher.java#L66)). Additionally, we require `CKM_PKCS5_PBKD2` for the _derivation_ operation, and `CKM_SHA_1_HMAC` as way to anticipate the `CKP_PKCS5_PBKD2_HMAC_SHA1` availability:
https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L198-L199

A totally explicit entry would be:

|          Java Algorithm          |                         PKCS<span>#</span>11 Mechanisms                         |
|:--------------------------------:|:-------------------------------------------------------------------------------:|
| Cipher.PBEWithHmacSHA1AndAES_128 | (`CKM_AES_CBC_PAD` or `CKM_AES_CBC`) and `CKM_PKCS5_PBKD2` and `CKM_SHA_1_HMAC` |

But we decided to follow the _comma &DoubleLongRightArrow; "or"_ convention, previously established in the table, so we added the additionally required mechanisms as a parenthesised note:

|          Java Algorithm          |                                PKCS<span>#</span>11 Mechanisms                                 |
|:--------------------------------:|:----------------------------------------------------------------------------------------------:|
| Cipher.PBEWithHmacSHA1AndAES_128 | `CKM_AES_CBC_PAD`, `CKM_AES_CBC` (`CKM_PKCS5_PBKD2` and `CKM_SHA_1_HMAC` required in any case) |

## Mac.HmacPBESHA1

https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java#L620-L621

Here, `CKM_SHA_1_HMAC` must be present for the _MAC generation/verification_ operation (performed by [letting the derived key continue to the _Mac_ implementation](https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java#L227-L251)). Additionally, we require `CKM_PBA_SHA1_WITH_SHA1_HMAC` for the _derivation_ operation:
https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L230-L231

A totally explicit entry would be:

| Java Algorithm  |          PKCS<span>#</span>11 Mechanisms           |
|:---------------:|:--------------------------------------------------:|
| Mac.HmacPBESHA1 | `CKM_SHA_1_HMAC` and `CKM_PBA_SHA1_WITH_SHA1_HMAC` |

This is what we wrote (in the inverse order).

## SecretKeyFactory.PBEWithHmacSHA1AndAES_128

https://github.com/openjdk/jdk/blob/1c596e147dac5102b31a946c905843b9b19b428e/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java#L736-L737

Since the SecretKeyFactory service just derives, we require `CKM_PKCS5_PBKD2` for the _derivation_ operation, and `CKM_SHA_1_HMAC` as way to anticipate the `CKP_PKCS5_PBKD2_HMAC_SHA1` availability.

A totally explicit entry would be:

|               Java Algorithm               |    PKCS<span>#</span>11 Mechanisms     |
|:------------------------------------------:|:--------------------------------------:|
| SecretKeyFactory.PBEWithHmacSHA1AndAES_128 | `CKM_PKCS5_PBKD2` and `CKM_SHA_1_HMAC` |

This is what we wrote.

----
# Proposal

> We should either follow the convention as in Cipher or explain what "X and Y" means. Rest looks good to me.

We are more or less following the same convention as in Cipher, using _comma_ instead of _"and"_ for Mac.HmacPBESHA1 and SecretKeyFactory.PBEWithHmacSHA1AndAES_128 would wrongly imply that any of the mechanisms is enough.

With the above explanations, do you still think that this table needs more clarification? Would it improve if we add a trailing _"required in any case"_ at the end, just like the parenthesised notes? Something like:

|               Java Algorithm               |                                PKCS<span>#</span>11 Mechanisms                                 |
|:------------------------------------------:|:----------------------------------------------------------------------------------------------:|
|                  [&mldr;]                  |                                            [&mldr;]                                            |
|      Cipher.PBEWithHmacSHA1AndAES_128      | `CKM_AES_CBC_PAD`, `CKM_AES_CBC` (`CKM_PKCS5_PBKD2` and `CKM_SHA_1_HMAC` required in any case) |
|                  [&mldr;]                  |                                            [&mldr;]                                            |
|              Mac.HmacPBESHA1               |            `CKM_SHA_1_HMAC` and `CKM_PBA_SHA1_WITH_SHA1_HMAC` required in any case             |
|                  [&mldr;]                  |                                            [&mldr;]                                            |
| SecretKeyFactory.PBEWithHmacSHA1AndAES_128 |                  `CKM_PKCS5_PBKD2` and `CKM_SHA_1_HMAC` required in any case                   |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1570972521

From rhalade at openjdk.org  Wed May 31 22:35:56 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 31 May 2023 22:35:56 GMT
Subject: RFR: 8308592: Update CA interop test certificates [v2]
In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com>
References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com>
Message-ID: <uVEaHCKfFjQZEhOVIJKPVcQyrEIy7a2UliDszFO97TQ=.4c3f23e5-41b8-4def-b745-1ffdb388bfba@github.com>

> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date.

Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:

  8308592: update other tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14252/files
  - new: https://git.openjdk.org/jdk/pull/14252/files/5885e352..c607a04d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=00-01

  Stats: 329 lines in 13 files changed: 68 ins; 98 del; 163 mod
  Patch: https://git.openjdk.org/jdk/pull/14252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252

PR: https://git.openjdk.org/jdk/pull/14252

From rhalade at openjdk.org  Wed May 31 22:46:53 2023
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 31 May 2023 22:46:53 GMT
Subject: RFR: 8308592: Update CA interop test certificates [v3]
In-Reply-To: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com>
References: <0JtshP5EI51fzdMlL-yD3cusn16Tr5soiZq9fx9_1Zg=.8ed8c38f-6cd0-4e3f-b6f0-79cf5e100734@github.com>
Message-ID: <eWyG92-q-gRRDg5EvB0SiZkNf-zSMSxIJPqnDkEZ7Bk=.37cdff5f-acb1-47e9-8c6a-67c143f22863@github.com>

> The new approach uses test URLs directly to verify interoperability with CA infrastructure. This would help us avoid having regular test fixes to update test artifacts as long as CAs keep test domains up to date.

Rajan Halade has updated the pull request incrementally with one additional commit since the last revision:

  8308592: remove unused imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14252/files
  - new: https://git.openjdk.org/jdk/pull/14252/files/c607a04d..71811873

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14252&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14252/head:pull/14252

PR: https://git.openjdk.org/jdk/pull/14252